대화 상태 추적 (Dialogue State Tracking, DST)
1. 개요
대화 상태 추적(Dialogue State Tracking, DST)은 목적 지향 대화 시스템(Task-oriented Dialogue System)에서 사용자의 입력과 이전 대화 이력을 분석하여, 사용자의 현재 의도와 요구사항을 정형화된 상태(State)로 유지하고 업데이트하는 핵심 기술이다.
목적 지향 대화 시스템은 사용자가 특정 작업(예: 호텔 예약, 항공권 조회)을 완수하는 것을 목표로 한다. 이를 위해 시스템은 사용자가 언급한 제약 조건(Constraint)을 정확히 기억해야 하며, DST는 이러한 정보를 추출하여 '신념 상태(Belief State)'라는 형태로 관리함으로써 대화 관리자(Dialogue Manager)가 적절한 시스템 응답을 결정할 수 있도록 돕는 가교 역할을 수행한다.
DST와 대화 관리(DM)의 관계도
DST는 대화 관리(Dialogue Management)의 하위 구성 요소로서, 다음과 같은 파이프라인 구조를 가진다.
사용자 입력 $\rightarrow$ NLU(자연어 이해) $\rightarrow$ DST(대화 상태 추적) $\rightarrow$ Dialogue Policy(대화 정책) $\rightarrow$ NLG(자연어 생성) $\rightarrow$ 시스템 응답
- DST의 역할: NLU가 추출한 개별 의도(Intent)와 개체(Entity)를 누적하여, 대화 전체의 맥락을 반영한 '최종 상태'를 유지한다.
- DM과의 관계: DST가 업데이트한 상태 값은 대화 정책(Policy) 모듈의 입력값이 되며, 정책 모듈은 이 상태를 바탕으로 DB 조회 여부나 추가 질문 필요성을 판단한다.
2. 동작 원리 및 메커니즘
DST의 핵심은 신념 상태(Belief State)를 업데이트하는 것이다. 신념 상태란 시스템이 추측하는 "사용자가 현재까지 무엇을 요청했는가"에 대한 확률적 또는 결정론적 집합이다.
학술적으로 DST는 단순히 값을 할당하는 것이 아니라, 각 슬롯-값 쌍에 대한 확률 분포(Probability Distribution)를 유지하는 과정이다. 즉, 가능한 여러 값에 대해 신뢰도 점수(Confidence Score)를 계산하고, 가장 가능성이 높은 상태를 선택하여 최종 상태로 결정한다.
슬롯-값(Slot-Value) 채우기 및 업데이트 예시
DST는 주로 슬롯(Slot)과 값(Value)의 쌍으로 상태를 표현하며, 대화가 진행됨에 따라 이를 추가, 확장, 수정한다.
| 단계 |
사용자 입력 |
DST 처리 내용 |
업데이트된 상태 (Belief State) |
변경 유형 |
| T1 |
"서울행 기차표 찾아줘" |
destination 슬롯에 '서울' 할당 |
{destination: 서울} |
신규 추가 |
| T2 |
"내일 오전 10시 출발로" |
date와 time 슬롯 업데이트 |
{destination: 서울, date: 내일, time: 10:00} |
슬롯 확장 |
| T3 |
"아니, 오후 2시로 바꿔줘" |
time 슬롯 값 수정 (Overwrite) |
{destination: 서울, date: 내일, time: 14:00} |
값 수정 |
| T4 |
"서울 말고 부산으로 해줘" |
destination 슬롯 값 수정 |
{destination: 부산, date: 내일, time: 14:00} |
값 수정 |
3. 주요 접근 방식
DST 기술은 단순 규칙 기반에서 시작하여 최근 대규모 언어 모델(LLM)을 활용한 방식으로 진화해 왔다.
방식별 비교 분석
| 구분 |
규칙 기반 (Rule-based) |
통계적/딥러닝 기반 (Neural DST) |
LLM 기반 (Generative DST) |
| 메커니즘 |
정규표현식, 키워드 매칭 |
RNN, BERT, 분류 모델 |
Prompting, In-context Learning |
| 특징 |
명확한 규칙 정의 필요 |
대량의 레이블링 데이터 필요 |
사전 학습된 지식 활용 |
| 장점 |
예측 가능성 높음, 가벼움 |
도메인 내 높은 정확도 |
유연한 문맥 이해, 데이터 부족 해결 |
| 단점 |
예외 처리 어려움, 확장성 낮음 |
새로운 도메인 적용 시 재학습 필요 |
추론 비용 높음, 환각(Hallucination) |
최근에는 특정 도메인의 학습 데이터 없이도 상태를 추적하는 Zero-shot DST가 주목받고 있다. 이는 LLM의 강력한 추론 능력을 활용하여, 프롬프트에 슬롯 정의와 대화 이력을 제공하고 정형화된 형식(JSON 등)으로 상태를 출력하게 하는 방식이다.
* 작동 방식: [시스템 프롬프트: 너는 DST 모듈이다. 다음 슬롯 리스트를 참고하여 JSON 형태로 상태를 업데이트하라] $\rightarrow$ [대화 이력] $\rightarrow$ [LLM 생성 결과]
* 핵심: 별도의 파라미터 업데이트 없이 지시문(Instruction)만으로 새로운 도메인에 즉시 적용 가능하다는 점이 가장 큰 특징이다.
4. 핵심 구성 요소 및 데이터셋
기본 개념 정의
- 도메인(Domain): 대화가 이루어지는 특정 영역 (예: 호텔, 식당, 택시, 날씨).
- 슬롯(Slot): 도메인 내에서 추적해야 할 세부 정보 항목.
- 값(Value): 슬롯에 들어갈 실제 데이터.
- Ontology 기반: 미리 정의된 값의 목록(예: 음식 종류 = [한식, 중식, 일식, 이탈리안])에서 선택하는 방식.
- Open-vocabulary 기반: 정해진 목록 없이 자유 텍스트를 추출하는 방식.
대표 벤치마크 데이터셋
- MultiWOZ (Multi-Domain Wizard-of-Oz): 가장 대표적인 DST 데이터셋으로, 여러 도메인을 넘나드는 복잡한 대화 시나리오를 포함하고 있어 모델의 도메인 전환 능력을 평가하는 데 사용된다.
- SGD (Schema-Guided Dialogue): 수많은 도메인의 스키마(Schema)를 제공하여, 모델이 처음 보는 도메인에서도 슬롯을 추적할 수 있는지 평가하는 벤치마크이다.
5. 평가 지표 (Evaluation Metrics)
DST 모델의 성능을 측정하기 위해 다음과 같은 지표가 사용된다.
- Joint Goal Accuracy (JGA): DST의 가장 핵심적인 지표이다. 특정 턴(Turn)에서 모든 슬롯의 값이 정답(Ground Truth)과 정확히 일치해야만 정답으로 처리한다. 하나라도 틀리면 오답으로 처리하므로 매우 엄격한 지표이다.
- Slot Accuracy: 전체 슬롯 중 개별 슬롯이 얼마나 정확하게 예측되었는지를 측정하는 지표이다.
- MultiWOZ 평가 방식: MultiWOZ 데이터셋에서는 주로 JGA를 통해 모델이 복잡한 다중 도메인 상황에서 전체 상태를 얼마나 정확하게 유지하는지를 평가한다.
6. 한계점 및 향후 과제
DST 구현 시 다음과 같은 기술적 난제가 발생하며, 이를 해결하는 것이 향후 주요 연구 과제이다.
- 모호성 해결 (Ambiguity Resolution): 사용자가 "그거 말고 다른 곳으로"라고 말했을 때, '그거'가 가리키는 대상(지시어 해소, Coreference Resolution)을 정확히 파악해야 한다.
- 문맥 전환 (Context Switching): 호텔 예약을 하다가 갑자기 근처 식당을 묻는 경우, 이전 도메인의 상태를 유지하면서 새로운 도메인의 상태를 생성하는 능력이 필요하다.
- 오류 전파 (Error Propagation): T1 시점에서 슬롯 값을 잘못 추적하면, 이후 T2, T3 단계에서도 잘못된 상태가 유지되어 결국 시스템이 엉뚱한 응답을 내놓는 현상이다.
- 환각 현상 (Hallucination): LLM 기반 DST에서 대화 내용에 없는 정보를 임의로 생성하여 상태에 추가하는 문제가 발생하며, 이를 억제하기 위한 제약 조건 생성 연구가 진행 중이다.
7. 활용 사례 및 응용
DST는 사용자 경험(UX)을 결정짓는 핵심 요소로, 다양한 산업 분야에 적용되고 있다.
- AI 고객센터: 사용자가 상담 도중 요구사항을 변경해도 이를 즉각 반영하여 상담원에게 전달하거나 자동 처리한다.
- 가상 비서 (Siri, Bixby 등): "내일 날씨 알려줘" $\rightarrow$ "그럼 모레는?"과 같은 연속 질문에서 '날씨'라는 슬롯을 유지하며 날짜만 업데이트한다.
- 예약 시스템: 항공, 호텔, 렌터카 등 복잡한 제약 조건(날짜, 인원, 등급)이 필요한 서비스에서 정확한 필터링 조건을 생성한다.
대화 상태 업데이트 예시 (JSON)
사용자가 "강남역 근처의 이탈리안 레스토랑을 예약하고 싶어. 시간은 저녁 7시로 해줘."라고 말한 뒤, 다시 "아니, 일식으로 바꿔줘."라고 요청했을 때의 상태 변화이다.
1. 초기 상태 (Empty)
{
"domain": "restaurant",
"belief_state": {
"food": null,
"area": null,
"time": null
}
}
2. 첫 번째 요청 후 (Slot Filling)
{
"domain": "restaurant",
"belief_state": {
"food": "italian",
"area": "gangnam_station",
"time": "19:00"
}
}
3. 수정 요청 후 (Slot Overwrite)
{
"domain": "restaurant",
"belief_state": {
"food": "japanese",
"area": "gangnam_station",
"time": "19:00"
}
}
# 대화 상태 추적 (Dialogue State Tracking, DST)
## 1. 개요
**대화 상태 추적(Dialogue State Tracking, DST)**은 목적 지향 대화 시스템(Task-oriented Dialogue System)에서 사용자의 입력과 이전 대화 이력을 분석하여, 사용자의 현재 의도와 요구사항을 정형화된 상태(State)로 유지하고 업데이트하는 핵심 기술이다.
목적 지향 대화 시스템은 사용자가 특정 작업(예: 호텔 예약, 항공권 조회)을 완수하는 것을 목표로 한다. 이를 위해 시스템은 사용자가 언급한 제약 조건(Constraint)을 정확히 기억해야 하며, DST는 이러한 정보를 추출하여 '신념 상태(Belief State)'라는 형태로 관리함으로써 대화 관리자(Dialogue Manager)가 적절한 시스템 응답을 결정할 수 있도록 돕는 가교 역할을 수행한다.
### DST와 대화 관리(DM)의 관계도
DST는 대화 관리(Dialogue Management)의 하위 구성 요소로서, 다음과 같은 파이프라인 구조를 가진다.
> **사용자 입력** $\rightarrow$ **NLU**(자연어 이해) $\rightarrow$ **DST**(대화 상태 추적) $\rightarrow$ **Dialogue Policy**(대화 정책) $\rightarrow$ **NLG**(자연어 생성) $\rightarrow$ **시스템 응답**
* **DST의 역할**: NLU가 추출한 개별 의도(Intent)와 개체(Entity)를 누적하여, 대화 전체의 맥락을 반영한 '최종 상태'를 유지한다.
* **DM과의 관계**: DST가 업데이트한 상태 값은 대화 정책(Policy) 모듈의 입력값이 되며, 정책 모듈은 이 상태를 바탕으로 DB 조회 여부나 추가 질문 필요성을 판단한다.
---
## 2. 동작 원리 및 메커니즘
DST의 핵심은 **신념 상태(Belief State)**를 업데이트하는 것이다. 신념 상태란 시스템이 추측하는 "사용자가 현재까지 무엇을 요청했는가"에 대한 확률적 또는 결정론적 집합이다.
학술적으로 DST는 단순히 값을 할당하는 것이 아니라, 각 슬롯-값 쌍에 대한 **확률 분포(Probability Distribution)**를 유지하는 과정이다. 즉, 가능한 여러 값에 대해 신뢰도 점수(Confidence Score)를 계산하고, 가장 가능성이 높은 상태를 선택하여 최종 상태로 결정한다.
### 슬롯-값(Slot-Value) 채우기 및 업데이트 예시
DST는 주로 **슬롯(Slot)**과 **값(Value)**의 쌍으로 상태를 표현하며, 대화가 진행됨에 따라 이를 추가, 확장, 수정한다.
| 단계 | 사용자 입력 | DST 처리 내용 | 업데이트된 상태 (Belief State) | 변경 유형 |
| :--- | :--- | :--- | :--- | :--- |
| **T1** | "서울행 기차표 찾아줘" | `destination` 슬롯에 '서울' 할당 | `{destination: 서울}` | 신규 추가 |
| **T2** | "내일 오전 10시 출발로" | `date`와 `time` 슬롯 업데이트 | `{destination: 서울, date: 내일, time: 10:00}` | 슬롯 확장 |
| **T3** | "아니, 오후 2시로 바꿔줘" | `time` 슬롯 값 수정 (Overwrite) | `{destination: 서울, date: 내일, time: 14:00}` | 값 수정 |
| **T4** | "서울 말고 부산으로 해줘" | `destination` 슬롯 값 수정 | `{destination: 부산, date: 내일, time: 14:00}` | 값 수정 |
---
## 3. 주요 접근 방식
DST 기술은 단순 규칙 기반에서 시작하여 최근 대규모 언어 모델(LLM)을 활용한 방식으로 진화해 왔다.
### 방식별 비교 분석
| 구분 | 규칙 기반 (Rule-based) | 통계적/딥러닝 기반 (Neural DST) | LLM 기반 (Generative DST) |
| :--- | :--- | :--- | :--- |
| **메커니즘** | 정규표현식, 키워드 매칭 | RNN, BERT, 분류 모델 | Prompting, In-context Learning |
| **특징** | 명확한 규칙 정의 필요 | 대량의 레이블링 데이터 필요 | 사전 학습된 지식 활용 |
| **장점** | 예측 가능성 높음, 가벼움 | 도메인 내 높은 정확도 | 유연한 문맥 이해, 데이터 부족 해결 |
| **단점** | 예외 처리 어려움, 확장성 낮음 | 새로운 도메인 적용 시 재학습 필요 | 추론 비용 높음, 환각(Hallucination) |
### 최신 LLM 기반 Zero-shot DST 기법
최근에는 특정 도메인의 학습 데이터 없이도 상태를 추적하는 **Zero-shot DST**가 주목받고 있다. 이는 LLM의 강력한 추론 능력을 활용하여, 프롬프트에 슬롯 정의와 대화 이력을 제공하고 정형화된 형식(JSON 등)으로 상태를 출력하게 하는 방식이다.
* **작동 방식**: `[시스템 프롬프트: 너는 DST 모듈이다. 다음 슬롯 리스트를 참고하여 JSON 형태로 상태를 업데이트하라]` $\rightarrow$ `[대화 이력]` $\rightarrow$ `[LLM 생성 결과]`
* **핵심**: 별도의 파라미터 업데이트 없이 지시문(Instruction)만으로 새로운 도메인에 즉시 적용 가능하다는 점이 가장 큰 특징이다.
---
## 4. 핵심 구성 요소 및 데이터셋
### 기본 개념 정의
1. **도메인(Domain)**: 대화가 이루어지는 특정 영역 (예: 호텔, 식당, 택시, 날씨).
2. **슬롯(Slot)**: 도메인 내에서 추적해야 할 세부 정보 항목.
3. **값(Value)**: 슬롯에 들어갈 실제 데이터.
* **Ontology 기반**: 미리 정의된 값의 목록(예: 음식 종류 = [한식, 중식, 일식, 이탈리안])에서 선택하는 방식.
* **Open-vocabulary 기반**: 정해진 목록 없이 자유 텍스트를 추출하는 방식.
### 대표 벤치마크 데이터셋
* **MultiWOZ (Multi-Domain Wizard-of-Oz)**: 가장 대표적인 DST 데이터셋으로, 여러 도메인을 넘나드는 복잡한 대화 시나리오를 포함하고 있어 모델의 도메인 전환 능력을 평가하는 데 사용된다.
* **SGD (Schema-Guided Dialogue)**: 수많은 도메인의 스키마(Schema)를 제공하여, 모델이 처음 보는 도메인에서도 슬롯을 추적할 수 있는지 평가하는 벤치마크이다.
---
## 5. 평가 지표 (Evaluation Metrics)
DST 모델의 성능을 측정하기 위해 다음과 같은 지표가 사용된다.
* **Joint Goal Accuracy (JGA)**: DST의 가장 핵심적인 지표이다. 특정 턴(Turn)에서 **모든 슬롯의 값이 정답(Ground Truth)과 정확히 일치**해야만 정답으로 처리한다. 하나라도 틀리면 오답으로 처리하므로 매우 엄격한 지표이다.
* **Slot Accuracy**: 전체 슬롯 중 개별 슬롯이 얼마나 정확하게 예측되었는지를 측정하는 지표이다.
* **MultiWOZ 평가 방식**: MultiWOZ 데이터셋에서는 주로 JGA를 통해 모델이 복잡한 다중 도메인 상황에서 전체 상태를 얼마나 정확하게 유지하는지를 평가한다.
---
## 6. 한계점 및 향후 과제
DST 구현 시 다음과 같은 기술적 난제가 발생하며, 이를 해결하는 것이 향후 주요 연구 과제이다.
1. **모호성 해결 (Ambiguity Resolution)**: 사용자가 "그거 말고 다른 곳으로"라고 말했을 때, '그거'가 가리키는 대상(지시어 해소, Coreference Resolution)을 정확히 파악해야 한다.
2. **문맥 전환 (Context Switching)**: 호텔 예약을 하다가 갑자기 근처 식당을 묻는 경우, 이전 도메인의 상태를 유지하면서 새로운 도메인의 상태를 생성하는 능력이 필요하다.
3. **오류 전파 (Error Propagation)**: T1 시점에서 슬롯 값을 잘못 추적하면, 이후 T2, T3 단계에서도 잘못된 상태가 유지되어 결국 시스템이 엉뚱한 응답을 내놓는 현상이다.
4. **환각 현상 (Hallucination)**: LLM 기반 DST에서 대화 내용에 없는 정보를 임의로 생성하여 상태에 추가하는 문제가 발생하며, 이를 억제하기 위한 제약 조건 생성 연구가 진행 중이다.
---
## 7. 활용 사례 및 응용
DST는 사용자 경험(UX)을 결정짓는 핵심 요소로, 다양한 산업 분야에 적용되고 있다.
* **AI 고객센터**: 사용자가 상담 도중 요구사항을 변경해도 이를 즉각 반영하여 상담원에게 전달하거나 자동 처리한다.
* **가상 비서 (Siri, Bixby 등)**: "내일 날씨 알려줘" $\rightarrow$ "그럼 모레는?"과 같은 연속 질문에서 '날씨'라는 슬롯을 유지하며 날짜만 업데이트한다.
* **예약 시스템**: 항공, 호텔, 렌터카 등 복잡한 제약 조건(날짜, 인원, 등급)이 필요한 서비스에서 정확한 필터링 조건을 생성한다.
### 대화 상태 업데이트 예시 (JSON)
사용자가 "강남역 근처의 이탈리안 레스토랑을 예약하고 싶어. 시간은 저녁 7시로 해줘."라고 말한 뒤, 다시 "아니, 일식으로 바꿔줘."라고 요청했을 때의 상태 변화이다.
**1. 초기 상태 (Empty)**
```json
{
"domain": "restaurant",
"belief_state": {
"food": null,
"area": null,
"time": null
}
}
```
**2. 첫 번째 요청 후 (Slot Filling)**
```json
{
"domain": "restaurant",
"belief_state": {
"food": "italian",
"area": "gangnam_station",
"time": "19:00"
}
}
```
**3. 수정 요청 후 (Slot Overwrite)**
```json
{
"domain": "restaurant",
"belief_state": {
"food": "japanese",
"area": "gangnam_station",
"time": "19:00"
}
}
```