「我们要做 eval」这句话在不同团队里指三件完全不同的事，而它们的数据来源、运行频率、决策用途都不一样。混为一谈是常见的失败起点。
最常见的两种失衡：只有①的团队会不断把离线分数刷高，却发现线上没有任何改善；只有③的团队每个改动都要跑一周实验，迭代速度慢到无法承受，且无法归因。②几乎总是被跳过的那一层，而它恰恰是维持长期质量的关键——因为 LLM 系统的改动极易产生非局部的影响。
评估集不是建好就一劳永逸的资产，它有三个必须主动管理的问题：
① 过拟合。反复在同一个评估集上迭代，你会逐渐把系统调成「在这 200 条上表现好」，而非「真的更好」。缓解：保留一个从不用于迭代、只在重大发布前跑一次的保留集（holdout）；定期从线上补充新样本。
② 分布漂移。用户的问法、场景、热点都在变。半年前建的评估集可能已经不代表今天的流量。缓解：定期（如每季度）用线上真实分布重新采样一批，检查评估集的代表性。
③ 覆盖偏差。凭空编写的问题会集中在系统本来就擅长的区域。最有价值的样本来自线上失败——用户重问的、点踩的、转人工的（6.1 的代理信号正是它的来源）。
一条务实的建议：把「每次修复一个线上问题，就把它加进回归集」变成团队纪律。这是成本最低、复利最高的做法——评估集会随着系统的成长自动积累它真实的弱点分布，而不需要任何专门的建设项目。大多数优秀的评估集都是这样长出来的，不是设计出来的。
用模型给模型的输出打分，是让评估规模化的主要手段。它确实有效，但有三个必须处理的问题：
① 必须校准。这是使用 LLM 评委的前提而非可选项：拿 50–100 条人工标注过的样本，检查评委的判定与人工判定的一致率。一致率不达标的评委，它给出的所有分数都是噪声——而你会拿这些噪声去做发布决策。校准之后还要定期重测，因为换模型或改 prompt 都会改变评委的行为。
② 已知的系统性偏差。LLM 评委倾向于更长的回答、格式更漂亮的回答、以及与自己风格相似的回答。在做 A/B 对比时还存在位置偏差（倾向选择放在前面或后面的那个）。对策：交换位置各评一次取平均、在评分标准中明确「长度不是评判依据」、优先使用二元或少档位的判定（「是否忠实于材料」）而非 1–10 打分——细粒度分数的噪声远大于其信息量。
③ 能程序判定的，就不要用模型判定。JSON 是否可解析、引用编号是否存在、枚举值是否合法、数字是否与材料一致——这些用代码判定既免费又确定。把 LLM 评委留给真正需要语义判断的少数环节，这既省钱又让评估结果更可信。
① 业务指标信噪比低。LLM 改动对留存、转化这类终极指标的影响通常很小，需要很大的样本量和很长的时间才能显著。对策：使用更敏感的中间指标——重新生成率、点踩率、转人工率、会话完成率。它们与质量的相关性强，且响应快得多。
② 灰度必须能按版本分桶。如果监控无法区分新旧版本的流量，A/B 的结论会被混合污染。这要求 6.1 的 trace 里记录了版本信息——评估体系依赖可观测性体系，两者必须一起建。
背景：一个客服问答产品，团队搭了 LLM-as-judge 的自动评估：让模型给回答打 1–10 分，取平均作为质量指标。
过程：三周里做了几轮 prompt 优化，离线平均分从 7.2 稳步涨到 8.4。团队很受鼓舞。但线上的代理信号——点踩率、转人工率——完全没有变化。
排查：团队做了一件本该在最开始做的事——抽 80 条样本人工标注，与评委的打分做对比。结果：
真相：三周的「优化」实际上做的是让回答变得更长、更有条理——这确实提升了评委给的分数，但对用户能否解决问题几乎没有影响。团队优化的是评委的偏好，不是产品的质量。
修复：
① 把 1–10 打分改成几个二元判定：「是否回答了用户的问题」「是否忠实于检索材料」「是否包含有效引用」。二元判定的一致率远高于细粒度打分——因为它不需要评委在「7 分还是 8 分」这种本就没有客观标准的问题上做判断。
② 把能程序判定的部分（引用编号是否存在、是否包含拒答表述、JSON 是否合法）从评委手里拿走，改用代码判定。
③ 在评分标准中明确写入「回答长度与格式不作为评判依据」。
④ 建立校准流程：每次修改评委 prompt 或更换评委模型后，必须用人工标注样本重测一致率，不达标不投入使用。
三条教训：
① 未校准的评委比没有评委更危险——它给了你一个可以持续优化的数字，让整个团队朝错误方向努力，而且看起来一切正常。
② 细粒度打分是个陷阱。「这个回答值 7 分还是 8 分」没有客观答案，评委在这个问题上的输出主要是噪声。二元或三档判定的信息量更高。
③ 离线指标必须与线上信号对齐验证。如果离线分数涨了而线上代理信号毫无反应，首先该怀疑的是指标本身，而不是「线上信号不敏感」。这个反射是这次事故最该被内化的一点。
评估框架：Langfuse / LangSmith / Braintrust（与 trace 打通，可直接从线上日志构造数据集）、DeepEval、RAGAS（RAG 专用指标）、promptfoo（轻量、配置驱动，适合接 CI）。选型的关键是能否与你的 trace 系统打通——评估集最好的来源就是线上日志。
接入 CI：把回归测试做成一条流水线，任何触及 prompt、检索配置、模型版本、工具 schema 的改动都必须跑一遍。用「相对上一版本是否退化」而不是绝对分数阈值作为门禁——绝对阈值会随评估集更新而失效。
评委模型的选择：不必用最强的模型做评委。对二元判定类任务，中等规模模型经过校准后通常足够，成本低一个数量级，可以全量在线跑。把预算留给真正需要强模型的少数判断。
标注工具：Argilla、Label Studio 等；小团队用带模板的表格 + 双人标注一致性检查也完全够用。不要因为「没有标注平台」就不做人工标注——校准所需的样本量只有几十到一百条。
务必做的一件事：把评委的判定结果与人工标注的一致率本身也做成一个被追踪的指标。评委模型会被升级、评委 prompt 会被修改，一致率的漂移是静默的——不追踪它，你不会知道评估体系是什么时候开始失真的。
因为它提供的是一个可以被持续优化的错误信号，而不是明显的缺失。
没有评委时，团队知道自己缺少评估手段，会保持谨慎、会依赖人工抽查和线上反馈。而未校准的评委给出一个看起来专业的数字，团队会围绕它做决策、把它写进周报、用它做发布门禁——整个组织朝着一个未经验证的方向持续用力，而所有仪表都显示正常。
具体的失效机制：LLM 评委有已知的系统性偏差——偏好更长的回答、格式更漂亮的回答、与自己风格相近的回答，以及 A/B 对比时的位置偏差。围绕这样的评委优化，实际优化的是这些偏差对应的表面特征，而非真实质量。案例中三周的「优化」只是让回答变长变整齐，线上指标纹丝不动。
校准怎么做：拿 50–100 条人工标注样本，测评委判定与人工判定的一致率。并且这不是一次性的——评委模型升级或评委 prompt 修改后必须重测，一致率的漂移是静默的。把一致率本身做成被追踪的指标。
降低对评委依赖的两个办法：能程序判定的（JSON 合法性、引用是否存在、枚举值）一律用代码；需要语义判断的优先用二元判定而非 1–10 打分——细粒度分数的噪声大于信息量。
按可能性从高到低排查：
① 评估指标本身有问题（最常见）。评委未校准、存在长度/格式偏好、或指标测的不是用户真正在乎的东西。验证方法：抽样人工标注，看离线分数与人工判断的一致性。这应该是第一个怀疑对象，而不是最后一个。
② 评估集不代表真实分布。golden set 可能覆盖偏差严重——集中在系统本来就擅长的区域，或来自半年前已经漂移的分布。改动在评估集覆盖的场景上有效，但那些场景只占真实流量的一小部分。
③ 数据泄漏 / 过拟合评估集。反复在同一评估集上迭代，把系统调成了「在这 200 条上表现好」。这就是保留集（holdout）存在的理由——用一个从不参与迭代的集合验证。
④ 线上指标不够敏感。留存、转化这类终极指标信噪比低，小改动测不出来。换更敏感的中间指标——重新生成率、点踩率、转人工率、会话完成率。注意：这个原因应该排在后面，先怀疑指标而不是先怀疑线上信号。
⑤ 改动确实真实但影响面小。比如优化的是只占 3% 流量的场景，整体指标自然看不出来。验证方法：只在受影响的流量子集上看指标。
⑥ 实验设计问题。分桶不干净、样本量不足、观察期太短、或监控无法按版本分桶导致新旧流量混在一起。
原则：从最便宜、最能防止灾难的开始，不要一上来建完整体系。三人团队做全套评估基础设施必然烂尾。
第一周做的（成本几乎为零，价值最高）：
① 结构性指标——JSON/schema 校验失败率、工具调用失败率、拒答率、引用缺失率。可程序判定、零标注成本、可直接告警（6.1）。
② 线上代理信号——重新生成率、点踩率、转人工率。埋点很简单，能立刻感知质量变化。
③ trace 记录版本信息——模型版本、prompt 版本。没有它，后面所有归因都做不了。
第一个月做的：
④ 回归集，用最省力的方式积累——把纪律定成「每修复一个线上问题，就把它加进回归集」。不要专门立项建评估集，让它随系统成长自然长出来。目标是几十条，不是几百条。
⑤ 一个能跑回归集的脚本，接进发布流程。哪怕只是手动跑，也远好于没有。
第二三个月做的：
⑥ LLM-as-judge，但先校准——用二元判定而非打分，用 50–100 条人工标注测一致率。如果一致率不达标，宁可先不用。
⑦ 保留集——从回归集里划出一部分从不用于迭代。
暂时不做的：完整的 A/B 实验平台（流量不够，统计功效不足，先用灰度 + 代理信号观察）、复杂的标注平台（表格够用）、追求评估集规模（100 条覆盖全面的样本 > 1000 条同质样本）。
贯穿的判断：评估体系的价值不在于精确度量质量，而在于「改坏了能被发现」。三人团队最该防的是回归退化，而不是精确排名两个 prompt 的优劣。