如何從零開始搭建智能外呼系統(tǒng)？

一、序言

隨著人工智能技術的發(fā)展，近半年來涌現(xiàn)了大量基于人工智能的呼叫中心業(yè)務服務商和集成商。僅電銷機器人這一個方向就少有近百家公司正在推廣運營，包括奇高，嘉舜等。商務上的需求非常強烈，整個市場都飛快地熱鬧起來。

一套可提供saas服務的智能外呼系統(tǒng)，看起來功能并不復雜。一個網(wǎng)站可注冊、充值繳費開票，登錄后在后臺頁面選擇或者定制外呼話術腳本，新建外呼任務并導入外呼號碼列表，明確外呼策略（時間段、重呼次數(shù)），設置外呼機器人數(shù)量（同時撥出幾個號碼），點擊開始。然后就可以看著進度條走完，外呼機器人按照列表一個個打電話出去。任務完成后，可以查看外呼結果列表。

那么如何從零開始搭建一套對外可以提供saas服務的智能外呼系統(tǒng)呢？

二、總覽

我們先列出，搭建這樣一整套系統(tǒng)需要哪些技術和資源：

• 運營商線路：提供方包括三大運營商、集成線路商，這是我們打電話出去要交電話費，必須涉及的供應商。

• 呼叫中心設備：商用設備原廠包括avaya、genesys、cisco、華為等，集成商很多，開源的也有一些。在發(fā)起外呼任務時，saas平臺是把外呼請求發(fā)給了呼叫中心設備經(jīng)由運營商線路而撥出去的。

• AI能力：包含語音識別、語音合成、語義理解。這就是外呼機器人的核心組成部分，它能聽懂接電話的人所說的話、表達的意思，并回復和引導對話。

• saas服務平臺：即用戶可以注冊、登錄、繳費、上傳呼叫列表、發(fā)起外呼任務、外呼結果查看的網(wǎng)站，這個是終端用戶可以看得到的前端界面。

 

四個主要模塊，其中一些難以自研，只能選擇供應商：

1. AI能力部分（中文ASR/TTS）基本已經(jīng)格局穩(wěn)定，沒太多可挑選的。

2. 運營商資源這塊兒，可以選擇老廠的碼號線路資源多的然后便宜的去談合作，一方面外呼應用在催收場景時容易被封號，同時話費再便宜也好幾分錢一分鐘，也是重要的成本。

3. 呼叫中心設備，因為涉及不少接口對接調試，優(yōu)先選自己熟悉的，其次選便宜的且技術資料多的。

4. 是外呼saas平臺，可能這是各個電銷機器人服務商/集成商容易實現(xiàn)自研的部分。

明確了涉及到的技術和資源之后，再明確一下建設步驟。由于各個廠商都有各自的資源和能力，建設方式也各不相同，簡單來說可以分成以下幾類：

1. 有運營商資源的，等著別人找上門來就行了。

2. 呼叫中心廠商，必然有已長期合作的運營商線路資源，手里也有呼叫中心設備+職場，也有技術人員。于是就選擇自研saas平臺，然后找AI能力廠商合作提供ASR/TTS/NLU。

3. AI能力廠商，尤其以NLU起家的在線客服類廠商，通常會選擇嘉舜的語音能力，然后去找呼叫中心類廠商合作。

4. 啥都沒有，只有幾個技術人員的，選擇自研saas平臺，接入呼叫中心設備、AI能力、運營商資源。

作為初學者，為了自行從零開始搭建一套對外可以提供saas服務的智能外呼系統(tǒng)，身份必然是第四種，啥都沒有，啥都要干。

以上這四部分，核心角色是呼叫中心。AI只是插上了想象力的翅膀，但是沒這翅膀，呼叫中心還是呼叫中心，但是AI就只是空中樓閣了。業(yè)務明確可落地的呼叫中心才是想象力的基石，這一點與CV和安防的關系很像。

三、呼叫中心搭建

1. 通信原理

目前對呼叫中心比較普遍接受的定義是：呼叫中心是以計算機電話集成（CTI）技術系統(tǒng)為基礎，將計算機的信息處理功能、數(shù)字程控交換機的電話接入和智能分配、自動語音處理技術、 Internet技術、網(wǎng)絡通信技術、商業(yè)智能技術與業(yè)務系統(tǒng)緊密結合在一起，將公司的通信系統(tǒng)、計算機處理系統(tǒng)、人工業(yè)務代表、信息等資源整合成統(tǒng)一、的服務工作平臺 。

一代呼叫中心架構NGCC（Next Generation Call Center）如下圖所示：

具體如何理解呢？

先從簡單的說起：個人A給個人B打了個電話。

• 流程：A→PSTN→B

• 解釋：PSTN是Public Switched Telephone Network，公共交換電話網(wǎng)絡，也就是運營商的電話網(wǎng)絡。

然后來個復雜點的：個人A給呼叫中心400xxxxxxxx打了個電話，撥通后先聽到了錄音，“您好，找B類接線員說話請按0號鍵”。按了0，然后聽到錄音，“排隊中，請稍后”。幾分鐘后接通，B0026號接線員接了電話。

流程：A→PSTN→PBX→IVR→ACD→B

解釋：PBX是Private Branch Exchange，用戶級交換機，這是企業(yè)內(nèi)部的局端用戶級交換機，整個呼叫中心的出入口設備。

PSTN到PBX之間是中繼（分成模擬中繼、數(shù)字中繼、IP中繼），這是將通訊公司的局端交換機與企業(yè)內(nèi)部的用戶級交換機（PBX）相連的通訊線路。

IVR是Interactive Voice Response，互動/交互式語音應答，我們把它叫語音導航。實現(xiàn)的是類似撥打10086后聽到錄音說，xx業(yè)務請按x，這個環(huán)節(jié)。主要用途是根據(jù)業(yè)務分流來電，進入對應的排隊機。

ACD是Automatic Call Distribution，自動電話分配，也叫排隊機。

再來個復雜點的：個人A給呼叫中心400xxxxxxxx打了個電話，撥通后先聽到了錄音，“您好，您想找哪類接線員？”

個人A說，“B~~”。

然后很快接通，“您好，這是B0026號機器人，有什么可以幫您？”

個人A說，“我不想跟機器人說話，泥奏凱~”

然后聽到錄音，“為您轉接很貴的真人客服，排隊中，請稍后”。

幾分鐘后接通，B1026號真人接線員接了電話。

流程：A→PSTN→PBX→IVR（→ASR→NLU）→ACD（→ASR→NLU→DM→NLG→TTS）→ACD→B

解釋：現(xiàn)在智能的部分，也就是我們說的語音機器人的部分，分別在IVR和虛擬坐席處體現(xiàn)。

IVR部分，不再需要提示按鍵，而是直接問來電方需要辦理什么業(yè)務，然后識別語音、理解意圖后，進入對應的業(yè)務隊列排隊。排隊后可以等待真人客服接待，也可以由機器人先行接待。

機器人（實際是服務器資源）資源空閑時，直接接待，進行語音對話，對話過程就是語音識別、語義理解、語音合成的多次調用，部分業(yè)務涉及業(yè)務數(shù)據(jù)接口對接調用，比如查詢話費、積分。并可以根據(jù)需求自動或者選擇轉人工，再次進入排隊，等候真人客服接待。

其中IVR部分示意圖如下：

 

2. 集成實施

 

上面提到的全部流程中，PBX、IVR、ACD等部分基本都是由我們說的呼叫中心設備商提供，產(chǎn)品有三種類型:板卡式、交換機式、VoIP形式。

交換機式比較適合大型職場，例如三五百人以上，硬件價格五位數(shù)。交換機領域，主要有：avaya、genesys、cisco、華為、中興，其中常用的兩家對比下來，avaya比genesys便宜（參見文章）。

板卡式適合中小型職場，比如幾十人到兩三百人，硬件價格四位數(shù)?；诎蹇ńㄔO呼叫中心的步驟，可以參考使用三匯板卡的這幾篇（主要前4篇講原理）。

選擇板卡之前，先要確定選用哪種中繼線路，比如：使用常規(guī)的數(shù)字中繼，那么就需要選擇數(shù)字板卡，這個找板卡的供應商問就行了。通常來說呼叫中心要購買的一條E1數(shù)字中繼報價五位數(shù)/年，由用戶級交換機將局端的光信號轉換為30路模擬信號，也就是支持30個人同時接打電話，通話費會另外按照實際呼出分鐘數(shù)收取。

近期一個實際落地項目是選擇了數(shù)字中繼+Asterisk（開源VoIP PBX純軟方案），（可參考：安裝配置，調試）示意圖如下：

具體的軟件業(yè)務細節(jié)，比如：常規(guī)客服中心需要的管理模塊、配置模塊、工單服務、坐席服務、報表模塊、CRM，還有比如：坐席班長監(jiān)聽、通話插入、質檢，錄音文件管理等整套軟件細節(jié)，不做詳述。

四、AI能力對接

在具體落地中，這個領域的常規(guī)參與者通常具備呼叫中心能力或者AI能力其中一種，而主要的對接點也就在于AI能力與呼叫中心設備去對接，而ASR/TTS與呼叫中心設備對接的常規(guī)協(xié)議主要是mrcp/sip。

媒體資源控制協(xié)議（Media Resource Control Protocol, MRCP）是一種通訊協(xié)議，用于語音服務器向客戶端提供各種語音服務(如語音識別和語音合成)。有兩個版本的MRCP協(xié)議，版本2使用SIP作為控制協(xié)議，版本1使用RTSP。

實際對接的時候，會遇到不少技術問題，有的呼叫中心廠商會要求ASR/TTS引擎做私有云部署，這樣避免了內(nèi)外網(wǎng)穿透時防火墻的諸多設置和語音流的時延。這對基于語義起家（并購買語音能力）的公司是一個小小的難題。

1. 語音識別

現(xiàn)有技術中實現(xiàn)一次性語音識別典型的流程時序，具體包括一下步驟：

•  MRCP Client發(fā)送INVITE消息給MRCP Server請求建立會話，攜帶MRCP Client側的SDP；

• MRCP Server回復200表示請求已經(jīng)成功接受處理，攜帶MRCP Server側的SDP；

• MRCP Client隨后發(fā)送ACK消息證實200消息已經(jīng)收到，此一個SIP會話成功建立；

• MRCP Client發(fā)送RECOGNIZE消息給MRCP Server請求語音識別，按照MRCP協(xié)議規(guī)定的格式攜帶相關的語音識別控制參數(shù)，并且指定語法文件路徑；

• MRCP Server接收RECOGNIZE請求，編譯語法文件，回復200消息給MRCP Client；

• MRCP Client此時開始根據(jù)之前協(xié)商好的SDP，開始源源不斷的發(fā)送RTP語音流給MRCP Server；

• MRCP Server接收RTP語音流，當檢測到用戶開始說話時，發(fā)送START-OF-INPUT事件；

• 當MRCP Server根據(jù)語法文件定義得到識別結果時，通過RECOGNITION-COMPLETE事件返回識別結果；

• MRCP Client發(fā)送BYE消息給MRCP Server結束會話；

• MRCP Server發(fā)送200消息給MRCP Client確認結束；

• MRCP Client通過上述流程獲得MRCP Server提供的一次完整語音識別能力。

電話渠道的語音流采樣率一般是8k 16bit，這種語音識別的準確率遠遠低于app等渠道采集音頻的識別率。再加上人在打電話時說話方式相對隨意，導致語音識別部分成為了影響電話機器人能力和效果的重要瓶頸。

2. 語音合成

實現(xiàn)語音合成典型的流程時序，具體包括一下部分：

• SPEAK:向服務器端提供文本,啟動語音合成（c→s）。

• STOP:如果服務器正在語音合成資源,則停止語音合成與語音流（c→s）。

• PAUSE:通知服務器資源暫停語音合成與語音流（c→s）。

• RESUME:通知暫停的語音合成資源繼續(xù)進行語音合成與語音流（c→s）。

• CONTROL:更改語音合成資源相關參數(shù),從而影響合成的語音流（c→s）。

• SPEAK-COMPLETE: SPEAK請求已經(jīng)成功處理（s→c）。

• SPEECH-MARKER:服務器正在處理語音標簽時,遇到請求消息頭字段 Speech Marker中標記的tag（s→c）。

• BARGE-IN-OCCURRED:客戶端檢測到barg-in-able事件或DTMF數(shù)字時,發(fā)送該消息通知服務器（c→s）。

現(xiàn)在主流廠商為了使通話效果盡可能模擬真人外呼，除了涉及業(yè)務接口調用的數(shù)據(jù)查詢使用了TTS，基本采取整句錄音的方式。

3. NLU部分

準確來說，一個簡單的對話機器人系統(tǒng)框圖，包括語音識別（ASR）、語音合成（TTS）、自然語言理解（NLU）、對話管理（DM）、自然語言生成（NLG）幾個模塊組成。而這一部分就是智能外呼系統(tǒng)的主流玩家——NLU類（智能客服）廠商的強項了。

對于呼叫中心從業(yè)者來說，ASR/TTS/NLU如同黑盒一般，只暴露出接口。而國內(nèi)語音能力的供應商，要么很土豪，少量QPS不要錢，要么就是非常標準的報價五位數(shù)一條線路/年，實在也沒有太多可以選擇的余地。

對于只有NLU能力的廠商來說局面也是一樣，除了需要接入ASR/TTS的能力，還需要去尋找可以合作的呼叫中心，并且想辦法拿到盡可能低的話費報價。

五、行業(yè)現(xiàn)狀

經(jīng)過一些調研和競品分析，行業(yè)內(nèi)雖然有少近百家公司在推廣和運營電銷機器人，但毫不客氣地說，大部分都不及格。

一 ★

• 官網(wǎng)粗制濫造，類似有漂浮閃動flash，反復頻繁提示你聯(lián)系商務。

• 對各類基礎能力只有含糊其辭的描述，沒有錄音、演示、試用途徑。

二 ★★

有錄音可以試聽，但明顯可以聽出來，部分是真人直接對話錄音，而并非機器人與真人的通話錄音。部分若干家公司用于試聽播放的錄音文件完全一致，不知道誰抄誰的。

三 ★★★

• 有錄音可以試聽，甚也有演示視頻。錄音可能仍有作假嫌疑，演示視頻部分能感覺出來是按照特定的對話腳本去走流程，但是可以完成多輪對話了，語音時延在2s以內(nèi)，屬于基本可用。

• 不支持NLG，機器人所說的內(nèi)容均為錄音。

四 ★★★★

• 支持NLG（Natural Language Generation），支持字段調用，支持TTS合成與錄音無縫銜接。但由于TTS調用的是某幾個大廠的api，而錄音多數(shù)為自己根據(jù)業(yè)務需求去錄的，會出現(xiàn)銜接生硬的問題。方案是直接全文TTS，或者選擇與TTS音色相接近的播音員進行錄制。

• 對打斷的處理有待優(yōu)化，要么不支持打斷，要么打斷后處理方式粗糙（如重播、多次打斷后多次直接播放對應錄音）。

• 語義理解能力相對較弱，但配合相對完善的話術策略，可以保持相對可接受的兜底。

五 ★★★★★

• 支持對話中識別關鍵詞打斷。如介紹推銷信息時被打斷問價格，則直接停下并立刻回復價格信息。

• 報價模式不局限于“線路xxxxx元/年，話費0.xx元/分，話術腳本xxxx/個”的模式。如純錄音外呼機器人0.xx元/分，含NLG的外呼機器人x.xx元/分。

• 除了根據(jù)業(yè)務場景定制話術腳本之外，基于已有的積累（如呼叫中心電銷的通話記錄等）形成特定行業(yè)的話術模板，只需要填入特殊字段信息即可使用。

• 語義層面，支持跨節(jié)點/返回節(jié)點問答（比如：先回答說我不是本人，進入到下一個節(jié)點后，客戶再說一次我是本人，系統(tǒng)仍能處理）。

• 外呼結果分析，目前階段通常機器人外呼只用來做輪初篩，需要對通話內(nèi)容進行語義判斷，按需分析是否需要第二輪人工跟進。

• 通話中轉人工，是否允許在機器人外呼過程中被動或主動轉人工，這一項在實現(xiàn)時接近于IVR部分機器人應答+轉人工的模式，在流程設計和資源配置上相對有難度。

• 根據(jù)通話內(nèi)容自動判別二次回撥，如被告知“現(xiàn)在沒空接電話，10分鐘后再給我打”（機器人二次呼叫），或者表示“有興趣，需轉人工跟進”后經(jīng)由預測式外呼后回撥到用戶號碼上（真人接線）。

六、商業(yè)落地

商務模式比較簡單粗暴，粗略的成本核算如下：

• 運營商的通訊資源，幾分錢一分鐘的話費成本，以及平均下來一千左右一路的中繼線路費用。

• 其次是呼叫中心廠商的服務器、帶寬、呼叫中心設備license/運維等成本。

• 再次是AI能力的使用費，比如：嘉舜公開報價2w每線路每年。

• 是外呼saas平臺的建設和運維成本。

那么電銷機器人廠商，競爭這么激烈，誰才會笑到呢？

一是要有價格相對低廉的運營商資源和語音能力資源，這樣可以明確的報出一個行業(yè)內(nèi)相對較低的價格。比如：完全不按照主流友商們1-3w/線/年的報價方式，直接來幾毛錢一分鐘隨便打，隨打隨充。

二是呼叫中心資源方，是帶客進場，別從0開始找客戶，直接把現(xiàn)有的呼叫中心B端客戶轉化一部分成為機器人電銷客戶。

三是語義的能力，尤其是話術模板的設計能力。這一塊兒很容易被忽視，但是這反而也是產(chǎn)品經(jīng)理可以出成績的地方。一般來說可以拿呼叫中心多年積累的語料去分析一套話術模板（堪比銷售的對話體系），然后做ABtest也好。

從mvp開始逐漸增加主要話術分支也好，心理學基礎必須要有，必要時可以從游戲成癮機制等角度入手，《戀與制作人》的對話技巧學起來，一句話怎么說能讓接電話的人概率的順著自己的思路走，達成目的，從而形成特定細分領域機器人話術模板，得到的外呼效果（接通率、通話時長、電銷意愿、催收意愿）。

這一塊兒雖然很細，但是反復迭代之后可以以一敵萬，甚達到現(xiàn)在各類智能音箱背后核心系統(tǒng)一樣的地位。

四是外呼saas平臺。這部分是web類產(chǎn)品經(jīng)理的天下了，具體功能點就不詳細列舉了，友商們的網(wǎng)頁和后臺過一遍，基本好壞也能判斷出來了。

于現(xiàn)在此時此刻被視作亮點的可視化外呼腳本編輯，筆者個人認為其實是雞肋，普通人根本用不好，腳本邏輯只能做得很簡單，多輪對話、跨節(jié)點對話效果也不好，反而很容易導致客戶放棄。還不如干干脆脆給個可設置變量的場景化標準模板（話術模板由產(chǎn)品經(jīng)理提供），外呼試用效果好，客戶更容易買單。

七、結語與參考資料

這一套智能外呼系統(tǒng)搭下來，不僅僅可以做電銷機器人，可以做各類外呼，也可以做IVR語音導航、呼入電話客服。“NLU+CallCenter”就像這幾年“CV+安防”的結合一樣，也會如商湯科技聯(lián)合創(chuàng)始人林達華所說：

“中間也存在風險：一邊是從應用端往前走，一邊是從技術端往后走，大家都想占領技術上的制高點。這需要大家建立一種信任和共贏機制，只有這樣合作才能長久”。

AI雖然火熱受追捧，但具體項目落地并被市場認可和買單并不是那么容易。作為入行并不久的初學者，嘗試借以此文抽絲剝繭梳理了從0開始搭建智能外呼系統(tǒng)的全流程，才疏學淺囿于見聞，疏漏和不當之處在所難免，權當拋磚引玉。

諸多細節(jié)限于主題和篇幅不做詳述，如有任何問題，歡迎隨時交流。

參考資料：

• 《呼叫中心技術》，詹舒波等，人民郵電出版社，2015-09-01

• MRCPv2概述

• MRCPv2 – Speech Synthesizer Resource

• MRCP協(xié)議學習筆記

• MRCPv2 協(xié)議及其在分布式語音資源方案中的應用

• 華為在審：一種語音識別方法及裝置

• 百度-智能呼叫中心 Java SDK文檔