• 技術基礎：智能外呼機器人核心是AI的基礎技術，賦予產品識別語音、語義理解、合成語音的能力，簡單來說就是如何準的確地識別客戶所表達的意思，一般稱作識別意圖。而另一方面，Fs、sip構建的話務服務賦予產品對外通話的能力，可以撥通客戶的手機進行交流。
• 資源許可：構建的機器人服務需要耗費一定的資源，一般將整個過程分為話務、TTS、ASR、機器人方面的資源。如果要完成完整的外呼服務，一般是1:1的關系。如果是saas產品，可以將整個許可打包成一個商品出售。按這樣區分可以清晰劃分產品框架，后續的運維、擴容也十分方便，也利于計算成本、產品定價。
• 話務模塊：話務模塊是管理話務能力方面的功能，語音通訊、錄音等。
• 語音服務：該模塊是管理語音方面的能力，包括ASR服務、TTS服務。也會有一些產品將這些能力納入話務模塊。
• 算法模塊：算法模塊是外呼機器人的核心能力，需要完成數據的處理、模型的構建與訓練等，讓機器人具備識別能力。
• 對話管理：機器人識別客戶的意圖之后，需要做出一定的回應。怎么說、說什么由對話管理去控制。
• 運營管理：基于上述模塊的協作完成一個外呼服務的構建，對于業務人員來說則需要在運營層面去管理外呼名單、外呼策略等，讓機器人運轉起來。

對產品有全局的架構思維，有助于全面地看待問題，無論是產品設計還是后續的運營都是很有幫助的。

二、業務流程

智能外呼，簡單來說就是模擬人的對話能力，教會機器人去識別語音內容，然后根據內容做出應答。在運營管理發起外呼動作，整體的業務流會經過以下幾個步驟：

1.由話務服務出局通話請求，撥通客戶的電話后，收集客戶語音并實時返回至語音服務模塊；

2.語音服務將客戶的語音經過ASR處理，輸出客戶的文本給到算法模塊；

3.算法模塊經過算法分析，識別客戶的意圖，了解客戶想表達的意思。有一點需要注意的是，不一定非要語音才能分析意圖，比如客戶靜默太長時間，可輸出一個靜默的意圖，讓機器人再次喚醒客戶對答。也不一定是對文本內容直接分析，比如機器人未播完話術時被客戶打斷，這時候應該輸出一個打斷的意圖，停止播報，讓客戶說完再識別。各種各樣的情景，跟人與人之間的對話情景對應；

4.得到客戶的意圖后，對話控制根據對話流程，輸出機器人需要對答的內容。對答文本流轉至TTS合成語音（如果文本不涉及變量，可以一次性保存為錄音，不占用TTS資源），或者調用已錄好的音頻，傳至話務服務模塊，對客戶輸出語音。然后再次得到客戶語音，循環這個過程直至結束后將對話數據返給外呼管理模塊，進行后續的分析。

三、產品設計

1. 話務服務模塊

依托于FS強大的拓展性，搭建一個電話軟交換平臺，可對接運營商的sip線路，也可用網關設備搭建話務中心，提供呼叫控制、資源分配、錄音、計費等能力。一般大企業會有獨立的話務服務，專供需要的業務系統接入，而自建外呼服務或者構建saas產品則需要從0到1去搭建了。

2. 語音服務模塊

ASR、TTS是基礎底層技術，自研成本非常高，而且經過長期的發展也很成熟，市面上有科大、阿里云、騰訊云等廠商的服務。一般有兩種模式，一種是接入云服務，按調用次數收費，如果有開放的開發環境建議使用這種模式，可以隨時升級調優。另外一種是買斷服務，購買完整的語音服務，包括模型、資源，一般在較為封閉的開發環境使用，比如銀行業務。但這種模式成本較大，而且調試升級不方便。

3. 對話管理

對話管理是智能外呼機器人產品的核心模塊，涉及VUI設計、話術管理等。VUI設計是指語音交互流程，就是機器人的應答邏輯，是機器人的主心骨。我對于VUI的設計主要有以下幾個步驟：

1）梳理外呼業務的主流程

產品必定會有一個流程，以期望客戶按我們的設計走，完成一定的動作，達到業務目標。所以在設計前應當梳理清楚我們要做的是什么業務，業務涉及什么環節，業務目標又是什么。以一個信用卡欠款催收為例：

2）歸納意圖

在業務運轉過程找中，會遇到哪些情況，然后歸類起來，形成一個意圖，代表客戶反饋給機器人的狀態?？蓪⒁鈭D分為三種類別：通用意圖、業務意圖、QA。

• 通用意圖：顧名思義就是整個人機對話環節都可能會發生的情況。咱們可以想想現實中打電話，對方可能會正在忙沒法接電話，可能信號不好聽不清等等，可以歸納出“正忙、聽不清”的意圖；
• 業務意圖：與業務相關的情況，比如客戶表示是不是本人、已還清欠款等情況，可歸納出“是本人、非本人、已還款”的意圖；
• QA：通用意圖以及業務意圖是固定的，在實際運營中會有些頻率不高或者未想到的語料，可以在線上添加QA語料，然后在后臺經過關鍵詞提取、預定訓練方式實現模型建設，可減少算法投入成本，也比較靈活。如果某個QA出現頻率高，可以考慮增加一個通用意圖或者業務意圖。

確定意圖后，有助于我們梳理流程框架：

3）編寫對話劇本

確定了環節、意圖后，還是比較零散的信息，典型的對話場景是怎么樣的？實際的對話流又是怎么體現的？這時候可以借助對話劇本去模擬人機對話。如果客戶按推薦的流程走，并完成了目標，稱之為愉悅路徑。如果客戶沒有按推薦的流程走，無法完成外呼目標，則成為非愉悅路徑。

舉個例子：

編寫對話劇本其實就是梳理主流程、異常分支如何處理，尤其是非愉悅路徑，通話環境的情況很復雜，各種不在目標內的情況要做好處理。

4）設計對話跳轉邏輯

經過對話劇本的編寫，VUI有了雛形，接下來需要整合成一個完整的流程。對于VUI，我理解為一個龐大的決策樹，在某個節點，根據客戶的反饋決定往哪個分支走，主體設計是環節+意圖+跳轉。

對話的跳轉邏輯設計是個十分復雜的過程，需要反復推敲跳轉是否合理，是否符合業務場景，是否覆蓋了常見的情況。從開場白到完成業務目標會有多種分支，而且有時候跳轉較多，單純看路徑會比較抽象，可以借助對話劇本具象化。另外建議設置好結束點，路徑設計不宜過長，機器人沒法像人這么靈活，對話輪次過多反而會阻礙業務目標的達成。如果某個意圖出現頻率高，而且處理方式是一致的，可以提煉出來作為一個全局節點。

5）設計話術

確定了對話跳轉邏輯后，需要明確每個節點機器人的應答話術。話術內容的設計也很考究，基本原則是通用化、封閉化。應答內容盡量通用化，往主流程引導，兜住未知的情景，復雜的內容引導客戶去確認。雖然AI大大提升了效率，但是還沒有達到可以處理全部開放化的情景，比較適合做標準化的工作。舉個例子，你想確認客戶的地址是否正確，不應該去問”請問您所在的地級市是哪里“，答案千千萬萬，而且asr識別不準，可行性可想而知，倒不如改為”請問您是在xxx地方嗎？“，這樣范圍可控。

參照對話跳轉邏輯設計每個節點話術，包括環節+客戶意圖+機器人話術+跳轉節點:

經過5個步驟的思考以及設計，對話管理模塊的功能已完成，產品展示層面比較多的是畫布的模式，可以自由組合各個環節、節點以及話術。但VUI設計是復雜性的功能，不建議普通客戶去操作，交由專業人員管理，或者采用模板的方式推廣。

4. 算法模塊

VUI里面涉及的意圖是由算法分析出來的，建議在意圖設計的環節也保持與算法的同事溝通。算法模型是核心資產，也是產品護城河。目前市面上會有廠商提供NLP服務，但作為核心能力，建議采用自研，契合自身業務去構建算法能力。智能產品需要眾多的語料去完善其模型，即使產品上線后也需要不斷去調優，一套完整的算法優化流程尤為重要。

作為產品經理，重點關注其中的標注結果，核對分類是否正確、是否存在與產品設計違背的地方、是否可以達到可用的效果，這樣可以減少效果與最終目標的不適應情況。另外還有需要關注模型校驗的結果是否符合預期，生產對客的效果如何。

雖然AI技術很強大，但也不是無敵，也要看與各個技術的配合度以及局限性。語音機器人特別依賴ASR的準確率，曾經踩過一個坑，詢問客戶的所在地，以判斷是否可辦理金融業務，但ASR對短句的轉譯能力差，無法精準轉寫，導致識別準確率很低，效果很不理想。如果前期關注到ASR的局限性，就很有可能會規避這個問題。

算法能力的構建涉及多個角色、多個流程以及持續性優化，如果業務比較成熟，可以搭建一套運營后臺系統去支撐這部分工作，發現熱點知識、拒識等內容，實行標注質檢工作等。

5. 運營管理

經過各個模塊的搭建，已經具備了機器人外呼能力、識別能力、對答能力，運營管理模塊就負責如何使用機器人，根據業務需要設計各種外呼策略，比如重撥、定時外呼、防騷擾等。

四、結語

智能外呼機器人是AI落地較為廣泛的產品，涉及了多個領域的知識，也需要多種角色參與，因此需要掌握的東西比較多，很考驗產品的整合能力。同時也是十分重運營的產品，不是搭建完成就完事了。如果功能建設完成了，我認為只是從0到0.5，要達到真正的對客效果，還需要持續優化，采集更多的語料去豐富意圖、提升識別效果等。

以上為本人的一點經驗之談，歡迎大家一起交流。