1. RAG没有你想象的那么简单先搞清楚我们在调什么晚上十点同事在工作群里发来一张截图问我这个知识库机器人是不是坏了截图里的回答一本正经地写着“对于Redis内存碎片率过高建议重启Redis实例释放内存”而知识库原文写的其实是“优先检查maxmemory-policy、客户端key分布是否均匀再考虑重启”。那一瞬间我第一反应是“模型不行”但冷静下来拆了一遍链路后发现问题出在RAG的召回环节——模型拿到的上下文根本就是错的那段文档。这个经历让我决定把RAG从向量到评测体系完整地重学一遍并且用Spring AI落地了一个真正能回答业务问题的服务。这篇博文就是那一次的完整复盘。我会按照13张图的顺序把整条链路的每个环节、每个我踩过的坑以及最后怎么用数据说话而不是靠感觉调参全部讲清楚。如果你正在做知识库问答、智能客服或者企业内部文档问答这篇文章应该能帮你省下好几周的试错时间。1.1 那一次“翻车”让我意识到RAG是完整的系统而不是两个模型当时我做的方案其实很常规把Markdown文档整篇塞给大模型让模型“直接读”结果文档太长截断模型只能看到开头一小段于是捡了“重启Redis”这个关键词就开始编。后来我换成RAG方案认为只要把文档切碎、检索相关片段、再让模型基于片段回答就万事大吉。但真相是RAG是一条包含“入库”和“问答”两个阶段的流水线任何一个环节出问题最终回答都会跑偏。入库阶段包括文档解析、文本切分、向量化、存入向量库。问答阶段包括问题向量化、相似度检索、上下文注入、生成回答。大部分人把注意力放在“检索”和“生成”上却忽略了切分和向量模型选型这些前端步骤。实际上知识库里的内容质量、切分粒度、元数据是否完整决定了后面检索效果的上限。检索只是在“已经切好的碎片”里找出相对相关的内容如果碎片本身是残缺的检索再准也白搭。1.2 13张图的编排逻辑整条链路到底涉及哪些环节很多人一提到RAG就说“向量检索大模型”但这个定义太粗糙了。我这次整理成13张图不是为了凑数字而是为了让每一个环节都有对应的可视化认知。它们大致分五组前2张讲整体链路和核心概念第3到第5张讲向量原理与相似度计算第6到第9张讲Spring AI工程落地第10到第11张讲进阶形态Agentic RAG和Ontology RAG最后第12到第13张讲评测体系与调优闭环。这个顺序其实刻意安排成了“从原理到工程再到验证”。很多人一上来就写代码连向量数据库为什么能检索语义都不清楚遇到问题根本无从下手。先把原理立住再上手项目最后用评测指标反向驱动优化这才是可复制的路径。我见过太多团队做完一个Demo就声称“RAG已上线”结果没有评测集、没有指标全靠人工肉眼判断回答质量这种做法在生产环境里撑不过一个礼拜。1.3 一个反常识结论RAG真正的瓶颈在“喂进去”这一步在做这个项目之前我一直以为检索是最难的部分。实际跑起来之后发现影响最大的其实是“文档怎么切”和“向量模型怎么选”。同一个问题在相同的向量库、相同的生成模型下只改切分参数回答质量可能直接从“能看”变成“胡说”。举个具体的例子运维手册里有一条完整的排障步骤写在同一段中但如果按固定字数切分这条步骤正好被切到两个chunk里。用户问“内存碎片率过高怎么处理”检索只命中了前半段“检查maxmemory-policy”后半段关键的“客户端key分布是否均匀”就丢了。模型拿到半个步骤只能靠自己推理补全于是补出了“重启Redis”这种看似合理其实偏离原文的内容。所以在调模型、调Prompt之前先把切分策略和元数据做好性价比高得多。2. 向量是什么从“苹果、橙子和猫”理解语义坐标第2张图我在白板上画了一个三维坐标系里面有三个点苹果、橙子和猫。这不是玩笑想理解Embedding和向量检索这是最快的路径。2.1 三维空间里的苹果多维空间里的句子假设我们只用一个三维空间来描述水果X轴是甜度Y轴是红色的程度Z轴是脆度。苹果大概是[0.9, 0.8, 0.95]橙子是[0.7, 0.2, 0.6]猫这个点就比较奇怪可能是[0.1, 0.3, 0.5]三个维度都很低离苹果和橙子都很远。这个坐标系里两个点的距离越近它们就越“相似”。大模型里的Embedding做的事情本质上就是把这个三维坐标扩展到几百维甚至上千维。每一个维度表示模型从海量语料里学到的某种语义特征可能是“是否与编程相关”“是否包含时间信息”“是否偏口语化”等等。文本经过Embedding模型处理后会得到一个向量比如384维或者768维的浮点数数组。语义接近的句子在这样一个高维空间里距离就近“猫吃鱼”和“猫吃猫粮”的距离比“猫吃鱼”和“买股票”近得多。在RAG链路里文档切分后每个chunk都会变成一个向量用户问题也会变成向量。检索的本质就是在向量空间里找“离用户问题最近的几个chunk”。这也是为什么传统关键词搜索做不到的事情RAG能做到用户问“内存碎片率高怎么办”即使文档里没有出现“内存碎片率”这几个字只要语义接近也能被召回。2.2 余弦相似度、欧氏距离、点积到底该用哪个向量检索的核心是计算相似度最常用的有三种余弦相似度、欧氏距离和点积。图3里我画了两个向量之间的夹角和距离这张图很好理解。计算方式直觉理解典型适用场景余弦相似度只看方向是否一致不管向量长度RAG默认首选语义相似度用方向表达更稳定欧氏距离看两点在空间里的实际距离低维空间、聚类场景、空间数据点积方向相似且长度越大则得分越高向量已归一化时与余弦等价大规模索引更高效为什么RAG里默认选余弦因为Embedding向量的模长长度往往受文本长度、模型偏好影响而不是语义本身。一句话短问题“怎么处理Redis碎片”和一个长文档chunk向量长度差很多但语义方向可能一致。余弦相似度把模长归一化只看方向正好规避了这个问题。余弦值的范围是-1到1实际业务里我自己的经验是0.7以上才值得进入上下文0.5以下基本可以视为无关内容。点积和余弦的关系简单说就是如果所有向量都先做了L2归一化也就是把模长变成1那么点积结果就等于余弦相似度。很多向量库默认做的就是这个操作所以点积在这种场景下也是合理选择而且计算更快。欧氏距离则在低维向量、空间坐标类数据上更直观但用在千维语义向量上受维度诅咒影响更大不够稳定。2.3 选Embedding模型的三个坑语言、维度、版本第4张和第5张图我画的是“模型选型”和“维度配置”两张决策图。这里有很多细节容易被忽略我逐一说明。第一语言匹配。如果你的知识库是中文文档却用了一个主要面向英文的Embedding模型检索效果会明显打折。我最早用Ollama里的nomic-embed-text做demo英文效果不错但中文长文档检索经常召回无关内容。后来我换成了对中文支持更好的模型比如bge系列或text2vec系列效果立刻好了不少。千万记住Embedding模型不是一个“通用翻译器”它对训练语料里的语言更敏感。第二维度一致。每个Embedding模型产出的向量维度是固定的比如nomic-embed-text输出768维bge-small是384维。如果你用的是PostgreSQL的pgvector建表时dimensions字段就必须和模型输出一致。配错了要么报错要么存进去的是截断向量检索结果完全没法看。我的习惯是项目启动时就把模型名、输出维度、向量库配置三项写在同一个文档里避免换机器或换环境时对不上。第三版本一致性。Embedding模型升级后同一个句子得到的向量会变化这意味着旧向量和新向量在空间里是不可比的。一旦换模型版本最稳妥的做法是全量重新向量化。不要偷懒只增量更新否则新旧向量混在一起检索质量会出很多稀奇古怪的问题。3. Spring AI实战从空工程到一个能回答问题的RAG服务第6到第9张图开始进入工程环节。我用Spring AI 1.0搭建了一个本地RAG知识库服务生成模型和Embedding模型都用Ollama跑在本地向量库先用最简单的内存实现再切到PGVector。整个过程从零到能回答业务问题大约一个下午就能完成。3.1 为什么我在Java生态里选了Spring AI先说选型。市面上做RAG的框架很多Python生态有LangChain、LlamaIndexJava生态有Spring AI、langchain4j。我的项目是纯Java的Spring Boot服务团队没有Python运维能力所以第一选择必须是Java方案。那剩下的问题就是Spring AI和langchain4j二选一。我最终选了Spring AI理由是它和Spring Boot的集成最自然依赖注入、配置体系、自动装配直接复用不需要额外的胶水代码。Spring AI把EmbeddingModel、ChatModel、VectorStore都抽象成了接口切换底层实现非常方便比如今天用Ollama明天换OpenAI只需要改配置和依赖。另外它提供的QuestionAnswerAdvisor机制把“检索注入上下文生成回答”这三个动作封装成了一个顾问组件代码量少很多。如果你只是在Java项目里做RAGSpring AI是最省心的路径。langchain4j也很成熟但它的设计更接近LangChain组件多、组合方式灵活适合有精力做高度定制方案的团队。3.2 准备工作Ollama本地模型、Spring Boot依赖与最小配置模型我用Ollama跑在本地好处是不会把业务数据传到外部接口适合企业内部知识库。需要两个模型一个生成模型一个Embedding模型。我用的是qwen2.5:7b做生成nomic-embed-text做Embedding但其实如果知识库是中文更好的是换成bge-m3这类中文Embedding模型。安装和拉取模型很简单两条命令ollama pull qwen2.5:7b ollama pull nomic-embed-textOllama服务的默认地址是http://localhost:11434Spring Boot这边加依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-ollama-spring-boot-starter/artifactId version1.0.0/version /dependency版本号请以Spring AI官方Maven仓库的最新稳定版为准1.0版本之后API已经稳定很多。核心配置文件长这样spring: ai: ollama: base-url: http://localhost:11434 chat: options: model: qwen2.5:7b temperature: 0.2 embedding: options: model: nomic-embed-text这里的temperature我习惯设0.2。问答场景不希望模型自由发挥太多温度低一点回答会更贴上下文也更容易复现。3.3 文档导入与切分被绝大多数人低估的上限来源第7张图我画的是“切分粒度对召回的影响”这张图决定了很多人的知识库指标好不好看。Spring AI里读取纯文本文件很简单用TextDocumentReader再配合TokenTextSplitter做切分。下面是我在项目里实际跑通的代码var reader new TextDocumentReader(new FileSystemResource(docs/ops-handbook.txt)); ListDocument docs reader.get(); var splitter new TokenTextSplitter(300, 50); ListDocument chunks new ArrayList(); for (Document doc : docs) { for (Document chunk : splitter.apply(doc)) { chunk.getMetadata().put(source, ops-handbook.txt); chunks.add(chunk); } }这里两个参数很关键chunk size是300个tokenoverlap是50个token。为什么要overlap因为切分时如果一刀切下去很可能把一句话的上下文切断。overlap让相邻chunk有重叠部分即使关键信息正好在边界附近至少有一个chunk能保留完整语义。token不是字符是模型词的切分单位大概300个token相当于300到800个中文字符具体取决于文本。我的经验值是对于以段落为主的知识库300到500的chunk size都合理太小了上下文不够太大了检索精度会下降。切分完一定要做一件事把元数据写进每个chunk。上面代码里的source字段只是一个最简单的例子你还可以加标题、章节号、页码、最近修改时间。这些元数据后续有两个用途一是做过滤比如只检索某个目录下的文档二是做答案溯源用户问完问题后你能告诉他是哪份文档的哪一段支撑了这个答案。没有元数据RAG就是个黑盒。3.4 向量化与存储选型内存库、PGVector还是独立向量库切分完成后下一步是把每个chunk交给EmbeddingModel向量化然后存入VectorStore。Spring AI里这个动作被简化成了vectorStore.add(chunks)Embedding模型会自动调用。第一版我直接用SimpleVectorStore它是内存向量库完全不需要额外部署适合验证流程。但内存库有个致命问题重启即丢失。所以我很快切到了PGVector也就是PostgreSQL加向量插件。如果你的业务库本来就在用PostgreSQL这是最平滑的路径不需要引入单独的向量数据库服务运维成本极低。配置如下spring: datasource: url: jdbc:postgresql://localhost:5432/rag_demo username: postgres password: postgres ai: vectorstore: pgvector: initialize-schema: true dimensions: 768 index-type: HNSW distance-type: COSINE_DISTANCE注意dimensions是768对应nomic-embed-text的输出维度。如果你换成384维的bge-small这里也要同步改成384。initialize-schema让Spring AI自动建表省去手工SQL。索引类型我用HNSW这是一种适合高维向量检索的近似最近邻索引速度优于暴力扫描精度损失在可接受范围内。选型建议可以记住这个规律原型验证和内部工具用SimpleVectorStore已有PostgreSQL、数据量在百万级以内用PGVector数据量百万级以上、并发很高、需要独立扩展再考虑Milvus或Qdrant这类独立向量数据库。不要一上来就上重组件很多项目的知识库最初只有几千个chunk内存库完全能跑系统复杂度应该跟着业务规模走。3.5 关键一步用QuestionAnswerAdvisor把检索接进生成第8张图是这个项目的核心示意图用户问题先进ChatClient然后QuestionAnswerAdvisor自动去向量库检索把命中的chunk注入Prompt最后生成模型基于上下文回答。这个机制省掉了很多手写Prompt拼接的脏活。实际代码非常短Service public class RagService { private final ChatClient chatClient; private final VectorStore vectorStore; public RagService(ChatModel chatModel, VectorStore vectorStore) { this.chatClient ChatClient.create(chatModel); this.vectorStore vectorStore; } public String answer(String question) { var advisor new QuestionAnswerAdvisor( vectorStore, SearchRequest.builder() .topK(4) .similarityThreshold(0.6) .build() ); return chatClient.prompt() .user(question) .advisors(advisor) .call() .content(); } }SearchRequest的两个参数值得细说。topK4表示每次检索返回4个最相似的chunk。太少了可能漏掉关键内容太多了模型会被不相关内容干扰回答时容易跑偏。similarityThreshold0.6是相似度过滤阈值低于这个分数的不进上下文避免模型捡垃圾。这两个参数没有万能值需要根据你的文档风格和业务场景微调。我建议从topK4、阈值0.6起步看评测数据再改。很多初级方案会忽略一件事如果所有chunk的相似度都低于阈值QuestionAnswerAdvisor会返回空上下文这时候模型仍会硬答。我推荐在Prompt层面加一句“如果上下文不包含答案直接回答不知道”这能显著减少幻觉。如果你用的是Spring AI的默认Prompt模板也可以通过自定义SystemMessage来实现。3.6 一个能跑的Controller以及它漏掉的东西写了Service之后暴露一个HTTP接口就很直接了RestController public class RagController { private final RagService ragService; public RagController(RagService ragService) { this.ragService ragService; } PostMapping(/api/rag) public MapString, Object ask(RequestBody MapString, String body) { String question body.get(question); String answer ragService.answer(question); return Map.of(answer, answer); } }这个接口够demo用了但它漏了两件事。第一没有历史对话记忆用户追问“那具体参数怎么配”时系统不知道“那”指什么。RAG问答如果要支持多轮需要把历史消息塞进PromptSpring AI里可以通过ChatMemory管理对话窗口但这一步会明显增加复杂度我建议先保证单轮回答质量再考虑多轮。第二日志里没有记录召回了哪些chunk。我在生产环境里会把question、answer、retrieved chunk id全部打进日志这样出了问题能回溯也是后面做评测集的重要素材。4. 进阶知识割裂、Agentic RAG与Ontology RAG基础RAG版本上线后我们的机器人能回答大部分单点知识问题。但没过多久就遇到一类很棘手的情况一个问题的答案分散在多个文档里机器人回答得支离破碎。4.1 知识割裂为什么两个文档同时回答时RAG会“断片”第10张图我画了一个例子文档A写“变更需要提交申请单”文档B写“申请单需经经理审批”。用户问“变更流程需要谁审批”正确的答案是“需要提交申请单并由经理审批”。但普通RAG只会从文档A和文档B里各自召回相似片段模型虽然把两个片段都拿到了却未必能正确组合因为两个chunk是孤立召回的它们之间的逻辑关系并没有被显式表达出来。这个问题就叫“知识割裂”。根源在于RAG的一次检索假设“答案在某一个或者某几个局部片段里”但真实业务知识往往是跨文档关联的。要解决知识割裂有两个进阶方向Agentic RAG让模型自己决定查什么、怎么查Ontology RAG用图谱把实体和关系显式建模。4.2 Agentic RAG让模型自己决定“去哪里查”Agentic RAG的核心思路是把检索决策权从“固定流程”交给Agent。普通RAG不管什么问题都去同一个向量库检索Agentic RAG则由大模型先拆解问题判断该去哪里查、要不要多查几次拿到结果后再决定是否继续追问。我测试过最轻量的实现方式是在Spring AI里做“问题路由”。先用一次模型调用让模型输出问题类别比如“运维类”“财务类”“人事类”然后根据类别选择不同的知识库或不同的检索参数。更进一步的是用Spring AI的Tool Calling机制把“查询运维知识库”“查询人事知识库”封装成两个Tool让模型自主决定调用哪个工具。实现思路大致是Tool(description 查询运维知识库) public String queryOps(String query) { return vectorStoreOps.similaritySearch(query); } Tool(description 查询人事知识库) public String queryHr(String query) { return vectorStoreHr.similaritySearch(query); }当用户问“报销流程怎么走”模型会先分析这个问题属于人事或财务不会跑到运维知识库里翻答案。这个模式能有效降低检索噪声特别适合有多套知识库、业务域差异明显的场景。缺点是多了一次模型调用延迟变高成本也上去了。所以别为了“先进”而盲目上Agentic如果单库检索的Hit Rate已经很高先做好基础RAG再说。4.3 Ontology RAG把“相似”升级为“可达”第11张图是Ontology RAG的最小示意一组实体节点比如“变更申请单”“经理”“审批流程”以及它们之间的关系边。普通RAG只能判断文本相似Ontology RAG能沿着关系边走到逻辑上相关的节点。举个具体场景。用户问“谁有权审批紧急变更”如果文档里没有“紧急变更”这个词只有“变更审批”和“值班经理”向量检索很可能召回失败。但如果有本体关系变更审批由经理负责紧急变更是变更的一种那么就能顺着一跳关系推理出“紧急变更的审批人是值班经理”。这个推理能力是普通向量检索不具备的。我的建议是除非知识库有明确复杂的实体关系、且多跳查询需求特别多否则先不要上完整的GraphRAG和本体平台。工程复杂度会成倍增加。可以先在工程上做一颗“轻量实体关系表”把关键实体和关系维护成邻接列表检索时先向量找到入口实体再扩展一跳或两跳的关联文本。这对中小企业知识库来说已经能覆盖很大一部分跨文档问题。5. 评测体系没有数字就没有资格谈优化第12张图是“RAG评测三层框架”第13张图是“Hit Rate与忠实度双指标驱动调优”。这两张图给整条链路装了仪表盘。在写出评测脚本之前我对系统效果所有的评价都停留在“感觉还行”这非常危险。5.1 三层评测组件、管道、应用RAG系统的评测至少分三个层次层次关注点典型指标判断方式组件级切分质量、向量模型、向量库本身检索TopK召回是否合理、Chunk是否完整人工抽查切分结果和检索样例管道级从问题到检索结果这一段Hit Rate、MRR、NDCG用标准问答对批量计算应用级最终回答质量忠实度、正确率、可读性LLM裁判打分 人工验收不要一上来就评“回答好不好”这类应用级指标。如果管道级的Hit Rate只有0.4你再怎么优化Prompt和生成模型都没用因为模型根本没拿到该拿的知识。反过来Hit Rate高但回答还是错的那才需要看Prompt和应用层的问题。5.2 最值得盯紧的两个指标Hit Rate与忠实度Hit Rate的定义特别简单针对测试集中的每个问题标准答案所在的那个chunk是否出现在系统召回的前TopK结果里。是就算命中不是就算未命中。用公式表示就是命中的问题数除以总问题数。我给自己建了20条测试问题刚开始跑的时候Hit Rate只有0.45也就是说快一半的问题连“相关文档”都没召回模型等于在裸答。忠实度衡量的是回答和检索上下文的一致性简单理解就是模型有没有“照着材料说”。即使Hit Rate高模型也可能不按上下文回答自己发挥编一段。忠实度一般用LLM作为裁判来打分Prompt可以这样写你是一个严谨的评测助手。下面是用户问题、系统检索到的上下文片段和模型回答。 请判断模型回答是否严格基于上下文是否包含上下文之外的编造信息。 只能输出两个词忠实 或 不忠实。注意LLM裁判也有偏差所以在小规模评测集上我建议再加一遍人工复核。把裁判判为“不忠实”的回答全部拉出来人工看慢慢积累出一份“坏答案集”对后续改进非常有价值。5.3 20条问题构建最小可行评测集不需要一开始就建几百条测试数据20到50条足够发现问题。关键是问题来源要真实。我当时的做法很简单从内部系统的搜索日志和客服聊天记录里把真实用户问过的高频问题抄出来按业务域分类每个域挑几条。然后为每个问题标注两样东西标准答案、标准答案所在的文档chunk ID。这里有个小技巧标准答案不是必须写一段完美的话只需要标注“这个问题应该由哪些chunk来支撑”以及“期望回答包含哪些关键点”。比如“Redis碎片率过高怎么处理”这个问题的期望关键点是maxmemory-policy检查、客户端key分布是否均匀如果模型回答里没有这两个关键点就算错误。还有一条很重要的建议不要用AI生成问题来冒充真实用户问题。AI生成的问题往往太工整、信息太完整和真实用户口语化、残缺的提问方式差距很大。用AI问题测出来的Hit Rate好看但一到线上就崩。5.4 指标驱动的优化顺序有了指标之后优化的顺序就很清晰了。我的决策过程基本是这样一个分支Hit Rate低 → 检查切分粒度、向量模型语言匹配、topK是否太小、similarityThreshold是否过高 Hit Rate正常但忠实度低 → 检查上下文是否太多噪声、Prompt是否明确要求只基于上下文回答 检索结果为空 → similarityThreshold可能过高或知识库里根本没有相关内容 回答内容与chunk不一致 → 生成模型温度可能过高或Prompt约束不严我在这个项目里最典型的一次调优是把chunk size从500降到300Hit Rate从0.45提到了接近0.8。原因很简单原来chunk太长每个chunk里混杂了多个主题Embedding向量被“平均”掉了检索时反而不够聚焦。切小之后每个chunk只表达一个主题向量空间更清晰召回的准确率自然上来了。但你如果把chunk size继续降到100又会发现上下文不足模型回答时信息量不够。这就是典型的平衡问题必须在自己的数据集上实测不能照搬别人的参数。6. 避坑实录与常见问题速查最后这部分我把实际运维和二次开发中遇到的典型问题整理成一个速查表方便你遇到类似情况时快速定位。6.1 向量模型和文档语言不匹配检索结果等于“猜”现象检索出来的chunk看起来完全不相关甚至返回的是其他主题的内容。原因大概率是Embedding模型的语言偏好和知识库语言不一致。我之前用nomic-embed-text跑中文知识库就是这种效果。解法更换为中文效果更好的Embedding模型。如果文档是中英混合的优先选多语言模型。换完模型后记得全量重新向量化旧向量必须清掉重生成。6.2 切分太整齐反而坏事语义断层与重复污染切分有一对矛盾切太大向量不聚焦切太小语义不完整。更隐蔽的问题是同一份文档的相似段落被切成多个chunk后向量检索可能同时返回两个内容高度重叠的chunk白白占掉TopK名额还把真正需要的第三个chunk挤掉了。解法除重。在入库阶段对chunk做一次文本去重完全相同或近乎相同的段落只保留一个。另外切分策略可以结合文档结构优先按标题和章节边界切而不是完全按固定字符数硬切。6.3 图片、扫描件和文本拆解工具很多人问“知识库能存图片吗”。直接存图片给普通Embedding模型是没用的因为文本Embedding模型读不了图像内容。如果你是做通用知识库我的建议是图片以“描述文字”和“图片文件URL”两个元数据字段存进chunk这样检索时能定位到图但生成模型只能通过描述文字理解图片内容。如果必须直接理解图片语义就要上多模态Embedding模型或者在入库前先OCR、再调用图像描述模型生成caption文本。本地文本拆解工具的选择Java项目可以用Apache Tika解析PDF、Word、HTML扫描件需要先OCR推荐Tesseract或PaddleOCR。Python生态里unstructured也很流行文档解析质量不错。无论用哪个工具解析完都建议人工抽查十几个chunk确认标题层级、表格内容有没有乱。6.4 框架选择恐惧Spring AI还是langchain4j这个问题我最后再聊一点。如果团队是Java技术栈Spring Boot已经是基建的一部分那直接用Spring AI它的自动配置和抽象能让你少写很多代码。如果你的RAG流程需要很复杂的自定义管线比如多跳检索、重排序、复杂的文档解析langchain4j的组件化程度更高扩展更容易。两者都能跑通RAG别反复横跳尽快用真实数据做一轮评测比纠结哪个框架更重要。最后分享一个我自己的实战习惯每次改完切分参数、检索阈值或者Prompt之后我都会把那20条测试集完整跑一遍把Hit Rate和忠实度记在一张表格里。这个习惯听起来笨但坚持两周后你会清楚地看到哪些改动真正有效哪些只是自我安慰。RAG系统不是一个“装完就结束”的东西它更像一棵需要持续修剪的树评测集就是你的尺子每次修剪后拿尺子量一量才不会剪歪。