01

導讀

AI面試機器人通過利用靈犀智能語音語義平臺的人機語音對話能力模擬招聘者與求職者進行多輪語音溝通，達到在線化面試的效果。本文詳細描述了AI面試機器人的後端架構組成、對話引擎設計、資源需求預估策略、服務性能優化方法。AI面試機器人上線一年多來，累積接待了百萬次面試請求，極大地提升了招聘者招聘效率、求職者面試體驗。

02

項目背景

58同城生活服務平臺包括房產、汽車、招聘、本地服務（黃頁）四大老牌業務，平臺連接著海量的C端用戶和B端商家，B端商家可以在平臺上發佈房源、車源、職位、生活服務等各類信息（我們稱之為“帖子”），平臺將這些帖子分發給C端用戶供其瀏覽從而幫助他們獲取自己所需要的信息，幫助B端商家分發傳播信息從而獲取目標客戶，為了提升B端商家獲取目標客戶效率，提升C端用戶體驗，平臺在個性化推薦、智能化連接等方面持續地在進行著產品創新。以招聘為例，受2020年疫情的影響，傳統的線下招聘面試方式受到了較大的衝擊，平臺上求職者通過微聊、視頻等在線化面試請求量急增，由於一位招聘者在同一時刻只能與一位求職者建立在線化的視頻面試渠道，導致求職者、招聘者兩端鏈接成功率較低。為了提升求職者用戶體驗、提高招聘者面試效率，58同城TEG AI Lab與招聘業務線等多個部門協同打造了一款智能化招聘面試工具：神奇面試間。該產品主要由三大部分組成：客戶端、音視頻通信、AI面試機器人（參見：人物｜李忠：AI面試機器人打造智能化招聘）。本文將主要聚焦在AI面試機器人上，AI面試機器人通過利用靈犀智能語音語義平臺的人機語音對話的能力模擬招聘者與求職者進行多輪語音溝通，達到在線化面試的效果。一方面可解決一位招聘者只能響應一位求職者的在線化面試請求，提升招聘者作業效率；另一方面能滿足求職者不限時間、地點進行視頻面試，同時將個人簡歷從傳統的文字描述介紹轉換成更加直觀生動的視頻化自我展示。本文詳細描述了AI面試機器人的後端架構組成、人機語音對話引擎設計、如何預估資源需求應對流量擴容、如何優化服務性能來保證整體AI面試機器人服務的穩定性、可用性。

03

AI面試機器人後端架構

AI面試機器人架構如上圖所示，包括：1、接入層：主要用來處理與上下游的交互，包括與音視頻端約定通信協議；提取面試中用戶畫像、抽取機器人用戶交互時間軸信息下發招聘部門。2、邏輯層：主要是用來處理機器人和用戶的對話交互，包括將機器人的問題文本合成為語音數據發送給用戶，對用戶進行提問，讓機器人可以“說得出”；用戶回覆後，將用戶回覆語音數據通過VAD（Voice Activity Detection）斷句，流式語音識別為文本，讓機器人“聽得見”；對話引擎根據用戶的回覆文本和話術圖決定回覆內容然後合成語音發送給用戶，從而實現機器人和用戶的“溝通交流”。3、數據層：存放話術圖、對話記錄、標註信息等基礎數據。4、web系統：可視化配置話術結構、對話策略、標註面試對話數據。

04

AI面試機器人與用戶交互整體流程

一次完整的AI面試流程如上圖所示，可以被劃分為面試前、面試中、面試後三階段。面試前：主要是建立通信鏈路以及資源初始化，AI面試機器人與音視頻端的語音信號是通過UDP進行傳輸的，音視頻與AI面試機器人通信所需的IP和端口是需要動態維護。音視頻端通過SCF（SCF是58自主研發的RPC框架）接口發起面試請求，該請求一方面從AI面試機器人處實時動態獲取IP與端口資源用於音視頻後續將此次面試過程的採集到的語音信號發到AI機器人，另一方面告訴AI機器人需要將響應用戶的語音信號所需要發送的IP與端口，由於SCF支持負載均衡，所以音視頻端發起的面試請求會隨機打到AI面試機器人服務集群上某臺機器，這個時候這臺機器上的AI面試機器人通過SCF透傳的參數獲取到音視頻端的ip和端口，接下來AI面試機器人服務首先嚐試從可用端口隊列（服務初始化的時候創建的該隊列，以隊列的數據結構存放可用的端口對）中poll第一個可用端口對（發送端口和接收端口組成的pair），如果獲取成功，服務會把這臺機器的IP和端口通過SCF面試請求接口返回給音視頻端，後續雙方就可以進行UDP通信了，面試完成後，服務會把端口對push到可用端口隊列中。如果獲取端口對失敗，服務會通過SCF接口返回給音視頻端建立通信失敗代碼，音視頻端可以重試或者放棄此次面試請求。建立通信流程：在語音信號傳輸過程，在系統中我們採用了RTP協議作為音頻媒體協議。RTP協議即實時傳輸協議（Real-time Transport Protocol），為ip網上語音、圖像、傳真等多種需要實時傳輸的多媒體數據提供端到端的實時傳輸服務。RTP報文由兩部分組成：報頭和有效載荷。RTP報頭：屬性解釋：屬性解釋VRTP協議版本的版本號，佔2位，當前協議版本號為2P填充標誌，佔1位，如果P=1，那麼該報文的尾部填充一個或多個額外的8位數組，它們不是有效載荷的一部分X擴展標誌，佔1位，如果X=1，則在RTP報頭後面跟著一個擴展報頭CC參與源數，CSRC計數器，佔4位，指示CSRC標識符的個數M標記，佔1位，不同載荷有不同的含義，對於視頻，標記一幀的結束；對於音頻，標記會話的開始。PT有效載荷類型，佔7位，用於說明RTP報文中有效載荷的類型，如音頻、圖像等，在流媒體中大部分是用來區分音頻流和視頻流的，便於客戶端解析。序號佔16位，用來標識發送者所發送RTP報文的序列號，每發送一個報文，序列號增加1。這個字段當下層的承載協議用UDP的時候，網絡情況不好的時候可以用來檢查丟包。同時網絡出現抖動可以用來對數據進行重新排序。時間戳佔32位，反應了該RTP報文的第一個八位組的採樣時刻，接收者可以用時間戳來計算延遲和延遲抖動，並進行同步控制。SSRC用於標識同步信源，該標識可以隨機選擇，參加同一個視頻會議兩個同步信源不能有相同的SSRCCSRC每個CSRC標識符佔32位，可以有0～15個。每個CSRC標識了包含在該RTP報文有效載荷中的所有特約信源。面試中：在此過程中，AI面試機器人首先發送開場白，開場白文本通過tts（Text To Speech）合成為語音數據，語音數據經過編碼，進行壓縮，發送到約定好的音視頻端的IP和端口，用戶根據聽到的問題進行相關回復；AI面試機器人將接收到的用戶語音流進行解碼，通過vad斷句、流式語音識別為文本，對話引擎根據用戶回覆文本和話術結構狀態圖決定回覆內容，AI面試機器人和用戶不斷對話交互，直到話術結束或者用戶掛斷面試。面試後：一旦AI面試機器人收到音視頻關於面試結束的請求，AI面試機器人將回收面試準備階段申請的資源如端口、線程等；構建用戶的畫像（涉及到用戶最快到崗時間、是否從事過該工作、年齡等信息）提供給招聘方，方便商家進行篩選，以及對面試對話進行錄音存儲。錄音方案：

05

對話引擎核心功能

在整個面試流程中AI面試機器人和用戶交互是由對話引擎基於話術流程驅動的，其中話術是一個有向無環圖，最初話術圖是兩分支話術（所有節點的邊 <= 2），由於結構簡單，造成機器人對話機械，用戶回答問題意願低，面試完成率（回答了機器人提出的所有問題的用戶比例）僅20%。因此為了提高用戶的對話意願，提升機器人的智能對話能力，我們重構了話術結構，設計了多分支話術（某個節點的邊 >= 3），如下所示，用戶可以根據年齡、學歷、性格個性化地回覆用戶不同的話術，新話術結構上線後，面試完成率超過了50%。同時為了更加細粒度地設計對話策略，我們在策略鏈上設計了節點級的策略鏈，可以為單個節點定製個性化的對話策略，滿足個性化的對話需求。數據層面：為了實現多分支話術，我們重新設計了話術相關的數據結構，抽象出一些數據實體包括：話術表、話術節點、話術邊等。話術節點通過話術編號綁定到話術上，同時維護話術文本等屬性，話術邊維護節點之間的拓撲關係，有開始節點、結束節點，話術邊通過邊編號綁定著這個邊上的命中正則、語料等規則，同時可以使用邊id為這個邊定製自己的規則。策略鏈通過策略鏈編號綁定不同的策略，話術、節點通過策略鏈編號綁定不同的策略鏈。代碼層面：抽象出來邊、節點、話術類、話術狀態類概念，邊和節點是數據層的映射，邊上還維護了正則、語料等命中邏輯，話術類維護了開場白節點、話術圖等關鍵信息，話術圖是整個話術拓撲結構的映射，維護了節點和以該節點為開始節點邊集合的映射，話術狀態類維護了話術的當前狀態，包括話術類和當前節點，系統可以根據話術當前節點，從話術圖中獲取到以該節點為開始節點的所有邊（類似鄰接表），根據用戶當前的回覆去匹配不同邊上的規則，如果命中，那麼話術圖就流轉到命中邊的結束節點，同時從該節點上獲取機器人的回覆內容，話術結構就流轉起來了。話術圖數據結構：通過以上數據結構，系統平臺能快速響應業務方的話術定製需求，例如招聘方可以自定義每個招聘職位的問題，我們將這些問題抽象為話術中的虛擬節點，使用虛擬邊將虛擬節點連接起來，從而為不同職位提供個性化的面試問題，實現千人千面的效果。

06

服務性能優化實踐

神奇面試間上線後效果良好，因此業務方希望進行快速擴量，AI面試機器人需要支持最高同時在線千人以上，因此我們從資源管理、資源預估、性能試驗、監控四方面入手，有效提升了AI面試機器人服務的性能，線上實際使用中，優化後服務可同時接待的面試請求能力為優化前20倍。資源管理方案：為了更好地管理服務中使用到的資源，防止出現資源耗盡，我們設計瞭如下所示的資源管理方案。首先AI面試機器人跟音視頻是通過SCF約定通信協議，由於SCF是負載均衡的，所以調用方請求會隨機打到集群中某臺機器上，比如某一次請求打到服務實例1，通信協議可以將這通面試的交互綁定到該實例，接下來是抽象出來一個會話的概念（代碼層面是一個會話類，每一個會話是一個線程），將這一通面試中申請的資源比如發送接收端口、編解碼類、各種線程資源註冊到會話上，在代碼上保證釋放會話時一定釋放註冊在會話上的資源，這樣不同視頻面試通過線程的隔離性實現了資源隔離，從而方便進行資源管理。同時通過會話id（調用方通過通信協議約定好的，具有全局唯一性）將會話實例綁定到會話容器上。用戶掛斷的時候調用SCF釋放資源，由於SCF的隨機性，請求可能打到服務實例3，實例3上是沒有這通面試的會話，為了釋放資源，我們使用WMB（五八同城自研消息隊列）廣播這個釋放資源消息，消息體中含有會話id，所有服務實例都會消費到這一條消息，服務實例1含有該會話id，找到與會話id綁定的會話，調用會話的資源釋放功能，將使用到的資源釋放（其餘實例會丟棄該消息）。如果由於某些原因釋放請求沒有執行，會話容器有一個會話監視線程，可以掃描會話容器中所有會話的生命週期，為會話設定一個最大的生命週期（比如10分鐘），如果會話過期，主動觸發會話的資源回收，釋放會話資源。同時對於會話中申請的線程、端口等有限資源，我們使用集中式管理，使用線程池對線程集中管理，將所有可用端口放入到一個隊列中，對隊列剩餘端口進行監控，保證服務的穩定性和可用性。機器資源預估:限制資源瓶頸關注點會話申請的臨時資源臨時資源是否可以及時回收，比如端口、線程、編解碼類等資源。機器網絡帶寬1000MB/s >> 2500 * 32 KB/s機器硬盤資源商家自定義問題LRU淘汰策略線程線程池隊列中任務大小、任務執行耗時、創建線程數量監控等指標性能實驗:我們設計瞭如上圖所示的實驗方案：1、是對系統的架構進行梳理，發現其中有限的資源，同時整理壓力測試方案，2、是使用多線程模擬線上環境，3、是多種強度的強度試驗，瓶頸資源的分析，服務的分析。4、定位瓶頸點，增加閾值報警，重新試驗，5、是在實際場景中的服務的穩定性表現。壓力測試：接下來我們進行壓力測試，嘗試多種強度請求量試驗，當使用2500請求/min對接口進行壓力測試，發現服務的主要瓶頸是在服務的堆內存上。從下圖可以看到服務的堆內存很快到達100%，接口無響應。我們dump堆內存後發現堆內存中出現幾百個DialingInfo對象，每個對象佔用18.75MB，查看代碼可知，這個對象使用來存放AI面試機器人和用戶的對話內容，allRobotVoiceBuffer和allUserVoiceBuffer兩個對象各自佔用一半的內存大小，allRobotVoiceBuffer是存放機器人的語音信息（存放形式：byte數組），allUserVoiceBuffer是存放用戶的語音信息。查看代碼可以發現allRobotVoiceBuffer和allUserVoiceBuffer這兩個對象初始化服務的時候就共同佔用了18.75MB（這個數值是因為要存放5min的音頻數據），我們需要考慮這個初始化大小是否合理，分析神奇面試間歷史通話數據，可以看出來63%的用戶沒有回答機器人第一個問題直接掛斷面試，因此我們嘗試降低這兩個對象初始化內存大小，將allRobotVoiceBuffer修改為0.47MB（這個數值為機器人第一個問題音頻的大小），allUserVoiceBuffer為0MB，同時由於allRobotVoiceBuffer和allUserVoiceBuffer這兩個對象可以ms級別擴容，如果對話內容超過對象大小可以實現擴容不影響服務，修改後我們仍然使用2500min/請求去壓力測試，服務可以實現穩定的垃圾回收。細粒度的監控:指標類型概述服務關鍵性指標請求量、成功量、失敗量、沒有可用端口等13個指標資源性指標可用端口隊列長度小於閾值、緩存個性化問題超過閾值等5個指標流程性指標構建話術失敗、下發關鍵信息失敗、下發時間軸失敗等52個指標線程池監控指標請求創建線程數量、正在執行的任務數量、任務平均耗時6個指標職位問答環節指標獲取語音答案異常、答案預熱平均耗時等9個指標ASR指標自研語音識別平均時長、自研識別失敗等18個指標Vad指標調用次數、最大耗時等4個指標

07

總結

本文主要介紹了AI面試機器人的後端架構，AI面試機器人和用戶的交互全流程，對話引擎的核心功能以及服務性能優化實踐等工作。後續我們將持續支持神奇面試間項目的功能迭代以及性能優化，進一步將AI面試機器人落地到不同的業務。參考文獻1、RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne R. Frederick S. Casner V. Jacobson