導語：本文作者前後經歷了40+個機器人的搭建、設計與運營，同時從0-1構建了機器人對話平台。通過對過往經驗的復盤總結，作者對「對話機器人」的核心功能要點做了梳理與總結，希望這篇文章對你有所幫助，歡迎大家討論。
一、對話概述
在講對話核心功能之前，我們先看一下，什麼是對話？
對話是對話雙方基於某個話題，通過語言進行信息交互的過程。比如：你早上起來，你媽媽跟你的對話：
Mother：早餐想吃啥？我給你煮
你：我喝點粥就好了
Mother：那煎荷包蛋給你吃吧
你：好嘞，我剛想吃
Mother：要一個還是兩個？
你：一個就好了
Mother：再給你弄點腐乳吧
你：好呀
1.1 對話組成部分
對話的定義中，有幾個關鍵的組成部分。
1.1.1 對話雙方
即一個對話中的信息傳遞與交互者，這裡一般指的是雙方的對話，若是超過2人，則視為「群聊」。可以想想微信中的定義：單聊和群聊。
在上述的例子中，對話雙方就是你和你媽媽。你們倆通過語言進行信息的交互，如果你爸也參與進來，那就是三方的對話。相較於雙方的對話，三方（或更多）的對話，在信息交互上更為複雜些，這不在我們的討論範圍內。
1.1.2 話題
一個對話的進行，必定有其對應的話題，話題與對話雙方的核心需求相關聯。
沒有話題的對話，幾乎不存在。當然，你可能會說，那我就漫無目的的閑聊唄，沒有固定話題呀。是的，這裡我們把「閑聊」也看做一個話題。
「閑聊」雖然看起來漫無目的，但是其本質也是為了滿足對話雙方的需求與目的。如果沒有這個需求，那雙方可能連說話/打字都懶得動，故這裡把「閑聊」也定義為某個話題。
在上述的例子中，你和你媽媽這個對話的話題就是「吃早餐」，為什麼有這個話題？
因為你媽媽關心你早餐吃什麼，你不論出於真的想吃早餐也好，想讓你媽媽放心也好，都是基於「吃早餐」這個話題，跟你媽媽聊幾句。當然你除了聊「吃早餐」，你可能也會在對話中，突然想起你昨天到的快遞，進而問你媽媽「快遞是不是拿了」。
此時，對話就變成了多個話題：「吃早餐」、「是否拿快遞」。
一個對話中，可能只有1個話題，也可能有多個話題。詳情你可以回想下生活中的各種對話。當多個話題交織在一起時，對話的結構也會變複雜。但是，幾乎沒有對話是沒話題，對話雙方在那兒對話的（想想是不是挺詭異），這種「牛頭不對馬嘴」的對話，同樣也不在我們的討論範圍內。
1.1.3 語言
語言是信息的載體。在對話中，基於話題，對話雙方是需要語言來交流的，語言可以通過語音（也就是說話）、文字（也就是打字）來表達。
而我們為什麼需要語言呢？因為語言主要是來傳遞人要表達的信息的，再看上述的例子：你媽媽說：「早餐想吃啥？我給你煮」.
為啥你媽媽要這麼說？因為你媽媽要知道你「早餐想吃啥」這個信息，因為獲取這個信息，她才能進行接下去的動作：你想喝粥，她就煮粥；你想吃包子，她就熱包子；你想吃龍蝦，她可能就把你抓過來打你頭並說：「一大早你腦子是睡傻了吧你」。
同樣的，你說「我喝點粥就好了」，也是通過語言來傳遞「你想喝粥」的信息給你媽媽，讓她接收到這個信息，你們倆都在使用語言傳遞各自想要表達的信息。
當然，語音、文字這兩種方式，能承載的信息是有差別的。語音能承載的信息更多，因為有語調、語速等更多維度的信息。這個也是目前AI對話領域的ASR信息衰減的一個原因，此處在不贅述。
1.1.4 信息交互
對話的本質在於對話雙方間的信息交互。信息交互是讓對話進行的必要條件。
比如上述的例子中，你媽媽問你：「早餐想吃啥？我給你煮」。而你沒回應她，繼續玩弄自己的手機。那你媽媽會怎麼樣呢？你媽媽大概率會再問你一次「早餐想吃啥？」（生氣值上升20%）。
為什麼？因為在對話中，信息是需要交互的。你沒有回應你媽媽問你的話，這是信息的單向傳遞，你媽媽並沒有獲取到她想要的信息，所以她再問了你一次。假如你再不回答，那對於這個話題，對話就進行不下去了。你媽媽可能開始質問你，對話的話題就轉變為另一個：「為什麼你媽媽問你話你不答」。
所以，信息交互對於對話而言，是至關重要的組成部分，也是讓對話進行的基石。
1.2 機器人在對話中的職責
在講機器人在對話中的角色與職責前，我們先來看一下，機器人能做的事情是什麼？對話機器人的興起，得益於本次AI中的NLP領域的發展。可用於對話的AI能力有什麼呢？
- 語義識別能力：意圖識別、實體識別、語義相似度識別
- 知識構建與識別能力：知識圖譜
看著似乎挺抽象是吧？沒事，我們後面會具體講。簡單地說，現在的AI技術決定了對話機器人可以解決的問題是：某個特定行業領域下，基於某類特定問題，提供簡單固定的解答/服務。
上述的「吃早餐」對話場景，如果是一個「早餐機器人」，它會怎麼做呢？
假設它的工作流程是：詢問早餐需求->做早餐，那麼，「詢問早餐需求」跟你的對話應該是這樣的：
Bot：早上好，請問你早餐想吃什麼呢？（提供選項：粥，包子，麵包，花生湯）
你：我想喝粥
Bot：好的。那您喝粥配荷包蛋可以嗎？
你：好啊，我剛想吃荷包蛋
Bot：吃一個還是兩個呢？
你：一個就好了
Bot：再配點腐乳嗎？
你：好呀
看完這段你可能會說：這效果不是跟我和我媽的對話一樣嘛！機器人真的有這麼厲害嗎？
答案是NO，機器人並沒有那麼厲害。為什麼？我們從剛才說的對話機器人可解決的問題看。
1.2.1 特定行業領域的特定問題
上述的對話是基於「吃早餐」這個話題對應的「飲食」這類領域而定的。如果是所有領域（或者說是開放閾），機器人是處理不了的。
比如你突然問它：「我的快遞單號是多少」，它可能就沒法解答。因為它只是針對你「吃早餐」的機器人。問快遞單號的話，你可以打開淘寶，讓阿里小蜜機器人回答你：）
1.2.2 提供簡單固定的解答/服務
機器人只能提供固定流程的解答與服務，並不能解答覆雜、隨機性太大的對話問題。
比如剛才的對話，機器人說：「早上好，請問你早餐想吃什麼呢？」而你說：「有鍋邊糊嗎」（註解：鍋邊糊是福建早餐小吃）機器人可能壓根就不知道你在說什麼。
因為機器人的這個問題，是有人為的預設值，若訪客回復內容，未落在預設值內，就會出現機器人無法處理的問題。
所以，在設計機器人時，需要了解當機器人發問后，訪客可能會說的內容。語言本身就是開放閾的內容，訪客會說什麼，設計者只能按照概率大小去設計，盡量去覆蓋，並無法窮盡訪客的說法。
而訪客的語言，又受到個人因素、當時環境因素的影響，從本質上來說，這是永遠的矛盾點。
因此，對話機器人能解決的對話問題，是所有對話語言問題中的一部分，或者說一小部分。雖然對話機器人做不了非常智能、隨機性很大的對話問題，但是在某些領域，對話機器人還是可以很高效、便捷地幫人處理很多對話問題。
比如智能客服領域、系統內人力資源問答領域等等，這也是目前對話機器人的價值應用領域。
二、機器人對話
2.1 用戶對話場景
既然對話機器人是針對某個特定行業領域的對話，那麼在設計對話功能之前，第一步是需要明確，對話機器人解決的是哪個行業領域，什麼訪客，具體什麼場景的的問題。這是對話機器人的框架與邊界，只有先確定，後面的設計才可以進行。
2.1.1 確定行業領域
比如：「電商行業」、「金融行業」、「醫療行業」等等，行業決定了訪客特性、機器人應答策略、機器人知識庫內容與結構。
2.1.2 確定對話場景
比如：「售後場景」、「售前場景」、「企業內部接待支持」、「微信群聊」等等。不同的對話場景，可能對應不同的對話目的，決定了機器人「該如何應答」。
場景往下拆分，根據顆粒度從大到小，又可分為：場景->意圖，指的是場景從大到小的拆分。
有的機器人根據業務需要，還會更細地拆分為：場景->主題->意圖（父意圖）->意圖（子意圖）。每個意圖下分別對應不同的機器人對話流程，同時流程間會設定各種規則，以應對在對話中訪客不同的發問情況。
如何確定對話場景？
一般需要AI訓練師/AI PM，根據行業內的場景情況，通過人工對話數據，或查閱相關資料/訪談的方式，了解行業場景特性，並拆分出具體的訪客意圖。
比如：在「電腦培訓售前場景」中，根據訪客對話場景，會劃分「諮詢網頁設計」、「諮詢JAVA課程」、「諮詢SEO課程」，「諮詢Python課程」等等。常見的，對話場景的數量，一般在20個-50個之間不等（當然，某些特定對話場景會超出這個範圍）。
對話場景的劃分，需遵循MECE原則：相互獨立，完全窮盡。即：所有意圖需覆蓋所有的訪客意圖情況（完全窮盡），且意圖之間盡量相互獨立，互不交叉（相互獨立）。這會為後續的應答策略，做一個良好的場景設定，讓後續的對話設計更好進行。
2.2 機器人應答策略
雖然不同的對話場景中，機器人具體的應答策略是不一樣的：比如售後場景的機器人主要以解答為主，而售前場景的機器人是引導訪客留聯。但是在所有場景的機器人中，是有一套適用於對話機器人設計的應答策略方法論的，差別點在於具體落地機器人的實現展示方式。
2.2.1 單輪對話、多輪對話
根據機器人與訪客對話形式的不同，可以將對話形態劃分為單輪對話、多輪對話，通俗地講即：你想讓機器人如何解決訪客的問題。
2.2.1.1 單輪對話：訪客問一個問題，機器人立即回答
比如：
訪客：「你們培訓地點是在哪兒啊？」
BOT：「我們是在海淀區知春路25號百事大廈13樓」
這類訪客問題中，訪客問的是一個客觀的，不隨訪客信息/其他信息等的不同而不同的回答。即：不論訪客是小明，還是小紅，「培訓地點」它永遠都是「海淀區知春路25號百事大廈13樓」。所以機器人只需要根據事實（通常將該類知識配置在知識庫中），直接回答即可。
由於其交互是一問一答，在一個對話輪次中即可解決問題，故稱之為「單輪對話」。
2.2.1.2 多輪對話：訪客問一個問題，機器人通過詢問訪客信息，根據訪客不同的信息作出回答
比如：
訪客：「我可以報六級英語培訓班嗎」
BOT：「請問下您通過四級英語考試了嗎？」
訪客：「通過了」
BOT：「嗯好的，您可以報六級英語培訓班的，這邊登記下您的信息」
這類訪客問題中，若要進行回復（無論是機器人/人工），則需確定某些參數信息才可回復。「是否通過四級英語考試」，是上述例子中的參數變數。
「通過」對應一個回答；「未通過」則對應另一個回答。機器人需要通過詢問訪客這些信息，才能進行回答。所以對話需要進行多輪的交互，一般為「機器人詢問-訪客答」的方式，故稱之為「多輪對話」。
這兩種對話形式，也構成了目前對話機器人的對話，是對話的框架基礎。為什麼沒有其他類型的對話形式呢？
原因很簡單，因為現有的NLP技術，在支撐具體業務場景下，這兩種對話形式是最有效的。或者換句話說，暫時沒有第三種方式讓機器人更好地服務訪客。
而對話機器人的設計，主要在於對話策略的設計，具體表現在對話流程的邏輯設計。單輪對話由於其一問一答的形式，基本不需要對話邏輯的設計，其重點在於知識的構建和回答的設計。所以，對話設計的重點，在於多輪對話的設計。
2.2.2 多輪對話設計
多輪對話的設計要點：場景、對話流程、信息流轉。
2.2.2.1 場景
定義對話場景，行業內機器人的做法主要是通過意圖定義場景。比如：「諮詢Python課程」這個意圖，通過對意圖的解答和服務，來完成機器人對話。
2.2.2.2 對話流程
這個是對話機器人的核心，包括：對話流程如何運轉、異常情況該如何處理、多輪對話與單輪對話的協作配合。
2.2.2.3 信息流程
對話內的信息，是對話的核心要素。所以需要設計：對話內信息如何流轉；同時，由於機器人是需要和對話外的系統做信息交流，所以也需設計對話外信息如何與對話內信息進行交互流轉。
2.3 核心功能要點
2.3.1 場景識別
場景識別，是對對話場景、用戶意圖的識別。這也是對話中體現AI技術運用的核心功能。行業內主流的做法，是用意圖來定義，對應的AI技術就是意圖識別，本質上是一種分類演算法。
比如：「諮詢Python課程」這個意圖，需要提供訪客關於這個意圖的各式各樣的說法，進行模型訓練，從而「教會」模型去識別。所以需提供讓用戶可進行意圖定義、語料定義的功能，讓用戶可進行配置。
通常的做法是：
2.3.1.1 讓用戶構建語料
主要有2種方式：
- 讓用戶自行構想創建。但這種方式是及其枯燥和艱難的，因為定義一個意圖，需要幾十條甚至上百、上千條的對話語料（對模型來說，數據量越多越好）。對於用戶來說，任務艱巨且乏味；
- 抽取人工對話數據，通過系統推薦構建語料庫。這種方式是在用戶創建數條語料后，系統根據相似度，從人工對話數據語料中，推薦給用戶。用戶可自行決定添加/不添加，省去了自己憑空想象的枯燥過程。
2.3.1.2 讓用戶構建意圖句式
與第一種方式不同，這種方式是讓用戶抽象意圖的各種表達方式，通過一個句式，來涵蓋訪客的說法。句式內容可包括：關鍵詞、正則表達式、實體。通過配置詞順序、匹配度，來構建句式，從而實現匹配訪客說法的目的。
值得注意的是，這種構建方法，本質上是通過「寫規則」來設計，與AI的理念實際上是相反的。所以一般作為補充第一種方式使用。
其弊端也很明顯：往往句式寫多了，句式之間可能出現交叉、互斥的情況。而配置的人卻較難發現與調整。當句式越來越多后，就更難進行調整，對對話機器人實則是一種隱患。
當然，這種方式在機器人冷啟動時相當好用，這也是其存在的可能是最大的價值。
除了上述通過意圖來定義用戶場景外，還能通過其他維度進行定義。比如，通過關鍵詞、實體、正則表達式、變數，來定義用戶場景。
定義的維度越豐富，能支撐的業務也就越多，同時對於後續流程的處理，也就需考慮更為複雜的情況。所以基於當前需解決的業務形態來設計，至關重要。
2.3.2 流程邏輯
流程邏輯的構建，可以說是對話機器人的骨架。流程決定了對話機器人是否可為訪客提供價值。流程與場景一般是一一對應的關係，通常我們若用意圖來定義場景的話，那麼每一個意圖，將會對應一個對話流程。
還是上述「電腦培訓行業」的機器人，當機器人向訪客詢問：「請問你想了解哪方面的培訓課程呢？」
- 訪客若說：「我想了解Python課」，那麼對應意圖識別的結果為「諮詢Python課程」，於是進入「Python課程」的對話流程；
- 訪客若說：「我想了解JAVA課」，那麼對應意圖識別的結果為「諮詢JAVA課程」，於是進入「JAVA課程」的對話流程。
當然，訪客也有可能什麼都不說，或者壓根就不回答機器人的問題，只顧自己描述自己的問題。這就需要機器人設計者（AI訓練師），構建「無意圖」/「通用意圖」，來覆蓋訪客的各種場景，讓機器人應對自如。
以下講講流程邏輯功能設計中的關鍵要點：當你開始設計對話機器人時，你就會發現，對話機器人的骨架，其實是一棵對話樹。
除了對訪客問題的識別，通過AI能力進行外，這棵樹幾乎全部是由AI PM/AI訓練師，通過定義對話規則，來構成的。這也就是我們說的對話策略。而流程的設計，即使這棵樹的設計。
2.3.2.1 流程間邏輯
一個機器人中，必定有多個流程，一般數量在幾十個，流程間邏輯的設計尤為重要。
- 流程優先順序
眾多流程中，當訪客的問題，同時滿足多個流程進入條件時，哪一個流程優先觸發？
通常的做法是，讓用戶給意圖/流程做一個優先順序的排序。如按照編輯順序從上往下，越重要的意圖，用戶可以放在越前面。這是一種對於大多數場景有效的做法，但是真的就沒問題嗎？
答案是NO，比如：
訪客：「Python課和JAVA課，哪個好學啊？」
這種情況下，訪客意圖是「諮詢Python課程」，還是「諮詢JAVA課程」呢？
按照我們剛才說的策略，用戶意圖「諮詢Python課程」排在「諮詢JAVA課程」前面，則進入「諮詢Python課程」意圖的流程，反之則對換——這能解決訪客的問題嗎？
這是通過人工預判的方式，來提前設定訪客問題的意圖歸屬。而訪客的意圖，可能隨著對話場景、對話語境、自身情況的不同，而存在差異的。簡單來說，就是我們用一種簡單的一刀切的方式，來解決訪客的可能複雜的意圖問題。這是一種概率押賭的方式，只能解決一大部分問題，而非所有問題。
很遺憾，目前的AI技術，只到這個能力，還尚未到真正的「人工智慧」時代。所以技術不夠，產品來湊，需要產品經理來不足AI不好解決的問題。
我們的做法是，針對這句訪客問題，可用知識圖譜進行答疑（當然也可配置FAQ+規則，但是需要做的排列組合較多，如：Python+JAVA；Python+C語言，等等），同時進入一個「無意圖」的流程。通過進一步詢問來確定訪客的意圖及對應的流程。
- 流程間跳轉關係
流程間分為同級流程，與父子流程。
同級流程：同級流程之間的跳轉，一般和流程中新意圖的識別有關。當訪客觸發新的意圖時，即做流程跳轉，比如：
訪客：「我想學Python」 —-進入「Python課程」流程
BOT：「可以的，我先了解下您的情況」
…
訪客：「C語言怎麼樣啊？」—-跳轉至「C語言課程」流程
…
父子流程：子流程的准入條件，需為先觸發父流程。二者為並非同級關係，而是從屬關係。
比如：在醫療口腔中，「牙齒美白」與「冷光美白」是父子流程關係。因為「冷光美白」是「牙齒美白」中的一種方式。
訪客：「你們能做牙齒美白嗎？」 —-進入「牙齒美白」流程
BOT：「可以的，我先了解下您的情況」
…
訪客：「冷光的你們有沒有啊？」—-跳轉至「冷光美白」流程
…
一般而言，進入子流程后，將不再返回至父流程。因為子流程是更細的場景，對話機器人的服務原則是，進入更細的場景，即能提供更有針對性的服務。
- 流程執行唯一性
同級流程中，當流程執行后，訪客問題再次出發了該流程，是否可再次進入呢？
這個問題其實根據不同的行業與業務場景，策略的選擇是不一樣的。通常來講，對於售後服務等來說，重複進入同一個流程，要求是較低的。
同時由於詞槽收集可避免重複發問，所以可接受再次進入流程；而售前引導性的場景，就較為幾回再次進入同一流程，因為這樣往往會讓機器人看著更加「不智能」，降低訪客對服務的信任感，所以一般是不能再次進入的。
但是無論如何，這個問題都是在對話機器人中，流程邏輯設計中應考慮的要素。
2.3.2.2 流程內邏輯
流程內的邏輯，指的是當訪客進入某流程時，機器人的應答策略。
- 流程准入條件
前面說了，流程一般的准入條件為意圖。但一些較複雜的場景，除了意圖外，我們還可以用關鍵詞、正則表達式、實體、變數來定義訪客的場景，作為流程准入的條件。
流程准入條件，可以看成是流程的大門：條件定義得寬泛，則門越大，進入流程的訪客問題類別更少，在流程中需處理的情況就越多；條件定義得苛刻，則門越窄，進入流程的訪客問題類別越少，在流程中需處理的情況就越少。但是同時，需定義的流程數量也更多。
- 流程進展
流程進展是對話處理的關鍵。簡單來說就是，機器人如何發問？當機器人發問后，訪客的各種回復情況，怎麼處理？
a. 機器人如何發問？
a）發問內容
發問內容與當前意圖下，機器人需獲取的信息相關。通常為設計者設計的固定詢問話術，進行發問。
這裡順便提到AI技術：NLG，即對話生成。可通過AI通過對話場景，生成相應的話術內容。但從實際效果來看，目前的NLG尚未達到業務對話要求，固定的話術效果會更好。
b）發問順序
發問順序通常是固定的預設順序。通常設計者會根據用戶場景，設計某個意圖下，機器人發問的具體順序。當然，在發問之前，若機器人已收集到相應信息，可做跳過處理。
b. 訪客回復后，機器人如何處理？
訪客回復后的處理，是對話流程往下進行的必要條件。機器人發問后，訪客的回應可能有幾種情況：
a）提供了機器人發問的信息
情況1：提供了單一信息，比如：
BOT：「你想諮詢什麼課程呢？」
訪客：「Python課」
這種情況是最理想的情況。我們只需要設定不同信息下對應不同的對話分支走向即可，對話樹也即順利進行下去。
情況1：提供了多信息
BOT：「你想諮詢什麼課程呢？」
訪客：「Python和JAVA的課程我都考慮」
這種情況中，AI演算法會從訪客的回復中提取「Python」和「JAVA」兩個信息，並且並不知道訪客到底是想要哪個。這種情況就需要做特殊處理，有幾種常見的處理方式：
- 隨機選取一個信息，進行後續對話分支的執行；
- 構建句式，選取其中一個信息，作為分支執行的條件；
- 進入除預設分支外的默認/其他分支，執行後續的動作。
具體適用哪種策略，也需根據不同機器人而設計。
b) 訪客回復，但未提供機器人發問的信息
情況1：訪客的回復內容，未在預設的對話分支中，比如：
BOT：「你想諮詢電腦培訓的什麼課程呢？」
訪客：「我想諮詢畫畫的班」
這種情況下，一般設計者也較難預知這種訪客的回復，一般會讓對話走「默認/其他」分支流程，以便讓對話繼續。當然，事後發現了問題，也可以通過補充對話分支的方式，來擴充機器人應答能力。
情況2：訪客的回復內容，新起了一個話題，比如：
訪客：「我想諮詢下Python課程」
BOT：「好的。請問您是什麼學歷呢？」
訪客：「對了，你們的JAVA課怎麼樣啊？」
這種情況，訪客已經新起了個話題「JAVA課」，對話可以進入「JAVA課」的意圖流程中。當然，也可以不進入，這就涉及到「新流程優先」還是流程內「分支優先」的問題。
一般而言，對於場景較為垂類，較無多話題交叉的對話，使用「分支優先」是更優的選擇；而對於對話中較長有多話題交叉的對話，使用「新流程優先」效果會更好一些。這也是策略的選擇，通過概率大小決定應答策略。
c) 訪客不回復
當機器人發問后，訪客不回復。有可能是訪客離開了對話，也有可能是訪客切換了應用程序（常見於手機中）。訪客若不提供相關的信息，對話不好進行下去。
處理的方式有：間隔一段時間（如幾十秒）后，機器人再次發問（話術可有所變化），以獲得相應信息；或是靜默等待，若訪客依然不回復，則自動填入信息默認值，執行下一步對話動作。
- 流程打斷處理
在機器人發問-訪客回復的多輪對話 交互中，我們預想的是訪客會按照我們預設的對話節奏進行。但是實際過程中，訪客並不在意機器人是按照什麼規則、什麼節奏進行對話的，所以會出現當機器人正在應答，訪客進行打斷的情況（特別是在語音機器人的場景中）。
一般的處理方式是：被打斷後，機器人暫停回復，等待訪客表述完。被打斷的流程，若進入了新的流程，一般會等新流程執行結束后，再次回到原有流程。這個可根據不同的流程而設定「打斷後恢復」的設置。
2.3.3 信息流轉
前文講了，對話中的信息流轉，是對話的重要屬性，信息流轉分為對話內與對話外的信息流轉。
2.3.3.1 對話內信息流轉
即通過獲取訪客信息，做信息的記錄、傳遞、更新與使用。其中，有兩個要素是最重要的：
- 實體：實體是系統獲取訪客信息的來源。可以通過AI的實體識別能力，也可通過定義關鍵詞庫的方式進行識別，這是信息獲取的源頭；
- 變數（詞槽）：通過實體識別獲取了訪客信息后，需要存在一個載體中，這個載體就是變數（詞槽）。變數就像人體血液中的紅細胞一樣，獲取、運輸、更新對話信息，並把信息給對話的中控系統使用。可作為條件判斷的依據，也可作為話術的內容。
2.3.3.2 對話外信息流轉
在對話機器人中，對話信息不僅在對話中流轉，也可跟對話外部的系統做信息的交互，比如：
訪客：「幫我查一下明天的天氣」
BOT：「好的。明天北京天氣晴，氣溫15-23攝氏度。」
對話機器人需要通過外部系統（查天氣系統），才能獲取具體的天氣信息。其中，通過將具體的日期、地點信息傳遞給查天氣系統，獲取相應的天氣信息，這就是對話外信息流轉。
一般會設置介面調用的方式，通過設定介面和參數，與對話 機器人外的系統做信息交互。從而實現各種對話機器人技能的落地，如：查天氣、訂火車票、開電視、打開音樂等等
2.3.4 流程與知識庫協作
如果說流程是整個對話機器人的骨架，那麼知識庫就如同機器人的血肉，因為機器人做答疑的一大部分內容，是通過知識庫進行的。而流程與知識庫需通過寫作配合，才能讓對話機器人在解答訪客問題的同時，又讓對話順利無縫地進展，從而最終達到對話目的。
流程與知識庫協作的策略，主要有以下2種：
- 訪客發送的每條信息，先使用知識庫做解答，后執行流程的動作與話術：該策略適用於「解答型服務」的對話。即：盡量解答訪客的每個問題，即使機器人的對話顯得啰嗦，也可接受。
- 當訪客回復未在預設的對話分支中時，才使用知識庫做解答
該策略適用於「引導性服務」的對話，對話重點在於讓對話引導的體驗更加，而不在於解答訪客的每個問題。兩種策略均各有利弊，側重點不同，提供的服務體驗也不同，可根據具體情況而確定。
三、總結
對話機器人產品，鑒於現有的AI技術，可以說有一大部分是需要AI PM做規則設計、策略設計的。
設計思路可概括為：用判斷概率的方式，選擇其對話策略。所以對話中有大量的邏輯設計、策略選擇，根據對話機器人所處的行業領域與用戶場景，做不同的取捨和側重點設計。
本文主要概述了對話機器人的設計要點，但有些要點中，又有其豐富的設計理念和實操細節，本文不在此方面贅述。後續會針對重點要素做詳細講解，希望對你有幫助。
作者：咖喱魚丸，5年PM經驗，2年AI PM經驗