做一套可持续的 LLM 评测体系：离线数据集、在线回放与回归基线

Sun, 22 Mar 2026 02:30:00 +0800

你会发现 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 模板与回归阈值建议。

回归测试 on lategege 的技术博客