LLM testing 到底在测什么?从 trace、eval 到上线前回归的完整思路
LLM testing 测的不是一段确定的代码逻辑,而是 prompt、模型输出、工具调用和 agent 多步流程在真实输入下的行为是否符合预期。它和 LLM evaluation、observability 是三件不同的事:observability 负责"看到生产里实际发生了什么",evaluation 负责"定义并量化什么算好",testing 则是把这两者串起来——用 trace 发现的问题转成测试用例,用 eval 打分,在上线前跑回归拦截退化。如果你刚上线一个 LLM 应用、发现它"偶尔变差但说不清哪里差",这套流程就是为你准备的。
三个概念别混:observability、evaluation、testing 各管什么
| 环节 | 回答的问题 | 典型动作 |
|---|---|---|
| Observability | 生产里实际发生了什么? | 检查每条 agent trace、工具调用,搜索日志,跟踪延迟/成本/质量 |
| Evaluation | 什么算"好"?怎么量化? | 用 LLM、代码或人工给输出打分,在数据集上跑实验 |
| Testing | 改动后有没有变差? | 用版本化数据集对比 prompt/模型,上线前拦截退化 |
Braintrust 把这三者放在一个平台里,它的定位是"agent 的主动式可观测平台"(active observability platform),核心逻辑是:agent 的失败方式和普通软件不同,AI 会静默地漂移和退化,所以需要主动把生产中的模式自动浮现出来,再拿这些模式去评估、迭代。
测试对象:不止是"模型答得对不对"
LLM 应用的失败点分散在多个层次,测试要覆盖:
- prompt:改动措辞、加 few-shot 后行为是否还稳定
- 模型输出:内容质量、格式、是否幻觉
- 工具调用:agent 是否在正确的时机调用了正确的工具、参数对不对
- 多步 agent 流程:整条链路走下来是否达成目标,而不只是单步正确
普通软件的 bug 是确定性的,LLM 的退化往往是概率性的、静默的——同一个 prompt 今天和下周表现可能不同。这就是为什么单靠单元测试不够,需要 trace + eval 的组合。
第一步:用 trace 看真实行为
trace 记录的是生产里实际发生的事:prompt、response、工具调用,以及延迟、成本、质量指标。Braintrust 的描述里,observability 部分强调可以"检查每条 agent trace 和工具调用,跨百万级日志搜索,实时跟踪延迟、成本和质量的"。
为什么从 trace 开始:你无法测试你观察不到的行为。先让 trace 跑起来(资料里对应"Log your first trace"),才能知道用户实际怎么用、agent 在哪里出错。
预期结果:你能看到具体某次失败的完整链路——输入是什么、模型返回什么、调了哪个工具、耗时多少。
第二步:把发现的模式转成 eval
Braintrust 的 Discovery 环节描述了一个闭环:对 trace 应用智能分析,识别重要行为,验证证据,测试改进,再衡量结果。其中 Patterns 是一种自动化机制,能跨生产 trace 识别反复出现的问题和机会。
动作:从 trace 里找出反复出现的失败模式(比如某类问题总是答错、某个工具总是被误调),把它变成一条可复现的测试用例,放进数据集。
打分方式有三种,Braintrust 的 evals 部分明确列出:
- LLM 评分:用另一个模型给输出打分,适合主观质量
- 代码断言:用确定性规则检查,适合格式、字段、精确匹配
- 人工标注:人工判断,适合高价值或边界模糊的样本
验证方法:同一批数据集上跑改动前后的版本,看分数是否真的提升,而不是凭感觉。
第三步:上线前回归,拦截退化
这是 testing 区别于单纯 evaluation 的关键——版本化数据集 + 对比实验。Braintrust 的 evals 描述里提到"针对真实数据集跑实验,并排对比 prompt 和模型"。
具体做法:
- 把数据集版本化(资料里对应"Flexible, versioned datasets"),这样每次对比都基于同一批样本
- 改动 prompt 或换模型后,在数据集上重跑
- 并排对比结果,确认没有引入新的失败
- 在发布前拦截坏版本(资料里对应"Block bad releases before they hit production")
常见卡点:数据集不固定,导致每次对比的基准不同,分数变化无法归因。所以版本化是前提,不是可选项。
最小可行流程:从第一次 trace 和第一个 eval 开始
不需要一次搭全。按这个顺序:
- 接入 trace:让生产请求被记录下来,先能看到真实行为
- 挑一个失败案例:从 trace 里找一条明显出错的,手动复现
- 建第一个 eval:把这条案例放进数据集,选一种打分方式(代码断言最快)
- 跑一次对比:改一版 prompt,在数据集上对比新旧分数
- 扩展:用 Patterns 这类自动化发现更多反复出现的问题,逐步扩充数据集
Braintrust 还提供了一个 eval maturity assessment(评估成熟度自测),可以用来判断自己团队处在哪个阶段、下一步该补什么。资料里也提到 Loop——一个帮助改进 agent 的 AI,可以描述你想优化的目标,自动生成更好的 prompt、scorer 和数据集,适合在流程跑通后加速迭代。
什么时候需要这套流程
- 你的 LLM 应用已经上线,但质量波动说不清原因
- 你准备改 prompt 或换模型,担心引入退化
- 你的 agent 有多个工具调用步骤,单步测试覆盖不到整体行为
如果还在原型阶段、没有真实用户输入,可以先从构造数据集和基础 eval 入手,但 trace 的价值要等有生产流量后才充分体现。