AI testing 到底在测什么?从 trace、eval 到上线前回归的完整思路

更新时间

AI testing 测的不是"代码有没有 bug"，而是模型在真实输入下的输出质量是否稳定、是否在预期范围内。它由三件事组成：用 trace 记录每次调用实际发生了什么，用 eval 把"好"变成可重复打分的标准，用回归门禁在发布前拦住质量下降。适用条件是：你的应用依赖 LLM 或 agent，输出是概率性的、会随 prompt、模型版本、数据分布变化而漂移——这类系统用传统单元测试覆盖不了。

为什么传统软件测试不够用

传统测试的假设是：同样的输入应该得到同样的输出，断言通过就是正确。AI 应用打破了这个假设。

  • 失败是概率性的：同一个 prompt 可能 90% 的情况答得好，10% 的情况编造事实。一次通过不代表稳定。
  • 会静默漂移和回归：Braintrust 的描述里点得很直白——"AI drifts and regresses silently"（AI 会静默地漂移和回归）。改了 prompt、换了模型版本、上游数据变了，质量可能悄悄下降，但没有任何报错。
  • "正确"本身需要定义：一段摘要、一次工具调用、一轮多步 agent 推理，没有唯一的正确答案，只有"是否符合预期"。

所以 AI testing 的核心不是断言，而是可观测性 + 可重复的质量衡量 + 发布前的拦截。

trace：先看清生产里到底发生了什么

trace 是 AI testing 的原始证据。它记录一次请求的完整链路：prompt、模型返回、工具调用（tool calls）、耗时、成本。Braintrust 把它描述为"实时检查 agent trace 和工具调用，跨百万级日志搜索，实时追踪延迟、成本和质量的"能力。

为什么 trace 是起点：

  • 你无法测试你没看到的东西。生产里用户实际怎么问、agent 实际调了哪些工具、在哪一步跑偏，只有 trace 能还原。
  • trace 是排查和构造测试用例的原料。一个反复出现的问题，从 trace 里被识别出来后，才能变成一条可复现的 eval 用例。

具体动作：接入 trace 后，先跑通"记录第一条 trace"，确认 prompt、response、tool call 三类信息都能被看到，再谈打分和回归。

eval：把"好"变成可重复的分数

eval（评估）解决的是"怎么判断输出好不好"。Braintrust 给出的打分方式有三类，可以按场景选：

打分方式 适合什么 代价
LLM 打分 主观质量、语义正确性、开放式输出 需要设计评分 prompt，本身要校准
代码打分 有确定规则的检查（格式、关键词、数值、工具调用是否正确） 便宜、稳定，但覆盖不了模糊质量
人工打分 高风险、需要专业判断、校准自动打分器 慢、贵，通常用于抽样和校准

关键机制：eval 不是跑一次就完事，而是在版本化的数据集上反复跑。Braintrust 强调"用真实数据集做实验，并排比较 prompt 和模型"。也就是说，你改一版 prompt，应该能在同一批数据上看到分数变化，而不是凭感觉说"好像更好了"。

验证方法：同一数据集、同一打分器，改 prompt 前后各跑一次，对比分数。分数没变或变差，说明改动没带来收益。

数据集与实验：让改动可比较

没有固定数据集，eval 分数就没有可比性。数据集应该来自真实场景——从生产 trace 里挑出有代表性的输入，包括正常案例和已知的失败案例。

  • 版本化：数据集本身要能追踪版本，否则"上次 85 分"和"这次 85 分"可能根本不是同一套题。
  • 并排比较：同一批数据上跑不同 prompt、不同模型，看哪个更符合预期。
  • 覆盖失败案例：只测简单样本会高估质量。把生产里发现的问题样本加进数据集，才能防止同类问题复发。

上线前回归门禁：在用户发现之前拦住

这是 AI testing 和"事后监控"的分界。Braintrust 的描述是"在进入生产前拦截坏发布"（Block bad releases before they hit production）。

机制是：把 eval 挂到发布流程上，设定质量阈值。新版本在数据集上跑分，低于阈值就不放行。这样质量下降在发布前被拦住，而不是等用户投诉。

常见卡点：

  • 阈值定得太松，拦不住回归；定得太严，正常波动也被拦。需要先用历史版本跑出分数分布，再定线。
  • 数据集不更新，门禁会逐渐失效——生产里出现的新问题类型没进数据集，就测不出来。

从生产 trace 回到测试：闭环怎么转

完整的循环是：

  1. 观测：trace 记录生产里 agent 的真实行为。
  2. 发现模式：从大量 trace 里识别反复出现的问题或机会（Braintrust 的 Patterns 自动化就是做这件事——"识别生产 trace 中反复出现的问题和机会"）。
  3. 验证证据：确认这个模式是真的问题，不是噪声。
  4. 转成 eval：把这个问题做成一条可复现的测试用例，加进数据集。
  5. 测改进：改 prompt 或模型，在数据集上验证分数提升。
  6. 发布并回归：通过门禁后发布，继续用 trace 观测。

这个闭环的意义在于：测试用例不是拍脑袋想出来的，而是从真实失败里长出来的。每修一个问题，测试集就更贴近真实风险一分。

怎么判断自己该从哪一步开始

  • 还没接入 trace：先做可观测性，否则后面都是盲测。
  • 有 trace 但没有 eval：从最高频或最严重的失败场景开始，先做几条代码打分或 LLM 打分，跑起来比做全更重要。
  • 有 eval 但没门禁：把 eval 接到发布流程，设一个基于历史分数的阈值。
  • 已经在跑但质量还在漂：检查数据集是否覆盖了生产里的新问题类型，以及打分器是否需要重新校准。

一句话总结：AI testing 测的是输出质量在真实输入下的稳定性，靠 trace 提供证据、eval 提供标准、回归门禁提供拦截，三者缺一不可。