PTT職涯區 / Soft_Job (軟體人)

[請益] Elastic Search結果慘烈怎麼修

看板Soft_Job (軟體人)作者 (鍛鍊的還不夠)時間10月前 (2024/01/15 17:47), 編輯推噓8(14推 6噓 44→)
留言64則, 26人參與, 10月前最新討論串1/4 (看更多)
小弟是網路公司的PM，負責一個跟景點圖資有關的產品，目前服務內有個進50萬的POI資 料庫，但是讓用戶搜尋時，跑出來的結果非常糟糕，而且負責此項目的同事說能優化的都 做了，已經無法再調整。想問問看版上的大神能不能開示怎麼處理比較好 被檢索的欄位 poiNameCN：晴空塔 poiNameEN：Tokyo Skytree nickname1：天空樹 nickname2：新東京鐵塔 adminDivisionCN：日本/東京都/東京都心/墨田區 adminDivisionEN：Japan/Tokyo/Special wards/Sumida 原本理想的情況是，不管用戶是輸入景點的中文或英文名稱、或是輸入別名，或是輸入名 稱加上行政區劃內的某一層(例如輸入：東京 天空樹)，都可以用這些欄位來找出關連， 可是實測之後的結果卻很糟 想問問有沒有大神有這種讓elsatic search同時比同一個物件的多個欄位，再排關聯度的 經驗，能給小PM一點建議，讓我可以再去爭取重開這個優化的需求 感謝！ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.133.105.193 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1705312027.A.A80.html
→
01/15 17:55, 10月前 , 1F
50萬筆聽起來沒有很大(? 你們是用like去查嗎
01/15 17:55, 1F
推
01/15 18:06, 10月前 , 2F
是同行嗎 xd https://techblog.funliday.com 裡面我有寫一
01/15 18:06, 2F
→
01/15 18:06, 10月前 , 3F
些可以參考，但都是舊版的方式了，有空再寫新版的方式
01/15 18:06, 3F
噓
01/15 18:23, 10月前 , 4F
怎麼個糟法？連舉例都不會不要當pm害人好嗎 另外官
01/15 18:23, 4F
→
01/15 18:23, 10月前 , 5F
方不是有sup嗎？官方對於這case給的回應是什麼
01/15 18:23, 5F
推
01/15 18:25, 10月前 , 6F
發現k旺？
01/15 18:25, 6F
→
01/15 18:26, 10月前 , 7F
我認為B0988698088 應該有SOLUTION的，出一篇吧。
01/15 18:26, 7F
推
01/15 18:31, 10月前 , 8F
你要先釐清是 recall 還是 ranking 問題。換句話說是搜尋
01/15 18:31, 8F
→
01/15 18:31, 10月前 , 9F
結果沒有命中還是單純排序太後面。此外對 input 拆詞後是
01/15 18:31, 9F
→
01/15 18:31, 10月前 , 10F
採用什麼樣語法搜尋，以及需要檢查拆詞後的結果符不符合
01/15 18:31, 10F
→
01/15 18:31, 10月前 , 11F
預期。然後同義詞機制要重新設計，通常是在 query time
01/15 18:31, 11F
→
01/15 18:31, 10月前 , 12F
先展開比較單純好維護。然後地點看你是想要真的依照經緯
01/15 18:31, 12F
→
01/15 18:31, 10月前 , 13F
度找還是單純用關鍵字，演算法差很多
01/15 18:31, 13F
→
01/15 18:34, 10月前 , 14F
如果是你這需求，從 schema design 就錯了，不如說
01/15 18:34, 14F
→
01/15 18:34, 10月前 , 15F
說你們做了什麼優化好了XD
01/15 18:34, 15F
→
01/15 18:35, 10月前 , 16F
排關聯度就單純很多，同常就命中的詞 + BM25 + 設欄位權
01/15 18:35, 16F
→
01/15 18:35, 10月前 , 17F
重。雖然進階的應該要用使用者 log 去用 ML 做 ranking，
01/15 18:35, 17F
→
01/15 18:35, 10月前 , 18F
不過看起來你們的進度連初階 elasticsearch 功能都還沒正
01/15 18:35, 18F
→
01/15 18:35, 10月前 , 19F
確使用，也就是我前面說的你們可能連 recall 都不好
01/15 18:35, 19F
→
01/15 18:36, 10月前 , 20F
其次，你們的需求&量級用到 elasticsearch 感覺有
01/15 18:36, 20F
→
01/15 18:36, 10月前 , 21F
點殺雞用牛刀了，可以試試 Meilisearch 這種小型的
01/15 18:36, 21F
→
01/15 18:36, 10月前 , 22F
，你們應該會快樂很多，也不用懂那麼多
01/15 18:36, 22F
→
01/15 18:37, 10月前 , 23F
其實你可以善用 chatGPT 應該可以有簡單的理解。也可以嘗
01/15 18:37, 23F
→
01/15 18:37, 10月前 , 24F
試自己架 elasticsearch，應該還不需要寫到 code，除了匯
01/15 18:37, 24F
→
01/15 18:37, 10月前 , 25F
大量資料以外
01/15 18:37, 25F
→
01/15 19:00, 10月前 , 26F
這是pm責任嗎？
01/15 19:00, 26F
噓
01/15 19:07, 10月前 , 27F
連問題都說不清楚 這PM
01/15 19:07, 27F
推
01/15 19:37, 10月前 , 28F
看你說明是想要用天空樹也搜尋到晴空塔之類的，那就是同義
01/15 19:37, 28F
→
01/15 19:37, 10月前 , 29F
詞
01/15 19:37, 29F
→
01/15 19:37, 10月前 , 30F
然後再來針對搜尋的關鍵字去做中文、英文分詞，資料入庫時
01/15 19:37, 30F
→
01/15 19:37, 10月前 , 31F
就會去做索引，再加上個英文大小寫或是簡繁的 filter，後
01/15 19:37, 31F
→
01/15 19:37, 10月前 , 32F
面再記錄一下搜尋熱門關鍵字，去維護 dict 或是 synonym
01/15 19:37, 32F
推
01/15 21:00, 10月前 , 33F
這問題有說不好嗎？好奇
01/15 21:00, 33F
→
01/15 21:26, 10月前 , 34F
感覺也沒到不好 就不足以判斷問題在哪裡吧
01/15 21:26, 34F
推
01/15 22:04, 10月前 , 35F
用json dsl組full text search理論上會得到你要的
01/15 22:04, 35F
→
01/15 22:04, 10月前 , 36F
東西才對,如果還是不行，那就是分詞問題，比較不好
01/15 22:04, 36F
→
01/15 22:04, 10月前 , 37F
處理喔
01/15 22:04, 37F
→
01/15 23:46, 10月前 , 38F
他問題不是同義詞，而是搜尋的結果差強人意
01/15 23:46, 38F
→
01/15 23:46, 10月前 , 39F
這東西很主觀
01/15 23:46, 39F
→
01/15 23:48, 10月前 , 40F
這不太適合新手寫..
01/15 23:48, 40F
推
01/16 06:17, 10月前 , 41F
你家工程師該煩惱的事丟給你在煩惱快跑ㄅ
01/16 06:17, 41F
→
01/16 08:08, 10月前 , 42F
先定義一個分數來表示「糟糕程度」再來根據分數做調整
01/16 08:08, 42F
→
01/16 08:08, 10月前 , 43F
這個分數要跟你們商業上的需求一致
01/16 08:08, 43F
推
01/16 08:10, 10月前 , 44F
這發文，大概連怎樣評價搜尋引擎的指標都不懂吧，只靠感覺
01/16 08:10, 44F
→
01/16 08:10, 10月前 , 45F
。做PM啊，先去了解一下怎麼樣量化自己產品的品質水準。1.
01/16 08:10, 45F
→
01/16 08:10, 10月前 , 46F
先學搜尋引擎常見評價指標。2. 根據自己產品，選擇適合的
01/16 08:10, 46F
→
01/16 08:11, 10月前 , 47F
指標(別硬抄網路上的)3. 設計一個上線前，必需測過的多個
01/16 08:11, 47F
→
01/16 08:11, 10月前 , 48F
測試案例。評價測試案例得到的分數。4.針對沒過的案例，再
01/16 08:11, 48F
→
01/16 08:11, 10月前 , 49F
來與技術人員討論，這個案例怎麼改善。沒這流程，只會造成
01/16 08:11, 49F
→
01/16 08:11, 10月前 , 50F
搜尋引擎改了A，卻產生新的Bug或副作用而已。
01/16 08:11, 50F
→
01/16 08:13, 10月前 , 51F
不要靠"感覺"或"單一case"來決定好壞。硬是解決了一個case
01/16 08:13, 51F
→
01/16 08:13, 10月前 , 52F
，只常會造成其他case變差。
01/16 08:13, 52F
推
01/16 09:01, 10月前 , 53F
推樓上，做任何事情前最重要的就是先把 metric 訂好
01/16 09:01, 53F
噓
01/16 10:07, 10月前 , 54F
實作結果與需求不符，怎不直接打回去重弄就好了?
01/16 10:07, 54F
→
01/16 10:07, 10月前 , 55F
能優化的都做了 => 結果很爛 = 沒做
01/16 10:07, 55F
推
01/16 11:12, 10月前 , 56F
....我覺得語氣沒不好。大家壓力好大...
01/16 11:12, 56F
推
01/16 11:39, 10月前 , 57F
遇到鳥PM大家火氣都很大
01/16 11:39, 57F
推
01/16 12:41, 10月前 , 58F
先確認一下，是 ElasticSearch 7 還是 8 呢？
01/16 12:41, 58F
推
01/16 18:56, 10月前 , 59F
expalin看看分數吧,搞不好你們有動到排序他會完全不吃scor
01/16 18:56, 59F
→
01/16 23:50, 10月前 , 60F
ES...好久沒聽到這個詞了 都是說OS惹拔
01/16 23:50, 60F
推
01/17 22:16, 10月前 , 61F
好奇你的糟是指搜尋速度慢 還是達不到想要的效果
01/17 22:16, 61F
噓
01/17 22:36, 10月前 , 62F
嘻嘻，終於有讀書人的問題了，不是碼工的問題了。
01/17 22:36, 62F
噓
01/18 21:15, 10月前 , 63F
噓射後不理
01/18 21:15, 63F
噓
01/19 00:21, 10月前 , 64F
連mapping都沒放上來也想問ES問題喔
01/19 00:21, 64F
‣ 更多 DOC 的文章
文章代碼(AID): #1bfFyRg0 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 DOC 的文章
文章代碼(AID): #1bfFyRg0 (Soft_Job)