📄 分数不是检查点属性：SURE-EVAL 把执行与打分钉成可重放契约
英文题目：SURE-EVAL: A Systematic and Unified Agentic Framework for Reproducible Evaluation
标签：#语音识别 | #评测协议 | #文本到语音 | #基准测试
评分：7.3/10 | 创新 1.5/2 | 技术严谨 1.2/1.5 | 实验充分 1.1/1.5 | 清晰度 0.8/1 | 影响力 1.1/1.5 | 开源 0/1.5 | 可复现 0.3/0.5 | 工程/实践 1.3/1.5
👥 作者与机构
- Jing Peng：Shanghai Jiao Tong University
- Junhao Du：Shanghai Jiao Tong University
- Yixuan Wang：Shanghai Jiao Tong University
- Bowen Wang：University of Bristol
- Hanqi Li：Shanghai Jiao Tong University
- Chaolei Liu：Shanghai Jiao Tong University
- Weihan Chen：Shanghai Jiao Tong University
- Haohui Xie：Shanghai Jiao Tong University
- Ruichen Sun：Imperial College London
- Chenghao Wang：Xi’an Jiaotong University
- Wen Wen：Shanghai Jiao Tong University
- Guanyu Chen：Shanghai Jiao Tong University
- Xiaoyu Gu：Shanghai Jiao Tong University
- Haoyu Li：Shanghai Jiao Tong University
- Yiwei Guo：Shanghai Jiao Tong University
- Bohan Li：Shanghai Jiao Tong University
- Tao Liu：Shanghai Jiao Tong University
- Yucheng Wang：ETH Zurich
- Yu Xi：Shanghai Jiao Tong University
- Yihua Zhou：AISpeech Co., Ltd.
- Qiang Zhou：AISpeech Co., Ltd.
- Feng Lu：AISpeech Co., Ltd.
- Shuai Wang：Nanjing University
- Kai Yu：Shanghai Jiao Tong University
📌 核心摘要
语音评测的输入是大量异构模型发布与评测请求，输出应是可复核分数，但同检查点会因运行时、解码策略与归一化实现不同而显著漂移。SURE-EVAL将一次评测形式化为执行契约与评分契约绑定的可执行声明，主智能体先核验可调用工具并提交数据集与流水线版本，再把得分操作交由确定性程序严格完成。工具智能体负责系统性解析仓库与报错证据并经由四道验证门产出隔离可调用接口，从而把智能体限定在解释证据而非改写评分逻辑。与已有语音基准只固定数据集或打分不同，该框架把环境搭建、推理控制与版本化度量纳入同一完整可追溯审计链条。在Seed-TTS-Eval基准的zh子集下，IndexTTS2的内容错误率为1.09，低于F5-TTS的内容错误率1.54。该结论仅适用于所注册流水线与单卡推理设置，未验证多硬件与大规模重复采样的稳定性。原文未披露训练、推理或部署成本。
🔗 开源与复现资源
本次未形成可展示的已核验资源记录，开放状态尚未核实。
可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。
🧭 深度解读
输入是什么？为什么语音分数总对不上？
这篇论文的输入是公开发布的语音与音频模型仓库、检查点、文档与社区证据，目标是给出可重放的评测分数。读者需要先保留一个基本判断：论文不提出新的识别或合成模型，它研究评测本身。对于刚进入语音方向的研究生，白话理解是：自动语音识别（Automatic Speech Recognition，ASR）是把声音转成文字，语音合成（Text-to-Speech，TTS）是把文字转成声音，声音转换（Voice Conversion，VC）是把一个人的声音转成另一个人的声音，说话人日志（Speaker Diarization，SD）是判断谁在何时说话，带说话人标签的识别还要把文字归属到说话人。
学习依赖的第一步是承认分数有两个来源。同一份检查点在不同运行时、硬件、精度、解码温度、波束宽度、回退与重试策略、提示传播、分块策略下会产生不同预测。即使预测固定，抽取、校验、规范化、切分、打分与聚合不同也会得到不同分数。论文把前者叫执行方差，后者叫打分方差。复述时不要把词错率下降直接说成模型更强，必须先问两份分数的执行条件与打分路由是否一致。
输出是一个可执行评测声明：分数加上产生它的运行时、协议、流水线节点、预测与审计制品。资源状态方面，本次未发现来源绑定且完成验证的资源，不得声称代码、模型或数据已公开，只能按论文文字讨论方法与实验条件。后续章节先对照已有路线，再进入契约表示与两个智能体工作流。
已有基准做了什么？还缺哪一块？
要理解定位，需要按同输入、同目标、同运行阶段对照已有路线。语音表示基准固定了下游任务套件，比较的是冻结表示，不是任意端到端发布的部署。多语与长语音识别榜单统一了数据集、规范化、词错率与效率报告，但仍是识别专用榜单，预设了评测界面。语音理解统一框架整理了数据、预测格式、规范化与打分，但新仓库的接入仍多靠人工。
另一条线是智能体自动化。通用仓库部署工具能推断依赖并生成可执行环境，但不定义任务相关的推理条件与分数语义。大语言模型基准编排工具能把自然语言请求转成可追溯流程，但前提是评测接口已经可用。论文的判断是：前者缺分数契约，后者缺异构上线。用初学者语言说，已有工作要么假设模型已经可调用，要么只解决环境能跑，都没有把异构上线、受控推理与版本化打分钉在同一个可执行工作流里。
因此不要把类别差异当成同条件胜负。论文没有声称在识别精度上超过上述基准，它的互补点是把新增发布变成智能体上线问题，再用确定性程序评测，运行时、硬件、解码约束、输出规范化与评测器版本都作为可审计契约的一部分。这一定位直接引出下一节的两个方差例子。
两个方差如何在一个例子里同时出现？
先建立问题直觉。教学例子仅用于理解机制，不代表论文实测数值。假设你拿到同一个识别检查点和同一句话，固定解码得到正确转写，改成高温加回退解码就把序列号听成发音相近的错误词，词错率从零变成十几个点，这就是执行方差。再假设预测已经固定，一个打分契约按字面算错，另一个先做中文数字与时间表达的规范化再算错，原来落后的系统反而变成零错，这就是打分方差。两个例子说明同一检查点不保证同一可执行系统，同一预测也不保证同一分数。
下图把上述两条链路画成左右两栏，左侧强调同一检查点不保证同一可执行系统，右侧强调不同打分契约可能反转表面排名，底部给出只有联合指定才可比的结论，值得逐栏对照阅读。
看图路径： 1. 先看左侧面板从同一检查点和相同语音出发经过不同推理协议得到不同预测的箭头；2. 再看右侧面板从固定预测出发经过不同打分契约得到不同分数并可能反转排名的示例；3. 最后读底部只有可调用工具推理协议规范化契约与评测器联合指定才可比的结论条
论文图 1。原论文 Figure 1:：“Motivation for SURE-EVAL. Comparable scores require jointly specified model onboarding, inference protocol, output normalization, and metric evaluation.”。
这张图的可执行读法需要分 3 步。左侧从相同检查点加相同语音出发，经过不同运行时与推理协议得到不同预测与词错率，图中用固定解码与回退解码两种设置对比，固定解码温度为零且无回退，另一侧温度更高且允许回退。右侧从固定预测出发，经过不同打分契约得到不同分数，图中用字面字符错与规范化后字符错对比 2 个模型，字面计算下差距很大，规范化后一个模型归零。底部把可调用工具、推理协议、规范化契约与评测器并列，说明缺任何一项都不能直接比较。后续所有设计都是为了把这两条链路分别固定下来。
全景是什么？谁允许改分数？
全景分三块：主智能体工作流是全局入口，工具智能体工作流负责把未就绪目标变成已验证可调用工具，确定性评测层负责所有能改变分数的操作。主智能体先查是否有已验证工具，未解决才调用工具智能体。工具就绪后，主智能体提交评测范围与协议，再把耗资源的工作交给已注册的确定性程序。每个结果附带运行时、协议、流水线节点、预测与审计制品。
核心控制原则是：智能体只在需要解释异构证据的地方工作，分数语义的决定必须先物化成结构化协议输入。智能体可以在声明的选项中选择，不能在运行中现写规范化逻辑、替换评测器或即兴改打分命令。两份结果只有在相关执行与打分字段相等或属于声明的兼容协议类时才可直接比较，改检查点、精度、解码策略、规范化版本或评测器版本都会产生不同的声明，即使显示的模型家族与指标名不变。
执行契约 × 打分契约： 执行契约负责固定模型如何被运行，包括模型与检查点版本、已验证运行时与封装、硬件拓扑、精度与量化、任务相关推理选择；打分契约负责固定输出如何被算分，包括规范数据集实例、输出模式与抽取规则、规范化路由、指标实现与聚合过程；二者搭配的理由是同一检查点换运行时会改变预测、同一预测换规范化会改变分数，只有两份契约同时固定并存档，分数才能跨模型比较与重放。
下图展示从用户请求加溯源证据到评测声明的 4 层：输入层、智能体控制层、结构化执行层与输出层，中间有一条协议提交边界把解释与执行分开，建议沿纵向主路径先看一遍。
看图路径： 1. 先沿输入层到智能体控制再到结构化执行最后到输出层的纵向主路径看；2. 再看主智能体到工具智能体只有未就绪时才触发的虚线分支；3. 最后确认协议提交边界上下哪部分允许智能体解释哪部分只允许固定脚本执行
论文图 2。原论文 Figure 2:：“Overall SURE-EVAL architecture. The Main Agent Workflow routes requests, invokes the Tool Agent Workflow when callable readiness is unresolved, and hands score-bearing work to…”。
这张图要这样用：上半部分看主智能体分类、路由、定范围与评估，右侧工具智能体只在就绪未解决时介入，完成后返回带运行时、封装与输出契约的已验证工具。下半部分看可执行评测计划绑定数据集、协议与运行界面，再进入准备、预测、校验与打分的确定性层。最下是分数加运行记录的评测声明。边界的意义是提交之后模型特有的报错不能触发未记录的数据集、解码、规范化或评测器变更，任何变更都要新契约与新运行标识。
工具智能体如何把仓库变成可调用工具？
工具智能体不选数据集、不调榜单设置、不算分。它的起点是一个有界上线假设：模型身份、仓库与检查点指针、运行时包络、可调用输入输出契约，未知字段保持显式。不知道权重位置或设备要求就从证据中解决，或保留未解决，或作为阻塞条件上报。
关键机制是选择性上下文路由加有界记忆。发现阶段广泛收集仓库文件、检查点、文档、社区证据与本地执行信号。路由阶段按相关性、可靠性、新鲜度与互补性只选最小上下文，任务指引覆盖识别、翻译、日志、理解、合成与转换，环境指引覆盖包管理、容器与接口，失败记录只在观察到报错后才加载。记忆分成系统规则、只读为主的模型画像、易失的工作与执行记忆、制品索引，不同角色看到不同切片，并做压缩与淘汰。
下图左侧讲路由只送相关内容，右侧讲记忆保持紧凑新鲜与角色对齐，底部区分 4 种视角，建议先看漏斗再看权限表。
看图路径： 1. 先看左侧从广泛发现经漏斗式路由到最小打包上下文的三步；2. 再看右侧从系统记忆到制品索引的五层读写权限与稳定程度箭头；3. 最后对照底部规划实现验证与报告四种角色看到的不同视图
论文图 3。原论文 Figure 3:：“Tool Agent Workflow module view. Context routing selects task, environment, and failure-specific knowledge while preserving bounded memory and auditable evidence.”。
这张图左侧讲路由只送相关内容：从模型输入契约出发，经发现、收窄路由到带溯源的最小打包上下文，原则是相关、最小、可追溯。右侧讲记忆保持紧凑、新鲜与角色对齐：系统记忆只读、模型画像大多只读、工作与执行记忆可读写、制品索引只读，并用预算、新鲜度、相关性、压缩与淘汰管理。底部区分规划、实现、验证与报告 4 种视角。教学上可以这样记：规划者只看来源身份与未解决字段，实现者只看选中的构建与封装证据，验证者只看契约与制品，报告者只看验证结果与溯源。
工具智能体工作流 × 可调用工具： 工具智能体工作流负责解读仓库、检查点、文档与报错等异构证据并完成隔离适配，可调用工具是它的交付物，是带运行时入口、输入输出契约与四道门验证的可查接口；前者只做证据选择与失败修复，后者只保证确定性评测能直接调用，二者组合把仓库能跑变成评测能用，阻止未通过输出契约的模型流入打分阶段。
对本地发布，选中证据转成隔离的模型本地环境与封装，远程接口在允许时包在同一可调用接口后。候选工具必须按序过四道门：导入、模型与权重加载、最小推理、输出契约校验。导入成功只说明包图可加载，加载成功才解决检查点与设备路径，推理成功说明入口在有界夹具上可调用，契约成功才说明返回字段与文件能进入确定性评测。成功跑通但输出畸形不算就绪，后面的门不能补偿前面的失败，也不允许放宽输出模式来宣布成功。
\[\mathcal{C}_{\mathrm{exec}}=\left\langle M,R,H,Q,\Pi_{\mathrm{infer}}\right\rangle,\]该式先解释符号与输入：执行契约包含模型与检查点版本、已验证运行时与封装、硬件拓扑、精度与量化、任务相关推理选择。计算目标是把可执行条件钉死，后续预测函数必须在这些固定条件下对规范数据集实例运行。原文没有给出该式的数值优化过程，它是契约表示，不是待训练损失。
主智能体如何提交一次可比的运行？
主智能体的中心输出不是对话计划，而是 1 次提交后的运行：工具、数据集、推理画像、打分路由、可执行入口、输出路径与预期制品在耗资源执行前全部固定。结构化请求记录评测目标、目标模型、允许任务与数据集、执行约束、可用证据与制品位置。仅有目录或端点不算就绪证据，就绪缺失、损坏或未验证就暂停评测并移交给工具智能体，主智能体不在评测运行内修依赖或重写封装。
就绪后解决 3 个耦合对象：数据集范围同时记录选中与排除及理由，脚本路由解决已注册的准备、预测、校验、规范化、指标与报告节点，运行界面把选择绑定到具体输入输出位置与可执行入口。推理协议固定硬条件与软条件，硬条件包括加速器类别与拓扑、运行时版本、精度与量化，软条件包括任务与语言模式、温度、波束或搜索强度、回退与重试、提示传播、分块设置。按语义而非名字归一化，不支持的字段记为不适用，不静默替换。
打分协议固定从原始输出经模式校验、规范化、指标节点、聚合到报告的完整路由，主智能体只能选与任务语言兼容的路由，不能在执行中创作新规则，全量跑之前先用小规模冒烟测试验证同一端到端界面。
下图从上往下读，顶部是输入契约与批准，中部是就绪路由与三者汇成提交运行，底部是冒烟测试与执行报告，建议重点看分叉与阻塞去向。
看图路径： 1. 先看顶部主流程输入契约中目标约束与证据字段；2. 再看中部工具就绪路由器分叉到已验证工具池或工具智能体移交的路径；3. 最后看底部有界冒烟测试后就绪与阻塞重规划的两条去向
论文图 4。原论文 Figure 4:：“Main Agent Workflow from readiness-aware intent resolution to committed execution and auditable run evidence.”。
这张图从上往下读：顶部是带目标、约束与证据的主流程输入契约与人工批准，接着澄清请求进入工具就绪路由器，分叉到已验证工具池或工具智能体移交。中部是数据集范围、脚本路由与运行界面三者汇成提交后的评测运行，再进入有界冒烟测试。底部是就绪判断，通过才执行、评估与出报告，不通过则进入阻塞重规划移交，且冒烟失败不允许绕过失败节点或按原契约报告部分分数。
主智能体工作流 × 确定性评测层： 主智能体工作流负责把评测请求变成提交后的运行，包括选数据集范围、选脚本路由、绑定输入输出与可执行入口，确定性评测层负责真正改变分数的操作，包括准备、预测、校验、规范化与打分；前者只在已声明选项中选择而不现场编写规则，后者只执行已注册版本化程序，二者组合让语义判断与分数计算分离，任何解码或打分改动都必须另起新契约与新运行标识。
规范化路由 × 指标节点： 规范化路由负责把原始输出变成可比形式，包括模式校验、语言相关等价规则、切分与对齐，指标节点负责用固定版本算出分数，包括词错率、字符错率、说话人相似编码器与质量预测器；前者决定什么算相同，后者决定相同程度值多少分，二者都带版本号按序执行，组合后才能解释为何名义相同的词错率或平均意见分在不同前端下不再等价。
\[\mathcal{C}_{\mathrm{score}}=\left\langle D,O,\mathcal{K},\mathcal{E}\right\rangle,\]该式先解释符号与输入：打分契约包含规范数据集实例、输出模式与抽取规则、规范化路由、指标实现与聚合过程。计算目标是把原始预测变成可审计分数，原文明确每个阶段都是已注册版本化程序，主智能体只做路由选择。同样，这不是损失函数，不涉及梯度路径。
本研究训练了什么？没有训练什么？
本研究没有训练任何语音模型，也没有报告梯度路径、优化器、学习率或参数冻结更新细节。论文的真实计算是调用、适配与重放：工具智能体构建隔离环境与封装并做四门验证，主智能体提交协议后调用确定性脚本做推理与打分。把无训练等同于确定性求解是错误的，冻结参数也不能推出系统输出确定，因为解码温度、采样、回退重试与外部检索都可能引入随机性。
需要复述的计算过程是两段。第一段是上线计算：按任务与环境指引选证据、建环境、写封装、跑导入加载推理与契约校验，失败在上线内部按分类修复，不向榜单阶段隐匿。第二段是评测计算：按提交的硬件、推理与打分路由跑预测，再按版本化节点做抽取、规范化、打分与聚合，全程记录解析后的节点标识与版本，不用可变的最新别名。
缺项要明确指出：原文未给出智能体内部提示词、迭代步数上限之外的搜索细节、环境构建耗时分解，也未声称比较了不同基座编码智能体的差异。复现时只能按固定编码智能体与执行预算理解 1 次通过的含义，不能从模型名称推定实现细节。
评测在什么条件下跑？什么被冻结了？
实验分两类能力：异构上线与协议治理评测。上线对比固定同一编码智能体、同一初始模型说明、同一上游证据与同一执行预算，基线只给构造并验证可调用接口的通用目标，完整工作流额外给上下文路由、分层记忆、任务环境指引、结构化上线契约与四道验证门。1 次通过的定义很严：必须在首次智能体调用内同时通过导入、检查点加载、有界推理与输出契约校验，无需用户追加纠正指令。
一次通过上线 × 协议提交后执行： 一次通过上线负责度量工作流脚手架的价值，要求在首次智能体调用内走完导入、加载、有界推理与输出契约四道门，协议提交后执行负责度量比较的公平性，要求在耗资源全量运行前先冻结硬件、推理与打分路由并做小规模冒烟测试；前者隔离上线能力，后者隔离比较条件，组合后才能把上线失败与模型能力差区分开，把协议差异与模型差异区分开。
主智能体实验的执行条件被显式冻结，本地推理的硬件、批量与量化条件如下表所述，表中比较问题是不同模型是否在同一加速与批量下运行，公平条件是同一清单与同一无量化设置，指标方向在此表不涉及分数高低，只涉及条件一致。表后解释是冻结的意义所在。
| 条件 | 指标 | 基线 | 本方法 | 比较对象 |
|---|---|---|---|---|
| 本地推理环境 | 执行环境 | single NVIDIA RTX 4090 with batch size one | single NVIDIA RTX 4090 with batch size one | 本地模型 |
| 解码控制 | 推理参数 | temperature is fixed to 0 | temperature is fixed to 0 | 支持对应控制的解码器 |
上表数字与单位的来源是原文连续句，硬件用单卡批量一无量化，解码对支持的控制固定温度零与波束一并禁用回退重试，不支持的记为不适用。数据集清单、音频预处理、切分、输出抽取、规范化与指标节点版本在被比较模型间完全相同。识别覆盖多个条件，合成用相同提示、目标与子集定义并在执行前冻结模型特有生成控制。冻结的意义在于让后续词错率与合成质量差异能归因到模型与协议，而不是归因到换卡或换批量。
上线集合的组成需要单独交代，比较问题是工作流增益是否只来自单一任务模板，公平条件是同一编码智能体与证据，指标方向是 1 次通过数量越高越好，详见下表，表后解释见正文。
| 条件 | 指标 | 基线 | 本方法 | 比较对象 |
|---|---|---|---|---|
| 上线集合 | 组成规模 | 18 public releases | 18 public releases | 异构发布 |
| 任务构成 | 覆盖广度 | eight dedicated ASR systems | eight dedicated ASR systems | 同一批版本 |
上表说明版本集合包含专用识别、多任务音频、合成、转换、日志与带标签识别，多任务主要指音频输入基座模型仍需语音执行与打分契约。该构成支持的判断是基线失败分布在多任务家族而非单一模板，限制是该表只度量有界上线任务的 1 次通过，不度量下游模型质量与重复运行统计可靠性。
上线增益来自哪里？一次通过提高了多少？
比较问题是同一编码智能体加工作流脚手架能否提高首次调用成功率，公平条件是同一模型说明、证据与预算，指标方向是 1 次通过数越高越好。下表只放可在原文连续句中逐字核对的总数，不把仅出现在矩阵中的逐模型符号搬入此处，避免无源抄数。表后解释给出具体代价与反例。
| 条件 | 指标 | 基线 | 本方法 | 比较对象 |
|---|---|---|---|---|
| 首次调用四门全过 | 1 次通过数 | A Codex-only baseline completes 12 models in one shot | the same Codex agent equipped with the SURE-EVAL Tool Agent Workflow completes all 18 in one shot | 同一编码智能体 |
| 未全过情况 | 失败分布 | A Codex-only baseline completes 12 models in one shot | the same Codex agent equipped with the SURE-EVAL Tool Agent Workflow completes all 18 in one shot | 同一证据与预算 |
上表支持的判断是结构化工作流把基线失败转为首次调用成功，失败横跨识别、合成、日志与带标签识别，涉及后端依赖栈、非标准检查点布局、模型特有生成接口与任务相关模式映射等不同模糊来源，因此不只是学会某个仓库模板。必须同时说明未胜出项：基线本身已通过多个版本，说明通用编码智能体并非不能上线，增益来自选择性上下文、角色对齐记忆、显式未解决字段与有序验证门阻止了已拒绝路径反复试错与局部变通削弱接口。限制是该结果不涉及识别或合成质量，也不涉及多次运行的方差，方法论价值仅在于阻止导入成功或非空回复冒充可评测。
统一识别评测在提交公共硬件、推理、数据集、输出与打分契约后产生，论文明确不作无约束榜单解读。英文专用检查点的中文条件记为不支持而不保留无意义字符错，多语系统在英中数据集上保持可用。机制上这体现了按语义归一化：不支持的语言模式保持可见，而不是静默选更有利的模式。结论可追溯到同一打分路由，而非逐模型规范化或选择性评测器。未评测边界是部分检查点英文低词错与中文不可用的权衡，运行记录保留不支持行为，这对选型有操作意义，但常在论文特有结果表中被省略。
换成统一协议后论文报告的数字还成立吗？
比较问题是同一名义子集下论文特有执行与打分设置换成提交后的统一契约会偏移多少，公平条件是同一提示目标与子集定义，指标方向是内容错越低越好，差值定义为统一减去报告。下表只用原文连续句中出现的区间值，不逐格复制矩阵中的逐模型小数，避免把矩阵裸值误当句子证据。表后解释给出方向性结论与反例。
| 条件 | 指标 | 基线 | 本方法 | 比较对象 |
|---|---|---|---|---|
| 名义子集 | 报告与统一差 | paper-reported and unified results | absolute differences of 0.02–0.52 points between paper-reported and unified results | 3 个合成系统 |
| 分语言方向 | 中文与英文偏移 | with shifts from -0.02 to +0.10 points | all three unified scores are lower by 0.23–0.52 points | 中文与英文子集 |
上表支持的判断是差距随模型与语言变化，而不是统一契约一致更严或更松：中文统一分数接近报告值，英文统一分数系统性更低。论文明确不把原结果判为错误，它们描述的是不同且有时未完全说明的评测声明。差异来自模型检查点选择、推理参数、提示引用处理、随机生成、识别前端、规范化与聚合路由的多因素交互。这是一个多因素消融，不是单变量对照，因此不能把偏移归因到某一个前端或某一条规则。
合成多维视图进一步显示内容错、说话人相似估计与非侵入质量预测器的排名并不一致，默认向量模式与关闭向量模式在内容错与相似度之间存在权衡，这确认了每个评测节点的身份、版本与模式都是科学声明的一部分。
哪些结论不能从证据中推出？
首先区分 3 类表述。直接报告是：完整工作流全部 1 次通过、基线部分 1 次通过、统一协议下英文统一分数更低。有限解释是：结构化路由把异构情况转成同一移交接口、统一视图暴露单指标隐藏的权衡。未验证推测是：未来扩大注册表与社区服务能让研究更透明可比，这属于展望而非已验证因果。
缺失证据不是技术错误，但必须点名。原文未测量误判率之外的延迟、成本与帧率，不能承诺这些量得到改善。未给出重复运行统计可靠性，不能把 1 次通过推广为每次必过。未给出训练资源分解，推理开销与实际延迟要分开讨论。相关性不等于因果：编码器与质量预测器排名不一致只能说明节点身份重要，不能证明某个编码器普遍正确，注册表也不主张某种规范化普遍正确，只要求所选等价策略显式、对所有被比较系统一致并可从制品中恢复。
另一个常见误解是把无训练当成确定性。即使参数冻结，温度、采样、回退与分块仍可能改变输出。把不支持字段记为不适用也不等于公平，公平指语义适用维度被固定且例外可见。总体趋势不等于每组每步成立，中文接近而英文系统性偏低就是反例，任何跨语言平均都必须先说明是否包含不支持条件。
要重放一次可比评测先固定什么？
复现的第一步不是跑模型，而是拿契约。按论文实际做法，先准备模型身份、仓库检查点指针、运行时包络与可调用输入输出契约，把未知权重位置与设备要求标为未解决。再用任务与环境指引做隔离环境与封装，按导入、加载、最小推理、输出契约四道门验证，任何放宽模式的成功都不算就绪。
第二步是提交运行再执行。先固定加速器类别与拓扑、运行时版本、精度量化，再固定任务语言模式、温度、波束搜索强度、回退重试、提示传播与分块语义，不支持的记为不适用。再固定数据集实例、输出模式抽取规则、规范化路由、指标实现聚合版本，记录解析后的节点标识而非可变最新别名。提交后先跑有界冒烟测试验证同一端到端界面能读数据、能产模式合法预测、规范化能接受、指标能出报告字段，失败进入阻塞重规划或移交工具智能体，不绕过失败节点，不按原契约报告部分分数。
关键超参数与信息条件按原文保留：本地推理单卡批量一无量化，支持控制的解码器固定温度零与波束一并禁用回退重试。代码、权重与系统可运行要区分：本次没有可用性证据，只能说论文文字描述了匿名节点清单与代表性运行制品在补充材料中，复现者需要补做的验证是把矩阵中的逐模型数值与运行清单中的节点版本逐 1 对齐，并检查表头单位与聚合对象是否一致，数值相同不代表指标相同，百分点与相对百分比也不能混用。
何时值得用这套框架？一句话如何带走？
当你的困扰是论文数字复现不出、名义相同的模型没法比、新仓库接入门槛高时，这套框架值得尝试：它把分数从检查点属性改成可执行声明，用智能体解释证据，用确定性程序决定分数。复现时先做上线四门，再做协议提交与冒烟测试，最后才看全量分数。需要补的验证是重复运行稳定性、更多任务与评测节点的覆盖、以及延迟成本等未测量量的记录。
带走的判断是：可比分数要求联合指定可调用工具、推理协议、规范化契约与评测器，缺任何一项的排名都可能反映流水线选择而非模型能力。论文用多个版本的 1 次通过对比证明上线脚手架的价值，用统一识别与合成评测证明隐藏执行与打分选择会实质改变解释，用报告与统一的协议分析证明差距可审计而不是笼统归因于复现误差。
📎 论文与评分元数据
排名：前50% | 文档类型：系统技术报告 | arXiv 原文
⚖️ 评分明细
评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。
评分规则：type-aware-v1
评分模型：muse-spark-1.3-contributor
评分请求协议：openai_responses