一、项目背景

某企业用我们 RAG 知识库底座搭了内部问答，上线头两周一片好评，高频的怎么报销、年假几天答得飞快。但慢慢有员工在群里吐槽，问了个偏门的专有名词，比如某个内部系统缩写加版本号，它要么答非所问，要么硬编。我们拉了日志一看，长尾 query 的 top3 准确率比高频低了快三十个点，而长尾恰恰是最费人工、最该让模型接住的那些问法。更要命的是，长尾问法往往来自新员工或跨岗协作，答错了比不答更糟，人家照着错答案去操作，后面救火的成本比多答对数十个高频问题还高，所以我们把长尾命中率当成这个项目的头号指标。

二、落地场景

这个项目专攻长尾召回。我们对检索做了词权重调参，给专有名词、缩写、产品代号更高的权重，不再和通用词一视同仁。同时建了同义词和缩写扩展表，员工打 CRM-V2 能映射到客户关系管理系统第二版等若干表述。我们还专门攒了一批长尾评测 query，每次召回策略改动都跑一遍，看长尾命中率动没动，不让高频的好掩盖长尾的坏。运营侧接了召回质量看板，能按部门看长尾问法的答准率，哪个业务域的生僻问法最容易翻车一目了然。

三、关键技术挑战与解决思路

头一个难处是词权重怎么定。通用 BM25 对所有词平等，但内部知识库里 V2、灰度、回滚这些词信息量极大，我们给这类词加了 boost，权重从 1.0 提到 2.5，长尾召回立刻好转。第二是同义扩展别过度，早期我们把缩写扩太宽，反而引入噪声把正确文档挤下去，后来改成精确匹配优先、扩展仅作召回补充，精排阶段不再被噪声带偏。第三是长尾评测集的维护，长尾问法散在员工真实提问里，我们写了个脚本定期从拒答和低分回答里捞候选，人工标完进评测集，集子从 200 条长到 1200 条，覆盖才够。第四是召回和生成的分工，召回错了生成再强也白搭，我们先死磕召回，再让生成层只基于召回文档作答，杜绝它凭空编。

案例片段（已脱敏）： 检索词权重配置片段：boost_terms: {"V2": 2.5, "灰度": 2.0, "回滚": 2.0, "SLA": 1.8}，其余默认 1.0；扩展表 CRM-V2 -> ["客户关系管理系统 第二版", "crm 2.0"]，仅参与召回补充，不参与精排打分。 长尾评测结果（脱敏）：评测集 1200 条，调参前 top3 准确率 61%，调参后 83%，拒答率从 14% 降到 5%，人工纠错工单周均降 40%。

四、效果数据

词权重调参加同义扩展后，长尾 query 的 top3 准确率从 61% 提到 83%，拒答率从 14% 降到 5%，新员工跨岗问法的答准率明显上来，群里那种"它又瞎编"的吐槽少了一大半。员工关于答非所问的吐槽周均下降约四成，知识库运营终于敢在主群推全员使用了。高频 query 准确率保持不动，说明改动没伤到主体，没出现"顾此失彼"。评测集覆盖从 200 条扩到 1200 条后，长尾问题暴露更全，每次改动前跑一遍心里有底。文中数据为项目复盘口径，已做脱敏。

长尾评测集现在是这个知识库团队的固定资产，每次召回或生成改动都先跑它，集子也一直在长，从员工真实提问里持续捞。我们后来把长尾命中率和拒答率做成了知识库运营的周报头两个指标，哪块业务域的生僻问法最容易翻车，运营一眼就能定位去补文档。生成层我们也加了引用可见，答案里标出它基于哪段召回文档，员工发现答错能直接反推是召回还是生成的问题，定位快了不止一倍。召回和生成两层职责划清之后，幻觉类投诉明显少了，知识库才敢在主群全面推。

同义扩展表我们后来做成了可运营的资产，业务方发现新缩写或黑话，直接提工单加进表，不用等研发排期。我们还加了一层召回去重，同一文档被多个扩展词命中时只计一次，避免长尾 query 被单一文档刷屏挤掉其他候选。之前出现过扩展太宽导致 top3 全是同一篇的情况，加上去重后多样性回来了。长尾命中率稳在八成以上之后，知识库运营终于愿意在主群推全员使用，之前怕生僻问法翻车不敢大声推，现在底气足了，员工提问量反而上来了。

长尾这块的投入我们觉得值，因为它直接关系到员工愿不愿意真的用起来，答准了才留得住人，知识库的价值全在日活上。

五、可复用经验总结

RAG 上线别被高频好评骗了，真正的短板永远在长尾，那批生僻问法才是员工最想甩给系统的活，答准了才显价值，答错了反而添乱。词权重要敢于给专有名词加码，默认平等是对内部知识库的误用，通用语料训出来的权重放到企业内网会水土不服。同义扩展是双刃剑，扩太宽引入噪声比不扩还糟，我们栽过这跟头，后来严格限定为召回补充才稳。评测集得自己养，从真实拒答里捞比凭空编靠谱得多，集子够大才敢说召回稳了。生成层一定要基于召回文档作答，召回错了就别指望它救场，这层边界我们划清之后幻觉少了一大截。