公开榜单只负责筛选模型，真正的产品评测才负责做决定

Artificial Analysis 推出了 Optima：团队可以从自己的文件、Agent 轨迹、代码环境或任务描述出发，建立专属 benchmark。它的产品主张很务实——不要默认公开排行榜能替具体业务选出正确系统，而应同时比较质量、单任务成本和单任务耗时（官方发布说明）。

这个界面变化确实有价值，但它并没有改变评测的基本难题。私有数据一样可能偏离真实用户；自动生成的 rubric 可能奖励错误行为；模型评分器可能高度自洽，却与客户判断相反；样本可能泄露答案，harness 可能偏向某一家模型，而一次运行的偶然结果也可能被包装成采购依据。

因此，小团队今天最值得改变的，不是“把全部 benchmark 搬进 Optima”，而是：不要再购买一个模型分数，要开始维护一套决策仪器。

本文给出一份私有产品评测晋级协议。核心包括：边界清楚的决策合同、三类任务库、开发/校准/盲测证据隔离、证据保管台账、评分器校准、措辞变体、重复试验、有效任务成本，以及由责任人签字的晋级凭证。Y Build 没有运行本文建议的实验；下文所有空白结果和阈值都不是实测数据。Optima 的能力与示例属于厂商说明；其他项目用于解释设计边界，不证明这套协议可原样适用于所有产品。

Optima 改变了什么，又把什么留给了团队

Optima 的产品页称，团队可以导入已有评测文件、Hugging Face 数据集、受支持平台的 Agent 轨迹或代码环境。团队也可以提供用例描述与输入/输出示例，由 Optima 构建 benchmark。平台另行支持 rubric 评分或成对偏好评分，并同时报告表现、单任务成本和耗时（Optima 产品页）。

这些能力能消除真实的启动阻力。三个人的小团队不应先造一套分布式评测基础设施，才有资格比较两个候选模型。直接导入真实轨迹，也比从通识问答题开始更接近产品。

但平台不能替团队决定证据意味着什么。至少还有五个问题必须由产品方回答：

1. 导入的轨迹代表哪一部分线上用户？
2. 哪些低频失败虽然样本少，却必须获得更高权重？
3. rubric 测到的是客户结果，还是一份看起来整齐的答案？
4. 评分器能否分辨“可接受的另一种做法”和“真正错误”？
5. 平均质量提升，能否弥补恢复变慢、方差变大或一次严重失败？

Optima 的发布材料展示了示例结果，也主张用户可以找到显著降低成本或耗时的替代方案。这些适合用来说明产品功能，不应当成独立模型结论。最终结果取决于任务、模型版本、harness、评分器和运行日期。可引用的评测单位是完整配置，不是图表顶部那个模型名字。

窄 benchmark 会让问题更好，不会让答案包打天下

另外两个近期项目，更容易看出“缩小范围”的价值和边界。

MathCode 围绕一个难而明确的流程构建终端 Agent：把自然语言数学题转成 Lean 4 定理，并尝试完成形式化证明。能够编译通过的证明，比一段流畅解释更接近可验证终态。但 MathCode 在形式化任务上的成功，不能证明同一系统能处理客服分流、合同审查或产品调研。验证器越专，结论也必须越窄。

LittleLearner 控制的是另一条边界。研究者从零训练一个 50 亿参数模型，使用一套 880 亿 token 的语料，明确筛选为美国小学课程范围内的内容，并排除五年级以上教授的概念、事实和词汇。作者把它定位成研究“模型在已知训练边界内外学到了什么”的受控沙盒。首轮实验发现，后训练和上下文学习能帮助模型更好利用已有知识，但没有显著抬高范围之外的能力。

这是特定研究环境中的证据，不是采购报告。它对产品评测最有启发的地方，是训练边界可解释。团队也应该用同样克制的方式写结论：

• “候选 B 在固定配置下通过了我们的 24 个退款政策样本”是有边界的说法；
• “候选 B 是最聪明的客服模型”不是；
• “72 次已声明试验里没有观察到严重违规”是证据；
• “候选 B 很安全”不是。

窄评测的可信度来自它主动缩小结论，而不是借小测试偷渡大结论。

评测用户真正拿到的产品系统，而不是模型标签

用户从来不会单独体验一个基础模型。他们实际接触的是一个系统。HELM 这类公开评测框架会尽量统一模型适配方式，以便横向比较；私有产品评测还多一项相反但同样重要的责任：必须保留用户上线后会遇到的那套具体适配。

系统结果 = 模型快照
         + 提示词与政策
         + 工具定义与权限
         + 检索上下文与客户状态
         + 编排、重试与 fallback
         + 用户界面与恢复路径

Anthropic 当前的 Agent 评测指南明确区分两类脚手架：Agent harness 负责驱动模型、工具和循环；evaluation harness 负责任务运行、轨迹记录、评分与聚合。团队口中的“我们评测了模型 A”，往往实际是“我们在一个 scaffold、一个工具 schema 和一档预算下评测了模型 A”。

因此，每个候选系统都要冻结完整指纹：

任何关键字段发生变化，旧凭证就过期。营销名称稳定，不代表被评测的系统没有改变。

先写清楚唯一的晋级决策

假设一家小型 SaaS LedgerLane 会读取费用凭证，并生成交给财务人员复核的会计资料包。团队看到某个新模型在公开比较中更快、更便宜，想替换现有系统。实际流程包含图片提取、供应商匹配、重复凭证判断、政策检索、异常解释，以及人类审批队列。

他们不应从“哪个模型最好”开始，而要先写成一个决策：

候选系统 B 能否在三个已支持市场的英文凭证范围内替换现有系统，在不增加严重政策漏检的前提下，降低每份有效资料包的成本或人工复核时间？

这句话同时限定了用户范围、现有基线、候选对象、风险边界和有效收益，也暴露了哪些内容不在本次结论里。它不证明多语言质量、税务建议、欺诈识别、自动付款批准，或其他文档格式上的表现。

开始生成任务之前，先写好四种结果：

• hold：证据失效、不完整，或触发阻断阈值；
• shadow：候选系统只做影子运行，不向客户展示结果，用于收集更接近生产的证据；
• limited_go：仅向一个已命名的低风险分群开放，并保留自动 fallback；
• promote：只在已声明范围内设为默认系统。

如果不提前定义结果状态，团队很容易把任何有趣的分数都解释成“可以上线”。

建三类任务库，让每一类只回答一个问题

把所有样本堆在一起，只会得到一个掩盖测试目的的平均数。至少应维护三类任务库。

1. 核心验收库

先放入 20–50 个普通任务，来源包括人工上线前检查、客服问题与产品需求。Anthropic 认为，这个数量对早期 Agent 评测是务实起点；成熟产品若要识别更小的差异，则需要更大的样本。LedgerLane 的核心样本可以包括：清晰凭证、已知供应商、常见币种、标准政策字段和普通重复状态。

它回答的是：候选系统能否稳定完成客户已依赖的工作？通过率应足够高，能充当回归门禁。

2. 边缘与高后果库

这里放低频但代价高的情况：金额被裁切、日期冲突、跨 workspace 重复上传、凭证里出现类似 prompt 的文字、不受支持的税务结论、缺失币种、供应商别名歧义，以及试图越过审批边界执行写操作。

不能让出现频率抹去严重性。一次自动付款、一次跨租户泄露，或一句编造的合规结论，都可能直接阻断晋级，即使另外 99 个普通样本通过。

3. 能力前沿库

加入现有系统经常失败、但一旦解决就有明显产品价值的任务，例如多页票据包、手写备注、混合语言字段，或必须精确引用政策条款的受限解释。初始通过率低并不是问题。它问的是候选系统是否打开了有价值的新能力，而不是能否守住已有合同。

报告时必须分开三类任务库。候选模型可能一边提高前沿能力，一边破坏核心流程。把两者合成总分，会把真正的取舍藏进一个舒服的平均数里。

把学习证据与晋级证据彻底隔开

上述三类任务库说明样本为什么存在；每一类内部还需要三种访问分区，说明样本可以怎样使用。

在任何调优之前完成分区，并记录内容哈希与 split ID。不要让近似重复、同义改写或同一客户事故跨分区出现。可以维护加盐后的相似度检查，也可以给样本标注人工 family ID，确保同一个底层例子不会既当教材又当考题。

晋级盲测集必须控制访问。构建者可以知道它的类别、数量、严重程度构成与评分方法，但不应看到具体内容和预期结果。保管人记录每一次访问。只要构建者看过某个盲测样本，这个样本就要退出盲测集；不能因为“大家应该记不住表格改动”就继续称它为盲测。

盲测集一旦打开，本轮只能得到两种结果：接受冻结配置下的比较结果，或者继续调系统并重新准备新的晋级证据。用同一批盲测样本反复改 prompt、rubric、工具、阈值或 harness，等于把发布门禁偷偷变成开发集。小团队可以把退役盲测样本转入回归库，但必须用新近授权的失败案例、新写的合成样本或独立储备池补充盲测区。

这正是本文与通用评分器指南的主要区别：它假设评分器独立性和校准已经完成，重点治理的是私有 benchmark 本身是否仍然有效，是否有资格授权晋级。

私有证据要有用，也不能变成黑箱

私有任务能降低模型记住公开答案的概率，也更贴近产品，但同时带来数据保管、隐私与审计问题。

OpenAI 最近的第三方评测共同方法建议在可能时采用私有或新构造任务以降低污染风险，同时也特别提示 broken problem、harness 影响、捷径、拒答和抽样复核。隐私只能解决有效性问题中的一项。对 Optima 的独立报道也给出了相同边界：用例相关性提高，并不会自动消除数据质量和评测偏差（The Decoder）。

每个 fixture 至少要记录：

不需要真实客户内容时，就用合成替代。确实需要真实样本时，应减少字段、限制访问、设定留存期，并把可复用 fixture 与可识别原始材料分开。把生产轨迹上传到托管评测服务之前，先确认对方的数据处理、留存、训练用途、访问控制、删除能力与区域条款满足团队义务。

公开报告可以披露任务类别、各分区数量、哈希、评分器类型、重复策略、访问例外与局限，而不公开私有记录或答案。所谓“私有”不能等同于“无法审查”。

让每一种评分器都受另一类证据约束

不同主张需要不同评分方法。

确定性检查适合验证字段、schema、数据库状态、权限边界、数字对账、引用和其他可直接从系统读取的事实。对 LedgerLane 而言，声称的总额必须等于行项目之和；供应商必须真实存在；重复凭证不能产生第二份草稿；付款状态绝不能被改变。

模型评分器适合辅助判断解释质量、政策相关性，或草稿是否保留了关键限制。它必须使用版本化 rubric 和人类校准样本。候选模型不能成为自己输出的唯一裁判；并且在晋级盲测集打开前，评分器独立性工作必须已经完成。

人工复核负责歧义、高后果和依赖品味的样本。领域评审应能选择 accept、reject 或 abstain，记录原因，也能对奖励错误目标的 rubric 提出异议并要求复核。

产品结果要放在受控离线有效性之后。影子模式对账、复核时间、纠错率、放弃率和用户反馈，才能检验离线分数是否代表真实价值。

OpenAI 的上下文评测方法建议：由领域专家维护 golden set，在接近真实条件下运行，纳入低频但高代价的边缘情况，定期审计模型评分器，并持续吸收线上信号（Specify → Measure → Improve）。NIST 也要求记录测试集、指标与工具，并在接近部署条件的环境中证明表现（AI RMF Measure）。

实操规则可以压缩成一句话：任何一种评分器都不能一锤定音。确定性检查约束模型评分，人类校准主观 rubric，生产结果再检验离线构念是否真的重要。

改写措辞并重复运行，再相信模型排名

同一道任务的一种表述，不能代表它在线上可能出现的全部表达。新的 BenchDrift 研究沿语言、指代、语用和结构四个维度生成保持语义不变的改写。在 8 个模型和 3 个 benchmark 上，原本答对的可能变错，原本答错的也可能变对；作者报告称，更强模型仍然会受措辞变化影响（论文、代码与数据）。

不能把论文里的漂移比例直接套到产品 prompt 上，但它足以挑战“一个问题只测一种写法”的脆弱假设。

对 LedgerLane 的每个高价值意图，建议建立四种版本：

1. 线上最常见的普通说法；
2. 保持要求不变的更短说法；
3. 调换上下文和约束出现顺序；
4. 使用代词、前序状态或界面标签的真实指代变体。

由领域评审确认每个变体保持同一预期行为。如果改写改变了要求，它就是新任务，不是鲁棒性变体。

对于非确定系统，每个变体至少运行三次。轮换候选顺序，并让每次试验都从同一个干净、已设种子的环境快照重新开始，不能继承上一次状态。首次通过与恢复后通过要分开记录。最终报告分布和最差的关键切片，不只报平均数。

一个有意保持克制的起点是：30 个基础任务 × 4 种变体 × 3 次运行 × 2 个候选 = 720 次试验。预算更小可以减少基础任务，但应先保留类别、变体、重复和严重样本，再考虑扩大宽度。

先过有效性门禁，再谈经济性

Optima 把单任务成本和耗时放在质量旁边，方向是对的。产品团队应先确认盲测集仍保持盲态、评分器通过校准、没有阻断失败，而且候选系统守住核心任务库，然后才比较每个有效结果的成本。

有效任务成本 =
  （模型 + 工具 + 检索 + 评分 + 重试 + 人工复核成本）
  / 经独立验收的任务数

首次验收与恢复后验收必须分开；同时报告 p50/p95 耗时、每个有效任务的人工复核分钟数、不同任务库的成本，以及 fallback 后实际使用了哪个模型。

一个便宜模型如果让人工复核时间翻倍，总成本可能更高。一个很快的模型如果产生低频但不可接受的状态，就仍然不能上线。团队必须预先定义：多大的成本、时间或能力前沿提升，才值得承担切换系统的运营成本；略高于零、但没有实际意义的点估计不算收益。

严重安全或隐私失败不能先折算成钱，再塞进平均数。阻断约束仍然是约束。

用一份版本化评测合同固定实验

第一次运行候选系统之前，就应保存实验定义。一份可复用的最小合同如下：

eval_id: ledgerlane-receipt-review-2026-08
decision: replace-incumbent-for-supported-english-receipts
population:
  markets: [market_a, market_b, market_c]
  languages: [en]
excluded_claims:
  - tax_advice
  - fraud_detection
  - payment_approval

systems:
  incumbent: {model: null, prompt_hash: null, harness_sha: null}
  candidate: {model: null, prompt_hash: null, harness_sha: null}

evidence_custody:
  dataset_split_ids: {development: null, calibration: null, promotion_holdout: null}
  dataset_hashes: {development: null, calibration: null, promotion_holdout: null}
  holdout_custodian: null
  access_log: null
  contamination_check: null
  post_open_tuning_requires_fresh_receipt: true

task_banks:
  core: {base_tasks: 20, variants_each: 4, trials_each: 3}
  edge: {base_tasks: 8, variants_each: 4, trials_each: 3}
  frontier: {base_tasks: 2, variants_each: 4, trials_each: 3}

graders:
  deterministic: [schema, total_reconciliation, duplicate_state, no_payment_write]
  model_rubric: {model: null, prompt_hash: null, calibrated_cases: 12}
  human_review: {owner: null, mandatory_cases: [all_severe, all_abstain]}
  blind_adjudication: {enabled: true, candidate_labels_hidden: true}

blocking_gates:
  severe_policy_misses: 0
  cross_tenant_disclosures: 0
  unauthorized_writes: 0
  core_regressions_vs_incumbent: 0

benefit_gate:
  require_one_of: [lower_accepted_task_cost, lower_review_time, frontier_gain]
  minimum_meaningful_delta: null
  comparison_method: paired_by_fixture_with_interval
  uncertainty_rule: hold_if_interval_crosses_predeclared_delta

signoff:
  decision_owner: null
  independent_reviewer: null

result:
  decision: null
  evidence_bundle: null
  expires_on: null
  rerun_triggers: []

四个零都是“零观察阻断事件”的发布门禁，不是对总体人群“永远不会失败”的统计证明。必须同时记录试验分母。如果收益小于预设的有意义差异，或配对区间跨过该差异，就选择 hold 或 shadow，不要凭有噪声的点估计晋级。产品责任人签最终决策，独立评审人签证据有效性。

把评测本身当作一款会失败的产品

任务生成的单源偏差。 同一个模型起草任务、预期答案和 rubric，于是它的偏好悄悄变成真值。必须让人复核，并用真实需求和真实失败案例作为任务库基础。

高频轨迹偏差。 导入轨迹会过度代表高频、成功和最近才被埋点的用户。需要主动抽取放弃、纠错、升级、慢任务和低频高后果案例。

答案泄露。 文件名、注释、隐藏状态、仓库历史、联网能力，或开发集里的近似重复题暴露目标。应检查环境、审计跨分区样本 family，并测试候选系统能否在未解决任务前检索到专属细节。

钻 rubric 空子。 评分器奖励“提到政策词汇”，却不检查动作是否正确。表面质量评分必须与终态检查配对。

成对比较不一致。 评分器可能偏好 A 胜 B、B 胜 C、C 又胜 A，也可能因为候选顺序改变结论。要随机化顺序、测量分歧，并把不稳定样本交给人。

回归被平均数遮住。 能力前沿的大幅提升抵消核心流程的小幅损失。不同任务库和阻断约束必须分开。

隐私治理流于表面。 团队口头称其为私有套件，实际却把客户原文复制进多个厂商、日志、表格和评审邮箱。必须维护数据流向和删除记录。

盲测集反复使用。 首次失败后继续调优，再用同一批“盲测”题重跑。暴露样本要退役，晋级必须使用新证据。

快照失效。 托管 alias、评测器或路由政策在批准后改变。任何关键指纹变化都让凭证过期。

无人维护 benchmark。 没有人删除坏题、调查分歧或吸收线上失败。需要明确 owner、复核频率和变更日志。

判断这套协议何时太重，何时仍然不够

当模型、厂商、推理预算、Agent harness、工具权限、检索系统或评分器变化，可能影响客户决策或可变状态时，应使用完整协议。公开 benchmark 无法代表专有工作流细节时，它尤其有用。

如果只是内部写作辅助、强制人工复核、又不处理敏感数据，可以缩小规模：保留决策合同、任务库、模型指纹、评分器校准、重复试验和结果凭证，但减少变体和复核数量。

不能用这套协议为医疗、法律、金融、就业、教育或其他受监管决策做认证。它不证明公平、隐私合规、安全或普遍安全性。具体领域可能仍需要专业验证、受影响用户研究、安全测试、法律审查和持续监控。

它也不足以解决一个全新产品类别里“成功是什么”尚未稳定的问题。此时应先做用户研究并厘清工作流，再优化 benchmark。为错误的产品承诺算出精确分数，不是进步。

一份 48 小时 Build Lab 执行表

**第 0–4 小时：**写下决策、目标人群、排除项、晋级状态和阻断约束。指定产品决策责任人与评测负责人。

**第 4–12 小时：**收集 20–30 个安全基础样本，覆盖核心、边缘与前沿任务库。完成开发/校准/盲测分区，并记录哈希、来源、同意、脱敏、预期行为、访问历史和过期条件。

**第 12–18 小时：**优先实现确定性检查。只有无法从状态或结构直接验证的主张，才使用主观 rubric；至少用 12 个混合样本和领域评审完成校准。

**第 18–24 小时：**生成措辞变体，审查语义等价性，冻结系统指纹和环境，预先计算试验预算、最小有意义差异与比较方法。

**第 24–36 小时：**冻结配置，打开晋级盲测集，轮换候选顺序，并在每次运行前重置到同一个干净环境。坏 fixture 进入隔离区，不能在运行中悄悄修改。

**第 36–42 小时：**检查全部严重失败、评分分歧、弃权样本和候选间的大差异。分别计算各任务库的有效任务成本和复核时间。

**第 42–48 小时：**只针对已声明范围签署 hold、shadow、limited_go 或 promote。附上证据包、局限、过期日期和重跑触发器。证据无效时，正确结果是 hold，不是修一张图表。

真正耐用的资产，是决策仪器

Optima 降低了自定义 benchmark 的使用门槛。MathCode 展示了验证器与窄工作流绑定的价值。LittleLearner 说明，受控范围能让能力边界更可解释。BenchDrift 则提醒团队，一种措辞很容易制造脆弱分数。

这些材料共同支持一个克制的结论：最好的评测既不是最大的排行榜，也不只是最私密的数据集。它应该是团队能长期维护的最小决策仪器——代表真实产品决策，暴露自己的盲区，而且系统一变就能重新运行。

公开 benchmark 仍然重要。它们适合发现候选、展示广义能力、提供共享参照。让公开榜单负责初筛；让版本化的产品评测负责决定；并让每一张晋级凭证都有过期时间。

参考资料

1. Artificial Analysis — Announcing Optima: create a custom benchmark for your use case
2. Artificial Analysis — Optima product page
3. The Decoder — Optima lets users test models against their own data
4. Math-AI — MathCode repository
5. Li et al. — LittleLearner: Language Models Under Pedagogically Controlled Knowledge Exposure
6. Thakur et al. — The Wording Effect: Quantifying Two-Way Drift in LLM Benchmark Performance
7. IBM — BenchDrift code and data
8. Anthropic — Demystifying evals for AI agents
9. OpenAI — How evals drive the next chapter in AI for businesses
10. OpenAI — A shared playbook for trustworthy third-party evaluations
11. NIST — AI Risk Management Framework Core
12. Stanford CRFM — Holistic Evaluation of Language Models