摘要

本文描述了一個(gè)基于計劃的、獨立于任務(wù)的對話(huà)管理框架RavenClaw。該框架的一個(gè)關(guān)鍵特點(diǎn)是，它將對話(huà)控制邏輯的特定領(lǐng)域方面與獨立于領(lǐng)域的對話(huà)技巧隔離開(kāi)來(lái)，并在這個(gè)過(guò)程中促進(jìn)了在復雜的、面向任務(wù)的領(lǐng)域中運行的混合主動(dòng)系統的快速發(fā)展。系統開(kāi)發(fā)人員可以專(zhuān)注于描述對話(huà)框任務(wù)控制邏輯，而RavenClaw對話(huà)框引擎則透明地支持和執行大量與領(lǐng)域無(wú)關(guān)的會(huì )話(huà)技能，如錯誤處理、計時(shí)和輪流。

RavenClaw對話(huà)框管理框架

RavenClaw是一個(gè)兩層對話(huà)管理框架，它在對話(huà)控制邏輯的領(lǐng)域相關(guān)和領(lǐng)域獨立方面之間實(shí)現了清晰的分離-參見(jiàn)圖2。特定于域的方面由dialog任務(wù)規范（dialog task specification）捕獲，dialog任務(wù)規范本質(zhì)上是系統作者提供的交互層次計劃?？芍赜玫?、獨立于域的對話(huà)引擎通過(guò)執行給定的對話(huà)任務(wù)規范來(lái)管理對話(huà)。在此過(guò)程中，對話(huà)引擎還提供了一組與域無(wú)關(guān)的基本會(huì )話(huà)策略，如錯誤處理、計時(shí)和輪流行為，以及各種其他通用對話(huà)機制，如幫助、重復、取消、暫停/恢復、退出、重新啟動(dòng)等。

The dialog task specification

dialog任務(wù)規范描述了交互的分層計劃。更具體地說(shuō)，對話(huà)任務(wù)規范由對話(huà)代理樹(shù)組成，每個(gè)代理負責處理交互的一個(gè)子部分。例如，圖3描繪了RoomLine的對話(huà)任務(wù)規范的頂部，RoomLine是一個(gè)語(yǔ)音對話(huà)系統，可以幫助用戶(hù)預訂會(huì )議室（關(guān)于該系統的更多細節將在后面的第5.2節中介紹）。根節點(diǎn)包含幾個(gè)子節點(diǎn)：Login（標識用戶(hù)到系統）、GetQuery（從用戶(hù)獲取時(shí)間和房間限制）、GetResults（對后端執行查詢(xún)）和DiscussResults（顯示獲得的結果并處理即將進(jìn)行的選擇會(huì )議室的協(xié)商）最符合用戶(hù)需求。在樹(shù)的更深一層，登錄代理分解為Welcome，它提供一個(gè)簡(jiǎn)短的歡迎提示AskRegistered和AskName，用于向系統標識用戶(hù)，最后是GreetUser，用于向用戶(hù)發(fā)送問(wèn)候。

對話(huà)框任務(wù)規范中的對話(huà)框代理分為兩類(lèi)：基本對話(huà)框代理（如圖3所示為灰色）和對話(huà)框代理（如圖3所示為透明）?；緦υ?huà)代理位于樹(shù)中的終端位置（例如Welcome、AskRegistered）并實(shí)現原子對話(huà)操作或對話(huà)移動(dòng)。有四種基本對話(huà)代理：通知-生成輸出（例如，歡迎）、請求-請求用戶(hù)信息（例如，AskRegistered）、期望-期望用戶(hù)信息，但不顯式請求（例如，Projector）和執行-執行特定于域的操作，例如數據庫訪(fǎng)問(wèn)（例如。Projector）。對話(huà)框代理占據樹(shù)中的非終端位置（如Login、GetQuery）；它們的目的是控制其包含的代理的執行，并封裝對話(huà)框任務(wù)的更高層次的時(shí)間和邏輯結構。

個(gè)對話(huà)代理實(shí)現一個(gè)執行單元，該例程在運行時(shí)由對話(huà)引擎調用。執行單元特定于代理類(lèi)型。例如，通知代理在執行時(shí)生成輸出，而請求代理在生成請求的同時(shí)還收集用戶(hù)的響應。對于對話(huà)代理，執行單元負責規劃其子代理的執行。除了執行單元之外，每個(gè)對話(huà)代理還可以定義前提條件、觸發(fā)器以及成功和失敗條件。在計劃樹(shù)中各種代理的執行時(shí)，對話(huà)引擎和父對話(huà)代理會(huì )考慮這些問(wèn)題。

如果對話(huà)代理是RavenClaw對話(huà)管理框架中的基本執行單元，則系統在整個(gè)對話(huà)過(guò)程中處理的數據將封裝在concepts中。concepts可以與對話(huà)框任務(wù)樹(shù)中的各種代理相關(guān)聯(lián)，例如圖3中注冊的和用戶(hù)名，并且可以被樹(shù)中的任何代理訪(fǎng)問(wèn)和操作。RavenClaw對話(huà)框管理框架中預定義了幾個(gè)基本concepts類(lèi)型:Boolean、string、integer和float。此外，該框架還支持開(kāi)發(fā)人員定義的更復雜的concepts類(lèi)型，如（嵌套）結構和數組。在內部，每個(gè)concepts的“值”由一組值/置信對表示，例如city_name={Boston/0.35；Austin/0.27}。因此，對話(huà)引擎可以跟蹤每個(gè)concepts的多個(gè)替代假設，并可以捕獲每個(gè)假設中的不確定性水平（Bohus and Rudnicky，2005a；Bohus and Rudnicky，2006）。此外，每個(gè)concepts還保留以前值的歷史記錄，以及有關(guān)接地狀態(tài)、concepts上次更新時(shí)間等的信息。

The RavenClaw dialog engine

現在，我們將注意力轉向RavenClaw對話(huà)框引擎用于執行給定對話(huà)框任務(wù)規范的算法。對話(huà)引擎算法集中在兩個(gè)數據結構上：一個(gè)對話(huà)堆棧，它在運行時(shí)捕獲話(huà)語(yǔ)結構；另一個(gè)期望議程，它捕獲系統在任何給定回合中期望從用戶(hù)那里聽(tīng)到的內容。該對話(huà)框由交錯執行階段和輸入階段控制——見(jiàn)圖5。在執行階段，任務(wù)樹(shù)中的對話(huà)代理放置在對話(huà)堆棧上并從中執行，從而在進(jìn)程中生成系統行為。在輸入階段，系統使用期望議程將當前用戶(hù)輸入的信息傳輸到對話(huà)框任務(wù)樹(shù)。下面，我們將更詳細地描述這兩個(gè)階段。

The execution phase

首先，對話(huà)框引擎調用對話(huà)框堆棧頂部代理的執行單元。執行單元的效果因代理類(lèi)型而異。例如，通知代理輸出一個(gè)系統提示；請求代理輸出一個(gè)系統請求，然后請求一個(gè)輸入階段；對話(huà)框代理將其子代理推送到對話(huà)框堆棧上。執行單元完成后，控件將返回到對話(huà)框引擎。如果未請求輸入階段（某些代理可以在完成執行單元時(shí)發(fā)出此請求），則對話(huà)框引擎將測試對話(huà)框堆棧上所有代理的完成條件。所有已完成的代理都將從對話(huà)框堆棧中刪除。接下來(lái)，對話(huà)框引擎調用錯誤處理決策過(guò)程。在這一步中，錯誤處理決策過(guò)程（我們將在第4.3節中更詳細地描述）收集有關(guān)對話(huà)框進(jìn)行得如何的證據，并決定是否觸發(fā)錯誤處理操作。如果需要錯誤恢復操作，錯誤處理決策過(guò)程將動(dòng)態(tài)創(chuàng )建錯誤處理代理并將其推送到對話(huà)框堆棧上（例如，顯式確認等）。最后，在執行階段的最后階段，對話(huà)框引擎檢查對話(huà)框任務(wù)樹(shù)中所有代理的焦點(diǎn)聲明（觸發(fā)器）條件。如果任務(wù)樹(shù)中的任何代理請求集中，它們將被推送到對話(huà)框堆棧的頂部。

為了清楚起見(jiàn)，我們將通過(guò)圖6中的RoomLine對話(huà)框任務(wù)的執行呈現逐步跟蹤。相應的對話(huà)框任務(wù)樹(shù)也顯示在同一圖中。在啟動(dòng)時(shí)，對話(huà)框引擎將根代理RoomLine放在對話(huà)框堆棧上。接下來(lái)，對話(huà)框引擎進(jìn)入執行階段。首先，引擎調用堆棧頂部代理的Execute例程–RoomLine。這是一個(gè)對話(huà)代理，它基于其執行策略和子代理的先決條件，決定它需要首先使用登錄代理。因此，它會(huì )將登錄推送到對話(huà)框堆棧上—參見(jiàn)圖6，步驟2，并將控件返回到對話(huà)框引擎。接下來(lái)，對話(huà)框引擎從對話(huà)框堆棧中彈出所有已完成的代理。由于RoomLine和登錄都尚未完成，對話(huà)框引擎通過(guò)調用錯誤處理決策過(guò)程繼續。在這種情況下不采取錯誤處理操作。2接下來(lái)，對話(huà)框引擎檢查焦點(diǎn)聲明，但此時(shí)不存在焦點(diǎn)聲明。因此，對話(huà)引擎將進(jìn)入一個(gè)新的執行階段。這一次，Login位于堆棧的頂部，因此對話(huà)框引擎調用Login.Execute。Login將Welcome代理推送到對話(huà)框堆棧上，并將控件返回到對話(huà)框引擎-參見(jiàn)圖6，步驟3。同樣，沒(méi)有完成任何代理，沒(méi)有采取任何接地措施，也沒(méi)有焦點(diǎn)聲明。接下來(lái)，對話(huà)框引擎執行Welcome。這是一個(gè)通知代理，它將向用戶(hù)發(fā)送歡迎消息。系統說(shuō)：“歡迎使用RoomLine，會(huì )議室預訂助理”。接下來(lái)，當對話(huà)框引擎檢查完成條件時(shí)，它將發(fā)現Welcome已完成（在代理輸出提示后立即通知complete），因此它將從執行堆棧中彈出Welcome–見(jiàn)圖6，步驟4。在下一個(gè)執行階段，再次調用Login.Execute。這一次，由于歡迎代理已經(jīng)完成，登錄代理將通過(guò)在對話(huà)框堆棧上推送AskRegistered代理來(lái)計劃執行它-參見(jiàn)圖6，步驟5。同樣，堆棧上的代理都沒(méi)有完成，沒(méi)有采取任何接地操作，也沒(méi)有提出焦點(diǎn)聲明。當對話(huà)引擎下一步執行AskRegistered時(shí)，此代理將輸出一個(gè)請求–“您是注冊用戶(hù)嗎？”？，然后通過(guò)向對話(huà)框引擎傳遞特定的返回代碼來(lái)調用輸入階段。下一小節將討論輸入階段。

The input phase

在第一階段，系統將期望議程（expectation agenda）組裝起來(lái)，這是一個(gè)描述系統在當前回合中期望從用戶(hù)那里聽(tīng)到什么的數據結構。議程分為多個(gè)層次。每個(gè)層次對應于對話(huà)堆棧上的一個(gè)代理，因此對應于特定的語(yǔ)篇段。對話(huà)框引擎從頂部元素到底部遍歷堆棧，并在預期議程中構造相應的級別。在上面描述的示例中，在A(yíng)skRegistered代理觸發(fā)一個(gè)輸入階段之后，堆棧立即包含AskRegistered、Login和RoomLine代理–請參見(jiàn)圖6，步驟5。因此，對話(huà)引擎通過(guò)收集AskRegistered代理的期望值來(lái)構建議程的第一級。AskRegistered代理希望聽(tīng)到已注冊concepts的值，其形式為輸入中的[是]或[否]語(yǔ)法槽。議程中的第二層是通過(guò)收集堆棧上下一個(gè)代理（即登錄）的期望來(lái)構建的。當一個(gè)機構宣布其期望值時(shí)，默認情況下，它收集其子代理的所有期望值。在這種情況下，登錄代理希望同時(shí)聽(tīng)到注冊concepts（來(lái)自AskRegistered代理）和用戶(hù)名concepts（來(lái)自AskUserName代理）。最后，期望議程的第三層（在本例中是最后一層）是通過(guò)收集RoomLine代理的所有期望來(lái)構建的。除了注冊和用戶(hù)名concepts外，最后一級還包含對話(huà)框任務(wù)樹(shù)中所有其他代理的期望值。事實(shí)上，期望議程中的層次概括了系統期望聽(tīng)到的內容，從當前的焦點(diǎn)問(wèn)題開(kāi)始，并在越來(lái)越大的話(huà)語(yǔ)片段中移動(dòng)。

組裝好預期議程后，對話(huà)框引擎等待用戶(hù)的輸入；這是輸入階段的第二個(gè)階段。

Expectation agenda and mixed-initiative interaction

我們用一個(gè)在航空旅行計劃領(lǐng)域運行的語(yǔ)音對話(huà)系統的例子來(lái)說(shuō)明焦點(diǎn)轉移機制。示例如圖7所示。在n號轉彎處，系統問(wèn)題是“你會(huì )從舊金山回來(lái)嗎？”？“對應于對話(huà)框任務(wù)樹(shù)中的/FlightLine/Leg1/AskReturn代理。此時(shí)，用戶(hù)不再回答系統問(wèn)題，而是決定詢(xún)問(wèn)有關(guān)在舊金山預訂特定酒店的問(wèn)題。解碼后的輸入與議程最后一級的[hotel name]期望值相匹配，酒店名稱(chēng)concepts也相應更新。一旦這個(gè)輸入階段完成，系統將繼續執行一個(gè)階段。在焦點(diǎn)索賠分析期間，/FlightLine/Hotels代理索賠焦點(diǎn)，因為此代理有一個(gè)觸發(fā)條件，即更新酒店名稱(chēng)concepts。因此，對話(huà)框引擎將此代理放置在對話(huà)框堆棧的頂部-請參見(jiàn)圖7中時(shí)間n+1處的堆棧。當對話(huà)引擎繼續執行時(shí)，對話(huà)將從Hotels dialog agency繼續。一旦hotels子對話(huà)框完成，hotels agency將從執行堆棧中彈出，我們將回到上一個(gè)上下文中的AskReturn問(wèn)題。

系統作者可以控制對話(huà)框管理器允許用戶(hù)在對話(huà)框中的每一點(diǎn)采取的主動(dòng)性，方法是控制議程上的哪些期望是打開(kāi)的，哪些期望是關(guān)閉的（關(guān)閉的期望不受約束）。默認情況下，由請求或預期代理定義的預期僅在會(huì )話(huà)焦點(diǎn)與定義預期的代理位于同一主主題下時(shí)打開(kāi)。例如，如果我們的酒店代理被定義為一個(gè)主主題（使用IS-main-topic指令），那么在圖7的步驟n中，[hotel name]期望將被關(guān)閉，并且酒店名稱(chēng)concepts將不會(huì )被更新。因此，系統作者可以通過(guò)定義樹(shù)中的主要主題來(lái)控制哪些期望是開(kāi)放的，哪些是關(guān)閉的。

可以通過(guò)一組期望范圍操作符實(shí)現更細粒度的控制，這些操作符可用于更改期望的默認激活行為。

• ！運算符；定義期望時(shí)使用此運算符時(shí)（例如！[是]>是），只有當定義期望的代理實(shí)際上處于焦點(diǎn)時(shí)，期望才會(huì )打開(kāi)。
• *運算符；當使用此運算符時(shí)，期望值始終是開(kāi)放的。
• @（<agent_name>；<agent_name>?！┻\算符；僅當對話(huà)的焦點(diǎn)位于指定列表中的某個(gè)代理下時(shí)，期望才打開(kāi)。例如，如果我們希望僅當對話(huà)在旅行的第一段而不是第二段時(shí)才允許hotel-name concepts綁定，那么期望可以定義為@（/FlightInfo/Leg1；/FlightInfo/Hotels）[HotelName]

基于上下文的語(yǔ)義消歧

考慮圖8中的示例，該示例同樣來(lái)自在空中旅行域中操作的虛擬系統。對話(huà)的焦點(diǎn)是AskFrom請求代理，該代理負責獲取行程第一段的出發(fā)城市。此代理聲明了對from_cityconcepts的兩個(gè)期望值：[FromCity]，它捕獲諸如“我想從舊金山離開(kāi)”之類(lèi)的結構，以及[city]捕獲孤立地說(shuō)出的城市名稱(chēng)，例如“San Francisco”。同時(shí)，到達子樹(shù)中的AskTo請求代理還聲明期望值[城市]和[城市]，以便在to_cityconcepts中捕獲到達城市。用戶(hù)用一個(gè)簡(jiǎn)單的城市名稱(chēng)來(lái)回答系統問(wèn)題，這個(gè)名稱(chēng)在語(yǔ)義上被解碼為[城市]。由此產(chǎn)生了一種語(yǔ)義上的歧義：這座城市應該與“從城市”concepts相聯(lián)系，還是與“到城市”concepts相聯(lián)系？在concepts綁定階段，通過(guò)自上而下遍歷議程，可以自動(dòng)解決歧義。在這種情況下，輸入會(huì )更新from_city concepts，因為它出現在議程的更高級別（在本例中是第一級）。

因此，期望議程自動(dòng)實(shí)現了一個(gè)歧義消解啟發(fā)式：如果一個(gè)輸入可用于更新多個(gè)concepts，則始終更新最接近當前上下文的concepts，即議程中較高的concepts，我們認為該concepts模仿了人類(lèi)對話(huà)中使用的啟發(fā)式。

動(dòng)態(tài)特定語(yǔ)言建模

支持動(dòng)態(tài)的、特定于上下文的語(yǔ)言建模。在對話(huà)框中的每個(gè)回合，期望議程都會(huì )在語(yǔ)義級別捕獲系統期望從用戶(hù)那里聽(tīng)到的內容。這些信息可以通過(guò)插入大量較小的、固定的語(yǔ)言模型來(lái)動(dòng)態(tài)地構造特定于上下文的識別語(yǔ)言模型，從而提高識別精度（Xu和Rudnicky，2000）。例如，考慮到圖8中的示例，系統可以通過(guò)插入[是]、[否]、[來(lái)自城市]、[城市]、[城市]等的模型來(lái)創(chuàng )建特定于狀態(tài)的語(yǔ)言模型。

RavenClaw對話(huà)框管理框架中的錯誤處理

體系結構概述

RavenClaw對話(huà)框管理框架中的錯誤處理架構包含兩個(gè)主要組件：（1）一組錯誤恢復策略，和（2）在適當時(shí)間觸發(fā)這些策略的錯誤處理決策過(guò)程-見(jiàn)圖9。

錯誤恢復策略分為兩類(lèi)：（1）從誤解中恢復的策略（例如，顯式和隱式確認）和（2）從不理解中恢復的策略（例如，要求用戶(hù)重復、要求用戶(hù)重新措辭、提供幫助等）。這些策略是使用前面描述的RavenClaw對話(huà)框任務(wù)規范形式主義編寫(xiě)的，它們可用作庫對話(huà)框代理。系統作者只需指定對話(huà)管理器應該使用哪些策略，并相應地配置它們。

處理潛在錯誤的責任委托給錯誤處理決策過(guò)程（sequel中的EHDP），它是RavenClaw對話(huà)框引擎的子組件。在每個(gè)執行階段，EHDP收集可用的證據，并決定應該采用哪種錯誤恢復策略（如果有的話(huà)）。如果認為有必要執行操作，EHDP將創(chuàng )建相應錯誤恢復策略的實(shí)例，相應地對其進(jìn)行參數化，并將其推送到對話(huà)框堆棧上。實(shí)際上，EHDP更改了對話(huà)框任務(wù)，以確保相應地處理潛在的錯誤例如，在圖9所示的示例中，基于置信度得分，對話(huà)框引擎決定觸發(fā)對開(kāi)始時(shí)間concepts的明確確認。因此，引擎實(shí)例化了一個(gè)ExplicitConfirm對話(huà)框代理（它實(shí)現了一個(gè)顯式的確認策略），通過(guò)傳遞一個(gè)指向要確認的concepts的指針（在本例中為start_time）對其進(jìn)行參數化，并將其放在對話(huà)框堆棧上。接下來(lái)，戰略執行。完成后，它將從堆棧中移除，對話(huà)框將從它停止的位置繼續。在顯式確認的執行過(guò)程中，所有其他的對話(huà)框控制機制仍然存在；例如，用戶(hù)可以請求更多的幫助，甚至改變當前的對話(huà)框主題。

錯誤恢復策略

根據所解決的問(wèn)題類(lèi)型，RavenClaw對話(huà)管理框架中的錯誤恢復策略可以分為兩組：（1）處理潛在誤解的策略和（2）處理不理解的策略。目前的一系列策略如表1所示。

參考文獻

The RavenClaw dialog management framework: Architecture and systems