本地模型与 Agent 任务评测
本协议比较完整配置在任务中的表现，不另做一张模型总榜。计时前先区分推理阶段，设置动作阈值前理解概率校准；任务依赖检索证据时，再采用检索与生成评估拆解失败原因。
评测的最小实验单元不是模型名称，而是一组完整的配置组合：
权重 + 量化 + 运行时 + 模板 + 上下文策略
+ 生成参数 + 工具 + 评测框架 (Harness) + 硬件
评测结果对应的是这组完整配置。比较某一个因素（例如量化方式）时，应有意只改变这个因素，并固定其余设置。如果同时改动多个组件，就无法单独判断结果差异来自哪一项变化。
固定运行卡片 (Run Card)
在开始测试前，必须明确并记录以下配置，形成“运行卡片”：
model: organization/model
revision: 不可变的 commit 或 artifact hash
artifact: 精确的文件名及量化格式
runtime: 名称、版本、后端 (backend)、驱动 (driver)
template: 聊天/推理/工具解析器 (chat/reasoning/tool parser)
context: 原生上限、请求长度、KV Cache 类型
generation: temperature、top-p、最大输出长度、seed (若支持)
hardware: GPU、VRAM、RAM、CPU offload 策略
harness: 版本、可用工具、权限、迭代预算
务必将运行卡片与原始结果、失败案例一同归档保存。
评测层级
1. 集成冒烟测试 (Integration Smoke Tests)
在评估模型质量之前，先排除模板或服务端故障。测试项包括：
- 普通对话
- 精确 JSON 输出
- 一次带对抗性干扰项的有效工具调用
- 一次畸形或被拒绝的调用
- 与使用场景相关的多语言文本
- 取消操作
- 上下文边界情况
2. 个人任务重放 (Personal Task Replay)
选取 10–30 个具有外部验收标准的代表性任务。
- 编码任务应涵盖：缺陷修复、跨文件 API 保持、测试诊断、陌生文档处理、证据不足场景、越界操作。
- 知识工作应涵盖：带引用的提取、冲突来源处理、时间相关问题、拒答 (abstention)。
3. 系统行为指标 (System Behavior)
正式记录前先预热运行时。随后记录以下系统级指标：
- 结果接受率
- 严重度加权失败率
- 首 Token 延迟的中位数与尾部值 (First-token latency)
- 解码速度 (Decode speed)
- 端到端耗时的中位数与尾部值
- 峰值 VRAM/RAM
- Offload 情况
- 重试次数
- 工具调用有效性
- 无关 Diff 数量
- 人工介入次数
对比示例
假设对同一 7B 模型的 Q4 和 Q6 版本进行测试，每个版本执行 20 个任务，各重复 3 次：
注：以上表格中的数值仅为报告格式示例，并非声称的实际测试结果。
决策取决于后果阈值。例如，Q6 多出的 6 次接受运行可能使其在写操作场景中更具价值，而 Q4 仍可用于只读的分拣任务。
对于小样本，应报告具体计数和不确定性，而不仅仅是百分比。保留任务级别的结果，以确认性能提升并非由某一类重复的简单任务导致。
量化与上下文测试
在比较不同量化产物时，必须固定运行时、提示词和生成参数。
- 必须包含精确编辑和工具调用测试，因为平均语言基准测试可能掩盖格式退化问题。
- 先测试原生上下文长度；随后通过增加干扰项并将证据放置在不同位置来扩展长度。
- 同时测量 KV Cache 内存占用和质量变化。
外部基准测试
lm-evaluation-harness、HELM 风格评测以及 Aider 的代码基准测试提供了有用的参考锚点。但它们无法复现私有仓库环境、本地量化细节、Harness 权限设置或人工干预成本。
使用外部基准时，需检查：
- 任务版本
- 数据污染风险
- 提示词适配情况
- 样本数量
- 分数是厂商自报还是独立复现
偏差与决策规则
- 个人套件容易过拟合当前工作负载；公开套件容易过拟合其发布的任务分布。
- 英语/Python 代码、成功完成的任务、可用硬件以及能跑起来的模型通常被过度代表。
- 应包含已知的困难失败案例，并定期加入新的保留集 (holdout) 任务。
决策原则： 选择能满足预先声明的任务阈值、且拥有显存余量和可接受严重失败率的最小配置。 当运行卡片中的任何字段发生变化时，必须重新测试，而不是仅仅因为出现了新的排行榜就重新测试。
评估框架的命令行接口指南 说明如何选择任务、限制样本数、输出结果文件和记录逐题结果。先用小型公开基准跑出可检查的结果，再增加规模；逐题输出有助于区分格式错误与答案错误。