LLM Evals Playbook 是怎么工作的？我用一条真实链路把它讲清楚

一条真实评测链路

上周我在整理一个客服问答 Agent 的回归测试，遇到最头疼的问题是：每次模型微调后，怎么快速知道哪些地方变好了、哪些地方反而变差了？

传统的单元测试不适用——LLM 输出是自然语言，没有固定的断言值。翻了一圈工具，最终选择了 LLM Evals Playbook 的思路。它不是一本 PDF，而是一套可执行的评测框架，核心流程是：定义评测标准 → 生成测试数据集 → 运行评估 → 分析结果并迭代。

下面是我跑通的第一条完整链路，每一步都有对应的代码和配置文件。

第一步：定义评测标准

评测必须从业务出发。我的场景是客服问答，所以定义了三个维度：

• 答案准确性：回答是否基于提供的知识库，不 hallucinate。
• 完整性：是否覆盖用户问题的所有子问题。
• 语气合规：是否保持友好、不推卸责任。

每个维度用 1-5 分打分，并附上评判标准说明。Playbook 要求这些标准必须可操作，比如“准确性”不能只说“正确”，而要写成“答案中每一条信息都必须能在知识库中找到对应原文”。

这里最容易犯的错误是标准过于模糊。我第一版写的是“回答应该准确”，结果不同评估员打出来的分数方差很大。后来改为“答案中若出现知识库中没有的实体或数据，扣 2 分”，一致性才上来。

第二步：生成测试数据集

Playbook 建议数据集包含三类样本：正常问题、边缘问题（如缺上下文）、对抗问题（如诱导模型输出不当内容）。

我用自己业务中的真实用户日志生成了 50 条正常问题，然后手动构造了 20 条边缘和 10 条对抗问题。构造对抗问题时要小心——不要直接拷网上的 prompt injection 模板，那往往脱离你的实际业务场景。

一个关键失败点：数据集和评测标准之间必须对齐。如果你的标准要求“不 hallucinate”，但数据集里大部分问题都是简单查询，模型本来就不会胡说，那评测结果就缺乏区分度。正确做法是先跑一轮小样本，看模型在哪里容易出错，据此补充数据集。

第三步：运行评估

我用 LangChain 的 Evaluator 框架对接了 Playbook。每个测试样本的评估过程是：先让被评测的 Agent 回答问题，然后用一个 Evaluator LLM（比如 GPT-4o）根据预设标准打分。

评分必须附带理由，不能只给分数。例如：“准确性 4 分：回答中提到了价格 199 元，但知识库中是 1999 元，扣 1 分。完整性 5 分：覆盖了价格、货期、售后三个子问题。” 这样后续分析时能精确定位缺陷。

第四步：分析结果并迭代

评估完成后，我的输出是一个 CSV 表格，每行是样本 + 各维度分数 + 理由。分析时重点看：

• 哪些维度分数普遍低：如果完整性平均只有 2.5 分，说明模型经常遗漏信息。
• 哪些样本分数波动大：评估员之间或样本之间的差异，往往指向标准不清晰。

我第一次跑出来的结果：准确性 4.2，完整性 3.0，语气 4.8。完整性低的原因是模型只回答了用户显式问的问题，没有主动提供关联信息（比如用户问“什么时候发货”，模型回答了发货时间，但没有连带说明物流查询方式）。于是我在 prompt 里加了“如果用户问题涉及订单，主动补充订单号查询物流的步骤”。第二轮评测完整性提升到 4.5。

最容易失败的地方与错误理解

Playbook 最大的陷阱是数据集和标准脱节。很多人照着模板写了几条标准，再从 HuggingFace 随便拉个数据集就跑评测，结果分数很好看但实际不反映业务问题。正确做法是：标准和数据集必须来自同一业务场景，并且先做小规模验证。

另一个常见错误是把评测当成一次性验收。Playbook 的价值在于持续回归：每次模型更新、prompt 调整后都要重新跑，形成“评测 -> 分析 -> 修复 -> 再评测”循环。如果只跑一次就丢在那里，那本质上就是没有评测。

如果你现在就要落地，第一步应该怎么做

1. 选择一个具体的业务场景（比如客服问答、代码生成、摘要）。不要试图覆盖所有能力。
2. 定义 2-3 个可操作的评测维度，每个维度写清楚扣分条件。
3. 收集 10 条真实样本，手工跑一遍：你亲手用标准打分，看标准是否清晰，数据集是否有区分度。这一步不花超过 1 小时。
4. 根据手工跑的结果调整标准，然后扩展到 50-100 条样本。
5. 接入自动化框架（LangChain、DeepEval 等），开始循环。

下一步去哪里系统化学习

如果想把评测体系搭建得更完整，或者想了解如何在 Agent 工程中系统整合 Evals，可以进一步阅读更系统的原创付费文章和 AI 编程进阶课程。