LLM 应用可观测性：从 Trace 视角展开的探索与实践之旅

2024-07-27
浙江
本文字数：7296 字
阅读完需：约 24 分钟

作者：坤硕

背景介绍

随着生成式 AI 概念的火爆，以 ChatGPT 为代表，市场上涌现了一系列商用或者开源的大模型，同时基于大语言模型以及 AI 生态技术栈构建的应用以及业务场景也越来越多，大规模的模型训练以及模型推理场景也催生了 MLOps、LLMOps 等相关的岗位需求。如何监控并保障大模型应用上线的性能以及用户体验？如何支持复杂拓扑场景下 LLM 应用领域的链路可视化分析以及根因定位？需要从成本以及效果等方面获得线上实际效果表现，辅助分析、评估以及优化迭代大语言模型等。基于上述需求以及问题背景，面向 LLM 应用技术栈的可观测能力解决方案也成为了日益重要的话题。

AI 应用生态以及应用范式

OpenAI 在 2022 年 11 月 30 日推出了 ChatGPT，一经发布吸引了大量的市场关注以及用户注册体验。以 ChatGPT 为代表的大语言模型在大范围连续对话能力、生成内容质量、语言理解能力和逻辑推理能力上都得到大幅提升。相比于国外，国产大模型通过不断突破模型参数量的上限，延长上下文记忆，同时结合降价以及免费等手段吸引客户，最近 OpenAI 宣布停止对中国客户提供服务，整体上看国产的商业化以及开源大模型可以作为平替并满足国内的需求场景。同时围绕 LLM 的技术栈生态发展，一系列脚手架或者工具平台也应运而生，加速了应用落地速度。

以 LangChain、LlamaIndex、Semantic Kernel、Spring AI 为代表的应用编排框架通过抽象封装显著降低了开发难度，提升了工程迭代效率。
向量数据库技术，如 Pinecone、Chroma、Weaviate 和 Faiss，凭借其语义向量检索与长期记忆能力，与大模型协作解决了数据实时性、知识图谱构建及模型幻觉等问题，进一步提升 LLM 的应用效果。
一站式应用研发平台，例如 Dify、Coze 等，通过提供开箱即用的便捷工具，基于可视化的编排，调试以及部署能力，大幅度降低开发门槛，加速了从创意到应用的转化流程。

基于上述技术能力以及框架工具开发的大语言模型应用，主要分为如下三类应用范式：对话应用、RAG 应用、Agent 应用。

对话应用

此类应用的核心在于依托大模型的广泛泛化能力，确保对话互动的自然流畅。开发者的工作重心聚焦于用户界面（UI）的设计，通过精心构造提示（Prompt Engineering）及微调策略来优化输入输出。应用架构相对简单，逻辑路径较短，需要集合具体应用场景选取通用或领域特定的大模型。研发流程着重于提示的结构化设计及与大模型标准 OpenAPI 的高效对接，这一模式适合快速构建简易 AI 应用或初步探索性项目，具备较强的灵活性与快速迭代能力。

RAG 应用

优化大模型回应质量的策略，一般采取微调与提示工程等，虽有成效但仍面临知识边界、虚构信息及安全隐私的挑战。为应对这些难题，RAG（Retrieval-Augmented Generation）技术通过引入知识库作为大语言模型的辅助，克服长尾知识获取、信息时效性、私有数据查询及增强信息源验证与可解释性的不足。通过标准化流程加速知识的定制化嵌入，即经由分块、索引等步骤将专有知识存储于向量数据库中，依据用户查询精准匹配，以此丰富大模型的输入上下文，显著提升回复的精确度与全面性。然而 RAG 技术亦有其局限性，特别是针对高度整合性、对比性分析及多维度推理的需求，仍需进一步的技术革新与策略优化。

Agent 应用

设计模式上，LLM Agent 强调反思、工具运用、规划以及多 Agent 协作。针对复杂的问题，需要通过任务拆解、长期记忆、多轮推理反思、外部工具调用等结合来综合实现，是当前应用落地研究的热点。LLM Agent 看起来很强大，但是面临的挑战也不少，例如推理过程的复杂性可能导致的响应延迟、推理复杂以及缺乏失败自愈导致的可靠性差、依赖的外部工具质量参差不齐，非完全可控的安全信任度考量以及多 Agent 交互协作缺乏成熟经验。往往需要通过 workflow 编排，反馈自省以及可观测等手段实现更高的可控性以及可靠性。

为什么需要 LLM 应用可观测

TruEra 的研究数据揭示，尽管 2023 年被视为构建大规模语言模型（LLM）应用原型的繁荣时期，但实际转化成生产环境部署的比例依旧偏低。历史数据分析指出，仅约 10% 的企业能将超过 25% 的 LLM 开发项目推进至生产阶段，而逾 75% 的企业则尚未实现任何 LLM 应用的商业化落地。这一现状凸显了从理论原型到实践应用之间存在的显著差距。例如前面介绍的不同的应用范式都面临实际的问题需要解决。究其原因，大模型应用从研发到生产依然面临着一系列挑战。

大模型依赖存在不确定性

LLM 作为一种复杂的统计模型，其行为偶尔呈现出不可预知性，尤其在以下几个核心问题上表现突出：

模型效果不佳：模型在处理复杂逻辑推理任务时能力欠佳，且由于知识库的局限性，面对新颖问题时回答质量不高。此外，随时间推移，模型漂移可能导致回答质量逐渐下滑。
性能与可靠性挑战：LLM 设计为无状态，完成一次回答需耗时超过十秒，复杂推理则更久。在高并发场景下，大型模型的请求容易引发限流，同时部分请求还可能偶发失败，影响服务稳定性。
可解释性和透明度不足：模型的可解释性需要提供详尽的模型版本、参数配置及部署详情，以便用户更好地理解和验证模型输出的答案。
资源管理问题：监控计算资源的负载与效率至关重要，因 LLM 系统在高峰期可能遭遇响应迟缓，并受限于 Token 计数的硬性约束，影响服务的连续性和效率。

LLM App 架构链路复杂

一个复杂的 LLM App 应用架构可能包含前端 UI 组件、认证模块、会话管理、对话服务、LLM 路由以及静态或者动态的流程编排。需要对接不同的 LLM 服务，需要借助 Moderation 和 Guarddrails 进行内容审查以及提示词防御。可能会调用外部工具或者服务来完成具体的操作，查询向量数据库来优化对话上下文或者长期记忆，通过对接缓存服务能够直接命中缓存降低对 LLM 的重复调用进而降低成本。可能会面临如下挑战：

不同应用的语言技术栈多样，技术框架多样，不同的大模型调用，如何低成本高质量的采集数据发现并定位线上问题？
如何监控大模型应用上线后，端到端全链路的性能以及业务质量，在性能下降或者报错时及时触发告警，第一时间保障用户体验？
如何标准化的记录输入输出，跟踪 Token 消耗、关键执行动作、结果状态，最终通过可视化的方式进行呈现并灵活分析？
应用编排框架屏蔽底层细节，Agent 逻辑复杂、使用的工具质量参差不齐，如何具备一定的白盒化能力进行根因定位？
如何记录线上实际效果表现数据，辅助分析、评估以及持续优化迭代 LLM 应用？

综上，LLM 应用存在复杂的应用链路拓扑、组件依赖以及大模型领域洞察，需要通过可观测能力来保障系统 SLA 以及终端用户使用体验。

LLM APP 部署技术栈挑战

从架构角度来讲，当需要可扩展性、弹性和解耦时，我们可以实现微服务架构。应用程序的不同组件被解耦并作为独立的服务运行，例如用户交互系统、提示工程系统、RAG 系统、LLM 处理等，每个服务都可以根据需求独立扩展。相应的会引入 K8s 以及各种中间件组件等依赖，进一步增加了整体技术栈研发以及运维的复杂性。完整技术栈可以分为：

基础设施层：关注 GPU 资源的优化利用、K8s 的容量规划与性能调优，以及构建可靠的组件运行环境。
模型服务层：侧重于模型服务的稳定运行、模型输出的质量控制，及其成本效益分析。
中间件层：确保所有组件和服务间的通信高效且可靠，监测中间件的可用性以支撑上层应用。
应用层：聚焦于代码性能优化、流程编排集成，逻辑严谨性以及建立健壮的异常处理机制。
业务层：直接关联用户体验，通过量化分析终端响应速度、业务功能的可达性以及深入会话数据分析，持续提升服务质量。

为了确保整个系统的顺畅运作，特别是满足模型层以及新的依赖组件稳定性需求，每一层级都需要精细的监控与可观测性策略。

LLM App 关注点存在差异

微服务架构通过细致的服务拆分策略，衍生出一系列服务单元，这些单元之间通过微服务网关进行交互，依赖的组件包括数据库、NoSQL 以及消息等各类中间件。在基础设施层面，采用 Kubernetes（K8s）平台来达成资源的动态扩展与自动化运维管理，不仅提升了系统的弹性和可靠性，还简化了服务的部署与维护流程。而 AI 应用架构下，通过多 Agent 进行协同交互来解决复杂的问题，强依赖大语言模型的推理能力，通过集成 AI 网关来简化对接不同的 LLM 服务，从而屏蔽实现协议层面的差异，同时支持流量路由，请求管控、安全防护等公共能力。

AI 应用架构下依赖的组件相对较少，主要为向量数据库、外部工具调用、RAG 组件等。对于独立部署的大型语言模型服务，鉴于其对计算资源的高度需求，通常部署在以 GPU 集群为核心的基础架构之上，该配置专门针对深度学习任务进行了优化。对 GPU 资源的精细管理和监控成为关键，确保资源利用率最大化且能根据模型训练或推理的需求动态调整资源水位，维持系统运行的高效与稳定。

总体而言，微服务架构侧重于系统架构的灵活性与韧性建设，LLM 应用则致力于模型效率与效果的极致追求。两者的可观测能力述求从关注焦点、数据复杂度、技术挑战、性能评估标准上存在一定的差异。LLM 应用的可观测性可能需要处理更高维度的数据，尤其是涉及自然语言处理的复杂度，需要对模型输出进行语义分析。所以 LLM 应用可观测主要聚焦于推理性能的提升，模型输入输出的质量优化以及资源消耗的有效管理。利用先进的评估指标以及不同模型的 A/B 测试等科学实验方法，来量化分析模型的性能表现，并持续迭代优化，以期达到最佳的业务成效。

阿里云 LLM 应用可观测方案

阿里云 ARMS 可观测支持自研以及开源探针采集可观测数据，围绕 Logs、Metrics、Trace、Profling 四大支柱构建可观测数据底座，覆盖 RUM、APM、STM、容器监控以及基础设施监控等，全面拥抱 Prometheus、OpenTelemetry、Grafana 开源标准，为客户提供高可靠、高性能、功能丰富、开箱即用的端到端全栈可观测能力。

针对 LLM 应用的可观测解决方案，可以在 ARMS 可观测平台基础能力之上，聚焦 LLM 领域洞察，通过高质量的采集加工 LLM 应用产生的 Logs、Metrics、Trace 以及 Profiling 数据进行加工以及提供可视化的分析能力，通过进一步挖掘加工、关联分析上述数据可以最大化的释放数据价值。接下来我们来看下阿里云 LLM 应用可观测解决方案具体实现思路以及产品能力。

面向 LLM 应用特点的领域化 Trace 语义

通过分析 LLM 应用的交互特点以及处理链路，参考对话应用、RAG 应用、Agent 应用的操作以及应用编排框架（例如 LangChain、LlamaIndex 等），最终确定以会话串联用户交互问答过程，以 Trace 承载应用全链路交互节点，定义领域化的操作语义，标准化存储以及可视化展示关键内容的思路。

通过定义出关键的操作类型（LLM Span Kind）用以标识 LLM 应用的核心操作语义。具体分为如下 Kind：

CHAIN：标识静态流程编排，可能包含 Retrieval、Embedding、LLM 调用，还可以嵌套 Chain 等。
EMBEDDING：嵌入处理，例如针对文本嵌入大模型的操作，可以根据相似度查询并优化问题。
RETRIEVER：表示 RAG 场景下从向量数据库获取数据，用于补充上下文内容以提升 LLM 的响应准确性以及全面性。
RERANKER：针对输入的多个文档，结合提问内容判断相关性进行排序处理，可能返回 TopK 的文档作为 LLM。
TASK: 标识内部自定义方法，例如可能调用本地的某个 function 等应用自定义的逻辑
LLM：标识对大模型的调用，例如基于 SDK 或 OpenAPI 请求不同的大模型进行推理或者文本生成等。
TOOL：标识对外部工具的调用，例如可能调用计算器或者请求天气 API 获取最新的天气情况。
AGENT：智能体场景，标识动态编排，需要基于大模型的推理结果决策执行下一步，例如可能涉及到 LLM 以及 Tool 的多次调用，一步步决策得出最终答案。

不同的操作类型涉及的输入输出或者关联上下文属性存在一定的差异，例如 LLM 操作下会存在 Prompt（可选的 Prompt Template）、调用到模型服务的请求入参以及响应内容，输入输出 Token 消耗等内容。例如 RETRIEVAL 涉及到 document chunk 的具体内容以及相关度评分等。通过提取上述关键操作的属性字段定义并记录在 Span 中，基于上述字段可以方便的进行 Trace 数据分析以及统计，同时支持详情视图标准化的格式展示，可以非常清晰地了解操作执行的步骤以及具体细节，辅助开发者快速定位关键节点以及排查原因。

提供高质量自研 Python Agent/SDK

要实现上述 LLM Trace 语义的数据采集和上报，需要具备端侧埋点自动采集以及对接服务端上报数据的能力。由于 LLM 应用的主流开发语言为 Python，阿里云在自研 JAVA Agent 的基础上，全新推出了基于 OpenTelemetry Python Agent 底座的自研 Python Agent。相比开源实现，阿里云 Python 探针提供更丰富的指标、链路及持续剖析数据，灵活的采样策略，细粒度管控，支持动态配置，提供多种性能诊断和数据，通过全方位自监控提供高可用稳定性保障。

同时阿里云 Python Agent 面向大模型应用进行量身打造，支持最新 OpenTelemetry LLM semantic convention，支持 LLamaIndex/LangChain/通义千问/OpenAI 等国内外框架和模型，实现埋点更加精细化，同时支持自定义属性透传能力，以满足多样化监测需求。技术层面，通过框架的 Callback 机制以及 decorator 原理，能够实现无侵入埋点，极大地简化了部署流程。用户仅需在应用启动阶段安装该探针（容器环境可以基于 ack-onepilot 组件通过调整工作负载的 YAML 即可实现自动安装以及升级），即可自动完成 Metrics、Traces、Profiling 等多维度数据的收集，并无缝对接至阿里云可观测平台，显著降低了观测性集成的技术门槛，为 LLM 应用的稳定运行与高效运维提供了坚实的基础。

简单集成的场景可以单独使用 Aliyun Python SDK 仅仅上报调用链数据就可以享受到开箱即用的 LLM 应用可观测大盘以及调用链分析以及可视化能力。同时也支持集成了开源项目 OpenInference、Openllmetry 的 SDK 的 LLM 应用将数据上报并托管到阿里云可观测服务端。针对多语言以及框架埋点等无法覆盖到的场景，可以基于原始的 OT SDK 参照标准的 LLM Trace 语义（见文末相关链接）实现自定义埋点并上报。

我们更加推荐使用 Aliyun Python Agent（预计 8 月底对外发布）将数据上报到可观测网关后，通过数据缓冲应对流量高峰、通过协议兼容、字段富化、指标聚合、流量统计、自监控等保障整体数据链路的高性能以及可靠性。最终将指标数据写入 Prometheus，调用链数据写入 SLS 存储，中间还可能涉及到编码相关的元数据存储。最终加工写入的数据通过在控制台查询展示，指标类通过告警等方式来提供服务。

开箱即用的专属指标大盘与分析视图

应用接入成功后，阿里云可观测默认提供开箱即用的指标分析大盘，针对 LLM 应用额外提供领域指标大盘，通过 LLM 应用特征自动识别并动态渲染展示专属领域大盘，提供 LLM 调用统计及趋势、输入输出的 Token 使用趋势、模型维度 Top 等指标分析能力。

大语言模型应用具备专属的 Trace Explore 分析视图，支持按照 LLLM Span Kind 以及模型名称等进行统计分析；展示操作执行次数，Token 消耗趋势以及输入输出内容的展示，支持按照自定义 Attributes 列展示。

基于领域化的视图针对 LLM 应用流程中的关键操作进行格式化展示，突出操作类型、Token 消耗以及输入输出内容等关键信息，帮助开发者聚焦关注内容进行问题排查。同时针对调用链详情页做了大量的功能以及体验优化，例如超长的调用链更快加载速度、支持过滤、聚焦 span，支持自定义的事件配置快速跳转自定义链接等。

总结来看，阿里云应用可观测通过洞察 LLM 领域特点，结合开源标准定义领域化的 Trace 语义，自研面向大语言模型应用的 Python Agent 能力实现高质量数据采集上报并标准化存储，围绕客户痛点来构建领域化指标大盘以及调用链分析视图，结合端到端的全链路观测能力，提供给开发者更加高效的问题排查手段以及细节洞察，大幅提升了问题排查定位效率。

实践案例

使用 Python SDK 观测基于 LlamaIndex 的应用。

1. 基于 LlamaIndex 搭建一个聊天机器人

可参考 llama-index use cases 搭建：https://docs.llamaindex.ai/en/stable/module_guides/deploying/query_engine/

2. 安装 SDK

pip3 install  aliyun-instrumentation-llama-index

复制代码

3. 埋点初始化

from aliyun.instrumentation.llama_index import AliyunLlamaIndexInstrumentor
from opentelemetry import tracefrom opentelemetry.sdk.resources import Resource, SERVICE_NAME, SERVICE_VERSIONfrom opentelemetry.sdk.trace import TracerProviderfrom opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter
resource = Resource(    attributes={        SERVICE_NAME: 'aliyun_llama_index_test',        SERVICE_VERSION: '0.0.1',        # "telemetry.sdk.language": "Python",    })provider = TracerProvider(resource=resource)provider.add_span_processor(BatchSpanProcessor(ConsoleSpanExporter()))  # 在控制台输出Tracetrace.set_tracer_provider(provider)AliyunLlamaIndexInstrumentor().instrument()