[가상인간연구팀 김석겸]
목적 지향 대화(Goal-Oriented Dialogue) 혹은 과제 지향 대화(Task-Oriented Dialogue, TOD)는 특정 업무를 달성하는 것을 목표로 대화하는 것을 말합니다. Open-domain dialogue(ODD)는 대화 자체가 목적인 것에 비해, TOD는 목표가 뚜렷합니다. ODD가 대화가 목적이기 때문에 대화 턴수를 늘리는 것이 성과 중 하나로 볼 수 있는데, TOD는 목표를 빠른 시간 안에 성공하는 것이 성과 중 하나입니다.
TOD는 아래 그림에서 볼 수 있듯이 3가지 방식으로 구성 가능합니다. 파이프라인(pipeline) 시스템, 엔드투엔드(end-to-end ) 시스템, 조합(joint) 시스템이 있습니다. 이번 글에서는 이 세 개의 시스템을 다양한 방식으로 평가하는 논문을 통해 TOD의 현 주소를 조명하고자 합니다. 2020년에 나온 논문이지만 의미 있다고 생각해서 이렇게 가져왔습니다.
파이프라인(pipeline) 혹은 모듈러(modular) 방식은 일반적으로 4가지 구성요소로 이루어져 있습니다. 다음 네 가지를 순차적으로 수행하여 에이전트의 응답을 해내는 방식입니다.
- Natural Language Understanding (NLU): 의도 분류, 개체명 인식, 감정 분석 등 자연어 표현을 기계가 이해할 수 있는 다른 표현으로 변환시키는 기술
- Dialogue State Tracker (DST): 대화의 상태를 추적하는 기술
- Dialogue Policy: 과거 대화 상태를 기반으로 시스템 행동을 예측하는 기술
- Natural Language Generation (NLG): 시스템 계산의 결과를 사람의 언어, 자연어로 만들어내는 기술
End-to-end 시스템은 대화 히스토리로부터 바로 에이전트의 응답을 생성해내는 방식입니다.
Joint 시스템은 위 두 시스템의 중간 정도라고 보시면 됩니다. 파이프라인 방식의 4가지 중 일부를 결합한 방식입니다. 예를 들어, word-level DST는 NLU와 DST 를 결합한 방식이고 word-level Policy는 policy와 NLG 를 결합한 시스템입니다.
이 경험 연구에서는 네 가지 연구적 질문을 던지며 실험을 진행합니다.
- 어떤 구성이 가장 높은 성능을 내는가
- 구성요소별, 싱글턴 평가척도가 시스템별 멀티턴 평가척도에서도 효과가 있는지
- 다른 태스크 복잡도(e.g. single domain vs multi domain)에서 시스템의 성능은 어떻게 달라질까
- 시뮬레이터 평가와 인간 평가 간 관련도가 높을까
실험 세팅
- Data: MultiWOZ
- multi domain, multi intent task-oriented dialogs corpus
- dialog states와 system acts 가 대화문장마다 다 명시되어 있음
- User Goal: 간단히 말해서 대화를 통해 사용자가 달성하고자 하는 목표 상태를 말함.
- 지정된 제약사항, 필요한 정보를 포함하는 목표 상태를 설명함
- 올바른 비교를 위해 simulator 와 인간 평가자 모두에게 1,000개씩 user goal 을 할당하여 평가
- Platform and Simulator: ConvLab
- 다양한 시스템 구성으로 TOD agent를 구성할 수 있도록 해주는 플랫폼이자 평가 툴
- Amazon Mechanical Turk와 같은 크라우드 소싱 기능도 가능하여 인간 평가도 가능
- Evaluation Metrics
- Turn: user goal을 달성하는데 걸린 대화 턴 수 (최대 20턴까지만 지켜봄 -> 최악이 20)
- 20턴 안에 목적을 이루지 못하면 실패로 간주
- Inform: 요청한 정보가 모두 충족되었는지 평가(slot)
- Precision
- Recall
- F1
- Match Rate: 추출한 개체명이 user goal 내에 정의된 모든 제약사항을 충족하는지 평가
- Success Rate: user goal 달성한 비율.
- inform recall과 match rate가 모두 1일 때만 해당 대화 세션이 성공했다고 간주
- Turn: user goal을 달성하는데 걸린 대화 턴 수 (최대 20턴까지만 지켜봄 -> 최악이 20)
각 시스템 구성요소로 어떤 모델이 쓰였는지 특징만 간략히 살펴보겠습니다.
- System Configurations
- NLU – intent classification, slot filling 두 가지 과제로 평가
- MILU: RNN-based model
- multi domain, intent, slots 대응 가능
- BERT
- fine tuning 하여 사용
- MILU: RNN-based model
- DST – slot filling으로 평가
- Rule-based DST: NLU의 출력을 그대로 업데이트하는 방식 사용
- word-level DST
- 종류
- MDBT: 멀티 도메인 분류기, 모든 가능한 후보 slot과 value를 열거
- SUMBT: BERT encoder 기반, slot-utterance 매칭 아키텍쳐 사용
- TRADE: 도메인 간 지식을 공유해서 slot value를 바로 생성
- COMER: 위계적 인코더-디코더 모델 사용하여 state 생성
- 평가 척도
- slot accuracy: 각 triplet (domain, slot, value)를 각 정답과 비교하여 일치하면 맞은 것으로 간주하는 정확도
- joint accuracy: 해당 턴의 모든 triplet이 정답과 일치하여야 맞은 것으로 간주하는 정확도
- 종류
- Policy
- 단일 policy
- Rule-based
- GDPL: 강화학습 기반 정책, reward function 학습에 활용
- word-level policy
- MDRG: 대화 상태를 조건 짓는데 attention 메카니즘 활용
- HDSA: 위계적 dialog act 예측값으로부터 시스템 응답을 얻음
- LaRL: latent action framework 를 활용
- 단일 policy
- NLG
- Retrieval-based
- SCLSTM: 생성 모델, RNN에 sentence planning cell을 추가
- 평가 척도
- BLEU score
- Slot Error Rate(SER): 생성 문장 안에 놓치거나 잘못 만든 슬랏이 얼마나 있는지
- E2E
- TSCP: 대화 상태를 표현하기 위해 belief span 활용
- DAMD: action span도 활용하여 dialog acts를 추가 정보로 활용
- NLU – intent classification, slot filling 두 가지 과제로 평가
실험 결과
RQ1. 시스템 구성에 따라 성능이 어떻게 다른지
결과 해석이 필요한 부분이 굉장히 많은 표지만 제가 주목한 부분은 TOD의 특성상 많은 정보를 정확하게 전달하는 시스템이 성능이 높았다는 점입니다. 그런 면에서 pipeline system이 다른 두 시스템보다 비교적 전체적으로 성능이 우수하였습니다. 특히 BERT(NLU) + rule(DST) + rule(Policy) + retrieval(NLG) 구성이 모든 측정치에서 가장 성능이 좋았고요. 각 기능을 쪼개어 기능마다 얻을 수 있는 모든 정보를 변형하지 않고 전달하였다고 생각합니다. 같은 구성임에도 성능이 떨어지는 구성은 여러 기능을 합치는 과정에서 정보 손실이 있었습니다.
RQ2. 구성요소별, 단일턴 평가와 시스템별 멀티턴 평가가 일관되는지
Table 2 는 각 모듈의 구성요소별 성능을 측정한 표입니다. (a)에서 NLU의 성능이 table 1의 system1, system2의 성능으로 이어진다는 점에서 pipeline 구조에서 NLU 성능의 중요성을 일깨워줍니다. 당연한 논리로, 말을 이해 못했는데 답을 똑바로 하기 어려울 것이기 때문입니다. (b)에서 개별 triplet (domain, slot, value)에 대해서는 잘 예측하지만 한 턴 안에서의 모든 triplet을 맞추는 것은 50%도 안 되는 성능을 보여주고 있습니다. joint accuracy가 낮은 것이 대화의 성공률을 낮췄다고 봅니다.
앞선 내용이나 NLG 내용을 보면 구성요소별 평가와 시스템별 평가의 결과가 유사하지만 모든 결과가 그런 것은 아닙니다. 예를 들어, TRADE와 COMER 의 구성요소별 성능은 유사한데 비해 시스템별 성능은 TRADE가 더 높은 모습을 보여주고 있어 두 평가 방법 간 차이가 보입니다. 두 평가가 항상 일관되지 않기 때문에 TOD 평가시 구성요소별 평가와 시스템 평가는 함께 이루어져야 함을 시사합니다.
RQ3. 태스크 복잡도에 따른 성능 차이
table 3 는 도메인 별로도 시스템 성능 차이가 있을 수 있음을 보여줍니다. attraction이 비교적 어려워보입니다. table 4 는 도메인의 개수가 늘어날수록 시스템 성능이 떨어짐을 보여줍니다. RQ3의 결과는 태스크 복잡도가 올라갈수록 성능은 떨어진다는 일반적인 결과를 확인해줍니다.
RQ4. Simulator 와 인간의 평가 간 상관
LU 는 시스템의 언어 이해 능력, RA는 시스템의 응답 적절성을 평가한 것입니다. 왼쪽 4개 지표는 시스템 응답에 대한 인간의 평가 점수(5점 리커트 척도 사용)이고 Corr 이 시뮬레이터 점수와 인간 평가점수 간 피어슨 상관계수입니다. 상관계수가 약 0.5~0.6 정도에 분포하고 있으므로 시뮬레이터와 인간 평가가 어느 정도 유사하다고 볼 수 있습니다. 인간 평가자를 모델 개선마다 고용하는 것은 비용과 시간 면에서 비싸기 때문에 시뮬레이터의 성능은 효율성 측면에서 중요합니다.
정리 및 생각
이 업계에서 2년이란 시간은 긴 시간이지만 이 경험적 연구는 TOD 분야를 접근하고자 할 때 어떤 구성을 하고 어떤 정보가 성능에 긍정적 효과를 보이는지 잘 알려주는 연구였다고 생각합니다. 자기가 추구하는 상황에 따라 구성을 달리 선택할 수 있다고 봅니다. 예를 들어, 도전적인 것보다는 안전하게 정확한 대답을 원하는 상황에서는 시스템1과 같은 구성에 foundation model의 성능을 올리는 것이 적합해보입니다.
e2e 시스템쪽으로 생성 모델 중심으로 성능 향상이 계속해서 이루어지고 있기 때문에 table 1의 성능 결과는 일시적일 수 있습니다. system 1과 같은 구성은 비교적 단순해서 개선의 여지가 적습니다. 오히려 향후 연구 분야에서는 생성 모델의 베이스라인으로서의 역할이 주역할이 되지 않을까도 싶습니다.
또 다른 의견은 효율성의 측면에서 볼 수 있습니다. 모든 대화를 학습해서 해야 하는 상황이라면 학습의 부담이 있습니다. Rule 기반의 추적과 추출 기반 응답을 생성모델의 출력값과 공존시켜서 학습을 하지 않아도 되는 영역을 구축하는 것도 다른 방법이 될 수 있지 않을까 싶습니다.