提升知识库问答准确率的工程手段

一、问题的起点：为什么「搭好了」却「答不准」

很多团队做知识库问答，第一个版本跑通得很快：把文档灌进去，接上模型，问几句似乎也能答。但一放到真实使用场景里，问题就暴露了——答案似是而非、引用错了文档、该说「不知道」的时候瞎编、同一个问题今天答得对明天答得错。于是常见的反应是「换个大模型试试」，但换完之后往往没有明显改善。

原因在于：知识库问答的准确率，主要不取决于模型，而取决于模型之外的那套工程。 模型是最后一步的「组织语言」，而在此之前，系统要做三件事——把文档切成合适的粒度、在提问时把它们准确地找出来、按合理的顺序喂给模型。这三步里任何一步出问题，再强的模型也只能在错误的材料上作答。业界把这套流程称为检索增强生成（RAG），而它的准确率是一个可以用工程手段逐步提升的指标。

本文按数据流顺序拆解提升准确率的五个环节：召回质量、重排、上下文组织、拒答策略、评测与回归。顺序很重要——上游的缺陷无法靠下游弥补，如果召回的内容根本不含答案，重排和提示词再讲究也没用。这也是我们建议「先诊断哪一环最弱，再针对性投入」的原因。

二、召回质量：先保证「找得到」

召回是整个链路的地基，目标是「答案所在的片段，一定要被找出来」。这一步如果漏了，后面的环节全都没有意义。影响召回质量的因素集中在三处。

切分策略

切分决定了一段检索的最小单位。切得太碎，一个完整的意思被拆散，检索到半句话无法作答；切得太整，一段里混了好几个主题，噪音多、精度低。常见的做法有几种：

• 按结构切。优先使用文档自身的结构——标题、章节、段落，让每段语义相对完整。这是多数场景的默认选择。
• 按长度切并留重叠。对没有明显结构的文本，按固定长度切分，但相邻两段保留一定重叠，避免关键句正好落在切分点上被割断。
• 按语义切。用模型判断语义边界，适合结构混乱的文档，但成本和复杂度更高。
• 带上下文切。在每段前面附上它所属的章节标题甚至文档标题，让脱离原文的片段依然能保留语境。这一条在实际中作用明显，因为「第 3 条：不超过 30 天」单独看毫无意义，附上「关于退款期限的规定」才可检索可理解。

切分没有通用的标准答案，它和你的文档形态、问题类型强相关。可行的做法是先固定一种，用评测集测出问题，再针对性调整。

向量化与关键词的结合

纯向量检索擅长语义相近的匹配，但对精确词（编号、产品型号、专有名词、代码）容易失手——因为这些词的语义表示往往不够区分。反过来，传统的关键词检索（如 BM25）对精确词很准，但对同义改写无能为力。因此实践中多数系统采用混合检索：向量召回与关键词召回各取一批，合并去重后再进入下一步。这样既能接住「这句话换个说法怎么问」，也能接住「某个具体编号是什么」。

元数据的过滤

不是所有文档都该被平等对待。如果系统知道提问者是谁、属于哪个部门、问的是哪类业务，就可以在检索前先用元数据缩小范围。这一层过滤有两重价值：一是提高精度（把无关领域的内容先排除），二是控制权限（不能让用户检索到他无权访问的文档）。权限过滤必须做在召回阶段，而不是在回答之后。 若先召回后过滤，敏感内容已经进入了模型的上下文，存在被间接泄露的风险。

三、重排：把「相关的」排到前面

召回的初步结果通常有几十甚至上百条，但最终能进入模型上下文的只有几条。谁进谁出，由重排决定。重排做得好不好，直接决定了模型看到的是「最有用的三条」，还是「三条有点相关但没用」的内容。

召回阶段用的是「粗排」，追求快和全；重排阶段用的是「精排」，追求准。二者的关系是漏斗：召回宁可多召回一些（保证不漏），重排负责挑出真正最能回答问题的（保证不偏）。

重排的常见做法是引入一个专门的排序模型，对「问题—候选片段」的匹配度做更精细的打分。相比召回用的向量相似度，重排模型能捕捉更细的语义关联，比如问题问的是「原因」，而某段讲的是「结果」，二者语义接近但不是答案——这类细微差别，粗排容易误判，精排更容易识别。

重排中最容易被忽略的一点是多样性。如果前三条都来自同一份文档的相邻段落，等于浪费了上下文名额。更好的做法是在保证相关性的前提下，让入选片段覆盖不同的信息点或不同的来源，避免答案被单一来源带偏。

还有一点需要说明：重排是有成本的。它要对每个候选片段做一次额外计算，候选越多、延迟越高。因此重排的候选数量需要权衡——取五十条还是两百条，取决于你对响应速度和准确率的要求。在多数内部知识库场景里，召回数量控制在一个合理区间、重排取前若干条，是性价比更高的选择，而不是无限扩大候选。真正需要优化的，往往不是「多找一些」，而是「找得更准一些」。

四、上下文组织：模型看到的顺序和边界

同样的候选片段，不同的组织方式会让答案质量明显不同。这一步常被低估，但它几乎是「零成本」的提升点。

顺序有影响。 研究表明，模型对上下文中段位置的关注度往往低于开头和结尾。因此一个重要但不紧急的原则是：把最相关的片段放在靠前或靠后的位置，而不是埋在中间。此外，如果同一主题有多条片段，按逻辑顺序（背景—规定—例外）排列，比打乱顺序更容易得到完整答案。

要给出边界。 把片段直接拼接起来，模型很难分清哪里是文档原文、哪里是系统说明。用明确的标记把每段括起来，并标注来源（文档名、章节），既便于模型区分，也便于事后追溯引用。这对需要出处可核查的场景是硬要求。

要控制总量。 上下文不是越多越好。塞得越满，一是成本越高，二是噪音越多，模型越容易被无关信息干扰。一个务实的做法是设置一个上限，让重排后的结果按分数截断，而不是能塞多少塞多少。

要给指令。 在上下文之后，明确告诉模型「只用以下材料回答，材料中没有的信息不要补充」。这一句话的作用，比很多复杂的技巧都直接。

五、拒答策略：知道什么时候说「不知道」

一个知识库问答系统可不可信，不只看它答对的次数，更看它在没有依据时会不会硬答。能拒答的系统才是可用的系统，因为一次编造的答案可能比一次「没找到」造成更大的损失。

拒答不是让模型「感觉不确定就别答」，那样会时灵时不灵。应当把它做成一套有明确触发条件的机制：

• 检索层面：如果重排后的最高分低于某个阈值，说明库里很可能没有相关内容，直接返回「未找到」。这一层的判断在模型之外，稳定且可控。
• 生成层面：要求模型在回答时标注依据的片段；如果它无法指向任何片段，就应当拒答，而不是凭常识作答。
• 规则层面：对超出知识库范围的问题（如涉及外部实时信息、专业医疗法律建议），无论检索结果如何都按预设话术兜底。

拒答的话术也有讲究。好的拒答不是生硬的「无可奉告」，而是告诉用户「我没有找到关于某个问题的资料，你可以换个说法，或联系某某」。这样既避免了错误信息，又给了用户下一步的路径。拒答率本身也是要监控的指标——太高说明知识库覆盖不足，太低则要警惕是在「硬答」。

六、评测与回归：让改进可衡量

前面所有环节的调整，如果没有评测，就变成了凭感觉。评测是这个系统工程里回报最高、却最常被跳过的一步。

第一步，建评测集。 从真实用户提问里挑选一批有代表性、且答案明确的问题（通常几十到几百条即可起步），为每条标注「正确的答案应该来自哪份文档的哪一段」。评测集是资产，需要持续扩充——每当线上发现一个新类型的失败案例，就把它补充进去。

第二步，分层指标。 不要只统计「答对率」，而要把指标拆到每个环节：

环节	关键指标	说明
召回	命中率	答案所在片段是否被召回
重排	首位命中率	最相关片段是否排进前列
生成	忠实度	答案是否只用了给定材料
端到端	正确率、拒答率	用户视角的最终效果

这样拆的好处是，一旦效果变差，能立刻定位到是哪一环退化，而不是笼统地「换个模型」。

第三步，回归。 每次改动（换切分方式、调阈值、换模型、改提示词）后，都跑一遍同一套评测集，对比各层指标的变化。防止出现「修好了 A、弄坏了 B」的情况。改动频繁时，评测应当自动化。

需要提醒的是，评测集要覆盖应当拒答的样本。只测「能答对的」，会系统性高估系统能力，掩盖乱答的问题。

七、落地建议：一个务实的改进顺序

结合上面的拆解，如果效果不达预期，建议按下面的顺序排查和投入，而不是一上来就换模型。

1. 先看召回。抽一批失败案例，人工检查「正确答案所在的片段是否被召回」。如果经常没被召回，问题在切分或向量化，优先解决这里。
2. 再看重排。如果正确答案被召回了但没排进前列，加强重排或调整多样性策略。
3. 然后看上下文组织。检查喂给模型的片段是否带来源标记、顺序是否合理、总量是否失控。
4. 补上拒答机制。设定检索阈值与生成端依据要求，先让系统学会说「不知道」。
5. 最后调模型与提示词。前面都做好了，模型和提示词的边际收益才明显。
6. 全程有评测。改动前先有基线，改动后跑回归，用数据判断有效性。

关于这套链路的工程实现与质量保障，可以参考 工程与质量保障 与 技术能力 中的相关说明。

八、小结

知识库问答的准确率，是一个可以被工程手段持续提升的指标，而不是靠一次「换个更强的模型」解决的问题。它的提升路径有明确顺序：先保证召回不遗漏，再让重排挑出对的，再组织好上下文，然后教会系统拒答，最后用评测把每一步的改进固定下来。上游的问题无法靠下游弥补，这是这套方法最重要的前提。

对投入这件事的判断也很简单：如果系统经常答错，先别急着调模型，花半天时间看看失败案例里，材料到底有没有被找出来。多数时候，答案就在这一步。

如果你的团队正在做企业知识库或智能问答，欢迎把文档形态、使用场景和当前效果讲清楚，我们通常先做一轮效果诊断，再判断该从哪里下手。相关能力说明见 AI 应用与 AIGC 服务 与 常见问题。