搜索也好，檢索式對話也好，文本是一個很難繞開的話題，雖然語義是一個重要因素，用語義相似度直接梭，但是用戶的感知可不是如此，很多用戶的感知更多是文本層面的相似要高于語義相似，或者說，遇到語義相似和文本相似的時候會更優先接受文本相似，畢竟文本使用戶能直接看到的，當然語義相似度雖好，但是對于沒有什么標注數據的情況，也是束手無策吧。

所以，即使語義相似度如火如荼地發展著，文本層面的匹配依舊是項目實踐中不可避免的關注點。

cqr&ctr概念

cqr和ctr的概念還是比較清晰明確的。

給定query和title，現在計算cqr和ctr。

講完了，就是這么簡單，其實就是看兩者交集占query的占比和占title的占比，就是對應的cqr和ctr。

當然，由于這種計算會把所有詞的重要性考慮進去，例如“怎么做作業”分別和“怎樣做作業”、“怎么做手機”，兩個的相似度就一樣了，此時就要考慮到給每個詞加點權重，這樣能更好地描述，這就是一個優化的實用版本，加權

給定query，有對應的權重和title，以及對應權重，現在計算cqr和ctr：

想到可能會有人問到權重怎么來，這里我就要把我的歷史文章放出來了，之前是專門講過詞權重的問題的：NLP.TM[20] | 詞權重問題

這個應該就是我自己平時用的版本了，而且屢試不爽。

而如果是要分析兩個句子綜合、無偏的相似度，只要相乘就好了：

細品

可以看到，這個東西很簡單，就是一個基于統計計算的工具，但是我依然想仔細討論一下這個東西。

首先，有關相似度，其實我們很容易想到這個計算方法：

就是比較著名的jaccard相似度，當然還有一個更加出名的方法，那就是BM25（更為常見，此處就不贅述了）。但是我并沒有選擇，為什么呢，其實核心就是1個點：

query和title的長度信息。

jaccard距離雖然能比較綜合、無偏向性地計算兩者的相似度，但問題是，當query和title長度計算差距很大的時候，計算準確性就會受到影響，而分成兩個指標，則能夠充分表現兩者的相似性，當然具體用哪種其實還是要看具體場景的，有的時候這種無偏向性對效果優化還是有用的，但是有的時候其實會影響最終效果。

來看個例子，query是“我昨天新買的手機，今天怎么就不能開機了”，title是“手機不能開機”，這里可以，ctr無疑就是1，當然cqr就比較低了，但是我們可以用ctr作為后續的排序特征或者過濾條件。

優缺點

感覺有些東西想說但是沒說出來，直接總結一下這個方案的優缺點吧，以便大家進行方案選擇吧，這個優點，是相對于常見的語義相似度模型而言的。

首先說優點：

能夠體現文本層面的相似度，在一些領域下體驗比較好。

性能比語義相似度模型好很，所以是一個簡單輕快的模型。

無監督，詞權重的話用語料就可以訓練了。

效果穩定可追蹤。

當然，還是有缺點的。

文本層面的匹配無法體現語義，同義詞、說法之類的無法體現。

對切詞敏感，類似“充不進去電”和“充電”就完全匹配不上。

應用

有這些有缺點，其實我們就可以考慮這個相似度該怎么用了：

用于過濾一些肯定不對的答案。

無標注數據下，這個指標可以作為排序的指標，對啟動項目挺重要的。

作為排序特征，保證結果在文本層面還是比較接近的。

當然，在一個比較完整的搜索或者是檢索式對話的系統里，其實這種文本相似度類的特征還是非常有收益的，結合語義相似度還是會有一些比較穩定的收益。

小結

東西其實不難，卻是非常實用的技能，但是在應用的過程中能夠想到的人其實很少，但有用的東西我們學起來也挺好。

原文標題：【文本匹配】cqr&ctr：文本匹配的破城長矛

文章出處：【微信公眾號：深度學習自然語言處理】歡迎添加關注！文章轉載請注明出處。

責任編輯:haq