2026-06-24

LLM 评估体系专栏 #1：从「凭感觉」到自动化 Eval 管道

为什么需要一个评估专栏？

做 AI 工程的人大概都有过这种体验：模型在 Benchmark 上跑分很好看，一上线就翻车。翻的不是大错，而是那种「说不清哪里不对但就是感觉不行」的衰退。

没有评估体系（Eval）的 LLM 应用，就像开一架没有仪表盘的飞机——你以为在平飞，其实在俯冲。40% 的组织在部署 LLM 后 90 天内会遭遇严重质量退化（AI Workflow Lab, 2026），这不是危言耸听，是缺乏系统化 Eval 的自然结果。

这个专栏的目标是逐步构建一套完整的 LLM 评估知识体系：从评估维度设计、离线/在线分工、LLM-as-Judge 最佳实践、回归测试与 CI 集成、评估数据版本管理，到生产环境中的持续监控与反馈闭环。一期一个主题，循序渐进。

本期主题：Eval 管道的基本框架

一个核心矛盾

LLM 应用和传统软件最大的区别在于：输出不可穷举，且没有标准答案。 一个传统的 CRUD API，你写 100 个测试用例覆盖了所有分支，基本就可以放心了。但 LLM 面对同一个 prompt，今天和明天的输出可能完全不同——甚至连模型自己都不知道会输出什么。

所以评估不是「做完一次就完事」的事，而是需要变成持续运行的自动化管道。

离线守门 + 在线感知

Eval 管道可以分解为两个互补的子系统：

离线评估（Offline Eval）：变更前的安检门。每次 prompt 修改或模型升级，自动在 Golden Dataset 上跑一遍，pass 才上线。

Anthropic 的经验是「先窄后宽」：从一个非常狭窄的领域（比如「回答简洁性」「文件编辑的正确率」）建 Eval，再逐步扩展到复杂行为。不要一开始就想评估模型的全部能力——你根本做不到。

在线评估（Online Eval）：生产环境中的持续感知。追踪分布漂移、事实一致性、用户体验、安全合规。

离线评估保证「你交出的东西没问题」，在线评估保证「它上线后确实没问题」。

多维指标矩阵

别只盯准确率。一个实用但常被忽略的原则：一个维度上的天花板，往往是另一个维度的地板。 比如你可以通过降低输出长度来显著降低幻觉率——但代价是回答太短，用户不满意。

一个健康的 Eval 体系应该覆盖这些维度：

每个维度设 SLO 阈值，超过阈值触发告警或自动回滚。

LLM-as-Judge 三条铁律

用 LLM 评估 LLM 是目前最主流也最容易踩坑的做法。三个来自实践的铁律：

① 用 pass/fail 而非打分
要求 Judge 模型输出 0-10 的评分，结果往往聚集在 7-9 之间，分辨力极差。改成「是否满足 X 条件」的二分判断，判准率显著提升。本质原因：评估一张椅子「稳不稳」远比评估它「有多稳」容易。

② 控制长度偏差
实测所有 LLM Judge 都偏好更长、更详细的回答。如果你的任务中简洁是美德（比如客服回答），长度偏差会扭曲你的整个评估体系。缓解方法：评估前对输出做长度归一化，或在 prompt 中明确「长度不纳入评估标准」。

③ 先推理再打分
要求 Judge 先输出思考链（CoT）再给出判断，而不是直接出 score。让评估过程可追溯、可审计——当人类 reviewer 发现误判时，可以直接在 CoT 中指出错误环节。

Takeaway

评估体系的本质不是追求完美指标，而是建立可持续的反馈闭环：

定义成功标准 → 自动化门禁 → 在线监控 → 真实案例反哺 → 更新标准

Anthropic 说得好：「Eval 迫使团队明确什么是成功——这个过程本身比任何具体指标都更有价值。」

下期预告：**#2 离线评估：Golden Dataset 的设计、维护与污染防御**——如何构造高质量评估集、防止 benchmark 泄露、以及数据集本身的版本管理。