智能体关键能力：LLM Evals 与生产级评估体系

企业里把 LLM 和 Agent 真正用起来最难的从来不是把它跑通。最难的是回答两个朴素的问题它现在到底行不行以及我改完之后有没有变差。确定性软件能用单元测试加覆盖率把这两个问题答得明明白白。LLM 是概率系统输出是开放文本行为依赖 prompt、上下文、工具返回甚至同一份输入两次采样都能给出不一样的答案。这里没有 oracle没有期望输出可以硬编码。Evals 本质是给这套非确定性系统造一把可重复的标尺。我的看法很直接评估不是上线后才补的功课它是 Agent 工程的第一性原理。没有评估所有号称的调优都是黑暗里调收音机调一下听一下毫无积累。这一篇我们不讲工具清单讲最底层的机制为什么需要评估评估在哪些层次上发生指标到底在度量什么以及生产环境里那套评估体系是怎么把混乱收敛成可信任的工程活动的。一、为什么非确定性系统必须有评估确定性软件的测试逻辑是输入确定输出确定断言相等。这套逻辑对 LLM 彻底失效失效来自三个源头非确定性、漂移、回归。非确定性来自采样即使 temperature 设成零同一个 prompt 加同一份输入两次生成也可能不同。原因包括解码时的数值非确定性、batch 内注意力计算的微小差异、以及服务端负载导致的 beam 行为变化。这意味着你不能靠我试了一次好像行来判断一个能力。评估必须定义在分布层面在足够大的样本上正确响应的比例是否达到阈值。数学上要诚实。把单次生成看成从条件分布 P(Y|X) 里抽样评估要估计的是在测试分布 D 上质量函数 Q 的期望值 E_{XD}[E_{YP(Y|X)}[Q(Y)]]。单次观察方差极大要得到稳定的估计样本量 N 必须足够大。中心极限定理告诉我们比例的估计误差大约服从 1/√N 的衰减所以你想把置信区间收窄一半样本量得翻四倍。这就是为什么 eval 的单位是集而不是例指标是率而不是次。很多团队上线前拿五六个例子手测一遍就宣布 OK这在统计上毫无意义。举个具体的数你想以 95% 置信度检出 5 个百分点的成功率变化假设基线成功率 70%两比例检验需要的样本量在几百条量级。eval 集的规模是被统计有效性逼出来的不是拍脑袋定的宁可少测几个维度也要把样本量凑够。漂移来自底座和世界的双重变动你依赖的底座模型会被供应商悄悄升级P(Y|X) 随之变化你的 prompt 在新模型上可能突然变得更保守或者更爱幻觉。你改 prompt 是显式漂移底座的服务端变更对你而言是隐性漂移。更麻烦的是知识漂移外部世界变了新法规、新 API、新事实正确答案本身在动。eval 集的意义就是当锚点把这些变动暴露出来。漂移这一点和传统软件的回归测试同源但难得多因为什么是正确本身都不固定。回归来自你自己的修改你为了修场景 A 改了 prompt结果场景 B 掉分了。没有回归集你根本发现不了。eval 集在这里扮演的角色等价于软件工程的 golden set 或回归套件每次改动跑全量对 score diff 做 review。区别在于传统断言失败是确定的二值LLM eval 有方差你必须区分真回归和噪声波动。一个实用做法是多次运行取均值并看置信区间必要时做两比例 z 检验z (p1 − p2) / √(p(1−p)(1/n1 1/n2))用统计显著性把噪声和真回归分开。二、评估在三个层次上发生把评估类型按粒度铺开其实是三个层次单元级关注单次生成的质量轨迹级关注多步过程是否合理系统级关注端到端有没有达成业务目标。同一套方法会落在不同层次上理解层次比背清单重要。单元级 LLM-as-judge用一个强模型当裁判按 rubric 给候选输出打分这是当前最现实可用的方法。两种形态最常见分类式给 rubric 加候选输出 1 到 5 分或 pass/fail 的结构化结果通常走 function calling 拿稳定 JSON对比式直接把 A 和 B 喂进去问谁更好主要用在 A/B 选型或迭代里挑优。它为什么有效因为有用性连贯性这种语义质量根本没法用字符串匹配度量。人类裁判是 gold standard但贵且慢judge 是人类裁判的可扩展近似。数学直觉要清楚judge 其实是对人类质量函数 H(Y) 的一个有偏估计 J(Y)。我们真正在乎的不是 J 的绝对值准不准而是 J 和 H 的相关性高不高能不能保持正确的排序和回归方向。换句话说judge 是个 ranker不是 scorer。但 judge 有自己的系统性偏差这是工程里最容易被忽略的坑。位置偏差让它在 pairwise 比较里偏好排在前面的那个。冗长偏差让更长的回答自动拿更高分哪怕内容更水。自我偏好偏差是模型倾向于给和自己风格相似的输出打高分。权威语气偏差则让用词笃定的答案显得更可信。这些偏差不能靠用更强的模型消除更强的模型只是把偏差换了个更优雅的形式。缓解手段是工程化的pairwise 要把顺序互换各跑一次取平均分类式要喂 rubric 加参考回答逼 judge 对照而非凭印象用 chain-of-thought 让 judge 先给理由再给分降低随机性关键的要拿人类标注做校准算出 judge 和人的一致性Spearman 相关和偏差方向必要时对 judge 分数做后校准回归修正。没有这步你盯着 dashboard 上的分数涨跌其实可能只是在看 judge 的心情。校准的具体做法是画校准曲线把 judge 分数分箱算每箱里人类判正的比例理想情况应该落在对角线上明显偏离就说明有系统性偏差。更进一步可以算 Spearman 相关看排序一致性算 Brier score 看概率校准程度。我的经验是judge 和人的 Spearman 低于 0.7 就别拿它做回归门禁只能当粗筛真要进门禁至少先做好校准曲线再决定。引用与忠实度针对 RAG 和会调工具的 Agent回答到底有没有忠实于它引用的证据有没有幻觉出上下文里根本不存在的东西。忠实度faithfulness的标准做法是把回答拆成若干 claim逐一让 judge 判断每个 claim 是否能被检索上下文蕴含entailment最终分数就是被支持的 claim 占比。引用正确度更进一步它看引用的具体片段是不是真的支撑了那个论点而不是文中确实出现了引用就算数。这类指标更客观因为它有金标准证据可对是 RAGAS 体系的核心faithfulness、context precision、context recall 都落在这里。顺带说清楚 RAGAS 这几个指标的直觉免得把它当黑盒。Context recall 衡量检索回来的上下文覆盖了多少参考答案里的事实分数低说明漏检。Context precision 衡量检索的排序质量相关段落是不是排在前面用的是类似 DCG 的折扣加权。Faithfulness 如上是生成回答对上下文的忠实程度。它们合起来回答一件事证据找得全不全、排得好不好、用得诚不诚实。任务成功率给 Agent 一个明确目标比如把这个 bug 修掉并提 PR它是不是真完成了。判定可以是程序化的最终状态符合预期文件改对了、PR 建了、测试过了也可以是 judge 看最终产物。这是端到端最硬的指标因为它直接对齐业务目标。但它的方差也最大复杂任务本身成功率就不高成功的定义边界还常常模糊需要人工裁定。实践中我建议把成功率和步骤数、工具调用次数、花费摆在一起看同样成功率下步骤越少越好这是个帕累托权衡。轨迹级评估不只看结果对不对还看它怎么走过去的每一步规划合不合理工具调用对不对有没有重复调用或死循环。两种做法一是 step-level judge在轨迹中间对每个 action 打质量分能精确定位是哪一步走错了二是对整条轨迹打一个整体分衡量连贯性和效率。轨迹评估的价值在于结果对可能是侥幸轨迹对才说明方法可靠、能泛化。它也是过程奖励模型PRM和 RLAIF 的基础信号。和任务成功率的关系是成功率是 0/1 的粗信号轨迹分是连续的细信号能给出改进梯度更适合驱动迭代和强化学习。三、指标从准确率到忠实度再到工具调用正确率指标不是越多越好而是要清楚每个指标在度量什么、它会在哪里骗你。准确率与精确率召回落在可判对错的硬任务上比如分类、事实命中、工具选择。Accuracy (TPTN)/总数但在不平衡集上召回更关键。Agent 最大的风险面往往是该做的动作没做召回直接衡量这个比看整体准确率有用得多。忠实度 faithfulness即回答中被证据支持的 claim 占比或 judge 给出的 0 到 1 分。它衡量幻觉程度是 RAG 和工具型 Agent 的生命线。一个回答准确率看着高但靠编faithfulness 会把它揪出来。有用性 helpfulness让 judge 判断是否真正解决了用户意图。这是端到端体验指标最难定义却最重要。我的观点是很多团队沉迷于 faithfulness 和准确率却忽略了用户真正感知的是 helpfulness。一个忠实但答非所问的回复faithfulness 满分也没用。工具调用正确率这是 Agent 区别于纯生成模型的核心能力指标。它还能拆成三块工具选择是否选对、参数是否符合 schema、参数的语义是否正确。前两块容易程序化校验第三块常常还要 judge 或单测。工具调用错了后面生成得再漂亮也是南辕北辙。这些指标常组合成综合分但权重要小心。不同阶段关注点不同早期看成功率和工具正确率稳定期更要盯忠实度和成本。把权重写死一成不变是另一种会让 eval 失真的隐性漂移。综合分的设计还有个常见陷阱各指标量纲不同、方差不同简单加权平均会把高方差指标的声音放大掩盖低方差但关键的指标。更稳的做法是先对每个指标归一化到同一区间再按业务阶段加权或者直接盯少数几个北极星指标其余只作监控不进总分。另一个坑是综合分对小幅均匀退化不敏感所有指标都掉一点加权平均可能还在阈值之上但用户体验已经明显变差。所以回归门禁必须看单指标 diff不能只看总分。四、生产级评估体系离线、在线、人工三层闭环单机跑一遍 eval 脚本只是玩具。生产级体系是三层加起来再配一道回归门禁。离线回归集是一份固定、标注好、版本化的测试用例集合从几百到几千条覆盖核心场景和边界 case。每次 prompt 或模型改动都跑全量生成 score diff 报告并进 code review。它等价于传统 CI 里的回归套件。这里的关键是这份集本身是公司资产要进版本库、要防污染下一节细说要和训练数据严格隔离。在线监控 / 影子评估对线上真实流量采样打分judge 异步跑、不影响用户。监控成功率、helpfulness 分布、工具调用失败率、幻觉率、延迟和成本设告警阈值发现漂移。更进一步用 shadow 或 canary新版本旁路上线和旧版本在同一份流量上直接比分数上线前就预判线上表现。众包与人工校准定期抽一批 judge 评分的样本让人标算 judge 和人的一致性校准偏差同时把最难的边界样本人工标注后回灌进回归集。这一步是让 judge 持续可信的闭环没有它前两层迟早会因为 judge 漂移而集体失真。门禁要设计得稳。CI 里设回归门禁关键指标相对基线跌超过阈值或置信区间下界低于阈值就阻断合并。但门禁必须容忍噪声否则会出现两类错误把噪声当回归的 false positive 会天天阻塞开发方差大到盖住真回归的 false negative 则让门禁形同虚设。多次运行加统计检验是基本配置不是可选项。具体怎么设噪声容忍一个常用配置是每个改动跑 K 次比如 5 到 10 次取聚合指标再和基线的多轮均值比较。拦截不要用点估计的差而用置信区间下界只有区间下界低于阈值才阻断。否则单次波动就会误杀好改动团队很快就会对门禁失去信任。五、评估集怎么建以及如何避免被污染评估集的构建质量决定了你所有结论的天花板。来源要真实首选线上日志采样它反映真实分布比人工拍脑袋造的题有价值得多。其次人工构造边界 case 和对抗样本补日志里采样不到的长尾。再叠加合成数据扩量。标注要有 oracle每条样本都得有明确的可判定标准正确答案、判分 rubric、或者可程序化校验的最终状态。没有 oracleeval 本身不可信你只是在用一个模糊去测另一个模糊。困难样本要多人标注取共识看标注者间一致性inter-annotator agreement一致性低说明题目本身模糊得返工。分层抽样按场景、难度、用户群分层保证覆盖率。只测简单样本会给出虚高的分数掩盖长尾的崩溃这种虚高比低分更危险因为它会让你带着错误的安全感上线。污染是评估最大的隐形杀手底座模型的训练数据可能见过你的测试题尤其公开 benchmark或者你公司内部文档泄漏进了训练语料结果分数虚高、完全不可信。数学上这把测试损失变成了训练记忆评估的泛化含义被彻底蒸发。规避手段是工程纪律train/dev/test 严格隔离测试集用私有、内部、时效性强的问题比如本周刚出的文档对公开 benchmark 做改写扰动改变其分布留一个从不外泄的 holdout 集并定期刷新测试题到模型 cutoff 之后的新事实。一个实用判据换一个模型从没见过的同类问题Agent 还行那才说明你的 eval 没被污染。还有一个容易被忽视的污染来自 prompt 本身。如果你的 prompt 里嵌了大量示例而这些示例恰好和测试题同分布eval 测的其实是模型对示例的记忆而非泛化能力。解决办法是测试题和 few-shot 示例严格不重叠且示例的分布要宽于测试分布宁可示例更通用也不能和考题撞车。六、评估如何真正驱动迭代评估不是终点它是方向盘。把失败 case 当 bug 修。每个 fail 都写成一条 regression test 防止复发这和软件工程的态度完全一致。区别在于你修的是 prompt、是工具定义、是检索策略不是常规代码但纪律一样。用 score diff 做决策而不是感觉。跑 eval、看哪个维度掉分、哪个 case 失败、针对性改加 few-shot、加工具、改检索、收窄 prompt再跑 eval 看回归集回升且其他维度不降。A/B 上线前用离线 eval 加影子评估预测线上表现把感觉会好变成数据说会好。把 eval 分数和线上真实指标留存、人工满意度对齐逐步建立离线分与线上体验的相关性团队才会真正信任 eval。信任建立起来后迭代速度是指数级的因为每个人的改动都能立刻被客观量化不再靠口头争论。落到组织层面我建议把 eval 集和分数历史当一等公民资产来维护每次改动的 score diff 进 PRreview 时和代码一起看分数历史做成时间序列能一眼看出某次提交引入的漂移。当这套成为团队肌肉记忆Agent 的迭代就从谁嗓门大谁对变成数据说话这也才是评估体系最值钱的部分。终极目标就一句话让改变模型行为从玄学变成可测量、可回归、可协作的工程活动。评估体系本身也是要迭代打磨的产品不是一次性建完就扔那的基建。