Inkling 评测暴露模型能力与可靠交付之间的验证缺口
Inkling 评测暴露模型能力与可靠交付之间的验证缺口
2026/07/23
2026年7月22日，Artificial Analysis 公布 Inkling 的 AA-Briefcase 评测结果：总 Elo 为836，规则得分为19.3%；呈现质量 Elo 为863，分析质量 Elo 为764，相差99点，且在 Excel、PowerPoint、PDF、Word 以外的文件类型上表现最弱。[S1]
这组差异说明，同一套系统可以把文件做得更像成品，却没有同等程度地满足内容分析和明确规则。对于支付/API 集成和多文件专业交付这类结果可由外部检查、部分正确仍可能导致失败的任务，现有证据支持把确定性验收、有效测试数据、状态检查和失败恢复列入生产基础架构预算。它尚不能证明验证层在所有任务上都比更换更强模型有效；合理的决策顺序，是先建立统一验收集，再比较两类投入各自带来的增益。
成品看起来合格，不等于任务已经完成
AA-Briefcase 把91项多周知识工作任务拆成三类评价：逐项判断要求是否满足的二元规则、分析质量两两比较，以及呈现质量两两比较。这样做针对的正是“产物精美，但内容错误或分析不足”的情况。[S2] Inkling 呈现与分析之间99点的 Elo 差距因此不是一个普通分项波动，而是指出了不同验收维度可能给出不同结论：只看视觉效果，会放过规则和内容上的失败。[S1][S2]
这种缺口并不限于一个系统。AA-Briefcase 首发结果中，整体规则表现最强的模型也只在3%的任务上满足全部标准；91项任务里有31项没有任何模型超过50%。当任务要求检查5个以上外部文件时，高智能模型的平均通过率约40%，低于只依赖提示词时的约55%。[S2] 文件和检查点增加后，生产系统需要解决的不只是生成质量，还包括要求有没有逐项覆盖、外部材料有没有真正读取，以及最终产物能否通过完整验收。
因此，多文件交付更适合将规则通过、分析正确和呈现质量分别测量。视觉复核可以发现排版问题，却不能替代事实与规则检查；单一总分也会遮住足以让整个交付失败的短板。
长程任务把局部能力与完整通过拉开
2026年6月10日，一则关于 Agents' Last Exam 的报道以“1490个真实任务、最强模型通过率仅8.6%”概括其结果，形成了本题对真实长程任务可靠性的早期观察。[S3] 论文 v2 给出的口径是：250多名行业专家参与，覆盖13个行业簇、55个子领域和1000多项结果可验证的长程真实任务；在最难层级，主流模型与执行框架配置的平均完整通过率低于1%。[S4]
这些数字不能与 AA-Briefcase 的分数直接横比，两套基准的任务集合和评分口径不同。它们共同支持的范围更窄：一般智能、生成质量或局部步骤完成，不能直接外推为严格的端到端成功。长链路会累积工具使用、材料读取和完成条件上的失误，而“完整通过”要求所有关键环节都落到可验证终态。
这一结论也有明确限制。低通过率可能部分来自基准刻意选择难题、执行框架和工具缺陷、任务表述含混或评分器设计，不能全部归因于模型与生产交付之间的永久结构矛盾。[S2][S4] 公开材料也没有提供同一模型、同一任务在有无独立验证层条件下的受控对照，因此目前只能确认验收缺口存在，不能量化模型升级和验证层分别贡献了多少成功率。
支付集成适合先把成功状态做成可检查对象
2026年7月17日，一则报道以 Stripe 集成基准中“能开发但校验仍是短板”的发现，把这一问题带入支付场景。[S5] Stripe 实际发布相关基准的日期是2026年3月2日。它构建了11个接近生产环境的支付集成环境，多数评分器通过 API 调用、自动化 UI 测试和 Stripe 测试对象检查结果，判断任务是否真正完成。[S6]
支付/API 集成之所以更适合优先建设模型外验证，并非因为模型能力无关，而是成功状态相对容易外部判定，错误放行又可能产生真实业务风险。Stripe 观察到，智能体有时会用不存在的数据触发400错误，随后误以为验证已经完成；也会因为浏览器焦点问题放弃本可恢复的流程。更成功的运行会先生成有效测试数据，再进行验证。[S6] 在这些失败里，即使代码生成部分正确，错误的测试前提或状态判断仍会让端到端任务失败。有效测试数据、状态检查和失败恢复正好作用于这些位置。
但模型升级仍是实质变量。Stripe 的测试中，Claude Opus 4.5 在4项全栈任务上的平均得分为92%，GPT-5.2 在两组专项题上的平均得分为73%；AA-Briefcase 的整体表现也通常随一般智能提高。[S2][S6] 这反驳了“模型选择已经不重要”的说法。模型和验证层并非二选一：前者影响生成与判断能力，后者负责把可外部判定的完成条件变成系统不能跳过的检查。
预算应按任务能否严格验收来分配
目前得到支持的判断是：对支付/API 集成、多文件专业交付等可以定义外部真值或严格规则、且部分正确不可接受的任务，企业 AI 平台、软件工程和安全负责人不应只凭模型总分选型。应先建立端到端评分器，准备有效测试数据，记录关键状态并允许失败恢复，再让不同模型在同一验收集上比较成功率、误放行、延迟和成本。[S2][S6]
开放式创意、目标含混或无法确定性验收的任务不在同一结论范围内。这些任务仍更依赖模型判断和人工评审。现有证据也不支持把低通过率全部归因于模型外系统，更不支持所有 Agent 产品都把验证投资置于模型投资之前。
下一步最有判别力的信号，是公开同一模型、同一任务集在加入独立验证、回滚和状态控制前后的严格通过率、返工率与误放行率，并用同一组任务测试模型升级。如果验证层的增益在多个任务集上稳定超过单纯升级模型，核心判断会增强；如果更强模型在没有额外验证层时持续达到严格门槛，而且成功率增益更大，这一判断就应被削弱或推翻。