文档问答如何识别无答案并主动拒答

内部文档问答最伤信任的情况，是资料根本没写，助手却答得很肯定。作者用一个公开数据演示提出：先决定系统什么时候该拒答，再讨论怎样生成答案。

这个演示把「引用原文」和「拒绝回答」做成两种正式结果。它也暴露了一个关键局限：找到内容相近的段落，不代表段落真的回答了问题。做知识库问答时，这比回答是否流畅更值得先验证。

检索到相关段落，为什么还不能直接回答

作者提供的入口是 KB.answer(question)，返回三项内容：最佳段落作为引用、该段落确实包含答案的置信度，以及引用或拒答的决定。

它直接返回段落，不生成回答。作者把生成文字留给语言模型，而是否回答，先用检索特征上的小模型判断：

• 第一名段落的检索得分。
• 第一名领先第二名的分差。
• 按逆文档频率（IDF）加权的问题词覆盖率。
• 段落未覆盖的问题词占比。

IDF 加权可以理解为：越少见、越能区分问题的词，权重越高。判断不能只看段落和问题撞上了多少常见词。

这种拆分的价值是方便定位错误。引用选错了，就检查检索和回答判断；引用正确、生成文字却添油加醋，再检查生成环节。

相关性只是回答的线索，不能直接当作答案存在的证据。

95% 的目标，为什么测试只达到 90%

演示使用 SQuAD 2.0 dev 中的 35 篇 Wikipedia 文章，许可为 CC BY-SA 4.0，用百科文章代替企业文档。作者明确说明，这是公开数据上的测试数字，不是客户项目成果。

文章被分成调参集和测试集，拒答阈值在独立文章上调整，目标精确率为 95%。精确率关心的是：系统选择给出引用的回答里，有多少确实答对。

测试还故意把三分之一的测试文章排除在知识库外。这些文章对应的问题必须拒答，才能检验系统遇到知识范围之外的问题时，会不会硬找一个段落交差。

最终测试知识库包含 406 个段落，共评估 4,904 个问题：

项目	原文结果
调参时的目标精确率	95%
仅统计可回答问题时的引用答案精确率	93%
混入知识库外问题后的引用答案精确率	90%
内容接近但没有答案的问题的拒答率	39%

95% 是调参目标，不能写进产品介绍充当测试成绩。作者也承认，阈值只是基于样本得到的估计，需要在客户自己的文档和问题上重新调整。

更值得关注的是 39%。SQuAD 中有一类问题，主题与文档很接近，但文档并没有提供答案。系统只拒绝了其中 39%，说明词汇层面的信号很难识别这种差别。

作者认为，真实系统可以在这里加入重排模型（reranker）或 LLM。不过，原文没有提供加入之后的对照结果。

还有一处信息缺口：作者强调，知识库外问题的拒答率应该写进验收文档，却没有给出这项指标的具体数值。不能拿混合后的 90% 精确率代替它，两者衡量的事情不同。

我的判断

我认同把拒答设为独立结果，也认同为它准备专门的测试集。只测知识库已覆盖的问题，很容易让一个擅长寻找相似段落的系统，看起来像一个知道自己能力边界的系统。

这个演示的另一点价值是保留原文引用。用户可以核验依据，开发者也能看清系统到底选中了什么。但引用存在，仍然不保证引用支持答案。

它的适用前提也很明确：数据来自 Wikipedia，规模和问题分布都有边界，不能直接套到企业 wiki。原文没有给出置信度的校准结果，也没有说明精确率如何判定，因此不能把返回的置信度直接理解成可靠的正确概率。

与直接让 LLM 判断是否有答案相比，这套做法把判断依据拆得更清楚；但谁更准、更省，作者没有提供对照数据。加入 reranker 或 LLM 能改善多少，目前也只是待验证的方向。

能拿来做什么

• 给内部文档助手补两类测试问题：一类完全超出知识库，另一类与文档主题相近、却找不到答案，并分别统计拒答率。
• 在 Node 问答接口中，把引用段落、置信度和回答决定分别返回，让前端可以明确展示「文档未提供答案」，并保留可核验的引用入口。
• 调整拒答阈值时，按文档划分调参集和测试集，再用团队真实问题复测；验收时同时写出精确率、拒答率和仍未解决的失败类型。