OpenAI工程师花3周搭监控，改个提示词就抓瞎了

87%的LLM团队有完整的可观测性仪表盘，却只有不到12%能把生产数据变成回归测试。这是2024年LangChain用户调研里最扎眼的一组数字。

你花了三周把链路追踪接进Jaeger，指标塞进Grafana，告警怼进Slack。模型说什么、耗多久、花多少钱，一目了然。然后你改了提示词。模型变好了还是变糟了？哪些输入会翻车？你不知道。你的追踪是只写的——能看，但从不评估。

生产数据躺在Jaeger里，从没变成测试用例。这是「toad-eye」团队在自己身上发现的坑。他们造了座桥，把链路追踪导出成测试集，结果跑第一遍就傻眼：一半span是空的，因为recordContent默认关闭。工具 designed to 提取测试数据，啥也提不出来。

「看起来正常」是最贵的幻觉

每个LLM团队都走过这个流程：部署提示词v2，盯几小时仪表盘，「延迟差不多，没报错」，下一项。这不是评估，是体检。你在查系统健康——延迟、错误、成本——但不管输出质量。模型可能正在返回微妙变差的答案，你永远发现不了，因为没有基于真实流量的回归测试。

做得好的团队有另一套循环：收集生产输入输出→从真实流量提取测试用例→新提示词跑一遍→打分：v2比v1好吗？→放心部署。

步骤2到4是评估框架干的活。问题卡在步骤1到2。你的追踪在Jaeger，评估框架要YAML数据集。没人造这座桥。

一条CLI命令把Jaeger链路转成测试集：

npx toad-eye export-trace abc123def456

输出很直白：✅ Exported trace abc123def456 → ./trace-abc123de.eval.yaml

生成的YAML长这样：name、source、metadata（trace_id、时间戳、模型、供应商），然后是cases数组。每个case有id、variables.input、assertions。断言是自动生成的——基于生产模型实际返回的内容。

保守基线：抓退化，不抓优化

导出不只是复制输入输出。它分析生产响应，创建基线断言：max_length按实际长度+20%缓冲，not_contains筛掉生产里没出现的拒绝话术，is_json标记结构化输出。这些是保守基线——能抓住「突然开始拒绝回答」或「JSON格式崩了」，但不会替你优化。

保守是设计选择。自动化断言的目标是防止未知退化，而非定义「好」的标准。后者需要人工判断。

工具开源在GitHub，但文档里埋了个细节：默认只导出最近24小时的追踪。不是技术限制，是刻意为之。旧追踪的模型版本、提示词版本、甚至API行为都可能不同，混进测试集会污染基线。24小时窗口强制你用「足够新鲜」的生产数据。

从「能看」到「能测」的距离

链路追踪和评估框架的割裂是个老问题。Jaeger 2017年开源，OpenTelemetry 2019年成为CNCF项目，LLM评估框架（如EleutherAI的LM Eval Harness）2022年后才爆发。两个生态各自生长，接口从未对齐。

toad-eye的解法很产品经理：不造新系统，做格式转换器。Jaeger的JSON追踪→YAML测试集，中间塞一层断言生成器。技术债最小，迁移成本最低。

他们在自己代码库跑了一遍：47%的导出尝试失败，因为recordContent没开。修完配置后，23%的追踪包含多轮对话，需要人工拆分成独立测试用例。最后只有31%能直接进CI流水线——但比0%强。

这个数字没写在README里，是团队工程师「max」在Discord频道随口提到的。他说得轻描淡写：「我们以为开箱即用，结果发现是配置考古。」

配置考古——这个词挺准。LLM基础设施的默认设置往往为「别泄露敏感数据」优化，而非「方便后续分析」。recordContent关闭是合规选择，但把可观测性变成了只写存储。你得主动打开开关，才能从「能看」走到「能测」。

toad-eye的导出命令支持--assertion-strategy参数，可选conservative、strict、minimal三种模式。conservative就是前面说的+20%缓冲；strict要求输出完全一致，适合确定性任务；minimal只检查HTTP 200。没有「smart」模式——团队试过用LLM自己评估输出质量，延迟和成本都扛不住。

这也是个务实的边界。评估评估者（evaluating the evaluator）是另一个深渊，他们选择先不跳。

工具发布两周，GitHub star数刚过600。Issues里有条来自某电商LLM团队的反馈：他们用这套流程抓了三次提示词退化，其中一次是「模型突然开始在价格回答后加免责声明」——仪表盘完全没报警，因为延迟和错误率都没变。