如何在Solr中更好的處理同義詞.doc

如何在Solr中更好的處理同義詞當(dāng)使用Solr來構(gòu)建搜索引擎的時(shí)候，你可能經(jīng)常會(huì)遇到這樣的場(chǎng)景：你有一個(gè)同義詞列表，并且你想用戶查詢也能夠命中到同義詞。聽起來很簡(jiǎn)單不是嗎？為什么搜索“dog”的時(shí)候，不能命中包含“hound(獵犬)”或者“pooch(狗)”的文檔呢？甚至包含“Rover(流浪者)”和“canis familiaris(犬)”?叫Rover或者其他名字，可能只是為了讓小狗聽起來很可愛。事實(shí)證明，Solr的同義詞擴(kuò)展沒有你想象的那么簡(jiǎn)單。但是我們有很多好的方法來搬石頭砸自己的腳。The SynonymFilterFactorySolr提供了一個(gè)聽起來很酷的SynonymFilterFactory,它可以接收一個(gè)逗號(hào)分割的同義詞文本。你甚至可以選擇同義詞是相互擴(kuò)展還是特定方向的替換。舉例來說，你可以讓“dog”，“hound”和“pooch”都擴(kuò)展為“dog|hound|pooch”，或者你可以指定“dog”映射到“hound”，反過來卻不可以，或者你可以把所有的詞都轉(zhuǎn)化為”dog“,Solr處理這部分是非常靈活的并且做的很棒。當(dāng)你考慮是把SynonymFilterFactory放在查詢分析器還是索引分析器時(shí)，這個(gè)問題就變得很復(fù)雜啦。Index-time vs. query-time下圖總結(jié)了查詢時(shí)（query-time）和索引時(shí)（index-time）同義詞擴(kuò)展的基本差異。當(dāng)然我們是為了解決solr中使用的問題，但是這2種方法適用于任何信息檢索系統(tǒng)。你的直觀選擇可能是將SynonymFilterFactory放在查詢分析器內(nèi)。理論上，這樣做有以下優(yōu)點(diǎn)： 索引大小不會(huì)變化 同義詞可以隨時(shí)更換，不用更新索引 同義詞實(shí)時(shí)生效，不需要重新索引然而，按Solr Docs所說，這是一個(gè)Very Bad Thing to Do()，顯然的你應(yīng)該把SynonymFilterFactory放在索引分析器里，而不是簡(jiǎn)單的依靠你的直覺來判斷。文檔里說，查詢時(shí)的同義詞擴(kuò)展有以下的缺點(diǎn)： 多字同義詞并不能識(shí)別為短語(yǔ)查詢 罕見同義詞的IDF會(huì)被加權(quán)，導(dǎo)致不可想象的搜索結(jié)果 多字同義詞不會(huì)匹配查詢這有點(diǎn)復(fù)雜，因此也值得我們一一解決這些問題。多字同義詞并不能識(shí)別為短語(yǔ)查詢?cè)贖ealth On the Net,我們的搜索引擎使用MeSH來做查詢擴(kuò)展，MeSH是一個(gè)為健康領(lǐng)域提供優(yōu)質(zhì)同義詞的醫(yī)療本體。例如”breast cancer“的同義詞：breast neoplasmbreast neoplasmsbreast tumorbreast tumorscancer of breastcancer of the breast因此在正常情況下，如果SynonymFilterFactory配置了expand=true,查詢”breast cancer“就變成了：+(breast breast breast breast breast cancer cancer) (cancer neoplasm neoplasms tumor tumors) breast breast)這將命中包含”breast neoplasms“,”cancer of the breast”等等的文檔。然而，這也意味著，如果你正在做一個(gè)短語(yǔ)查詢（比如”breast cancer“）,如果想生效，你的文檔必須字面上匹配類似”breast cancer breast breast“這樣的字符。?。窟@里到底發(fā)生了什么？事實(shí)證明SynonymFilterFactory并沒有按你所想來擴(kuò)展多字同義詞。直覺上，可能認(rèn)為它表現(xiàn)為一個(gè)有限自動(dòng)機(jī)，Solr構(gòu)建出的結(jié)果可能類似這樣(忽略復(fù)數(shù))：但是，它真正構(gòu)建的是下面這樣的：簡(jiǎn)直是一碗意大利面。你可憐的文檔必須依序包含所有的4個(gè)部分。讓人驚訝。同樣，DisMax和EDisMax查詢分析器的mm(最小匹配)參數(shù)，并不能像你所想的那樣工作。在上面的例子中，設(shè)置mm=100%將需要所有4個(gè)部分都匹配。+(breast breast breast breast breast cancer cancer) (cancer neoplasm neoplasms tumor tumors) breast breast)4罕見同義詞的IDF會(huì)被加權(quán)即使你沒有多字同義詞，Solr Docs也提到了第二個(gè)避免查詢時(shí)擴(kuò)展的原因：不正常的IDF加權(quán)。考慮我們的”dog”,”hound”,”pooch”例子，查詢3個(gè)里面的任意一個(gè)都會(huì)被擴(kuò)展為：+(dog hound pooch)由于“hound”和”pooch“是比較少見的字，因此無論查詢什么，包含這些字的文檔會(huì)在查詢結(jié)果中排名特別高。這對(duì)可憐的用戶來說，簡(jiǎn)直是一個(gè)浩劫，為什么搜索”dog“的時(shí)候，會(huì)有那么多包含”hound“和”pooch“的怪異文檔排名那么高。索引時(shí)擴(kuò)展通過給”dog”,”hound”,”pooch”賦予相同的IDF值，而不管原始文檔是什么。多字同義詞不會(huì)匹配查詢最后，也是最嚴(yán)重的是，如果你對(duì)用戶查詢做任意類型的分詞，SynonymFilterFactory并不會(huì)匹配多字同義詞。這是因?yàn)榉衷~器會(huì)將用戶輸入分開，然后才交給SynonymFilterFactory來轉(zhuǎn)換。比如，查詢“cancer of the breast”會(huì)被StandardTokenizationFactory分詞為“cancer”,”of”,”the”,”breast，并且只有獨(dú)立的詞才會(huì)傳給SynonymFilterFactory。因此，在這種情況下，如果分詞后的單個(gè)詞，比如cancer“和”breast“都沒有同義詞的情況下，同義詞擴(kuò)展就壓根不會(huì)發(fā)生。其他問題最初，我按照Solr的建議，使用索引時(shí)擴(kuò)展，但是我發(fā)現(xiàn)索引時(shí)同義詞擴(kuò)展有它自己的問題。顯然，除了有索引爆炸的問題，我還發(fā)現(xiàn)一個(gè)關(guān)于高亮的有趣的bug。當(dāng)我搜索”breast cancer“的時(shí)候，我發(fā)現(xiàn)高亮器會(huì)很神奇的把”breast cancer X Y“給高亮了，其中”X“和”Y“是文檔中任何跟在”breast cancer“后面的2個(gè)字符。例如，它可能會(huì)高亮”breast cancer frauds are“或者”breast cancer is to“。看完這個(gè)solr bug,這和前面提到的Solr多字同義詞擴(kuò)展是一個(gè)原因。使用查詢時(shí)擴(kuò)展，你的查詢被轉(zhuǎn)換為像意大利面般的圖已經(jīng)足夠的怪異了。但是在索引時(shí)擴(kuò)展，假如你的文檔包含”breast cancer treatment options“,會(huì)變成什么樣子呢。這就是Lucene認(rèn)為的你文檔的樣子。同義詞擴(kuò)展給你帶來了比你要求更多的東西，類似”Dada-esque“的結(jié)果！”Breast tumor the options“確實(shí)是這樣的。從根本上來說，Lucene認(rèn)為一個(gè)查詢”cancer of the breast“(4個(gè)Token)和你原始文檔里的”breast cancer treatment options“(4個(gè)Token)是一樣的。這是因?yàn)門okens只是一個(gè)疊加另一個(gè)上面而已，丟失任何信息的部分都可以由它后面的部門來替代。查詢時(shí)擴(kuò)展不會(huì)引起這個(gè)問題，因?yàn)镾olr只擴(kuò)展了查詢，而不是文檔。因此Lucene仍然認(rèn)為查詢的”cancer of the breast“只會(huì)匹配文檔里的”breast cancer“。總結(jié)所有這些古怪的問題，讓我得出這樣的結(jié)論：Solr內(nèi)建的同義詞擴(kuò)展機(jī)制是及其糟糕的。我必須找出一個(gè)更好的方法來讓Solr按我想的來運(yùn)行?？傊瑹o論是索引時(shí)擴(kuò)展還是查詢時(shí)擴(kuò)展使用標(biāo)準(zhǔn)的SynonymFilterFactory都是不可行的，因?yàn)樗鼈兌加懈髯圆煌膯栴}。Index-time 索引爆炸 同義詞不能立即生效，所有文檔需重新索引 同義詞不能立即刪除 多字同義詞導(dǎo)致多余的文字被高亮Query-time 短語(yǔ)查詢不支持 罕見同義詞被認(rèn)為加權(quán)了 多字同義詞不匹配查詢我開始假設(shè)理想的同義詞擴(kuò)展系統(tǒng)應(yīng)該是基于查詢時(shí)的，由于基于索引的擴(kuò)展有那么多固有的缺點(diǎn)。同時(shí)，我也意識(shí)到在Solr實(shí)現(xiàn)同義詞擴(kuò)展之前，有一個(gè)更加根本的問題需要解決?；氐健眃og“/”hound”/”pooch”的例子，對(duì)待3個(gè)詞對(duì)等的是不明智的。在特定的查詢中，”dog“可能并不與”hound“和”pooch“是一樣的，比如 (e.g. “The Hound of the Baskervilles,” “The Itchy & Scratchy & Poochy Show”). 一視同仁感覺是錯(cuò)誤的。同樣的，即使使用官方推薦的索引時(shí)擴(kuò)展，IDF權(quán)重也被拋棄了。每個(gè)包含”dog“的文章現(xiàn)在也都包含”pooch“，這意味著我們將永久的丟失關(guān)于”pooch“的真實(shí)IDF值。在一個(gè)理想的系統(tǒng)里，搜索”dog“，返回的結(jié)果應(yīng)該包含所有存在”hound“和”pooch“的文檔，但是應(yīng)該將所有包含真實(shí)查詢的文檔排的更靠前面，包含”dog“的應(yīng)該得到更高的分。同樣的，搜索“hound”應(yīng)該把包含“hound”的排的更靠前面，搜索“pooch”就應(yīng)該將包含“pooch”的更靠前。所有的3個(gè)搜索都返回相同的文檔集，但是結(jié)果排序不一樣。Solution我的解決方法是，把同義詞擴(kuò)展從分析器的Tokenizer鏈移動(dòng)到QueryParser。不是把查詢變成如上面的縱橫交錯(cuò)的圖，而是把它分為2個(gè)部分：主查詢和同義詞查詢。然后我為每個(gè)部分獨(dú)立配置權(quán)重，指定每個(gè)部分內(nèi)部為“should occur”。最后將二者使用“must occur”的布爾查詢包裝起來。因此，搜索“dog”為被解析為類似這樣：+(dog)1.2 (hound pooch)1.1)1.2和1.1是獨(dú)立的權(quán)重，可以配置。文檔必須包含“dog”,”hound”或者“pooch”，但是“dog”更優(yōu)先顯示。這樣來處理同義詞，帶來了另一個(gè)有趣的副作用：它消除了短語(yǔ)查詢不支持的問題。如果是“breast cancer”(帶引號(hào))，將會(huì)被解析為這樣：+(breast cancer)1.2 (breast neoplasm) (breast tumor) (cancer ? breast) (cancer ? ? breast)1.1)(問號(hào)?的出現(xiàn)是由于停用詞“of”和“the”)這意味著查詢帶引號(hào)的“breast cancer”會(huì)匹配所有包含“breast neoplasm,” “breast tumor,” “cancer of the breast,” and “cancer