※ 引述《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/