档案高质量数据集建成以后：新增资料为什么会让旧答案变坏

上一篇讨论档案高质量数据集时，我把它定义为一组可追溯、可复测、可以持续更新的样本资产。文章发出后，有读者追问：目录、原文、权限、版本和人工判断依据都整理好了，数据集是不是就算建成了？

这个问题很要紧。许多项目把“数据集交付”理解为某一天完成的成果：多少万页原文、多少条 OCR、多少组问答，验收单签完，数据集就被放进向量库。运行几个月后，档案仍在接收，开放状态仍在变化，OCR 还会纠错，智能检索却越来越难解释。新资料查到了，过去已经答对的问题反而开始引用错页、错项目，甚至碰到不该出现的材料。

第一次上线之后，数据集才进入最难管理的阶段。

它必须同时承担两种职责。一种是给检索系统提供知识，另一种是给系统划定质量标尺。前一种数据会不断增长，后一种数据要持续记录“哪些问题曾经答对、依据是什么、谁有权看到、什么变化不允许发生”。只有知识库，没有这把标尺，所谓高质量只能描述数据入库时的状态，不能约束系统运行一年的质量。

新增一份正确的档案，也可能制造一个错误答案

设想一个已经通过验收的查询：

> 某项目的批复日期和批复单位是什么？

数据集 V1 中有该项目 2023 年的立项批复、实施方案和验收意见。系统命中立项批复第 1 页，抽取出正确日期和批复单位，普通业务人员也有权打开这页原文。这个结果已经由档案人员确认。

几个月后，数据集 V2 接收了一份 2025 年同名项目的调整批复。新文件本身没有任何质量问题，题名、文号、原文和开放状态都准确，OCR 里还多次出现“批复日期”。索引重建后，它的词面相似度高于 2023 年材料。用户仍然问原来的问题，系统却把 2025 年调整批复排到第一位。

这类错误很容易被误判为模型“偶尔答错”。实际上，它暴露的是数据集更新后的关系变化。单条档案都正确，不等于它们放在一起仍能支持正确判断。同名项目、相近题名、重复文号、正本与修订本、公开版本与受控版本，会互相争夺检索排名。资料越丰富，这种竞争越频繁。

所以，档案数据质量不能只检查单条记录是否完整，还要检查新增记录是否改变了原有查询的证据秩序。后者正是回归测试要解决的问题。

把评测集做成数据集的一部分

不少项目准备过“测试问题”，通常只有问题和参考答案两列。它可以支持一次验收，却很难解释一次退化。

仍以刚才的问题为例。如果参考答案只写“2023 年 4 月 17 日，某单位”，系统给出相同文字就可能得分。但这段文字也许来自一份汇总表，引用按钮却指向 2025 年调整批复；也可能模型读到了普通用户无权查看的内部审批材料，最后碰巧拼出了正确答案。答案文字对了，检索链路仍然不合格。

一条能进入档案高质量数据集的回归样本，要保存当时被确认过的业务事实和证据关系：

{
  "case_id": "Q-017",
  "question": "某项目的批复日期和批复单位是什么？",
  "principal": "business_general",
  "target_archive_id": "A-2023-041",
  "required_evidence": {
    "component_id": "C-01",
    "page": 1
  },
  "forbidden_archive_ids": ["A-2025-118"],
  "answer_facts": {
    "approval_date": "2023-04-17",
    "approval_org": "某单位"
  },
  "expected_behavior": "answer_with_source",
  "risk": "release_blocker"
}

这些字段不是为了把 JSON 写得漂亮。principal 固定利用者身份，防止管理员测试掩盖普通用户的权限问题；target_archive_id、组件和页码固定证据位置；forbidden_archive_ids 记录容易混淆或无权使用的对象；expected_behavior 允许系统在问题有歧义时追问年份，而不是强行猜一个答案。

同一条样本还可以有不同身份版本。管理员能够检索某份受控档案，普通用户应当拒答或只返回公开材料。两条用例的问题文字相同，合格行为却不同。档案领域的评测如果没有用户身份，权限测试基本是空的。

从这个角度看，评测集并非知识库之外的附属文档。它是高质量数据集内部专门用于“判断变化”的那一部分。生产数据告诉系统有什么，回归样本告诉团队什么不能被悄悄改坏。

先找证据怎么变了，再问大模型为什么答错

一次错误回答至少可能来自六处：权限过滤、候选召回、重排、上下文截断、答案生成、引用回跳。把六处压成一个“回答准确率”，只能知道坏了，无法知道修哪里。

最省时间的排查方法，是暂时关掉答案生成，直接比较数据集 V1 和 V2 的检索结果。对于 Q-017，需要回答几个具体问题：

· 2023 年批复有没有进入前 10 个候选；

· 它从原来的第几位掉到了第几位；

· 2025 年材料在哪一层超过了它，是初始召回还是重排；

· 用户身份进入检索前，受限材料是否已经被过滤；

· 正确片段进入模型上下文后，引用对象和页码是否仍然一致。

如果正确证据根本没有召回，应检查实体约束、元数据索引、切片和召回策略。若召回时排在前列，经过重排后掉出上下文，应查重排特征是否过度依赖题名和词面相似。证据进入上下文且位置正常，模型仍混淆日期含义，再看提示、字段语义和生成模型。原文内容正确但点击引用打开了另一页，则问题在对象标识和页码映射。

每层都有自己的判断方式。召回层看必须证据是否进入 Top K，以及首次出现位置；权限层要求无权片段出现数为零；答案层核对日期、单位、文号等事实；引用层验证档号、组件、页码和实际打开的原文。模型生成的文字只是最后一层，不能替前面的错误遮羞。

总分上升，版本仍然可能不能发布

假设一次更新加入了新的档案门类。120 道固定用例中，7 道关于新资料的问题由失败变为通过，3 道旧题由通过变为失败。总通过数增加了 4，报告曲线很好看。

再展开那 3 道旧题：一道只是正确证据从第 2 位降到第 4 位；一道把无权材料放进了候选集；另一道答案内容基本正确，但引用页已经错位。这个版本不能因为总分变高就上线。权限泄漏和证据断链都是阻断项，新题的进步不能抵消它们。

这组数字用于说明发布判定，并非客户项目的验收数据。它反映一个常被忽略的原则：平均分适合观察趋势，不能代替逐题差分。审核候选版本时，应先找出哪些已经兑现过的能力被撤回，再看总分变化。

档案 AI 的发布门可以很朴素：新增权限泄漏必须为零；高风险旧题不得从通过变为失败；引用回跳不得新增断链；存在歧义时，追问或返回多个候选优于无依据地选一份；其余排名波动要有可解释记录。几条硬规则比“综合准确率不低于 85%”更能保护实际利用。

数据集版本号必须能重放一次错误

测试人员发来一张错误回答截图，开发人员在另一套环境里复现不出来，这在检索项目中很常见。两边虽然都说使用“V2 数据集”，读取的语料批次、OCR 文本或索引别名可能已经不同。

能够承担回归测试的数据集版本，不能只是文件夹名称。一次运行至少要串起语料快照、文档清单校验值、OCR 版本、切片规则、embedding 模型、索引参数、重排模型、权限策略、生成模型和提示版本。只要其中一项改变，运行结果就应生成新的 run_id。

run_id 下面还要保留每道题的候选列表、各层得分、最终回答、引用对象和人工判定。这样才能从一次错误回到当时的数据和规则。若只保存总分，团队会反复争论“是不是模型波动”；若保留了运行指纹，可以直接看到正确证据在哪一步被挤走。

版本治理还要处理档案数据自身的变化。重新扫描可能让页码映射变化，OCR 纠错会改变切片文本，目录修订会改变实体字段，开放审核会改变可见范围。它们都属于数据集版本的一部分，不能只给向量模型标版本号。

把线上错误变成下一版数据资产

高质量数据集不会靠一次集中标注成熟。它的质量很大一部分来自运行期：用户查到同名对象，档案人员发现日期语义混淆，权限审计发现受限片段进入召回，原文迁移后出现回跳错页。每一次真实故障都比凭空编一道测试题更有价值。

故障修复后，要把原问题、用户身份、错误证据、正确证据和失败原因固化为回归样本。下一次新增资料、重跑 OCR、调整索引或升级模型时，这条样本自动重放。若同类错误再次出现，版本就停在发布门外。

这里有一个容易做反的地方：只把“答对的问题”收进数据集，却把失败样本留在工单或聊天记录里。这样会使评测集越来越像演示题库。提高系统稳定性更依赖边界样本：同名项目、缺失年份、多个有效版本、页码错位、低置信 OCR、开放状态刚调整、问题本身无法唯一判断。

失败样本也不必一律要求系统给出答案。有些问题的正确行为就是追问，有些应当拒答，有些只能列出多个候选请用户确认。把这些行为写进样本，才能避免模型把“什么都敢答”误装成能力。

数据集更新要留出退路

回归测试不能停在一份报告上。新批次档案进入候选索引后，先在影子环境运行固定样本和本批新增样本。通过发布门，再切换索引别名；上一版索引暂时保留。若线上出现测试集没有覆盖的退化，可以迅速切回基线版本，并保留候选版本用于复盘。

搜索引擎 alias、向量库 collection 版本、双表或蓝绿部署都能实现这件事，项目可以按现有技术栈选择。新旧数据集不能在同一个不可逆的索引里直接覆盖，否则回归测试发现问题以后，团队仍然没有办法恢复。

测试成本也可以分层控制。每次小更新先跑权限、召回、重排和回跳检查，它们速度快，也不需要调用生成模型。只对排名发生变化的用例、高风险样本和抽样集执行完整问答评测。这样，数据集每天更新也能复测，不必等到大版本上线前集中补作业。

领至科技在档案智能检索项目中判断数据集质量，不会只停在“数据是否清洗完成”。我们更关心一次更新能否说明它影响了哪些旧问题，错误能否定位到具体档案、组件和处理环节，修复后能否用原样本复现，发现越权或错引时能否阻断发布并恢复上一版。这些能力决定了高质量数据集能否从建设成果变成长期运行的工程资产。

上一篇回答了什么样的档案数据可以称为高质量数据集。这一篇补上后半个问题：数据集的“高质量”要在每次变化后重新证明，经得起重放、比较和追责。新增档案能被找到，只完成了更新的一半；旧答案、旧证据和旧权限边界仍然守得住，更新才算完成。