本文最初發佈於Microsoft Research博客，由InfoQ中文站翻譯並分享。
“說起來容易做起來難。”這句話反映了對話式人工智能的前景。問“我和Megan什麼時候都有空”只需幾秒鐘。但手動查看日曆花的時間要長很多。事實上，我們藉助科技完成的每一件事，都讓人感覺是走過了一條通往短期目標的漫長道路。在微軟Semantic Machines公司，我們正在努力填補這一空白——構建對話式人工智能體驗，你只要專注於說出你想要的東西，剩下的交由系統就行了。和這樣的AI對話，應該像和朋友說話一樣：自然地、符合語境地、協作地。
一個真正強大的對話式AI需要做的不僅僅是深刻理解語言，它還要具備情境性、靈活性和健壯性，人工智能還必須深刻理解動作——大多數目標都涉及多個步驟和多個信息源。表達目標、動作和對話狀態是對話式AI系統的核心挑戰之一。我們在《計算語言學協會會刊》（TACL）上新發表了一篇論文，題爲“面向任務的對話即數據流合成”（Task-Oriented Dialogue as Dataflow Synthesis），描述了一種新的表示和建模框架，它將對話解釋爲數據流圖，使跨多個領域的複雜任務的對話成爲可能。我們還發布了一個包含超過40000個對話的數據集（標註了數據流圖）和公共排行榜，可以幫助人工智能社區在多輪任務導向對話中解決具有挑戰性和現實意義的問題。
從我們的新數據集中可以看出用戶請求令人難以置信的多樣性：
-
目標多樣性。用戶可能想要“與Megan預約會議”。他們也可能想”與Megan預約一個週二的會議”，甚或是“與Megan預約在勞動節後第一個她有空的早上開一個會”。
-
語言多樣性。問題可能會是“明天天氣怎麼樣？”同樣的問題也可能會以“明天外面怎麼樣？”或“遠足時我需要帶一件夾克嗎？”這樣的形式出現。
-
語境多樣性。“How about three?”這句話的意思完全取決於剛剛說了什麼。句子“Megan兩點沒空，你有其他建議嗎？”是提議更改會議時間。句子“天氣預報說中午多雲”是對於天氣有疑問。句子“Rivoli有一張兩人桌”是要求增加晚餐預訂的座位。
傳統的“填槽式（slotfilling）”對話系統忽略了這種多樣性。它們只支持一組目標，除了當前目標中缺失參數的列表之外，它們沒有上下文表示。而在另一個極端，最新的“端到端”神經對話系統原則上可以自由地學會任意上下文相關的響應，但僅僅是靈活地使用詞彙是不夠的，因爲對話還需要靈活地執行動作。部署的系統還需要有可控性和真實性，在非結構化系統中，這非常具有挑戰性。
我們提供了第三種方法，使用深度學習來生成和消費強大的“數據流”表示，它超越了填槽式方法，提供了靈活的動作和可控的語義。數據流旨在支持人類在日常生活中自然、靈活、開放的對話。我們的方法基於以下五個關鍵理念。
1. 用戶請求即程序
現有的對話方式非常適合解釋固定的、預先定義好的任務請求，比如“開燈”或“”設置一個名爲pasta的定時器，時長5分鐘”。在這些方法中，對話系統設計者定義了一組固定的意圖，每個意圖都有一組固定的參數。系統用用戶所表達的意圖和該意圖的參數來標記每個用戶請求：
但是，對於更復雜的請求，比如“我和Megan一起喝咖啡的時候氣溫會是多少？”回答這個問題需要對話代理做一系列不同的事情：找出Megan是誰，在日曆應用程序中使用Megan查找事件，找出開始時間，然後使用時間查詢天氣服務。我們不需要系統構建者創建專門的weather_during_event_with_person意圖，而是將自然語言請求轉換爲一個程序，將所有這些調用聯繫在一起。我們將該程序表示爲一個數據流圖，它明確定義了對話代理計劃中的步驟（節點）之間的數據依賴關係（邊）：
一旦神經網絡預測到這個程序，對話代理就會執行它，根據結果對用戶進行回覆，並將結果存儲在數據流圖中。
2. 面向任務的對話是交互式編程
使用數據流表示用戶意圖的一個好處是，它可以非常自然地概括爲在多次來回通信中展開的交互。如果用戶開始的時候問“我下一次什麼時候和Megan見面？”，則對話代理首先預測一個小的圖片段：
如果用戶在接下來的一輪對話中繼續問“那時的天氣怎麼樣？”，回答這個新問題所需的大部分工作已經完成了。對話代理返回到上一輪的程序片段，將其輸出輸入到新的API調用中，然後描述結果：
這個過程的結果與我們之前爲一個複雜問題生成的程序完全相同！這種重用是我們這個框架的核心特性——複雜動作是通過組合更簡單的動作來構建的，而不是定義一堆頂級行爲。這種組合可以一次完成，也可以在多次循環中通過依次擴展數據流圖逐步完成。
3. 語義依賴語境
擴展後的圖作爲對話狀態。它記錄到目前爲止代理爲理解、服務和響應用戶所執行的所有計算。隨後的表達都是在這個上下文中被解釋（通過深度學習），它們可以引用這些早先的計算和結果。正如我們在論文中所展示的，顯式引用和重用早先計算的機制提高了對話代理機器學習的數據效率和準確性。它們還使工程師更容易推理和控制對話代理的行爲。
在前面的示例中，用戶使用單詞then引用數據流圖中較早的節點。其他指稱表達，如that、her或the second meeting you mentioned，也可以表示重用對話中之前提到的值或實體的請求。
這種引用也可以隱式地發生。想象一下，問你的設備“天氣怎麼樣？”，通常你指的是近期的天氣。但如果你在提及未來的一項活動後問同樣的問題，你很可能是在詢問活動期間活動地點的天氣。最終，這兩種情況需要兩種不同的計算方法。如下所示，左邊的計算將用於解釋近期的情況，右邊的計算用於解釋特定於事件的情況：
弄清楚如何區分這些用法（更不用說對這個問題的其他解釋）是一個具有挑戰性的機器學習問題。但憑直覺，在這兩種情況下，“天氣怎麼樣？”的意思是相同的——用戶想知道與會話上下文最相關的時間和地點的天氣。
在我們的方法中，這種推理是顯式的：當在上下文中解釋用戶輸入時，我們的對話代理就顯式地預測了引用現有計算片段的程序，包括從對話開始就隱式可用的片段，比如here和now。對於上面的兩個例子，會是下面這個樣子：
換句話說，在這兩段對話中，對話代理用同樣的方式解釋“天氣怎麼樣？”這個問題。它預測出了相同的數據流圖片段，調用refer(Time)和refer(Place)，但是，對這個片段的解釋會根據前面的上下文發生變化。
“公司休假期間怎麼樣？”這個問題與上下文的關係更緊密。這裏，用戶不只是引用一個現有的實體，而是要求對話代理爲之前的問題計算出一個新的答案，其中一些細節已經變了。我們稱這種轉變爲修正（revision）。與引用一樣，修正提供了一種強大的機制，用於執行復雜的圖轉換，以響應簡單的請求。下面這個示意圖說明了代理預測的修正，當用戶問完“我和Megan喝咖啡時天氣怎麼樣？”之後又問“公司休假期間怎麼樣？”
在這裏，第一次事件搜索的條件（包含Megan的名爲coffee的事件）被替換爲新的條件（指定名爲company retreat的事件）。
查看論文了解更多細節：https://www.microsoft.com/en-us/research/publication/task-oriented-dialogue-as-dataflow-synthesis/。
4. 事情會出錯
在任何複雜的對話中，事情的發生都有許多意想不到的方式。與Megan預約會議的請求可能會失敗，因爲用戶的聯繫人列表中沒有叫Megan的人；因爲有許多人都叫Megan；因爲沒有空開會；甚或因爲網絡已斷開，對話代理無法與服務器取得聯繫。每種情況都需要不同的響應，而現有的對話系統通常使用複雜的硬編碼邏輯來從錯誤中恢復。
我們通過從數據流圖的某個節點拋出異常來處理所有這些故障。我們的對話代理會響應這個失敗的“結果”，爲用戶生成一個適當的警告或問題。用戶可以隨意響應，也許是通過糾正問題；例如，在這個上下文中，“我指的是Megan Bowen”將被解釋爲改進原始請求的修訂。這種方法允許系統和用戶在出現錯誤時根據上下文靈活地、模塊化地、協作地處理錯誤。
5. 語言生成依賴於對話語境
要成爲一名有用的團隊合作伙伴，對話AI系統需要能夠生成語言，而不僅僅是解釋它。大多數現有的對話方法要麼是硬編碼生成規則（導致輸出聽起來像機器人，不會因上下文不同而改變），要麼是非結構化的神經語言模型（有時不說實話！）在我們的方法中，語言生成被建模爲一個神經引導的合成程序轉換過程，在這個過程中，代理會輪流擴展數據流圖。代理可以討論圖表中出現的任何內容，而不僅僅是它計算得出的最後結果。它甚至可以向圖中添加新的計算和結果，用戶可以在以後的對話中隨意引用：
代碼、數據和新一輪競爭
我們相信，這種方法是邁向新一代自動對話代理的第一步，它可以像人與人之間那樣與人交互。然而，解決這個問題需要整個社會的共同努力。爲了促進基於數據流的對話代理的開放研究，我們發佈了迄今爲止最大、最複雜的面向任務的對話數據集SMCalFlow。該數據集具有41517個標註了數據流程序的對話。這個數據集來自於人類之間探討日曆、天氣、人和地點的開放式對話。與現有的對話數據集相比，我們收集對話不是基於預先指定的腳本，參與者不受限制，他們什麼都可以問，他們可以按自己的方式完成他們的任務。因此，SMCalFlow與現有的對話數據集有本質上的不同，它有關於代理能力、多輪錯誤恢復和複雜目標的具體論述。
數據集、代碼和排行榜都可以在我們的GitHub頁面上找到。我們期待看到自然語言處理社區如何使用這個新資源。
查看英文原文：