面向非工程师的评估：判断AI工作流正在变好还是变差

我们经常看到这样一种情况：团队构建了一个AI工作流——可能用于起草内容、对客户支持请求分类或生成销售电子邮件。第一周运行良好，团队非常满意，于是全面推广。

三个月后，情况似乎不太对劲。输出质量好像下降了，客户开始投诉，销售代表也不再使用它。没人知道变化是什么时候发生的，也不知道原因。

原因几乎总是相同：没有人进行衡量。第一周表现良好的工作流可能逐渐退化，底层模型可能已经更换，提示词可能发生漂移，输入分布也可能改变。如果不进行衡量，直到用户投诉时你才会发现问题——到那时，信任已经受损。

解决办法是进行评估，即系统地衡量AI输出质量。评估通常被视为工程问题，但每个运行AI工作流的团队都需要它，而且无需编写代码也能掌握基本方法。

本文将介绍评估是什么、为什么重要，以及非工程师如何为任何AI工作流建立评估。

评估不是为了做表面文章。有效的评估会产生一项决策：发布、暂缓、回滚或调查。如果某个分数无法改变团队的行动，就应简化评估，直到它能够推动决策。

评估是什么（以及不是什么）

评估是一种方法：根据你控制的示例，系统衡量AI输出的质量。

评估包含以下组成部分：

• 数据集。 一组输入，即AI要处理的内容。
• 预期行为。 你希望AI如何处理这些输入。
• 评分方法。 如何衡量AI是否正确完成任务。
• 运行与报告。 处理数据集、为每项输出评分并汇总结果。

其目的在于用一种可重复的方法追问：“AI是否以我期望的质量完成了我要求的任务？”并在答案发生变化时及时发现。

评估并不是：

• 初次构建时的一次性测试。
• 感觉不对劲时才进行的抽查。
• 用户反馈（反馈有帮助，但具有滞后性、速度慢且存在偏差）。
• 凭感觉判断（“输出感觉没问题”）。

真正的评估按计划运行，使用明确的一组输入，并采用一致的评分方式。即使没人投诉，它也能为你提供信号。

为什么“工程师工具”不适合大多数团队

如果在Google上搜索“LLM evals”，会看到许多介绍Promptfoo、LangSmith、Braintrust和Helicone等工具的文章。它们都很出色，但其设计对象是在规模化交付LLM产品的工程师。

对于大多数运行AI工作流的营销、销售、运营和支持团队来说，这些工具过于复杂。你需要更简单的方案：无需学习整套工具，就能衡量自己的特定工作流。

好消息是，只需电子表格和一个LLM就可以做到。它达不到LangSmith的复杂程度，但足以发现大多数质量问题。

四种评估模式

常见的评估模式有四种，每种适合不同类型的工作流。

模式1：精确匹配

适用于只有一个正确答案的情况。

工作流示例：将客户支持工单分入8个类别。

数据集：50张工单及其正确类别。 评分：AI的答案与正确类别匹配得1分，不匹配得0分。 输出：正确率百分比。

这种模式非常适合分类、提取和简单的结构化输出。

模式2：参考答案比较

适用于存在已知优质答案可供比较的情况。

工作流示例：起草产品说明。

数据集：30个产品，以及你为其编写的“参考”说明。 评分：从准确性、语气和完整性等维度，判断AI说明与参考说明的接近程度。

可以人工评分（由人工阅读两者并给出1–5分），也可以使用LLM评判者（见下一种模式）。参考答案比较是内容工作流的黄金标准。

模式3：以LLM作为评判者

适用于输出形式可以多种多样，但质量可以判断的情况。

工作流示例：生成个性化销售电子邮件。

数据集：30份潜在客户资料。 评分：由LLM担任评判者，根据输入和输出，从具体程度、专业性、长度和语气匹配度等维度评分。

以LLM作为评判者非常强大，但需要精心设计提示词。常见模式如下：

你正在评估一封销售电子邮件的质量。请从以下维度评分：

1. 具体程度（1-5）：是否提及潜在客户的具体事实，而不是泛泛恭维？
2. 专业性（1-5）：语气是否像同行交流，而不是垃圾邮件？
3. 长度适当性（1-5）：是否简洁（40-80个英文单词）？
4. 语气匹配度（1-5）：是否符合我们的语气（直接、不使用流行术语）？

请为每个维度给出分数，并用一句话说明原因。

输出JSON：{"specificity": {"score": N, "reason": "..."}, ...}

潜在客户资料：[input]
待评估电子邮件：[output]

评判LLM能提供人工审核者难以达到的一致性：使用同一个评判模型、同一个提示词，并统一应用。但从未验证过的评判者，只是质量未知的第二意见，因此应认真进行一次校准：

1. 选取团队已经标注过的50个示例（通过/不通过，或采用你们的评分量表）。复用审核队列中的真实案例，不要虚构合成案例。
2. 让评判者处理相同的50个示例并计算一致率。 一致率高于约85%时，可将其用于常规筛查，同时保留人工抽样。若在约70%到85%之间，应阅读每一项分歧：问题几乎总是评分标准含糊，而不是评判者愚笨——收紧评分标准的措辞后重新运行。低于约70%时，评判者衡量的内容与你不同，不要据此自动化。
3. 不仅要看错误率，还要看错误方向。 放过不良输出的评判者很危险；把良好输出标为不合格只会带来麻烦。应据此设定阈值。
4. 每当更换评判模型、评判提示词或评分标准时，都要使用20–30个新示例重新校准——这三者中的任何一项变化，都会悄然改变一致率。

这些区间是我们建议采用的起始流程，并非自然定律；不可妥协的要求是：在评判者的分数用于任何门禁之前完成校准。

模式4：属性检查

适用于可以将“良好”表达为具体且可测试属性的情况。

工作流示例：为电商商店生成产品标题。

数据集：50个产品。 对每项输出检查以下属性：

• 长度为30–70个字符。
• 包含品牌名称。
• 至少包含一项产品的关键属性。
• 不使用禁用营销词（“amazing”“best”“revolutionary”）。

每项属性都是是/否测试。分数等于所有输出中通过属性检查的比例。

属性检查非常适合必须始终满足的结构化约束。它运行速度快，也能发现特定的漂移。

如何建立第一次评估

下面是一套适合非工程师的实用方案。

第1步：选择工作流

选择一个工作流，不要试图一次评估所有内容。选取你最担心其质量，或后果最重大的工作流。

例如：“按主题对入站客户支持工单进行分类的AI。”

第2步：构建数据集

建立一个包含20–50个代表性示例的列表，其中包括：

• 简单情况（明确属于类别A）。
• 困难情况（可能属于A，也可能属于B）。
• 边缘情况（无法明确归入任何类别）。
• 常见变体（用不同措辞表达同一意图）。

将其记录在电子表格或Google Sheet中：

这就是你的评估集。它不应频繁变化，因为它的作用是充当稳定的参考。

第3步：定义评分

对每个示例而言，什么样的答案算正确？务必具体。

对于分类：类别必须精确匹配。 对于内容：在2–4个具名维度上分别给出1–5分。 对于提取：逐个判断字段正确或错误。

写下评分标准，并始终遵循。

第4步：用数据集运行工作流

让AI工作流处理数据集中的每个示例，并把输出记录在新列中。

对于分类，可以使用Google Sheets的GPT集成等函数在电子表格中完成，也可以手动复制粘贴。

对于更复杂的工作流，可以把输入导入Promptfoo等工具，或每周运行一次批处理任务。

第5步：评分

对于精确匹配：添加一列“match”，预期值等于实际值时填1，否则填0。求和后即可得到准确率。

对于以LLM作为评判者：针对每项输出运行评判提示词，并记录分数。

对于属性检查：把每项属性作为独立测试运行，然后汇总。

最小可行评分卡

第一次评估应跟踪较少的维度，但每个维度都必须能推动具体行动。

评分卡应指定负责人和发布规则。“正确率低于90%时由产品负责人审核”比“跟踪正确率”更有约束力。

第6步：汇总

汇总表可以采用以下形式：

随着时间推移，这会呈现出质量变化轨迹。分数下降会触发调查。

第7步：设定计划

定期运行评估。对大多数工作流而言，每周一次完全足够。每次更改提示词或模型后，都应在部署前运行。

这是一个每周30分钟的习惯。设置一个重复日历时段，不要跳过。

本文链接的配套评分卡专为首次每周评估而设计。

添加发布门禁

当评估位于变更之前时，最能发挥价值。对于任何会影响客户、运营记录或团队决策的AI工作流，都应设置一个小型发布门禁：

1. 基线。 记录当前生产工作流的分数。
2. 候选版本。 使用相同评估集运行新的提示词、模型、工具或工作流步骤。
3. 比较。 候选版本必须保持安全性和回归分数，而且主要质量分数的降幅不得超过约定容差。
4. 决策。 发布、暂缓、修改或回滚，并记录原因。
5. 发布后检查。 上线后，用少量真实案例样本重新运行。

第一天就实现自动化并非必要。只要能持续阻止未经衡量的变更上线，使用指定审批人的电子表格就足够。

分数下降时怎么办

评估的目的就是发现质量衰退。发现后，应展开调查。

一种简单的调查方式如下：

第1步：找出失败案例。 具体哪里出错了？

第2步：寻找模式。 失败是否集中出现（输入相似），还是分散出现（输入类型不同）？

第3步：诊断。

• 集中出现 → 很可能存在特定弱点（提示词问题、知识缺失）。
• 分散出现 → 很可能是整体质量下降（模型变化、漂移）。

第4步：提出原因假设。

• 底层模型最近是否发生变化？查看提供商的变更日志。
• 提示词最近是否发生变化？回滚并测试。
• 输入分布是否发生变化？查看近期真实数据。
• 数据集是否已经过时？更新示例。

第5步：测试修复。 只做一项变更，然后重新运行评估。分数恢复了吗？

这种系统化方法优于慌乱和猜测。

持续建设数据集

初始数据集只是起点。可以通过以下方式持续改进：

添加真实失败案例。 当真实客户或用户案例产生不良输出时，把它加入评估集。它现在就是一个回归测试：如果这一特定问题再次发生，你会及时发现。

删除过时案例。 随着工作流演进，一些测试案例会失去相关性，应将其移除。

扩大覆盖范围。 如果评估集有20张“account-access”工单，却只有1张“billing”工单，说明评估过度偏向某一类别，应重新平衡。

发现边缘情况时及时添加。 包括新的客户投诉模式、新产品功能和新类别。

良好的评估数据集是动态的：它反映当前现实，而不是历史现实。

常见错误

以下几种做法会导致评估计划失败：

错误1：开始前先构建完美的评估。 包含50个示例和复杂评分的数据集令人望而生畏；包含10个示例和简单评分的数据集今天就能完成。先从小处开始，再持续迭代。

错误2：只评估顺利路径。 全是简单示例无法发现真实故障。应包括困难情况、边缘情况和已知曾经失败的情况。

错误3：评估集漂移。 每次工作流变化都更新评估集，会让分数失去意义。评估集应很少变化，工作流则可以更频繁地变化。目标是衡量工作流，而不是衡量评估本身。

错误4：盲目信任LLM评判者。 LLM评判者存在偏差，会过度重视长度、格式等表面特征。应定期依据人工判断校准评判者。如果你与评判者意见不一致，说明评判提示词需要改进。

错误5：只评分，不行动。 每周运行评估却从不根据数据行动，只是在做表面文章。评估的目的是发现并修复问题。如果分数下降无法触发调查，就是在浪费时间。

错误6：只评估一个维度。 “我的评估显示准确率达到95%！”——但响应质量可能变差，响应速度可能变慢，幻觉率也可能升高。应在重要之处跟踪多个维度。

有帮助但并非必需的工具

如果希望从电子表格升级，可以考虑以下易用选项：

Promptfoo。 开源工具，通过YAML配置，可在你的电脑或CI中运行，非常适合测试和比较提示词。

Braintrust。 提供美观界面的托管评估平台，价格较高，但功能强大。

LangSmith。 专门与LangChain工作流绑定；如果你使用该生态系统，它会很合适。

Helicone。 用于记录和分析LLM调用，也具备评估功能。

OpenAI Evals。 开源框架，更偏向开发人员。

对大多数非工程团队而言，电子表格加ChatGPT/Claude就足够。如果想升级，Promptfoo是最容易上手的“正式工具”。

为期4周的评估计划

对于从零开始的团队，可以采用以下现实可行的计划：

第1周：选择并定义。

• 选择一个工作流。
• 构建包含20个示例的数据集。
• 定义评分方式（精确匹配、LLM评判者或属性）。

第2周：建立首个基线。

• 运行评估并记录基线分数。
• 找出任何明显的失败。
• 暂时不要改动，只需观察。

第3周：迭代。

• 做一项你认为能提升质量的变更。
• 重新运行评估。
• 分数上升、下降还是不变？调查原因。

第4周：设定计划。

• 安排每周运行。
• 记录评估流程。
• 向团队说明分数的含义以及什么情况会触发行动。

4周后，你将拥有一套可用的评估。接下来可以扩大范围：将更多工作流纳入评估计划、深化数据集并完善评分方式。

文化转变

与其说评估需要技术转变，不如说更需要文化转变。习惯于因为AI工作流“看起来能用”就上线的团队，需要开始接受衡量。

这种转变包括：

愿意看到数字下降。 有时你满怀期待的变更会损害质量，评估会告诉你这一点。你必须愿意回滚。

投入校准。 在新评估的第一个月，应预留时间调整数据集、评分方式和提示词。这是一项投资。

养成“前后对比”的习惯。 AI工作流的任何非平凡变更，都要在上线前通过评估。最终这会成为一种本能。

坚守质量底线。 分数下降时，应修复或回滚。不能仅仅因为截止日期临近，就带着退化的质量发布。

这种文化转变是最难的部分。一旦建立起来，工具反而很容易解决。

一个工作流、二十个示例、每周半小时

评估决定了AI工作流能否长期受到信任，还是会在无人察觉的情况下逐渐滑向平庸。

开始时不需要工程师、机器学习专业知识或复杂工具。你只需要一个值得衡量的工作流、一个小型数据集、一种评分方法，以及每周半小时。

本周选择一个工作流，构建包含20个示例的评估，运行并查看结果，下周再运行一次。留意这一过程所建立的纪律。

6个月后，有评估的团队会拥有真正得到改进的AI工作流；没有评估的团队则会发现，自己的工作流看起来和6个月前一样——只不过质量更差。