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