近两年,“AI 测试工程师” 这个词越来越常见,但很多测试人员一接触大模型应用,就会有一种明显的不适应:
以前测试的是一个相对确定的系统。按钮点击后会跳转到哪里,接口返回什么字段,输入某个值会出现什么结果,理论上都可以提前定义清楚。
但到了大模型应用这里,情况变了。
同一个问题,模型这次可能回答得很好,下次却可能答偏;改了一句 Prompt,效果可能提升,也可能让原本正常的场景退化;系统明明没有报错,页面也没有异常,可用户就是觉得 “不好用”。
这说明,AI 时代的测试重点,已经不再只是 “功能是否正常”,而是 “输出是否可靠”。这也是 LLM 评估这类文章真正想解决的问题。

一、为什么传统测试方法到了大模型这里不够用了

传统软件测试的核心,是验证系统行为是否符合预期。

核心验证内容

二、测试对象变了:从 “功能正确” 变成 “输出质量”

LLM 评估的本质是:系统性衡量一个 AI 应用输出质量的过程。
过去:验证 “有没有错”,现在:验证 “是不是好”。

输出质量的核心维度

三、只靠传统断言,已经测不准大模型应用了

常见误区:继续写自动化断言就能完成 AI 测试。
答案是: 可以,但只能覆盖一部分。

1. 代码式评估:AI 时代的 “传统自动化测试”

适用于确定性强的输出:

四、为什么现在会出现 “用 LLM 来评估 LLM”

核心方法:LLM-as-a-Judge
让另一个模型评估当前模型输出:

五、测试数据集,会成为 AI 测试最核心的资产之一

传统测试强调测试用例设计,到了大模型测试阶段,更重要。
Eval Dataset ≈ 大模型应用的测试用例库
好的评估集应覆盖:

六、Prompt、模型、RAG 变更,本质上都应该跑回归测试

常见误区:

七、AI 应用上线后,监控的不只是 “有没有报错”

传统线上监控指标:

八、测试人员如何理解 “AI 测试工程师” 的能力升级

未来测试人员不仅验证功能,还要参与定义和保障 AI 输出质量。

能力升级方向

  1. 从功能验证,升级到质量评估:关注回答相关性、正确性、稳定性、安全性
  2. 从脚本编写,升级到评估设计:会设计评估维度、标准和数据集
  3. 从确定性断言,升级到混合评估:规则断言 + LLM Judge + 人工复核
  4. 从测试执行,升级到持续回归:Prompt、模型、RAG 变更纳入流水线
  5. 从线下验证,升级到线上质量治理:关注生产环境中的幻觉、不安全内容、任务退化

本文主要内容源自 “What is LLM Evaluation?“一文, 文章链接: https://arize.com/llm-evaluation/?utm_source=chatgpt.com


↙↙↙阅读原文可查看相关链接,并与作者交流