導(dǎo)語：本文作者前后經(jīng)歷了40+個機器人的搭建、設(shè)計與運營，同時從0-1構(gòu)建了機器人對話平臺。通過對過往經(jīng)驗的復(fù)盤總結(jié)，作者對“對話機器人”的核心功能要點做了梳理與總結(jié)，希望這篇文章對你有所幫助，歡迎大家討論。

一、對話概述

在講對話核心功能之前，我們先看一下，什么是對話？

對話是對話雙方基于某個話題，通過語言進行信息交互的過程。比如：你早上起來，你媽媽跟你的對話：

Mother：早餐想吃啥？我給你煮

你：我喝點粥就好了

Mother：那煎荷包蛋給你吃吧

你：好嘞，我剛想吃

Mother：要一個還是兩個？

你：一個就好了

Mother：再給你弄點腐乳吧

你：好呀

1.1 對話組成部分

對話的定義中，有幾個關(guān)鍵的組成部分。

1.1.1 對話雙方

即一個對話中的信息傳遞與交互者，這里一般指的是雙方的對話，若是超過2人，則視為“群聊”。可以想想微信中的定義：單聊和群聊。

在上述的例子中，對話雙方就是你和你媽媽。你們倆通過語言進行信息的交互，如果你爸也參與進來，那就是三方的對話。相較于雙方的對話，三方（或更多）的對話，在信息交互上更為復(fù)雜些，這不在我們的討論范圍內(nèi)。

1.1.2 話題

一個對話的進行，必定有其對應(yīng)的話題，話題與對話雙方的核心需求相關(guān)聯(lián)。

沒有話題的對話，幾乎不存在。當(dāng)然，你可能會說，那我就漫無目的的閑聊唄，沒有固定話題呀。是的，這里我們把“閑聊”也看做一個話題。

“閑聊”雖然看起來漫無目的，但是其本質(zhì)也是為了滿足對話雙方的需求與目的。如果沒有這個需求，那雙方可能連說話/打字都懶得動，故這里把“閑聊”也定義為某個話題。

在上述的例子中，你和你媽媽這個對話的話題就是“吃早餐”，為什么有這個話題？

因為你媽媽關(guān)心你早餐吃什么，你不論出于真的想吃早餐也好，想讓你媽媽放心也好，都是基于“吃早餐”這個話題，跟你媽媽聊幾句。當(dāng)然你除了聊“吃早餐”，你可能也會在對話中，突然想起你昨天到的快遞，進而問你媽媽“快遞是不是拿了”。

此時，對話就變成了多個話題：“吃早餐”、“是否拿快遞”。

一個對話中，可能只有1個話題，也可能有多個話題。詳情你可以回想下生活中的各種對話。當(dāng)多個話題交織在一起時，對話的結(jié)構(gòu)也會變復(fù)雜。但是，幾乎沒有對話是沒話題，對話雙方在那兒對話的（想想是不是挺詭異），這種“牛頭不對馬嘴”的對話，同樣也不在我們的討論范圍內(nèi)。

1.1.3 語言

語言是信息的載體。在對話中，基于話題，對話雙方是需要語言來交流的，語言可以通過語音（也就是說話）、文字（也就是打字）來表達。

而我們?yōu)槭裁葱枰Z言呢？因為語言主要是來傳遞人要表達的信息的，再看上述的例子：你媽媽說：“早餐想吃啥？我給你煮”.

為啥你媽媽要這么說？因為你媽媽要知道你“早餐想吃啥”這個信息，因為獲取這個信息，她才能進行接下去的動作：你想喝粥，她就煮粥；你想吃包子，她就熱包子；你想吃龍蝦，她可能就把你抓過來打你頭并說：“一大早你腦子是睡傻了吧你”。

同樣的，你說“我喝點粥就好了”，也是通過語言來傳遞“你想喝粥”的信息給你媽媽，讓她接收到這個信息，你們倆都在使用語言傳遞各自想要表達的信息。

當(dāng)然，語音、文字這兩種方式，能承載的信息是有差別的。語音能承載的信息更多，因為有語調(diào)、語速等更多維度的信息。這個也是目前AI對話領(lǐng)域的ASR信息衰減的一個原因，此處在不贅述。

1.1.4 信息交互

對話的本質(zhì)在于對話雙方間的信息交互。信息交互是讓對話進行的必要條件。

比如上述的例子中，你媽媽問你：“早餐想吃啥？我給你煮”。而你沒回應(yīng)她，繼續(xù)玩弄自己的手機。那你媽媽會怎么樣呢？你媽媽大概率會再問你一次“早餐想吃啥？”（生氣值上升20%）。

為什么？因為在對話中，信息是需要交互的。你沒有回應(yīng)你媽媽問你的話，這是信息的單向傳遞，你媽媽并沒有獲取到她想要的信息，所以她再問了你一次。假如你再不回答，那對于這個話題，對話就進行不下去了。你媽媽可能開始質(zhì)問你，對話的話題就轉(zhuǎn)變?yōu)榱硪粋€：“為什么你媽媽問你話你不答”。

所以，信息交互對于對話而言，是至關(guān)重要的組成部分，也是讓對話進行的基石。

1.2 機器人在對話中的職責(zé)

在講機器人在對話中的角色與職責(zé)前，我們先來看一下，機器人能做的事情是什么？對話機器人的興起，得益于本次AI中的NLP領(lǐng)域的發(fā)展。可用于對話的AI能力有什么呢？

• 知識構(gòu)建與識別能力：知識圖譜

看著似乎挺抽象是吧？沒事，我們后面會具體講。簡單地說，現(xiàn)在的AI技術(shù)決定了對話機器人可以解決的問題是：某個特定行業(yè)領(lǐng)域下，基于某類特定問題，提供簡單固定的解答/服務(wù)。

上述的“吃早餐”對話場景，如果是一個“早餐機器人”，它會怎么做呢？

假設(shè)它的工作流程是：詢問早餐需求->做早餐，那么，“詢問早餐需求”跟你的對話應(yīng)該是這樣的：

Bot：早上好，請問你早餐想吃什么呢？（提供選項：粥，包子，面包，花生湯）

你：我想喝粥

Bot：好的。那您喝粥配荷包蛋可以嗎？

你：好啊，我剛想吃荷包蛋

Bot：吃一個還是兩個呢？

你：一個就好了

Bot：再配點腐乳嗎？

你：好呀

看完這段你可能會說：這效果不是跟我和我媽的對話一樣嘛！機器人真的有這么厲害嗎？

答案是NO，機器人并沒有那么厲害。為什么？我們從剛才說的對話機器人可解決的問題看。

1.2.1 特定行業(yè)領(lǐng)域的特定問題

上述的對話是基于“吃早餐”這個話題對應(yīng)的“飲食”這類領(lǐng)域而定的。如果是所有領(lǐng)域（或者說是開放閾），機器人是處理不了的。

比如你突然問它：“我的快遞單號是多少”，它可能就沒法解答。因為它只是針對你“吃早餐”的機器人。問快遞單號的話，你可以打開淘寶，讓阿里小蜜機器人回答你：）

1.2.2 提供簡單固定的解答/服務(wù)

機器人只能提供固定流程的解答與服務(wù)，并不能解答復(fù)雜、隨機性太大的對話問題。

比如剛才的對話，機器人說：“早上好，請問你早餐想吃什么呢？”而你說：“有鍋邊糊嗎”（注解：鍋邊糊是福建早餐小吃）機器人可能壓根就不知道你在說什么。

因為機器人的這個問題，是有人為的預(yù)設(shè)值，若訪客回復(fù)內(nèi)容，未落在預(yù)設(shè)值內(nèi)，就會出現(xiàn)機器人無法處理的問題。

所以，在設(shè)計機器人時，需要了解當(dāng)機器人發(fā)問后，訪客可能會說的內(nèi)容。語言本身就是開放閾的內(nèi)容，訪客會說什么，設(shè)計者只能按照概率大小去設(shè)計，盡量去覆蓋，并無法窮盡訪客的說法。

而訪客的語言，又受到個人因素、當(dāng)時環(huán)境因素的影響，從本質(zhì)上來說，這是永遠的矛盾點。

因此，對話機器人能解決的對話問題，是所有對話語言問題中的一部分，或者說一小部分。雖然對話機器人做不了非常智能、隨機性很大的對話問題，但是在某些領(lǐng)域，對話機器人還是可以很高效、便捷地幫人處理很多對話問題。

比如智能客服領(lǐng)域、系統(tǒng)內(nèi)人力資源問答領(lǐng)域等等，這也是目前對話機器人的價值應(yīng)用領(lǐng)域。

二、機器人對話 2.1 用戶對話場景

既然對話機器人是針對某個特定行業(yè)領(lǐng)域的對話，那么在設(shè)計對話功能之前，第一步是需要明確，對話機器人解決的是哪個行業(yè)領(lǐng)域，什么訪客，具體什么場景的的問題。這是對話機器人的框架與邊界，只有先確定，后面的設(shè)計才可以進行。

2.1.1 確定行業(yè)領(lǐng)域

比如：“電商行業(yè)”、“金融行業(yè)”、“醫(yī)療行業(yè)”等等，行業(yè)決定了訪客特性、機器人應(yīng)答策略、機器人知識庫內(nèi)容與結(jié)構(gòu)。

2.1.2 確定對話場景

比如：“售后場景”、“售前場景”、“企業(yè)內(nèi)部接待支持”、“微信群聊”等等。不同的對話場景，可能對應(yīng)不同的對話目的，決定了機器人“該如何應(yīng)答”。

場景往下拆分，根據(jù)顆粒度從大到小，又可分為：場景->意圖，指的是場景從大到小的拆分。

有的機器人根據(jù)業(yè)務(wù)需要，還會更細地拆分為：場景->主題->意圖（父意圖）->意圖（子意圖）。每個意圖下分別對應(yīng)不同的機器人對話流程，同時流程間會設(shè)定各種規(guī)則，以應(yīng)對在對話中訪客不同的發(fā)問情況。

如何確定對話場景？

一般需要AI訓(xùn)練師/AI PM，根據(jù)行業(yè)內(nèi)的場景情況，通過人工對話數(shù)據(jù)，或查閱相關(guān)資料/訪談的方式，了解行業(yè)場景特性，并拆分出具體的訪客意圖。

比如：在“電腦培訓(xùn)售前場景”中，根據(jù)訪客對話場景，會劃分“咨詢網(wǎng)頁設(shè)計”、“咨詢JAVA課程”、“咨詢SEO課程”，“咨詢Python課程”等等。常見的，對話場景的數(shù)量，一般在20個-50個之間不等（當(dāng)然，某些特定對話場景會超出這個范圍）。

對話場景的劃分，需遵循MECE原則：相互獨立，完全窮盡。即：所有意圖需覆蓋所有的訪客意圖情況（完全窮盡），且意圖之間盡量相互獨立，互不交叉（相互獨立）。這會為后續(xù)的應(yīng)答策略，做一個良好的場景設(shè)定，讓后續(xù)的對話設(shè)計更好進行。

2.2 機器人應(yīng)答策略

雖然不同的對話場景中，機器人具體的應(yīng)答策略是不一樣的：比如售后場景的機器人主要以解答為主，而售前場景的機器人是引導(dǎo)訪客留聯(lián)。但是在所有場景的機器人中，是有一套適用于對話機器人設(shè)計的應(yīng)答策略方法論的，差別點在于具體落地機器人的實現(xiàn)展示方式。

2.2.1 單輪對話、多輪對話

根據(jù)機器人與訪客對話形式的不同，可以將對話形態(tài)劃分為單輪對話、多輪對話，通俗地講即：你想讓機器人如何解決訪客的問題。

2.2.1.1 單輪對話：訪客問一個問題，機器人立即回答

比如：

訪客：“你們培訓(xùn)地點是在哪兒啊？”

BOT：“我們是在海淀區(qū)知春路25號百事大廈13樓”

這類訪客問題中，訪客問的是一個客觀的，不隨訪客信息/其他信息等的不同而不同的回答。即：不論訪客是小明，還是小紅，“培訓(xùn)地點”它永遠都是“海淀區(qū)知春路25號百事大廈13樓”。所以機器人只需要根據(jù)事實（通常將該類知識配置在知識庫中），直接回答即可。

由于其交互是一問一答，在一個對話輪次中即可解決問題，故稱之為“單輪對話”。

2.2.1.2 多輪對話：訪客問一個問題，機器人通過詢問訪客信息，根據(jù)訪客不同的信息作出回答

比如：

訪客：“我可以報六級英語培訓(xùn)班嗎”

BOT：“請問下您通過四級英語考試了嗎？”

訪客：“通過了”

BOT：“嗯好的，您可以報六級英語培訓(xùn)班的，這邊登記下您的信息”

這類訪客問題中，若要進行回復(fù)（無論是機器人/人工），則需確定某些參數(shù)信息才可回復(fù)。“是否通過四級英語考試”，是上述例子中的參數(shù)變量。

“通過”對應(yīng)一個回答；“未通過”則對應(yīng)另一個回答。機器人需要通過詢問訪客這些信息，才能進行回答。所以對話需要進行多輪的交互，一般為“機器人詢問-訪客答”的方式，故稱之為“多輪對話”。

這兩種對話形式，也構(gòu)成了目前對話機器人的對話，是對話的框架基礎(chǔ)。為什么沒有其他類型的對話形式呢？

原因很簡單，因為現(xiàn)有的NLP技術(shù)，在支撐具體業(yè)務(wù)場景下，這兩種對話形式是最有效的。或者換句話說，暫時沒有第三種方式讓機器人更好地服務(wù)訪客。

而對話機器人的設(shè)計，主要在于對話策略的設(shè)計，具體表現(xiàn)在對話流程的邏輯設(shè)計。單輪對話由于其一問一答的形式，基本不需要對話邏輯的設(shè)計，其重點在于知識的構(gòu)建和回答的設(shè)計。所以，對話設(shè)計的重點，在于多輪對話的設(shè)計。

2.2.2 多輪對話設(shè)計

多輪對話的設(shè)計要點：場景、對話流程、信息流轉(zhuǎn)。

2.2.2.1 場景

定義對話場景，行業(yè)內(nèi)機器人的做法主要是通過意圖定義場景。比如：“咨詢Python課程”這個意圖，通過對意圖的解答和服務(wù)，來完成機器人對話。

2.2.2.2 對話流程

這個是對話機器人的核心，包括：對話流程如何運轉(zhuǎn)、異常情況該如何處理、多輪對話與單輪對話的協(xié)作配合。

2.2.2.3 信息流程

對話內(nèi)的信息，是對話的核心要素。所以需要設(shè)計：對話內(nèi)信息如何流轉(zhuǎn)；同時，由于機器人是需要和對話外的系統(tǒng)做信息交流，所以也需設(shè)計對話外信息如何與對話內(nèi)信息進行交互流轉(zhuǎn)。

2.3 核心功能要點

2.3.1 場景識別

場景識別，是對對話場景、用戶意圖的識別。這也是對話中體現(xiàn)AI技術(shù)運用的核心功能。行業(yè)內(nèi)主流的做法，是用意圖來定義，對應(yīng)的AI技術(shù)就是意圖識別，本質(zhì)上是一種分類算法。

比如：“咨詢Python課程”這個意圖，需要提供訪客關(guān)于這個意圖的各式各樣的說法，進行模型訓(xùn)練，從而“教會”模型去識別。所以需提供讓用戶可進行意圖定義、語料定義的功能，讓用戶可進行配置。

通常的做法是：

2.3.1.1 讓用戶構(gòu)建語料

主要有2種方式：

1. 讓用戶自行構(gòu)想創(chuàng)建。但這種方式是及其枯燥和艱難的，因為定義一個意圖，需要幾十條甚至上百、上千條的對話語料（對模型來說，數(shù)據(jù)量越多越好）。對于用戶來說，任務(wù)艱巨且乏味；
2. 抽取人工對話數(shù)據(jù)，通過系統(tǒng)推薦構(gòu)建語料庫。這種方式是在用戶創(chuàng)建數(shù)條語料后，系統(tǒng)根據(jù)相似度，從人工對話數(shù)據(jù)語料中，推薦給用戶。用戶可自行決定添加/不添加，省去了自己憑空想象的枯燥過程。

2.3.1.2 讓用戶構(gòu)建意圖句式

與第一種方式不同，這種方式是讓用戶抽象意圖的各種表達方式，通過一個句式，來涵蓋訪客的說法。句式內(nèi)容可包括：關(guān)鍵詞、正則表達式、實體。通過配置詞順序、匹配度，來構(gòu)建句式，從而實現(xiàn)匹配訪客說法的目的。

值得注意的是，這種構(gòu)建方法，本質(zhì)上是通過“寫規(guī)則”來設(shè)計，與AI的理念實際上是相反的。所以一般作為補充第一種方式使用。

其弊端也很明顯：往往句式寫多了，句式之間可能出現(xiàn)交叉、互斥的情況。而配置的人卻較難發(fā)現(xiàn)與調(diào)整。當(dāng)句式越來越多后，就更難進行調(diào)整，對對話機器人實則是一種隱患。

當(dāng)然，這種方式在機器人冷啟動時相當(dāng)好用，這也是其存在的可能是最大的價值。

除了上述通過意圖來定義用戶場景外，還能通過其他維度進行定義。比如，通過關(guān)鍵詞、實體、正則表達式、變量，來定義用戶場景。

定義的維度越豐富，能支撐的業(yè)務(wù)也就越多，同時對于后續(xù)流程的處理，也就需考慮更為復(fù)雜的情況。所以基于當(dāng)前需解決的業(yè)務(wù)形態(tài)來設(shè)計，至關(guān)重要。

2.3.2 流程邏輯

流程邏輯的構(gòu)建，可以說是對話機器人的骨架。流程決定了對話機器人是否可為訪客提供價值。流程與場景一般是一一對應(yīng)的關(guān)系，通常我們?nèi)粲靡鈭D來定義場景的話，那么每一個意圖，將會對應(yīng)一個對話流程。

還是上述“電腦培訓(xùn)行業(yè)”的機器人，當(dāng)機器人向訪客詢問：“請問你想了解哪方面的培訓(xùn)課程呢？”

• 訪客若說：“我想了解Python課”，那么對應(yīng)意圖識別的結(jié)果為“咨詢Python課程”，于是進入“Python課程”的對話流程；
• 訪客若說：“我想了解JAVA課”，那么對應(yīng)意圖識別的結(jié)果為“咨詢JAVA課程”，于是進入“JAVA課程”的對話流程。

當(dāng)然，訪客也有可能什么都不說，或者壓根就不回答機器人的問題，只顧自己描述自己的問題。這就需要機器人設(shè)計者（AI訓(xùn)練師），構(gòu)建“無意圖”/“通用意圖”，來覆蓋訪客的各種場景，讓機器人應(yīng)對自如。

以下講講流程邏輯功能設(shè)計中的關(guān)鍵要點：當(dāng)你開始設(shè)計對話機器人時，你就會發(fā)現(xiàn)，對話機器人的骨架，其實是一棵對話樹。

除了對訪客問題的識別，通過AI能力進行外，這棵樹幾乎全部是由AI PM/AI訓(xùn)練師，通過定義對話規(guī)則，來構(gòu)成的。這也就是我們說的對話策略。而流程的設(shè)計，即使這棵樹的設(shè)計。

2.3.2.1 流程間邏輯

一個機器人中，必定有多個流程，一般數(shù)量在幾十個，流程間邏輯的設(shè)計尤為重要。

• 流程優(yōu)先級

眾多流程中，當(dāng)訪客的問題，同時滿足多個流程進入條件時，哪一個流程優(yōu)先觸發(fā)？

通常的做法是，讓用戶給意圖/流程做一個優(yōu)先級的排序。如按照編輯順序從上往下，越重要的意圖，用戶可以放在越前面。這是一種對于大多數(shù)場景有效的做法，但是真的就沒問題嗎？

答案是NO，比如：

訪客：“Python課和JAVA課，哪個好學(xué)啊？”

這種情況下，訪客意圖是“咨詢Python課程”，還是“咨詢JAVA課程”呢？

按照我們剛才說的策略，用戶意圖“咨詢Python課程”排在“咨詢JAVA課程”前面，則進入“咨詢Python課程”意圖的流程，反之則對換——這能解決訪客的問題嗎？

這是通過人工預(yù)判的方式，來提前設(shè)定訪客問題的意圖歸屬。而訪客的意圖，可能隨著對話場景、對話語境、自身情況的不同，而存在差異的。簡單來說，就是我們用一種簡單的一刀切的方式，來解決訪客的可能復(fù)雜的意圖問題。這是一種概率押賭的方式，只能解決一大部分問題，而非所有問題。

很遺憾，目前的AI技術(shù)，只到這個能力，還尚未到真正的“人工智能”時代。所以技術(shù)不夠，產(chǎn)品來湊，需要產(chǎn)品經(jīng)理來不足AI不好解決的問題。

我們的做法是，針對這句訪客問題，可用知識圖譜進行答疑（當(dāng)然也可配置FAQ+規(guī)則，但是需要做的排列組合較多，如：Python+JAVA；Python+C語言，等等），同時進入一個“無意圖”的流程。通過進一步詢問來確定訪客的意圖及對應(yīng)的流程。

• 流程間跳轉(zhuǎn)關(guān)系

流程間分為同級流程，與父子流程。

同級流程：同級流程之間的跳轉(zhuǎn)，一般和流程中新意圖的識別有關(guān)。當(dāng)訪客觸發(fā)新的意圖時，即做流程跳轉(zhuǎn)，比如：

訪客：“我想學(xué)Python” —-進入“Python課程”流程

BOT：“可以的，我先了解下您的情況”

…

訪客：“C語言怎么樣啊？”—-跳轉(zhuǎn)至“C語言課程”流程

…

父子流程：子流程的準(zhǔn)入條件，需為先觸發(fā)父流程。二者為并非同級關(guān)系，而是從屬關(guān)系。

比如：在醫(yī)療口腔中，“牙齒美白”與“冷光美白”是父子流程關(guān)系。因為“冷光美白”是“牙齒美白”中的一種方式。

訪客：“你們能做牙齒美白嗎？” —-進入“牙齒美白”流程

BOT：“可以的，我先了解下您的情況”

…

訪客：“冷光的你們有沒有啊？”—-跳轉(zhuǎn)至“冷光美白”流程

…

一般而言，進入子流程后，將不再返回至父流程。因為子流程是更細的場景，對話機器人的服務(wù)原則是，進入更細的場景，即能提供更有針對性的服務(wù)。

• 流程執(zhí)行唯一性

同級流程中，當(dāng)流程執(zhí)行后，訪客問題再次出發(fā)了該流程，是否可再次進入呢？

這個問題其實根據(jù)不同的行業(yè)與業(yè)務(wù)場景，策略的選擇是不一樣的。通常來講，對于售后服務(wù)等來說，重復(fù)進入同一個流程，要求是較低的。

同時由于詞槽收集可避免重復(fù)發(fā)問，所以可接受再次進入流程；而售前引導(dǎo)性的場景，就較為幾回再次進入同一流程，因為這樣往往會讓機器人看著更加“不智能”，降低訪客對服務(wù)的信任感，所以一般是不能再次進入的。

但是無論如何，這個問題都是在對話機器人中，流程邏輯設(shè)計中應(yīng)考慮的要素。

2.3.2.2 流程內(nèi)邏輯

流程內(nèi)的邏輯，指的是當(dāng)訪客進入某流程時，機器人的應(yīng)答策略。

• 流程準(zhǔn)入條件

前面說了，流程一般的準(zhǔn)入條件為意圖。但一些較復(fù)雜的場景，除了意圖外，我們還可以用關(guān)鍵詞、正則表達式、實體、變量來定義訪客的場景，作為流程準(zhǔn)入的條件。

流程準(zhǔn)入條件，可以看成是流程的大門：條件定義得寬泛，則門越大，進入流程的訪客問題類別更少，在流程中需處理的情況就越多；條件定義得苛刻，則門越窄，進入流程的訪客問題類別越少，在流程中需處理的情況就越少。但是同時，需定義的流程數(shù)量也更多。

• 流程進展

流程進展是對話處理的關(guān)鍵。簡單來說就是，機器人如何發(fā)問？當(dāng)機器人發(fā)問后，訪客的各種回復(fù)情況，怎么處理？

a. 機器人如何發(fā)問？

a）發(fā)問內(nèi)容

發(fā)問內(nèi)容與當(dāng)前意圖下，機器人需獲取的信息相關(guān)。通常為設(shè)計者設(shè)計的固定詢問話術(shù)，進行發(fā)問。

這里順便提到AI技術(shù)：NLG，即對話生成。可通過AI通過對話場景，生成相應(yīng)的話術(shù)內(nèi)容。但從實際效果來看，目前的NLG尚未達到業(yè)務(wù)對話要求，固定的話術(shù)效果會更好。

b）發(fā)問順序

發(fā)問順序通常是固定的預(yù)設(shè)順序。通常設(shè)計者會根據(jù)用戶場景，設(shè)計某個意圖下，機器人發(fā)問的具體順序。當(dāng)然，在發(fā)問之前，若機器人已收集到相應(yīng)信息，可做跳過處理。

b. 訪客回復(fù)后，機器人如何處理？

訪客回復(fù)后的處理，是對話流程往下進行的必要條件。機器人發(fā)問后，訪客的回應(yīng)可能有幾種情況：

a）提供了機器人發(fā)問的信息

情況1：提供了單一信息，比如：

BOT：“你想咨詢什么課程呢？”

訪客：“Python課”

這種情況是最理想的情況。我們只需要設(shè)定不同信息下對應(yīng)不同的對話分支走向即可，對話樹也即順利進行下去。

情況1：提供了多信息

BOT：“你想咨詢什么課程呢？”

訪客：“Python和JAVA的課程我都考慮”

這種情況中，AI算法會從訪客的回復(fù)中提取“Python”和“JAVA”兩個信息，并且并不知道訪客到底是想要哪個。這種情況就需要做特殊處理，有幾種常見的處理方式：

• 隨機選取一個信息，進行后續(xù)對話分支的執(zhí)行；
• 構(gòu)建句式，選取其中一個信息，作為分支執(zhí)行的條件；
• 進入除預(yù)設(shè)分支外的默認/其他分支，執(zhí)行后續(xù)的動作。

具體適用哪種策略，也需根據(jù)不同機器人而設(shè)計。

b) 訪客回復(fù)，但未提供機器人發(fā)問的信息

情況1：訪客的回復(fù)內(nèi)容，未在預(yù)設(shè)的對話分支中，比如：

BOT：“你想咨詢電腦培訓(xùn)的什么課程呢？”

訪客：“我想咨詢畫畫的班”

這種情況下，一般設(shè)計者也較難預(yù)知這種訪客的回復(fù)，一般會讓對話走“默認/其他”分支流程，以便讓對話繼續(xù)。當(dāng)然，事后發(fā)現(xiàn)了問題，也可以通過補充對話分支的方式，來擴充機器人應(yīng)答能力。

情況2：訪客的回復(fù)內(nèi)容，新起了一個話題，比如：

訪客：“我想咨詢下Python課程”

BOT：“好的。請問您是什么學(xué)歷呢？”

訪客：“對了，你們的JAVA課怎么樣啊？”

這種情況，訪客已經(jīng)新起了個話題“JAVA課”，對話可以進入“JAVA課”的意圖流程中。當(dāng)然，也可以不進入，這就涉及到“新流程優(yōu)先”還是流程內(nèi)“分支優(yōu)先”的問題。

一般而言，對于場景較為垂類，較無多話題交叉的對話，使用“分支優(yōu)先”是更優(yōu)的選擇；而對于對話中較長有多話題交叉的對話，使用“新流程優(yōu)先”效果會更好一些。這也是策略的選擇，通過概率大小決定應(yīng)答策略。

c) 訪客不回復(fù)

當(dāng)機器人發(fā)問后，訪客不回復(fù)。有可能是訪客離開了對話，也有可能是訪客切換了應(yīng)用程序（常見于手機中）。訪客若不提供相關(guān)的信息，對話不好進行下去。

處理的方式有：間隔一段時間（如幾十秒）后，機器人再次發(fā)問（話術(shù)可有所變化），以獲得相應(yīng)信息；或是靜默等待，若訪客依然不回復(fù)，則自動填入信息默認值，執(zhí)行下一步對話動作。

• 流程打斷處理

在機器人發(fā)問-訪客回復(fù)的多輪對話 交互中，我們預(yù)想的是訪客會按照我們預(yù)設(shè)的對話節(jié)奏進行。但是實際過程中，訪客并不在意機器人是按照什么規(guī)則、什么節(jié)奏進行對話的，所以會出現(xiàn)當(dāng)機器人正在應(yīng)答，訪客進行打斷的情況（特別是在語音機器人的場景中）。

一般的處理方式是：被打斷后，機器人暫停回復(fù)，等待訪客表述完。被打斷的流程，若進入了新的流程，一般會等新流程執(zhí)行結(jié)束后，再次回到原有流程。這個可根據(jù)不同的流程而設(shè)定“打斷后恢復(fù)”的設(shè)置。

2.3.3 信息流轉(zhuǎn)

前文講了，對話中的信息流轉(zhuǎn)，是對話的重要屬性，信息流轉(zhuǎn)分為對話內(nèi)與對話外的信息流轉(zhuǎn)。

2.3.3.1 對話內(nèi)信息流轉(zhuǎn)

即通過獲取訪客信息，做信息的記錄、傳遞、更新與使用。其中，有兩個要素是最重要的：

• 實體：實體是系統(tǒng)獲取訪客信息的來源。可以通過AI的實體識別能力，也可通過定義關(guān)鍵詞庫的方式進行識別，這是信息獲取的源頭；
• 變量（詞槽）：通過實體識別獲取了訪客信息后，需要存在一個載體中，這個載體就是變量（詞槽）。變量就像人體血液中的紅細胞一樣，獲取、運輸、更新對話信息，并把信息給對話的中控系統(tǒng)使用。可作為條件判斷的依據(jù)，也可作為話術(shù)的內(nèi)容。

2.3.3.2 對話外信息流轉(zhuǎn)

在對話機器人中，對話信息不僅在對話中流轉(zhuǎn)，也可跟對話外部的系統(tǒng)做信息的交互，比如：

訪客：“幫我查一下明天的天氣”

BOT：“好的。明天北京天氣晴，氣溫15-23攝氏度。”

對話機器人需要通過外部系統(tǒng)（查天氣系統(tǒng)），才能獲取具體的天氣信息。其中，通過將具體的日期、地點信息傳遞給查天氣系統(tǒng)，獲取相應(yīng)的天氣信息，這就是對話外信息流轉(zhuǎn)。

一般會設(shè)置接口調(diào)用的方式，通過設(shè)定接口和參數(shù)，與對話 機器人外的系統(tǒng)做信息交互。從而實現(xiàn)各種對話機器人技能的落地，如：查天氣、訂火車票、開電視、打開音樂等等

2.3.4 流程與知識庫協(xié)作

如果說流程是整個對話機器人的骨架，那么知識庫就如同機器人的血肉，因為機器人做答疑的一大部分內(nèi)容，是通過知識庫進行的。而流程與知識庫需通過寫作配合，才能讓對話機器人在解答訪客問題的同時，又讓對話順利無縫地進展，從而最終達到對話目的。

流程與知識庫協(xié)作的策略，主要有以下2種：

1. 訪客發(fā)送的每條信息，先使用知識庫做解答，后執(zhí)行流程的動作與話術(shù)：該策略適用于“解答型服務(wù)”的對話。即：盡量解答訪客的每個問題，即使機器人的對話顯得啰嗦，也可接受。
2. 當(dāng)訪客回復(fù)未在預(yù)設(shè)的對話分支中時，才使用知識庫做解答

該策略適用于“引導(dǎo)性服務(wù)”的對話，對話重點在于讓對話引導(dǎo)的體驗更加，而不在于解答訪客的每個問題。兩種策略均各有利弊，側(cè)重點不同，提供的服務(wù)體驗也不同，可根據(jù)具體情況而確定。

三、總結(jié)

對話機器人產(chǎn)品，鑒于現(xiàn)有的AI技術(shù)，可以說有一大部分是需要AI PM做規(guī)則設(shè)計、策略設(shè)計的。

設(shè)計思路可概括為：用判斷概率的方式，選擇其對話策略。所以對話中有大量的邏輯設(shè)計、策略選擇，根據(jù)對話機器人所處的行業(yè)領(lǐng)域與用戶場景，做不同的取舍和側(cè)重點設(shè)計。

本文主要概述了對話機器人的設(shè)計要點，但有些要點中，又有其豐富的設(shè)計理念和實操細節(jié)，本文不在此方面贅述。后續(xù)會針對重點要素做詳細講解，希望對你有幫助。

作者：咖喱魚丸，5年P(guān)M經(jīng)驗，2年AI PM經(jīng)驗

本文由 @咖喱魚蛋egg 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議

標(biāo)簽：社區(qū)回訪 物流行業(yè) 呼和浩特 通遼 徐州