评委的可信度卡在输入上
自动评测跑不准，多数时候不是评委模型不够强，而是喂进去的数据是从生产日志重建的：混着工具内部提示词、用户语言与系统状态对不上、错误过滤污染分母。
一个自动评测系统跑出通过率，你信不信这个数字？多数团队的第一反应是调评委的提示词，或者换一个更强的模型。但真正让数字失真的，通常是更前面的一步：喂给评委的那些对话，是从生产日志里重建出来的，而生产日志从来不是为评测准备的。
淘宝的 AI 购物助手把这件事做成了日级工业化运行，日复一日评测海量真实会话。他们的结论是：评测可信度的瓶颈不在评委模型本身，而在数据质量和评测标准的持续校准 taobao-shopping-eval。离线评测的数据是精心构造的，字段完整、格式统一；线上日志不是，用户表达模糊、工具返回异常、字段散落在多张表里。同一套评委提示词，喂离线数据能跑，喂线上数据就会大量解析为空——在线与离线两条腿 讲了两者的分工，这篇讲线上这一侧的数据要怎么重建。
从原始日志到评委能消费的输入
线上数据要经过四层清洗才配送给评委。这四层不是一次设计出来的，是随着各域评测推进依次暴露、逐层补上的。
第一层，补全字段。 线上日志各功能模块的卡片协议独立、字段解析方式各异，直接复用离线提示词会大面积解析为空。需要逐域对照离线的数据定义修复解析、补字段映射。一个具体陷阱是卡片文本动辄数千字，拼接后超出上下文窗口，有的平台不报错而是静默返回空结果——这一条数据就等于没评，所以要在数据准备阶段做长度预检和截断。
第二层，对齐语义。 用户说的「已经揽收了」，系统里存的是某个英文状态枚举值，而它并不等于「已发货」。评委不知道这层映射，就会认为客服说「已发货」与系统状态矛盾，判成回复错误。解法是在提示词里显式建立用户语义与系统语义的映射表——这不是评委的问题，是输入没翻译。
第三层，剔除噪声。 工具调用记录里带着工具接口自身的内部提示词（系统指令、开发注释）。这些不是客服生成的内容，但评委看到会把它读成客服说的话，据此判对判错。用规则把这类透传内容剔掉，只保留实际调用的参数和返回值——就这一步，各域评测准确率都有明显提升。
第四层，收窄入口。 早期按宽泛条件捞数据，大量不属于该功能的提问被算进分母。某个流程类功能里，多数样本其实只是咨询政策、并未真正发起操作，甚至完全无关；分母被污染，通过率自然极低且不可信。改成按功能标识精确过滤后，评测数据才真正可用——也才暴露出那个功能通过率低的真实原因是提示词不适配线上数据，而不是产品质量差。
四层里没有一条是关于评委模型的。它们全部是数据工程。
上下文给多了也会错
一个反直觉的发现：给评委的上下文不是越多越好。
多轮对话场景下，最初的做法是把完整对话历史和全部工具调用链都交给评委，让它拥有最充分的背景。结果评委用前几轮的工具返回来评判当前轮的回复——前一轮返回的某个金额，被当成当前轮的事实依据，跨轮信息互相干扰，通过率明显偏低。改成只传当前轮的工具调用后，通过率显著跃升。
原因是注意力分配：上下文里存在多个轮次的工具调用时，模型难以区分当前轮该看哪个，容易被相邻轮次带偏。这条经验对提示词工程的含义是——精准投喂，而不是无差别堆砌。
同一类问题还有一个更基础的版本：评委没有「现在几点」的概念。客服回复里的「明天到达」「3 个工作日到账」，用户提问里的「近一年订单」，评委都无从判断准确性。解法是在输入里拼上用户提问的精确时间戳，并说明以此为参考基准。这一步修好了时效类功能的「时效篡改」误判，也解决了检索类功能因时间锚点缺失导致的大量误判。
数字不对时，先归因再动手
评测出问题时的第一反应往往是改提示词。但通过率异常的根因分四层，修错层的代价是越调越差。
- 数据层：喂进去的数据本身有问题——内部提示词没剔干净、长卡片截断丢了关键信息、字段映射错位。修数据清洗逻辑，影响该功能所有同类数据。
- 提示词层：数据对，但评委对规则的理解有偏差，比如边界场景缺少判定示例、子项之间的判定边界描述模糊，评委把 A 的失败归到 B。补判定规则或示例。
- 标准层：评测标准本身与技术认知不一致。比如产品预期是「查无结果时如实兜底 + 引导查看详情」，而标准会导致判 0。这一层影响最大，改完要同步离线和在线的标准快照。
- 产品真实质量问题：排除以上三层后剩下的，才是产品真的编造了事实、真的传错了参数、真的触碰了红线。这类才反馈给产品团队修。
书里的教训很直白：早期没有归因机制时，看到通过率下降就调提示词，结果有时越调越差，因为根因在数据层或标准层，改提示词只是掩盖问题。
让幻觉自己举手
归因是事后的事，还有一类问题连归因的机会都没有：幻觉不会抛调用栈异常，所有传统健康检查都是绿的——下游照常消费了那条编造的推荐，很久之后才有人发现对应的事实根本不存在。一家大型零售企业的库存平台，上线第一个月末约 15% 的智能体返回是幻觉；半年后降到 1.5%。推动下降的不是换更强的模型，而是把 LLM 能力当平台基础设施来治理 llm-platform-playbook。
两个具体做法。一是在平台边界而不是各应用里强制结构化输出：每次调用声明输出 Schema，校验通过才返回调用方，失败时把校验错误回喂给模型重试并设硬上限。放在平台层的好处是下游可以依赖「返回即合规」的契约，Schema 违规成为平台监控指标，而不是深埋在应用日志里的异常。二是让输出 Schema 自带证据申报字段：要求模型声明每条结论是否有检索证据支撑、是否超出了知识范围。这个字段生成成本近零，却把「看似自信的答案」变成了机器可读的失败信号——声明有证据但来源为空、校验不过，就是平台识别幻觉精度最高的信号。
重试也要分类。Schema 不合规，附上错误信息重试；模型承认了没有证据支撑，加强锚定上下文再试；限流和超时这类基础设施故障，指数退避。三类混成一套通用重试逻辑是错的——盲目重跑产生幻觉的提示词，只会得到另一个幻觉。
指标异动先拆分子分母
同样的纪律适用于线上指标。某个功能的路由通过率突然骤跌，直觉反应是功能回归、线上出了紧急故障。逐日拆解后发现：分子（匹配到该功能的会话）几天内平稳，分母（该功能的基础会话）却在两天内先翻倍、再接近三倍——不是流量涌入，而是该功能的意图占比异常抬升。
按子标签拆解定位到：真实业务动作全程平稳，暴涨集中在一个标签上，量级近乎翻十倍。这批提问原文几乎全是使用类咨询，根因是上游另一个功能放量后，意图模型把这类咨询错误地标成了该功能的投诉标签，被过滤条件捞进了分母。剔除这个标签后，五天的跌幅全部消失、恢复平稳。
不做归因就会以为线上有紧急 bug 要修，其实只需从评测过滤条件里去掉一个不属于该功能真实动作的标签。
通过率涨了，不代表产品变好了
多轮迭代的目标不是「让通过率变高」，而是「让通过率更可信」。早期通过率低，多半不是产品真那么差，而是评测方法还没调对；等各功能的通过率收敛稳定之后，后续的每一次变化才指向真实的质量问题。
这个判断决定了你该怎么读评测报表。收敛之前，指标主要反映评测系统的成熟度；收敛之后，指标才开始反映产品。两份报表长得一样，含义相反。
校准的手段是持续抽样比对：每轮迭代后做评委与人工打标的一致性校验，用纯随机抽样保证通过率无偏。样本量要按需要的精度反推——要让通过率误差控制在正负 1 个百分点约需四千条样本，正负 0.5 个百分点约需一万五千条。有一个实用推论：如果通过率的波动明显超出置信区间宽度，那多半不是抽样噪声，而是标准或模型发生了实质变化，值得去查。
代价也要说清楚：这套做法要求日级留存全量日志、维护分功能的清洗管线、持续投入人工打标。对一次性内部工具完全不划算。判断标准写不写得出来，取决于你有没有先定义完成——这一条 先定义完成，再写第一行代码 已经讲过。检查方法是挑一个已上线的评测任务，问自己三个问题——评委的输入是从生产日志重建的吗？重建过程有哪几层清洗？通过率异常时，你会先改提示词还是先归因？第一个答不上来，说明评测的上限还没被看见。