15 分钟手工搭一套 LLM 评测集：不用 MLflow，不用平台

每次换模型、改提示词、调 temperature，你想知道结果会变好还是变坏，但只能拿刚生成的那几段读一遍，凭感觉说"感觉差不多"。这套流程撑得过 demo，撑不过生产：感觉不稳定，跨人不对齐，过两周你自己也记不清上次到底是什么水平。

评测集是解药，但它不一定要重。下面这套方案，一个 JSON 文件加一个 Python 脚本，15 分钟能跑起来，只需要你手头有一份真实的任务列表。

第一步：题从哪来

永远不要手写理想化的题目。 去翻生产日志或 beta 用户反馈，把最近 30 天里"答错了"或"用户追问了第二遍"的请求筛出来，每个 case 就是一个未来的测试题。

筛的时候留三种：

• 答错答案的（有明确对错）
• 答对但很啰嗦或很离谱的（质量问题）
• 边界场景（超长输入、中英混排、模糊指令）

10~20 个就够开始。50 个以上才是"维护一套评测"的负担，前 20 个价值最大——它们全部来自你的真实失败记忆。

第二步：每道题长什么样

一个 JSON 数组，每题三个字段：

{
  "id": "invoice-overflow-001",
  "prompt": "这是一张 $47.99 的账单，套餐是 $45，请处理差额",
  "expect": {
    "contains_any": ["$2.99", "2.99"],
    "max_tokens": 200
  }
}

expect 是断言层，按任务类型挑：

• 事实性任务（计算、提取、翻译）：contains_any / not_contains / 精确匹配，能自动化判分的直接判
• 格式任务（要 JSON、要表格）：加 json_valid: true，或做一次 schema 检查
• 风格任务（写文案、改写）：别硬写关键词，在 expect_notes 里留一句人话，跑完人眼扫一遍，60 秒一个 case，比维护脆弱的关键词更快

关键原则：能自动断言的绝不人眼判，人眼判的只留给真正主观的部分。 如果一半的 expect 你写了又删、不知道写什么，说明这类题不适合进当前版本的评测集。

第三步：跑分和对比

脚本核心 20 行：循环每题调一次 API，收集输出和耗时，对 expect 跑断言，输出一个表格：

case	通过	耗时	备注
invoice-overflow-001	✅	2.3s
mt-fallback-zh-003	❌	4.1s	漏了"半宽括号要保留"

对比用法值钱的地方在这里：换模型/改提示词之前跑一版，把输出存进 runs/20260901-before/，改完跑进 runs/20260901-after/，diff 两个文件夹。重点看三类变化：

1. 以前对的现在错了（回归，最严重，优先修）
2. 以前错的现在对了（改善，先确认它为什么对）
3. 两边都错但错法变了（中性，记一笔，观察趋势）

别追求一次覆盖所有维度。第一版只回答一个问题：这次改动，家里的 case 掉了几道。

三个常见的坑

坑一：题目泄露。 如果线上用户会接同一个提示词，评测题里的 prompt 一旦出现在对外文档、错误信息或日志里，等于开了作弊通道。题目 ID 和 prompt 不要外泄。

坑二：temperature=0 的假确定性。 很多模型 0 温度下输出仍有微幅波动，两次跑分输出不一样，不代表模型变坏或变好。判断"回归"至少连跑 2 次，两次都错才记。

坑三：集子只进不出。 "连续 5 次全对且从未再出错的 case"移到 archive/ 子目录。留在主集里的，应该永远是能区分模型高低的题，而不是全公司历史上的题。

从哪里开始

打开今天的 API 日志，筛出 10 个"答得不理想"的请求，写成 JSON，补上断言，跑一次、存档，评测 v0.1 就有了。下一次改提示词或换模型之前先跑 v0.1，你会拿到一个数字，而不是一个感觉。这个数字，就是你和下一个版本之间的那份合同。