如何进行 AI 应用的测试和效果评估?
AI 应用输出非确定、链路长——传统「输入 → 固定输出」单测不够,需要 分层测试 + 离线评测集 + 线上观测 组合。本篇讲面试答法;Agent 轨迹评测见 工具调用与评测实践;RAG 检索评测见 [如何优化 RAG 检索效果](/docs/ai/Agent/面试/如何优化 RAG 检索效果);成本见 Token 计算与成本。
测试 vs 效果评估
| 测试(Test) | 效果评估(Eval) | |
|---|---|---|
| 目的 | 功能对不对、会不会崩 | 好不好用、达不达标 |
| 典型 | schema 校验、Mock LLM、权限、超时 | 成功率、事实性、用户满意度 |
| 确定性 | 高(工具参数、路由逻辑) | 低(开放生成需规则+人工) |
| 时机 | CI 每次提交 | 离线 nightly + 上线后抽样 |
面试一句话:测试保「能跑、不越权」;评估保「答对、答稳、答得起」。
分层评估(先拆链路)
用户请求
↓
┌─ 组件层 ─────────────────────────────────┐
│ 检索 Recall@k │ 工具选对 │ Prompt 格式 │
└────────────────────────────────────────────┘
↓
┌─ 端到端层 ─────────────────────────────────┐
│ 任务成功率 │ 答案事实性 │ 拒答是否正确 │
└────────────────────────────────────────────┘
↓
┌─ 线上层 ───────────────────────────────────┐
│ 抽样人工 │ 用户反馈 │ 成本/延迟/错误率 │
└────────────────────────────────────────────┘
原则: 能在组件层评的不要只评最终字符串——RAG 检索错却被生成「润色」掩盖,是常见盲区。
按应用形态怎么评
1. 对话 / Chatbot
| 维度 | 做法 |
|---|---|
| 功能测试 | Mock LLM 测路由、鉴权、流式、会话存储 |
| 效果 | 小集人工打分(相关、安全、风格);关键场景 must_include / must_not_include |
| 回归 | 固定 seed + 黄金用例;Prompt 变更后 diff 通过率 |
2. RAG
| 层 | 指标 / 做法 |
|---|---|
| 检索 | Recall@k、MRR;(question, gold_chunk_id) 评测集 |
| 生成 | 答案是否引用正确片段;无依据是否拒答 |
| 端到端 | must_include 关键字、LLM-as-judge(需人工校准) |
详见 [如何优化 RAG 检索效果](/docs/ai/Agent/面试/如何优化 RAG 检索效果)、RAG 落地实践。
3. Agent
| 维度 | 指标 |
|---|---|
| 任务成功率 | 端到端是否完成用户目标(查单、改文件、发请求) |
| 轨迹质量 | 步数、调错工具比例、重复调用、是否触达 max_steps |
| 工具层 | expect_tool、参数 schema 是否正确 |
| 安全 | 不可逆操作是否被闸门拦住;租户隔离 no-leak |
{"id": "order-1", "input": "查订单 A100", "expect_tool": "get_order"}
{"id": "brief-2", "user_id": "u1", "session1": "请简短", "session2": "还在吗", "expect_style": "brief"}
轨迹 JSONL(step / tool / args / ok / error)是排障 + 评测 + 审计的共同素材——见 工具调用与评测实践。
离线评测集怎么建
| 步骤 | 说明 |
|---|---|
| 从真实失败 case 采 | 线上 bad case、客服工单、内测反馈 |
| 覆盖边界 | 拒答、多轮指代、权限、脏数据、超长输入 |
| 标注粒度 | 能结构化就结构化(工具名、chunk_id、关键字),少靠纯开放文本 |
| 规模 | PoC 20~50 条;上线前 100+;按场景分 tag |
| 格式 | JSONL,便于 CI 脚本批量跑 |
起步顺序: 先评「硬指标」(工具选对、Recall@k、拒答)→ 再加 LLM 判分 → 最后人工抽检校准。
常用指标(别乱用 NLP 经典指标)
| 指标 | 适用 | 慎用 |
|---|---|---|
| 任务成功率 / Pass@1 | Agent、工具型任务 | — |
| Recall@k / MRR | RAG 检索 | 生成质量 |
| must_include / 规则断言 | 政策、编号、关键词 | 开放创作 |
| LLM-as-judge | 开放问答排序 | 未校准就上线 |
| 人工 Likert 分 | 最终质量金标准 | 成本高 |
| BLEU / ROUGE | 机器翻译、摘要对照参考答案 | 开放域客服/Agent |
面试可说:业务可验收的用规则+成功率;开放文本用人工抽样+判分模型,别背 BLEU。
非功能维度
| 维度 | 测什么 |
|---|---|
| 成本 | 每请求 token、每用例 eval 账单;smoke 用便宜模型,全量放 nightly |
| 延迟 | TTFT、端到端 P95;检索+重排+多步 Agent 叠加 |
| 稳定性 | 超时、重试、降级、Mock 与真 API 切换 |
| 安全 | 提示注入、越权检索、敏感信息进日志;红队用例集 |
| 回归 | Prompt / 模型 / 索引版本变更后评测集通过率 |
成本评测见 Token 计算与成本 测试与评测成本控制一节。
线上怎么评
| 手段 | 说明 |
|---|---|
| Trace 全量、Eval 抽样 | Langfuse / LangSmith 等存 trace;1%~5% 人工或判分 |
| 用户反馈 | 👍👎、转人工率、重复提问率 |
| A/B | 新 Prompt / 新检索策略对比成功率与成本 |
| 告警 | 拒答率骤降、工具失败率升、单请求 token 异常 |
离线评「能不能发版」;线上评「有没有漂移」——两者都要。
CI 里怎么落地
PR / 提交
├─ 单测:schema、路由、Mock LLM(快、无 API 费)
├─ smoke eval:10~20 条黄金用例 + 便宜模型
└─ nightly:全量评测集 + 真模型 + 成本预算上限
| 实践 | 原因 |
|---|---|
| Mock LLM 测编排 | 单测稳定、不烧钱 |
| eval 与 prod 模型隔离 | 防止 CI 打生产 Key |
| 通过率阈值 gate | 回归 block merge |
| 存历史报告 | 对比哪次 Prompt 改坏了 |
常见坑
| 坑 | 说明 |
|---|---|
| 只评最终答案 | 检索/工具错了不知道 |
| 评测集泄露到训练 | 用公开 benchmark 吹高分无意义 |
| 单次跑就上线 | LLM 有随机性,要看多次或固定 seed |
| 忽略成本 | eval 跑一晚账单爆炸 |
| 无安全用例 | 越权、注入上线后才爆 |
面试参考答法(60~90 秒)
AI 应用我会分三层:组件、端到端、线上。
测试侧用 Mock LLM 保证编排、鉴权、超时、schema 在 CI 里稳定跑。评估侧建 JSONL 评测集:RAG 先评 Recall@k 和拒答;Agent 评任务成功率和轨迹(工具选对、步数、无死循环);对话评 must_include 和人工抽检。
离线全量跑 nightly,控制 eval 成本;上线后 trace 全量、效果抽样,看反馈和转人工率。非功能一起看 token、P95 延迟和安全红队。不用 BLEU 评开放客服,用业务可验收的规则和成功率说话。
延伸阅读
| 篇 | 关系 |
|---|---|
| Agent 系统高频题 | 评测指标速览 |
| 工具调用与评测实践 | Agent 轨迹与离线 eval 代码 |
| [如何优化 RAG 检索效果](/docs/ai/Agent/面试/如何优化 RAG 检索效果) | 检索层指标 |
| FDE 交付闭环实践 | 客户验收与评测集 |
| Token 计算与成本 | eval 成本控制 |
| Agent 安全与权限 | 注入与工具闸门,红队用例从哪来 |
| 可观测与线上评测 | 生产 trace 字段与线上抽样 |
面试速记
- 测试 vs 评估: 测试保能跑、不越权;评估保答对、答稳、答得起。
- 分层: 检索/工具组件 → 端到端成功率 → 线上抽样;别只评最终字符串。
- Agent 三件套: 任务成功率、轨迹质量、事实性(+ 成本延迟)。
- RAG: Recall@k 先行,再评生成与拒答。
- 落地: Mock 单测 + JSONL 离线集 + nightly + 线上 trace/反馈;慎用 BLEU。