IBIB：按服务路由而非模型标识评测企业 AI 系统
来自 arXiv · 期号 2026-09-10
摘要
企业部署的是系统，不是模型权重。可用能力取决于权重、服务路由、精度、输出契约和测试框架的组合，但现有的 18 个基准评测都只按模型标识打分。 本文提出 IBIB 协议，把这种测量偏差变成可报告的数据。协议分三部分：一个对评测任务内容不可见的预检步骤，先验证路由能否执行评测契约；一个包含可靠性的首次通过评分规则，把失败计入分数但不计入不支持的能力；以及结构上对分数不可见的裁决流程。 在 11 个系统上的测试有四个发现：能力可用性是可测量的——两次相同权重的单路由运行，后来在预检中失败了不同的断言；评测区分度并不均匀——7 个套件中有 4 个在 6 个系统的范围内就饱和了；服务路由的选择让同一个版本和精度从 77.38 跳到 82.54；排除失败响应会改变排序，所以是否计入可靠性会影响结论本身。 论文附了算法、分类表、请求契约和清单模式，但参考实现（128 个锁定任务、987 个断言）保持密封——协议本身才是成果，不是测试集。
深读
导读 企业部署的是AI系统，而非单个模型权重。现有18个主流基准评测都只按模型标识打分，忽略了服务路由、精度、输出契约等关键因素。本文提出IBIB协议，将这种测量偏差转化为可报告的数据，为评估企业级AI系统提供了更精确的方法论。 关键信息 - 现有18个基准评测均按模型标识（model identifier）打分，而非按实际部署的系统路由。 - IBIB协议包含三个部分：对评测任务内容不可见的预检步骤、包含可靠性的首次通过评分规则、以及结构上对分数不可见的裁决流程。 - 在11个系统上的测试发现：服务路由的选择让同一个版本和精度从77.38跳到82.54，配对区间为[0.11, 10.60]。 - 7个评测套件中有4个在6个系统的范围内就饱和了，区分度主要来自受治理的数据库工作和多标签页连接。 - 参考实现包含128个锁定任务和987个断言，覆盖文档、电子表格、图表、工具和数据库工作，但该语料库保持密封状态。 逐节讲解 问题：基准评测只测模型标识，不测系统 现有基准评测（共18个）都只按模型标识打分，但企业实际部署的是包含权重、服务路由、精度、输出契约和测试框架在内的完整系统。这种测量方式忽略了系统层面的差异，导致评测结果无法反映真实可用能力。 解决方案：IBIB协议的三部分结构 IBIB协议将测量偏差转化为可报告的数据，包含三个核心部分： 1. 能力绑定预检（capability-binding preflight）：在评测任务到达之前，先验证路由能否执行评测契约。该步骤对评测任务内容不可见，确保路由具备执行任务所需的基础能力。 2. 首次通过评分规则（first-pass scoring rule）：将失败计入分数，同时将不支持的能力排除在外，从而包含可靠性因素。 3. 裁决流程（adjudication）：在结构上对分数不可见，避免裁决结果受分数影响。 测试发现：四个关键结果 在11个系统上的测试揭示了四个主要发现： 1. 能力可用性是可测量的：两次相同权重的单路由运行，后来在预检中失败了不同的断言；第三次运行通过了预检但随后失败。模型标识无法暴露这些限制。 2. 评测区分度并不均匀：7个套件中有4个在6个系统的范围内就饱和了，区分度几乎完全来自受治理的数据库工作和多标签页连接。因此论文报告的是基于区间的分组，而非排名。 3. 服务路由的选择影响显著：同一个版本和精度，因服务路由不同（访问模式、测试框架生成、服务工具调用解析器不同），得分从77.38跳到82.54。 4. 是否计入可靠性会影响结论：排除失败响应会改变排序，因此是否包含可靠性因素会影响结论本身，而不仅仅是措辞。 值得注意 论文附了算法、分类表、请求契约和清单模式，但参考实现（128个锁定任务、987个断言）保持密封状态，论文声称“程序本身才是工件，而非语料库”。这意味着外部研究者无法直接…