在自己的任务上评测模型
评测的最小实验单元不是模型名称，而是一组完整的配置组合：
权重 + 量化 + 运行时 + 模板 + 上下文策略
+ 生成参数 + 工具 + 评测框架 (Harness) + 硬件
评测结果对应的是这组完整配置。比较某一个因素（例如量化方式）时，应有意只改变这个因素，并固定其余设置。如果同时改动多个组件，就无法单独判断结果差异来自哪一项变化。
用 API 模型时也是同一套做法：权重、量化、运行时和硬件换成服务商和完整的模型 ID，其余各项照样要固定。在两家服务商的模型之间挑，和在同一模型的 Q4 与 Q6 之间挑，用的是同一张运行卡片和同一批任务。
本协议比较完整配置在任务中的表现，不另做一张模型总榜。计时前先区分推理阶段，设置动作阈值前理解概率校准；任务依赖检索证据时，再采用检索与生成评估拆解失败原因。
固定运行卡片
在开始测试前，必须明确并记录以下配置，形成“运行卡片”：
model: organization/model（API 模型写服务商和响应里返回的完整模型 ID）
revision: 不可变的 commit 或 artifact hash
artifact: 精确的文件名及量化格式
runtime: 名称、版本、后端 (backend)、驱动 (driver)
template: 聊天/推理/工具解析器 (chat/reasoning/tool parser)
context: 原生上限、请求长度、KV Cache 类型
generation: temperature、top-p、最大输出长度、seed (若支持)
effort: 推理强度或思考预算、子 Agent 设置
cache: 提示/前缀缓存是否开启，冷启动还是已预热
hardware: GPU、VRAM、RAM、CPU offload 策略
harness: 版本、可用工具、权限、迭代预算
务必将运行卡片与原始结果、失败案例一同归档保存。
评测层级
1. 集成冒烟测试
在评估模型质量之前，先用一小批确定性测试排除模板解析或服务端接线的低级故障，依次测过普通对话、精确 JSON 输出、带对抗性干扰项的有效工具调用、一次畸形或应被拒绝的调用、贴近使用场景的多语言文本、生成中途取消以及上下文窗口边界输入。
工具调用测试要分别在空缓存和已预热的提示缓存下各跑一次。9 月 23 日提交的一个 llama.cpp issue 报告：设置 tool_choice: "required" 后，Qwen3-8B 服务端仍会直接用文字回答，失败集中在复用已预热缓存前缀的请求上；关掉提示缓存后，同样的请求都调用了工具。这只是一位报告者的复现。到 10 月 29 日，这个 issue 仍然开着，没有维护者回复，10 月 24 日被机器人标为 stale；但它足以说明缓存状态应当写进运行卡片。
2. 个人任务重放
选取 10–30 个具有明确外部验收标准的代表性任务。编码任务应涵盖缺陷修复、跨文件 API 一致性、测试诊断、陌生文档处理、证据不足时的克制以及越界操作拦截；知识工作应涵盖带引用的信息提取、冲突来源处理、时间敏感问题以及条件不足时的拒答。
验收标准要靠另一个模型来判时，先照检索与生成评估里的办法，拿手标样本核对评分器。
3. 系统行为指标
正式记录前先预热运行时。每次评测除了统计按预设验收标准计算的结果接受率，还要记录按后果轻重加权的严重度加权失败率（例如改坏无关文件比格式小错代价高，将各次权重相加再除以运行次数）。同时一并记下首 Token 延迟与端到端耗时的中位数及尾部值、解码速度、峰值 VRAM/RAM、Offload 情况，以及重试次数、工具调用有效性、无关 Diff 数量和人工介入次数。
推理强度也要当作测试变量，而不是只往上调的旋钮。Anthropic 报告，Sonnet 5.5 在 FrontierCode 上用 Max 档的得分低于 Xhigh 档。Max 档更常启动拆给多个子 Agent 的代码审查；在 AI 编码公司 Cognition 检查的两个案例中，这导致了超时，或改动超出任务范围。带思考预算的本地模型也可能这样失败，所以至少在同一时间预算内比较两档设置。
对比示例
假设对同一 7B 模型的 Q4 和 Q6 版本进行测试（每个权重约用 4 位和 6 位存储的量化文件），每个版本执行 20 个任务，各重复 3 次：
决策取决于后果阈值。例如，如果 Q6 多出的 6 次接受运行是真实差距，它在写操作场景中更有价值，而 Q4 仍可用于只读的分拣任务。
这 6 次是不是真实差距，要看不确定性，所以小样本应报告具体计数和不确定性，而不仅仅是百分比。拿这张表来算：42/60 是 70%，48/60 是 80%。按正态近似，60 次运行的 95% 区间半宽分别是 1.96×√(0.7×0.3/60) ≈ 12 个点和 1.96×√(0.8×0.2/60) ≈ 10 个点，两个区间约为 58%–82% 和 70%–90%，大段重叠。况且这 60 次只是 20 个任务各跑 3 遍，同一任务的三次结果彼此相关，区间实际还要更宽。所以这 6 次差距不足以下结论。保留任务级别的结果，以确认性能提升并非由某一类重复的简单任务导致。
量化与上下文测试
比较不同量化产物时，必须固定运行时、提示词和生成参数。测试中必须包含精确编辑和工具调用用例，以免平均语言基准测试掩盖格式退化问题；测量上下文能力时，先测试原生上下文长度，再通过增加干扰项并将关键证据放在不同位置来逐步拉长长度。
同一个模型名，背后的模型也会变
用 API 时，代码里写的名字不一定一直指向同一个模型。OpenAI 的模型页在每个模型名下列出带日期的快照，gpt-4o 页面说快照能锁定某个版本，让性能和行为保持一致。Anthropic 的模型总览写明，从 4.6 代起每个模型 ID 本身就是固定快照，包括不带日期的 ID；更早的模型，别名只是指向带日期 ID 的快捷方式。
所以运行卡片里要写 API 响应实际返回的完整模型 ID，而不是代码里的简称。遇到三种情况就把同一批任务重跑一遍：返回的模型 ID 变了；服务商发来弃用或迁移通知；定期重跑时，同一批任务的接受率明显下滑。你自己用户的提示也会慢慢偏离当初挑的那批任务，所以每隔一段时间从新的真实请求里抽几条，加进保留集。
外部基准测试
lm-evaluation-harness、HELM 风格评测，以及 Terminal-Bench 4.0 这类编码 Agent 榜单，提供了有用的参考锚点；挑选 AI 编码 Agent 一页记录了 10 月的榜单。Aider 的 polyglot 榜单最后更新于 2025-11-20，上面没有现在的模型，只能当历史参考。这些基准都无法复现私有仓库环境、本地量化细节、Harness 权限设置或人工干预成本。
引用外部基准前，应核对任务版本、数据污染风险、提示词适配情况、样本数量，以及成绩是由厂商自报还是由独立方复现。
偏差与决策规则
个人套件和公开套件各自会过拟合什么、哪些任务容易被过度代表，怎样判断 AI 实验的证据强弱一页列出了这些偏差。落到这套协议上，就是放进已知的困难失败案例，并定期加入新的保留集任务。
比较多个配置或反复查看结果时，假设检验、效应量与多重比较说明怎样预先确定比较族和停止规则。最终选用满足预先声明任务阈值、保留显存余量且严重失败率可接受的最小配置；只有当运行卡片中的任一字段发生变化时才重新测试，不必每次排行榜更新就重跑一遍。
lm-evaluation-harness 的命令行接口指南说明怎样选择任务、限制样本数、输出结果文件和记录逐题结果。现在的命令行用子命令：lm-eval run 跑评测，lm-eval ls 列出任务，lm-eval validate 检查任务配置；不带子命令的旧写法仍然可用。先用 --limit 跑几条，加上 --output_path 和 --log_samples 保存逐题的输入输出，确认结果能检查了再增加规模；逐题输出有助于区分格式错误与答案错误。