Are Large Language Models All You Need for Task-Oriented Dialogue?

올한해를 회고하며 Are Large Language Models All You Need for Task-Oriented Dialogue https://arxiv.org/pdf/2304.06556v2 논문을 읽었다.

불과 몇년 전만 해도 우리는 BERT 기반의 인텐트 분류기와 NER을 조합해 챗봇을 만들었다. 디자이너들은 수많은 예상 질문을 작성하고, 각각의 인텐트를 정교하게 설계했다. 마치 퍼즐을 맞추듯 하나하나 규칙을 정의하고 폴백을 처리하는 방식이었다. 이당시 내가 얻은 경험은 ner을 글로벌(?)하게 작업했더니 맥락을 기반한 태깅은 잘 되나 오태깅은 어쩔수 없었다. 특히 중의적인 단어들.. 그래서 도메인별 ner을 만들어야 겠다는 생각을 했다.

작년초에 생성형모델을 활용해 펑션콜기반의 챗봇을 poc을 만들어보고, 현재 운영하고 있는 플랫폼으로의 기능을 내재화 하고 싶었다. (지금은 다른부서에서 비슷한 일을 하고 있지만.. ㅎ)

의도파악

인텐트내에 예상발화를 관리 하고, 의도를 더 잘 파악하기 위해 주요 키워드를 태깅하고 되묻기(슬롯필링)을 위해 위 그림처럼 주요 핵심 키워드에 제품명이나 가격대와 같은 정보를 관리했다.

 

2022년 10월쯤 gpt계열의 모델들을 접하게 됐고, 플레이그라운드에서 써보고 많이 당황? 스러웠다. LLM의 등장으로 내가 해오던 많은 작업들이 변화될것으로 보였으니까... 이그젝트하게 관리해오던 방식에서 BERT의 룰베이스 그리고 GPT계열로 인해 더 이상 엄격한 규칙이나 수많은 예시 데이터가 필요하지 않게 되었다. 대신 자연어로 된 함수 설명만으로도 챗봇이 사용자의 의도를 이해하고 적절한 응답을 생성할 수 있게 되었다. 그만큼 챗봇을 제작하는 과정이 단순화되었고 장벽이 낮아졌다. 굳이 이해?하지 않아도 자연어로만 챗봇을 관리하고 디자인할수 있게 되었으니까... 

이런 식의 함수 정의만으로도 LLM이 자연스럽게 사용자의 의도를 파악하고 필요한 정보를 추출할 수 있게 되었다.

기존의 복잡한 파이프라인(인텐트 분류, 슬롯 필링 등을 별도로 처리)을 LLM의 펑션 콜링으로 단순화했다는 점이다. 매우 동의한다.

펑션콜이 늘어날수 있다. 그런 경우 당연히 중의적인 펑션콜이 일어나지 않도록 하는것에 대한 고민이 필요하다. 중의적인 펑션콜이 실행되면 정보가 서로 보완되어 정확도가 높아질수도 있지만, 인풋토큰을 비효율적으로 쓰기도 하고 이는 응답속도에도 영향을 준다고 생각한다.이게 검색도메인이라고 한다면 당연히 큰 데이터를 주는것 보다는 연관있는 데이터만 주는게 할루시네이션방지에도 좋다는 생각이다.

컨텍스트-상태관리

1:1채팅에서만 있던 챗봇에 대화처리를 생각해보면 컨텍스트관리도 인풋->아웃풋 인텐트를 연결하는 방식이었다. 해당 인텐트가 실행되어 다른 인텐트와 컨텍스트가 연결된다는 것이다. 

과거(?) 라고 말하기 조금 그렇지만 전에는 이렇게 처리를 했다. 사용자의 의도상태를 관리했다.

샘플예시다. llm을 사용하여 문맥전체를 고려하여 이전 대화 히스토리를 종합적으로 파악하여 의도를 분류하고, 암시적인 사용자의 의도까지 파악해서 그 다음 컨텍스트 관리를 보다 쉽게 하는 것이다.

예를 들어, 아래를 보자. 이전 히스토리를 파악하여 별도의 followup-question이 없더라도 대화의 흐름을 파악하고 관리할수 있다.

이전 대화 맥락을 파악하고, 생략된 정보를 복원하여 실제 의도를 추론하게 되는것이 llm을 활용하여 보다 쉽게 구현과 설계가 가능해지게 되었다. 

단체채팅방에서는 어떨까? 한친구는 커피를 주문하려고 하지만 또다른 친구는 그냥 본인 얘기를 할 것이다. 그럼 1:1이 아닌 단체채팅방에서는 어떻게 대화컨텍스트를 관리 해야될까?

그래서 내가 생각한 방식은 숏텀메모리의 개념을 대화주제와 대화의도를 관리하는 것이다. 그리고 이를 참고하여 llm에 던질때는 연관된 내용만 가급적 참고할수 있도록 하는 것이다. (관련된 논문은 현재 없어 팀원분들과 기고 해보려고 하는데 그럴 시간이 우리에게 주어졌을지는 모르겠네;;;)

물론 이 역시 샘플코드다.

현재 사용자들이 무슨 대화를 나누더라도, 타임디케이기반으로 가장 연관성 있는 대화만 참조하도록 하는것이다. 말많(?)았던 24년도 이프카카오에서 관련된 내용을 발표했다.  https://www.youtube.com/watch?v=DnJaHvIWt4w

 

커피얘기를 나누는 도중에 다른 잡담이나 다른 주제로 이야기를 나누더라도 다시 커피대화를 한다고 하면 관련있는 엔티티와 대화맥락을 llm이 참고 할수 있을테니 말이다.

즉, 여러 주제가 섞여도 각 스레드별 컨텍스트 유지가 가능하다. 해당 코드가 들어가진 않았지만 단순히 검색이 아닌, Action까지 수행해야 하는 트리거라고 하면 (예를 들면 커피와 여행) 서비스호출어가 없어도 관련된 대화를 나눈다면 발화인식도 가능할것으로 예상하고 있다. 컨텍스트 전환을 명시적으로 표시해 사용하는 사용자에게 이해도도 같이 맞출수 있다고 생각한다.

도메인감지와 상태추적(DST)

지금 내가 리뷰하고 있는 논문도 결이 좀 비슷한거 같다. 매 대화턴마다 llm을 두번 사용하여 활성도메인을 감지 하고 (내 생각에는 우리가 하고있는것처럼 Agent를 라우팅하는 과정) 현재 턴에서 변경되거나 새로나타는 슬롯값을 출력한다. (슬롯이라고 표현하지만 주제라고 봐도 무방할듯) 

도메인 감지 후 수동으로 설계된 도메인설명을 포함해 프롬프트로 상태를 예측한다. 해당 논문을 참고하면 현재 턴에서 변경된 슬롯-값 쌍만 생성하고 관리 한다. 그리고 이 대화턴을 업데이트해 전체 상태를 누적하고 있다. (DST가 무조건 해야되는 대화상태관리이다. 상태관리를 어떻게 정의할지는 고민이 필요하다)

그런데 해당 논문을 보면서 드는 생각은 접근이 다소 어려운데? 라는 생각이 든다. 이유는 엔티티와 인텐트의 상태관리를 하지 않아도 최근 히스토리 (렐레번스한것만 참고해서 넘기면 그룹방은 훨씬 효율적이다. 최근히스토리를 100개 넘겨도 활성채팅방은 여러대화가 오가니까)를 활용하여 QueryRe-write를 하면 사용자발화에 생략된 정보를 파악할 수 있기 때문이다. 그리고 여러턴에 긴 대화를 한경우라면 주제기반의 숏텀메모리를 활용하여 연관성 있는 정보만 참조하게 하면 된다고 생각한다.

챗봇 vs 에이전트

The Rise of AI Agents (2023, a16z)  챗봇은 대화 중심의 인터페이스이다. 주로 질문-응답 형태의 상호작용을 해왔다.

에이전트는 사용자를 대신해 무언가의 작업을 수행하고 목표 달성을 위해 능동적으로 행동한다. AutoGPT, BabyAGI가 그 예다.

이렇게 코드로 표현하면 이해가 좀 쉬우려나 추론이라는 과정이 챗봇에는 없다고 봐야한다.

사고하는 방식과 예측하여 행동하는것. 굳이 단계를 나눈다면

1. 기본적인 작업수행과 정확도 향상 > 2. 맥락 기반의 추론능력 추가 : 나도 여기까지는 고민하고 써보고 있다.

3.선제적으로 예측하여 행동하고 제안을 하는 것 : 이건 주제기반으로 활동할수 있다는걸 재작년 개인poc에서 해봤다. 서비스에 넣어볼 날도 오겠지 

4. 자율적인 의사결정 및 학습 : 강화학습이나 DPO를 고려해야 하고 피드백을 수집해야 하는데 피드백을 준다는게 어려운거라서..암묵적인 피드백을 활용해야 될거 같다. 

샘플코드다. 암묵적인? 피드백을 넣는 과정을 넣진 않았지만 내가 만드는 에이전트가 좋은지는 위와 같은 지표로 볼수 있지않을까?

Learning from User Interactions in Conversational AI" (2023) https://www.sciencepublishinggroup.com/article/10.11648/j.ajcst.20240703.11 이런 연구내용을 보면 비슷하게 접근한 방식이 있다. 아래 지표로 명시적인 유저의 피드백없이도 지표화 하는것이다. (명시적인 유저의 피드백은 노이즈도 많고 해석이 어려울수 있음)

1. 시간 기반 분석:

• 사용자의 응답 속도
• 메시지 입력 패턴
• 대화 지속 시간

1. 행동 패턴 분석:

• 링크 클릭
• 제안된 기능 사용
• 화면 스크롤 패턴

1. 컨텍스트 기반 평가:

• 이전 대화 기록과의 일관성
• 사용자 프로필과의 연관성
• 태스크 완료율

 

서비스부서에 있다보니 검토하고 도입하는데 한계가 있음을 느낀다. 기다림이라는게 주어지지 않으니까.. 나에게는 매우 아쉬운 한해다.