搭一条能扛日常迭代的大模型评测管线

TL;DR

评测管线是模型迭代里最容易被低估的工程。 真正能扛日常迭代的管线需要：

1. 可重放：固定数据集 + 固定 seed + 固定推理参数。
2. 可对比：每次评测都打 tag，结果落库可索引。
3. 可解释：能下钻到具体样本看坏 case。

三条准则

1. 数据集 immutable

评测集一旦发布，只能新增版本，不能改旧版。改了就不能跨版本对比。 我用一个简单的命名约定：eval_set_v1.0_2026Q1.jsonl，版本号 + 季度 tag。

2. 推理参数显式记录

config = {
    "temperature": 0.0,
    "top_p": 1.0,
    "max_tokens": 2048,
    "seed": 42,
    "model": "qwen2.5-7b-sft-v3",
}

把这个 dict 跟评测结果一起存 —— 否则三个月后你看到一条 60 分的结果， 根本不知道当时是 temperature=0 还是 0.7。

3. 评分器可版本化

LLM-as-judge 的 prompt 也是代码。改 prompt = 评分器升级 = 跨版本结果不再可比。 prompt 跟着代码走 git，不要写在数据库或者 yaml 里偷偷改。

一个常被忽略的细节

重试逻辑。LLM 推理有概率失败（超时、安全过滤、空输出）。 默认重试 N 次还是直接当 0 分？这个决定会显著影响均分。 我的做法：失败标记为 null，不计入均分，但单独统计 null 率。 null 率超过 5% 视为评测无效。

落地建议

• 别一上来追求 dashboard。先把 JSONL → 评测脚本 → JSONL 的链路跑通。
• 报表用 HTML 输出比 PowerPoint 好用 100 倍——可以直接 python -m http.server 分享。
• 每次评测都生成 case 报告，至少抽 50 条人工看一遍，机器分跟人工感觉经常对不上。