※ 引述《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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1705406976.A.CE5.html