No.363
大模型应用怎么做评测?离线评测和线上评测有什么区别?
一句话回答
大模型的输出是开放的文本,同一输入多次运行结果也不一样,不能像传统测试那样只断言"等于期望值",要用评测集加打分的方式来衡量。离线评测在上线前用固定的评测集跑一遍,用规则检查、模型打分和人工审核给结果打分,用来比较不同的 Prompt、模型和参数;线上评测看真实用户的反馈和业务指标,加上抽样审查和 A/B 测试,确认改动在真实流量下有效。两者要形成闭环:线上发现的失败案例不断补充进离线评测集。
详细解析
为什么比传统测试难
- 输出开放:同一个问题有很多种正确的回答,无法做精确匹配
- 不确定:采样带来的随机性,让同一输入每次的结果都可能不同(见 生成与采样)
- "好"有多个维度:正确、完整、简洁、语气、格式、安全,经常互相冲突
- 牵一发动全身:改一句 Prompt 修好了一类问题,可能弄坏另一类
- 依赖上游:模型供应商更新模型后,行为可能跟着变
离线评测和线上评测
| 离线评测 | 线上评测 | |
|---|---|---|
| 时机 | 上线前、每次改动后 | 上线后持续进行 |
| 数据 | 固定的评测集 | 真实的用户流量 |
| 打分方式 | 规则断言、模型打分、人工标注 | 用户反馈(点赞、点踩、重新生成)、业务指标、抽样审查、A/B 测试 |
| 优点 | 可重复、可对比、成本可控,能在上线前拦住问题 | 反映真实的效果和问题分布 |
| 局限 | 评测集覆盖不全,和真实分布有差距 | 结果滞后、噪声大,发现问题时用户已经受到影响 |
| 主要用途 | 选方案、回归测试 | 验证效果、发现新问题 |
评测驱动的开发流程
文本
定义任务和成功标准
↓
建一个小评测集(几十条,覆盖主要场景和边界情况)
↓
写第一版 Prompt / 流程 → 跑评测 → 看失败案例 → 改进 ──┐
↑ │
└──────────── 没达标,继续迭代 ←───────────────┘
↓ 达标
灰度上线 → 线上监控、用户反馈、抽样审查
↓
线上发现的失败案例加入评测集 → 进入下一轮迭代
从小规模开始,不必等评测体系完备。先准备几十条有代表性的样本,读一遍模型的真实输出,归纳出主要的失败类型,再针对这些类型写检查。之后逐步扩充评测集、自动化、接入 CI(见 回归测试)。
打分方式:从便宜到昂贵
- 规则检查:JSON 能否解析、必填字段是否齐全、长度、关键词、是否调用了正确的工具。便宜、确定,能用规则判断的就不要交给模型
- 模型打分:让另一个模型按评分细则判断正确性、相关性等(见 LLM-as-a-Judge)
- 人工评审:最准但最贵,用来制定标准、校准模型打分,以及评估高风险场景
代码示例
一个最小可用的离线评测脚本:
TypeScript
interface Case {
id: string
input: string
tags: string[]
check: (output: string) => boolean | Promise<boolean> // 规则检查,或者调用评委模型
}
async function runEval(cases: Case[], app: (input: string) => Promise<string>) {
const stats = new Map<string, { pass: number; total: number }>()
const failures: { id: string; output: string }[] = []
for (const c of cases) {
const output = await app(c.input)
const ok = await c.check(output)
if (!ok) failures.push({ id: c.id, output })
for (const tag of ['全部', ...c.tags]) {
const s = stats.get(tag) ?? { pass: 0, total: 0 }
s.total += 1
if (ok) s.pass += 1
stats.set(tag, s)
}
}
for (const [tag, s] of stats) console.log(`${tag}:${s.pass}/${s.total}`) // 按标签看通过率
return failures // 失败案例要逐条人工看
}
面试官可能追问
大模型评测和传统的单元测试有什么区别?
单元测试断言确定的结果,要么通过要么失败;大模型评测是统计意义上的,看通过率和分数分布,允许一定比例的失败,而且要和基线版本对比才有意义。两者不是替代关系:解析输出、执行工具、拼接 Prompt 这些确定性的代码逻辑,仍然要写普通的单元测试。
离线评测分数提高了,线上效果反而变差,可能是什么原因?
- 评测集和真实问题的分布不一致,或者反复针对评测集调 Prompt,对它过拟合了
- 评分标准和用户真正在意的不一致,比如评分偏好又长又全的回答,用户却嫌啰嗦
- 离线没测到的因素变差了,比如延迟变长、成本上升
所以离线评测通过后,还要灰度上线、看线上指标。
评分标准由谁来定?
产品和领域专家定义什么是好的回答,写成评分细则,并给出正反例;开发把细则落实成规则检查和评审 Prompt。标准要先用一批人工标注的样本验证:不同的人按同一份细则打分,结果是否一致。业务规则变化时,标准也要跟着更新。
易错点
- 手动试几个例子就判断"效果变好了"
- 只做离线评测,上线后不再观测;或者只看线上反馈,上线前不做评测
- 一开始就追求大而全的评测体系,迟迟不开始
- 只看总分,不看具体的失败案例
AI 模拟面试官
用自己的话回答,AI 对照参考答案打分、指出遗漏,再追问,最多 3 轮
登录后就可以和 AI 面试官对练,面试记录也会保存下来。登录
这道题你掌握了吗?
选一个最接近的状态,没掌握的题会出现在"我的进度 · 待复习"里。
学习记录暂存在本机浏览器。登录后自动同步到账号,换设备也能看到。