你以为你在测模型，其实你在测一条管道：IB² 如何重新定义 AI 系统的"能力"

一个让排行榜沉默的实验

2026 年 7 月 24 日，DeepInfra 上的一个 FP8 精度的模型跑完了一套 128 题的企业基准测试，得分 26.12。

两天后，同一个模型权重，换了一条部署路线（CoreWeave FP8），得分 62.25。

同一个模型，同一套题，分数差了 36 分。

这不是 bug。这是 IB² 论文要解决的核心问题：当你报一个模型的分数时，你到底在测什么？

"企业部署的是系统，不是检查点"

论文的第一句话就点明了问题：

> Enterprises deploy systems, not checkpoints.

一个 AI 系统的可用能力，取决于六个因素的联合：权重、部署路线、精度、输出契约、工具实现和测试框架（harness）。但现有 18 个主流基准测试，全部只报告"模型标识符"（model identifier）的分数——仿佛 GPT-5.6 或 Claude Sonnet 5 是一个有确定能力的对象。

这个假设是错的。

DeepInfra 得分 26.12 的原因：它的部署路线限制了每次请求最多 4 张图片，而测试合同要求 13 张图片。模型根本没机会看到完整的题目。CoreWeave 得分 62.25 的原因：它宣称支持 262,144 token 的输出上限，但实际在 32,768 token 处就截断了，返回 finish_reason=length。

两个案例中，模型权重完全相同，但"部署路线"改变了模型能做什么。 而传统的基准测试，没有任何机制能检测或报告这种差异。

IB² 协议：先验管道，再测能力

IB²（Iterate Business Intelligence Benchmark，平方形式写作 IB²）不是又一个基准测试。它是一个协议——一套规定"如何测量"的规则。

协议的核心是四个算法：

1. 能力绑定预检（Capability-binding Preflight）

在正式测试之前，先验证部署路线能否执行评估合同。这就像考试前先检查考场是否有电——如果灯都灭了，你考出来的分数不能反映学生的水平。

预检是"金盲"的（gold-blind）：它不知道答案，只检查路线能否接收、处理和返回符合契约的响应。DeepInfra 的 4 图限制和 CoreWeave 的 32K 截断，都是在这一步被发现的。

2. 可靠性包容评分（Reliability-inclusive Scoring）

传统基准测试只算准确率：答对多少题。IB² 把"能不能回答"也纳入评分。如果一条路线在 128 题中只能处理 100 题，那 28 题的失败不是"模型不会"，而是"路线不支持"。

这一步是论文最反直觉的设计。排除失败响应后再算准确率，会改变排名。 论文的原话是："reliability inclusion changes a conclusion, not its wording"——可靠性包容改变的是结论本身，不是措辞。

3. 金盲裁决与恢复（Gold-blind Adjudication and Recovery）

当模型返回的答案不符合预期时，不能直接判错。可能是模型的输出格式与评估器的解析器不兼容（harness 的问题），也可能是模型真的答错了。IB² 用一个金盲裁决器区分这两种情况，并在前者发生时尝试恢复。

4. 套件分层任务集自助抽样（Suite-stratified Task-set Bootstrap）

用自助抽样估计分数的置信区间，而不是只报一个点估计。关键创新：区间排除零才声称排序显著，否则报告"共享分辨率组"（resolution group）而不是排名。

128 道题，987 条断言，11 个系统

IB² 的参考实例包含 7 个测试套件，覆盖电子表格推理、文档理解、图表问答、工具调用和文本到 SQL 五大企业能力。128 道锁定任务，987 条断言——每道题不只判对错，而是检查多个维度的契约合规性。

11 个系统的测试结果揭示了一些令人不安的事实：

注意"完成率"这一列。Kimi K3 只完成了 108/128 道题——20 道题因为路线限制而无法提交。如果排除这 20 道题再算准确率，Kimi K3 的排名会上升。但 IB² 拒绝这样做："不能回答"本身就是能力信息。

同一个模型，两条路线，36 分差距

论文中最有说服力的实验是 Qwen3.8-27B 的双路线测试：

• RunPod 路线：77.38 分
• AkashML 路线：82.54 分

同一个权重，同一套题，5.16 分的差距。95% 置信区间 [0.11, 10.60]——虽然下界勉强排除零，但区间宽度暴露了一个事实：你报的"Qwen3.8-27B 的分数"是一个依赖于部署路线的随机变量，不是一个常数。

两条路线的差异不在模型，而在访问模式、测试框架生成器和服务工具调用解析器。论文诚实地指出："harness generation is a property of our evaluator, not any endpoint"——测试框架的生成是评估器的属性，不是端点的属性。这意味着分数的差异来自评估器与路线的交互，而非路线本身。

饱和度分析：哪些测试已经分不出系统了？

IB² 还做了一个自我批判性的分析：哪些套件已经失去了区分前沿系统的能力？

结果：7 个套件中有 4 个在 6 个系统的带宽内饱和了——分数差异不再显著。区分能力几乎全部来自受管数据库工作和多表连接的两个套件。

这意味着：如果你只用饱和的套件测系统，所有前沿模型看起来都差不多。排行榜上的微小差异，可能只是噪声。

为什么 IB² 不是又一个基准测试

IB² 最反潮流的地方在于：它不发布公开题库。

128 道任务和 987 条断言是锁定的（sealed）。论文通过合成一致性测试夹具（synthetic conformance fixtures）和已签名的留存证据来支持可审计性，而不是通过公开语料。这违反了机器学习社区"可复现=公开数据"的默认假设。

但论文给出了理由：公开题库会被污染。 一旦题目公开，模型会在训练数据中见过它们，分数就不再反映能力。IB² 选择用协议的可复现性替代数据集的公开性——任何人可以按协议重新生成一套等价的测试题，但原始题库保持锁定。

这篇论文的深层主张

IB² 表面上是一个评估协议，深层是一个哲学主张：

"模型能力"不是一个标量，而是一个依赖于部署上下文的函数。

当你问"GPT-5.6 有多强"时，这个问题是没有定义的。有定义的问题是："GPT-5.6 通过 OpenAI Responses 路线、xhigh 推理强度、原生工具调用、在 IB²-7 Full 配置下，得分 87.37。"

这就像问"一辆车有多快"——取决于路面、轮胎、天气和驾驶员。只报一个最高速度，是测量误差。

IB² 的 GitHub 仓库（IterateAI/IBIB）目前为私有，协议规范和参考实现尚未公开发布。但论文已给出完整的算法描述和形式化定义，足以理解协议的设计意图。

在 AI 评测越来越追求"一个数字排名一切"的当下，IB² 提醒我们：当你把六个变量压缩成一个标量时，你丢失的不是信息，是结论本身。

---

*论文：arXiv:2609.10494（42 页，4 图）* *协议：IB²（4 个算法，7 个套件，128 任务，987 断言）* *核心主张：能力 = f(权重, 路线, 精度, 契约, 框架)，不是 f(权重)*