• 技術基礎：智能外呼機器人核心是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）歸納意圖

在業務運轉過程找中，會遇到哪些情況，然後歸類起來，形成一個意圖，代表客戶反饋給機器人的狀态。可将意圖分為三種類别：通用意圖、業務意圖、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，要達到真正的對客效果，還需要持續優化，采集更多的語料去豐富意圖、提升識别效果等。

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!