OpenAI用户花3周搭监控，改完提示词才发现数据全白存

你的大模型应用跑了3周，Jaeger（分布式追踪系统）里堆了上万条调用记录，Grafana（数据可视化平台）仪表盘亮着绿灯，Slack群安静得像深夜的机房。然后你改了提示词——v2上线，没人知道答案是变好了还是更糟了。

这不是监控失效，是监控只完成了一半。

原文作者团队踩过这个坑：他们用自家工具导出生产数据准备做回归测试，结果50%的span（追踪单元）是空的——因为recordContent默认关闭。设计用来提取测试数据的工具，连数据都读不到。修完这个bug，他们才意识到更深层的问题：整个行业都在"写只读"地处理LLM追踪数据。

监控仪表盘是安慰剂

几乎每个LLM团队的部署流程都一样：推v2，盯几小时仪表盘，延迟差不多，没报错，收工。作者管这叫"看起来没事"式评估——你检查的是系统健康，不是输出质量。模型可能在返回更差的答案，只是差得不够明显，不会触发告警。

真正有效的团队有另一套循环：收集生产输入输出→从中提取测试用例→新提示词跑旧数据→打分对比→有信心地部署。步骤2到4是评估框架做的事，但步骤1到2之间缺一座桥。

你的追踪存在Jaeger，评估框架要YAML数据集。没人建这座桥，所以生产数据永远躺在那里，变不成测试。

一条命令把追踪变成测试集

作者团队做的工具叫toad-eye，核心就一条CLI命令：

npx toad-eye export-trace abc123def456

输出直接是评估框架能读的YAML。一条追踪里多个LLM调用，每个变成一个测试用例。断言不是凭空写的，是分析生产响应自动生成的——长度上限、JSON格式检查、禁用词过滤，都是基于模型实际返回的内容。

这些基线是保守的：它们能抓回归，抓不了改进。但"没变坏"已经是v2上线的最低门槛，而大多数团队连这个都没做到。

为什么我们默认关掉内容记录

那个50%空span的bug很有意思。recordContent默认关闭，可能是出于成本或隐私考虑，但结果就是：你想做评估的时候，发现数据仓库是空的。

这像买了保险箱却忘了放东西进去。更讽刺的是，团队花了3周搭observability（可观测性）体系，最后能回答的只有一个问题："服务有没有挂？"至于"模型有没有变笨"，仪表盘沉默如谜。

作者的原话很扎心："You observe but never evaluate." 你观测，但从不评估。生产数据是写只读的。

现在他们每天导出生产追踪，自动转成回归测试。v2上线前跑一遍，数字说话。这流程不性感，但解决了那个最基础的焦虑：改完提示词，我怎么知道没搞砸？

你的团队是怎么处理这个问题的——有把追踪数据真正用起来，还是也在"写只读"地存着？