先交代一个我最近常被问到的场景知识库已经有了文档也整理得很整齐接下来作为 Java 程序员还能做什么很多人以为把文档塞进系统就算完事但实际上知识库只是原料真正让用户用自然语言问出答案的是 RAG 这套技术。我是做 Java 后端的最近用 Spring AI 把团队里一个“沉睡”的 Wiki 变成了可问答的服务这篇就围绕 Spring AI、Java、RAG 和知识库这四个关键词把整个实战过程、踩过的坑和进阶思路写清楚。如果你已经有一个整理好的知识库想在 Spring Boot 项目里接入智能问答这篇文章里的方案可以拿来直接用。1. 知识库和 RAG 的关系先搞清楚你要解决什么问题1.1 知识库不等于知识服务先说一个我观察到的现象团队里“知识库已经有了”和“知识服务可用”之间往往隔着一层窗户纸。很多团队用 Obsidian、Wiki、Dify 甚至自研系统攒了一堆文档文件摆得整整齐齐但真正要找一个问题的答案时还是要靠人肉翻目录、猜关键词最后可能还得问老同事“那个文档到底放哪了”。知识库本质上只是把分散的内容集中存放了它解决了“东西丢不了”的问题但没有解决“东西找得到、问得出”的问题。RAG 做的事就是把最后这一层打通用户提问系统从知识库里检索相关内容再由大模型组织成自然语言回答。这里有一个关键点——回答必须基于检索到的内容而不是模型自己脑补否则“知识库”就变成了“模型自由发挥”。我用一个生活类比帮团队理解这件事知识库像一座图书馆的藏书室里面的书又多又全但读者不知道哪本书里有答案RAG 负责把问题在书架上定位到具体的几本书、翻到相关章节再由一个“话痨”图书管理员把这些内容用口语总结给读者。藏书室是基础但它不产生服务服务是检索和生成一起完成的。1.2 为什么在 Java 侧打通而不是另起炉灶我接触到的不少团队知识库已经存在但做智能问答的人第一反应是“用 Python 写一个独立服务”。站在技术尝鲜的角度Python 生态确实有 LangChain、LlamaIndex 这些工具RAG 相关的轮子也更丰富。但你回头看业务系统的现状用户体系在 Spring Boot 里权限体系在 Spring Boot 里接口暴露也是 Spring Boot。在一个成熟的 Java 团队里为了一个问答功能引入第二套技术栈等于给自己埋了运维和协作上的雷。更顺的路是直接用 Spring AI 把它嵌进现有服务复用已有的登录、鉴权、日志链路让知识问答变成业务系统里的一个普通接口。这也是我把方案定位成“Spring AI RAG”而不是“Python RAG”的原因——不是哪个语言更牛而是 Java 项目里用 Spring 生态本来就最顺。1.3 Spring AI 在 RAG 链路里的角色Spring AI 是 Spring 生态面向 AI 应用的一套抽象层它不重新发明 RAG而是把 RAG 链路里的组件都封装成了可替换的接口EmbeddingModel 负责把文本向量化VectorStore 负责存取向量ChatModel 负责对话生成QuestionAnswerAdvisor 负责把“检索 组装上下文 回答”串成一条流水线。你只要搭好这套骨架具体用哪家模型、哪款向量库都是配置和注入的问题。对于已经会 Spring Boot 的 Java 程序员学习成本基本被压到了最低。你要学的不是新框架而是“RAG 各个环节的语义是什么、参数怎么调”这一点我会在第 2 部分展开。2. 拆解 RAG 链路四个组件决定成败2.1 Embedding把文字变成坐标Embedding 模型把一句文本映射成一组浮点数维度从几百到几千都有例如智谱的 embedding-2 是 1024 维OpenAI 的 text-embedding-3-large 是 3072 维。它的核心特点是语义相近的文本向量距离也近。你可以把它理解成给每句话做了一张“语义身份证”两句话意思接近身份证的坐标就挨得近。这里要强调一个使用原则知识库里的文档用什么模型向量化检索时也必须用同一个模型。我见过有人切库时用 A 模型上线时换了 B 模型结果整个库的向量全部失效重启服务后答案质量全崩这个问题排查起来非常隐蔽。所以我把“Embedding 模型一致性”写成了团队的上线检查项谁要换模型必须重新构建一遍知识库索引。在 Spring AI 里Embedding 模型就是一个接口。官方实现里有 OpenAiEmbeddingModel、OllamaEmbeddingModel智谱等国产模型厂商也给出了对应的 Spring AI 集成方式。业务代码统一面向 EmbeddingModel 编程底层模型换了上层代码不用动。2.2 切块策略别让大文档毁掉检索为什么一定要切块因为大模型上下文窗口再大也不可能把整本手册塞进去而且如果让模型从一千页文档里找答案定位精度会非常差。切块的目的是让知识库变成很多个小段落检索时只取最相关的几段拼进 Prompt。切块有两个核心参数块大小和重叠区。我常用的起手式是块大小 500 个字符、重叠 80 个字符。500 字符约等于正常 300 字上下的一段话语义完整性尚可80 字符的重叠区可以减少前后文被切断导致的语义断裂。具体取值要根据文档类型调整产品文档、FAQ按标题层级切优先保留章节语义500 字符块起步没问题。代码示例、配置片段块要小一些200 到 300 字符否则检索到半截代码根本没法用。表格数据强烈建议表格单独作为一块不要让切块器把表头和单元格拆散。Spring AI 里提供了 TokenTextSplitter也支持自定义 Splitter。我实践中比较推荐“按标题切 超长段落再二次切”这种组合方式。观察下来固定长度切块在文档结构良好的知识库上效果不错但如果你的文档结构混乱先做一轮清洗其实比调参更重要。2.3 向量存储从原型到生产的选型思路向量存储负责把 Embedding 后的向量存起来并在检索时做相似度搜索。Spring AI 抽象了 VectorStore 接口切换实现类对业务代码基本透明。我建议按项目阶段选型不要一上来就上重组件。方案适用场景优点缺点SimpleVectorStore本地原型、Demo零依赖内存实现几行代码跑通重启丢数据不适合生产Redis Vector Store中型项目已有 Redis部署简单支持持久化性能不错高维向量大量写入时需关注内存Milvus / Elasticsearch大型知识库多租户容量大、检索性能强、支持过滤组件重需要专门运维如果你团队里已有 Elasticsearch直接用它的向量检索能力是最省事的选择如果是从零开始Redis 方案的门槛最低。我原型阶段用的是 SimpleVectorStore一天内跑通了整个链路确认方案可行后换成了 Redis。这个决策路径很实用先验证业务逻辑再重构基础设施避免在不确定需求的时候过度设计。2.4 检索、重排与生成最后一公里闭环当用户提问进来链路是这样的先把问题向量化然后在向量库里做相似度搜索取 TopK 个文档块再把文档块作为上下文拼进 Prompt最后让大模型生成回答。这里有一个容易忽视的环节重排序。向量相似度检索本质上是“粗筛”检索结果可能包含语义接近但实际不相关的片段。如果有预算加一个 Reranker 模型把粗筛出的前 20 个块重新精排取前 5 个送进 Prompt回答精度会有肉眼可见的提升。我自己实测加 Reranker 之后回答“牛头不对马嘴”的情况至少减少一半。Prompt 设计也直接影响生成质量。我会在系统提示词里明确写“仅依据上下文中提供的信息回答问题如果上下文中没有答案直接承认不知道引用内容时指出来源。”这句话看起来简单但对幻觉的抑制效果非常显著。Spring AI 里可以用 PromptTemplate 把这些约束固化下来不用每个接口重复写。3. 实战落地让已有知识库变成问答服务3.1 依赖与配置最先踩坑的地方Spring AI 的依赖坐标变化比较快网上很多人粘贴的版本号可能已经过时。我最推荐的方式是你用 Spring Initializr 生成项目的时候直接勾选 Spring AI 相关依赖让官方帮你匹配一组兼容版本比从零散文章里抄坐标稳得多。你在 pom.xml 里会看到类似的依赖结构dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-zhipuai/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-vector-store-redis/artifactId /dependency配置文件里接入智谱或者 OpenAI 风格都类似下面是一份精简的 application.yml 示例spring: ai: model: chat: zhipuai embedding: zhipuai zhipuai: api-key: ${ZHIPU_API_KEY} chat: options: model: glm-4-flash embedding: options: model: embedding-2 vectorstore: redis: index: knowledge-index prefix: knowledge请注意不同版本的 starter 对配置项的迁移差异很大如果启动时报配置绑定错误就去官方文档翻对应版本的配置清单。这一步我在团队里反复提醒Spring AI 更新很勤出了问题先怀疑“版本和配置不匹配”不要急着怀疑业务代码。3.2 加载文档与写入向量库知识库内容加载我用的是 TikaDocumentReader它基于 Apache Tika能处理 Markdown、PDF、Word 等常见格式。你只需要把知识库文件的路径或者 Resource 传进去Spring AI 就能把文本内容提取出来。Configuration public class KnowledgeIndexConfig { Bean VectorStore vectorStore(EmbeddingModel embeddingModel) { return new RedisVectorStore( RedisVectorStore.builder() .embeddingModel(embeddingModel) .indexName(knowledge-index) .prefix(knowledge) .build()); } Bean CommandLineRunner loadKnowledge(VectorStore vectorStore, EmbeddingModel embeddingModel) { return args - { FileSystemResource resource new FileSystemResource(./docs); TikaDocumentReader reader new TikaDocumentReader(resource); ListDocument documents reader.get(); TokenTextSplitter splitter TokenTextSplitter.builder() .withChunkSize(500) .withChunkOverlap(80) .build(); ListDocument splits splitter.apply(documents); vectorStore.add(splits); }; } }这段代码做的事情很简单读取 docs 目录下的文件切成 500 字符左右的小块向量化后写入 Redis。我故意把这段写在 CommandLineRunner 里因为原型阶段你只需要启动一次让索引建好就行。后续做增量更新时可以单独抽象一个 IndexService按文档变更去重建单个文件的块而不是全量重建。3.3 实现问答接口问答接口是我最喜欢的部分因为 Spring AI 已经把复杂度封装得很干净。你不需要手动完成“检索、拼 Prompt、调用模型”这三步一个 QuestionAnswerAdvisor 就能串起来。RestController public class AskController { private final ChatClient chatClient; public AskController(ChatClient.Builder builder, VectorStore vectorStore) { this.chatClient builder .defaultAdvisors(QuestionAnswerAdvisor.builder(vectorStore).build()) .build(); } PostMapping(/ask) public String ask(RequestBody AskRequest request) { return chatClient.prompt() .user(request.question()) .call() .content(); } }QuestionAnswerAdvisor 会在每次询问时自动完成问题向量化、向量库检索、取出相关块拼进 Prompt、交给 ChatModel 生成。你甚至可以不写任何检索代码。如果检索结果需要按业务条件过滤可以在 Advisor 里传入 QueryRequest 的过滤条件比如只检索某个目录下、某个标签下的文档。这一点对于“知识库里有不同部门文档、不同用户只允许问自己部门内容”的场景特别有用。3.4 参数选择与效果验证RAG 的效果不是部署完就结束的它需要持续调参。我维护了一张验证用例表每次调完参数后跑一遍用结果倒推参数合理性问题类型示例期望结果常见失败直接命中“XX 服务的超时时间默认是多少”答出具体数字并说明出处块切得太碎答案被截断改写提问“那个服务连不上该怎么办”能理解并定向到 FAQ 文档检索不中因为表述和库中不一致跨文档组合“部署流程里前置条件有哪些”能合并多篇文档的信息只检索到其中一篇答案不完整TopK 参数的选择也有讲究。默认取 4 到 6 个块比较平衡太少会漏关键信息太多会把无关内容一起送进 Prompt导致模型学会“混搭胡编”。相似度阈值可以设一个兜底低于 0.7 的结果不要进 Prompt直接返回“知识库中未找到相关内容”。这个阈值需要在你的向量模型下实测不要照搬别人项目的数值。4. 进阶多轮对话、MCP 与 Agentic RAG4.1 RAG 和 MCP 到底有什么区别这个热搜词出现得很频繁说明不少人把这两个概念搞混了。我用一句话区分RAG 解决的是“怎么把外部知识喂给模型”MCP 解决的是“模型怎么调用外部工具和系统”。RAG 是查资料给你看MCP 是帮你办事。举例来说同样面对一个“报销审批卡住了”的问题RAG 会从知识库里检索报销流程文档告诉你“应该走哪个审批节点”MCP 则会直接调用审批系统的接口帮你查出单子卡在谁那里甚至替你触发催办。一个偏知识回答一个偏能力调用两者不是对立关系而是可以配合模型先用 RAG 了解规则再用 MCP 操纵系统。如果你只是让知识库能问答那用 RAG 就够了不需要上 MCP。MCP 意味着你要把自己的业务系统工具暴露给模型涉及权限、审计和安全性设计复杂度高很多。Java 团队不要为了赶热点而引入多余复杂度先把 RAG 跑稳再谈 MCP。4.2 多轮对话的三种设计方式知识问答一旦带上“多轮”检索策略就必须调整。用户在对话里说“那第二点呢”“它有什么缺点”这些问题的指代依赖于前文直接拿去向量检索几乎什么都查不到。我实测下来有三种方案按复杂度和效果递增排序。第一种是简单拼接把最近几轮对话文本拼到当前问题后面一起送去检索实现简单但噪声大Token 消耗也高。第二种是查询改写先用大模型把“那第二点呢”改写成独立问题“告警通知的第二点注意事项是什么”再用改写后的文本去检索。这种方式效果好很多也是我推荐的做法。第三种是使用 Spring AI 的 ChatMemory用 MessageWindowChatMemory 维护最近 N 轮对话让模型可以访问历史上下文相当于由模型自己决定怎么理解当前问题。生产环境我目前用的是“查询改写 ChatMemory”组合改写保证检索质量ChatMemory 保证生成连贯。成本上会多一次模型调用但换回来的问答体验是值得的。4.3 Agentic RAG当知识库不止一个如果你只有一个知识库基础 RAG 够用。但企业里常见的情况是产品文档、工单系统、人事制度、FAQ 分散在多个地方用户的问题根本不知道应该去哪个库查。这时候可以做 Agentic RAG也就是让模型自己决定查哪里。Spring AI 已经支持 Tool Calling可以把“检索产品文档”“检索工单系统”“查询员工制度”分别封装成函数模型根据用户意图决定调用哪个工具。这种方式相对灵活但也有明显代价路由决策不准时会变得又慢又贵。我的建议很直接先把单库 RAG 跑顺指标都稳定了再升级成多库路由。不要一上来就 Agentic否则你会同时面对检索调参和工具调度的双重问题排查成本翻倍。5. 常见问题与排查技巧实录5.1 检索结果不相关优先查这几点我在调试 RAG 时踩过最多的坑总结起来就是三个原因。第一切块不合理答案明明在文档里但被拦腰切断检索回来的块没有关键信息这时候要把块调大一点或者改成按标题切。第二Embedding 模型不一致索引构建和查询用了不同模型向量空间对不上。第三TopK 和阈值设置不当阈值太严导致查不到阈值太松导致答案被不相关内容污染。排查顺序建议是先看检索回来的原文块是否合理再看模型输入 Prompt 的实际内容最后再调参数。很多问题在“看 Prompt 实际内容”这一步就能定位。5.2 模型幻觉严重怎么办幻觉的根源是模型在上下文中找不到答案于是开始自由发挥。除了在 Prompt 里强制约束“仅依据上下文回答”之外我还有两个实用技巧。一是在 Prompt 尾部要求“回答中必须包含所引用文档的标题或 ID”这样可以倒逼模型只输出它真正看到的内容也方便用户回到原文验证。二是用 Reranker 压缩上下文把不相干的候选块过滤掉减少模型被误导的可能。如果这些做完仍然幻觉大概率是知识库里真的没有答案可以考虑告诉用户“该问题不存在于当前知识库”并附上相似问题推荐。5.3 性能与成本怎么控RAG 的成本大头在 Embedding 和 LLM 调用。控制成本的经验有几个第一高频问题加缓存同一个标准化问题在短时间内重复问直接命中缓存返回第二Embedding 结果落库缓存同一个文档块不要每次启动都重新向量化第三控制上下文长度不要无脑把大量候选块塞进 Prompt块越多 Token 越贵回答不一定更准。并发方面调用外部模型 API 时要做好限流和超时Spring AI 的 RetryTemplate 和超时配置要提前调好避免第三方抖动拖垮业务线程。5.4 从原型到生产要注意什么原型阶段我用 SimpleVectorStore 跑通后上了生产前做了一次完整的“工程化体检”。第一内存向量库换成 Redis 或者 Elasticsearch保证持久化和容量第二建立增量更新机制知识库文档每天都有改动全量重建索引成本太高至少要给每个文档记录一份版本号或更新时间戳按变化去更新对应块第三加监控看板重点关注问答接口耗时、向量库命中率、LLM 调用 Token 消耗。知识库索引不是静态数据它是会“过期”的维护策略决定了这个系统能不能长期好用。最后再分享一个我个人的实际体会知识问答系统上线后我让团队用“十个真实业务问题”作为验收基线每天跑一遍把每次调参的影响都记录下来。RAG 和传统接口最大的不同是它的效果需要持续调不存在“一次搞定”的版本。知识库已经有了设备也搭好了真正决定这件事上限的是你愿不愿意去持续迭代检索质量和回答体验。做下去文档就不再是一堆文件而是真正能回答问题的“团队记忆”。
Spring AI + Java + RAG：把知识库变成智能问答服务实战
先交代一个我最近常被问到的场景知识库已经有了文档也整理得很整齐接下来作为 Java 程序员还能做什么很多人以为把文档塞进系统就算完事但实际上知识库只是原料真正让用户用自然语言问出答案的是 RAG 这套技术。我是做 Java 后端的最近用 Spring AI 把团队里一个“沉睡”的 Wiki 变成了可问答的服务这篇就围绕 Spring AI、Java、RAG 和知识库这四个关键词把整个实战过程、踩过的坑和进阶思路写清楚。如果你已经有一个整理好的知识库想在 Spring Boot 项目里接入智能问答这篇文章里的方案可以拿来直接用。1. 知识库和 RAG 的关系先搞清楚你要解决什么问题1.1 知识库不等于知识服务先说一个我观察到的现象团队里“知识库已经有了”和“知识服务可用”之间往往隔着一层窗户纸。很多团队用 Obsidian、Wiki、Dify 甚至自研系统攒了一堆文档文件摆得整整齐齐但真正要找一个问题的答案时还是要靠人肉翻目录、猜关键词最后可能还得问老同事“那个文档到底放哪了”。知识库本质上只是把分散的内容集中存放了它解决了“东西丢不了”的问题但没有解决“东西找得到、问得出”的问题。RAG 做的事就是把最后这一层打通用户提问系统从知识库里检索相关内容再由大模型组织成自然语言回答。这里有一个关键点——回答必须基于检索到的内容而不是模型自己脑补否则“知识库”就变成了“模型自由发挥”。我用一个生活类比帮团队理解这件事知识库像一座图书馆的藏书室里面的书又多又全但读者不知道哪本书里有答案RAG 负责把问题在书架上定位到具体的几本书、翻到相关章节再由一个“话痨”图书管理员把这些内容用口语总结给读者。藏书室是基础但它不产生服务服务是检索和生成一起完成的。1.2 为什么在 Java 侧打通而不是另起炉灶我接触到的不少团队知识库已经存在但做智能问答的人第一反应是“用 Python 写一个独立服务”。站在技术尝鲜的角度Python 生态确实有 LangChain、LlamaIndex 这些工具RAG 相关的轮子也更丰富。但你回头看业务系统的现状用户体系在 Spring Boot 里权限体系在 Spring Boot 里接口暴露也是 Spring Boot。在一个成熟的 Java 团队里为了一个问答功能引入第二套技术栈等于给自己埋了运维和协作上的雷。更顺的路是直接用 Spring AI 把它嵌进现有服务复用已有的登录、鉴权、日志链路让知识问答变成业务系统里的一个普通接口。这也是我把方案定位成“Spring AI RAG”而不是“Python RAG”的原因——不是哪个语言更牛而是 Java 项目里用 Spring 生态本来就最顺。1.3 Spring AI 在 RAG 链路里的角色Spring AI 是 Spring 生态面向 AI 应用的一套抽象层它不重新发明 RAG而是把 RAG 链路里的组件都封装成了可替换的接口EmbeddingModel 负责把文本向量化VectorStore 负责存取向量ChatModel 负责对话生成QuestionAnswerAdvisor 负责把“检索 组装上下文 回答”串成一条流水线。你只要搭好这套骨架具体用哪家模型、哪款向量库都是配置和注入的问题。对于已经会 Spring Boot 的 Java 程序员学习成本基本被压到了最低。你要学的不是新框架而是“RAG 各个环节的语义是什么、参数怎么调”这一点我会在第 2 部分展开。2. 拆解 RAG 链路四个组件决定成败2.1 Embedding把文字变成坐标Embedding 模型把一句文本映射成一组浮点数维度从几百到几千都有例如智谱的 embedding-2 是 1024 维OpenAI 的 text-embedding-3-large 是 3072 维。它的核心特点是语义相近的文本向量距离也近。你可以把它理解成给每句话做了一张“语义身份证”两句话意思接近身份证的坐标就挨得近。这里要强调一个使用原则知识库里的文档用什么模型向量化检索时也必须用同一个模型。我见过有人切库时用 A 模型上线时换了 B 模型结果整个库的向量全部失效重启服务后答案质量全崩这个问题排查起来非常隐蔽。所以我把“Embedding 模型一致性”写成了团队的上线检查项谁要换模型必须重新构建一遍知识库索引。在 Spring AI 里Embedding 模型就是一个接口。官方实现里有 OpenAiEmbeddingModel、OllamaEmbeddingModel智谱等国产模型厂商也给出了对应的 Spring AI 集成方式。业务代码统一面向 EmbeddingModel 编程底层模型换了上层代码不用动。2.2 切块策略别让大文档毁掉检索为什么一定要切块因为大模型上下文窗口再大也不可能把整本手册塞进去而且如果让模型从一千页文档里找答案定位精度会非常差。切块的目的是让知识库变成很多个小段落检索时只取最相关的几段拼进 Prompt。切块有两个核心参数块大小和重叠区。我常用的起手式是块大小 500 个字符、重叠 80 个字符。500 字符约等于正常 300 字上下的一段话语义完整性尚可80 字符的重叠区可以减少前后文被切断导致的语义断裂。具体取值要根据文档类型调整产品文档、FAQ按标题层级切优先保留章节语义500 字符块起步没问题。代码示例、配置片段块要小一些200 到 300 字符否则检索到半截代码根本没法用。表格数据强烈建议表格单独作为一块不要让切块器把表头和单元格拆散。Spring AI 里提供了 TokenTextSplitter也支持自定义 Splitter。我实践中比较推荐“按标题切 超长段落再二次切”这种组合方式。观察下来固定长度切块在文档结构良好的知识库上效果不错但如果你的文档结构混乱先做一轮清洗其实比调参更重要。2.3 向量存储从原型到生产的选型思路向量存储负责把 Embedding 后的向量存起来并在检索时做相似度搜索。Spring AI 抽象了 VectorStore 接口切换实现类对业务代码基本透明。我建议按项目阶段选型不要一上来就上重组件。方案适用场景优点缺点SimpleVectorStore本地原型、Demo零依赖内存实现几行代码跑通重启丢数据不适合生产Redis Vector Store中型项目已有 Redis部署简单支持持久化性能不错高维向量大量写入时需关注内存Milvus / Elasticsearch大型知识库多租户容量大、检索性能强、支持过滤组件重需要专门运维如果你团队里已有 Elasticsearch直接用它的向量检索能力是最省事的选择如果是从零开始Redis 方案的门槛最低。我原型阶段用的是 SimpleVectorStore一天内跑通了整个链路确认方案可行后换成了 Redis。这个决策路径很实用先验证业务逻辑再重构基础设施避免在不确定需求的时候过度设计。2.4 检索、重排与生成最后一公里闭环当用户提问进来链路是这样的先把问题向量化然后在向量库里做相似度搜索取 TopK 个文档块再把文档块作为上下文拼进 Prompt最后让大模型生成回答。这里有一个容易忽视的环节重排序。向量相似度检索本质上是“粗筛”检索结果可能包含语义接近但实际不相关的片段。如果有预算加一个 Reranker 模型把粗筛出的前 20 个块重新精排取前 5 个送进 Prompt回答精度会有肉眼可见的提升。我自己实测加 Reranker 之后回答“牛头不对马嘴”的情况至少减少一半。Prompt 设计也直接影响生成质量。我会在系统提示词里明确写“仅依据上下文中提供的信息回答问题如果上下文中没有答案直接承认不知道引用内容时指出来源。”这句话看起来简单但对幻觉的抑制效果非常显著。Spring AI 里可以用 PromptTemplate 把这些约束固化下来不用每个接口重复写。3. 实战落地让已有知识库变成问答服务3.1 依赖与配置最先踩坑的地方Spring AI 的依赖坐标变化比较快网上很多人粘贴的版本号可能已经过时。我最推荐的方式是你用 Spring Initializr 生成项目的时候直接勾选 Spring AI 相关依赖让官方帮你匹配一组兼容版本比从零散文章里抄坐标稳得多。你在 pom.xml 里会看到类似的依赖结构dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-zhipuai/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-vector-store-redis/artifactId /dependency配置文件里接入智谱或者 OpenAI 风格都类似下面是一份精简的 application.yml 示例spring: ai: model: chat: zhipuai embedding: zhipuai zhipuai: api-key: ${ZHIPU_API_KEY} chat: options: model: glm-4-flash embedding: options: model: embedding-2 vectorstore: redis: index: knowledge-index prefix: knowledge请注意不同版本的 starter 对配置项的迁移差异很大如果启动时报配置绑定错误就去官方文档翻对应版本的配置清单。这一步我在团队里反复提醒Spring AI 更新很勤出了问题先怀疑“版本和配置不匹配”不要急着怀疑业务代码。3.2 加载文档与写入向量库知识库内容加载我用的是 TikaDocumentReader它基于 Apache Tika能处理 Markdown、PDF、Word 等常见格式。你只需要把知识库文件的路径或者 Resource 传进去Spring AI 就能把文本内容提取出来。Configuration public class KnowledgeIndexConfig { Bean VectorStore vectorStore(EmbeddingModel embeddingModel) { return new RedisVectorStore( RedisVectorStore.builder() .embeddingModel(embeddingModel) .indexName(knowledge-index) .prefix(knowledge) .build()); } Bean CommandLineRunner loadKnowledge(VectorStore vectorStore, EmbeddingModel embeddingModel) { return args - { FileSystemResource resource new FileSystemResource(./docs); TikaDocumentReader reader new TikaDocumentReader(resource); ListDocument documents reader.get(); TokenTextSplitter splitter TokenTextSplitter.builder() .withChunkSize(500) .withChunkOverlap(80) .build(); ListDocument splits splitter.apply(documents); vectorStore.add(splits); }; } }这段代码做的事情很简单读取 docs 目录下的文件切成 500 字符左右的小块向量化后写入 Redis。我故意把这段写在 CommandLineRunner 里因为原型阶段你只需要启动一次让索引建好就行。后续做增量更新时可以单独抽象一个 IndexService按文档变更去重建单个文件的块而不是全量重建。3.3 实现问答接口问答接口是我最喜欢的部分因为 Spring AI 已经把复杂度封装得很干净。你不需要手动完成“检索、拼 Prompt、调用模型”这三步一个 QuestionAnswerAdvisor 就能串起来。RestController public class AskController { private final ChatClient chatClient; public AskController(ChatClient.Builder builder, VectorStore vectorStore) { this.chatClient builder .defaultAdvisors(QuestionAnswerAdvisor.builder(vectorStore).build()) .build(); } PostMapping(/ask) public String ask(RequestBody AskRequest request) { return chatClient.prompt() .user(request.question()) .call() .content(); } }QuestionAnswerAdvisor 会在每次询问时自动完成问题向量化、向量库检索、取出相关块拼进 Prompt、交给 ChatModel 生成。你甚至可以不写任何检索代码。如果检索结果需要按业务条件过滤可以在 Advisor 里传入 QueryRequest 的过滤条件比如只检索某个目录下、某个标签下的文档。这一点对于“知识库里有不同部门文档、不同用户只允许问自己部门内容”的场景特别有用。3.4 参数选择与效果验证RAG 的效果不是部署完就结束的它需要持续调参。我维护了一张验证用例表每次调完参数后跑一遍用结果倒推参数合理性问题类型示例期望结果常见失败直接命中“XX 服务的超时时间默认是多少”答出具体数字并说明出处块切得太碎答案被截断改写提问“那个服务连不上该怎么办”能理解并定向到 FAQ 文档检索不中因为表述和库中不一致跨文档组合“部署流程里前置条件有哪些”能合并多篇文档的信息只检索到其中一篇答案不完整TopK 参数的选择也有讲究。默认取 4 到 6 个块比较平衡太少会漏关键信息太多会把无关内容一起送进 Prompt导致模型学会“混搭胡编”。相似度阈值可以设一个兜底低于 0.7 的结果不要进 Prompt直接返回“知识库中未找到相关内容”。这个阈值需要在你的向量模型下实测不要照搬别人项目的数值。4. 进阶多轮对话、MCP 与 Agentic RAG4.1 RAG 和 MCP 到底有什么区别这个热搜词出现得很频繁说明不少人把这两个概念搞混了。我用一句话区分RAG 解决的是“怎么把外部知识喂给模型”MCP 解决的是“模型怎么调用外部工具和系统”。RAG 是查资料给你看MCP 是帮你办事。举例来说同样面对一个“报销审批卡住了”的问题RAG 会从知识库里检索报销流程文档告诉你“应该走哪个审批节点”MCP 则会直接调用审批系统的接口帮你查出单子卡在谁那里甚至替你触发催办。一个偏知识回答一个偏能力调用两者不是对立关系而是可以配合模型先用 RAG 了解规则再用 MCP 操纵系统。如果你只是让知识库能问答那用 RAG 就够了不需要上 MCP。MCP 意味着你要把自己的业务系统工具暴露给模型涉及权限、审计和安全性设计复杂度高很多。Java 团队不要为了赶热点而引入多余复杂度先把 RAG 跑稳再谈 MCP。4.2 多轮对话的三种设计方式知识问答一旦带上“多轮”检索策略就必须调整。用户在对话里说“那第二点呢”“它有什么缺点”这些问题的指代依赖于前文直接拿去向量检索几乎什么都查不到。我实测下来有三种方案按复杂度和效果递增排序。第一种是简单拼接把最近几轮对话文本拼到当前问题后面一起送去检索实现简单但噪声大Token 消耗也高。第二种是查询改写先用大模型把“那第二点呢”改写成独立问题“告警通知的第二点注意事项是什么”再用改写后的文本去检索。这种方式效果好很多也是我推荐的做法。第三种是使用 Spring AI 的 ChatMemory用 MessageWindowChatMemory 维护最近 N 轮对话让模型可以访问历史上下文相当于由模型自己决定怎么理解当前问题。生产环境我目前用的是“查询改写 ChatMemory”组合改写保证检索质量ChatMemory 保证生成连贯。成本上会多一次模型调用但换回来的问答体验是值得的。4.3 Agentic RAG当知识库不止一个如果你只有一个知识库基础 RAG 够用。但企业里常见的情况是产品文档、工单系统、人事制度、FAQ 分散在多个地方用户的问题根本不知道应该去哪个库查。这时候可以做 Agentic RAG也就是让模型自己决定查哪里。Spring AI 已经支持 Tool Calling可以把“检索产品文档”“检索工单系统”“查询员工制度”分别封装成函数模型根据用户意图决定调用哪个工具。这种方式相对灵活但也有明显代价路由决策不准时会变得又慢又贵。我的建议很直接先把单库 RAG 跑顺指标都稳定了再升级成多库路由。不要一上来就 Agentic否则你会同时面对检索调参和工具调度的双重问题排查成本翻倍。5. 常见问题与排查技巧实录5.1 检索结果不相关优先查这几点我在调试 RAG 时踩过最多的坑总结起来就是三个原因。第一切块不合理答案明明在文档里但被拦腰切断检索回来的块没有关键信息这时候要把块调大一点或者改成按标题切。第二Embedding 模型不一致索引构建和查询用了不同模型向量空间对不上。第三TopK 和阈值设置不当阈值太严导致查不到阈值太松导致答案被不相关内容污染。排查顺序建议是先看检索回来的原文块是否合理再看模型输入 Prompt 的实际内容最后再调参数。很多问题在“看 Prompt 实际内容”这一步就能定位。5.2 模型幻觉严重怎么办幻觉的根源是模型在上下文中找不到答案于是开始自由发挥。除了在 Prompt 里强制约束“仅依据上下文回答”之外我还有两个实用技巧。一是在 Prompt 尾部要求“回答中必须包含所引用文档的标题或 ID”这样可以倒逼模型只输出它真正看到的内容也方便用户回到原文验证。二是用 Reranker 压缩上下文把不相干的候选块过滤掉减少模型被误导的可能。如果这些做完仍然幻觉大概率是知识库里真的没有答案可以考虑告诉用户“该问题不存在于当前知识库”并附上相似问题推荐。5.3 性能与成本怎么控RAG 的成本大头在 Embedding 和 LLM 调用。控制成本的经验有几个第一高频问题加缓存同一个标准化问题在短时间内重复问直接命中缓存返回第二Embedding 结果落库缓存同一个文档块不要每次启动都重新向量化第三控制上下文长度不要无脑把大量候选块塞进 Prompt块越多 Token 越贵回答不一定更准。并发方面调用外部模型 API 时要做好限流和超时Spring AI 的 RetryTemplate 和超时配置要提前调好避免第三方抖动拖垮业务线程。5.4 从原型到生产要注意什么原型阶段我用 SimpleVectorStore 跑通后上了生产前做了一次完整的“工程化体检”。第一内存向量库换成 Redis 或者 Elasticsearch保证持久化和容量第二建立增量更新机制知识库文档每天都有改动全量重建索引成本太高至少要给每个文档记录一份版本号或更新时间戳按变化去更新对应块第三加监控看板重点关注问答接口耗时、向量库命中率、LLM 调用 Token 消耗。知识库索引不是静态数据它是会“过期”的维护策略决定了这个系统能不能长期好用。最后再分享一个我个人的实际体会知识问答系统上线后我让团队用“十个真实业务问题”作为验收基线每天跑一遍把每次调参的影响都记录下来。RAG 和传统接口最大的不同是它的效果需要持续调不存在“一次搞定”的版本。知识库已经有了设备也搭好了真正决定这件事上限的是你愿不愿意去持续迭代检索质量和回答体验。做下去文档就不再是一堆文件而是真正能回答问题的“团队记忆”。
