1. 打不通Telemetry和Evaluation回归测试就是在刻舟求剑1.1 为什么跑没跑过不等于该测的都测了做LLM应用的人应该都有同感这一类系统的回归测试是所有测试里最让人心里没底的。传统后端测试好歹有个明确的状态机、数据库字段、接口返回值可以断言但LLM应用的核心行为是一段输入得到一段输出输出本身是概率性的。你今天把v1.2版本的Agent跑一遍测试集所有case都过了不代表上线后用户遇到真实场景它还能过。更麻烦的是很多团队压根没有真实场景的测试集测试用例是产品经理凭感觉写的或者是开发从用户反馈里挑了几十条手工抄出来的和线上真实流量之间的gap非常大。我见过不少团队做LLM应用回归评估的方式维护一个几百条的Golden Set每次发版前跑一遍算个平均分分没掉就认为安全。听起来合理但这个Golden Set从哪儿来的大多数是三个人攒出来的覆盖的是他们想象中的用户问题而不是实际发生的用户问题。于是出现一个很魔幻的现象离线评估分数一路稳中有升线上用户体感却在下降。原因很简单——评估集和真实分布的偏差越来越大你在评估一个已经和现实脱节的模拟考题考得再好也不代表上路不出事。这就是标题里从运行事实到回归证据这句话想解决的问题。运行事实Runtime Facts指的是系统在生产环境里真实发生的调用轨迹、输入输出、异常事件它们是已经发生过的事实回归证据Regression Evidence则是用来判断这次改动是否让系统退步的证据集。这两者之间如果能打通回归测试就不再依赖拍脑袋攒数据而是从线上真实运行中持续提取、沉淀、更新评测样本。1.2 遥测数据里藏着被浪费的运行事实Telemetry这个词听起来像是运维那边的事——链路追踪、指标采集、日志聚合和测试团队有什么关系很多团队的现状是遥测数据归可观测性平台管测试数据归质量平台管两拨人各看各的看板老死不相往来。但如果你真去翻一遍生产环境的Trace数据会发现里面就是一座没开采的金矿。每一次真实的用户请求都自带完整的输入上下文、模型调用链、工具调用参数、中间结果、最终输出、耗时、Token消耗甚至用户后续的反馈信号点赞、点踩、重新生成、复制粘贴。这些数据比你手工造的任何测试样本都真实、都新鲜、都有代表性。问题在于大多数人把这些数据当日志看待——出故障了捞出来看看排查完就归档。很少有人把它当作可以自动生成评估用例的语料库来设计。Workrun这个项目最开始也就是个内部工具目标很朴素把这两个原本分离的东西接起来让每一次线上真实运行都能自动沉淀成下一次回归评估的证据。做到后来我们才发现这件事的价值远不止省了写用例的时间它实际上改变了整个团队的发布节奏和评估方法论。1.3 Workrun的定位与设计前提先说清楚Workrun到底是什么。它不是一个大而全的可观测性平台也不是一个通用的LLM评测框架它更像是一层翻译层一边接入生产环境的Telemetry数据另一边对接你现有的Evaluation流程无论你是用简单的规则校验还是用LLM-as-Judge或者是更复杂的Agent评估沙箱把两者之间的数据管道和语义映射做得足够可靠。我们做Workrun之前团队里的评估系统其实已经跑了两三个月但一直有个尴尬的处境评估报告写得再漂亮研发团队不太当回事。因为大家心里清楚评测集里那些case的来路不够硬。一旦用户线上反馈一个问题你回溯到对应Trace发现这个场景离线评估集里根本没有你就没法证明这个改动不会让类似的场景变差。这就是运行事实和回归证据之间断裂造成的信任塌方。Workrun的设计前提有三个第一生产环境的Telemetry必须足够结构化不能只是散落的日志文本第二从Trace到评估用例的转换必须尽量自动化人工只做审核和抽样确认第三评估结果必须能追溯到原始运行事实任何时候都能回答这条评估样本是哪个用户请求演化来的。这三个前提确立之后后面所有的工作都围绕它们展开。2. 采集层的取舍Telemetry怎么采才能不变成噪音2.1 全量采样还是自适应采样第一个要拍板的事就是采多少。很多人第一反应是全量采集反正存储便宜。但真正面对LLM应用的生产流量时全量采集是个灾难。一个Agent请求可能涉及十几轮LLM调用、几十个工具调用单个Trace的payload轻松上几十KB。用户量一起来每天几个TB的数据量传输、存储、检索的成本会让整个项目在第一天就被预算部门掐死。我们用的是自适应采样策略默认只对健康流量做10%的采样对异常流量做100%采样对慢请求和重试请求做100%采样。这个比例不是拍脑袋定的而是通过成本估算倒推的——先看单Trace的平均大小再乘预估日请求量算出每天最多能扛多少存储增量然后反推采样率。以我们当时的量级10%的采样率已经能保证每周攒下足够的有效样本。注意采样率不能全局固定。用户体量、流量分布、评估集缺口情况都是在变的。Workrun里我们把采样策略做成了动态配置每个服务可以单独设置阈值。最核心的一个判断是当前评估集中该类场景的覆盖度是否足够覆盖度低的路由自动提升采样率覆盖度饱和的路由可以降到更低比例。2.2 事件结构化的三个字段设计原则遥测数据如果只是按原样塞进ClickHouse或者ES里后面做评估用例生成的时候会非常痛苦。因为评估需要的是这一段对话的完整上下文而不是一串JSON Log。我们在事件结构化的阶段定死了一个规范不管是什么类型的事件LLM调用、工具调用、用户消息、系统异常统一吐成Event对象至少包含三个字段——trace_id、span_id、parent_span_id再加上一个event_type。这三个字段是链路重建的地基。有了它们任意一条事件都能被还原成一条树状的调用轨迹。第二个原则是所有高维信息比如模型返回的完整消息、工具返回的JSON统一存储为Payload字段但索引只给低维的元数据时间戳、模型名、耗时、是否异常、用户反馈标签。这样可以避免把高大上的Payload丢进倒排索引导致存储膨胀同时又能保证检索阶段快速过滤。第三个原则是事件必须携带业务语义标签。比如某个事件是用户最终采纳了答案还是用户反馈不满意这些标签在原始Trace里通常不会自动出现需要我们主动从业务系统引入。Workrun的做法是提供了一个轻量级SDK业务方在关键节点手工打一个semantic_tag成本极低但后续做评测样本筛选时几乎是命脉级的字段。2.3 从分散事件到完整轨迹的链路重建事件采集进来之后还有一步脏活链路重建。分布式系统里一个用户请求会串起多个服务每个服务都往Trace系统里写自己那一段。如果只是把同一trace_id的数据拼在一起大概率是乱序、缺段、相互嵌套的。Workrun里维护了一个轻量的轨迹重建器逻辑不复杂按照parent_span_id把事件构建成一棵时间树然后做一次拓扑排序把同一层级的事件按时间先后排列。这一步的坑在于很多服务并没有严格按照OpenTelemetry的规范去传parent_span_id尤其是老服务或第三方服务。我们实际的解法是对缺失父节点的子Span做一次就近匹配——根据时间窗口和调用链顺序把孤儿Span挂到最可能的父Span下面同时打上一个reconstructed: true的标记。这类重建出来的轨迹在生成评测样本时要额外小心因为它的上下文顺序可能不完整我们会降低它的优先级或者只截取其中信息量最大的一小段作为评测片段。链路重建质量的验收标准很简单抽样几十条轨迹人工确认这棵树能不能讲出一个完整的故事。如果一段轨迹连用户问什么、系统经历了什么、最终返回什么都说不清楚它就不具备成为评估证据的资格。3. 转换核心把运行轨迹加工成回归证据3.1 切分评测单元的标准不是每条Trace都能直接变成评测样本。一条用户请求里可能有十几个来回的对话其中大部分是低价值的中间试探。如果整条Trace直接塞进评测集模型评估时会被超长上下文带偏而且最终的得分也没法定位到具体哪个环节出了问题。我们定义了一个评测单元Evaluation Unit的概念它是回归评估的最小数据单位。Workrun切分评测单元的标准有三条第一必须包含一个完整的用户意图-系统响应闭环也就是至少一轮用户输入和对应的最终输出第二上下文长度不能超过评测模型的处理上限超长的轨迹按轮次截断保留最核心的意图段第三必须能定位到具体的业务功能模块这样回归失败时可以直接指认是哪个Agent、哪个Prompt链路的退化。这三条标准听起来简单实际执行时最困难的是第一条。因为用户意图不一定在一句话里表达完经常是我先问A再追问B最后才说出真实目的C。我们把这类多轮轨迹做了一次意图聚簇通过语义相似度把同一话题下的连续轮次合并为一个评测单元换句话说我们切分的不只是每一轮对话而是一段完整的话题会话。这个操作大大提升了后续评估的语义完整性。3.2 清洗、脱敏与标注的三步走从生产环境捞出来的原始Trace不能直接进评测集至少有三道工序是绕不开的。清洗这步主要处理两类问题。一类是明显异常的输入输出比如超长乱码、空响应、测试账号的假数据、内部压测产生的流量——这些样本不仅是噪音还会污染评估集的统计分布。另一类是脱敏LLM应用里用户输入经常携带个人隐私信息。Workrun会先跑一轮PII检测对邮箱、手机号、身份证号、地址做确定性脱敏同时保留语义占位符。这一步如果没做扎实评测集本身就有合规风险千万别省。标注这步是决定评估集质量的胜负手。我们一开始尝试过纯自动标注——让一个大模型给所有样本打标签速度快但质量参差不齐。后来改成弱监督人工抽查的方式先用规则LLM自动打标签内容包括业务领域、意图类型、难度等级然后按5%的比例随机抽样人工复核复核通过率低于85%的批次自动退回重新标注。测过几次之后95%以上的样本都能在这种工作流下达到可用的标签质量。这里有个容易被忽略的细节脱敏和标注的顺序必须先脱敏再标注。如果先让标注模型看了原始文本哪怕最后输出的是脱敏后的样本模型也可能把原始信息泄漏进系统记忆里这在自托管模型上尤其需要注意。3.3 自动扩写一个真实交互变出一组评测样本那些直接把生产Trace原封不动塞进评测集的做法只能说能用但远远不够高效。一个真实用户交互往往只覆盖了一个场景的一个侧面我们需要的是同一场景下的多个变体这样回归评估才不容易被单一输入形态钻空子。Workrun里做了一个样本扩写器给定一条真实的评测单元模型会基于原样本的意图和上下文生成3~5条语义等价的变体样本。举例来说真实用户问的是帮我总结一下这份合同里的违约责任条款扩写器会生成这份合同违约了怎么处理把违约责任部分提炼给我看乙方违约要承担什么后果等不同表述。这些变体在生产上是等价的但在输入分布上覆盖了不同的措辞模式。扩写不是无中生有我们给扩写器设了几个硬约束不能改变原始意图、不能引入原始样本中不存在的实体信息、生成的变体必须通过一轮双向语义一致性校验——用另一个模型判断变体能否还原回原样本的意图。双向一致率达到90%以上才入库。这样既保证了样本的多样性又防止扩写跑偏成主题联想。4. Evaluation Agent如何嵌入Workrun的评估闭环4.1 评估智能体解决的问题评估集准备好了接下来是评什么、怎么评、谁来评。我记得最初团队做评估的方式就是写一堆独立脚本对每个评测样本调用一次模型然后把输出丢给GPT-4判断好还是不好。很快我们就发现这种做法撑不住规模了。第一评估标准散落在各处。有的场景用回答是否准确有的场景用是否遵循系统指令有的场景看工具调用参数是否正确如果每个评估项都写一段独立的评判逻辑维护成本呈指数上升。第二单个评估任务往往需要多步推断。比如判断Agent是否在用户要求拒绝时仍然强制完成了操作这不能只看最后一轮输出要看上下文里的用户明确拒绝信号、工具调用链里是否出现了违规操作。这种多步Evaluator用一次Prompt打分根本做不好。所以Workrun把评估环节从一个打分函数升级成了Evaluation Agent——一个有目标、有工具、有记忆的评估智能体。它拿到一条评测样本后不是直接输出分数而是先拆解评估维度决定需要看哪些字段必要时调用额外的检索工具去查旧版本的历史行为最后综合出一个带证据链的评估结论。4.2 方法论注册机制从Rules到Protocol这里就是Evaluation智能体添加方法论这件事的落点。我们的评估方法论不是写死在代码里的而是通过一套注册机制来动态添加。每一条方法论本质上是一份评估协议Protocol包含四个部分适用场景什么类型的评测单元适用这条方法论评估维度要打分的维度列表比如事实准确性、指令遵循度、安全性、多轮一致性判定流程明确说明需要哪些上下文、按什么顺序做判断输出格式每个维度需要给出分数、理由、引用的原始证据片段。最初我们想偷懒把方法论直接堆进System Prompt里让Evaluation Agent自己领悟。结果效果很不稳定各场景的评估尺度漂移很大。后来改成了协议注册制——每个场景在添加方法论时会有一个协议校验环节将这条方法论先在已有人工标注的子集上跑一遍计算和人工标签的一致率一致率超过阈值才允许注册生效。这一步相当关键它保证了新增方法论的靠谱程度。方法论的添加过程本身很像教一个实习生学会打分先给他看规则再给几个正反样例最后让他试评一批你检查结果。Workrun里对应的操作就是注册协议、指定参考样例、进行小规模校准实验。4.3 评估结果的结构化输出与阈值管理评估Agent输出的不能只是一个通过/不通过否则没法追溯问题。我们规定了评估结果必须输出一份结构化报告至少包含以下内容每个维度的得分与置信度判定理由一段文本命中的样本原始片段Trace中的某一段是否存在低置信度的可疑点。这份报告会随评估结果一起进入数据仓库。回归评估最忌讳的就是输出一个剧场比分——大家只知道这次总分下滑了2分但不知道为什么。结构化的评估报告让团队能按图索骥从分数波动一路钻到具体的某一段运行时轨迹里。阈值管理上我们经历了几个阶段。最初是人工定每个维度0.8低于0.8就是失败。但LLM应用没有这么理想的二分边界很多场景的得分天然围绕0.75上下波动一个无关紧要的Prompt改动就能让它跳水。后来我们把单阈值改成了三区制绿色区得分高于0.85视为通过、黄色区0.7~0.85视为需要人工复核、红色区低于0.7视为明确回归。这个变化让评估结果从一刀切的红绿变成了有弹性的交通信号研发团队的反感度下降了一个量级。5. 回归评估上线后的三道坎5.1 误报刷屏阈值收敛的真实过程任何评估系统上线之后都会经历一段误报刷屏期Workrun也不例外。刚开始我们把评估结果接入发布流水线每次发布前自动跑全量评测集结果前两周几乎每两天就收到一个告警某个维度的均分跌落了0.05。一开始团队如临大敌停了发布去排查最后发现一半的告警都是假摔——具体来说是评估集里的样本在自动扩写和更新过程中新加入的样本难度偏高导致整体均分被拉低。这个锅不在模型而在评测集本身发生了分布漂移。后来我们搞了一个基线锁定机制每次回归评估必须同时跑对照子集和增量子集。对照子集是从上一次通过的样本里固定抽出的500条用于排除评测集变化导致的分数波动增量子集是从最新Telemetry里新增的样本。只有当增量子集的得分显著低于对照子集时才认定为真实回归。这套机制上线之后误报率直接从40%降到了个位数。5.2 评测集污染同一批样本反复用会钝化和单元测试一样的道理评测集本身也会过时。生产流量永远是动态的用户的问法会变产品在迭代新的工具在接入。如果你几个月都不更新评测集它在数学上仍然是运行事实但在语义上已经退化成旧世界的化石了。我们吃过这个亏有一段时间评估集连续三周没更新结果模型的一次重大改动在评估集上完好无损上线后却被用户投诉连基本问题都答不好。回溯后发现新增的用户问题类型在评估集里的覆盖几乎为零——评估集已经钝化到对现实失明。现在Workrun规定评测集必须每周增量更新更新节奏是70%保留、20%替换、10%新增。保留的是历史关键回归场景替换的是语义相似度过高的冗余样本新增的是这周Telemetry里覆盖度缺口最大的场景。同时我们有一个相似度去重器对入库的每个样本做一次向量相似度检查和已有样本相似度超过0.92的直接丢弃避免评测集被某一种问法刷屏。5.3 跨团队信任如何让研发认账做一个内部评估平台最难的往往不是技术而是让研发团队相信你的评估结论。开学时我们经常收到研发的质疑这个case我本地跑过没问题为什么线上评估说不行 ——后来发现一半的情况是评测样本本身有问题另一半是评测标准有歧义。解决方案其实不复杂我们强制做到了两点。第一任何评估失败结论必须附带证据链接一键跳转到原始Trace研发可以直接看到当时的样子而不是只看到一个冷冰冰的评分数字。第二评估标准必须对研发可见——他们可以随时查看某个维度的方法论协议甚至对协议提出修改建议。一旦研发发现评估标准本身不合理可以通过协议变更提案流程提交修改走校准实验验证后更新。这样一来评估体系不再是测试团队单方面制定的法律而是一个大家一起维护的共识机制。信任这个东西只能靠透明换回来。把评估逻辑做成黑箱它再准也没人买账做成白盒即使偶尔出点小问题大家也愿意陪你一起调。6. 一些可以带走的具体配置6.1 自适应采样策略示例最后分享几个可以直接抄作业的配置。Telemetry的自适应采样我们在Workrun里用的是类似下面这样的规则不同团队按自己的量级调整阈值即可健康请求默认采样率10%如果该场景在评测集覆盖度低于20%提升到50%异常请求返回错误、超时、重试采样率100%不参与覆盖度判断慢请求耗时超过P95采样率100%优先保留评估集覆盖度达标的场景采样率降至5%只保留每日随机一部分用于漂移监测。这套配置的核心思路是Telemetry的采集成本要花在未来可能变成评估证据的数据上。健康流量的价值密度低不值得全留异常和慢请求往往能暴露边界行为价值密度高值得全留。6.2 评估集增量更新的节奏评估集更新的具体节奏我们的经验是做周级别滚动不要搞成每天。每天更新意味着每个工作日都要重新校准一遍分数基线团队会被评估系统本身拖着走。每周一执行一次增量更新流程从过去7天的Telemetry中筛选候选评估单元跑一轮自动去重、脱敏、标注人工抽样审核新批次311比例通过率达标才入库计算新旧评估集的分布差异输出一份评测集变化报告更新基线锁定子集重新校准阈值。如果某周有重大版本发布比如更换了主模型或Agent框架可以在发布前额外触发一次定向补集专门从最近异常反馈中快速构建一小批回归用例跑一个只针对改动的快速评估。这个流程跑得多了团队就会形成条件反射——改大结构前先补评估集再改代码。6.3 回归评估的指标看板最后是看板指标。我们的主看板不放大而全的综合分因为综合分不具备可操作性。放的是回归证据覆盖率和回归失败定位耗时这两个指标。回归证据覆盖率衡量的是当前评测集中的场景数占最近30天Telemetry中识别出的有效场景数的比例。这个指标直接告诉你评估盲区有多大。回归失败定位耗时衡量的是从评估告警出发到定位到具体是哪个模块、哪个Prompt、哪个工具调用导致的退化需要多长时间。在结构化评估报告和Trace追溯链路跑通之后这个耗时从最初的平均半天压缩到了20分钟以内。顺便提一嘴如果你也在做类似的事情建议团队里至少有一个既懂一点可观测性、又理解评估体系的人来牵头。很多人觉得这是两个领域、两套体系但实际上它们缝合起来的那一层才是真正的价值所在。我见过好多团队在采集端做得极其漂亮评估集却还在手工维护也见过评估方法论研究得很深但输入数据全靠瞎编。Workrun这段实践给我的最大感受是Telemetry和Evaluation不是两个平行的子系统它们本质上是一条价值链的两端——运行事实只有被转化成回归证据才真正产生了闭环价值。