![]()
你的大模型应用跑了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上线前跑一遍,数字说话。这流程不性感,但解决了那个最基础的焦虑:改完提示词,我怎么知道没搞砸?
你的团队是怎么处理这个问题的——有把追踪数据真正用起来,还是也在"写只读"地存着?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.