對話狀態追蹤(Dialogue State Tracking)是什麼?

在多輪對話中自動追蹤和維護對話狀態(如用戶意圖、槽值),支持對話管理和任務完成。|本頁含完整原理、應用場景、iPAS 考試重點與 3 個常見問答。

英文
Dialogue State Tracking
主題標籤
對話系統、自然語言處理、任務導向
考點定位
非 iPAS 核心術語
最後更新
2026/06/23
對話狀態追蹤(Dialogue State Tracking)是什麼? 對話系統自然語言處理
術語快查

搜尋意圖: 如果你在找「對話狀態追蹤 是什麼」或「對話狀態追蹤 和相近概念差在哪」,先看這頁的短定義、完整說明與延伸比較。

TL;DR: 在多輪對話中自動追蹤和維護對話狀態(如用戶意圖、槽值),支持對話管理和任務完成。

實用情境: 適合用在閱讀 AI 文章、產品文件或和同事討論時,先用一頁快速對齊概念。

下一步: 先讀完定義,再往下看延伸比較與對應工具,把概念轉成實際應用。

在多輪對話中自動追蹤和維護對話狀態(如用戶意圖、槽值),支持對話管理和任務完成。

核心概念

對話狀態追蹤(Dialogue State Tracking,簡稱 DST)是建立任務導向型對話系統的基礎。與開放域對話不同,任務導向型對話有明確的目標(如訂購餐廳、查詢航班),涉及結構化的信息交換。在這類對話中,需要維護對話的「狀態」,即系統當前對用戶需求的理解和對話進度的把握。

對話狀態通常由多個元素組成。意圖(Intent)表示用戶想要做什麼,例如「訂餐廳」、「查詢天氣」。槽(Slot)表示完成任務所需的信息,例如「餐廳名稱」、「時間」、「人數」。信念狀態(Belief State)是系統對用戶槽值的概率分佈估計,例如系統認為用戶想要在晚上 7 點(概率 0.8)或晚上 8 點(概率 0.1)訂餐。

DST 的關鍵挑戰在於處理自然語言的歧義、省略、指代等語言現象。用戶在同一輪對話中可能只提供部分信息,或使用代詞引用之前提到的實體。系統需要將這些自然語言表達準確對映到結構化的槽值。同時,用戶可能會更正之前的信息(「我改主意了,實際上是 8 點」),系統需要能夠更新信念狀態。

運作原理

對話狀態追蹤通常通過以下步驟進行。首先是用戶意圖和信息抽取。系統分析用戶的自然語言輸入,識別用戶的主要意圖和提供的槽值信息。這通常使用意圖分類器和序列標註模型實現。意圖分類器預測用戶的意圖(例如分類為「訂餐」或「查詢」);序列標註模型(如 BIO 標註)識別句子中的信息片段及其槽類型(例如「北京」被標註為地點,「明天」被標註為日期)。

其次是狀態更新。初始狀態為空,隨著對話進行逐步積累信息。當識別出新的槽值時,系統需要決定如何整合到當前狀態。簡單的方法是直接覆蓋(新提供的「時間」值覆蓋舊值);更複雜的方法是維護多個假設(假設 A:用戶要 7 點,假設 B:用戶要 8 點),並根據後續對話逐步篩選。

對話狀態追蹤的技術方法經歷了多個演進階段。早期的方法使用規則和槽填充(Slot Filling),手工編寫規則將自然語言對映到槽值。這種方法簡單可靠但不夠靈活。後來發展出統計方法,使用有監督機器學習在標註的對話資料上訓練。近年來,預訓練語言模型(如 BERT)被用於 DST,直接從文本預測結構化狀態,性能顯著提升。

現代的 DST 方法通常採用端到端的神經網路架構。給定對話歷史(用戶和系統的多輪對話),模型直接預測當前的對話狀態。這可以通過多種方式實現:分類方法,將狀態預測為多個分類問題;生成方法,使用序列到序列模型生成狀態描述;抽取方法,直接從對話中抽取槽值。

實際應用

在餐廳預訂系統中,DST 追蹤用戶的預訂需求。系統需要確認餐廳名稱、就餐日期、時間、人數、飲食限制等信息。當用戶說「我想訂北京的一家義大利餐廳,明天,6 人」,系統提取餐廳類型(義大利)、地點(北京)、人數(6)、日期(明天)。當用戶後續說「不,改成 8 人」,系統更新人數槽值。

在航班預訂系統中,DST 維護出發地、目的地、出發日期、返回日期、艙位級別等槽值。對話中可能出現「我要從北京飛到上海,往返」,系統提取信息;用戶進一步說「請給我商務艙」,系統更新艙位信息。

在客服系統中,DST 追蹤用戶的問題類型、涉及的產品、用戶的賬號信息等。系統可以基於追蹤的狀態進行適當的操作,如開具發票、申請退貨、轉接專業客服。

在醫療詢問系統中,DST 追蹤患者的症狀、病史、用藥情況。系統根據追蹤的信息逐步診斷,可能要求進一步的症狀描述。

在購物助手中,DST 追蹤用戶對商品的偏好(品牌、價格範圍、顏色等),根據不斷更新的偏好推薦商品。

在旅遊規劃系統中,DST 追蹤旅遊目的地、出行日期、預算、興趣偏好等,據此提供個性化的行程建議。

常見誤區

誤區一:認為 DST 就是簡單的槽填充。現代 DST 需要理解複雜的語言現象,如隱含的修飾、指代消解、語言歧義等。簡單的規則無法處理這些情況。

誤區二:認為追蹤的狀態應該 100% 準確。實際上,系統應該維護信念狀態(概率分佈)而非點估計,允許不確定性。例如,系統可能有 80% 的置信度認為用戶要 7 點,20% 認為是 8 點。當不確定時,系統可以向用戶澄清。

誤區三:認為 DST 的訓練資料越多越好。實際上,資料的品質和多樣性更重要。涵蓋各種語言變化和邊界情況的小資料集可能優於大但單調的資料集。

誤區四:忽視對話歷史中的指代和省略。用戶可能說「我還要再來一份」而不重複完整的訂單細節。系統必須能夠從歷史中推斷出用戶指代的是什麼。

與相關技術的比較

  • DST 與意圖識別:意圖識別預測用戶的高層目標(「訂餐」),DST 則追蹤完成任務所需的詳細信息(「何時」「何地」「什麼菜」)。兩者互補,都是任務導向對話的必要組件。

  • DST 與槽填充:槽填充是 DST 的一個部分,專注於從文本中抽取槽值。DST 涵蓋整個狀態追蹤過程,包括槽值的抽取、整合、更新和信念狀態的維護。

  • DST 與知識圖譜:知識圖譜提供結構化的知識表示,DST 使用類似的結構表示對話狀態。在實踐中,DST 追蹤的槽值可能需要與外部知識圖譜(如餐廳資料庫)對齐以驗證或完善信息。

  • DST 與對話管理:對話管理決定系統應該做什麼(例如是否有足夠信息進行預訂),DST 提供決策所需的信息。兩者協作實現端到端的任務導向對話。

常見問題

當用戶自相矛盾時(例如先說 6 人後說 8 人),DST 應該如何處理?

系統應該維護信念狀態而非單一值。當用戶第一次說 6 人時,系統記錄人數槽值為 6。當用戶後來說 8 人時,系統識別出這是一個更新,而非新的獨立信息,因此將信念狀態更新為 8 人。系統也可以記錄修改歷史,以便後續對話時參考。在確信用戶的真實意圖前,系統應該向用戶確認:「您確認是 8 人嗎?」這樣可以避免進行基於誤解的預訂。

DST 如何處理用戶沒有明確說明但暗示的信息?

這涉及隱含信息的推理。例如,用戶說「我想在這家餐廳訂位」,隱含地指向之前對話中提到或搜尋結果中展示的一家餐廳。系統需要保持對話上下文的追蹤,識別代詞和定冠詞短語的指代。現代方法使用預訓練的語言模型(如 BERT)聯合處理指代消解和槽值提取。系統可能還需要進行對話歷史的編碼,在編碼中包含之前提到的實體信息,幫助模型進行指代解析。

DST 的準確率如何評估?

評估指標包括聯合準確率(Joint Accuracy,所有槽值都正確的比例)和槽級準確率(Slot-level Accuracy,每個槽值單獨的準確率)。由於信念狀態涉及概率分佈,也可以使用 F1 分數或其他排序指標。評估通常在有標註的對話資料集上進行(如 MultiWOZ、DSTC 競賽資料集)。實踐中,定期人工審查系統的 DST 錯誤,識別常見的失敗模式(如某個特定槽值總是錯誤),可以指導後續的改進。