GreedyAbyss这不是一篇讲RAG原理的文章，而是讲RAG系统上线之后怎么活下来的文章。我做了三年Java后端，近一年半全面转向大模型应用运维，踩过最多的坑既不在模型效果上，也不在代码逻辑里，而在部署、数据链路、连接管理、存储一致性和监控盲区。这个专题以《RAG系统运维与故障排查：从部署到监控的全流程指南》为核心，把我在生产环境从零搭建RAG知识库、并持续维护近一年积累的经验全部拆开，给同样正在做Spring AI + 大模型项目的朋友一条可以直接照抄的路。
1. 生产环境RAG系统：本地Demo与可运维架构之间的鸿沟
1.1 为什么本地跑通了一切，一上线就变成事故现场
我先说一个绝大多数RAG项目都会遇到的场景：开发在本地用Spring AI写了一个最小闭环，文档加载、切分、向量化、检索、调用大模型生成回答，全链路通，效果也不错。测试环境也没问题。结果部署到生产，第一天还好，第二天文档内容更新后ES里出现了成百上千条重复向量，检索结果全是同一篇文章的不同片段，回答质量跳崖式下跌。
这个问题几乎和RAG本身的效果无关，纯粹是运维设计缺失。本地Demo是单机、小数据量、人工触发重建的玩具；生产环境是分布式、持续写入、并发查询、依赖多个外部服务的真实系统。两者的差别集中在七个地方：数据写入的幂等性、连接池和重试机制、资源配额与弹性、日志与链路追踪、权限与安全、监控告警、以及配置管理。任何一项没做，系统都能跑，但总有一天会以事故的方式提醒你它存在。
我在这个专题里反复强调一句话：RAG系统比普通Web应用多出来的复杂度，几乎全部来自两条链路——一条是文档写入的离线链路，一条是问答检索的在线链路。离线链路要解决"数据怎么进得去、进得对、不重复"，在线链路要解决"请求怎么稳定出去、快速回来、答得准"。运维的一切动作都是围绕这两条链路展开的。
1.2 核心组件选型：Spring AI、向量库与模型服务的边界
Java技术栈做RAG，目前的主流组合绕不开Spring AI。Spring AI 1.x/2.x提供了完整的RAG抽象层：DocumentReader、TextSplitter、EmbeddingModel、VectorStore、QuestionAnswerAdvisor，配合Spring AI Alibaba 1.x系列还能把阿里云的通义系列模型接入进来。相比LangChain4j与Spring AI Alibaba，Spring AI的生态明显更贴合Java开发者的心智，而且它把很多容易被忽略的细节封装成了Spring Boot风格的自动配置。
但是组件选型永远不是技术越新越好，而是运维越省心越好。我从运维角度推荐的组合是：
- 后端服务：Spring Boot 3.x + Spring AI
- 向量库：Elasticsearch（生产环境用官方的dense vector search功能）
- 模型服务：API优先，本地模型用Ollama兜底
- 缓存与状态：Redis + Redisson
- 任务调度：Spring本身的事件机制 + xxl-job（用于批量重建向量索引）
- 可观测性：Prometheus + Grafana + Loki + SkyWalking
这套组合的核心理由是：你在生产环境做故障排查时，社区资料最多、踩坑记录最全的一定是这些主流组件。选太冷门的技术，出了问题连查都没地方查。
1.3 从Agentic RAG到Ontology RAG：运维视角的架构权衡
这个系列前面几个专题讲了不少RAG的进阶变体，比如Agentic RAG、Ontology RAG、GraphRAG。但我在生产环境见过太多团队把Agentic RAG直接搬到线上，结果运维成本直线上升——多轮工具调用意味着链路变长，每一步都可能超时、失败、返回非法格式，排查多轮调度问题比排查单个问答请求痛苦十倍。
我的建议是：生产环境第一版老老实实做Naive RAG，架构上预留Agentic的扩展点即可。先保证数据链路稳定、检索质量可衡量，再逐步加入路由、多工具调用和反思机制。Ontology RAG可以用于知识密集、实体关系复杂的垂直领域，但它的本体构建本身就是重运维任务，需要保证本体与文档的同步更新，否则会出现本体和文档数据不一致的诡异问题。
运维的本质是控制复杂度。每引入一个进阶机制，都要问自己：崩溃时我能不能在30分钟内定位到根因？如果不能，这个阶段就不该上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 文档入库与向量化流程：ES中的数据质量是RAG的生命线
2.1 RAG向量化流程拆解：从原始文档到可检索向量的完整路径
RAG向量化流程有很多文章写过，但大部分都在讲算法原理，我要从运维视角讲数据流转和状态管理。
完整的向量化流程是五个环节：
- 文档加载（DocumentLoader）：从OSS/S3/MinIO读取原始文件，解析PDF、Word、Markdown、TXT等格式。运维要关注的不是解析效果，而是文件格式异常、超大文件、加密文件这些边界情况。默认超时和内存限制一定要设置，否则一个损坏的PDF就能拖垮整个批量任务。
- 文档切分（TextSplitter）：按固定长度、递归字符、语义边界等方式切分。这里的核心运维参数是chunk_size和overlap。调大chunk_size会提高语义完整性但降低检索精度；overlap可以缓解上下文断裂，但会增加向量数量和数据冗余。
- 向量化（Embedding）：调用Embedding模型，把文本变成向量。这里是整个流程中唯一产生真实计算成本的地方，也是最需要关注QPS限制和超时的地方。
- 存储（VectorStore）：把向量和原始文本、元数据写入向量库。ES的dense vector search是生产环境最稳妥的选择。
- 索引维护：分词器配置、向量维度mapping、刷新频率、副本分片，全部要提前规划。
我在Spring AI里会这样组织代码，用事件驱动的方式把各个环节串起来：
java复制@Component
public class DocumentIngestionPipeline {
private final VectorStore vectorStore;
private final EmbeddingModel embeddingModel;
@EventListener(DocumentUploadEvent.class)
public void handleDocumentUpload(DocumentUploadEvent event) {
Document document = loadDocument(event.getFileUrl())