AI 应用测试的六条必备条件

传统软件的测试通常是确定性的：输入 A，期待输出 B，偏差超过阈值就报错。但 AI 应用（尤其是大语言模型驱动的产品）是概率性的——同一个 prompt 问两次，答案可能完全不同。这给测试带来了全新的挑战。

结合这段时间的实践，我总结了 AI 应用测试的六条必备条件。

1. 可观测性先行

在开始写测试用例之前，先把可观测性搭好。

• 日志：记录每一次模型调用的 prompt、response、延迟、token 消耗
• 追踪：从用户输入 → 检索增强（RAG）→ 模型推理 → 后处理 → 最终输出，每一步都要有 trace
• 仪表盘：实时查看请求量、成功率、P50/P95/P99 延迟、token 消耗趋势

没有可观测性就去测 AI，就像没有仪表盘就去赛车——你根本不知道哪里出了问题。

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ 用户输入  │ → │  RAG 检索 │ → │ LLM 推理 │ → │ 后处理    │ → 输出
└──────────┘    └──────────┘    └──────────┘    └──────────┘
     ↓ trace        ↓ trace        ↓ trace        ↓ trace
    延迟/success   召回率/相关性    tokens/耗时    格式校验/敏感词

2. 用「评测集」替代「测试用例」

传统测试是 pass/fail 的二元判断。AI 测试更像是打分——答案有多好？

你需要准备三套评测集：

评测集	用途	数据来源
核心场景集（~50条）	每次发版前必跑，作为质量门禁	手工精选的真实高频问题
回归集（~200条）	覆盖历史 bad case，防止已修问题复现	线上收集的真实 bad case
对抗集（~50条）	极限、边界、越狱、幻觉诱导	人工构造或红队测试生成

每条测试数据包含：{输入, 期望行为描述, 不可接受的内容}。

3. 评估不能全靠人工

让人类一条条看答案太慢了。建立自动评估 + 人工抽检的双层体系：

• 规则层（快，100% 覆盖）：格式校验、长度范围、关键词检测、敏感词扫描、引用来源是否真实
• 模型层（AI 评估 AI）：用 GPT-4 或 Claude 对答案打分（准确性、完整性、安全性、语调），打分逻辑要写清 rubrics
• 人工层（准，抽样 5%）：每周抽查，重点看自动评估得分边缘的案例

全量自动评估（规则+模型打分）→ 得分低于阈值 → 标记人工复审
                              → 得分高于阈值 → 抽样 5% 人工确认

4. 非确定性场景用「多次采样 + 统计」来判断

同一个 prompt，跑 N 次（建议 N≥10），统计：

• 通过率：N 次中有多少次满足期望？低于 80% 视为不通过
• 一致性：答案的核心结论是否稳定？用聚类算法或语义相似度来衡量
• 最差情况：N 次中最差的一条是否仍可接受？最差情况也必须过安全底线

# 伪代码：非确定性评估
results = [call_llm(prompt) for _ in range(10)]
pass_rate = sum(1 for r in results if evaluate(r).passes) / 10
consistency = semantic_similarity_matrix(results).mean()
assert pass_rate >= 0.8, f"通过率不足: {pass_rate}"
assert consistency >= 0.7, f"一致性不足: {consistency}"

5. 安全与护栏是硬性底线

AI 产品的安全测试不能用「尽量做好」来糊弄，必须是硬性阻断：

• PII 泄露：输出中绝对不能出现真实的手机号、身份证、银行卡号（用正则 + NER 模型双重检测）
• 越狱攻击：测试集应包含已知的 jailbreak prompt 模板（DAN、角色扮演、编码注入等）
• 角色偏离：客服 bot 不能说「作为 AI 我建议你辞职」——用第二层 classifier 模型判定输出是否越界
• 提示注入：用户输入中包含「忽略之前的指令」时，系统行为是否被篡改

安全不是 features，是 gate。一条安全问题，可以否定所有功能测试的通过。

6. 线上监控闭环

测试环境通过 ≠ 线上没问题。必须建立持续监控 → 发现 → 回灌的闭环：

1. 实时异常检测：延迟突增、空回复率飙升、token 消耗异常 → 自动告警
2. 用户反馈收集：点赞/点踩、举报、主动评分，把差评 case 自动入库
3. 定期回灌：每周把线上新发现的 bad case 加入回归评测集，确保修复后不再犯
4. A/B 对比：prompt 调优、模型切换、RAG 策略变更 → 先用 A/B 实验在 5% 流量上验证

小结

条件	一句话
可观测性	没日志就没测试
评测集	用打分代替 pass/fail
自动评估	规则 + AI 评分 + 人工抽检
多次采样	对非确定性结果用统计判断
安全护栏	硬性阻断，不是软性建议
线上闭环	regress → 入库 → 复测，永动循环

AI 应用测试不会一蹴而就，它是一个持续演进的系统工程。但把以上六条做到位，你的 AI 产品就有了基本的安全感和质量底线。