Evaluation
没有评测，就无法知道 AI 应用是不是真的变好了。大模型应用的评测要同时关注质量、事实性、稳定性、延迟、成本和安全。
为什么 AI 应用更需要评测
传统软件很多逻辑是确定的，输入相同通常输出相同。AI 应用不同：模型、Prompt、上下文、检索结果、工具调用和参数变化都可能影响输出。
如果没有评测，你会遇到这些问题：
- 改了 Prompt，不知道整体效果是变好还是变差。
- 换了模型，只看少数样例就上线。
- RAG 看起来回答不错，但引用其实不支持结论。
- Agent 最终答对了，但中间越权调用了工具。
- 成本下降了，但质量也悄悄下降。
评测不是最后一步，而是每次迭代的安全网。
评测维度
| 维度 | 说明 |
|---|---|
| Correctness | 答案是否正确 |
| Faithfulness | 是否忠实于给定上下文 |
| Completeness | 是否覆盖用户问题的关键点 |
| Format | 是否符合输出格式 |
| Safety | 是否避免越权、泄密和危险建议 |
| Latency | 响应时间是否可接受 |
| Cost | 单次请求成本是否可控 |
离线评测和在线评测
| 类型 | 适合回答的问题 |
|---|---|
| 离线评测 | 修改前后哪个版本更好 |
| 在线反馈 | 真实用户是否满意 |
| A/B 测试 | 两个方案在真实流量中哪个更有效 |
| 人工抽检 | 高风险或高价值结果是否可信 |
早期项目先做离线评测，因为成本低、可重复。上线后再逐步加入在线反馈和抽检。
最小评测集
建议从 30 到 50 条真实问题开始：
- 20 条常见成功问题
- 10 条边界问题
- 10 条应该拒答的问题
- 10 条历史 bad case
如何收集评测用例
评测集最好来自真实场景：
- 用户实际问过的问题。
- 产品经理和客服整理的高频问题。
- 历史线上事故和 bad case。
- 业务专家认为必须答对的问题。
- 权限、拒答、敏感信息等安全用例。
每条用例都应该有标签，方便按类型分析。例如 pricing、policy、edge、refusal、permission。
评测集应该长什么样
可以用表格或 JSON 保存：
| 字段 | 说明 |
|---|---|
| id | 用例编号 |
| question | 用户问题 |
| expected_behavior | 期望行为 |
| reference_answer | 参考答案 |
| required_sources | 必须引用的资料 |
| tags | 分类，例如 easy、edge、refusal |
不要追求一开始就完美。先把真实用户会问的问题收集起来，比空想 100 条问题更有价值。
示例 JSON：
{
"id": "rag_policy_001",
"question": "入职半年有年假吗？",
"expected_behavior": "基于员工手册回答，并说明不足一年不享有年假",
"reference_answer": "入职满一年后才享有年假。",
"required_sources": ["employee_handbook#vacation"],
"tags": ["policy", "rag", "easy"]
}评测方式
- 规则校验：JSON schema、字段完整性、引用格式
- 人工评分：适合早期和高价值场景
- LLM-as-judge：适合批量对比，但需要抽检
- A/B 测试：适合线上 prompt、模型和检索策略对比
不同任务怎么评测
| 任务 | 重点指标 |
|---|---|
| 分类 | 准确率、混淆矩阵、人工复核率 |
| 信息抽取 | 字段准确率、缺失率、格式合法率 |
| RAG 问答 | 检索命中率、忠实度、引用准确性、拒答准确性 |
| Agent | 工具选择、参数正确性、完成率、越权率 |
| 内容生成 | 可读性、完整性、风格一致性、人工满意度 |
不同任务不要用同一套粗糙分数。评测维度应该服务于业务风险。
项目检查点
- 每次改 prompt 是否跑评测
- 每次换模型是否比较质量和成本
- 是否保留 bad case
- 是否能复现线上问题
- 是否有人工复核入口
LLM-as-judge 注意事项
用模型当裁判很方便，但不能完全相信。
建议做法：
- 给裁判模型清晰评分标准
- 每个维度单独打分
- 要求输出理由
- 抽样人工复核
- 不要让同一个模型既回答又评分
- 对高风险业务保留人工审核
Judge Prompt 示例
你是 AI 应用评测员。请根据用户问题、参考资料和模型回答评分。
评分维度：
- correctness：回答是否正确
- faithfulness：是否只基于参考资料
- completeness：是否覆盖关键点
- format：是否符合要求
请输出 JSON：
{
"correctness": 1-5,
"faithfulness": 1-5,
"completeness": 1-5,
"format": 1-5,
"reason": "简短说明"
}Judge Prompt 要尽量稳定，不要让裁判自由发挥。
一个简单评分标准
| 分数 | 含义 |
|---|---|
| 5 | 完全正确，引用充分，格式符合 |
| 4 | 基本正确，有轻微遗漏 |
| 3 | 部分正确，但影响使用 |
| 2 | 主要结论错误 |
| 1 | 答非所问或严重编造 |
线上反馈闭环
上线后应该记录：
- 用户问题
- 检索到的文档片段
- 模型回答
- 模型和 prompt 版本
- 延迟和成本
- 用户是否点赞、点踩或追问
- 人工标注的失败原因
分析评测结果
不要只看平均分。平均分会掩盖关键问题。建议同时看：
- 哪些标签下降最多。
- 哪些问题从通过变成失败。
- 失败是否集中在某类文档、某个工具、某种输出格式。
- 成本下降是否伴随质量下降。
- 延迟增加是否来自检索、rerank 还是模型输出。
评测的价值不只是给分，而是帮助你定位下一步该改哪里。
实战练习
- 为个人知识库项目准备 30 条评测问题。
- 给每条问题打上 easy、edge、refusal、bad_case 标签。
- 写一个脚本检查 JSON 输出格式是否合法。
- 用人工评分和 LLM-as-judge 分别评测 10 条回答，对比差异。