作者DOC (锻链的还不够)
看板Soft_Job
标题[请益] Elastic Search结果惨烈怎麽修
时间Mon Jan 15 17:47:05 2024
小弟是网路公司的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://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1705312027.A.A80.html
1F：→ srwhite: 50万笔听起来没有很大(? 你们是用like去查吗 01/15 17:55
3F：→ kewang: 些可以参考，但都是旧版的方式了，有空再写新版的方式 01/15 18:06
4F：嘘 B0988698088: 怎麽个糟法？连举例都不会不要当pm害人好吗 另外官 01/15 18:23
5F：→ B0988698088: 方不是有sup吗？官方对於这case给的回应是什麽 01/15 18:23
6F：推 Sunal: 发现k旺？ 01/15 18:25
7F：→ Lordaeron: 我认为B0988698088 应该有SOLUTION的，出一篇吧。 01/15 18:26
8F：推 alihue: 你要先厘清是 recall 还是 ranking 问题。换句话说是搜寻 01/15 18:31
9F：→ alihue: 结果没有命中还是单纯排序太後面。此外对 input 拆词後是 01/15 18:31
10F：→ alihue: 采用什麽样语法搜寻，以及需要检查拆词後的结果符不符合 01/15 18:31
11F：→ alihue: 预期。然後同义词机制要重新设计，通常是在 query time 01/15 18:31
12F：→ alihue: 先展开比较单纯好维护。然後地点看你是想要真的依照经纬 01/15 18:31
13F：→ alihue: 度找还是单纯用关键字，演算法差很多 01/15 18:31
14F：→ johnny9144: 如果是你这需求，从 schema design 就错了，不如说 01/15 18:34
15F：→ johnny9144: 说你们做了什麽优化好了XD 01/15 18:34
16F：→ alihue: 排关联度就单纯很多，同常就命中的词 + BM25 + 设栏位权 01/15 18:35
17F：→ alihue: 重。虽然进阶的应该要用使用者 log 去用 ML 做 ranking， 01/15 18:35
18F：→ alihue: 不过看起来你们的进度连初阶 elasticsearch 功能都还没正 01/15 18:35
19F：→ alihue: 确使用，也就是我前面说的你们可能连 recall 都不好 01/15 18:35
20F：→ johnny9144: 其次，你们的需求&量级用到 elasticsearch 感觉有 01/15 18:36
21F：→ johnny9144: 点杀鸡用牛刀了，可以试试 Meilisearch 这种小型的 01/15 18:36
22F：→ johnny9144: ，你们应该会快乐很多，也不用懂那麽多 01/15 18:36
23F：→ alihue: 其实你可以善用 chatGPT 应该可以有简单的理解。也可以尝 01/15 18:37
24F：→ alihue: 试自己架 elasticsearch，应该还不需要写到 code，除了汇 01/15 18:37
25F：→ alihue: 大量资料以外 01/15 18:37
26F：→ layer0930: 这是pm责任吗？ 01/15 19:00
27F：嘘 johnbill: 连问题都说不清楚 这PM 01/15 19:07
28F：推 pvq212: 看你说明是想要用天空树也搜寻到晴空塔之类的，那就是同义 01/15 19:37
29F：→ pvq212: 词 01/15 19:37
30F：→ pvq212: 然後再来针对搜寻的关键字去做中文、英文分词，资料入库时 01/15 19:37
31F：→ pvq212: 就会去做索引，再加上个英文大小写或是简繁的 filter，後 01/15 19:37
32F：→ pvq212: 面再记录一下搜寻热门关键字，去维护 dict 或是 synonym 01/15 19:37
33F：推 qazwsx12: 这问题有说不好吗？好奇 01/15 21:00
34F：→ ku399999: 感觉也没到不好 就不足以判断问题在哪里吧 01/15 21:26
35F：推 internetms52: 用json dsl组full text search理论上会得到你要的 01/15 22:04
36F：→ internetms52: 东西才对,如果还是不行，那就是分词问题，比较不好 01/15 22:04
37F：→ internetms52: 处理喔 01/15 22:04
38F：→ layer0930: 他问题不是同义词，而是搜寻的结果差强人意 01/15 23:46
39F：→ layer0930: 这东西很主观 01/15 23:46
40F：→ layer0930: 这不太适合新手写.. 01/15 23:48
41F：推 guanting886: 你家工程师该烦恼的事丢给你在烦恼快跑ㄅ 01/16 06:17
42F：→ jigfopsda: 先定义一个分数来表示「糟糕程度」再来根据分数做调整 01/16 08:08
43F：→ jigfopsda: 这个分数要跟你们商业上的需求一致 01/16 08:08
44F：推 DrTech: 这发文，大概连怎样评价搜寻引擎的指标都不懂吧，只靠感觉 01/16 08:10
45F：→ DrTech: 。做PM啊，先去了解一下怎麽样量化自己产品的品质水准。1. 01/16 08:10
46F：→ DrTech: 先学搜寻引擎常见评价指标。2. 根据自己产品，选择适合的 01/16 08:10
47F：→ DrTech: 指标(别硬抄网路上的)3. 设计一个上线前，必需测过的多个 01/16 08:11
48F：→ DrTech: 测试案例。评价测试案例得到的分数。4.针对没过的案例，再 01/16 08:11
49F：→ DrTech: 来与技术人员讨论，这个案例怎麽改善。没这流程，只会造成 01/16 08:11
50F：→ DrTech: 搜寻引擎改了A，却产生新的Bug或副作用而已。 01/16 08:11
51F：→ DrTech: 不要靠"感觉"或"单一case"来决定好坏。硬是解决了一个case 01/16 08:13
52F：→ DrTech: ，只常会造成其他case变差。 01/16 08:13
53F：推 jigfopsda: 推楼上，做任何事情前最重要的就是先把 metric 订好 01/16 09:01
54F：嘘 ZakuSIN: 实作结果与需求不符，怎不直接打回去重弄就好了? 01/16 10:07
55F：→ ZakuSIN: 能优化的都做了 => 结果很烂 = 没做 01/16 10:07
56F：推 sw12: ....我觉得语气没不好。大家压力好大... 01/16 11:12
57F：推 DarkIllusion: 遇到鸟PM大家火气都很大 01/16 11:39
58F：推 untitled: 先确认一下，是 ElasticSearch 7 还是 8 呢？ 01/16 12:41
59F：推 ns1234: expalin看看分数吧,搞不好你们有动到排序他会完全不吃scor 01/16 18:56
60F：→ peter98: ES...好久没听到这个词了 都是说OS惹拔 01/16 23:50
61F：推 bitcch: 好奇你的糟是指搜寻速度慢 还是达不到想要的效果 01/17 22:16
62F：嘘 darkMood: 嘻嘻，终於有读书人的问题了，不是码工的问题了。 01/17 22:36
63F：嘘 FXW11314: 嘘射後不理 01/18 21:15
64F：嘘 ashlikewing: 连mapping都没放上来也想问ES问题喔 01/19 00:21