序言

Dialogflow

云小蜜

DuerOS

負責管理輸入輸出語境（input/output context）的上下文（Contexts）模塊是國內外主流 Bot Framework 中的一個常見設計，但彼此之間功能卻并不完全相同。這篇文章將嘗試分析這種設計被用來解決什么問題，以及解決這類問題的最佳實踐是什么，并對一些有爭議的問題給出自己的解。

實例

本文的講解兩個實際的 Case 開始。

先看第一個，這是阿里小蜜中的一個場景，有興趣的可以直接在淘寶內的阿里小蜜中輸入『教我挑蛋黃酥』來親自體驗一下。這張動態圖是我在 Dialogflow 中進行配置后所得到效果。

圖中包含如下細節：

• 輸入『教我挑蛋黃酥』展示內容為『蛋黃酥的基本資料』。
• 隨后以任意順序輸入任意多次『找帖子』『看清單』『挑商品』，都能夠正確的展示相應答案，且在展示之后，似乎又回到了輸入之前的狀態，能夠重新接受輸入（『找帖子』『看清單』『挑商品』）。
• 緊跟在『找帖子』『看清單』『挑商品』之后的『再看一批』，能夠在用戶問句完全相同的情況下正確的識別用戶所說更換的目標對象。且能在保持對話狀態不變的情況下，進行任意多次更換。

接下來是第二個，這是個經典的訂火車票預定場景。這個場景阿里小蜜同樣支持，不過截至目前，它在這個場景下還存在著不少問題，比如：

• 在澄清出發日期時，按照推薦輸入『換目的地』時會跳出當前話題
• 無法在澄清出發日期時更換出發地
• 信息填充完整后出現推薦語句『相應的飛機票』，點擊按鈕能夠正常識別，但是輸入問句并點擊發送后并不能得到預期結果。

我所給出的圖中包含如下細節：

• 當缺失『出發地』和『出發日期』時，能夠正常進行追問。
• 信息填充完整后，能夠通過『從杭州去天津』隱式的修改已填充的槽位內容。
• 信息填充完整后，能夠自由的通過『換出發地』『換目的地』清空部分已填充槽位的內容，重新填充。
• 信息填充完整后，能夠通過『相應的飛機票』切換到新的意圖，并繼承已經填寫過的槽位內容。

這里仍然存在一個缺陷，就是只有當『信息填充完整后』，才能夠進行相應的澄清、清空和意圖切換，這點下文中會進行進一步說明。

相關概念

由于 Dialogflow 是我分析過的所有競品之中設計最為完善的，所以對相關基礎概念的講解也用其作為例子。如下圖所示：

Dialogflow-Intent

User says 負責定義這個 Intent 所支持的 utterance，也即什么樣的用戶說法將會被識別到這個 Intent。同時，開發者可以對其進行標注，使其能夠正確的識別出用戶話中的關鍵信息以用于填槽。

Events 提供了一種獨立于 User says 之外的進入當前 Intent 的途徑，舉個例子，比如用戶剛進入對話頁時，服務器會發送一個 Welcome Event，觸發 Welcome Intent，在用戶說話之前，主動發起與用戶的對話。

Action 定義了這個 Intent 中需要被填寫的槽位信息，REQUIRED 指該槽位是否必填，PARAMETER NAME 指該槽位的名稱，ENTITY 指該槽位所對應的詞典/實體，IS LIST 指該槽位是否多值，PROMPTS 指該槽位的澄清話術/追問語句。

Response 用于定義該 Intent 的返回給用戶的答案。

Contexts

著重講一下 Contexts，Context 有 input context 和 output context 之分。

input context 指，當前 Intent 只有在與用戶對話的 Contexts 中包含所配置的 input context 時才能被觸發。一個 Intent 可以配置多個 input context，不同 input context 之間為且關系，也即 Contexts 必須包含一個 Intent 中配置的全部 input context，該 Intent 才能被觸發。

output context 可以被定義 lifespan，如前圖中的『5』，也即該 output context 所能夠存在的對話輪數。在一個 Intent 的 output context 的存續期內，可以通過特定的文法引用該 Intent 中已填寫的槽位值。

總而言之，Contexts 的意義有兩個：

• 作為信號，影響 Intent 的識別
• 作為載體，存儲已填寫的 Parameter Value

第一個 Case 的參考解

這個 Case 主要講解 Contexts 的第一個意義：作為信號，影響 Intent 的識別。

如前文所示，圖中所包含的細節如下：

• 輸入『教我挑蛋黃酥』展示內容為『蛋黃酥的基本資料』。
• 隨后以任意順序輸入任意多次『找帖子』『看清單』『挑商品』，都能夠正確的展示相應答案，且在展示之后，似乎又回到了輸入之前的狀態，能夠重新接受輸入（『找帖子』『看清單』『挑商品』）。
• 緊跟在『找帖子』『看清單』『挑商品』之后的『再看一批』，能夠在用戶問句完全相同的情況下正確的識別用戶所說更換的目標對象。且能在保持對話狀態不變的情況下，進行任意多次更換。

參考解如上圖。

首先，『教我挑蛋黃酥』作為一個 Intent & utterance 存在，進入該 Intent 后，給出『這是蛋黃酥的基本資料』作為 Response/Answer。

隨后，該 Intent 給出 output context A，其 lifespan 為5輪對話。『找帖子』『看清單』『挑商品』分別作為三個 Intent 存在，其共同特點為 input context 為 A，也即只有在 context A 存續期間，這三個 Intent 才能夠被觸發。

并且，『找帖子』『看清單』『挑商品』這三個 Intent，都需要給出一個 output context A，也即重置 context A 的存續時間。否則，一旦對話輪數超過 5，context A 就會失效，以其作為 input context 的 Intent 也無法再被觸發。

接下來是『再看一批』的解法，我的做法只是解法之一。我新增加了三個 Intent，它們的 utterance 均為『再看一批』，區別在于，第一個 Intent 的 input context 為 A 和 B，第二個為 A 和 C，第三個為 A 和 D。分別用于承接更換帖子、清單、商品的用戶意圖。

這里有一點需要注意，就是 context B C D 的 lifespan 只能是1，因為一旦超過1，就無法穩定的觸發到正確的『再看一批』Intent。舉個例子，如果 context B 的 lifespan 為2，用戶先說『找帖子』，隨后說『看清單』，在這個時候，Contexts 中會同時包含 context A B C，就會同時滿足 input context 為 A B 和 A C 的兩個不同的『再看一批』Intent 的觸發條件。

在這種解法下，如果需要額外實現承接更換基本資料的『再看一批』Intent，就需要在『教我挑蛋黃酥』Intent 的 output context 中額外輸出一個 context E，然后新增一個 input context 為 A 和 E 的『再看一批』Intent。

第二個 Case 的參考解

這個 Case 主要講解 Contexts 的第二個意義：作為載體，存儲已填寫的 Parameter Value

如前文所示，圖中所包含的細節如下：

• 當缺失『出發地』和『出發日期』時，能夠正常進行追問。
• 信息填充完整后，能夠通過『從杭州去天津』隱式的修改已填充的槽位內容。
• 信息填充完整后，能夠自由的通過『換出發地』『換目的地』清空部分已填充槽位的內容，重新填充。
• 信息填充完整后，能夠通過『相應的飛機票』切換到新的意圖，并繼承已經填寫過的槽位內容。

參考解如上圖。

首先，我將『訂車票』作為一個單獨的 Intent，它包含有三個 Parameter，分別是 formCity、toCity、date。用于承接『我要訂火車票』『我要從北京出發去上海』『我要明天去濟南』這類 utterance。該 Intent 輸出一個 output context A，用于記錄已填寫好的 fromCity、toCity、date。

同時，配置另外一個 Intent 專門用于承接用戶隱式的修改已填充槽位信息的意圖，如『改成下周二出發吧』『算了，還是從杭州出發吧』『先去南京一趟』。它需要 context A 作為 input context，因為在沒有 Contexts 的情況下，單獨說『改成下周二出發吧』是沒有意義的。該意圖引用 context A 中存儲的 fromCity、toCity、date 作為當前意圖對應 Parameter 的默認值，這樣即可實現使用用戶話中的信息優先進行已填槽位信息的改寫，而對于那些用戶澄清話語中不包含的 Parameter，則會仍然采用原意圖中繼承下來的內容。另外，為了支持后續的澄清，該意圖需要重置 context A 的 lifespan。

在這個參考解中，『換出發地』與『換目的地』需要被配置成兩個獨立的 Intent，配置上，分別需要對 fromCity 和 toCity 中的已填信息進行清空，隨后，由于 fromCity、toCity 均為必填槽，該意圖便會向用戶就相應槽位進行追問，從實現重新填充已填槽位的目的。

『相應的飛機票』作為另一個獨立的 Intent 而存在，它會繼承 context A 中所記錄的 fromCity、toCity、date。

一些更深層次的問題

前文主要是對 input/output context 意義的簡單介紹，并給出了針對文章開始的兩個 Case 的可行解。但這些遠不是解的全貌，接下來，我將會嘗試對于一些國內外 bot framework 設計中的爭議點，給出我的解。

1.多個 input context 之間，究竟應該是或關系，還是且關系？
Dialogflow 中的 input context 和云小蜜中的前置意圖均選擇了且關系；而 DuerOS 中的輸入語境選擇了或關系。

我先給出我的解：且關系優于或關系。通過或關系組織的輸入語境，無法構建兩層以上的依賴結構。

什么叫做兩層以上的依賴結構？

先說什么叫做依賴：如果一個對話狀態下，不同的輸入會導致后續對話路徑的不同，則說后續對話狀態依賴于當前對話狀態下的輸入。舉個例子，去銀行辦理業務，大堂經理可能會問你是不是 VIP，即便是辦理同樣的業務，VIP 和非 VIP 所走的流程也并不相同，也即后續的流程依賴于是否是 VIP 這個輸入。

而且，依賴也絕不僅僅只會存在一層，比如一些劇情游戲中，都存在多層依賴關系。極端情況下，你每一個選擇的不同都會導致最后得到不同的結局，狀態轉移圖可以看作是一棵滿多叉樹。

如果輸入語境間是或關系，就沒辦法描述『第一層選擇D，第二層選擇A，第三層選擇B，第四層選擇D... 最后一層選擇C』這類情況，也就沒能力為這種情況定義一個獨立的 Response。

2.為什么 bot framework 的 Intent 之間不能設計為完全依賴的樹結構？
前文中提到，部分對話狀態之前存在著依賴關系，而處理依賴關系，我們最先想到的就是使用樹結構。但是樹結構描述且只能描述完全依賴關系，一旦分支，就無法實現 Response 的共用。但是實際業務中，除了完全平級關系與完全依賴關系之外，還大量存在著非完全依賴關系。

如上圖所示，根 Intent （第零層）狀態下的不同輸入（A 或 B），會觸發第一層不同的 follow-up Intent，給出不同的 Response。也即第一層的兩個 follow-up Intent 依賴于根 Intent。而同時，第二層對第一層，第三層對第二層，甚至我沒有畫出來的第四層、第五層、第 N 層，分別對第三層、第四層、第 N-1 層，也存在相同的依賴關系。

注意，第 N 層只依賴于第 N-1 層，而不是同時依賴 N-1 層、N-2 層、N-3層 ... 一直到第零層的根 Intent，也即非完全依賴關系。不過如果我們先假設其是完全依賴關系，那么圖中第三層的八個 Intent 就會各自擁有不同的 Response，但是實際上，由于第三層只依賴于第二層，而又由于第二層可能的輸入又只有兩種（A 或 B），所以第三層實際上只應該存在兩個擁有不同的 Response 的 Intent，也即圖中 Response 分別為 a2 b2 的兩個 Intent，而不是八個（2的3次方）。隨著層數的增加，冗余的增加是指數級的。

當下主流 bot framework 的 Contexts 設計，使得每個 Intent 分別定義自己的 input context，實際上解決了這類冗余問題。在這樣的設計下，第三層的節點只需要配置一個指代第二層的 context 作為 input context 即可，同理，第二層的節點以指代第一層的 context 作為 input context，同時給出一個指代第二層的 context 作為 output context。最終，第一層、第二層、第三層都只會存在兩個 Intent（數量取決于業務中引發依賴關系的不同輸入的個數），每層的 Intent 個數也不必是2的 N 次方。最終形成一個沒有冗余的合理結構，如下圖所示：

3.『再看一批』的最優解是什么？

回顧上文中第一個 Case 的解，我為『找帖子』『看清單』『挑商品』，分別配置了一個『再看一批』的 Intent，如果我還需要對基本資料進行更換，那我還需要新增一個 context E（為了和 B C D 區分開），然后額外配置一個『再看一批』的意圖，專門用于更換基本資料。

但是這是最優解嗎？『再看一批』問題的核心在于，明確需要更換的到底是什么內容。為了解決這個問題，就一定要有一個信號，用于對不同的內容進行標識和區分。如果把這個問題放在對話系統中來解決，那利用 context 作為信號，然后以此來區分內容，確實是可行的，但是這種做法很差，每一類可以更換的內容，都需要占有一個 Intent。

其實還有另一種解法。不同內容所對應的『再看一批』都統一的使用同一個 Intent 來處理，共享語料，而區分不同內容的信號取決于當前正在展示的內容是什么，也即默認『再看一批』都是對最近展示的可更換內容的更換。

4.lifespan 在設計中的意義是什么？
lifespan 描述了 context 的存續時間， 能夠支持用戶在誤跳出當前 Intent 或臨時執行別的任務后，在一定的輪數內，仍然能夠回到原 Intent 中，繼續進行槽位的填寫。

DuerOS 中實際上無法對語境的 lifespan 進行設置，也即 context 只能保持一回合，前序 Intent 填過的槽位內容，在一輪對話之后就會被忘記。

Dialogflow 中，可以自由的定義每個 context 的存續時間。只要 Contexts 中包含某個 context，以該 context 作為 input context 的 Intent 就能被正常觸發，而且能夠通過『#context.parameter』的方式引用存儲在 context 中的前序 Intent 已填槽位信息。

云小蜜無法對每個 Intent 的 output context 進行自定義，每個 Intent 默認會產生唯一一個屬于當前 Intent 的 ouput context，且它的 lifespan 分為兩種，分別為生存周期（默認為5）和殘留周期（默認為2），也即如果該 Intent 的所有 Parameter 全部被填寫完整，其 output context 只擁有2輪對話的存續周期，否則擁有5輪，設計思想上也很好理解，生存周期的價值在于提供繼續填槽的可能性，而殘留周期的價值在于澄清，其重要性和價值也有所不同。

5.DuerOS 的輸入輸出語境設計中是否出現了耦合，云小蜜呢？
前文中提到，Contexts 的意義有兩個：

• 作為信號，影響 Intent 的識別
• 作為載體，存儲已填寫的 Parameter Value

DuerOS 中存在這樣一個設計，也即一個 Intent 只能使用它 input context 中存儲的前序 Intent 的已填槽位信息。通常情況下沒有什么問題，如果想要使用前序 Intent 的 output context 中的內容，follow-up Intent 必須跟在原 Intent 之后，這時，為 follow-up Intent 增加配置一個 input context 似乎并沒有什么問題，權且當做是對即將使用變量的聲明了。

但是問題在哪呢？作為信號和作為載體，是 Contexts 所擁有的兩個不同的意義，是不應該被耦合起來的。也即作為信號和作為載體這兩個意義并不都是同時起作用的。一個 Intent 完全可以只嘗試使用前序 Intent 中填寫的槽位信息，而根本不必將其配置為 input context 作為信號來影響自身的識別。

舉個例子，存在這樣兩個 Intent，一個叫做 Welcome Intent，一個叫做 Fallback Intent。Welcome Intent 當用戶初次進入對話頁時會觸發，期間會詢問用戶的昵稱，而 Fallback Intent 當用戶問句無法識別時會被觸發，Response 中會嘗試使用用戶的昵稱，給出『抱歉，[用戶昵稱]，我沒能理解您的意思』的回答。在這種情況下，Fallback Intent 其實只需要 Welcome Intent 中記錄的用戶昵稱而已，而根本不需要將包含用戶昵稱的這個 context 配置為 input context。Fallback Intent 中存在多條可用的 Response，并不是說沒有用戶昵稱就無法觸發了，也同樣不至于要把使用和不使用用戶昵稱的 Fallback Intent 作為兩個 Intent 來分別配置處理。

再說云小蜜，云小蜜中一個 Intent 只能通過默認的方式給出一個 output context，通常情況下也沒有問題，但是也會有些無法處理的情況。比如，作為載體的 context，其存續時間需要比作為信號的 context 更久。或者，一個 Intent 需要同時向外輸出多種信號，分別從不同的高度上刻畫當前的對話狀態。這些情況下，都需要多個承擔不同任務的 context 同時存在。

6.用戶澄清的多輪對話，究竟是在解決什么問題？
我個人將多輪對話從觸發和澄清兩個角度進行劃分，從觸發角度可被分為『用戶觸發』和『系統觸發』的多輪對話，而從澄清角度可被分為『用戶澄清』和『系統澄清』，我們通常最常見的機器人，解決的都是『用戶觸發』『系統澄清』的多輪對話，而『系統觸發』和『用戶澄清』是兩個重要的突破現有桎梏的方向。

我簡單將用戶澄清的多輪對話所解決的問題分為三種：

• 隱式的修改部分已填槽位的內容
• 顯式的清空部分已填槽位的內容
• 在繼承已填槽位內容的基礎上，切換到新場景

舉個例子，訂火車票這樣的場景，用戶講『改成下周二出發吧』『算了，還是從杭州出發吧』『先去南京一趟』屬于第一種；用戶講『換出發地』『換目的地』甚至『更換出發地與出發時間』屬于第二種；用戶講『相應的飛機票』『改成坐汽車』屬于第三種。

7.只有當一個 Intent 的 Parameter 填充完整之后，才能給出 output context 嗎？
這也是前文中提到過的一個問題，Dialogflow 和云小蜜中都存在類似的邏輯。Dialogflow 中，在前序 Intent 的Parameter 未填寫完整的情況下，嘗試觸發以前序 Intent 的 output context 為 input context 的 follow-up Intent，是不成功的。云小蜜也是，雖然在保留意圖列表（也即 Contexts）中，能夠看到處于生命周期中的 context，但是仍然無法觸發以其作為前置意圖的 follow-up Intent。

但是業務中的確存在著這樣的場景，比如在訂火車票的意圖之中，用戶還未完全填充所需的 fromCity、toCity、date，但卻直接說了『換成坐飛機』，這種情況下，我們其實應該嘗試切換到新的 Intent，然后將已經填充完成的內容繼承下去，在新的 Intent 里面繼續進行槽位的澄清。

8.隱式修改已填槽位內容的最優解是什么？

在第二個 Case 的解之中，我用一個修正車票信息的 Intent 來承載所有隱式修改已填槽位信息的用戶意圖，這也是 Dialogflow 的解。在這個問題上，云小蜜和 DuerOS 采取的方法可以說是兩個極端。

云小蜜內置了換槽的功能（本質上為每個 Intent 內置了這樣一個隱式修改已填槽位信息的 Intent），也即用戶無需配置這樣一個專門用戶隱式澄清信息的 Intent 就能夠滿足大多數『改成后天出發』這類需求。優點在于節省了配置量，而缺點在于喪失了部分靈活性，增大了誤跳出意圖的風險。

而 DuerOS 采用了全部打散的方式去解。比如查詢天氣這樣的一個 Intent，擁有兩個 Parameter，分別是 city 和 date，相應的，用戶也就存在『那北京呢』或『那后天呢』這類需求，DuerOS 用了兩個 Intent 來解決這兩類問題。但是我們將問題復雜化，如果一個 Intent 包含十個 Parameter 需要填寫，用戶不僅可能會對第 1、2、3、5、9個槽進行澄清，還可能同時澄清第12、567、2568、14567、234789個槽，這樣的情況一共有2的10次方減2種，那難道要配置1022個 Intent 去處理么。

DuerOS 造成這種冗余情況的原因在哪呢？核心問題在于不支持 default value，不支持槽位的默認值，導致了一個槽位只擁有唯一的一種填槽方式，要么從用戶話中抽取，要么就繼承自前序 Intent。這樣的情況下，『那明天呢』對應的 Intent 就需要使 date 之外的 city 繼承前序 Intent，而使 date 本身通過抽取用戶話中的信息來填充。『那北京呢』與此相對，但同理。

而 Dialogflow 通過 default value，能夠使得所有的 Parameter 默認繼承前序 Intent 已填寫的槽位信息，而同時又能根據用戶澄清話語中的信息來改寫繼承下來的默認值，從而只需要一個 Intent，就能夠完成所有情況下已填槽位信息的隱式改寫。

阿里另外的一個 AliGenie 平臺通過配置所謂連續對話語料的方式給出了這個問題的解，兼具了云小蜜不必配置新 Intent 的優勢，而又保留了人工干預 utterance 識別的可能性。如下圖：

9.Dialogflow 對顯式清空部分已填槽位內容問題所給出的解，是最優的嗎？

簡單的說，不是。

既然存在『換目的地』與『換出發地』兩個 Intent，就沒理由不會存在『換出發時間』，甚至會有『換出發地和出發時間』和『換目的地與出發地』等等，仍然存在著指數級的冗余。

我個人有個觀點：所有需要枚舉全部組合數情況的解決方案，其病因都在于抽象程度不夠。

比如 wit.ai 中，它嘗試完全通過編輯對話流的方式來解決 slot-base bot 的問題，也即假如有十個槽位需要填寫，它需要寫出這 1024 種狀態下引導用戶繼續進行填槽的對話流。因為用戶可能有第 1、2、3、5、9個槽未被填充，甚至還可能有第12、567、2568、14567、234789個槽未被填充。這樣的情況一共有 1024 種，比澄清時多一種，因為所有槽位全部都填寫完整的情況也是需要處理的，而澄清的時候并不需要對不能澄清任何一個槽位的用戶問句進行處理。

這里的問題同樣在于抽象程度不夠，從而導致了需要枚舉所有組合數的情況。這個問題我有一個解，能夠把指數級的意圖配置量降到常數級，或者講，只需要一個 Intent，這里就不詳細說了，留給讀者自己思考。

10.場景切換+槽位繼承，本質是什么？

再看一遍這個解，思考這樣一種情況。用戶正常填充完了 fromCity、toCity、date，然后說『相應的飛機票』，沒問題，我們繼承下用戶已經填寫的出發地、目的地和出發時間，幫用戶找到了相應的飛機票，但是如果這個時候，用戶講『換出發地』呢？

根據圖中的解，會發生什么？會回到『換出發地』這個 Intent，有問題嗎？當然有，我在圖中特別標注了，『換出發地』Intent 的 answer 是火車票，而『相應的飛機票』Intent 的 answer 是飛機票。難道用戶意圖切換到『相應的飛機票』后，再講『換出發地』，訂的票便成了火車票了么。

這讓我去反思圖中 context A 的意義。首先 context A 作了 fromCity、toCity、date 的載體，這是毫無疑問的，但是 context 的另外一個意義是作為信號，那作為信號存在的 context A，指代了什么呢？我們發現不論 answer 是飛機票還是火車票，context A 都存在，說明它不是區分具體答案內容的信號。而根據它作為出行信息載體的這個特性，我發現它實際上是作為出行域內的一個信號標志而存在的。而這個所謂出行域的特點，就是共享出發地、目的地和出發時間。

既然 context A 不足以作為區分火車票和飛機票等各種答案場景的信號而存在，那我們就應該額外增加一個信號用于處理這樣的問題。

我們考慮為所有 answer 為車票的 Intent 增加一個與 context A 分布相同的 context T，而為 answer 為飛機票的『相應的飛機票』Intent 增加一個 output context P。這樣在『相應的飛機票』之后接一句『換出發地』，就會由于缺少 context T，從而導致不能進入到 answer 為火車票的『換出發地』Intent 之中，問題也就解決了。

不過繼續思考一個問題，『相應的飛機票』Intent 的 input context 是什么？是 context A？還是 context A 和 T？

這個問題本質上等同于這樣一個問題，只有『訂火車票』Intent 的出發地、目的地、出發時間才能被『相應的飛機票』Intent 繼承嗎？答案顯而易見。汽車票也可以，船票（強行不考慮地理限制的話）也可以。

『相應的飛機票』Intent 的 input context 應當只是 context A，承接所謂出行域內所有 Intent 下用戶修改 answer 到飛機票的意圖。

依照這樣的思路，整個出行域的解是什么呢？如下圖：

每種不同 answer 的用戶意圖占有一個 Intent，同時，與這類 Intent 相對的，會存在三個配套 Intent，分別用于解決前文中提到的三個問題：修改、清空、切換。

也即，每個『訂火車票』擁有一個『修改火車票信息』，用于承接所有修改部分已填槽位信息的用戶意圖；擁有一個『重填火車票信息』，用于承接所有清空部分已填槽位信息的用戶意圖；擁有一個『相應的火車票』，用于承接出行域內所有其它 answer 的 Intent 到 answer 為火車票 Intent 的場景切換。

這就是出行域內復雜度為線性級別的解。

結語

前段時間跟業內不少前輩聊過，雖然受到了很大的打擊，但終究還是以此為契機看到了更多的東西。

有位前輩問過我的一個問題，給我留下了很深的印象：『你的邊界在哪？技術型產品和技術的邊界在哪？』。最近我也一直在思考這個問題，也漸漸有了自己的認知：技術負責給出問題的解，而技術型產品負責給出要求解的問題。

我最近一直在做的 Bot Framework 的競品分析，本質上也是希望通過他們的設計，找到他們在求解的問題。但是我不該，也不會止步于此。

因為還有一個更本質的問題需要我回答：他們求解的問題，是哪來的？如果無法回答這個問題，那我所做的，也只不過是亦步亦趨，拾人牙慧而已。

我有了三點想法：

• 對話問題的來源是語言中存在的現象
• 對話問題并不是對話平臺唯一要求解的問題
• 如果缺乏對已有解的了解，尋找問題的過程，也是低效的

第一點驅使我去更多的了解語言本身，第二點驅使我在分析競品建立起對整個平臺生態的把握，第三點驅使我去回顧、去跟進 ML、DL、NLP 領域的發展。

共勉。