最近和一些和對話系統(tǒng)不太了解的朋友聊了一下，發(fā)現(xiàn)其實很多人會把對話系統(tǒng)誤解為一個簡單、單一的系統(tǒng)，然而實際上對話系統(tǒng)內(nèi)部的結(jié)構(gòu)可以很復(fù)雜，這個原因很多吧，可能被一些文章給誤導(dǎo)吧，其實一個比較成熟的對話系統(tǒng)，內(nèi)部的結(jié)構(gòu)和組件是可以很多的，比較突出的就是多路召回以及其對應(yīng)的排序系統(tǒng)。這一期給大家介紹一下這兩個模塊。

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

多路召回的原因

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

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

不同內(nèi)容的數(shù)據(jù)結(jié)構(gòu)不同，要構(gòu)造不同的存儲和檢索方案，例如結(jié)構(gòu)化的內(nèi)容，用mysql，文本檢索用ES，向量檢索可以用faiss，還有圖譜等。

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

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

因為很多原因，我們需要做多路召回，把多種不同內(nèi)容、不同數(shù)據(jù)結(jié)構(gòu)的資源，分路進行各自的召回，各自處理好后再排序。

多路的召回形式

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

檢索式

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

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

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

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

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

生成式

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

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

生成式其實也會有很多領(lǐng)域以來知識支撐，一旦沒有知識，是會出現(xiàn)“一本書正經(jīng)的胡說八道”的情況。

寫到這，發(fā)現(xiàn)自己之前的對話系統(tǒng)系列文章寫過類似的文章，有關(guān)內(nèi)容生成的，在這里：前沿重器[24] | 聊聊對話系統(tǒng)：內(nèi)容輸出。

多輪

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

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

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

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

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

多路召回下的排序

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

有用戶反饋

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

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

無用戶反饋

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

產(chǎn)品原因，很多產(chǎn)品沒有明確的用戶回復(fù)，一般給了答案用戶就走了。

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

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

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

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

審核編輯 ：李倩