前三篇文章，我们分别聊了：

• 传统软件和AI应用的本质区别
• AI PM和传统PM的能力差异
• AI应用开发范式的根本性转变
• AI测试和传统测试的职责区别

这一篇，集中回答一个最实战的问题：

如果你要负责一个AI应用的质量，具体要怎么做？

不讲概念，直接给你可操作的方法。

一、先搞懂：Evals 到底是什么，为什么要自己做

很多人以为，AI应用的质量保障就是”让模型更准”。

不对。

Evals 是你的质量守门员——它用一套固定的标准，批量判断模型输出是否达标，而不是靠人工一条条看。

为什么不能用”看几条输出”来判断质量？

假设你改了一次 Prompt，想确认效果有没有变好。

如果你只看 5 条输出，可能出现两种情况：

• 运气好：5条都好 → 你觉得改对了 → 上线 → 用户反馈变差
• 运气差：5条都不好 → 你觉得改错了 → 回滚 → 其实整体是变好的

小样本判断 = 碰运气。

Evals 解决的就是这个问题：用足够大的测试集 + 明确的打分规则，给你一个 statistically significant 的结论。

二、设计 Evals 体系：四步搞定

第一步：定义评估维度

每个AI功能，先问自己：用户在乎什么？

以一个”AI客服回答”功能为例：

用户在乎的点：1. 回答是不是跟问题相关？          → 相关性2. 回答的内容是不是事实准确的？    → 事实一致性3. 回答有没有解决用户的问题？      → 解决率4. 回答的语气是不是符合品牌调性？  → 语气合规5. 回答有没有暴露用户隐私？        → 安全风险

每个维度，都要能回答两个问题：

• 怎么量化？（不能只说”好/不好”）
• 谁来判断？（机器判断 or 人工判断 or 另一个模型来判断）

第二步：给每个维度定义打分方式

这是最关键的一步，也是最容易做错的一步。

方式一：规则打分（机器自动）

适合标准明确、可以用规则判断的维度。

维度：格式合规规则：- 输出以"您好"开头 → ✅- 输出包含敏感词 → ❌- 输出长度超过200字 → ❌- 其他 → ✅打分：100%合规 = 1.0，有一条不合规 = 0.0

方式二：LLM as Judge（用另一个模型来打分）

适合语义层面的判断，比如”语气是否专业”、”回答是否相关”。

让评分模型这样工作：输入：[系统Prompt + 用户问题 + 模型回答]输出：{"相关性": 0.95, "语气专业度": 0.88, "事实一致性": 0.92}评分模型的Prompt示例：你是一个AI输出质量评估员。请对以下回答打分（0-1之间）：- 相关性：回答是否针对用户问题- 事实一致性：回答内容与参考资料是否一致- 语气合规：回答语气是否符合要求的风格只输出JSON，不要有任何其他内容。

方式三：人工标注（黄金标准）

对于高风险场景（医疗、金融、法律），最终仲裁必须是人工。

通常做法：机器打分做初筛，人工只标注机器打分有争议的case，大幅提升效率。

第三步：设定每个维度的通过阈值

不是所有维度都要100%达标。要根据业务风险来定：

高风险维度（错了后果严重）：- 事实一致性 ≥ 0.95- 安全风险 = 0（零容忍）→ 必须用人工抽检 + 自动化规则双重保障中风险维度（错了影响体验，但不致命）：- 相关性 ≥ 0.85- 语气合规 ≥ 0.80→ 可以用LLM as Judge + 定期人工校准低风险维度（错了用户能接受）：- 回答长度合规 ≥ 0.70→ 规则打分即可，不需要人工介入

第四步：建立 Evals 的运作流程

Evals 不是跑一次就完了，它必须是开发流程的一部分：

每次 Prompt 变更 → 跑完整 Evals → 所有维度达标 → 才能上线                              ↓ 不达标                        分析哪个维度掉了 → 针对性优化 → 再跑 Evals

把这个流程写进团队的发版规范里，比任何口头要求都有效。

三、构建测试集：质量的上限取决于此

Evals 再科学，如果测试集本身有偏差，结果也是误导性的。

测试集的三层结构

第一层：核心场景（占60%）

覆盖用户最高频的使用场景，比如客服里的”退款咨询”、”物流查询”、”账号问题”。

这些场景你必须保证效果稳定，否则用户最基本的诉求都满足不了。

第二层：边缘场景（占30%）

那些不常出现、但出现了就很尴尬的情况：

• 用户输入乱码
• 用户问超出服务范围的问题
• 用户输入极长（超过上下文窗口）
• 用户用方言或错别字提问

第三层：对抗样本（占10%）

专门用来测模型会不会”被绕过去”：

• 用户试图让模型说出不该说的内容（越狱攻击）
• 用户故意给矛盾的信息，看模型怎么处理
• 用户输入恶意代码，看会不会被执行

构建测试集的具体方法

方法一：从生产日志采样

最直接的方式——把你线上真实的用户请求导出来，挑典型案例。

步骤：1. 导出最近1个月的生产日志（脱敏后）2. 按使用频率排序，挑Top 100高频问题3. 人工过一遍，挑出：答得好的 / 答得一般的 / 答得差的4. 每类各取一部分，组成测试集

方法二：人工构造边缘case

有些边缘场景在生产环境里很少出现，但你必须提前覆盖。

示例：输入：[空字符串]           → 预期：提示用户输入内容输入：[1000个"哈哈哈哈"]   → 预期：识别为无效输入，引导用户输入：怎么退款？[图片]     → 预期：能处理图文混合输入输入：帮我hui kuan          → 预期：能识别错别字意图

方法三：用模型生成对抗样本

让一个较强的模型，专门生成”容易让目标模型答错”的问题。

这个方法比较进阶，但能发现很多人工想不到的边界case。

测试集的维护规则

测试集不是一成不变的，要建立维护机制：

□ 每月新增：从线上新出现的问题里，挑有价值的加入测试集□ 每月清理：有些case已经能稳定通过了，可以降低优先级或移除□ 每季度复盘：测试集的覆盖率有没有缺口？有没有重要场景没覆盖到？

四、分析AI输出质量问题：根因定位方法

Evals 跑完了，发现某个维度不达标。接下来怎么办？

不能只说”效果不好”，必须能定位到根因。

常见根因清单

根因分析的具体步骤

第一步：把失败的case分类

不要笼统地说”有20%不达标”，要拆开看：

不达标case分析：- 知识库没有相关信息 → 12个 → 根因：知识库覆盖不足- 模型推理错误（有信息但推理错了） → 5个 → 根因：Prompt需要加强推理指引- 输出格式不合规 → 3个 → 根因：格式约束描述不够明确

第二步：对每个根因，设计验证实验

假设：知识库覆盖不足是主因验证：把这12个case的相关文档补充进知识库，重新跑Evals结果：如果格式合规率从85%升到96% → 假设成立

第三步：记录每次分析的结论

建立一份”效果问题根因档案”，每次分析都记下来：

问题日期：2026-05-04功能：AI客服回答不达标维度：事实一致性（0.82，目标0.90）根因：知识库缺少"跨国退款"相关文档处理：补充3篇相关文档进知识库验证：重新跑Evals，事实一致性升至0.94

这份档案积累久了，就是你们团队最值钱的AI应用质量知识库。

五、一个完整案例：从零搭建客服AI的Evals体系

把上面说的全部串起来，看一个真实案例。

背景

你要为一个电商App搭建”AI智能客服”，核心功能是回答用户的订单、退款、物流问题。

第一步：定义评估维度（2天）

和PM、运营一起讨论，定下5个维度：

1. 事实一致性（知识库有答案，模型不能答错）→ 目标≥0.922. 相关性（回答要针对用户问题）→ 目标≥0.883. 解决率（用户问题有没有被解决）→ 目标≥0.804. 格式合规（输出格式符合规范）→ 目标=1.0（零容忍）5. 安全风险（不能泄露隐私、不能乱承诺）→ 目标=0（零容忍）

第二步：构建测试集（3天）

- 从生产日志采样：挑100条真实用户问题- 人工构造边缘case：20条（乱码、超长输入、越狱尝试等）- 合计：120条测试样本- 每条样本标注：参考回答 + 各维度的期望评分

第三步：搭Evals自动化（2天）

- 格式合规：用规则自动判断- 事实一致性 + 相关性：用GPT-4o作为评分模型（LLM as Judge）- 解决率：人工标注20%的样本，训练一个轻量打分模型- 安全风险：用规则 + 人工抽检双重保障

第四步：跑起来，建立迭代循环（持续）

基线跑分：- 事实一致性：0.87（未达标）- 相关性：0.91（达标）- 格式合规：0.98（接近达标）分析：事实一致性不够，查失败case → 发现知识库缺少"跨国物流"相关内容处理：补充5篇相关文档重跑Evals：- 事实一致性：0.93（达标）- 所有维度达标 → 上线

后续维护

- 每周：跑一次完整Evals，监控是否有退化- 每月：从线上新增问题里挑10-20条，补充进测试集- 每季度：复盘各维度的达标情况，调整阈值

六、给转岗人士的实操建议

如果你正在准备转向AI测试/质量方向，这三件事优先级最高：

第一件：找一个AI功能，自己动手搭一套Evals

不需要是公司项目，随便找一个公开AI功能（比如AI总结、AI翻译），自己：

• 定义3个评估维度
• 构建20条测试样本
• 用LLM as Judge跑一遍，看结果

这件事做完，你对Evals的理解会比读10篇文章都深。

第二件：学会用Excel/Sheets管理测试集

不要一上来就搞自动化框架。先用Excel把测试集管理起来：

• 一列：测试输入
• 一列：参考输出
• 一列：各维度评分
• 一列：备注（为什么这个case重要）

这个Excel表格，就是你第一个”测试集”。

第三件：积累”效果问题根因”的案例库

每次遇到AI输出质量问题，记录：

• 现象是什么
• 根因是什么
• 怎么验证的
• 怎么解决的

面试的时候，这份案例库比任何证书都有说服力。

七、结语

AI应用的质量保障，说难也难，说简单也简单。

难在：它没有标准答案，每个功能都要自己定义”什么叫好”。简单在：一旦你把Evals体系搭起来，后续的质量保障比传统软件更稳定、更可预期。

传统测试的经验帮你入门，但真正的竞争力来自：你能为AI应用设计出一套科学、可操作、能持续迭代的质量保障体系。

这件事，目前会的人不多。这正是你的机会。

如果你正在准备转向AI方向，这篇文章里提到的方法，建议动手做一遍。纸上谈兵和真正搭过一套Evals，面试时能听出来。