搜索结果不相关，很多时候原因在内容侧：标签口径不统一、用户说法没有被同义词覆盖、结果页缺少收窄入口。本文给出一套可对照的改进路径：先记录不相关查询建立基线，再按标签、同义词、筛选提示分层治理，最后用同一批查询验证效果。范围限于内容可检索性维护，不涉及搜索算法改造。
要点总览（TL;DR）
- 先建检索基线：记录查询词、当前返回条目、用户实际想找的内容，并归类为标签缺失、同义词未覆盖或筛选入口不清，后续改进与验证都围绕这批样本展开。
- 治理顺序按依赖关系排：先合并同义标签、建立受控词表，再把同义词挂到稳定标签上，最后在结果页按标签维度提供筛选提示，顺序颠倒会返工。
- 同义词从搜索日志和用户反馈中提取高频未命中说法，登记来源查询、映射目标与登记人；一词多义的说法拆成多条映射并注明适用语境。
- 用同一批查询在改进前后对照，观察不相关结果占比、二次搜索率和筛选点击情况；数字来自实际记录，没有数据时标注为演示假设。
- 内容量很小或查询高度集中时，优先修单个高频条目；标签治理需要持续人力，初期集中清理成本最高。
当前做法与目标：先建立可对照的检索基线
改进检索相关性，第一步是把现状记录下来，形成一份可以前后对照的基线表。没有基线，后续补齐标签或同义词之后，很难判断不相关结果是否真的减少，也容易把其他因素带来的变化误认为治理成效。
基线表围绕三类信息组织：现有维护实践的规模、不相关搜索的样本、以及改进目标的定义。规模部分记录当前标签总数、有标签的内容条目占比、同义词表的条目数量，这些数字用于判断治理工作量。样本部分逐条记录查询词、当前返回的条目、用户实际想找的内容，以及初步的问题归类。目标部分明确本次改进要降低的是不相关结果占比，标签数量增加只是过程指标。
| 字段 | 记录内容 | 示例（演示假设） |
|---|---|---|
| 查询词 | 用户实际输入的词 | “报销标准 出差” |
| 当前返回 | 搜索结果前几条的标题与标签 | 《差旅申请流程》《费用报销制度（旧版）》 |
| 期望结果 | 用户实际想找的条目 | 《2024年差旅费用报销标准》 |
| 问题归类 | 标签缺失 / 同义词未覆盖 / 筛选入口不清 | 同义词未覆盖：“报销标准”未映射到“费用报销”标签 |
样本来源可以是搜索日志中点击率低或紧接二次搜索的查询，也可以是用户直接反馈的“搜不到”案例。样本量不必很大，覆盖高频查询和典型问题类型即可。基线表建立后，本文的改进动作都围绕它展开，效果验证也回到同一批查询上。
瓶颈与误区：不相关结果通常卡在三个环节
把基线表中的样本按原因归类，多数不相关结果会落在三个环节：标签口径、同义词覆盖、结果页筛选提示。三类问题的表现不同，处理方式也不同，混在一起讨论容易导致动作失焦。
标签口径不统一
同一类内容存在多个并行标签，比如“费用报销”“报销”“财务报销”同时使用；或者标签层级混乱，产品名和文档类型混在同一层；又或者标签过粗，一个“制度”标签下挂着几百条内容，检索时无法区分。标签过细同样有问题，维护成本上升，用户也很难选对。基线表中如果出现“期望结果其实有标签，但标签名与查询词对不上”，通常属于这一类。
同义词表长期不更新
用户会用口语、缩写、旧称、部门内部叫法来搜索，而同义词表停留在建立时的版本。新业务上线、组织调整、产品改名之后，旧说法没有补充映射，新说法也没有登记。基线表中“查询词与目标条目的标签字面不同但含义接近”的样本，基本可以归入同义词缺口。
结果页缺少筛选提示
有些查询本身范围就宽，比如只输入“合同”，用户可能想找合同模板、审批流程或签署规范。此时即使标签齐全，结果页如果没有按文档类型、产品线等维度提供可见筛选项，用户仍要在大量结果中翻找。筛选入口不清的样本特征是：返回结果中确实包含目标条目，但位置靠后，用户没有继续往下看。
两个常见误区
第一个误区是把不相关全部归因于搜索算法，跳过内容侧检查就直接要求调整排序。标签和同义词的缺口不补齐，排序优化能起的作用有限。第二个误区是靠堆标签数量解决，给每条内容打上大量近义标签，短期看似覆盖了更多查询，长期会让标签体系失去区分度，维护和评审都变得困难。同义词维护中还有一个容易忽略的问题：只做一对一映射，把“报销”简单等同于“费用报销”，忽略了一词多义。比如“报销”在某些团队语境下指报销流程，在另一些语境下指报销标准，映射目标需要结合业务语境确定。
优先改进动作：标签、同义词、筛选提示的分层治理
三类缺口的处理有先后顺序。标签是底座，同义词要挂到稳定的标签上，筛选提示则依赖标签维度本身清晰。顺序颠倒会导致返工，比如先扩充同义词、后合并标签，同义词映射需要重做一遍。
第一步：治理标签，建立受控词表
由内容维护负责人牵头，把现有标签导出，按业务对象归类，合并同义标签，确定标签层级和命名规则。命名规则至少覆盖三点：同一概念只保留一个正式名称，其余作为同义词登记；标签按“业务对象—文档类型”等固定维度分层；每个标签写明适用范围和一条正例。治理完成后形成受控词表，作为后续新增内容的唯一标签来源。这一步的作用机制是减少“同一内容多种标签”造成的检索分散，让查询能稳定命中同一批条目。
第二步：补同义词，从搜索日志提取高频未命中说法
从基线表和搜索日志中筛出高频的未命中查询，逐条判断应映射到哪个受控标签或具体条目。映射关系登记在同义词表中，注明来源查询、映射目标、登记日期和登记人。对一词多义的说法，拆成多条映射并注明适用语境，避免把不同意图的查询导向同一结果。同义词表按月或按双周复核一次，新业务上线、产品改名时同步更新。这一步的作用机制是让用户的自然说法能对上受控标签，扩大有效命中的查询范围。
第三步：在结果页提供筛选提示
按受控标签的主要维度，在搜索结果页提供可见的筛选项，比如按产品线、文档类型、生效状态收窄。筛选提示的文案直接使用受控词表中的正式名称，与标签保持一致。对范围较宽的查询，可以在结果上方提示“可按文档类型筛选”，引导用户主动收窄。这一步不改变召回范围，作用在于帮助用户在结果较多时快速定位，减少因翻找失败而产生的二次搜索。
第四步：建立新增内容的标签规则，防止问题回流
在内容发布流程中加入标签必填和评审环节：新增或大改的知识条目必须从受控词表中选择标签，由内容负责人或指定评审人确认标签是否准确、是否需要补充同义词。评审记录与条目状态关联，便于后续追溯。没有这道规则，集中治理的成果会在几个月内被新增内容稀释。
| 动作 | 责任角色 | 执行顺序 | 作用机制 |
|---|---|---|---|
| 标签受控词表与合并 | 内容维护负责人 | 1 | 消除同义标签并存，稳定命中范围 |
| 同义词表补充与复核 | 内容维护人 + 一线支持人员 | 2 | 覆盖用户口语与旧称，扩大有效查询 |
| 结果页筛选提示 | 知识库管理员 | 3 | 帮助用户在宽查询下快速收窄 |
| 新增内容标签必填与评审 | 内容负责人 + 评审人 | 持续 | 防止标签口径再次分散 |
执行时按影响面排序：先处理基线表中出现频次最高的查询所涉及的标签和同义词，再逐步覆盖长尾。集中治理阶段可以按周排期，每周固定处理一批高频样本，处理完即记录状态，便于后续验证时区分已处理和未处理的部分。
这套流程涉及条目状态、评审记录和责任人的持续交接。在ONES中，知识条目可以作为文档承载标签与同义词登记信息，标签补齐、同义词复核和评审确认可以拆成工作项分配给对应角色，状态流转和评审意见留在同一处，便于按周检查治理进度。具体功能范围以实际使用的产品版本为准。
适用前提与代价：哪些条件决定改进能否落地
这套方法依赖两个前提：能拿到不相关样本，以及有人对标签体系负责。两个前提都满足时，按上述顺序推进即可；缺少其中一个，需要先补条件或缩小范围。
| 条件 | 不满足时的替代做法 |
|---|---|
| 有搜索日志或用户反馈渠道 | 先用支持团队收到的“搜不到”反馈和访谈记录建立小样本，同时推动搜索日志留存 |
| 有明确的内容维护责任人与标签规则 | 先指定一名临时负责人，只治理高频查询涉及的少量标签，规则随治理过程逐步成文 |
| 内容量达到一定规模、查询分布较分散 | 内容量很小或查询高度集中时，优先修单个高频条目，暂缓搭建完整标签体系 |
投入方面，标签治理和同义词整理属于持续性工作，初期集中清理的成本最高，需要投入较多人力做标签合并、层级调整和同义词登记；进入常态后，主要成本是新增内容的标签评审和同义词表的定期复核。标签粒度需要在维护负担和收窄效果之间取平衡：过细会增加每条内容的打标和评审时间，过粗则筛选提示起不到区分作用。建议先按业务对象和文档类型两个维度建立层级，运行一段时间后再根据查询样本决定是否细分。
效果验证：用同一批查询对照改进前后
验证的核心是用基线表中的同一批查询，在改进后重新执行，逐条对比返回结果与期望结果是否一致。同一批查询保证前后可比，避免换一批查询后得出无法归因的结论。
| 查询样本 | 改进前返回 | 改进后返回 | 指标变化 | 结论 |
|---|---|---|---|---|
| “报销标准 出差” | 目标条目未出现 | 目标条目出现在前三条 | 该样本由不相关转为命中 | 同义词补充生效 |
| “合同” | 目标条目在第 12 条 | 筛选“合同模板”后第 2 条 | 筛选点击 1 次 | 筛选提示生效 |
观察指标建议包括三项：不相关结果占比，即样本中返回结果与期望不符的比例；用户二次搜索率，即同一会话内用户修改查询词再次搜索的比例；筛选点击情况，即结果页筛选项被使用的频次和分布。三项指标从不同角度反映相关性变化，结合起来看比单一指标更可靠。
验证需要设置观察周期，比如治理完成后连续观察两到四周，再与基线对比。周期内如果同时上线了其他影响检索的改动，需要在记录中注明，避免把变化全部归因于标签和同义词治理。所有数字应来自实际记录；没有实际数据时，表格中的数值应明确标注为演示假设，不作为结论依据。
如果验证结果显示不相关占比没有明显下降，回到瓶颈归类环节，检查剩余样本卡在哪个环节：是高频标签仍未合并，是同义词映射遗漏了一词多义的情况，还是筛选入口的位置和文案不够清楚。按缺口补充后再次用同一批查询验证，形成“记录样本—归类—补齐—复测”的循环。每一轮循环都保留记录，几轮之后可以看清哪类缺口最常出现，据此调整新增内容的标签评审重点。
常见问题
标签和同义词都补齐了，为什么仍有查询返回不相关结果？
先回到基线表逐条核对剩余样本的归类。常见情况有三类：一是查询本身范围很宽，比如只输入“合同”，用户意图可能是模板、审批流程或签署规范，这时需要靠结果页筛选提示收窄，标签和同义词解决不了意图歧义；二是同义词映射只做了一对一，把口语说法导向了错误语境下的条目；三是目标条目本身内容陈旧或标题与正文主题不符，检索命中后用户仍认为不相关。
处理时按“标签—同义词—筛选提示—条目内容”的顺序排查，每轮只改一类，再用同一批查询复测，避免多类改动同时上线后无法归因。
同义词表应该多久复核一次，由谁负责？
复核频率取决于业务变化速度。新业务上线、产品改名、组织调整较频繁的团队，建议按月或按双周复核；变化较少的团队可以按季度。复核内容至少包括：新增的高频未命中查询是否已登记映射、旧映射目标是否仍然有效、一词多义条目是否需要拆分。
责任上建议由内容维护人主责，一线支持人员参与，因为他们最先接触到用户“搜不到”的反馈。每次复核记录日期和变更内容，便于后续验证时区分哪些改进已经生效。
标签粒度应该多细，有没有判断标准？
判断标准是维护负担与收窄效果的平衡。过细会增加每条内容的打标和评审时间，用户也难以选对；过粗则筛选提示起不到区分作用，比如一个“制度”标签下挂着几百条内容。
可操作的做法是先按业务对象和文档类型两个维度建立层级，运行一段时间后，看基线表中哪些查询因为标签过粗而无法收窄，再决定是否细分。细分时优先处理高频查询涉及的维度，长尾部分暂缓。
没有搜索日志，还能做这套改进吗？
可以先用小样本起步。从支持团队收到的“搜不到”反馈、用户访谈记录、群聊中的提问里整理查询样本，按基线表的字段记录查询词、当前返回和期望结果。样本量不必大，覆盖高频查询和典型问题类型即可。
同时推动搜索日志留存，日志可用后替换或扩充样本。需要注意的是，靠反馈收集的样本偏向已经表达出来的问题，沉默用户遇到的搜索困难可能没有被覆盖，结论的适用范围要相应收窄。
改进效果如何与同时上线的其他改动区分开？
在验证记录中注明观察周期内同时发生的其他改动，比如排序调整、内容批量迁移或页面改版。如果条件允许，把标签和同义词治理的改动与其他改动错开时间上线，给每类改动留出独立的观察窗口。
无法错开时，用样本级对比代替整体指标：逐条看基线表中的查询在改进后是否命中期望结果，并标注该样本对应的是哪类改动。样本级证据比整体不相关占比更能说明具体动作是否生效。
