※ 引述《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 好太多了。 剩下有空再寫文章分享更細部的東西好了。 -- ※ 發信站: 批踢踢實業坊(pttsite.org.tw), 來自: 49.158.164.63 (臺灣) ※ 文章網址: https://pttsite.org.tw/Soft_Job/M.1705374977.A.B61

推 DrTech: good ，難得正常的技術討論文章 01/16 12:37

推 sw12: 坑都挖好了，要跳還是要走舖好的..... 01/16 14:47

推 TSMCfabXX: 技術推 01/16 16:39

推 HYDE1986: 善良推 01/16 19:31

推 untitled: 提供API務實推 01/16 21:24

推 smilejin: 有人可以分析一下包養平台的差異嗎 01/16 21:24

→ peter98: 支持2 不同語系一定要分開 Data structure也要分開 01/16 23:51

推 yfr: 居然是k旺哥 01/17 13:52

推 crwu: 他們家開發估計對es不太熟 上面需求es很簡單能實現 01/21 01:02