[论文] IBIB: A Protocol for Measuring Enterprise AI Systems by Serving Route, Not Model Identifier (arXiv:2609.10494)
论文概要 研究领域: NLP 作者: Blake Stenstrom, Charangan Vasantharajan, Brian Sathianathan 发布时间: 2026-09-09 arXiv: 2609.10494
论文概要
研究领域: NLP 作者: Blake Stenstrom, Charangan Vasantharajan, Brian Sathianathan 发布时间: 2026-09-09 arXiv: 2609.10494中文摘要
企业部署的是系统，不是检查点。可用能力 jointly 取决于权重、服务路由、精度、输出契约和 harness，但所有18个审计基准都只给广告中的模型标识符打分。作者将这种系统性偏差视为测量误差，并提出 IB2 协议使其可报告。协议包含三部分：gold-blind 能力绑定预检，在任务到达前验证路由能执行评估契约；可靠性包含的首次评分规则，将失败保留在分数中同时将不支持的能力排除；以及结构上分数盲的裁决。在11个系统上的测试发现：能力可用性是可测量的——相同权重上的两次完整单路由运行后来在不同绑定门谓词上失败；区分度不均匀——七个套件中有四个在六系统带宽下饱和；服务路由选择使一个声明版本和精度从77.38变为82.54。原文摘要
Enterprises deploy systems, not checkpoints. Usable capability depends jointly on weights, serving route, precision, output contract, and harness, yet all 18 audited benchmarks score advertised model identifiers. We treat this as measurement error and give a protocol that makes it reportable. It has three parts. A gold-blind capability-binding preflight verifies that a route can execute the evaluation contract before any task reaches it; a reliability-inclusive first-pass scoring rule keeps failure in the score while keeping unsupported capability out; and adjudication is structurally score-blind. We call the protocol IB2 and release its algorithms, classification tables, request contract, and manifest schemas. Its reference instantiation, 128 locked tasks and 987 assertions over document, spreadsheet, chart, tool and database work, stays sealed: the procedure is the artifact, not the corpus. Across eleven systems, four results. Capability availability is measurable: two complete single-route runs on identical weights later failed distinct predicates of the finalized binding gate, while a third passed that gate before a fresh run. The advertised identifier exposed neither limit. Discrimination is not uniform: four of seven suites saturate under a six-system band, with the spread almost entirely from governed database work and multi-tab joins, so we report interval-backed resolution groups, not ranks; two of the nominal five-label output's four cuts fail multiplicity adjustment. Serving-arm choice moved one declared revision and precision from 77.38 to 82.54, paired interval [0.11,10.60], though the arms differ in access mode, harness generation, and the serving tool-call parser, and harness generation is a property of our evaluator, not any endpoint. Excluding failed responses from denominators changes the point ordering, so reliability inclusion changes a conclusion, not its wording.*自动采集于 2026-09-11*
#论文 #arXiv #NLP #小凯
讨论回复（1）
你以为你在测模型，其实你在测一条管道：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 个系统的测试结果揭示了一些令人不安的事实：
| 系统 | 分数 | 可靠性 | 完成率 |
|---|---|---|---|
| GPT-5.6 Terra | 85.95 | 83.98 | 127/128 |
| Qwen3.8-27B (AkashML) | 82.54 | 80.30 | 126/128 |
| GPT-5.6 Luna | 78.65 | 75.66 | 117/128 |
| Claude Sonnet 5 | 75.40 | 72.23 | 126/128 |
| Muse Glimmer 30B | 73.66 | 71.33 | 122/128 |
| Kimi K3 | 72.99 | 69.90 | 108/128 |
| Qwen3.6-27B | 68.27 | 65.39 | 101/128 |
| Qwen3.5-122B-A10B | 53.32 | 50.95 | 102/128 |
| GLM-5.2 + GLM-5V-Turbo | 41.10 | 38.11 | 86/128 |
同一个模型，两条路线，36 分差距
论文中最有说服力的实验是 Qwen3.8-27B 的双路线测试：
- RunPod 路线：77.38 分
- AkashML 路线：82.54 分
两条路线的差异不在模型，而在访问模式、测试框架生成器和服务工具调用解析器。论文诚实地指出："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(权重)*