LLM Evals Workflow Checklist：从工程视角拆解核心机制、边界与代价

为什么需要一套 LLM evals workflow checklist

很多团队在给 LLM 应用上 evals 时，第一反应是“用哪个框架”——LangSmith、MLflow、DeepEval 还是自建。但实际踩坑之后你会发现，工具选型只是最后一步。真正决定 eval 管线是否有效的是：你的问题定义是否清晰、指标选择是否匹配业务场景、数据构造是否覆盖了边界和失败模式。

这是一份面向工程团队的 LLM evals workflow checklist，不是通用指南，而是围绕“你已经有了一个 LLM 应用，现在需要判断它的质量”这个前提展开。

第一步：问题定义——你究竟要评估什么？

场景：一个客服摘要模型

假设你正在评估一个为客服对话生成摘要的 LLM。初步想法是计算 ROUGE-L 和 BERTScore，和人工标注对比。看起来合理，但实际运行两周后，团队发现 ROUGE 得分很高，但业务方抱怨摘要经常漏掉关键决策点（比如“已退款”或“需要升级工单”）。

这是典型的“指标与业务目标脱节”问题。ROUGE 衡量的是 n-gram 重叠，而业务需要的是事实完整性和决策可追溯性。

检查项：

• 你的评估目标是辅助模型迭代，还是作为上线准入门槛？
• 如果有多个业务维度（事实准确性、语气、结构完整性），你分别用什么指标衡量？
• 你是否区分了“模型行为”和“业务结果”？比如摘要够简洁但丢失了关键信息，二者是不同层级的质量问题。

失败点：定义模糊导致指标失效

最常见的问题是“使用语义相似度来评估摘要质量”。Semantic Similarity 可以衡量两个文本的含义一致性，但它无法区分“遗漏了关键事实”和“表达了不同但语义近似的观点”。如果业务需要“所有关键事实均被覆盖”，那你需要的不是相似度，而是 fact coverage 或者基于 JSON 的结构化验证。

第二步：操作步骤——搭建一次可重复的 eval run

1. 构造评估数据集

不要只用手写的十几个例子。一个策略：从生产日志中采样 200-500 条真实 query，然后人工标注“golden reference”。如果人工标注成本太高，可以用少量标注 + 弱监督扩展，但必须保证测试集是独立于训练集的。

检查项：

• 测试集是否覆盖了正常场景、边界场景（长文本、生僻词）、失败场景（用户输入不完整、格式异常）？
• 每一条测试输入是否有对应的“预期输出”？对于开放式任务，可以没有 single reference，但必须有“不可违反的条件”（例如“不得包含未出现在用户输入中的时间信息”）。

2. 选择并适配指标

常见组合：

• 精确匹配：适合分类任务。
• ROUGE / BLEU：适合文本生成，但注意它们对同义词和句式变化不敏感。
• 基于 LLM 的评估：使用 GPT-4 或 Claude 对输出打分。需要设计清晰的 prompt 和评分标准，否则 LLM judge 会引入自身偏好。
• 自定义规则：适合强约束场景，比如“输出必须包含 user_name 和 decision 两个 JSON 字段”。

检查项：

• 你选择的主指标是否和第一步定义的业务目标对齐？
• 是否添加了“次要指标”来检测副作用？比如摘要任务除了 ROUGE，还可以用“幻觉检测”（hallucination rate）作为一票否决指标。

3. 运行与记录

每次 eval run 必须记录：

• 模型版本 + 参数（temperature、top_p 等）
• 数据批次标识
• 所有指标的原始分数
• 失败案例（分数极低或违反约束的输出）

如果使用 LangSmith 或 MLflow，确保 metrics 的命名和版本是可追溯的。

失败点：只关注平均分，忽略分布

某次 eval 平均得分 0.85，但实际是 20% 的极端坏例子拉低了整体？还是 80% 的例子都在 0.95 以上？这两种情况的 avg 可能相同，但业务影响完全不同。检查项： 报告指标时，必须同时输出 P50、P90、P99 以及失败模式分布。

第三步：误区——四个高频踩坑点

误区 1：依赖单一指标

即使你用了“ROUGE + BERTScore + GPT 打分”多个指标，如果它们是相关度高的（比如 ROUGE-L 和 ROUGE-1 高度相关），实际并没有提供太多新信息。你需要选择正交的指标：一个衡量事实准确性，一个衡量结构，一个衡量用户偏好。

误区 2：测试集与训练集分布差异过大

一些团队直接从训练集拆出测试集，但训练集往往经过清洗和格式统一，而生产环境的输入更嘈杂。最终 eval 结果好看，上线后却崩盘。解决方案： 一定要构建一个独立的“生产镜像测试集”，尽量模拟真实流量分布。

误区 3：把人工评估当作 gold standard 却不做一致性校验

如果你依赖人工评估（比如给 3 个标注员打分），一定要计算 inter-annotator agreement (如 Cohen's Kappa)。如果只有 0.3，说明任务定义存在歧义，需要重新设计评估标准。

误区 4：忽略 eval 本身的代价

每次 eval run 都有计算成本和时间成本。如果你每天跑 100 个测试样本 × 10 个变体，调用云 API 的费用可能超过模型微调的费用。检查项： 定期清理无用 eval 缓存，使用采样策略（比如只测试 10% 的 outlier 样本）来平衡覆盖率和成本。

真实场景：一次失败的 eval 流程

团队 A 为客服摘要模型搭建了 eval pipeline，使用 ROUGE-L 和人工打分。结果：ROUGE-L 0.82，人工评分 4.2/5。上线两天后，客诉率飙升。分析发现：

• 人工评分样本集中在“无争议”场景；
• ROUGE-L 对“已退款”这类关键实体权重不足；
• 测试集里没有覆盖“用户包含脏话”或“客服切换语言”的案例。

修复方案：在测试集中加入 5% 的 dirty data（包含拼写错误、表情符号、多语言混用），并增加一条“关键实体覆盖度”的硬规则，任何摘要若遗漏了标记为“must_cover”的实体，直接判为失败。

替代方案：如果 eval 管线跑不起来怎么办？

如果你刚开始、算力有限，或者业务场景频繁变化，可以先不做全量 eval，改为“日志 + 抽检 + 规则监控”三步：

• 每条输出记录到日志，包含输入、输出、timestamp。
• 每天随机抽取 50 条，由 1 个工程师快速人工标注是否满足基本要求。
• 设置几条硬规则（如 JSON 格式校验、长度限制、敏感词检测），失败则触发告警。

这套轻量方案可以以较低成本发现问题，直到你的业务进入稳定期后再搭建完整 eval 管线。

总结

一份好的 LLM evals workflow checklist，不应该只是把框架步骤列出来。真正的价值在于：帮你识别每一步的目标、代价和失败模式。从问题定义出发，选择与业务对齐的指标，构建覆盖边界的测试集，然后避免常见误区。如果条件不允许，也可以从轻量方案起步。