ai-agents-for-beginners

生产环境中的 AI 代理:可观测性与评估

生产环境中的 AI 代理

随着 AI 代理从实验性原型转向真实世界应用,理解其行为、监控其性能并系统地评估其输出变得非常重要。

学习目标

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

目标是为您提供将“黑箱”代理转变为透明、可管理且可靠系统的知识。

注意: 部署安全且可信的 AI 代理非常重要。也请查看 构建可信赖的 AI 代理 这课。

跟踪(Trace)与跨度(Span)

诸如 LangfuseMicrosoft Foundry 等可观测性工具通常将代理运行表示为跟踪和跨度。

Langfuse 中的跟踪树

没有可观测性,AI 代理可能像一个“黑盒”——其内部状态和推理是不透明的,使得诊断问题或优化性能变得困难。有了可观测性,代理变成“玻璃盒”,提供透明性,这对于建立信任并确保其按预期运行至关重要。

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

将 AI 代理迁移到生产环境会带来一套新的挑战和需求。可观测性不再是“可有可无”,而是一项关键能力:

需要跟踪的关键指标

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

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

延迟(Latency): 代理响应有多快?长时间的等待会对用户体验产生负面影响。您应通过跟踪代理运行来衡量任务和各个步骤的延迟。例如,一个所有模型调用总共耗时 20 秒的代理可以通过使用更快的模型或并行运行模型调用来加速。

成本(Costs): 每次代理运行的费用是多少?AI 代理依赖按令牌计费的 LLM 调用或外部 API。频繁使用工具或多次提示会迅速增加成本。例如,如果一个代理为了边际质量提升而调用 LLM 五次,则必须评估该成本是否合理,或是否可以减少调用次数或使用更便宜的模型。实时监控也可以帮助识别意外的费用激增(例如,导致过多 API 循环的 bug)。

请求错误(Request Errors): 代理失败的请求有多少?这可以包括 API 错误或工具调用失败。为了使代理在生产中更具鲁棒性,您可以设置回退或重试。例如,如果 LLM 提供商 A 出现故障,您可以切换到 LLM 提供商 B 作为备份。

用户反馈(User Feedback): 实施直接的用户评估可提供有价值的见解。这可以包括显式评分(👍thumbs-up/👎down、⭐1-5 星)或文本评论。持续的负面反馈应提醒您,这是代理未按预期工作的一种信号。

隐式用户反馈(Implicit User Feedback): 即使没有显式评分,用户行为也会提供间接反馈。这可以包括立即改写问题、重复查询或点击重试按钮等行为。例如,如果您发现用户反复询问同一问题,这表明代理未按预期工作。

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

自动评估指标(Automated Evaluation Metrics): 您还可以设置自动评估。例如,可以使用 LLM 对代理的输出进行评分,例如判断其是否有帮助、是否准确等。也有若干开源库帮助您对代理的不同方面进行评分,例如用于 RAG 代理的 RAGAS 或用于检测有害语言或提示注入的 LLM Guard

在实践中,结合这些指标可以最好地覆盖 AI 代理的健康状况。在本章的 示例笔记本 中,我们将向您展示这些指标在真实示例中的表现,但首先,我们将了解典型的评估工作流。

为代理添加监控/埋点

要收集跟踪数据,您需要对代码进行埋点/监控。目标是对代理代码进行埋点,以发出可被可观测性平台捕获、处理和可视化的跟踪和指标。

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

有许多封装现有代理框架的监控库,可轻松地将 OpenTelemetry spans 导出到可观测性工具中。Microsoft Agent Framework 原生集成了 OpenTelemetry。下面是为一个 MAF 代理进行埋点的示例:

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
    # 代理的执行会被自动跟踪
    pass

本章的 示例笔记本 将演示如何对您的 MAF 代理进行埋点。

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

使用 Langfuse Python SDK 手动创建跟踪和跨度的示例:

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

代理评估

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

定期评估很重要,因为 AI 代理往往具有非确定性,并且可能会随着更新或模型行为漂移而演变——如果没有评估,您无法知道“智能代理”是否真正完成了它的工作,或者是否出现了回退。

AI 代理的评估分为两类:在线评估离线评估。两者都很有价值且互为补充。我们通常从离线评估开始,因为这是在部署任何代理之前必须完成的最低步骤。

离线评估

Langfuse 中的数据集项

这包括在受控环境中评估代理,通常使用测试数据集,而不是实时用户查询。您使用有已知预期输出或正确行为的策划数据集,然后在这些数据集上运行代理。

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

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

在线评估

可观测性指标概览

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

例如,您可能会跟踪实时流量中的成功率、用户满意度评分或其他指标。在线评估的优势在于它捕捉实验室环境中可能难以预见的情况——您可以观察随着输入模式变化而出现的模型漂移(如果代理的效果随时间下降)并发现测试数据中没有的意外查询或情形。这提供了代理在真实环境中行为的真实画像。

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

两者结合

在线和离线评估并不互斥;它们高度互补。来自在线监控的洞察(例如代理在某些新型用户查询上表现不佳)可以用于增强和改进离线测试数据集。反之,在离线测试中表现良好的代理可以更有信心地部署到线上并进行监控。

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

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

常见问题

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

问题 潜在解决方案
AI 代理无法稳定执行任务 - 优化提供给 AI 代理的提示;明确目标。
- 确认将任务拆分为子任务并由多个代理分别处理是否有帮助。
AI 代理陷入持续循环 - 确保您有清晰的终止条件,使代理知道何时停止流程。
- 对于需要推理和规划的复杂任务,使用专门用于推理任务的更大模型。
AI 代理的工具调用表现不佳 - 在代理系统之外测试并验证工具的输出。
- 优化工具的参数、提示和命名。
多代理系统表现不稳定 - 优化分配给每个代理的提示,确保它们具体且彼此区分。
- 使用“路由”或控制器代理构建分层系统,以确定哪个代理是正确的。

许多此类问题在具备可观测性后可以更有效地识别。我们之前讨论的跟踪和指标有助于精确定位代理工作流中出现问题的位置,从而使调试和优化更高效。

管理成本

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

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

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

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

让我们看看这在实践中如何运作

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

关于在生产中部署 AI 代理还有更多问题吗?

加入 Microsoft Foundry Discord,与其他学习者交流、参加答疑时段,并获得关于 AI 代理的问题解答。

上一课

元认知设计模式

下一课

代理式协议


免责声明: 本文件使用 AI 翻译服务 Co-op Translator 进行翻译。尽管我们尽力保证准确性,但请注意,自动翻译可能存在错误或不准确之处。原始语言的文档应视为具有权威性的来源。对于关键信息,建议采用专业人工翻译。因使用本翻译而产生的任何误解或误释,我们概不负责。