ai-agents-for-beginners

投产中的 AI Agent:可观测性与评估

投产中的 AI Agent

当 AI Agent 从实验性原型转向实际应用时,理解其行为、监控其性能以及系统性地评估其输出的能力变得尤为重要。

学习目标

完成本课后,您将了解如何/理解:

目标是让您掌握将“黑箱”Agent 转变为透明、可管理且可靠系统的知识。

注意: 部署安全且值得信赖的 AI Agent 非常重要。请查看构建值得信赖的 AI Agent课程。

Trace 和 Span

可观测性工具(如 LangfuseAzure AI Foundry)通常将 Agent 的运行表示为 Trace 和 Span。

Langfuse 中的 Trace 树

没有可观测性时,AI Agent 就像一个“黑箱”——其内部状态和推理过程不透明,难以诊断问题或优化性能。有了可观测性,Agent 就变成了“玻璃箱”,提供了透明性,这对建立信任和确保其按预期运行至关重要。

为什么可观测性在生产环境中很重要

将 AI Agent 转移到生产环境会带来一系列新的挑战和需求。此时,可观测性不再是“可有可无”的功能,而是关键能力:

需要跟踪的关键指标

为了监控和理解 Agent 的行为,需要跟踪一系列指标和信号。尽管具体指标可能因 Agent 的用途而异,但有些指标是普遍重要的。

以下是可观测性工具通常监控的一些常见指标:

延迟: Agent 响应的速度如何?长时间等待会对用户体验产生负面影响。您应该通过跟踪 Agent 的运行来测量任务和单个步骤的延迟。例如,一个在所有模型调用上耗时 20 秒的 Agent 可以通过使用更快的模型或并行运行模型调用来加速。

成本: 每次 Agent 运行的费用是多少?AI Agent 依赖于按 token 计费的 LLM 调用或外部 API。频繁的工具使用或多次提示可能会迅速增加成本。例如,如果一个 Agent 为了微小的质量提升调用 LLM 五次,您需要评估这种成本是否值得,或者是否可以减少调用次数或使用更便宜的模型。实时监控还可以帮助识别意外的成本激增(例如,由于错误导致的过多 API 循环)。

请求错误: Agent 失败的请求有多少?这可能包括 API 错误或工具调用失败。为了使 Agent 在生产中更具鲁棒性,您可以设置备用方案或重试机制。例如,如果 LLM 提供商 A 宕机,您可以切换到 LLM 提供商 B 作为备份。

用户反馈: 实施直接的用户评价可以提供宝贵的见解。这可以包括显式评分(👍/👎,⭐1-5 星)或文本评论。持续的负面反馈应引起警觉,因为这表明 Agent 未按预期工作。

隐式用户反馈: 用户行为即使没有显式评分也能提供间接反馈。这可能包括立即重新措辞问题、重复查询或点击重试按钮。例如,如果您发现用户反复提出相同的问题,这表明 Agent 未按预期工作。

准确性: Agent 生成正确或期望输出的频率如何?准确性的定义可能不同(例如,解决问题的正确性、信息检索的准确性、用户满意度)。第一步是定义成功对 Agent 的意义。您可以通过自动检查、评估分数或任务完成标签来跟踪准确性。例如,将 Trace 标记为“成功”或“失败”。

自动评估指标: 您还可以设置自动评估。例如,您可以使用 LLM 对 Agent 的输出进行评分,例如是否有帮助、准确或无害。还有一些开源库可以帮助您评估 Agent 的不同方面。例如,RAGAS 用于 RAG Agent,LLM Guard 用于检测有害语言或提示注入。

实际上,这些指标的组合可以最好地覆盖 AI Agent 的健康状况。在本章的示例笔记本中,我们将展示这些指标在实际案例中的表现,但首先,我们将学习一个典型的评估工作流程。

为 Agent 添加监控

为了收集 Trace 数据,您需要为代码添加监控。目标是为 Agent 代码添加监控,使其能够生成 Trace 和指标,这些数据可以被可观测性平台捕获、处理和可视化。

OpenTelemetry (OTel): OpenTelemetry 已成为 LLM 可观测性的行业标准。它提供了一套 API、SDK 和工具,用于生成、收集和导出遥测数据。

有许多监控库可以包装现有的 Agent 框架,并使其能够轻松地将 OpenTelemetry 的 Span 导出到可观测性工具。以下是使用 OpenLit 监控库 为 AutoGen Agent 添加监控的示例:

import openlit

openlit.init(tracer = langfuse._otel_tracer, disable_batch = True)

本章的示例笔记本将演示如何为 AutoGen Agent 添加监控。

手动创建 Span: 尽管监控库提供了良好的基础,但在某些情况下可能需要更详细或自定义的信息。您可以手动创建 Span 来添加自定义应用逻辑。更重要的是,您可以通过自定义属性(也称为标签或元数据)丰富自动或手动创建的 Span。这些属性可以包括业务特定数据、中间计算或任何可能对调试或分析有用的上下文,例如 user_idsession_idmodel_version

以下是使用 Langfuse Python SDK 手动创建 Trace 和 Span 的示例:

from langfuse import get_client
 
langfuse = get_client()
 
span = langfuse.start_span(name="my-span")
 
span.end()

Agent 评估

可观测性为我们提供了指标,而评估则是分析这些数据(并进行测试)以确定 AI Agent 的表现如何以及如何改进的过程。换句话说,一旦您拥有了这些 Trace 和指标,如何利用它们来评估 Agent 并做出决策?

定期评估很重要,因为 AI Agent 通常是非确定性的,并且可能会随着更新或模型行为的漂移而演变——如果没有评估,您无法知道您的“智能 Agent”是否真的在做好工作,或者是否出现了性能退化。

AI Agent 的评估分为两类:离线评估在线评估。两者都很有价值,且相辅相成。我们通常从离线评估开始,因为这是部署任何 Agent 前的最低必要步骤。

离线评估

Langfuse 中的数据集项

离线评估是在受控环境中评估 Agent,通常使用测试数据集,而不是实时用户查询。您使用经过精心挑选的数据集,这些数据集中您知道期望的输出或正确的行为,然后让 Agent 在这些数据集上运行。

例如,如果您构建了一个数学文字题 Agent,您可能会有一个包含已知答案的 测试数据集,其中有 100 道题目。离线评估通常在开发过程中进行(并且可以成为 CI/CD 流水线的一部分),以检查改进或防止性能退化。其优点是可重复,并且由于有标准答案,您可以获得明确的准确性指标。您还可以模拟用户查询,并将 Agent 的响应与理想答案进行比较,或者使用上述的自动化指标。

离线评估的关键挑战在于确保测试数据集全面且保持相关性——Agent 可能在固定测试集上表现良好,但在生产中遇到完全不同的查询。因此,您应不断更新测试集,加入新的边界情况和反映真实场景的示例。混合使用小型“冒烟测试”案例和大型评估集是有用的:小型集用于快速检查,大型集用于更广泛的性能指标。

在线评估

可观测性指标概览

在线评估是指在实时、真实环境中评估 Agent,即在生产中实际使用时进行评估。在线评估涉及监控 Agent 在真实用户交互中的表现,并持续分析结果。

例如,您可能会跟踪成功率、用户满意度评分或其他实时流量指标。在线评估的优势在于它捕捉到实验室环境中可能无法预见的情况——您可以观察到模型随时间的漂移(例如,随着输入模式的变化,Agent 的效果是否下降),并发现测试数据中未包含的意外查询或情况。它提供了 Agent 在实际环境中表现的真实画面。

在线评估通常涉及收集隐式和显式用户反馈(如前所述),并可能运行影子测试或 A/B 测试(即新版本的 Agent 与旧版本并行运行以进行比较)。挑战在于为实时交互获取可靠的标签或评分可能很棘手——您可能需要依赖用户反馈或下游指标(例如用户是否点击了结果)。

两者结合

在线评估和离线评估并非互斥,而是高度互补的。在线监控中的洞察(例如 Agent 在某些新类型用户查询中的表现不佳)可以用来扩充和改进离线测试数据集。反之,在离线测试中表现良好的 Agent 可以更有信心地部署并进行在线监控。

事实上,许多团队采用一个循环:

离线评估 -> 部署 -> 在线监控 -> 收集新的失败案例 -> 添加到离线数据集 -> 优化 Agent -> 重复

常见问题

在将 AI Agent 部署到生产环境时,您可能会遇到各种挑战。以下是一些常见问题及其潜在解决方案:

问题 潜在解决方案
AI Agent 无法一致地完成任务 - 优化提供给 AI Agent 的提示词;明确目标。
- 确定是否可以将任务分解为子任务,并由多个 Agent 处理。
AI Agent 陷入连续循环 - 确保您设置了明确的终止条件,以便 Agent 知道何时停止流程。

通过引入可观测性,许多问题可以更有效地被识别。我们之前讨论的跟踪和指标可以精确定位代理工作流中问题发生的位置,从而使调试和优化更加高效。

成本管理

以下是一些管理将AI代理部署到生产环境成本的策略:

使用较小的模型: 小型语言模型(SLM)在某些代理任务中表现良好,并能显著降低成本。如前所述,构建一个评估系统来比较小型模型与大型模型的性能是了解SLM在您的用例中表现的最佳方式。可以考虑将SLM用于较简单的任务,例如意图分类或参数提取,而将大型模型保留用于复杂推理任务。

使用路由模型: 类似的策略是使用多样化的模型和规模。您可以使用LLM/SLM或无服务器函数根据复杂性将请求路由到最合适的模型。这不仅能降低成本,还能确保在正确的任务上获得良好的性能。例如,将简单查询路由到较小、更快的模型,而仅在复杂推理任务中使用昂贵的大型模型。

缓存响应: 识别常见请求和任务,并在它们进入代理系统之前提供响应,是减少类似请求量的好方法。您甚至可以实现一个流程,使用更基础的AI模型来识别请求与缓存请求的相似度。这种策略可以显著降低针对常见问题或工作流的成本。

实践中的应用

本节的示例笔记本中,我们将看到如何使用可观测性工具来监控和评估代理的示例。

对生产环境中的AI代理有更多疑问?

加入 Azure AI Foundry Discord,与其他学习者交流,参加答疑时间,并解答您的AI代理相关问题。

上一课

元认知设计模式

下一课

代理协议


免责声明
本文档使用AI翻译服务 Co-op Translator 进行翻译。尽管我们努力确保翻译的准确性,但请注意,自动翻译可能包含错误或不准确之处。原始语言的文档应被视为权威来源。对于重要信息,建议使用专业人工翻译。我们不对因使用此翻译而产生的任何误解或误读承担责任。