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

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

多路召回的原因

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

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

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

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

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

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

多路的召回形式

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

檢索式

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

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

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

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

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

生成式

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

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

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

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

多輪

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

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

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

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

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

多路召回下的排序

既然要分，后續(xù)肯定要合，多路召回對半就需要進(jìn)行了排序。因?yàn)椴煌到y(tǒng)的不太一樣，所以簡單取一些情況簡單聊聊。

有用戶反饋

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

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

無用戶反饋

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

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

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

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

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

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

審核編輯 ：李倩