Knowledge-Gated Verifiable Tasks：把"无知的失败"与"无能的失败"在 benchmark 里分开

  • 关联论文：2608.30322
  • 作者：spark
  • 更新：2026-09-04

一句话结论

本文提出一套 knowledge-gated 任务构造协议：把任务指令与"私有规约 / 参考表 / 工具算子"的 compact artefact 解耦，并在提供 / 扣留 artefact 两个条件下做 byte-identical 任务对照，让"agent 失败是因为不知道规约"与"agent 失败是因为能力不够"在评测层面被显式区分。

解决什么真问题

专业 agent 任务高度依赖未公开规约：企业内部命名规则、API 错误码表、特定行业的合规术语……这些规约不在公开语料里。但主流 agent benchmark 几乎不控制 agent 是否能接触这些规约。

这导致两类失败被混在一起：

  1. Ignorance（无知）：agent 能力够，但缺规约知识 → 拿不到规约时 0 分、给规约时高分。
  2. Incompetence（无能）：agent 能力本身不足 → 给不给规约都低分。

两类失败的归因完全不同：前者补知识、后者要更强模型 / 训练。但当前 benchmark 把它们糊在一起，导致"加 RAG / 知识库就涨点"的归因常常是 noise——到底涨的是知识缺口的填补、还是模型本身能力的展现？说不清。

核心方法

任务构造协议：四件套

task_unit = {
    instruction:        任务正文（不含规约知识）,
    artefact: {
        conventions:    私有命名/调用规约,
        reference_tables: 参考表,
        utility_operators: 工具函数,
    },
    provenance:         规约来源审计链,
    leak_audit:         是否泄露到公开语料,
    executable_witness: 可执行验证脚本,
    criterion_rubrics:  命名化的评分维度,
}

四件套关键设计：

  • byte-identical instruction：在"提供 artefact"与"扣留 artefact"两种条件下，任务正文逐字节相同。变量只有 artefact 是否暴露——这使差分归因成为可能。
  • construction-time provenance：每个 artefact 都记录规约来源，避免 agent 在预训练中已见过而污染对照。
  • leak audits：检测规约是否意外进入公开语料，确保对照有效。
  • executable witnesses：对结构化任务，附可执行验证脚本，提供 exact ground truth；对不可完全自动判分的输出，使用命名 criterion-level rubrics。

知识闸门筛：five-trial empirical knowledge-gating screen

for each task t:
    pass_rate_with    = avg(pass over 5 trials with artefact)
    pass_rate_without = avg(pass over 5 trials without artefact)
    if pass_rate_with - pass_rate_without > threshold:
        retain t  # 知识闸门成立：失败可归因于知识缺口
    else:
        discard t # 知识闸门不成立：失败无法清晰归因

配置相对校准（configuration-relative calibration screen）

同一任务在多种 agent 配置上跑，保留至少 7 个通过知识闸门筛选的任务，作为最终评测集。

关键实验与数据

维度 关键结论（abstract verbatim）
校准任务总数 15 个
极差对照 "one frontier agent configuration achieves a 68.0% pass rate with the artefact and 0% without it"
负样本有效性 "on one task, a plausible but incorrect artefact also yields 0% across five trials"——错误规约不涨点，反向证明 agent 真在用规约
最终保留任务数 7 个（通过 five-trial 知识闸门筛选）
开源 "we publicly release part of the task suite and supporting tooling at https://github.com/DatagridsAI/Knowledge-Gated-Task-Construction"

⚠️ 原文未明确具体的 15 → 7 筛选阈值、7 个保留任务的主题分布、其他 agent configuration 的具体表现。

亮点与局限

亮点

  1. 首次把"知识 vs 能力"在 benchmark 里显式分离：byte-identical instruction + artefact 暴露 / 扣留的对照设计是干净的方法学贡献。
  2. 错误规约反向验证：用"看起来合理但错误的 artefact 仍 0%"排除"agent 涨分靠幻觉 / 模式匹配"的假阳性。
  3. 5 次 trial + executable witness：让评测本身有统计意义和可重复性，比单次跑分更可信。
  4. 配置相对校准：保留任务通过多 agent 配置的稳定筛选，避免某个特定模型的偏置。
  5. GitHub 公开：https://github.com/DatagridsAI/Knowledge-Gated-Task-Construction ，可直接复用任务构造工具链。

局限

  1. 作者明确自承局限："These experiments validate the behavior of the construction protocol; they do not establish that the retained tasks improve post-training"——本工作只验证"协议本身是否有效"，不验证"用这些任务训练能否提升 agent"。
  2. 评测维度偏窄：保留 7 个任务，主题覆盖度与统计功效有限；abstract 未给出任务主题分布。
  3. artefact 构造成本：每任务需人工配规约 + 工具 + provenance + leak audit，规模化困难。
  4. 依赖规约可形式化：对于高度依赖隐性知识 / 模糊判断的任务（谈判、创意），executable witness 设计本身是开放问题。
  5. 未测多种 agent 类型：仅"frontier agent configuration"作为对照，open-source 小模型 vs frontier 模型的差分表现未在 abstract 给出。

对工程落地的启发

  • agent 评测必须控制知识变量：内部评测时把"给文档 vs 不给文档"做成两套对照，避免把 RAG / 知识库的功劳算到模型能力头上。
  • 协议层面的工具链值得借鉴：provenance + leak audit + executable witness 的四件套对任何专业 agent benchmark 都通用。
  • 错误规约是负样本：自评时加入"看起来合理但故意错误"的规约，能筛掉"模型靠常识 / 幻觉硬答"的伪涨点。
  • 5 次 trial 比单次稳：单次跑分随机性大，对小样本评测尤其要重复。

与同方向工作的关系

  • 与 SWE-bench / HumanEval / MMLU 等通用基准：后者不区分知识 vs 能力，本文是"评测方法学补丁"。
  • 与 HAL, ToolBench 等工具调用基准：本文给"工具调用是否依赖私有规约"提供了差分框架。
  • 与 agent 失败归因研究（如 Why Agents Fail 类工作）：本文是评测侧的解法，把归因前置到任务构造阶段。
  • 与 RAG 评测（如 RGB / RAGAS）：本文方法可被 RAG 评测借鉴——"给文档涨点 vs 不给文档涨点"本身就能区分 RAG 价值与模型能力。

适合谁读

  • 做 agent benchmark 设计 / 评测方法学的学者——"知识闸门 + byte-identical instruction" 是值得抄的方法学。
  • 内部 AI 系统评测负责人——评估自家 agent 短板时，"知识 vs 能力"分离是诊断利器。
  • RAG / 知识库方向研究者——衡量 RAG 价值时避免与模型能力混淆。
  • 对 agent 可信度 / 可解释性有兴趣的产品 / 合规人员——理解失败归因是责任划定的前提。

工程落地与核查（Jay）

事实核查（Abstract / GitHub README 对照）

核查项 原文说法 核查结论
作者 Hanlin Tian ✅ arXiv submission history 确认（2608.30322 v1）
校准任务总数 15 个 ✅ Abstract verbatim
68.0% vs 0% 极差对照 "68.0% with artefact / 0% without" ✅ Abstract verbatim
15 → 7 任务筛选 "configuration-relative calibration screen retains seven tasks" ✅ Abstract verbatim
Five-trial screen "five-trial empirical knowledge-gating screen" ✅ Abstract verbatim；GitHub README 确认 5-trial threshold 作为筛选机制
负样本 "plausible but incorrect artefact also yields 0%" ✅ Abstract verbatim
开源链接 github.com/DatagridsAI/Knowledge-Gated-Task-Construction ✅ GitHub 可访问，README 内容与论文一致
筛选阈值具体值 解读：⚠️ 原文未明确阈值数字 ⚠️ Abstract 只说 "pass_rate_with - pass_rate_without > threshold"，GitHub README 同样未给出具体数值；需读 PDF §3
公开任务子集 GitHub README：5-task 公开子集（15 → 7 保留中的 5 个公开） ✅ README 原文确认：完整 15-task 校准池在论文 Table 1/Fig. 2，公开版本为 5-task 子集；解读原文"7 个保留任务均公开"需修正
参考解（golden solutions） GitHub README 明确不发布 ⚠️ README："reference solutions deliberately excluded"；解读原文未提及此限制
跨 agent 配置数量 仅 "frontier agent configuration" 单一对照 ⚠️ Abstract 只提一种配置；其他开源小模型对照数据需读 PDF §4
Benchmark runner GitHub README：sandbox/Docker 部分不可用 ⚠️ README："benchmark-running harness is tied to internal infrastructure"；任务本身 tests/ 可复用，但完整评测需自建 runner

可读性精修

  1. 局限第1条措辞需精确：原文引用"These experiments validate the behavior of the construction protocol; they do not establish that the retained tasks improve post-training"——这是作者自承最强的一条局限，建议在解读中提升权重，作为"不适合直接做训练数据"的核心提示。
  2. 公开子集澄清：解读原文"最终保留任务数 7 个"后紧跟"GitHub 公开"——实际 GitHub 仅公开其中 5 个，另外 2 个在论文 Table 中未公开；建议原文加注区分。
  3. 缺失信息透明度：5-trial threshold 数值、7 个保留任务的主题分布、具体筛选通过率——这些 Abstract 均未披露；解读中已标 ⚠️，表述准确。

工程落地：实际系统怎么用

核心适用场景：企业内部 agent 评测（客服 / 销售 / 运维 / 代码生成）；只要任务依赖私有规约（内部文档 / 私有 API / 特殊业务规则），即可用本文四件套构建差分评测集。

三步构建 knowledge-gated 评测集： 1. 规约抽取：从内部文档 / API 规范 / 业务规则中提取 artefact（命名约定、错误码表、工具函数签名）；附 provenance 记录来源。 2. leak audit：确认 artefact 内容不在公开语料中（用 grep / embedding search 对照）；若已泄露则该任务作废。 3. 知识闸门筛选：用 agent 跑 5-trial with/without artefact 差分，筛选 pass_rate_diff > threshold 的任务；阈值未公开，建议从 20-30% 开始调，保留差分最大的 7-10 个任务。

三个坑： - 坑1：Reference solutions 不公开。GitHub README 明确不提供 golden solutions，理由是"release golden trajectories burns evaluation value"；内部若要自动判分，必须自行从 task verifier（每个 task/tests/ 目录下）推导 ground truth，而非等待官方发布。 - 坑2：完整 benchmark runner 不可复用。GitHub 仅公开 task 本身（instruction.md + Dockerfile + tests/），但 provider/gateway 配置、retry + sandbox 逻辑属于内部基础设施；teams 需自行适配 BenchFlow 或其他 runner。 - 坑3：Artefact 构造成本高，难以规模化。每个任务需人工设计私有规约 + leak audit + executable verifier，人力成本高；建议先用内部高频任务优先，优先覆盖"规约明确、错误可判"的结构化场景（代码 / API 调用 / 数据录入），暂不覆盖"创意 / 谈判"等模糊判断类任务。 - 坑4：5-trial threshold 未公开，无法精确复现。Abstract 和 GitHub README 均未给出筛选阈值具体值；建议用 20-30% 作为初始经验值，实际使用中按"保留任务统计功效足够"做自适应调整。