llm-eval-set
name: llm-eval-set
description: 大模型评测集设计与回归验证。当要换模型、要改 prompt 又怕掉效果、要证明优化没有劣化、要给 AI 功能建立质量基线时使用。触发词：评测集、eval、benchmark、模型对比、换模型、效果回归、准确率、幻觉率、AB 测试、质量基线、大模型选型。不负责成本核算（走 llm-cost-audit）和 prompt 压缩执行（走 prompt-token-diet）。
大模型评测集设计
没有评测集的 AI 功能，等于没有测试的代码。区别是后者你知道自己在裸奔，前者你以为一切正常。
一、先想清楚测什么
不要一上来就找公开榜单。 公开评测集测的是通用能力，你的业务需要的是特定能力。榜单第一的模型在你的场景排第五，是常态。
回答三个问题：
- 这个功能失败时，用户会怎么描述？ 「答非所问」「编了不存在的条款」「格式坏了导致解析失败」——每一种失败模式对应一个指标。
- 哪种失败最不可接受？ 客服场景里编造政策比回答啰嗦严重一百倍。指标要按这个权重排序。
- 什么样算对？ 如果你自己都说不清，就先写 20 条「标准答案」，写的过程会逼你想清楚。
二、样本从哪来
按可信度从高到低：
- 线上真实请求。 最有价值。从日志里按分层抽样：高频场景、低频场景、报障过的 case 各取一部分。注意脱敏。
- 历史故障。 每一次线上出问题的输入都要进评测集。这是回归测试的核心，保证同一个坑不踩两次。
- 人工构造的边界情况。 空输入、超长输入、多语言混杂、注入攻击、模棱两可的提问。
- 公开数据集。 只用来做粗筛，不作为上线依据。
规模：起步 50 到 100 条就够用，别追求上千。小而准的评测集，胜过大而糊的。样本分布要和线上一致，不要一半都是简单 case。
必须包含负样本：模型应该拒答的、应该说「不知道」的、应该走人工的。只测正样本的评测集会鼓励模型胡编。
三、怎么判分
按成本和可靠性排序，能用前面的就不用后面的。
规则判分（最可靠，优先用）
- 格式合法性：能不能被 JSON 解析、字段是否齐全、枚举值是否在范围内。
- 关键字段精确匹配：抽取类任务的实体、数字、日期。
- 必含 / 必不含关键词：比如回答里必须出现免责声明，不能出现竞品名。
程序化指标
- 分类任务：准确率、精确率、召回率、F1。类别不均衡时看混淆矩阵，别只看准确率。
- 检索任务：Recall@K、MRR、NDCG。
- 抽取任务：字段级 F1。
模型判分（LLM as judge，用于开放式生成）
- 用评分卡，不要问「这个回答好不好」。评分卡拆成 3 到 5 个维度，每个维度给出明确的 1 到 5 分档位描述。
- 成对比较比打分稳定。给判分模型 A、B 两个回答问哪个更好，比让它给绝对分数可靠得多。
- 交换顺序跑两次消除位置偏好，两次结论不一致的算平局。
- 判分模型要和被测模型不同，避免自我偏好。
- 必须校准：人工标注 30 条，看判分模型和人的一致率。低于 80% 就不能用它做上线判据，先改评分卡。
人工判分
- 最贵但不可替代。用于校准自动判分，以及最终上线前的抽检。
- 标注要有明确规则文档，两个人独立标同一批，算一致率。
四、怎么跑
固定变量。 一次只改一个东西：模型、prompt、检索参数，三者不要同时动，否则归因不了。
温度设 0 或最低。 评测要可复现。确实需要测稳定性时，单独跑「同一输入重复 5 次看方差」的实验。
记录完整现场。 每条样本存下：输入、完整 prompt、模型、参数、输出、得分、判分理由、token 用量、耗时。出问题时能查。
报告要给出的东西：
| 项 | 说明 |
|---|---|
| 总分 | 加权后的单一数字，方便比较 |
| 分维度得分 | 定位到底哪一项掉了 |
| 失败样本清单 | 按严重程度排序，附输入和输出 |
| 与基线的差值 | 涨了还是掉了，掉多少 |
| 成本与延迟 | 效果之外的另外两个维度 |
只报一个总分的评测报告，等于没报。
五、判据
上线与否要有事先约定的阈值，不能事后看着数字找理由。
- 不可接受的失败（编造事实、泄露敏感信息、格式导致下游崩溃）：零容忍，出现一条就不能上。
- 主指标：相对基线不低于 -2 个百分点。
- 成本和延迟：在预算内。
- 人工抽检：随机 20 条，人看一遍没有明显问题。
四条全过才上线。任何一条不过，要么改，要么明确写下「我们接受这个代价，因为……」并留档。
六、维护
评测集会腐烂，需要持续喂养。
- 每次线上故障后，把触发故障的输入加进评测集。这是最重要的一条。
- 定期抽查线上分布，业务变了评测集要跟着变。
- 给样本打标签（场景、难度、来源），方便切片分析。
- 纳入 CI：改 prompt 的 PR 自动跑评测，结果贴在 PR 上。做不到全量就跑一个 20 条的快速子集。
- 版本化：评测集本身要进版本控制，改了要能追溯。
七、常见错误
- 在评测集上反复调 prompt 直到分数很高。 这叫过拟合，线上不会好。留一份从不用于调优的保留集。
- 只测平均，不看最差。 用户记住的是最差的那次。看 P95 而不是均值。
- 判分模型没校准就用。 分数好看，实际是判分模型在自娱自乐。
- 样本全是简单 case。 分数 95 分，上线一塌糊涂。
- 换模型只看榜单不跑自己的集。 省下的两小时会以两周的事故排查还回来。