最近和一些和對話系統不太了解的朋友聊了一下，發現其實很多人會把對話系統誤解為一個簡單、單一的系統，然而實際上對話系統內部的結構可以很復雜，這個原因很多吧，可能被一些文章給誤導吧，其實一個比較成熟的對話系統，內部的結構和組件是可以很多的，比較突出的就是多路召回以及其對應的排序系統。這一期給大家介紹一下這兩個模塊。

在工業界，可能會因為各種原因，我們需要采用多路召回的方式來處理對話系統，即分頭考慮多種答案的可能性，然后再篩選出最優的回答。這一期就給大家介紹多路召回和排序的來龍去脈，以及常見的解決方案。

多路召回的原因

上一期（心法利器[78] | 端到端任務的拆解設計）我們有提到，對于一個任務，如果比較復雜，我們是希望把任務進行拆解的，拆解之后各個擊破然后組裝回來，那么對于一個完整的對話系統也是如此，當然這也是它能被稱之為“系統”的理由，一般情況，我們會因為這些原因，把整個內容回復部分做拆解，形成多路召回：

回復內容的來源比較多樣。如一些問答類的，可能是問天氣、百科，這些資源的來源可能都不一樣，此時我們肯定是需要拆分多路召回逐個獲取的，甚至有些內容就是生成的，例如閑聊之類的。

不同內容的數據結構不同，要構造不同的存儲和檢索方案，例如結構化的內容，用mysql，文本檢索用ES，向量檢索可以用faiss，還有圖譜等。

有些可能是因為檢索內容和對象不同，例如QQ和QA匹配，例如改寫前后的匹配等。

一些回復需要特別的構造，如追問（你要問的是XXX嗎）、疑似問（你要問的問題是否在下面）、風控兜底（你說的這話不合適，對不起我還在學習）等。

因為很多原因，我們需要做多路召回，把多種不同內容、不同數據結構的資源，分路進行各自的召回，各自處理好后再排序。

多路的召回形式

由于上述原因，我們需要對對話系統進行多路召回，那么召回上，主要有哪些召回的鏈路呢。

檢索式

首先，是比較經典的檢索技術，這個其實對應的比較經典的檢索式對話，其實現在仍舊被廣泛使用，一些依賴數據、依賴知識背景的場景，這種檢索來找到合適的答案的方式是非常重要的，例如一些人物問答“魯迅的生卒年份”，客服場景“冰箱維修”，非常依賴檢索式，一般比較常用的檢索工具，有這些，大家可以根據實際情況進行選擇。當然，篇幅和時間原因，這里我只會提一些名詞，一些只是細節歡迎根據我提到的關鍵詞進行更加深入的學習。

對于結構化的知識，就是能形成關系表的那種，mysql是一個比較好的選擇，畢竟結構化查詢語言比較成熟，各種處理會比較簡單。

對于長文本、非結構化的檢索，技術上用的就是傳統搜索中的倒排索引，工具上，單機其實可以自己寫，也可以用，python寫個dict就可以了，具體的可以參考之前我寫的詞典匹配的這篇（把后面dict中的value改成長文本id即可），但是由于一般資源會比較多，所以更傾向于用分布式的方式，Elasticsearch是很好的選擇。

向量檢索，應該是現在比較潮流的玩法，在我們有一套比較好的向量的時候，就要做向量檢索，這個向量檢索的工具，單機推薦annoy，分布式推薦faiss，另外前面說的elasticseatch加上一些插件，如hnswlib也是可以用的。

另外還有一些更加前言的技術，例如知識圖譜，這個我具體沒有接觸，聽到比較多的是neo4j，其他的有熟悉這個的伙伴歡迎在評論區補充。

生成式

當然，除了經典的檢索式對話，還有大家比較喜歡聊起來的生成式，其實我的視角，工業界對生成式一直是比較謹慎的，主要原因有這么幾個：

生成式雖然非常直接，但是內容不可控，很多時候會有一些不太合適的回答，作為面向用戶的產品，可控性要求很高，例如一些不小心的涉黃涉暴，其實風險很高的，甚至有一些問句和答句分別看著很合適但是放一起就不合適的情況，雖然不多，但是一旦出現被封號下架沒了就很血虧了。

生成式其實也會有很多領域以來知識支撐，一旦沒有知識，是會出現“一本書正經的胡說八道”的情況。

寫到這，發現自己之前的對話系統系列文章寫過類似的文章，有關內容生成的，在這里：前沿重器[24] | 聊聊對話系統：內容輸出。

多輪

但說到這里，仍舊還有一種比較特殊的召回情況，需要說，就是多輪。多輪是一種對話系統一種特有的形式，另外這里會分強多輪和弱多輪，簡單解釋下：

強多輪是進入到一個比較狹窄的多輪通道，基本都會限制在這個對話鏈路里，一般是一些任務型的對話可能會這么做，例如定機票，多半需要將對話封閉起來做多輪的追問。一般無明確的打斷，都更傾向于封閉處理，不大會和其他鏈路一起排序。

弱多輪是做對話內容的信息繼承，在聊天過程可能會根據上輪信息給出進一步的回復，這種情況多半會比較寬松，通常都會參與和其他召回鏈路一起排序。

因此，如果是弱多輪，其實就是增加一個多輪的鏈路處理就好了，而對于強多輪，一般會增加一個打斷判斷，如果不打斷，就這一路多輪召回就好了，如果需要打斷，再讓位給其他鏈路即可。

值得注意的是，多輪只是一個對話系統里的特殊情況，多輪里面的內容，多半也逃不開檢索式和生成式這樣的形式。

多路召回下的排序

既然要分，后續肯定要合，多路召回對半就需要進行了排序。因為不同系統的不太一樣，所以簡單取一些情況簡單聊聊。

有用戶反饋

類似搜索和推薦系統，有些場景的推薦系統，是可以有用戶反饋的，例如一些客服系統之類的，用戶會給回復打分，例如“滿足”or“未滿足”，那就可以根據情況進行調整。既然有用戶的反饋，就可以開始利用起來，甚至是有些類似搜索的精排模型可以做。

因為不同系統中，用戶的反饋的占比、形式、可靠程度不同，采取的策略不太一樣，有些質量比較差或者比例比較低的，甚至直接拋棄，這個其實很考驗算法對現狀和自己手里方案的理解，因為資料看的還不太夠，我先不展開吧，后面有機會展開聊。我可以明確的是，直接套用搜索或者推薦那一套，很多時候是真不可行。

無用戶反饋

無用戶反饋往往是對話系統中最常見的情況，一般有這幾個原因：

產品原因，很多產品沒有明確的用戶回復，一般給了答案用戶就走了。

多答案的問題，一個提問可能有很多的回答方式，可能都是合理的，但用來做模型訓練也不好評估。

答案形式的豐富性，多種答案類型做統一表征存在困難，本身表征建模也不好做。

因此，大部分對話系統很難有用戶反饋和有監督的方式，這點真的得靠評測產品運營來做綜合評估然后來優化的，在多鏈路的合并時，往往是使用比較簡單的規則和簡單的認為評分進行分級排序，根據每個鏈路的質量、可靠性來進行綜合評估打分排序似乎是一個比較常規而且成本不高的方法。

這點不要以為非常罕見或者非常low，對于比較早起的搜索和排序系統，也是用的類似的方式來做綜合排序的，畢竟這個方式可靠簡單。

審核編輯 ：李倩