LangChain 应用程序部署后,仅仅确保其运行是不够的。生产系统需要持续观察,以验证它们是否达到性能预期并在预算范围内运行。大语言模型(LLM)的非确定性以及链式操作的复杂性,使得监控应用程序性能和成本显得尤为重要。忽视这一点可能导致用户体验下降、开销不断增加以及难以诊断间歇性问题。有效的监控涉及追踪特定的性能指标(KPI)和资源消耗模式。我们来探讨一下主要的衡量标准和方法。性能指标(KPI)追踪正确的性能衡量标准可以帮助了解应用程序的响应速度和可靠性。延迟: 这衡量了处理请求所需的时间。区分以下几种情况通常很有帮助:端到端延迟: 从接收用户请求到发送最终响应的总时间。这直接影响用户体验。组件延迟: 在 LangChain 应用程序特定部分花费的时间,例如单个大语言模型调用、数据检索步骤、工具执行或解析逻辑。找到缓慢的组件对于优化非常重要。 高延迟可能源于缓慢的大语言模型推理、效率不高的检索查询、复杂的后处理或网络延迟。LangSmith 等工具能自动追踪执行流程,为链或智能体调用中的每一步提供细致的延迟数据,从而更易于查明瓶颈。错误率: 监控错误的频率和类型是评估可靠性的根本。LangChain 应用程序中常见的错误类别包括:大语言模型 API 错误: 大语言模型提供商的速率限制、认证问题、服务器错误。工具执行错误: 智能体尝试使用工具时发生的故障(例如,API 关闭、参数无效、意外输出)。解析错误: 无法将大语言模型的输出解析为所需格式(例如,格式错误的 JSON、不正确的结构)。数据检索错误: 连接或查询向量存储或其他数据源时出现的问题。应用程序逻辑错误: 您自定义代码中封装或协调 LangChain 组件时存在的错误。 追踪错误率(通常表示为总请求的百分比)有助于找出系统性问题。分析错误类型可以指向根本原因,无论是基础设施不稳定、提示词脆弱性还是工具实现中的错误。LangSmith 通过自动标记遇到异常的运行来简化错误追踪。吞吐量: 这衡量了您的应用程序每单位时间(例如,每秒或每分钟请求数)能够成功处理的请求数量。了解吞吐量限制对于容量规划和确保您的应用程序能够根据需求进行扩展非常重要。它通常受单个请求的延迟和可用计算资源的影响。成本管理和令牌使用追踪大语言模型的使用通常根据处理的令牌数量(输入和输出)计费。未经监控的应用程序可能导致意想不到的高成本。令牌使用量: 这通常是主要的成本驱动因素。准确追踪需要监控:输入令牌: 发送给大语言模型的令牌(提示词、上下文、历史记录)。输出令牌: 大语言模型生成的令牌(响应)。 大多数大语言模型提供商会在其 API 响应中返回令牌计数。LangChain 与大语言模型的集成通常会自动捕获此信息。LangSmith 提供内置的每追踪令牌使用量追踪和聚合功能,使您能够分析与特定请求、链或智能体相关的成本。您可以可视化令牌消耗随时间变化的趋势,或按不同的应用程序功能或用户组细分使用量。# 使用 OpenAI 回调获取令牌使用量的示例 from langchain_openai import ChatOpenAI from langchain_core.callbacks import get_openai_callback from langchain_core.prompts import ChatPromptTemplate llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个乐于助人的助手。"), ("human", "{input}") ]) chain = prompt | llm with get_openai_callback() as cb: response = chain.invoke({"input": "给我讲个短笑话。"}) print(response.content) print(f"\nTotal Tokens: {cb.total_tokens}") print(f"Prompt Tokens: {cb.prompt_tokens}") print(f"Completion Tokens: {cb.completion_tokens}") print(f"Total Cost (USD): ${cb.total_cost:.6f}") # 需要设置定价信息 # 启用追踪后,LangSmith 会自动捕获此信息,无需显式回调。基础设施成本: 除了直接的大语言模型 API 调用外,还要考虑与托管您的应用程序(服务器、容器、无服务器函数)、运行向量数据库、数据存储和网络流量相关的成本。这些成本通常随使用量和请求量而增长。成本计算与归因: 通过将令牌使用量数据与大语言模型提供商的定价模型(例如,每 1K 输入令牌成本、每 1K 输出令牌成本)结合,您可以计算每请求的估计成本或聚合长期成本。在生产环境中,一项重要任务是将成本归因于特定的应用程序功能、租户(在多租户应用程序中)或用户操作。这通常涉及在 LangSmith 或您的监控系统中为请求或追踪添加相关的元数据标签。监控工具和方法多种工具和方法有助于监控性能和成本:LangSmith: 如前说明,LangSmith 专为观察 LangChain 应用程序而设计。它自动捕获追踪,包括延迟分解、令牌计数、错误和相关元数据。其仪表盘使能够可视化趋势并根据各种条件(例如,性能阈值、错误存在、特定标签)过滤运行。LangChain 回调: 您可以实现自定义的 CallbackHandler 来拦截链/智能体执行期间的事件(例如,on_llm_end、on_chain_start、on_tool_error)。这些回调可用于记录详细的性能数据、计算令牌使用量,或将指标发送到外部监控系统,如 Prometheus、Datadog 或自定义数据库。标准日志记录: 使用 Python 内置的 logging 模块来记录未被追踪自动捕获的应用程序级事件、错误和警告。有效组织您的日志,以便于解析和分析。应用程序性能监控(APM)系统: Datadog、Dynatrace、New Relic 等工具,或像 Prometheus 结合 Grafana 这样的开源替代方案,提供更广泛的基础设施和应用程序监控。将 LangChain 应用程序指标(通过回调或自定义日志记录)整合到这些系统中,可以全面了解系统健康状况。可视化和警报如果没有有效的可视化和警报,原始指标的用处会降低。仪表盘: 创建仪表盘(在 LangSmith、Grafana 或其他 APM 工具中)以可视化 KPI 和随时间变化的成本趋势。这有助于发现性能退步、成本异常或逐渐下降。{"layout": {"title": "过去24小时平均请求延迟", "xaxis": {"title": "时间"}, "yaxis": {"title": "延迟 (ms)"}, "template": "plotly_white"}, "data": [{"type": "scatter", "mode": "lines+markers", "name": "平均延迟", "x": ["00:00", "04:00", "08:00", "12:00", "16:00", "20:00", "23:59"], "y": [210, 225, 205, 240, 230, 255, 250], "marker": {"color": "#228be6"}}]}24小时内以毫秒为单位测量的平均端到端请求延迟。{"layout": {"title": "每日大语言模型令牌消耗量", "xaxis": {"title": "日期"}, "yaxis": {"title": "总令牌数"}, "template": "plotly_white", "barmode": "stack"}, "data": [{"type": "bar", "name": "输入令牌", "x": ["周一", "周二", "周三", "周四", "周五"], "y": [150000, 165000, 140000, 180000, 195000], "marker": {"color": "#74c0fc"}}, {"type": "bar", "name": "输出令牌", "x": ["周一", "周二", "周三", "周四", "周五"], "y": [75000, 80000, 70000, 90000, 100000], "marker": {"color": "#fab005"}}]}堆叠条形图,显示主要大语言模型一周内的每日输入和输出令牌使用量。警报: 根据重要指标的预设阈值配置警报。例如:如果 P95 延迟超过 2 秒则发出警报。如果错误率超过 1% 则发出警报。如果预计每日成本超过特定预算则发出警报。 警报在问题出现时主动通知相关团队,从而实现更快的响应和缓解。持续监控性能和成本并非一次性设置,而是一个持续的过程。定期审查仪表盘,及时调查警报,并将监控数据与应用程序更新或使用模式的变化相关联。这种严谨性对于在生产环境中运行可靠、高效且经济的 LangChain 应用程序非常重要。