你会发现 LLM 项目最痛的不是“第一次做出来”，而是：
- prompt 改了一句，效果变了
- 模型换了个版本，线上投诉变多
- retriever 调了参数，某些场景突然不好用
如果没有评测体系，你只能凭感觉回滚。
这篇文章给一套我认为可持续的评测框架：离线数据集 + 线上回放 + 回归基线。它适用于：
- 纯聊天问答
- RAG
- Agent（工具调用）
1. 明确评测对象：你到底要“评测什么”
建议先把任务分成三类：
- 检索质量（RAG）
- Top-K recall、MRR、命中率
- 生成质量（答案本身）
- 正确性、完整性、可读性、是否引用证据
- 行为质量（Agent）
- 工具调用是否正确
- 是否遵守边界（不越权、不外泄）
很多团队把这三类混在一起，导致指标失真。
2. 离线数据集：小而真实，比大而虚更重要
2.1 数据集来源
优先用真实用户日志：
- 搜索 query
- 工单问题
- FAQ 热点
如果没有，就让业务同学/客服给 50~200 条典型问题。
2.2 每条样本要有什么“标注”
不要一上来追求完美答案标注。
更轻量但高效的标注方式：
- RAG：标注“应该命中的文档/段落 id”（或至少 doc id）
- 生成：标注“必须包含的要点列表”（bullet points）
- Agent：标注“允许的工具序列/禁止行为”
这样成本低、可扩展。
3. 评测方法：别只用一个 LLM 打分
3.1 检索指标是硬指标
RAG 的检索阶段建议用硬指标：
- Top-5 recall：答案证据是否在前 5 个里
- MRR：正确证据排第几
这能把“检索问题”和“生成问题”拆开。
3.2 生成评测：用 rubric + 结构化检查
如果用 LLM-as-a-judge：
- 必须有 rubric（评分标准）
- 输出结构化（JSON）：
- correctness: 0-5
- completeness: 0-5
- grounded: 0-5（是否有证据）
- notes
同时加一些“硬规则检查”：
- 是否包含引用链接
- 是否输出了敏感字段
- 是否出现禁止词（例如泄露系统提示）
多信号比单一打分稳。
4. 线上回放：把事故变成数据
上线后最有价值的样本来自失败案例：
- 用户追问很多次
- 点踩/转人工
- 明显答非所问
你应该把这些请求“可回放化”，至少包含：
- 原始输入
- 当时的系统提示版本
- 检索结果（doc id、score）
- 工具调用记录（参数、返回）
- 最终输出
这样你能：
- 把失败样本加入离线集
- 做“回归基线”：以后改任何东西都不能再坏
5. 回归基线：评测要能挡住退化
实践里我会设三条线：
- 质量线：核心问题集的平均分不得下降
- 安全线：越权/外泄相关用例必须 0 失败
- 性能线：P95 TTFT/TPOT 不能超过阈值
每次改动（prompt、模型、检索、rerank、工具）都跑一遍。
6. 最小可行实现（MVP）长什么样
如果你今天就要做一个评测体系 MVP，我建议：
- 先收集 100 条真实问题
- 标注：
- 每条一个“参考要点”
- RAG 场景加 doc id
- 写一个脚本：跑完整链路，输出 JSON 结果
- 做一个简单 dashboard：
- 质量分布
- 失败样本列表
- 版本对比
一周内就能跑起来，然后边用边补。
结语
评测体系的价值不是“给领导看分数”，而是让你：
- 敢改
- 改得动
- 改完不怕上线
如果你告诉我你现在的产品形态（纯聊天/RAG/Agent）和数据源，我可以把这套评测框架进一步具体化成：字段定义、样本格式、rubric 模板与回归阈值建议。