SpringAIRAG全链路观测实践，如何精准定位性能瓶颈

在开发和运维基于Spring AI的RAG（Retrieval-Augmented Generation）应用时，性能问题往往成为最大的挑战之一。不同于传统应用的"完全不可用"，RAG应用更多面临的是"偶尔有点慢"的问题。这种性能波动通常难以定位，因为单一的总耗时指标无法区分是Embedding模型、Milvus相似度检索，还是大模型生成阶段出现了问题，甚至可能是网络传输环节导致的延迟。

为解决这一难题，笔者对一个基于Spring Boot 3.2.0、Spring AI 1.0.0、Spring AI Alibaba 1.0.0.2构建的RAG应用进行了全链路观测实践。该应用使用text-embedding-v4作为Embedding模型，qwen-plus作为生成模型，并以部署在远程服务器上的Milvus作为向量库。通过接入观测云，不仅实现了对应用内部调用链的追踪，还同步采集了远程Milvus的Prometheus指标，从而全面掌握了系统各环节的性能表现。

全链路追踪的关键要素

本次实践的核心在于构建一个完整的观测体系，包括三个主要维度：

应用内部调用链追踪：通过OpenTelemetry（OTLP）收集ChatClient、Advisor、EmbeddingModel和MilvusVectorStore等组件的Span信息，形成一次请求的完整调用记录。

应用级指标监控：利用Spring Boot Actuator暴露的Prometheus端点，采集应用层面的性能指标，如请求速率、错误率等。

外部服务指标采集：通过本机DataKit抓取远程Milvus的Prometheus指标，包括代理延迟、请求计数等关键数据。

通过这三层观测数据的结合，可以清晰地区分不同环节的性能瓶颈。例如，在本次实践中，通过对应用到Milvus之间网络增加人为延迟的测试，最终确认性能下降的主要原因是网络路径问题，而非大模型或Milvus服务本身的压力。

实践中的技术细节

为了实现上述观测体系，主要做了以下几项工作：

依赖集成：在pom.xml中加入了Actuator、Micrometer Observation、OpenTelemetry等必要的依赖。

本地数据采集：在Windows本机安装DataKit作为数据采集代理，它同时负责采集本机应用的Prometheus指标和远程Milvus的指标，并统一上传至观测云。

隐私保护设计：在采集过程中严格遵循隐私要求，只记录操作名称、耗时、状态等必要信息，不上传用户问题、模型答案和召回文档等敏感内容。

观测结果与价值

通过这次实践，成功实现了对RAG应用性能的精准定位。观测页面不仅显示了具体的调用链信息，还能回答诸如"这一次请求的时间去了哪里"、"同类操作最近是不是普遍变慢"以及"向量库内部是否同时出现压力"等问题。这种全方位的观测能力，使得在遇到性能问题时，能够快速定位并采取相应的优化措施，而不是盲目猜测或尝试各种解决方案。

总的来说，Spring AI RAG应用的全链路观测实践，不仅解决了性能问题难以定位的痛点，也为后续的系统优化和运维提供了强有力的数据支持。