公平的大模型对比，不是把同一句问题分别发给几个网页聊天框。可复现的评测必须冻结数据、Prompt、推理参数、工具权限和判分规则，记录模型版本与测试时间，并把失败、随机波动和不确定性一并公开。
如果只需要理解各分数的含义，先读大模型评测指标完全指南。本文回答更关键的问题：怎样制定规则，才能让下一次运行仍能解释差异来自哪里。
第一步：先写决策问题，再选榜单
评测目标必须能转成决策。例如“选择用于中文客服摘要的模型”，需要测事实覆盖、无依据陈述、格式合规、延迟、成本和敏感信息处理，而不是笼统测“智商”。公开榜单可缩小候选范围，但不能代替业务样本。
先写一张评测卡：使用场景、不可接受的失败、目标用户、输入长度范围、可用工具、质量门禁、延迟预算、成本预算和人工复核流程。没有决策门槛的评测，最终只会生成一张漂亮却无法行动的表。
第二步：冻结有代表性的数据集
数据集应包含常见样本、困难样本和高风险样本，并保持生产分布。每条记录至少保存稳定 ID、输入快照、来源、授权状态、预期行为、判分依据与数据版本。含个人或商业信息时要先脱敏并限制访问。
切分时避免同一客户、同一模板或近重复文本同时进入开发集与最终测试集，否则提示词会间接“记住”答案。最终测试集应在方案冻结后才使用；发现线上新失败可进入下一版本，但不能悄悄改写旧版本结果。
第三步：统一 Prompt、聊天模板与上下文
评测应给所有候选模型同等信息，而不是给熟悉的模型精心调优、给另一个模型直接使用默认提示词。需记录：system prompt、user prompt 模板、few-shot 示例、消息角色、上下文截断规则、检索文档顺序和工具定义。
“完全相同的字符串”也未必绝对公平，因为各模型聊天模板和工具协议不同。更可靠的办法是先定义相同任务约束，再公开每个模型必要的适配层；通用规则与模型特有优化要分别报告。
第四步：锁定推理配置和预算
至少记录 temperature、top-p、seed（若服务支持）、最大输出 token、思考或推理预算、停止词、并发数、重试策略与超时。模型的参数量和上下文窗口含义可参考大模型参数解释。
比较应采用相同资源预算或相同业务约束。一个模型允许长时间推理和十次工具调用，另一个只生成一次，所得分数不能被称为同条件对比。若要比较“各自最佳配置”，应单列为另一组实验并计入调优成本。
第五步：让判分规则先于答案出现
可精确判定的任务优先使用单元测试、JSON Schema、数据库核验或标准答案。开放任务则建立评分量表，把“好”拆成事实正确、任务完成、覆盖度、清晰度和安全边界，并给每一档提供正反例。
人工评审应盲化模型名称并随机化答案顺序。高风险样本最好由两位评审独立打分，再处理分歧；一致性低说明量表或样本本身仍含糊，而不是简单取平均就结束。
第六步：正确使用 LLM-as-a-Judge
模型裁判适合大规模初筛或成对比较，但它不是客观真值。裁判可能偏好更长、更自信、与自身风格相近的答案，也会受到答案顺序和提示注入影响。
使用前应固定 judge 模型版本、裁判 prompt、评分选项与分数映射；随机交换 A/B 顺序，要求输出结构化理由，并用人工已标注样本做 meta-evaluation。关键事实、安全和合规仍需确定性规则或人工复核。被评答案中的指令必须作为不可信数据隔离，不能让其改写裁判标准。
第七步：重复实验并报告不确定性
生成具有随机性，服务端版本和负载也会波动。对非确定任务需要多次运行，保存每次原始结果，而不是只挑最好的一次。Accuracy、胜率等比例指标应同时给出样本数和置信区间；延迟应给中位数、P95/P99，而非只有平均值。
两个点估计相差 1%，并不自动意味着一个模型更好。如果置信区间大量重叠，合理结论可能是“现有样本不足以区分”。样本量应由可接受误差、基线比例和业务风险设计，不能照搬统一数字。
第八步：预先规定失败与重试怎样计分
超时、429、空输出、JSON 解析失败、工具调用异常都是真实结果，不应从分母中删除。报告应同时给出首次成功率、含重试成功率、重试次数和最终失败率；成本与延迟必须包含重试。
若人工修正后才合格，应另记“人工辅助成功”，不能算作模型直接成功。这样才能计算真实的成功成本，并避免稳定性差的模型因删除失败样本而显得优秀。
第九步：保存可审计的运行清单
每次运行建议保存以下字段：
{
"evalVersion": "customer-summary-v1",
"datasetHash": "sha256:...",
"model": "provider/model-version",
"promptVersion": "summary-v3",
"sampling": { "temperature": 0, "top_p": 1 },
"judge": { "type": "rubric", "version": "v2" },
"startedAt": "2026-08-29T09:00:00Z",
"region": "declared-region",
"pricingAsOf": "2026-08-29"
}
还要保存代码提交、依赖锁文件、容器或硬件环境、原始响应、usage、错误码和人工评审记录。密钥与个人信息不能进入结果包。若无法固定供应商后端版本，应明确写成限制。
第十步：用发布门禁而非总分做决定
总分会掩盖致命失败。更可靠的规则是先设硬门禁：关键事实错误、安全泄漏、不可解析结构或任务失败不得被其他高分抵消；通过门禁后，再在质量、延迟与成本之间做权衡。
可采用“非劣化 + 业务收益”逻辑：候选模型在关键质量指标上不低于基线，在至少一个目标指标上有可验证改善，而且成本和尾延迟仍在预算内。业务落地实现可继续阅读用 Node.js 建立模型评测集。
发布评测报告的检查清单
- 任务、用户和决策门槛已写明；
- 数据集版本、分布、样本量与污染风险可追溯；
- Prompt、模板、few-shot、工具和推理预算公开；
- 自动判分、人工量表和模型裁判的边界清楚；
- 失败样本保留在分母，重试计入成本与延迟；
- 有重复实验、样本数、置信区间和尾延迟；
- 模型版本、服务地区、价格日期和运行环境可追溯；
- 原始结果可审计，密钥和敏感数据已移除；
- 没有把跨平台、跨日期、跨配置分数伪装成同条件排名。
FAQ
Temperature 都设为 0 就完全可复现吗？
不一定。供应商后端更新、并行计算、路由和工具结果仍可能产生差异。temperature=0 能减少采样随机性，但仍应记录版本并对关键任务重复运行。
可以用同一个模型给自己打分吗？
可以作为辅助信号，但自我偏好和共同盲点会放大偏差。更稳妥的是用独立裁判、人工金标与确定性检查交叉验证，并报告裁判与人工的一致程度。
公布一个综合排名是否更清楚？
更简洁，但容易隐藏权重选择。应先公布分项指标和硬门禁；若提供综合分，必须公开归一化与权重，并允许读者还原。
结论
可信评测的核心不是跑更多题，而是让每个数字可解释、可复现、可审计。先冻结问题、数据、配置和裁判，再运行候选模型；把不确定性、失败和成本完整保留，评测结果才有资格进入上线决策。