AI 评测：你需要知道的一切
这份文件整理了我和Shreya在期间收到的最常见问题教学5000+工程师和项目经理的AI评估。警告：这些都是对大多数情况下有效方法的尖锐看法。
它们并非普遍真理。请用你的判断。
如何使用这份常见问题解答
浏览你感兴趣的问题，或选择下面的指南，沿着常见问题解答和相关文章进行精心整理的阅读路径。
| 你在哪儿？ | 这听起来像我 |
|---|---|
| 我刚接触评估 | 我听说过这个词，但不确定评估具体包括哪些内容，或者我是否需要评估。 |
| 我不知道该测试什么 | 我正在开发一个人工智能产品，但我还没弄清楚该衡量哪些失败，或者什么样的良好性能应该是什么样子。 |
| 我不信任我的评估分数 | 我们有评估，但分数与我们对输出的判断不符，或者测试通过了，用户仍然遇到问题。 |
| 我的产品感觉太难评估了 | 我们的输出是主观的、冗长的，或者涉及许多步骤。即使是有知识的人，也很难判断自己是否正确。 |
| 评估耗费太多时间和金钱 | 我们花了太多精力去审查输出、维护测试或运行评估器。 |
所有问题
按章节浏览所有问题。
- 入门与基础
- 问：什么是AI评估？
- 问：什么是痕迹？
- 问：什么是最小可行评估设置？
- 问：我应该将开发预算中分配多少用于评估？
- 问：鉴于人工智能变化如此之快，现有的评估方法在5到10年后还会有意义吗？
- 问：我该如何向团队说明投资评估的理由？
- 错误分析与数据收集
- 问：为什么“误差分析”在人工智能评估中如此重要？它是如何进行的？
- 问：在注释数据之前，我需要参考答案或评分标准吗？
- 问：我应该记录一些不是模型问题的问题吗？
- 问：评估需要多少个示例？
- 问：除了用户反馈外，我该如何发现有问题的痕迹供审查？
- 问：我应该多久重新运行一次生产系统的错误分析？
- 问：当我的“黄金”评估数据集变得陈旧时，我该怎么办？
- 问：生成合成数据的最佳方法是什么？
- 问：有没有合成数据可能不可靠的情景？
- 问：当痕迹包含敏感数据时，我该如何进行评估？
- 问：当我的系统处理多样化的用户查询时，我该如何进行评估？
- 问：我如何高效采样生产痕迹以便审查？
- 评估设计与方法论
- 问：为什么你推荐采用二元（通过/不通过）评估，而不是1-5分（李克特量表）？
- 问：我如何将我的评估合并成一个单一的指标？
- 问：我应该实践以评估为驱动的开发吗？
- 问：我应该为我发现的每个失败模式都建自动化评估器吗？
- 问：我应该使用什么模型或大型语言模型来构建自动化评估？
- 问：我可以用Jev进行评估吗？
- 问：我如何判断我的自动评估是否值得信赖？
- 问：当我无法让我的LLM评委同意人类评审的观点时，我该怎么办？
- 问：我应该使用“现成型”评估指标吗？
- 问：相似度指标（BERTScore、ROUGE等）对评估大型语言模型输出有用吗？
- 问：我可以同时使用同一个模型进行主要任务和评估吗？
- 问：我应该给LLM法官多少背景信息？
- 问：我们如何评估模型表达不确定性或“知道它不知道什么”的能力？
- 人工注释与流程
- 问：应该有多少人为我的LLM输出做注释？
- 问：我怎样才能让AI输出更容易被人们评估？
- 问：产品经理和工程师应该在错误分析上合作吗？怎么做？
- 问：如果我不是领域专家，我能帮忙做评估吗？
- 问：我应该把注释和标签外包给第三方吗？
- 问：如何审查一条非常大的痕迹？
- 问：哪些评估部分可以用大型语言模型自动化？
- 问：我是否应该停止手动写提示，转而使用自动化工具？
- 工具与基础设施
- 问：我应该自己做注释工具，还是用现成的工具？
- 问：什么样的定制界面适合审查LLM输出？
- 问：我应该准备自己填补哪些评估工具的空白？
- 问：内部评估平台应在各团队间统一哪些标准？
- 问：你最喜欢的评估供应商是谁？
- 问：我应该如何更新和管理提示词？
- 问：系统提示符里应该写哪些，用户提示词应该写哪些？
- 生产与部署
- 问：评估在CI/CD与监测生产中有何不同？
- 问：护栏和评估员有什么区别？
- 问：我的评估员也可以自动使用修复或没错生产中的产出？
- 问：我应该花多少时间在模型选择上？
- 领域特定应用
- 问：RAG已经死了吗？
- 问：我应该如何评估编码代理？
- 问：我应该如何评估我的RAG系统？
- 问：我如何为文档处理任务选择合适的区块大小？
- 问：我如何调试多回合对话追踪？
- 问：如何评估有人工交接的会话？
- 问：我如何评估复杂的多步骤工作流程？
- 问：我如何评估代理性工作流程？
入门与基础
问：什么是AI评估？
AI评估是测试，告诉你AI系统是否达到了你的期望。当产品偏离用户需求或业务目标时，它们会给团队反馈。他们发现的失败也会成为你用来改进系统的数据。
更正式地说，评估是对质量的系统性测量。每次评估都会检查相关实例中的一个行为，并返回评分或结构化评价。大多数人工智能产品需要多次评估，因为它们可能以不同方式失败。
当你听到“评估”这个词时，通常指两种情况之一：模型基准或产品评估。
模型基准测试
模型基准比较通用模型在共享任务上的表现。模型提供者在发布新模型时会发布这些基准测试结果。常见例子包括GPQA钻石对于研究生级别的科学推理，终端工作台对于在命令行环境中执行复杂工作的代理，MMLU涵盖广泛主题的知识与推理。
这些评分可以帮助你选择一个有前景的模型作为起点。要评估你自己任务的质量，你需要产品评估，接下来我们将讨论。
产品评估
产品评估衡量你的具体AI产品是否达到了你的期望。它们将你对良好产品体验的判断转化为你可以追踪的指标。产品评估涵盖了产品的所有组成部分，包括模型、提示、检索、工具和应用代码。
这种评估形式专注于捕捉对用户和业务重要的失败。
考虑一个订单取消代理。其产品评估可能会检查是否选中了正确的订单，并等待取消工具成功后才通知用户订单已被取消。在GPQA Diamond或Terminal-Bench上获得高分对此信息帮助不大，因为这些基准无法访问你的系统。
你可以使用多种机制来实现产品评估，包括代码断言、人工审核、LLM评审和在线实验。正确的方法取决于所测量的失效类型，相关内容将有更详细的讨论在本系列中.
在其他部分AI评估常见问题解答我们专注于产品评估。它从分析痕迹开始，发现真实的失效模式。然后我们将重要的失效转化为有针对性的评估，并利用结果指导改进。
最后，重新运行评估告诉我们系统是否有所改进。
评估从哪里开始
如果你对产品专属评估完全陌生，可以参考这些帖子：
| 指南 | 内容涵盖 | |
|---|---|---|
| 第一部分:你的AI产品需要评估 | 构建一个领域特定的评估系统，包含范围测试、痕迹审查、人类评估和实验。 | |
| 第二部分:使用LLM作为评审进行评估：完整指南 | 捕捉领域专家的判断，用大型语言模型（LLM）评判自动化，并对该评判进行人工标签验证。 | |
| 第三部分:快速改进人工智能产品的实地指南 | 利用错误分析、真实数据和可信的评估来维持持续的产品改进循环。 |
问：什么是痕迹？
追踪是从单次初始用户查询到最终响应的所有操作、消息、工具调用和数据检索的完整记录。它涵盖会话中所有代理、工具和系统组件的每一步：多条用户消息、助手响应、检索的文档以及中间工具交互。
术语说明：不同的可观测性厂商对迹线和范围的定义各不相同。亚历克斯·斯特里克·范·林斯霍滕的分析突出这些差异（截图如下）：
问：什么是最小可行评估设置？
从错误分析开始，而不是基础设施。每当你做出重大修改时，花30分钟手动审查20-50个LLM输出。请一位了解你用户的领域专家作为你的质量决策者（“仁慈的独裁者”）。
用笔记本用于审查痕迹和分析数据，或者用像Claude或Codex这样的AI编码助手构建自定义注释接口。无论哪种方式，你都可以编写任意代码，可视化数据，并快速迭代。
该视频下面展示了一个内置在笔记本内部的简单注释界面。
问：我应该将开发预算中分配多少用于评估？
重要的是要认识到，评估是开发过程的一部分，而不是一个独立的项目，就像调试是软件开发的一部分一样。
你应该一直做误差分析.当你通过错误分析发现问题时，很多都是直接的bug，你可以立刻修复。这些修复不需要单独的评估架构，因为它们只是开发的一部分。
构建自动评估器的决定归结于成本效益分析。如果你能通过简单的断言或正则表达式检查发现错误，成本很低，且可能值得。但如果你需要让一个LLM作为评判的评估者对齐，考虑失败模式是否值得投入这笔投资。
在我们参与的项目中，我们开发时间中有60-80%的时间用于错误分析和评估.预计你大部分精力都用来理解故障（即查看数据），而不是构建自动化检查。
Be对高评估通过率进行优化持谨慎态度.如果你的评估100%通过，说明你对系统的挑战还不够。70%的通过率可能表明评估更有意义，实际上是在对你的申请进行压力测试。
重点关注那些帮助你发现真实问题的评估，而不是那些让你的指标看起来更好的评估。
问：鉴于人工智能变化如此之快，现有的评估方法在5到10年后还会有意义吗？
是的。即使模型完美，你仍然需要验证它们解决的是正确的问题。系统性误差分析、领域特定测试和监控的需求依然很重要。
如今的提示工程技巧可能会过时，但你仍然需要理解失效模式。此外，大型语言模型无法读心，且研究表明人们需要观察LLM的行为，才能正确地将需求外部化。
想深入了解这场辩论，请参见以下两种观点：“模型就是产品”对抗“模型不是产品”.
问：我该如何向团队说明投资评估的理由？
不要试图用“评估”来推销你的团队。相反，向他们展示你在查看数据时发现的内容。
首先，自己做错误分析。查看50到100条真实用户对话，找出产品最常见的失败方式。利用这些发现用数据讲述故事。
为你的团队介绍：
- 以下是你发现的主要失败模式列表。
- 显示高影响错误发生频率的指标。
- 用户与产品的互动方式令人惊讶。
- 关于你发现并修复的bug报告，标题是“防止生产问题”。
框架评估是开发的一部分，而非可选测试。记录你发现的错误、学到的知识、修复方法以及可能避免的影响。每周或每月分享。像“我们在用户看到之前发现了47个问题”这样的具体报告，比起抽象的评估推介更容易看清价值。
这种方法能建立信任。不仅仅展示仪表盘和指标;讲述你在数据中发现了什么的故事。通过讲述你的发现，你教会团队你所学到的内容，立即带来价值。
当你修复一个问题时，展示该问题的错误率如何下降。很快，你的团队会看到进展，并询问你是如何做到的。让结果而非方法引领对话。
这类似于经典的机器学习项目，结果是推测性的，进展受限于实验迭代.在这种情况下，分享每次实验的经验，展示进展并鼓励投资非常重要。
错误分析与数据收集
问：为什么“误差分析”在人工智能评估中如此重要？它是如何进行的？
误差分析为评估中最重要的活动.错误分析帮助你决定首先要编写哪些评估。它让你识别出适用于你的应用和数据的独特故障模式。该过程包括：
1. 创建数据集
收集用户与LLM交互的代表性痕迹。如果你没有任何数据，可以生成合成数据来开始。
2. 开放编码
人类注释者（理想情况下是仁慈的独裁者）会审查并撰写关于痕迹的开放式笔记，记录任何问题。这一过程类似于“日志记录”，并借鉴了定性研究方法。
在审核代理的建议之前，至少要自己注释30条痕迹。开始时，建议重点记录轨迹中观察到的第一个失败，因为上游错误可能导致下游问题，尽管如果可行，也可以标记所有独立的失败。
A领域专家应该正在执行这一步。
3. 轴向编码
将开放式笔记分类为“失效分类法”。换句话说，将相似的失败归入不同的类别。轴向编码是最重要的步骤。最后，统计每个类别的失败数量。
你可以使用大型语言模型（LLM）来辅助这一步。
4. 迭代精炼
让你的代理对数据进行聚类，并选择多样化的初始样本。在你完成前30个注释后，让它在剩余的痕迹中搜索你描述的可能失败实例。接受或拒绝它的建议，并不断迭代直到达到目标理论饱和这意味着新的评测不再揭示失败模式或改变现有的失败模式。
大约100条多样化的痕迹工作池是这种人机-代理循环的有效护栏。代理可以将你的注意力集中在最有信息量的痕迹上，这样你就不必再依次阅读全部100条。
查看每种评估需要多少示例才能完整分解。
你应该经常回顾这个过程。有进阶的方法可以更高效的采样数据比如聚类、按用户反馈排序，以及按高概率故障模式排序。随着时间推移，你会逐渐形成一个“嗅觉”，识别数据中哪里有故障。
不要跳过错误分析。它确保你开发的评估指标有真实应用行为的支持，而不是那些适得其反的通用指标（大多数平台都会建议你使用）。
关于错误分析如何有用的示例，请参见本视频，或者这个博客文章.
这是我们一位学生对误差分析过程的可视化，保维尔·胡林- 包括其在整体评估过程中的作用：
问：在注释数据之前，我需要参考答案或评分标准吗？
不行。在复习例题前先写评分标准可能会妨碍学习。
让我们先来解释一下定义：
- 参考答案是正确答案的一个例子。
- 评分标准是一套用来评判回复的标准，比如是否符合退款政策。
两者都有帮助，但把最初的期望当作起点，然后再修正。
通常最好等你先看完一些例子再制定详细的评分标准。评审者可能会过于专注于检查每一项，而忽视评分标准之外的问题。给评审者空间去发现你未曾预料到的问题非常重要。
这种你认为好的标准的变化被称为“标准漂移”.
举个例子，假设你有一个支持代理负责退款，并且根据你的政策将退款升级给真人。你可能要看几次互动后才意识到这个流程对用户来说很令人沮丧。
不要低估你在查看示例时会出现的标准漂移程度！
我们推荐使用误差分析系统地复习例子，决定哪些问题属于评分标准。这包括写开放式笔记说明哪些问题看起来不对，然后将相似笔记归类，看看哪些问题反复出现。
请参见此文现场演示做个攻略。
做完错误分析后，你可以根据用户和应用行为写出更好的评分标准。你应该这样做偶尔做错误分析，确保你的评分标准是最新的。
问：我应该记录一些不是模型问题的问题吗？
是的。在审查交互时，写下任何让产品变得不那么有用的地方。这包括与模型无关的缺失或故障功能。此外，不要关注错误发生的原因，因为这应该是在你优先确定哪些问题后才会发现。
例如，客服可能会告诉客户订单已发货，但不提供追踪链接。即使你的AI无法获取追踪链接，也要记录下这个问题。建立评估的前提是识别并优先解决哪些问题误差分析.其中一些问题可能是工程或设计上的不需要虽然是自动评估器，但它们仍然很重要需要修复！
最后，我们发现推迟根本原因分析，专注于问题，可以在查看更多数据的同时写出更高质量的注释。
问：评估需要多少个示例？
构建评估是一个流程，每个阶段需要不同的数据量。我们下面描述这些阶段：
| 舞台 | 该怎么办 |
|---|---|
| 1. 审核申请 | 读取跟踪并记录应用失败的方式。这个过程叫做错误发现.从100条不同的痕迹开始，自己至少做30条注释。 |
| 2. 创建并验证评估者 | 在两种评估者类型中选择。使用基于代码的评估当一个客观规则能够识别失败时。为每个条件和重要边缘情况包含通过和失败示例。使用LLM 评审当故障需要人工判断时。为每种失效模式标注100到200个例子。 |
| 3. 构建可重复的评估集 | 收集代表重要工作流程和已确认失败的示例。更改应用时运行该集合。这些集合通常会增加到100个或更多实例。 |
第一阶段：检查线路以找出故障
追踪是对你应用中一个用户会话的完整记录。请请编码代理帮你采样初始池，以覆盖不同的用户和工作流程。我们的评估插件可以帮助采样并为你的痕迹构建注释界面。
自己至少复习30条线索
我们建议用一种称为错误发现在让客服提出失败建议之前，先先了解自己。用自由文本记录任何从用户角度看有问题的地方。这些例子能让客服获得你的判断力的具体记录。
请保留这份第一遍手册。如果客服太早就开始提出问题，它的猜测会影响你的判断。你可能会错过依赖产品语境或你对良好用户体验定义的失败。
经过30次追踪后，请经纪人在剩余的样本池中搜索类似的例子。自己审查每一个建议。接受或拒绝每一个，并在中介误解你的条件时纠正他。
何时停止
持续进行，直到新的痕迹不再揭示失效模式或改变现有模式。定性研究者称之为理论饱和.我们建议至少复习100条痕迹。在学习阶段，继续阅读超过100条。
如果你想现场观看整个过程，请观看实时攻略.视频展示了Shreya Shankar如何利用特工快速审查痕迹，同时由人类负责失败标准。
本次审查产生失败分类法，即列出你的应用失败的具体方式。利用该分类法决定构建哪些评估者。
第二阶段：创建并验证评估员
为每个重要的失败模式选择一个评估者。评估者类型决定了你需要多少个带标签的示例。基于代码的评估适用于客观规则。LLM 评判者用于需要人工判断的失败。
基于代码的评估需要覆盖
当确定性规则能识别失败时，使用基于代码的评估。例如检查 JSON 是否解析，或工具调用是否使用正确的参数。
示例数量取决于检查涵盖的场景。至少，包含对每个条件都应通过和失败的例子。添加你在错误发现过程中发现的重要边缘案例。一个只有一条规则的检查可能只需要少数通过和少数失败的例子。
LLM评委需要有标签的例子
当失败需要主观或特定领域判断时，使用LLM裁判。计划为每个故障模式标记100到200个示例。当错误发现的标记痕迹与故障模式匹配时重复使用，然后收集更多，直到达到该范围。
标签应来自可信的领域专家并包含足够的通过和不通过示例来评估这两个类别。
将这些示例分为训练集、开发集和测试集。在提示中可能出现的列车示例中占10%到20%。在完善评审时，开发题用40%到45%。剩余40%留作最后一次测试。
如果可能，开发集和测试集中包含30到50个通过例题和30到50个失败例题。
该验证指南解释了整个过程。那法官验证抽认卡也是很好的视觉参考。
验证评估者后，整理出你将在开发过程中反复运行的示例。
第三阶段：构建可重复评估集
从错误发现中的示例开始，这些示例能捕捉重要的故障模式。找到已确认的故障时添加。
专门构建的评估集通常会增加到100个或更多样本。覆盖度决定了最终的规模。每个重要的工作流程和已知的失败都应被表示，并且该集合应保持足够廉价以便频繁运行。
基于代码的检查和LLM评判可以对相同的样本进行检测。该CI评估常见问题解答解释了开发过程中如何使用这套。
问：除了用户反馈外，我该如何发现有问题的痕迹供审查？
虽然用户反馈是缩小问题痕迹的好方法，但其他方法也很有用。以下是三种互补的方法：
从随机抽样开始
最简单的方法是随机抽样痕迹。如果发现问题很少，升级到压力测试：创建有意识测试提示约束的查询，看看AI是否遵守你的规则。
使用评估进行初步筛查
利用现有的评估来发现有问题的痕迹和潜在问题。一旦你确定了这些问题，就可以开始典型的评估流程，从错误分析开始。
利用高效的抽样策略
对于更复杂的痕迹发现，可以使用离群值检测、基于度量的排序和分层抽样来寻找有趣的痕迹。通用指标可以作为探索信号，识别值得审查的痕迹，即使它们不直接衡量质量。
问：我应该多久重新运行一次生产系统的错误分析？
在进行重大更改时，重新运行错误分析：新功能、提示更新、模型切换或重大漏洞修复。一个有用的启发式方法是设定评审目标至少是这样每个审查周期采集100+条新痕迹。
我们见过的典型复查周期在2-4周之间。请参阅这份常见问题解答，了解如何有效采样痕迹。
在主要分析之间，每周审查10-20条痕迹，重点关注异常值：异常长的对话、多次重试的会话，或被自动监控标记的痕迹。根据系统稳定性和使用增长调整频率。
新系统需要每周分析一次，直到故障模式稳定。成熟系统可能只需每月分析，除非使用模式发生变化。始终在事件、用户投诉激增或指标漂移后进行分析。
使用规模化引入新的边缘情况。
问：当我的“黄金”评估数据集变得陈旧时，我该怎么办？
随着产品和用户的变化，评估数据集自然会变得过时。使用常规数据误差分析寻找新问题并更新你的例子或参考答案。你多久复习一次这取决于你的使用场景以及产品或使用方式变化的速度。
与单元测试类似，评估可以发现修复后问题再次出现。然而，评估的维护和运行成本通常远高于单元测试。因此，你应将每个评估的成本与其信号价值进行权衡。
如果一切都在流逝这表明评估不再有用，应被淘汰或减少运行频率。
随着你的评估集变化，其分数可能不再能直接与旧评分对比。这没关系！评估的一个目的是为你提供可以进行爬山挑战的挑战。这些挑战应随着你的产品发展而变化，帮助你持续进步。
如果要用更长时间的指标跟踪进展，通常在评估之外使用产品指标会更好。产品指标的例子包括：流失率、活跃用户数、收入等。
问：生成合成数据的最佳方法是什么？
一个常见的错误是提示LLM去"give me test queries"没有结构，导致输出泛泛且重复。使用维度的结构化方法能产生更优质的综合数据，用于测试LLM应用。
我应该在什么时候使用合成数据进行评估？
在生产流量足够之前，使用合成数据开始错误分析，或测试在实际数据中罕见的已知故障。定义你需要的变体，生成示例，将它们应用于整个系统，并审查由此产生的痕迹。
合成数据无法告诉你生产环境中失败的普遍性。它也可能遗漏专业领域中重要的细节。一旦有真实数据，请尽快将合成样本与真实数据进行比较。
参见当合成数据可能不可靠时对于需要额外审查的案件。
先定义重要维度
首先定义维度：描述用户查询不同方面的类别。每个维度捕捉用户行为的一种变化类型。例如：
- 对于食谱应用，尺寸可能包括饮食限制（素食主义者,无麸质,没有），菜系类型（意大利语,亚洲,安慰食物），以及查询复杂度（简单的请求,多步,边缘情况).
- 对于客户支持机器人，尺寸可以是问题类型（片头,技术,概述客户情绪（沮丧,中立,开心），以及先验上下文（新刊,后续,已解决).
从失败假设开始.如果你缺乏对失败模式的直觉，可以大量使用你的应用，或者招募朋友一起使用。然后选择针对那些可能失败的维度。
先手动创建元组：手动写入20个元组。每个元组从每个维度中选择一个值。示例：（纯素,意大利语,多步).这些手动工作帮助你理解你的问题空间。
两步生成的尺度:
- 生成结构化元组： 让大型语言模型创建更多组合，比如（无麸质,亚洲,很简单)
- 将元组转换为查询： 在一个单独的提示中，将每个元组转换为自然语言
这种分离避免了重复的表达。该（纯素,意大利语,多步） 元组变为："I need a dairy-free lasagna recipe that I can prep the day before."
生成方法
你可以通过两种方式生成元组：
交叉积然后滤波器生成所有维度组合，然后用大型语言模型过滤。保证覆盖范围，包括边缘情况。当大多数组合有效时使用。
直接生成LLM：让LLM直接生成元组。这样组合更真实，但往往输出通用，错过罕见场景。当许多维度组合无效时使用。
先解决明显的问题：不要生成可以立即修复的问题的合成数据。如果你的提示没有提到饮食限制，就修正提示词，而不是生成专门的测试查询。
在对你的元组和提示词进行迭代之后，在你的实际系统中运行这些合成查询，以捕获完整的痕迹.大约100条不同痕迹的池是发现失败的有用起点。
让代理协助采样，自己至少注释30条迹，然后复习代理的建议，直到学习停滞。查看错误发现需要多少示例才能获得完整解释。
这里有一个视觉效果这有助于可视化整个过程。
问：有没有合成数据可能不可靠的情景？
是的：合成数据可能会误导或掩盖问题。有关在适当情况下生成合成数据的指导，请参见《生成合成数据的最佳方法是什么？》
合成数据失败的常见情景：
- 复杂的领域特定内容：大型语言模型常常忽略专业文件（如法律文件、医疗记录、技术表格）的结构、细微差别或特点。没有真实案例，关键边缘案例就会被遗漏。
- 低资源语言或方言对于资源有限的语言或方言，LLM生成的样本往往不现实。基于样本的评估无法反映实际表现。
- 当验证不可能时：如果你无法验证合成样本的真实性（由于领域复杂性或缺乏基础真实性），那么真实数据对于准确评估非常重要。
- 高风险领域在高风险领域（医学、法律、应急响应），合成数据往往缺乏细腻和边缘案例。这里的错误会带来严重后果，人工验证也很困难。
- 代表性不足的用户群体对于代表性不足的用户群体，LLM可能误导上下文、价值观或挑战。合成数据可能强化LLM训练数据中的偏见。
问：当痕迹包含敏感数据时，我该如何进行评估？
没有什么能替代真实互动的过程。这种情况并不理想，但你可以采取一些措施。以下是一些按偏好排序的选项：
- 尽量找到你被允许检查的真实数据。客户可能同意分享部分痕迹，或者测试用户允许你查看他们的互动。即使是有限访问，也能展示用户如何使用产品的例子。
- 如果你无法自己检查数据，就与有权限查看数据的领域专家合作。打造你的产品他们更容易核实作为他们日常工作的一部分。例如，医学研究助理可以向临床医生展示每个主张背后的证据，并标记冲突来源供审查。临床医生可以在使用产品时纠正具体主张或解决冲突。这些决策可以提供额外数据用于评估，但对存储和分享内容的限制相同。要设计好这类数据，了解专家如何核查答案。提供支持证据和小部分工作链接，供他们审查。询问最终答案是否有帮助往往只告诉你出了什么问题。我在以下内容中讨论了这种方法本帖.
- 编辑或编辑痕迹以便共享。如果敏感信息无法存储，请在记录前进行遮蔽。遮蔽工具可能会遗漏敏感信息，因此请检查它们的输出。当编辑痕迹可以共享时，删除个人信息和修改敏感细节可以使真实示例变得可用作复查。检查这些编辑是否保留了你需要评估的行为。
- 如果上述选项都不可行，那么合成数据应该是最后的选择。 合成数据可以帮助您发现最初的问题，但其缺点是它只能为您提供有关真实用户行为方式的有限证据。 详细了解何时 合成数据可能不可靠.
问：当我的系统处理不同的用户查询时，如何进行评估？
复杂的应用程序通常支持截然不同的查询模式——从“退货政策是什么？”到“比较符合这些标准的产品的各个地区的定价趋势。”每种查询类型都会使用不同的系统功能，从而导致对如何设计评估标准感到困惑。
误差分析 就是你所需要的。 您的评估策略应该来自观察到的故障模式（例如错误分析），而不是预先确定的查询分类。 不要创建涵盖您可以想象的每种查询类型的庞大评估矩阵，而是让系统的实际行为指导您在哪里投入评估工作。
在错误分析过程中，您可能会发现某些查询类别共享失败模式。 例如，所有需要时间推理的查询都可能会遇到困难，无论它们是简单的查找还是复杂的聚合。 同样，需要组合来自多个源的信息的查询可能会以一致的方式失败。 通过错误分析发现的这些模式应该决定您的评估优先级。 查询类别可能是对故障进行分组的好方法，但在分析数据之前您并不知道这一点。
要查看基本错误分析的示例， 看这个视频.
在 YouTube 上观看“错误分析：人工智能工程中投资回报率最高的技术”
问：如何有效地对生产痕迹进行抽样以供审查？
有多种方法可以对生产痕迹进行采样以供审查。 以下是一些常用的方法。
| 方法 | 它的作用 | 主要限制 |
|---|---|---|
| 随机 | 以相等的概率选择踪迹。 | 小批量可能会错过罕见的情况。 |
| 聚类 | 按相似内容对跟踪进行分组，并从每个组中选择示例。 | 结果取决于特征和聚类选择。 |
| 数据分析 | 审查极端值，例如延迟或工具数量。 | 极端值可能与质量无关。 |
| 分类 | 使用评估器或其他模型来标记可能的故障。 | 它有利于分类器已经知道如何找到的问题。 |
| 反馈 | 选择具有负面用户反馈的跟踪。 | 它会遗漏用户未报告的问题。 |
上表按照从最具探索性到最具针对性的顺序对抽样方法进行了排序。 当您开始时，您应该优化数据探索。 随着您了解更多，您可以开始更加依赖信号来选择迹线。 方法的正确组合取决于您的目标并且需要进行实验。
在每批中保留一些随机痕迹。 这使您有机会找到当前信号未描述的故障模式。
如何测量罕见故障模式？
使用有针对性的抽样来发现罕见的故障。 搜索与故障相关的信号，例如特定的工具序列、异常长的跟踪、重试或已知的输入模式。 检查目标批次以收集示例并改进故障定义。
这张抽认卡 我们的评估抽认卡系列直观地展示了这些方法。
使用标签选择下一条轨迹
我们可以借用机器学习中一种称为主动学习的技术来对生产痕迹进行采样。 在主动学习中，系统要求人们标记对其下一次更新最有用的数据点。
在 Shreya Shankar 的演练，Claude Code 集群跟踪并从每个集群中选择示例进行审查。 A monitor 命令手表 annotations.json 用于新标签。
当标签到达时，代理会更新故障分类法并查找类似案例或不同的故障。
在 YouTube 上观看“如何（正确）自动化 AI 评估”
在上面的视频中，主动学习用于错误分析，以查找新案例进行审查。 但是，此方法可以在工作流程中注释数据的任何位置使用。
👉想了解更多关于 AI 评估的信息吗？看看我们的人工智能评估课程. 这是一个实时学习小组，包含动手练习和办公时间。这里是一个25% 折扣码给读者。
👈
评估设计与方法论
问：你为什么推荐二元（通过/不通过）评估，而不是1-5评分（李克特量表）？
工程师常常认为利克特量表（1-5 评分）比二元评估提供更多信息，从而使他们能够跟踪逐步改进。然而，这种增加的复杂性在实践中往往带来的问题比解决的更多。
二元评估迫使思维更清晰，标签更一致。 Likert 量表带来了重大挑战：相邻点之间的差异（例如 3 与 4）是主观的，并且在注释者之间不一致，检测统计差异需要更大的样本量，并且注释者通常默认使用中间值以避免做出艰难的决定。
二元期权迫使人们做出决定，而不是将不确定性隐藏在中间值中。 在错误分析过程中，二元决策的制定速度也更快 - 您无需浪费时间争论某件事是 3 还是 4。
为了跟踪逐步改进，请考虑使用自己的二进制检查来测量特定的子组件，而不是使用比例。 例如，您可以将“包含的 5 个预期事实中的 4 个”作为单独的二进制检查进行跟踪，而不是将事实准确性评级为 1-5。 这保留了衡量进展的能力，同时保持清晰、客观的标准。
从二进制标签开始，了解“坏”是什么样的。 数字标签是高级的，通常不是必需的。
问：如何将我的评估合并为一个指标？
您创建的每个评估都应该返回一个 二元结果 （例如通过或失败）。您可能最终会进行多次评估，每次评估都会检查不同的失败。 但是，您组织中的人员可能需要跟踪一个号码。
我喜欢使用的一个简单方法是“全部通过”率。 仅当一个示例通过了每项检查时，它才算通过。 例如，如果 100 个示例中有 80 个通过了每次检查，则全部通过率为 80%。
设计您的报告或仪表板，以便您可以从总体通过率深入到每次检查的通过率，以便您可以了解导致失败的最大原因。
每次评估的总分和单独结果之间的中间立场是将相关检查分组到主题中。 然后，您可以报告每个组的通过率。 例如，审查 培养老板的公寓租赁助理 揭示了对话流程、移交和重新安排方面的问题。 这些主题可以成为评估组。
选择这些群体的另一种方法是根据失败的严重程度。 例如，对于应该阻止发布的检查报告一个通过率，对于您可以容忍的问题报告另一个通过率。 这种方法有助于控制生产版本。
如果您仍然需要一个单一的分数来解释重要性的差异，您可以给予某些检查比其他检查更大的权重。 我不鼓励复杂的加权分数，原因与我不鼓励的原因相同 李克特量表 法学硕士法官。
如果您的仪表板报告的综合分数每周从 3.2 跃升至 3.7，那么很容易对这种增长感到满意，但不知道用户得到了什么改进。 根据我们的经验，这样的仪表板通常是高性能的并且浪费每个人的时间。
无论您选择哪种方法，请记住，随着您的评估集发生变化， 它的分数可能不再与旧分数直接比较。评估为您提供了需要改进的挑战，这些挑战应该随着您的产品的发展而改变。 为了在较长时间范围内跟踪指标的进度，除了评估之外，通常最好使用产品指标。 当您的评估发生变化时，流失或活跃用户等衡量标准可以提供更稳定的比较基础。
问：我应该练习基于 eval 的开发吗？
一般不。基于评估的开发（在实现功能之前先编写评估器）听起来很有吸引力，但它带来的问题比解决的问题还多。与传统软件不同，传统软件的失败模式是可预测的，而大型语言模型的潜在失败面是无限的。
你无法预见什么会出错。
更好的方法是从错误分析开始。为你发现的错误编写评估器，而不是为你想象的错误编写评估器。这可以避免在评估内容上遇到阻碍，并防止在对实际系统质量没有影响的指标上浪费精力。
异常：基于评估驱动的开发可能适用于一些特定约束条件，在这些条件下你完全知道成功的标准。如果加入“绝不提竞争对手”，提前编写该评估器可能是可以接受的。
最重要的是，在实施评估之前，始终进行成本效益分析。要问失败模式是否值得投入。错误分析可以揭示哪些失败对你的用户真正重要。
问：我是否应该为我发现的每一种故障模式建立自动评估器？
让自动化评估器专注于修正提示后依然存在的失败。许多团队发现他们的LLM无法满足他们从未明确表达的偏好——比如想要简短的回复、特定的格式或逐步推理。
在构建复杂的评估基础设施之前，先解决这些明显的漏洞。
考虑不同评估者类型的成本层级。简单的断言和基于引用的检查（与已知正确答案进行比较）构建和维护成本低廉。作为评判的LLM评估者需要100+个标注的示例，持续的每周维护，以及开发者、项目经理和领域专家之间的协调。
这种成本差异应当塑造你的评估策略。
只为你会反复迭代的问题构建昂贵的评估器。由于LLM作为法官存在较大的开销，建议留给持续的泛化失败——而不是简单解决的问题。尽可能从廉价的基于代码的检查开始：正则表达式模式、结构验证或执行测试。
将复杂评估留给那些简单规则无法捕捉的主观特性。
问：我应该使用什么模型或大型语言模型来构建自动化评估？
首先检查是否可以用代码断言来测试该条件。例如，假设一个AI助手管理你的联系人，你想测试它是否在被要求时创建联系人。为了测试这个功能，你可以给它一个新的联系人来创建，然后查询数据库，确认是否存在一个符合请求信息的匹配记录。
使用代码断言可以避免对人工标签的需求。
当检验需要判断时，使用LLM或其他机器学习分类器。使用LLM评判时，我们建议将其作为返回的分类器使用通过还是不通过针对你想捕捉的错误。
无论你使用哪种模型，验证它在信任其决策之前，先对人类标签进行对抗。
例如，你可以尝试 JevTypeSafeBERT，或逻辑回归。不同的模型可能更便宜或更快，且与人工标签的一致性也可能不同。在数据上测量这些差异，找到符合你应用需求的模型。
例如，如果评估中发现了代价高昂的失败，你可能会接受较慢的评估，或者在需要即时反馈时更倾向于更快的模型。
使用大型语言模型时，从强大的模型开始，可以更容易开发评委的提示。一旦效果良好，可以尝试更小、更便宜的模型，测量你丢失的准确度。
你也可以使用与你的应用相同的模型.
代理人可以在你定义任务并标注示例后，帮助优化评委提示。给它设定一个具体的检测失败，并用标签来衡量进展。“找出所有错误并持续改进”太笼统了。
代理人需要知道什么算错误，以及如何判断某个更改是否有效。保持独立测试集在优化过程之外检查是否法官进行概括而是针对它所不调谐的例子。
问：我可以用Jev进行评估吗？
是的。来自TypeSafe的Jev是一个通用的分类器，可用于评估。一个返回的LLM法官通过还是不通过也是一种分类器。
你用同样的方式来验证Jev。用于评估的其他分类器通过将其预测与可信标签进行比较。这就是为什么我们在原始抽认卡并用“评估分类器”来替代：
要理解抽认卡中描述的验证过程，请参见本帖.
快速且廉价的分类器（如Jev）的优点是可以显著降低提示调优的成本和速度。提示调整涉及自动尝试对评估者的提示词进行修改，并检查其决策是否更符合人类标签。
GEPA是提示调优算法的一个例子。提示调优有时需要数百甚至数千次评估，因此每次运行成本降低可以带来显著的节省。
没有单一分类器能适用于所有评估。人工标签验证帮助你在准确性、成本和速度之间做出权衡。
问：我如何判断我的自动评估是否值得信赖？
对于做判断的评估者，可以将其与你想检测的失败的人标示例进行测试。这适用于大型语言模型评判员和其他机器学习分类器。你需要知道他们多久能发现失败，多久会发出虚报。
如果代码能直接检查条件，你就不需要人工标签来进行检查。参见评估时应采用哪种模型或方法。.
首先将标记的例子拆分为三组：
- 训练集：利用这些例子教评估者应该注意什么。对于LLM裁判或零点分类器，比如紫杉你可以把它们写进提示词里。
- 开发集（开发者）：在这些示例上运行评估器，并比较它的决策与你的标签。检查意见不合以改进提示词，或者在模型之间做出选择。在开发评估器时重复这个过程。提示词调优算法会利用开发者集来指导其修改。
- 测试集：把这些例子放在一边，等你完成修改再说。用它们作为对那些没有影响评估者决策的例子做最后检查。
每次你用开发结果来修改提示词或选择模型时，这些示例中的信息会影响评估者。经过多次轮询，它可能在开发者集表现不错，但在新示例中表现不佳。
这就是过度拟合，即使你从未直接将开发示例放入提示词中，也可能发生。测试集会给你对那些未引导这些变化的数据做最终检查。
如果测试分数远低于开发分数，检查是否存在过拟合。样本量较小，测量不确定，且集合间差异也可能导致差距。如果过拟合，请重新查看说明和示例，然后用新的未动测试集进行最终检查，重复开发。
关于过拟合问题超出本常见问题的范围。
为了衡量评估者与人类判断的匹配度，可以使用以下指标。这里，“正”表示存在错误，与下面的抽认卡相符。
- 真阳性率（TPR），也称为召回率，衡量评估者发现的实际故障数量。如果有人识别出10个故障，评估者发现8个，其TPR为80%。当漏掉失败代价高时优先考虑。
- 真实阴性率（TNR）衡量评估者正确通过了多少优秀输出。如果有人识别出100个良好输出，评估者通过95个，则其TNR为95%。其余五个是虚惊。高TNR有助于避免浪费人们时间去审核错误标记的良好输出。
在进行更改时跟踪这两个率。发现更多故障可能会以更多误报为代价。根据对你的应用的影响选择可接受的水平。如果故障很少见，即使是很小的误报率也可能引发大量不必要的审核。
下面的抽认卡展示了LLM评审的这一过程。开发与测试的分离同样适用于其他评估者.
抽认卡的数据集分割是基于提示的评委的示例。零发分级器.训练分类器可能需要更多训练数据。根据漏接失败和误报的成本选择目标。
问：当我无法让我的LLM评委同意人类评审的观点时，我该怎么办？
要调试LLM评判，你需要用带有人类通过/不通过标签的示例来比较其判决。获得这些标签的有效方法是误差分析，这为你提供了一种结构化的方式来审查申请数据并发现错误。
在收集带标签的例子时（我们建议至少50个通过和50个不合格的例子），检查评委与人类标签不符的地方，以获取需要修正的线索。常见问题包括缺少上下文或者模糊的指示。
如果你难以判断一个例子该通过还是不通过，这表明你需要更精准地定义成功。
在尝试自动提示调优之前，先手动检查一些分歧。算法如GEPA尝试修改评委提示，并衡量这些修改是否能改善与人类标签的一致性。如果过早进行提示调整，可能会错过与提示无关的重要问题（如缺少上下文、错误标签等）。
人们最常见的错误是指示他们的LLM评判同时发现过多不同类型的错误。相反，我们建议为每种失败类型单独建立一个评判。例如，检查助理是否在需要时升级到真人，比评分整体对话质量更为具体。
专注的评判也更容易与人类标签对齐，且更具可执行性。
最后，确保你的评判能推广到你没见过的数据（即不会对你调优的数据进行过度拟合）。最好的方法是把人工标注的例子留到最后测试时再用。
那验证常见问题解答解释如何拆分数据，并衡量评委是否同意人工审核员对未见过的例子的看法。
问：我应该使用“现成型”评估指标吗？
不。通用的评估浪费时间，且当你将其作为质量衡量标准时，会制造虚假的信心。不过，他们仍然可以帮助你找到痕迹进行检查。
为什么通用评估指标会误导人？
通用的评估指标无处不在。评估库包含帮助度、连贯性、质量等评分，承诺易于评估。这些指标衡量的是抽象的品质，可能对你的用例无关紧要。
好评分并不意味着你的系统有效。
相反，应进行错误分析以了解故障。根据真实问题定义二元故障模式。为这些故障创建定制评估器，并根据人类判断进行验证。
有经验的从业者可能会使用通用指标作为探索信号。一旦你理解它们为何作为质量指标失败，就可以利用它们寻找有趣的痕迹供人工审查。
问：相似度指标（BERTScore、ROUGE等）对评估大型语言模型输出有用吗？
像BERTScore、ROUGE、余弦相似度等通用指标对大多数AI应用中的LLM输出评估并不有用。相反，我们建议使用错误分析来识别针对你应用行为的特定指标。
我们建议设计二进制通过/失败。）评估（使用LLM作为评判）或基于代码的断言。
举个例子，考虑房地产CRM助理。建议不可得的看房（可以用断言测试）或令人困惑的客户形象（可以用LLM作为评判者测试）是有问题的。
通用指标如相似度或冗长度是无法识别的。课程中的一段相关引用：
“通用指标的滥用现象普遍存在。许多评估供应商推广现成指标，这些指标将工程师困在多余的工作中。”
相似度指标并非总是无用。它们在搜索和推荐等领域有用（因此对优化和调试RAG检索非常有用）。例如，嵌入之间的余弦相似度可以衡量检索系统中的语义接近度，平均成对相似度可以评估输出多样性（相似度越低，多样性越高）。
问：我可以同时使用同一个模型进行主要任务和评估吗？
对于LLM作为法官的选择，使用相同模型通常没问题，因为法官执行的任务与你的主LLM流程不同。虽然研究表明模型在评估自身输出时可能存在偏见，最终重要的是你的评判与人类判断的高度契合。
我们推荐构建的评审者执行有范围的二元分类任务。我们发现，在这种受限任务中，通常可以实现与人类标签的迭代对齐。
在你的评审面前，专注于在标注测试集上达到高的真阳性率（TPR）和真阴性率（TNR）。如果你难以与人类分数良好对齐，可以考虑尝试不同的模型。
然而，在某些组织中，引入新模型提供者可能需要付出不小的努力，这也是为什么除非存在特定的对齐问题，否则我们不会默认使用不同模型。
选择评判模型时，应从最有能力的模型开始，以建立与人类判断的高度契合。一旦建立可靠的评估标准，之后再进行成本优化。
问：我应该给LLM法官多少背景信息？
只给每个评判其失效模式所需的痕迹部分。不要默认给每个评判相同的完整痕迹。额外的上下文可能导致上下文腐烂还会让法官更糟。
找到合适的背景通常需要不断尝试。通过将法官的判决与人类标签进行比较来检验你的选择。然后，检查意见不合，判断法官是否缺乏必要证据，或被无关信息分散了注意力。
如果你不确定某条信息是否有帮助，可以尝试消融检查。这意味着一次切除一块，并与人体标签对比观察结果的变化。如果表现保持不变或有所改善，你可能可以省略它。
长期执行的代理可能会产生大量痕迹，填满甚至超过法官的上下文窗口。对于这些情况，可以考虑给法官一个工具来搜索所需的部分。不过，除非你绝对需要，否则不要添加这个工具，因为这类工具会增加额外的复杂性、成本和延迟。
问：我们如何评估模型表达不确定性或“知道它不知道什么”的能力？
许多应用需要一个模型在信息不足时拒绝回答问题。要评估这种拒绝行为是否校准良好，你需要测试模型是否在适当时间拒绝，但不拒绝回答问题应该能够回答。
为了有效完成这一点，你应构建包含以下组成部分的评估集：
- 可回答的问题：模型提供的上下文或一般知识中存在正确且可验证的答案的情景。
- 无解之问：设计用来诱使模型产生幻觉的情景。这些包括带有错误前提的问题、对上下文中明显缺失的信息查询，或远超其知识基础的主题。
虽然精确比例不是关键，但均衡的题目集，且可答和无法回答的问题数量大致相等，是一个不错的起点。题目的多样性和难度比精确比例更重要。
评估本身是对模型判断的二元（通过/不通过）检查。“通过”要求模型满足两个条件：必须回答可回答的问题，同时拒绝回答无法回答的问题。
失败定义为对无法回答的问题提供了虚构的答案，表明校准不佳。
在研究文献中，这种能力被称为“隐匿能力”。为了改善这种行为，值得在Arxiv上搜索此词了解最新的技术。
人工注释与流程
问：应该有多少人为我的LLM输出做注释？
对于大多数中小企业来说，任命一位单一领域专家作为“仁慈独裁者”是最有效的做法。这个人成为质量标准的最终声音。这位专家可能是心理健康聊天机器人的心理学家，或法律文件分析的律师。
一位专家消除了注释冲突，避免了“厨房厨师太多”带来的瘫痪。仁慈的独裁者可以纳入他人的意见和反馈，但他们推动整个过程。如果你觉得需要五位主题专家来评判一次互动，那就说明你的产品范围可能过于宽泛。
然而，大型组织或跨多个领域运营的（比如跨国公司拥有不同文化背景）可能需要多个标注者。当你使用多个人时，需要用像Cohen's Kappa这样的指标来衡量他们的同意度，这会考虑超越偶然的一致性。
不过，请用你的判断。即使在大公司，一个专家通常也足够了。
注释者应如何解决分歧？
让注释者在讨论前分别标注相同的例子。测量一致性，收集标签差异的案例。在对齐会议中，询问评分标准的哪部分导致了分歧，以及哪条规则能让下一个决定变得清晰。
更新评分标准，加入涵盖争议案例的定义、规则或示例。然后重新标注受影响的例子。如果注释者仍存在分歧，指定领域专家做最终决定并记录原因。
尽可能从仁慈的独裁者开始。只有在绝对必要时才增加复杂性。
问：我怎样才能让AI输出更容易被人们评估？
首先仔细审视你的产品设计。通常有助于展示用户在最终结果前可以检查的中间输出。例如，假设你有一位代理人通过综合患者的病史来撰写医疗报告。
与其让医生对报告提供反馈，不如展示提取出来的事实并链接到原始材料，让医生在生成报告前修正事实或解决冲突证据。这也能让医生保持参与感，并通过边做边检查工作来帮助他们建立信任。
这是这样一个界面可能的草图：
关于验证设计的更多讨论，请参见“很难评估”是一种产品气味.帖子对这个例子进行了扩展，并讨论了其他几个带有前后对比模型的例子。
在你设计好验证后，确保审核界面消除了审查数据的阻力。请参阅相关建议构建评审界面.一些常见建议包括：
- 以熟悉的格式显示输出。将生成的邮件渲染为邮件，代码中使用语法高亮。
- 将审核员需要的上下文保持在同一界面。将不重要的细节放在他们需要时可以扩展的部分。
- 添加快捷键，方便在示例间移动和记录判断。让保存笔记变得轻松，无需伸手拿鼠标。
- 展示进展，比如“已评审100个范例中的45个”，这样评审者就知道还有多少工作要做。
接下来，调试评审流程。首先，尝试少做一些例子，让评审有时间仔细检查每一个。让大家独立审查相同的例子，讨论分歧.你们也可以一起回顾示例，看看大家卡在哪里。
分歧可能暴露出不清晰的指示或缺失的信息。
问：产品经理和工程师应该在错误分析上合作吗？怎么做？
一开始就合作建立共享的上下文。工程师发现技术问题，如检索问题和工具错误。项目经理会发现产品失败，如用户期望未被满足、反应混乱或用户期望的功能缺失。
随着时间推移，你应倾向于选择一位仁慈的独裁者来分析错误：理解用户需求的领域专家或项目经理。赋权领域专家评估实际结果，而非技术执行。
问“是否已预约？”而不是“工具调用成功了吗？”赋能领域专家的最佳方式是为他们提供定制注释工具，显示系统结果和痕迹。展示确认邮件、生成的邮件或数据库更新，以验证目标完成。
将所有上下文集中在一个屏幕上，让非技术审核员专注于结果。
问：如果我不是领域专家，我能帮忙做评估吗？
是的，尤其是刚开始做评估时。我经常惊讶于在审查数据时发现许多不需要领域知识的低垂果实。例如，作为外部人员，我在专业领域遇到过类似问题：
- 短信聊天机器人被大量短促、断断续续的对话流所混淆，而人们往往在文字中写出，而非聊天。
- 当用户请求明显模糊时，缺乏查询消歧或后续跟进。
- 一开始就没有合适的仪器、日志记录或追踪。
- 缺乏小部件、界面元素或其他帮助用户完成任务的功能，而非过度依赖文本回复。
此外，请领域专家带你讲解一个例子，解释为什么它好或不好。观察他们检查什么以及需要哪些证据。运用你学到的东西构建更好的注释界面这让复习变得更轻松。
你还可以帮助团队收集互动并定期审查。例如，参见产品经理和工程师如何协作进行错误分析了解如何构建跨职能协作。
最后，确保将需要专业知识的判断交给专家。但不要以为你需要领域专业知识才能开始发挥作用！
问：我应该把注释和标签外包给第三方吗？
外包错误分析通常是个大错误（当然也有例外）。评估的核心是建立产品直觉，这种直觉只有系统性分析系统故障才能获得。你应该对将这一过程委托出去保持极度怀疑。
外包的危险
当你外包注释时，往往会打破观察失败与理解如何改进产品的反馈循环。外包的问题包括：
- 表面标签：即使是定义清晰的指标也需要细致判断，而外部团队缺乏这些判断。错误分析中的一个关键失误是将领域专家排除在标签流程之外。将这项任务外包给没有领域专业知识的人，如普通开发者或IT人员，往往会导致标签表层或错误。
- 未明说的知识流失：主领域专家拥有无法在评分标准中完全体现的隐性知识和用户理解。邀请这些专家有助于揭示他们的偏好和期望，而这些可能无法事先充分表达。
- 注释冲突与不一致：没有共享上下文，外部注释者可能制造的分歧多于解决。即使是内部团队也难以实现一致，这意味着你将花费更多时间在这个过程中。
推荐方法：构建内部能力
与其外包，不如专注于建立高效的内部评估流程。
1. 任命一位“仁慈独裁者”。对于大多数团队来说，最有效的策略是任命一位内部领域专家作为质量的最终决策者。这个人负责制定标准，确保一致性，并培养归属感。
2. 多注释者使用协作工作流程。如果需要多个注释者，请遵循结构化流程以确保一致性：* 起草初步评分标准，明确通过/不通过定义和示例。
* 让每位注释者独立标注一组共享痕迹，以反映表面解释差异。* 使用如Cohen's Kappa的概率修正指标测量注释者间一致性（IAA）。* 促进对齐会议，讨论分歧并完善评分标准。
* 反复进行此过程，直到一致性持续高。
如何处理容量限制
建设内部能力并不意味着你必须给每一条线索做标签。请使用以下策略来管理工作量：
- 智能抽样：仔细审查一个小而具代表性的痕迹样本。分析100条多样痕迹以寻找模式，比表面标记数千条更有效。
- “大声思考”协议：为了充分利用有限的专家时间，使用可用性测试中的这一技巧。请专家在审查少量痕迹时表达他们的思考过程。这种方法可以在一小时的会话中挖掘深刻见解。
- 构建轻量级定制工具：构建定制注释工具以简化审核流程，提高吞吐量。
外部帮助的例外情况
虽然不建议将核心错误分析流程外包，但在某些情况下，外部帮助是合适的：
- 纯机械任务：对于高度客观、明确的任务，如识别电话号码或验证电子邮件地址，在严格的内部流程定义评分标准后，可以使用外部注释器。
- 没有产品上下文的任务：不需要理解产品具体需求的明确任务可以外包。翻译就是一个很好的例子：它需要语言专业知识，但不需要深入的产品知识。
- 聘请主题专家：聘请外部专家作为内部领域专家并非外包;而是将必要的专业知识引入评估流程。例如，AnkiHub聘请四年级医学生评估他们的RAG系统是否适合医学内容，而不是外包给通用注释员。
问：如何审查一条非常大的痕迹？
当代理长时间运行或获取大量上下文时，跟踪可能会变得很大。一个有用的启发式方法是关注第一次上游故障.错误往往会累积，这意味着你可以优先处理之前的错误以节省时间。
在审查工具中使用渐进披露，先展示最相关的信息，让审核员根据需要扩展细节。例如，先展示对话过程，工具输出收缩，直到审核员需要检查。
如果单个追踪仍然过大无法审查，可以与领域专家合作，确定需要检查的内容。构建一个工具，提取相关证据并将其链接回追踪或检索到文档中的位置。
例如，在审查关于长期合同的回答时，工具可以显示相关条款并链接到其原始页面。一定要与领域专家一起验证此类提取。
质量比数量更重要。你通常通过仔细调查几次故障，比匆忙检查大量痕迹学到更多。
问：哪些评估部分可以用大型语言模型自动化？
LLM可以加快你评估流程的部分流程，但无法替代那些关键是你的专业知识的人类判断。例如，如果你让LLM处理所有误差分析（即审查和注释跟踪），你可能会忽略对产品重要的故障案例。
假设用户在反馈中不断提到“延迟”，但大型语言模型（LLM）将这些归类为通用的“性能问题”，而不是创建“延迟”类别。你会错过反复出现的响应缓慢投诉，也无法优先解决。
话虽如此，LLMs依然是加速评估工作流程某些部分的宝贵工具在监督下使用.
以下是大型语言模型可以提供帮助的一些方面：
- 第一遍轴向编码：在你自己开启30到50条痕迹代码后，使用大型语言模型将原始失败记录整理成建议的分组。这有助于你快速发现模式，但始终要自己审查和完善这些集群。注意：如果你不熟悉轴向和开放编码，请参见此常见问题解答.
- 将注释映射到失效模式：一旦定义了失败类别，你可以让大型语言模型建议每个新痕迹适用哪些类别（例如，“给定此注释：[open_annotation]和这些失败模式：[list_of_failure_modes]，哪个适用？”）。
- 建议及时改进：当你发现反复出现的问题时，让LLM提出具体的修改建议。在采纳任何修改前，请先审查这些建议。
- 分析注释数据：使用大型语言模型（LLM）或AI驱动的笔记本，找出标签中的模式，比如“延迟报告在高峰使用时段增加了3倍”或“响应缓慢主要来自移动设备用户”。
不过，你不应该把这些活动外包给LLM：
- 初始开放编码：始终在开始时自己仔细阅读原始跟踪。这样你才能发现新的故障类型，理解用户痛点，并建立对数据的直觉。绝不要跳过或委托。
- 验证失败分类法：LLM生成的分组需要你重新审视。例如，LLM可能会将“登录后应用崩溃”和“登录时间过长”归为同一类别，尽管一个是稳定性问题，另一个是性能问题。没有你的介入，你会忽略这些问题需要不同的修复方法。
- 真实标注：对于用于测试/验证LLM作为评审者的数据，请手工验证每个标签。LLM可能会犯错，导致基准测试不可靠。
- 根本原因分析：LLM可能会指出明显的问题，但只有人工审核才能发现某些工作流或边缘案例中出现的错误——比如仅在用户粘贴Excel数据时出现的错误。
总之，首先手动检查数据，了解实际出了什么问题。用LLM来扩展你学到的东西，而不是逃避查看数据。
问：我是否应该停止手动写提示，转而使用自动化工具？
自动化提示工程可能很诱人，但你应对那些承诺为你优化提示的工具保持怀疑态度，尤其是在开发初期阶段。写提示时，你被迫澄清假设并外化需求。
好写作就是好思考 1.如果你过早将这项任务委托给自动化工具，你就有可能永远无法完全理解自己的需求或模型的失败模式。
这是因为自动化提示优化通常会对预定义的评估指标进行爬坡式分析。它可以优化提示，使其在已知失败时表现更好，但无法发现新一。
发现新错误需要错误分析。此外，研究表明，评估标准在审查模型输出后往往会发生变化，这种现象被称为“标准漂移”2。这意味着评估是一个迭代的、由人类驱动的意义构建过程，而非一个可以设定一次然后交给优化器的静态目标。
一种务实的方法是利用大型语言模型（LLM）基于开放编码（关于痕迹的开放式笔记）来改进提示。这样，你就能保持一个观察数据并外部化需求的人类参与。
一旦你拥有高质量的评估集，提示优化就能有效提升最后一公里的性能。
👉想了解更多关于人工智能评估的信息吗？请查看我们的AI评估课程.这是一个现场的队列，包含动手练习和办公时间。这里有25%折扣码给读者看。
👈
工具与基础设施
问：我应该自己做注释工具，还是用现成的工具？
构建一个自定义注释工具。这是你对AI评估工作流程最有影响力的投资。借助像Cursor或Lovable这样的AI辅助开发工具，你可以在数小时内构建出定制化的界面。
我经常发现，使用自定义注释工具的团队，迭代速度快了大约10倍。
自定义工具的优点是：
- 它们能在一个地方显示你来自多个系统的全部上下文
- 他们可以以产品特定的方式渲染你的数据（图片、小部件、降价、按钮等）。
- 它们是为你的具体工作流程设计的（自定义筛选、排序、进度条等）。
当您需要协调数十个分布式标注器和企业访问控制时，现成工具可能更有价值。即便如此，许多团队仍觉得配置开销和限制不值得。
Isaac的Anki抽认卡注释应用展示了定制工具的强大——通过键盘导航和领域特定评估标准处理400+个查询结果，这些在通用工具中几乎无法配置。
问：用于审查 LLM 输出的良好自定义界面是什么？
出色的界面使人工审核变得快速、清晰且具有激励性。 我们建议您构建根据您的领域定制的自己的注释工具。 以下功能是我们认为效果良好的可能的增强功能，但您并不需要全部功能。 显示的屏幕截图是阐明概念的说明性示例。 在实践中，我很少在单个应用程序中实现所有这些功能。这最终是根据您的具体需求和限制做出的判断。
1. 智能地渲染轨迹，而不是通用地渲染轨迹:
以对领域来说直观的方式呈现跟踪。 如果您正在评估生成的电子邮件，请将它们呈现为看起来像电子邮件。 如果输出是代码，请使用语法突出显示。 允许审阅者查看完整的跟踪（用户输入、工具调用和 LLM 推理），但将不太重要的细节保留在可以展开的折叠部分中。 以下是用于查看房地产助理电子邮件的自定义注释工具的示例:
2.显示进度并支持键盘导航:
通过最大限度地减少摩擦并激励完成，让审阅者保持流畅状态。 包括进度指标（例如，“100 条中的第 45 条”），以限制审核会议并鼓励完成。 启用热键在迹线之间导航（例如，N 表示下一个）、应用标签以及快速保存注释。 下面是这些功能的说明:
3. 通过聚类、过滤和搜索进行跟踪导航:
允许审阅者按元数据过滤跟踪或按关键字搜索。 语义搜索有助于发现概念上相似的问题。 对相似的痕迹进行聚类（例如按用户角色分组）可以让审阅者发现重复出现的问题并探索假设。 下面是这些功能的说明:
4. 优先标记您认为可能有问题的痕迹:
由护栏、CI 故障或自动评估器标记的表面痕迹以供审查。 提供按钮来执行添加到数据集、提交错误或重新运行管道测试等操作。 直接在界面中显示相关上下文（管道版本、评估分数、审阅者信息），以最大程度地减少上下文切换。 下面是这些想法的说明:
一般原则：保持最小化
保持注释界面最小化。 仅当这些想法提供的好处超过额外的复杂性和维护开销时，才将其纳入其中。
问：我应该准备好填补评估工具中的哪些空白？
大多数评估工具都能很好地处理基础知识：记录完整的跟踪、跟踪指标、提示游乐场和注释队列。 这些都是赌注。 您可能需要在以下四个领域补充现有工具。
关注解决这些差距的供应商：这是他们了解从业者需求的强烈信号。
1. 错误分析和模式发现
在检查了 AI 失败的痕迹后，您的工具能否自动对类似问题进行聚类？例如，如果多个痕迹显示助理对奢侈品客户使用随意的语言，那么您需要能够识别这种更广泛的“角色语气不匹配”模式的东西。 我们建议构建使用人工智能来建议分组、将您的观察结果重写为更清晰的故障分类法、通过语义搜索帮助查找类似案例等功能。
2. 整个工作流程中的人工智能辅助
最有效的工作流程使用人工智能来加速每个阶段的评估。 在错误分析过程中，您需要法学硕士帮助您将开放式观察结果分类为连贯的故障模式。 例如，您可能会用“投资者语气错误”、“奢侈品买家过于随意”等注释来注释多条痕迹。您的工具应将这些识别为相同的基础模式，并建议统一的“角色语气不匹配”类别。
您还需要人工智能帮助提出修复建议。 在识别出您的助理在财产摘要中遗漏宠物政策的 20 个案例后，您的工作流程能否分析这些失败并提出具体的提示修改建议？
当它注意到缺少 WHERE 子句的模式时，它能否起草对 SQL 生成指令的改进？
良好的工作流程还可以帮助您对注释和跟踪进行数据分析。 我喜欢使用具有人工智能循环功能的笔记本，例如 朱利叶斯 或者 十六进制。
这些帮助我发现诸如“当用户提及社区名称时，位置模糊性错误会增加 3 倍”或“电子邮件生成中语气不匹配的发生率比其他方式高出 80%”之类的见解。
”
3. 通用指标的自定义评估器
准备好从头开始构建大部分评估器。 像“幻觉分数”或“有用性评级”这样的通用指标很少能够捕捉到对您的应用程序真正重要的内容，例如建议不可用的显示时间或忽略电子邮件中的预算限制。 根据我们的经验，成功的团队将大部分精力花在特定于应用程序的指标上。
4. 支持自定义注释应用程序的API
自定义注释界面最适合大多数团队。 这需要具有深思熟虑的 API 的可观察平台。 我经常必须构建自己的库和抽象，只是为了使批量数据导出易于管理。 您不必为了获取数据而对数千个请求进行分页或处理容易超时的端点。 寻找提供真正批量导出功能的平台，最重要的是，寻找可以让您高效写回注释的 API。
问：内部评估平台应该跨团队标准化什么？
在构建内部评估平台时，人们很容易从工具、基础设施和一组共享指标开始。 这可能会导致团队采用该平台提供的任何内容，而不检查它是否有助于他们发现和解决产品中的问题。
首先鼓励团队表现 误差分析 和 样本数据 有效地进行审查。 他们可以利用发现的失败来决定 自动检查 构建，然后 验证评估者 反对人类标签。 标准化这些流程，同时让每个团队开发自己的指标，并在需要时开发工具。 这 现场指南 展示了如何将它们组合在一起的示例。
使团队能够灵活地构建自己的工具，尤其是现在人工智能编码代理使定制软件的创建成本更低。 例如，工具 标注数据经常需要自定义接口适合正在审阅的数据。
从扫描文档中提取的文本审阅所需的界面与审阅聊天对话所需的界面不同。
一个平台仍然可以为结果提供共享存储，并支持标签工作的协作。首先从为一个团队和一个用例提供良好服务开始，然后随着你了解哪些需求是共享的再逐步扩展。
当团队的需求差异很大且可以自己廉价地构建工具时，标准化的好处就会较小。
只有在检查和测试数据可比时，跨项目比较评估分数才有意义。我们强烈建议不要提供通用指标，例如有用性或连贯性，作为一种捷径。
它们很少用作质量衡量标准，而且往往使团队忽视影响用户的失败。
问：您最喜欢的评估供应商是哪家？
评估工具处于竞争激烈的领域。 比较它们的特征是徒劳的。 如果我尝试做这样的分析，一周后就会失效！我在工作中遇到最多的供应商是: 兰史密斯, 他哭了 和 智囊团.
当我帮助客户选择供应商时，决策的重点是谁可以提供最好的支持，而不是纯粹的功能。 这会根据客户规模、用例等而变化。是的 - 主要是人为因素很重要，我敢说，是共鸣。
我没有最喜欢的供应商。 从本质上讲，它们的功能非常相似 - 我经常在它们之上构建自定义工具来满足我的需求。
这是一个 视频系列 其中对上述三个供应商的相对优势和劣势进行了实时评论。
问：我应该如何版本和管理提示？
将提示保持在代码附近与非技术利益相关者可以访问的环境之间存在不可避免的紧张关系。
我首选的方法是将提示存储在 Git 中。 这将它们视为与应用程序代码一起进行版本控制、审查和部署的软件工件。 虽然 Git 命令行对于非技术人员来说并不友好， GitHub Web 界面和 GitHub 桌面应用让它非常易于接近。
当我在 GitHub 工作时，我与许多非技术专业人士合作过，包括律师和会计师，他们都有效地使用这些工具。这里有一个博客文章针对非技术人员入门。
或者，LLM 工具领域的大多数供应商，例如像 Arize、Braintrust 和 LangSmith 这样的可观测性平台，都提供专门的提示管理工具。这些工具可用于快速迭代，但可能会增加额外的间接层。
提示管理工具为何常常不尽如人意：AI 产品通常涉及许多环节：工具、RAG、代理等。提示管理工具本质上是有限制的，因为它们无法轻松执行你的应用程序代码。
即使它们可以执行，通常也涉及大量间接操作，使得使用系统的功能测试提示变得困难。
在可能的情况下，笔记本提供了进行提示实验的绝佳解决方案如果你的代码库有 Python 入口点，或者你的代码库是用 Python 编写的，那么 Jupyter 笔记本在这个方面特别强大。
你可以实验提示，并用完整的工具和 RAG 功能迭代你的实际 AI 代理。这使得理解你的系统在实践中如何运作变得更加容易。此外，你可以在笔记本中创建小部件和小型用户界面，为实验和迭代提供两全其美的体验。
要了解这在实践中是怎样的，Teresa Torres 提供了一个非常棒的亲身操作演示，展示了她作为产品经理如何使用笔记本进行整个评估和实验生命周期：
在 YouTube 上观看 “从新手到一周内自动评估（作为产品经理）与 Teresa Torres”
如果笔记本不适用于您的代码库， 集成提示环境 可以有效地进行实验。 不管怎样，我更喜欢在 Git 中对提示进行版本控制和管理。
问：系统提示符与用户提示符应该包含什么？
没有什么比实验更好的了。 使用您的特定模型和用例测试这两种方法（最好使用评估）。 模型以不同的方式处理系统和用户提示，并且这些差异因提供程序和模型版本而异。 在提示和测量之间移动指令，从而为您的特定任务产生更好的结果。
一般准则: 将静态指令和角色定义放入系统提示符中。 将动态内容、示例和特定于任务的详细信息放入用户提示中。 将系统提示视为模型的宪法——适用于所有请求的规则。 包括身份、行为限制、输出格式要求和长期指示：“你是一名医疗助理。 切勿提供诊断。 始终建议咨询医疗保健提供者。”
用户提示包含实际任务、相关上下文、少量示例和要处理的数据。 用于分析、查询特定变体和上下文信息的文档都属于此处。 当感觉区别不清楚时，更喜欢用户提示。 它更易于跨模型移植并且更易于调试。
生产与部署
问：CI/CD 与监控生产中的评估使用有何不同？
CI 评估可以在部署之前防止已知的回归。 在线监控发现生产流量中的故障并估计它们发生的频率。
CI 中的评估
CI 的测试数据集很小（在许多情况下有 100 多个示例）并且是专门构建的。 示例涵盖核心功能、过去错误的回归测试以及已知的边缘情况。 由于 CI 测试经常运行，因此必须仔细考虑每个测试的成本（这就是您仔细整理数据集的原因）。与法学硕士作为法官的评估者相比，更倾向于断言或其他确定性检查。
生产在线监控
为了评估生产流量，您可以对实时跟踪进行采样并针对它们异步运行评估器。 由于您通常缺乏生产数据的参考输出，因此您可能更多地依赖更昂贵的无参考评估器，例如 LLM-as-judge。 此外，跟踪生产指标的置信区间。 如果下限超过您的阈值，请进一步调查。
连接两个系统
这两个系统是互补的：当生产监控通过错误分析和评估揭示新的故障模式时，将代表性示例添加到 CI 数据集中。 这减轻了新问题的回归。
这里有个视觉图这有助于形成对比。
问：护栏和评估员有什么区别？
护栏包括在线安全检查它们直接位于请求/响应路径中。它们用于验证输入或输出之前任何信息都能到达用户，因此通常包括：
- 快速且确定性——通常需要几毫秒的延迟预算。
- 简单且可理解– 正则表达式、关键词块列表、模式或类型验证器、轻量级分类器。
- 针对明显、高影响的故障—— PII 泄露、脏话、禁止指令、SQL 注入、格式错误的 JSON、无效代码语法等。
如果护栏触发，系统可以遮蔽、拒绝或重生成该响应。由于这些检查在触发时用户可见，误报被视为生产漏洞;团队负责版本护栏规则，记录每个触发，并监控速率以保持保守。
另一方面，评估员通常会跑之后生成了回答。评估者衡量简单规则无法测量的品质，如事实正确性、完整性等。他们的结论为仪表盘、回归测试和模型改进循环提供信息，但不会阻碍原始答案。
评估器通常异步或批量运行，以承担较重的计算能力，例如法学博士作为评审.作为法官的LLM可以在线使用只有当延迟预算和可靠性目标允许时。
慢速LLM法官在边缘案件的级联中可能可行。
立即设置防护措施，防止客观失效需要干预。使用评估器监控并改进主观或细致入微的标准。这些因素共同创造了多层保护。
提醒一下：不要盲目使用现成的LLM护栏。一定要看看提示词.
问：我的评估员也可以自动使用修复或没错生产中的产出？
是的，但只涉及其中的特定子集。这就是区分评估器以及一个护栏这是我们之前讨论过的。提醒一下：
- 评估员通常运行异步在生成响应之后。它们衡量质量，但不干扰用户的即时体验。
- 护栏跑同步在请求的关键路径中，在输出显示给用户之前。他们的工作是实时防止高影响的失败。
决定是否使用评估员作为护栏有两个重要的决策标准：
- 延迟与成本：评估器能否在关键请求路径中运行足够快且足够低廉，而不影响用户体验？
- 错误率权衡：假阳性（阻断优质输出并令用户沮丧）与假阴性（让不良输出传到用户手中并造成伤害）之间的成本效益平衡如何？在医疗建议等高风险领域，假阴性可能比假阳性更昂贵。在创意应用中，阻碍真实创造力的假阳性可能比偶尔的质量问题更具危害性。
大多数护栏设计就是这样几乎（以避免损害用户体验）并且有非常低的假阳性率（以避免阻断有效响应）。因此，你几乎不会用慢速或非确定性的LLM作为法官作为同步护栏。
不过，这些权衡可能会因你的使用场景而异。
问：我应该花多少时间在模型选择上？
许多开发者执着于模型选择作为提升大型语言模型应用的主要途径。在考虑模型切换之前，先从错误分析开始，了解你的故障模式。正如Hamel在办公时间所说：“我建议不要在没有证据的情况下，把切换模型当作改进系统的主要方向。错误分析是否暗示你的模型是问题所在？”
领域特定应用
问：RAG已经死了吗？
问题：看完这些后，我应该避免在我的AI应用中使用RAG吗“RAG死了”对于编码代理来说？
许多开发者在阅读了声称“RAG已死”的文章后，对何时以及如何使用RAG感到困惑。理解RAG的真正含义，而不是狭隘的营销定义，将帮助你为AI应用做出更好的架构决策。
那篇声称RAG已死的病毒式文章明确反对使用朴素向量数据库检索对于自主编码代理来说，而不是整个RAG的区别。这是一个许多开发者因误导性营销而忽视的关键区别。
RAG简单来说就是检索增强生成——利用检索提供相关上下文，从而提升模型的输出。核心原则依然至关重要：你的大型语言模型需要合适的上下文来生成准确的答案。
问题不在于是否使用检索，而在于如何有效地检索。
对于编码应用，朴素的向量相似性搜索常常失败，因为代码关系复杂且依赖上下文。现代编码助手如Claude Code并未完全放弃检索仍然使用取回——他们只是采用代理搜索，而不是仅依赖向量数据库，类似于人类开发者的工作方式。
你有多种检索策略可选，从简单的关键词匹配到嵌入相似度，再到基于LLM的相关性过滤。最佳方法取决于你的具体用例、数据特性和性能要求。
许多生产系统结合多种策略，或使用由LLM代理引导的多跳检索。
不幸的是，“RAG”已经成为一个没有统一定义的流行词。有些人用它指任何检索系统，也有人将其限制在向量数据库中。专注于最终目标：为你的大型语言模型提供成功所需的上下文。
无论是通过向量搜索、代理探索还是混合方法，都是产品和工程决策。
与其遵循绝对建议去避免或拥抱RAG，不如尝试不同的检索方法，衡量最适合你应用的方法。有关RAG评估和优化的更多信息，请参见本系列文章.
问：我应该如何评估编码代理？
如果你的编码代理处理各种任务，建议像使用基础模型一样使用公开基准测试。对于处理狭窄工作流程的代理，产品特定的评估更为合适。
该评估常见问题解答解释了这一区别。
流行的编码基准包括SWE工作台,终端工作台,帮助多语种， 和人类评估.
除了公开基准测试外，你还可以为组织中复杂的任务建立私有基准测试。OpenAI 描述了使用评估Codex的真实内部软件工程任务在启动时。
每个任务都需要一个工作环境和基于代码的测试，以确定代理是否成功完成了任务。
决定包含哪些任务，观察人们如何使用你的代理及其失败之处。与工程师一起审查运行，将反复出现的问题归类，并将有用的例子转化为测试。
这是误差分析，这同样适用于编码产品。如果已有测试已识别出失败，利用这些结果选择进行调查的运行。
人类的Clio研究示例了一种相关方法，按主题将聊天对话分组。你可以将这个理念应用于编码会话，以确定基准应涵盖的工作类型。
人类的编码代理评估指导建议从明确指定的任务开始，并建立一个稳定的环境，让单元测试能够验证结果。在你完成这些单元测试后，他们建议对测试未能捕捉到的内容添加检查，比如代码质量或代理如何与用户互动。
例如，Claude Code团队为文件编辑添加了评估，后来又增加了过度工程的评估。衡量文件编辑和过度工程的方法有很多，但你可以从新增的净代码行等指标开始圆复合复杂度.
约翰·贝里曼和肖恩·西米斯特的副驾驶谈话提供了更多编码代理评估的示例。对于代码补全，团队从仓库中移除函数实现，让模型重新生成，并运行现有测试。
对于聊天，他们使用了具有特定标准的LLM评判，并分别检查助手是否调用了正确的工具。他们还运行了A/B测试，跟踪用户是否接受建议并保存代码。
这些产品指标补充了离线评估。
问：我应该如何评估我的RAG系统？
RAG系统包含两个不同的组成部分，需要不同的评估方法：检索和生成。
从检索评估开始
检索部分是一个搜索问题。用传统的信息检索（IR）指标来评估。常见的例子包括Recall@k（所有相关文档中，你在前k中检索了多少？）、Precision@k（检索到的k文档中，有多少是相关的？）或MRR（第一个相关文档的位置有多高？）。
你选择的具体指标取决于你的使用场景。这些指标纯粹是搜索指标，用来衡量你是否找到了正确的文档（下面会详细说明）。
为了评估检索能力，创建一个查询及其相关文档的数据集。通过从语料库中提取文档，提取关键事实，然后生成这些事实能回答的问题，从而合成数据集。
这种反向过程可以为查询-文档对，用于测量检索性能，无需人工注释。
接下来，评估生成
关于生成组件，检查LLM对检索上下文的利用情况以及是否回答了问题。使用误差分析识别失败模式，收集人工标签，构建有针对性的大型语言模型评判，并对这些评判进行人工注释验证。
刘宇森的“只有6个RAG评估”提供了一个与这种分离良好对应的框架。他的第一层涵盖了传统的国际关系指标用于检索。第二层和第三层评估问题、上下文和答案之间的关系。
这些关系包括上下文是否相关（C|Q）、答案是否忠实于上下文（A|C）以及答案是否针对问题（A|Q).
除了Jason的六项评估外，对具体数据的错误分析还可能揭示领域特有的失败模式，这些模式需要单独的指标。例如，医疗RAG系统可能持续未能区分成人和儿童的药物剂量，或者法律RAG可能混淆了管辖区界限。
这些模式只有通过系统性审查实际失效才会显现。一旦识别出来，你可以在一般框架之外为这些具体问题创建有针对性评估者。
最后，在实现Jason的第二层和第三层指标时，不要随便使用现成的提示。标准的LLM作为评委流程包含多个步骤：错误分析、提示迭代、创建带标签的示例，以及衡量评委与人工标签的准确性。
一旦你知道评委的真实阳性和真负率，就可以修正其估计，确定系统中的实际失败率。跳过此验证，评委可能无法反映你的实际质量标准。
总之，首先使用IR指标进行调试，然后再利用经过充分验证的LLM评判来提升生成质量。
问：我如何为文档处理任务选择合适的区块大小？
与RAG优化区块以利检索不同，文档处理假设模型会看到每一个区块。目标是拆分文本，使模型能够有效推理而不被淹没。即使文档属于上下文窗口，拆分窗口可能更好。
长时间输入会因注意力瓶颈而降低性能，尤其是在上下文中间。两种任务类型需要不同的策略：
1. 固定输出任务→大块
这些任务的输出长度不会随输入增加而增加：提取数字、回答特定问题、分类某一部分。例如：
- “这份合同里的罚款条款是什么？”
- “2023年CEO的薪水是多少？”
使用可能包含答案的最大块（有附带注意事项）。这样可以减少查询数量，避免上下文碎片化。但请避免添加无关文本。模型对干扰非常敏感，尤其是输入量大时。
长输入的中间部分可能被忽视。此外，如果成本和延迟是瓶颈，你应考虑通过关键词搜索或轻量级检索器对文档进行预处理或筛选，以在输入大量数据前隔离相关部分。
2. 扩展输出任务→较小的块
这些包括总结、穷尽提取，或任何输出随输入增长的任务。例如：
- “总结每个部分”
- “列出所有客户投诉”
在这种情况下，较小的块有助于保持推理质量和输出完整性。标准方法是分别处理每个块，然后汇总结果（例如映射缩减）。在调整块大小时，尽量尊重段落、章节或章节等内容边界。
分块还有助于缓解输出限制。通过将任务拆分成多个部分，每个部分的输出可以保持在限制范围内。
一般指导
认识到这一点很重要为什么区块大小会影响结果.更大的块意味着模型必须一次性推理更多信息——本质上，认知负载更重。大型语言模型（LLM）的能力有限保留并关联长篇文本中的细节.如果内容过多，模型可能会优先考虑某些部分（通常是开头或结尾），而忽略或“遗忘”中间的细节。
这可能导致总结过于粗糙或遗漏事实。相比之下，较小的部分限制了问题：模型可以完全关注该部分。你是在权衡本地关注的全球背景.
没有经验法则能完美确定最适合你使用场景的块大小——你应该通过实验来验证.最佳区块大小会因领域和模型而异。我把区块大小当作一个需要调优的超参数。
问：我如何调试多回合对话追踪？
从简单开始。用通过/不通过判断检查整个对话是否达到用户的目标。查看整个走线，重点关注第一个上游故障。先阅读用户可见的部分，了解是否出现了问题。
然后再深入技术细节，比如工具调用和中间步骤。
多智能体跟踪日志
对于多代理流程，为每个用户请求分配会话或跟踪ID，并记录每条消息的源（哪个代理或工具）、跟踪ID以及序列中的位置。这样你可以重建从初始查询到最终结果的所有代理的完整路径。
注释策略
一开始只在走线中注注第一个故障。下游故障通常从第一个问题连锁而来，因此修复上游故障可以解决相关故障。随着经验积累，你可以在同一条线内标注独立的故障模式，以加快错误分析。
尽可能简化
当你发现失败时，用最简单的测试用例重现它。举个例子：假设购物机器人在对话的第4回合给出了错误的退货政策。在深入探讨完整的多回合复杂性之前，先简化为一回合：“X1000产品的退货窗口是多少？”如果仍然失败，说明你已经证明错误不是对话上下文的问题——很可能是基本的检索或知识问题，你可以更容易调试。
测试用例生成
你有两种主要方法。首先，用另一个大型语言模型模拟用户，创建真实的多回合对话。其次，使用“N-1测试”，即提供真实对话的前N-1回合，测试接下来发生的事情。
N-1方法通常效果更好，因为它使用实际的对话前缀而非完全合成的交互，但灵活性较低。
关键在于在全面性与效率之间取得平衡。并非每一次多回合失效都需要多层次分析。
当对话涉及工具或多个代理时，使用过渡失败矩阵来寻找错误热点。
问：如何评估有人工交接的会话？
在你的追踪中完整记录用户旅程，包括人工切换。追踪会持续到用户需求得到解决或会话结束，而不是在AI交接给人类时。记录切换决策、发生原因、上下文传输、等待时间、人工操作、最终解决以及人类是否拥有足够的上下文。
许多失败发生在切换边界时，AI交接过早、太晚或缺乏适当上下文。
在错误分析中评估交接是否可能出现故障。问：交接是否必要？AI是否提供了足够的背景信息？同时跟踪交接质量和交接率。有时最好的改进是完全减少交接次数，而非提升交接执行。
问：我如何评估复杂的多步骤工作流程？
记录从初始触发到最终业务结果的整个工作流程。在跟踪中包括LLM调用、工具使用、人工审批和数据库写入。你需要这些可视化来正确诊断故障。
同时使用结果和流程指标。结果指标验证最终结果是否符合要求：业务案例是否完整？准确吗？格式是否正确？流程指标评估效率：步数、所用时间、资源使用。
流程故障通常更容易调试，因为它们更具确定性，所以先解决它们。
按工作流程阶段划分错误分析。早期失败（理解用户输入）与中期失败（数据处理）和后期失败（格式化输出）不同。早期改进影响更大，因为错误在大型语言模型链中会连锁反应。
使用过渡失败矩阵分析工作流程中断的区域。创建一个矩阵，显示最后一次成功状态与首次失败发生的位置。这揭示了故障热点，并指导调试工作投入到哪里。
问：我如何评估代理性工作流程？
我们建议将代理性工作流程分为两个阶段进行评估：
1. 端到端任务的成功。将代理视为黑箱，判断它是否达到用户目标。为每个任务定义精确的成功规则，并通过人工审核进行衡量。认证的LLM法官.在错误分析中记录第一个上游故障。
一旦错误分析揭示了哪些工作流程最常失败，就转向步骤级诊断，了解它们为何失败。
2. 步级诊断。请先记录系统的痕迹你可以给单个组成部分评分，例如：
- 工具选择：检查代理是否选择了合适的工具。
- 参数提取检查输入是否完备且结构良好。
- 错误处理检查代理是如何处理空结果或 API 失败的。
- 上下文保留： 检查代理是否保留了之前的约束。
- 效率：计算所花费的步数、秒数和代币数。
- 目标检查点：在长期工作流程中验证关键里程碑。
我该如何测试工具调用？
测试工具名称、参数、结果和结果状态作为独立检查。当预期行为是客观的时，使用代码断言。例如，验证所选代理cancel_order，传递了正确的订单ID，收到了成功的回复，并在通知用户取消成功之前更改了订单状态。
同时测试授权和前提条件。如果用户未批准操作或系统跳过了必要的检查，有效的工具调用仍可能出错。
例如：“在伯克利寻找低于100万美元的房屋并安排看房”的拆解方式包括：正确提取参数、检索相关房源、检查可用性以及发送日历邀请。
每个检查点都可以独立通过或失败，使调试变得易于操作。
使用过渡失败矩阵来理解错误模式。创建一个矩阵，行代表最后一次成功状态，列代表第一次失败发生的位置。这是了解失败最多地点的好方法。
转换矩阵显示故障聚集的位置。在这个例子中，GenSQL → ExecSQL 转换导致 12 次失败，而 DecideTool → PlanCal 仅造成 2 次失败。
计数显示了应先调查哪些地方。这里还有一个例子文本转SQL示例来自布莱恩·比肖夫：
在这个例子中，Bryan 展示了不同实验间转换矩阵的差异。你如何组织转换矩阵取决于你应用的具体情况。例如，Bryan 的文本转 SQL 代理具有固有的顺序工作流程，他利用这一点来进一步分析。
你可以观看他的完整讲话更多细节请阅读。
创建代理失败测试用例
创建代理失败测试用例遵循我们之前关于调试多回合对话追踪的常见问题解答的原则。用最简单的测试重现仍然失败的错误。只有当失败依赖于对话上下文时，才使用多回合测试。
👉想了解更多关于人工智能评估的信息吗？请查看我们的AI评估课程.这是一个现场的队列，包含动手练习和办公时间。这里有25%折扣码给读者看。
👈
注释
- 保罗·格雷厄姆，“写与写不写”↩︎
- 施雷亚·尚卡尔等人，“谁来验证验证者？”将LLM辅助评估的LLM输出与人类偏好相结合↩︎
点赞
收藏
点踩
分享
