看板 Soft_Job
※ 引述《kewang (652公車)》之銘言: : ※ 引述《DOC (鍛鍊的還不夠)》之銘言: : : 小弟是網路公司的PM,負責一個跟景點圖資有關的產品,目前服務內有個進50萬的POI資 : : 料庫,但是讓用戶搜尋時,跑出來的結果非常糟糕,而且負責此項目的同事說能優化的都 : : 做了,已經無法再調整。想問問看版上的大神能不能開示怎麼處理比較好 : : 被檢索的欄位 : : poiNameCN:晴空塔 : : poiNameEN:Tokyo Skytree : : nickname1:天空樹 : : nickname2:新東京鐵塔 : : adminDivisionCN:日本/東京都/東京都心/墨田區 : : adminDivisionEN:Japan/Tokyo/Special wards/Sumida : : 原本理想的情況是,不管用戶是輸入景點的中文或英文名稱、或是輸入別名,或是輸入名 : : 稱加上行政區劃內的某一層(例如輸入:東京 天空樹),都可以用這些欄位來找出關連, : : 可是實測之後的結果卻很糟 : : 想問問有沒有大神有這種讓elsatic search同時比同一個物件的多個欄位,再排關聯度的 : : 經驗,能給小PM一點建議,讓我可以再去爭取重開這個優化的需求 : : 感謝! : 原文的推文大概都有提到了做法,但已經在這塊花了不少時間的我,也來分享一下 : 1. 依照欄位做多欄位分語系 : elasticsearch 每一個欄位都可以塞 array 進去,所以你的 nickname 可以分語系直接 : 塞進去,poiNameCN: ["晴空塔", "天空樹", "新東京鐵塔"] : 2. 分語系記得要用不同的 analyzer : CN 就用 ik, jieba, blahblah 之類的,EN 就用 standard 或用一堆 filter 串起來 : 無論是哪一種,記得都要用 analyze 測試結果,然後再加 filter 去處理 : 3. city 可以另外塞 index : 因為「東京」、「新宿」也是一個 city,這個必須要能做分詞 : 你現在看起來就是塞在同一個欄位 array?如果是塞成 array 的話也應該要正常才對 : 「猜出正確的 city」其實蠻難的,要先了解你們自己產品的 UX,再來決定如何做 : 4. 要不要直接串我們家的 API 啊? : 不確定是不是你有少列一些東西,但看起來你們家工程師好像連 elasticsearch 的基本 : 資料儲存方式都不太理解,需要補充蠻多知識的。 : 如果要串我們家 API 的話可以直接私訊我,現在已經改版到第三版了。 : 要從頭到尾做出一套實在是很花時間,要先充分理解使用者行為,然後一步一步演進。 : 從 POIBank v1 出來到現在已經過 5 年了,去年底已經改版到 v3,當然還是很多問題要 : 處理,但比 v1 好太多了。 : 剩下有空再寫文章分享更細部的東西好了。 推文跟 kewang 已經有很多資訊。我用有限的經驗回答你的問題,有些跟前人說的重複 分四部分:ES 工程、metrics 衡量、生態系、以及產品地位。 雖然第一個可能才是你想看的,但「越後面的才越重要」,讀的時候請記在心 ## Elasticsearch 技術 * 多看官方文件,例如 * https://bit.ly/3SlCYoS 欄位權重、跨欄位等等 * https://bit.ly/48UeF6D 自定義分數 * 要看你們用的 ElasticSearch 的版號的文件 * 搜尋分兩階段:recall 跟 ranking, 要先能匹配到,才有算分排名的機會 * 搜尋跟兩者有關:「怎麼建索引」跟「怎麼下 query」 * analyzer 影響 recall * 決定索引裡面的資料要怎麼處理(大小寫?斷詞?去掉符號?) * search_analyzer 則是用在處理使用者即時的 query。 通常 analyzer 跟 search_analyzer 應該要一樣的處理方式, 避免搭不起來的副作用。但 jieba 中文斷詞是個例外, 文本資料會希望更多可能性 (緣由見 https://github.com/fxsjy/jieba 全模式) * 不同的欄位可以、也最好有各別的 analyzer * 善用 /_analyze 去 debug 一個 analyzer 對於一串文字的處理結果 * 中文斷詞要處理,雖然 jieba elasticsearch plugin 不見得好用, 必要的時候需要自己魔改使用繁體字典或客製化字典 * 多欄位 * 可用 cross_fields + multi_match 去匹配多個欄位 * 每個欄位可用不同的“type”(keyword vs. text) 準確搜尋跟文本搜尋可以併用,並以不同的分數合併 * 分數調整 * 排名的分數有兩大類: 資料本身的重要性 (跟著 document, 與 query 無關,靜態的重要度) , 以及 query 跟資料的相關性 (runtime 算出) * 靜態分數、重要度:事先根據商業邏輯算好,在建造 index 的時候 放在文件的一個/多個欄位 * 整體排名可以自己寫公式,把靜態分數與不同欄位的相關分數融合在一起 * 匹配的時候,每個欄位可以有權重自調 * 善用 must, should, filter, 以及 minimum_should_match 的組合 * 但要注意,避免太多 should 讓 recall 過多,或是用奇怪的公式, 導致搜尋速度變慢 * 善用 `/_search?explain=true` 找問題,看匹配的理由與分數的組成 (BM25 is tricky, synonym is also tricy. 為了 recall 塞太多資料可能會傷害 ranking) * 如果延遲時間允許或是 API 設計得好,一個使用者的 query 可以做 多次多種準確度的搜尋,最後把結果合併起來 * Embedding 雖然可以考慮,不過不一定適合短文件(例如 POI) 需要科學方法測量評估,而測量需要資料 上面寫了有很多,不代表開發者沒試過,也不代表試了就有用。最重要的是:如果沒有「 衡量資料」只靠福至心靈 spot check,上面寫的都沒用,沒辦法優化/最佳化。 **指標需要 PM 提供。評量資料需要 PM 跟開發者一起研究** ## 搜尋評量 metrics * 概念:搜尋結果有絕對單一個答案嗎?還是多個模糊建議都適合給使用者? 這走向會決定哪類型的衡量比較好 * 概念:搜尋品質並非說一是一的程式,很容易「修東壞西」,所以要有測試資料 * 概念:做好了就算不動他,品質也可能會爛,因為使用者的 query 分布變化、 資料變化等等 (input drift, data drift) * 測試資料收集: * 使用者 log(e.g. 哪個關鍵字較流行) * 商業策略(e.g. 跟哪家公司關係利益較大,整體產品策略,使用者習慣養成...) * 要評量搜尋品質,盡量用大量資料,且能反應使用者習慣,或能反應商業策略 * 使用者習慣如果需要培養(例如教育使用者要怎麼用你們的搜尋), 一味取用目前使用者 log 不一定好 * recall 跟 ranking 是搜尋兩階段 * recall: 有多少該出的,是真的出了 * precision: 出的裡面,有多少是該出的 * ranking: 該出的結果,是否排在上面容易看見 * 做到極致的時候會需要 tradeoff: 產品/PM 需要決定是寧缺勿濫 (precision) 還是寧爛勿缺 (recall) * Google "ranking metrics" 了解有哪些指標 * 這篇應該不錯 https://bit.ly/3O5Sx19 * 搜尋結果要明確、不模糊: recall@k, precision@k, MRR) 等等 * 會有多個搜尋結果都很適合丟給使用者: DCG, nDCG 等等 * "Boss" metrics: 老闆半夜丟訊息給你「為什麼這個詞搜尋結果出來這麼爛?」 * 跟使用者有關還是商業策略有關? * 如果都無關,只是老闆爽,跟老闆適當解釋你們的衡量系統 ## 打造搜尋生態系 * Corpus data pipeline: 要索引的資料的來源? (自產、客戶、User generated, ...) 有固定規格嗎?大小頻率?需要清洗嗎?等等等 * 搜集互動資料(e.g. 搜尋了什麼,點了什麼), 了解 query 的分佈,跟目前使用者滿意度 * 衡量系統: * 能方便執行「人工單點審查」以及「大資料評比」,評估搜尋品質 * 自動線下測試(e.g. 固定測資,一鍵 / CICD 測量?) * 產品線上品質(e.g. 點擊率) * 搜尋模型/公式更新? * 需要衡量系統 * 公式/模型本身要有參數可以變化調整 * 更新的一種最笨方法:暴力測試不同參數組合, 以衡量系統出來的分數,取最高分的那組參數 * 「後門」系統 * 不完全遵照 elasticsearch 結果,甚至有可能直接蓋過 * 可以為獨立系統,也可以整合在「產生 ES query」裡 * 應付流行詞,如果怎麼調整公式,但搜尋結果就是爛 * 應付老闆 (huh?) * 飲鴆止渴:維護答案有成本 ## 搜尋是否為賣點? * 搜尋是否為產品重要流量入口?或是想投資變成重要入口? * 搜尋可大可小:可以是數十人投資一兩年,也可以是兩三人投資三個月。 哪些搜尋 feature 是核心?哪些是加分? * 站在公司的立場,自己從無到有開發維護搜尋?還是用別人的服務? 機會成本:同樣資源投資在其他地方有沒有可能比較好? * 搜尋體驗:precision or recall? 給使用者答案或探索(推薦)? === 搜尋單看技術面就有非常多眉角,簡單講沒有「單一答案」,可能需要多個系統篩選/排 序,還有測量品質。同時也沒有「標準答案」,每個產品都不一樣 然而,我偏見地認為 PM 不太應該給開發者「實作」的建議 (e.g. 你要 cross_fields 啊, 要 jieba 啊) 而是讓開發者了解產品的目標,功能的「緣由」與定義 (e.g. POI 有多種名詞。希望增加 recall。「京鐵」不要出「東京鐵塔」...) 與量化評斷方式。 同時從開發者那邊了解實作的「所需努力時間」跟「不確定性」,來調整產品的範圍大小 與策略。 我的意思是不要太一廂情願,覺得網路上找到解法,就能「爭取重開優化的需求」 其實給使用者的產品,搜尋功能真的不好做:在整個產品中的定位、產品領域、資料特性 、使用者故事、甚至公司部門的組成,都會影響策略。沒有體驗過的大概不會了解,希望 你不要氣餒,關鍵字與建議可以吸收,至於單純的指責就忽略吧,加油! === 網頁好讀版: https://ywctech.net/tech/build-search-products-using-elasticsearch-notes/ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.240.185.97 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1705406976.A.CE5.html
kewang: 推這篇,好文! 01/16 21:03
johnny9144: 精選好文! 01/16 21:51
panorama: 推好文 01/16 22:24
DrTech: 在台灣,難得看到有人說的出 recall 與 ranking 兩階段。 01/16 23:44
DrTech: 先求找得到,在求排得準。 01/16 23:45
Kroner: 最近天氣變化大,關節痛好像更嚴重了。 01/17 10:44
DrTech: 原PO說得都是基本功啦。實務上現在recall ,ranking很多時 01/16 23:50
DrTech: 候會用ML/AI來做。大系統越來越少用規則在算分了,不然Bug 01/16 23:50
DrTech: 解不完。 01/16 23:50
DrTech: 打造搜尋生態系那段很有趣。沒做過產品的應該很難體會。da 01/17 00:07
Kroner: UC2神招啊,吃下去就對了 01/17 12:39
DrTech: ta pipeline與蒐集使用者行為,對於未來搜尋結果的重要性 01/17 00:07
DrTech: 。 01/17 00:07
DrTech: 成功的搜尋產品真的不簡單,此文不只討論技術而已,還包含 01/17 00:08
DrTech: 產品。總結得很好。 01/17 00:09
Kroner: 想問一下有沒有關節痛的運動禁忌?怕動得更嚴重… 01/17 19:33
MIKEmike07: 推 01/17 06:04
hobnob: 謝謝分享 01/17 09:52
ian90911: 推好文 01/17 10:18
Hsins: 推 01/17 10:44
Kroner: 想問一下有沒有關節痛的運動禁忌?怕動得更嚴重… 01/18 12:55
ytall: 推 01/17 11:01
drysor: 推 01/17 12:19
nicetw20xx: 謝謝大大分享 01/17 12:33
untitled: 感謝補充與支持~ 01/17 12:39
Kroner: 樓上UC2當糖吃,天天走拿飛 01/18 23:23
holebro: 好文 01/17 12:39
CaptPlanet: 真4佛心 01/17 13:46
mathrew: 真佛心 01/17 19:27
dmeiki: 推 01/17 19:33
Kroner: 求推薦靠譜的復健診所,小弟關節治好再來跪謝! 01/28 09:35
imhaha: 推 01/17 22:27
richardz: 推 01/17 23:39
zero0825: 推感謝分享 01/18 12:39
ramskull: 一手漂亮 markdown 回文,直接貼進筆記收藏 01/18 12:55
Chricey: 關節痛就老人病 01/18 12:55
f0915034335: 優文 01/18 13:19
alpe: 佛心,推啊 01/18 13:23
inte629l: 推 01/18 13:25
Psyman: 推 01/18 23:23
Chricey: 我有在用UC2,感覺效果還不錯欸! 01/18 23:23
frankshih: 超讚,最近剛開始用。也是迷迷糊糊就做一版趕上線,看 01/20 07:38
frankshih: 來還有得優化 01/20 07:38
tw11509: 推 01/24 11:07
jason1596t: 這種等級的回文是可以免費看的嗎 01/28 09:35
Kroner: 5樓關節跟X一樣 01/28 09:35
howdiee: 推概念 01/31 21:51
niverse: 謝分享! 02/12 11:35
LeaChu: 推 02/21 01:14