8.0
热点
AI SCORE
技术实践2025-05-28 15:00
LLM评估完全手册：700+工程师经验总结
Hamel Husain#LLM Evals#质量评估#最佳实践
Editor brief · 编辑速览
汇总大规模工程师和PM在LLM评估实践中的常见问题和最佳实践。对构建AI应用质量评估体系很有参考价值。
这份文档汇总了 Shreya 和我在给 700+ 名工程师和 PM 讲授 AI Evals 时收到的最常见问题。警告：这些是关于在大多数情况下有效方案的尖锐观点。它们不是普遍真理。请自行判断。
如需引导式了解我们后续的 evals 工作，请使用 AI evals topic hub。
👉 想要深入学习 AI Evals？查看我们的 AI Evals 课程。这是一个实时小班课程，包含动手练习和办公时间答疑。这里提供了一个针对读者的 25% 折扣码。👈
如果你更喜欢听音频版本（由 AI 朗读），可以在这里播放。
如果你对产品级别的 LLM Evals（不是基础模型基准测试）完全陌生，请参阅这些文章：第 1 部分、第 2 部分和第 3 部分。否则，继续阅读。
迭代速度快 == 成功
案例研究：Lucy，一个真实房产 AI 助手
第 1 级：单元测试
第 2 级：人工评估与模型评估
第 3 级：A/B 测试
评估 RAG
Eval 系统释放免费超能力
微调
数据合成与策展
调试
问题：AI 团队淹没在数据中
第 1 步：找到首席领域专家
第 2 步：创建数据集
第 3 步：指导领域专家做出通过/失败的判断，并附带批评意见
第 5 步：迭代构建你的 LLM Judge
第 6 步：执行错误分析
第 7 步：创建更多专用的 LLM Judge（如需要）
错误分析如何持续揭示最高 ROI 的改进
为什么简单的数据查看器是你最重要的 AI 投资
如何赋能领域专家（不仅仅是工程师）来改进你的 AI
为什么合成数据比你想象的更有效
如何维护你的评估系统的可信度
为什么你的 AI 路线图应该计数实验，而不是功能
Trace（链路）是来自单个初始用户查询到最终响应的所有操作、消息、工具调用和数据检索的完整记录。它包括会话中所有智能体、工具和系统组件的每一步：多个用户消息、助手响应、检索的文档和中间工具交互。
术语说明：不同的可观测性供应商使用 trace 和 span 的不同定义。Alex Strick van Linschoten 的分析突出了这些差异（见下方截图）：
从错误分析开始，而不是基础设施。每当你做重大改动时，花 30 分钟手工审查 20-50 个 LLM 输出。使用一位理解你用户的领域专家作为质量决策者（"仁慈独裁者"）。
使用笔记本来审查 trace 并分析数据，或用像 Claude 或 Codex 这样的 AI 编码助手构建自己的自定义标注界面。无论哪种方式，你都可以写任意代码、可视化数据并快速迭代。下面的视频展示了在笔记本内部构建的一个简单标注界面。
重要的是要认识到，评估是开发过程的一部分，而不是一个独立的支出项，类似于调试是软件开发的一部分。
你应该始终在做错误分析。当你通过错误分析发现问题时，许多将是你会立即修复的直接 bug。这些修复不需要单独的评估基础设施，因为它们只是开发的一部分。
构建自动化评估器的决策归结为成本收益分析。如果你能用简单的断言或正则表达式检查捕获错误，成本最少，可能值得。但如果你需要对齐一个 LLM-as-judge 评估器，请考虑这个失败模式是否值得那笔投资。
在我们参与的项目中，我们在错误分析和评估上花费了 60-80% 的开发时间。预期你的大部分努力都将用于理解失败（即查看数据），而不是构建自动化检查。
谨慎对待优化 eval 通过率的做法。如果你正在通过 100% 的 eval，你可能没有充分地挑战你的系统。70% 的通过率可能表示一个更有意义的评估，实际上在压力测试你的应用。专注于能帮你捕获真实问题的 eval，而不是让你的指标看起来不错的那些。
会的。即使有完美的模型，你仍然需要验证它们在解决正确的问题。系统化的错误分析、特定领域的测试和监控的需求仍然很重要。
今天的 prompt 工程技巧可能会过时，但你仍然需要理解失败模式。此外，LLM 无法读取你的想法，研究表明人们需要观察 LLM 的行为才能正确地外化他们的需求。
关于这个辩题的深入视角，请参阅这两个观点："模型就是产品"与"模型不是产品"。
"模型就是产品"：
"模型不是产品"：
不要试图向你的团队推销"eval"。相反，向他们展示你查看数据时发现的内容。
从自己进行错误分析开始。查看 50 到 100 个真实用户对话，找到产品失败的最常见方式。用这些发现讲述一个数据故事。
向你的团队呈现：
将评估定位为开发的一部分，而不是可选的测试。保持一份你捕获的错误、你学到的东西、修复方案以及可能避免的影响的运行日志。每周或每月分享一次。"我们在用户看到问题前捕获了 47 个问题"这样的具体报告比关于 eval 的抽象宣传更容易显示价值。
这种方法建立信任。不要只是展示仪表板和指标；讲述你从数据中发现的故事。通过描述你的发现，你教会团队你在学到什么，提供即时价值。当你修复一个问题时，显示那个特定问题的错误率如何下降。很快，你的团队会看到进展并询问你是如何做到的。让结果而不是方法引导对话。
这类似于经典的机器学习项目，其中成果是推测性的，进展受到迭代实验的限制。在这种情况下，重要的是你分享每次实验的学习成果，以显示进展并鼓励投资。
错误分析是 eval 中最重要的活动。错误分析帮助你决定首先写什么 eval。它使你能够识别独特于你的应用和数据的失败模式。该过程涉及：
收集代表性的用户与 LLM 交互的 trace。如果你没有任何数据，可以生成合成数据来开始。
人工标注者（理想情况下是"仁慈独裁者"）审查并对 trace 编写开放式笔记，指出任何问题。这个过程类似于"日志记录"，改编自定性研究方法。开始时，建议关注 trace 中观察到的第一个失败，因为上游错误可能导致下游问题，尽管如果可行的话你也可以标记所有独立的失败。领域专家应该执行这一步。
将开放式笔记分类为"失败分类法"。换句话说，将类似的失败分组到不同的类别中。这是最重要的步骤。最后，计数每个类别中失败的数量。你可以用 LLM 来帮助这一步。
继续迭代更多的 trace，直到达到理论饱和，意味着新的 trace 似乎不会为你揭示新的失败模式或信息。根据经验，你应该至少审查 100 个 trace。我粗略的启发式是，如果 ~20 个 trace 没有出现新的类别，你可以停止（但开始时至少审查 100 个）。记住，目标是优先考虑实际发生最多的失败，而不是捕获每一个可能的失败（eval 不是免费的，所以我们需要务实）。
你应该经常重新审视这个过程。有高级的方法可以更有效地对数据进行采样，例如聚类、按用户反馈排序以及按高概率失败模式排序。随着时间推移，你会对在数据中寻找失败的位置产生"嗅觉"。
不要跳过错误分析。它能确保你制定的评估指标以应用的真实行为为依据，而不是采用适得其反的通用指标（大多数平台都会引导你使用这类指标）。有关错误分析如何发挥作用的示例，请参阅这段视频或这篇博客文章。
以下是我们的学员 Pawel Huryn 绘制的错误分析流程图，其中也展示了错误分析如何融入整个评估流程：
问：除了用户反馈之外，我该如何找出存在问题的追踪记录以供审查？
虽然用户反馈是聚焦问题追踪记录的一种好方法，但其他方法也同样有用。以下是三种可以互补的方法：
从随机抽样开始
最简单的方法是审查随机抽取的一组追踪记录。如果发现的问题很少，可以升级到压力测试：创建专门用于检验提示词约束的查询，观察 AI 是否遵循你的规则。
使用评估进行初步筛查
使用现有评估来找出存在问题的追踪记录和潜在问题。识别出这些问题后，就可以从错误分析开始，继续执行常规评估流程。
利用高效的抽样策略
如果需要更精细地发现追踪记录，可以使用异常值检测、基于指标的排序和分层抽样来寻找值得关注的追踪记录。即使通用指标不能直接衡量质量，也可以作为探索信号，用于识别值得审查的追踪记录。
问：我应该多长时间对生产系统重新执行一次错误分析？
进行重大变更时，应重新执行错误分析，例如新增功能、更新提示词、切换模型或修复重大缺陷。一个实用的经验法则是：将每个审查周期至少审查 100 条以上的新追踪记录设为目标。根据我们的观察，典型的审查周期为 2～4 周。有关如何有效抽样追踪记录，请参阅这篇常见问题解答。
在两次重大分析之间，每周审查 10～20 条追踪记录，重点关注异常值，例如异常冗长的对话、多次重试的会话，或被自动监控标记的追踪记录。根据系统稳定性和使用量增长情况调整频率。新系统需要每周进行分析，直到失败模式趋于稳定。成熟系统可能只需每月分析一次，除非使用模式发生变化。发生事故、用户投诉激增或指标漂移后，务必进行分析。使用规模扩大时会引入新的边界情况。
问：生成合成数据的最佳方法是什么？
一个常见错误是在没有结构的情况下提示 LLM“给我一些测试查询”，结果只会得到泛化且重复的输出。使用维度的结构化方法可以为测试 LLM 应用生成质量高得多的合成数据。
首先定义维度：用于描述用户查询不同方面的类别。每个维度都表示用户行为中的一种变化类型。例如：
对于食谱应用，维度可以包括饮食限制（纯素、无麸质、无限制）、菜系类型（意大利菜、亚洲菜、家常菜）和查询复杂度（简单请求、多步骤、边界情况）。
对于客户支持机器人，维度可以包括问题类型（账单、技术、一般问题）、客户情绪（沮丧、中立、开心）和先前上下文（新问题、后续问题、已解决）。
从失败假设入手。如果你对失败模式缺乏直觉，可以大量使用自己的应用，或者邀请朋友使用它。然后选择针对这些潜在失败的维度。
首先手动创建元组：亲手编写 20 个元组，每个元组都是从各个维度中分别选择一个值组成的具体组合。例如：（纯素、意大利菜、多步骤）。这项手动工作有助于你理解自己的问题空间。
通过两步生成法扩展规模：
生成结构化元组：让 LLM 创建更多类似（无麸质、亚洲菜、简单）的组合
将元组转换为查询：在另一个提示词中，将每个元组转换成自然语言
这种拆分方式可以避免措辞重复。（纯素、意大利菜、多步骤）这个元组可以转换为：“我需要一份不含乳制品的千层面食谱，并且可以提前一天准备好。”
生成方法
可以通过两种方式生成元组：
先做笛卡尔积再筛选：生成所有维度组合，然后使用 LLM 进行筛选。这种方式可以保证覆盖范围，包括边界情况。适用于大多数组合都有效的情况。
由 LLM 直接生成：让 LLM 直接生成元组。结果更贴近现实，但往往倾向于泛化输出，并会遗漏罕见场景。适用于许多维度组合无效的情况。
先修复显而易见的问题：不要为能够立即修复的问题生成合成数据。如果你的提示词没有提及饮食限制，应当修复提示词，而不是生成专门的测试查询。
对元组和提示词进行迭代后，通过实际系统运行这些合成查询，以捕获完整的追踪记录。抽取 100 条追踪记录进行错误分析。这个数量既能提供足够多的追踪记录，以便进行人工审查并识别失败模式，又不会多到难以处理。
问：是否存在合成数据不可靠的场景？
是的：合成数据可能产生误导或掩盖问题。有关在适当情况下生成合成数据的指导，请参阅“生成合成数据的最佳方法是什么？”
合成数据常见的失效场景包括：
复杂的领域特定内容：LLM 经常无法准确体现专业文档的结构、细微差别或特殊之处，例如法律文书、医疗记录和技术表单。如果没有真实示例，就会遗漏关键的边界情况。
复杂的领域特定内容：LLM 经常无法准确体现专业文档的结构、细微差别或特殊之处，例如法律文书、医疗记录和技术表单。如果没有真实示例，就会遗漏关键的边界情况。
低资源语言或方言：对于低资源语言或方言，由 LLM 生成的样本往往不符合实际情况。基于这些样本进行的评估无法反映真实表现。
低资源语言或方言：对于低资源语言或方言，由 LLM 生成的样本往往不符合实际情况。基于这些样本进行的评估无法反映真实表现。
无法验证时：如果由于领域复杂或缺乏真实基准而无法验证合成样本是否贴近现实，那么真实数据对于准确评估非常重要。
无法验证时：如果由于领域复杂或缺乏真实基准而无法验证合成样本是否贴近现实，那么真实数据对于准确评估非常重要。
高风险领域：在高风险领域（医疗、法律、应急响应）中，合成数据往往缺乏细微差别和边界情况。这些领域中的错误会造成严重后果，而且人工验证也很困难。
高风险领域：在高风险领域（医疗、法律、应急响应）中，合成数据往往缺乏细微差别和边界情况。这些领域中的错误会造成严重后果，而且人工验证也很困难。
代表性不足的用户群体：对于代表性不足的用户群体，LLM 可能会错误呈现其背景、价值观或面临的挑战。合成数据可能会强化 LLM 训练数据中已有的偏见。
代表性不足的用户群体：对于代表性不足的用户群体，LLM 可能会错误呈现其背景、价值观或面临的挑战。合成数据可能会强化 LLM 训练数据中已有的偏见。
问：当系统处理多种多样的用户查询时，我该如何开展评估？
复杂应用通常需要支持差异极大的查询模式，从“退货政策是什么？”到“比较各地区符合这些条件的产品价格趋势”。每种查询类型都会调用不同的系统能力，因此容易让人困惑，不知道该如何设计评估标准。
你只需要错误分析。你的评估策略应当从观察到的失败模式（例如错误分析）中产生，而不是由预先设定的查询分类决定。与其创建一个庞大的评估矩阵来覆盖你能想到的所有查询类型，不如让系统的实际行为决定你应当将评估工作投入到哪里。
在错误分析过程中，你很可能会发现某些查询类别具有共同的失败模式。例如，所有需要时间推理的查询都可能表现不佳，无论它们是简单查找还是复杂聚合。同样，需要组合多个来源信息的查询也可能以一致的方式失败。错误分析中发现的这些模式应当决定你的评估优先级。查询类别或许确实是一种合适的失败分组方式，但只有分析数据之后才能确定。
如需查看基础错误分析的实际示例，请参阅这段视频。
问：如何高效地抽样生产环境中的追踪记录以供审查？
有很多方法可以抽样生产环境中的追踪记录以供审查。以下是一些常见方法。
上表按照从探索性最强到针对性最强的顺序排列了各种抽样方法。刚开始时，应优先对数据进行探索。随着了解逐渐加深，可以开始更多地依赖信号来选择追踪记录。各种方法的适当组合取决于你的目标，需要通过实验来确定。
每个批次都要保留一些随机轨迹。这样你就有机会发现当前信号尚未描述的故障模式。
我们的评估闪卡系列中有一张闪卡直观展示了这些方法。
我们可以借鉴机器学习中一种名为主动学习（active learning）的技术，对生产环境中的轨迹进行采样。在主动学习中，系统会请人们标注那些对系统下一次更新最有帮助的数据点。
在 Shreya Shankar 的演示中，Claude Code 会对轨迹进行聚类，并从每个聚类中选择示例供人审查。一个 monitor 命令会监视 annotations.json 中是否出现新标签。当新标签到来时，AI 智能体会更新故障分类体系，并寻找类似案例或其他故障。
在上面的视频中，主动学习被用于错误分析，以发现需要审查的新案例。不过，这种方法可以应用于工作流中任何需要标注数据的环节。
👉 想进一步了解 AI 评估吗？欢迎查看我们的 AI 评估课程。这是一门实时组班课程，包含动手练习和答疑时间。这里为读者提供一个八折优惠码。👈
工程师通常认为，李克特量表（1～5 分评分）比二元评估能提供更多信息，从而可以跟踪渐进式改进。然而在实践中，这种额外的复杂性往往带来的问题多于它所解决的问题。
二元评估会迫使人们进行更清晰的思考，并给出更一致的标签。李克特量表会引入重大挑战：相邻分值之间的差异（例如 3 分与 4 分）具有主观性，不同标注者的判断也不一致；检测统计差异需要更大的样本量；而且标注者为了避免作出困难的决定，往往会默认选择中间值。
提供二元选项会迫使人们作出决定，而不是用中间值掩盖不确定性。在错误分析过程中，二元决策也能更快完成——你不必浪费时间争论某个结果究竟应该是 3 分还是 4 分。
若要跟踪渐进式改进，可以考虑使用各自独立的二元检查来衡量具体的子项，而不是使用评分量表。例如，与其对事实准确性进行 1～5 分评分，不如将“包含 5 个预期事实中的 4 个”拆分为单独的二元检查。这样既能保留衡量进展的能力，又能维持清晰、客观的标准。
先从二元标签开始，理解“差”是什么样子。数值标签属于进阶方法，通常没有必要。
通常不应该。评估驱动开发（在实现功能之前编写评估器）听起来很有吸引力，但它带来的问题往往多于解决的问题。传统软件的故障模式通常可以预测，而 LLM 可能发生故障的范围却几乎是无限的。你无法预知什么地方会出问题。
更好的方法是从错误分析开始。针对你实际发现的错误编写评估器，而不是针对想象中的错误。这样既能避免因为不知道该评估什么而受阻，也能防止把精力浪费在对系统实际质量毫无影响的指标上。
例外情况：对于成功标准十分明确的特定约束，评估驱动开发可能有效。如果你要添加“绝不提及竞争对手”这一要求，那么提前编写相应的评估器可能是合理的。
最重要的是，在实现评估之前，始终进行成本收益分析。要思考这种故障模式是否值得投入相应的资源。错误分析能够揭示哪些故障对用户真正重要。
应将自动化评估器集中用于那些在修正提示词后仍然存在的故障。许多团队发现，他们的 LLM 没有满足一些从未被明确说明的偏好，例如回答要简短、使用特定格式或进行分步推理。在构建复杂的评估基础设施之前，先修正这些显而易见的缺口。
需要考虑不同类型评估器之间的成本层级。简单断言和基于参考答案的检查（与已知正确答案进行比较）构建与维护成本较低。LLM-as-Judge 评估器则需要 100 个以上已标注的示例、持续的每周维护，以及开发人员、产品经理和领域专家之间的协调。这种成本差异应当影响你的评估策略。
只为那些需要反复迭代的问题构建昂贵的评估器。由于 LLM-as-Judge 会带来大量额外开销，应将其留给持续存在的泛化故障，而不是那些能够轻松修复的问题。尽可能从低成本、基于代码的检查开始，例如正则表达式模式、结构验证或执行测试。只有对于无法通过简单规则捕捉的主观质量，才使用复杂的评估方法。
不应该。通用评估既浪费时间，又会制造虚假的信心。（除非你用它们来进行探索。）
一位讲师指出：
“使用这些预制评估，你得到的结果只是：你根本不知道它们实际做了什么。最好的情况下，它们浪费你的时间；最坏的情况下，它们会制造一种毫无依据的信心假象。”1
通用评估指标随处可见。评估库中包含有用性、连贯性、质量等评分，并承诺让评估变得简单。这些指标衡量的是一些抽象品质，而这些品质可能与你的用例无关。在这些指标上得分良好，并不意味着你的系统能够正常工作。
相反，你应该进行错误分析以理解故障。根据真实问题定义二元故障模式。为这些故障创建自定义评估器，并依据人类判断对其进行验证。实际上，这就是整个评估流程。
经验丰富的从业者可能仍会使用这些指标，只不过使用方式可能与你预想的不同。正如 Picasso 所说：“像专业人士一样学习规则，这样你就能像艺术家一样打破规则。”一旦理解了通用指标为什么不适合作为评估，你就可以将它们重新用作探索工具，以寻找值得关注的轨迹（将在下一个常见问题中说明）。
在大多数 AI 应用中，BERTScore、ROUGE、余弦相似度等通用指标并不适合用于评估 LLM 输出。相反，我们建议使用错误分析