长上下文知识库测评为何要加入冲突与无答案样例

模型能够接收很长的输入，只说明请求在接口限制内，并不说明它能找出正确段落、引用真实位置或判断哪个版本生效。把一份连续长文档交给模型并成功回答几个问题，更像阅读演示，无法代表由制度、表格、FAQ、代码和会议纪要组成的知识库。有效测评需要故意加入分散事实、旧版冲突、无答案问题和无权限文档，分别观察召回、引用、拒答与访问边界。本文给出一套可复核的数据集设计和评分方法。

先把答案拆成原子事实

不要把一个长答案作为单一标准。以“某流程如何申请”为例，可以拆成：

适用对象
申请入口
必填材料
审批角色
生效条件
例外情况
依据文档与章节

每项分别标记正确、缺失、错误或无依据。这样能区分模型漏掉一个条件和整题答错，也便于回到原文核对。

建立带版本和权限的文档单元

每个测试文档至少有：

doc_id
title
version
effective_at
section_id
access_label
content

版本和权限元数据不能只放在提示词说明中，它们应随每个证据单元传递。权限过滤必须发生在资料进入模型上下文之前，不能要求模型看到未授权内容后“不要回答”。

位置测试要改变事实分布

将目标事实分别放在输入开头、中间和末尾，同时改变干扰材料数量。测试位置时保持事实内容与问题不变，只改变位置；测试内容类型时保持位置不变，只改变文本、表格或代码等形式。

一次同时改变长度、位置和文档类型，无法判断召回变化来自哪个因素。

冲突样例验证版本判断

为同一主题准备旧版与新版材料，并明确各自版本和生效信息。问题要求输出：

当前可确认的规则
采用该版本的依据
与旧版冲突的字段
仍然无法确定的信息

正确结果不一定是选择最新版文件名。若材料没有说明生效关系，模型应报告冲突，不能自行决定哪个版本覆盖另一个。

无答案样例检查是否会补全

加入资料中确实没有答案的问题，并设置预期状态 INSUFFICIENT_EVIDENCE。验收包括：

• 没有生成确定事实；
• 指出缺少哪类信息；
• 不把常识或其他任务记忆当作知识库证据；
• 给出的后续检索建议不冒充已完成调查。

无证据却给出确定结论应单独统计为高风险失败，不能与普通遗漏合并。

权限样例测试上下文构造

创建两个测试角色，为其准备不同可见文档。相同问题在两个角色下运行，检查传入模型的 doc_id 列表，而不只是最终回答。

如果无权限文档已经进入上下文，即使模型这次没有泄露，访问控制仍然失败。应修复检索和权限过滤，而不是增加一句“不要引用”。

引用必须真的支持结论

要求模型输出 doc_id、section_id 和必要的短引用。验证程序检查标识存在，人工再判断引用片段是否支持对应原子事实。

引用准确性至少区分：

标识有效且支持结论
标识有效但不支持结论
标识不存在
结论没有引用

看起来合理的文件名不能当作证据。

分开比较全量上下文和检索上下文

若要判断是否需要每次传入全部资料，建立两个固定变体：

A：经过权限过滤后的全部测试资料
B：同一权限范围内由固定检索配置选出的证据

两组使用同一模型、提示词、问题和验收。记录召回、引用、端到端延迟、实际用量和失败重试。检索配置也需版本化，否则 B 组变化无法复现。

不要预设 RAG 一定更好或长上下文一定更完整，结论由具体任务集决定。

一张最小结果表

同时保留样本量。没有运行的空表只能称为测试计划，不能称为测评结果。

文档注入作为独立安全用例

在测试资料中加入把文档内容伪装成指令的文本，验证系统仍将其视为资料而不是高优先级规则。业务控制不能只靠模型遵循提示词，还应限制工具、输出和外部动作。

若知识库允许 HTML、Markdown 或附件，分别测试隐藏字段、链接和元数据的处理。清洗规则要版本化，并保留原始来源供授权人员回查。

结论与限制

长上下文知识库的核心指标不是“能放多少”，而是原子事实召回、引用支持、冲突处理、正确拒答和权限过滤。通过位置扰动、旧新版材料、无答案与角色权限样例，可以发现简单阅读演示覆盖不到的失败。

本文提供测试协议，没有任何模型的实测数据。结果只适用于记录的文档集、检索版本、权限规则、模型和提示词；生产资料的授权、脱敏与保留仍需单独评审。