上一篇我们先把整条线搭起来了，已经过了好几天了，今天周末我们来继续开始实战学习吧。

Spring Boot 做 AI，不是接一个模型接口就结束。真正往后走，大概会经历这样一条线：

Chat → RAG → Tool → MCP → Memory / Skill → Planner / Agent

这一期先不急着讲 Tool，也不急着讲 MCP，更不急着说 Agent。

因为很多项目一开始就犯了一个错误：基础的 Chat RAG 还没做稳，就开始谈 Agent。

最后结果往往是：页面上看起来很高级，能对话、能总结、能回答，可一遇到真实业务问题，答案就开始飘。

客户问一句：“我们这个设备过保以后还能不能免费更换配件？”它答得像模像样，但实际规则根本不对。

员工问一句：“这个项目交付延期，合同里有没有违约条款？”它给你总结了一大段，听着很专业，可真正打开合同，发现关键条款没引用到。

老板问一句：“上个月客户投诉最多的是哪类售后问题？”它开始分析趋势，但后台数据根本没接进来。

所以，做 AI 应用第一步不是追 Agent。第一步应该是先问清楚：

它到底知不知道我们自己的业务？

普通 Chat 的局限

很多所谓 AI 应用，其实只是一个聊天壳

Spring Boot 接 AI，最容易做的就是 Chat。

Controller 接收用户问题，Service 调用模型，模型返回答案。这一层很轻，也很适合作为起点。

Spring AI 的 ChatClient 本身就是为了这类调用设计的，它提供了 fluent API，可以和 AI Model 交互，也支持同步和流式调用；Prompt 里可以组织 system message、user message，以及一些运行时替换参数。

所以一个最小 Chat 应用大概就是这样：

@RestController@RequestMapping("/ai")public class AiChatController { private final ChatClient chatClient; public AiChatController(ChatClient.Builder bUIlder) { this.chatClient = builder .defaultSystem("你是一个企业知识助手，请用简洁、准确的方式回答问题。") .build(); } @GetMapping("/chat") public String chat(@RequestParam String question) { return chatClient.prompt() .user(question) .call() .content(); }}

这个东西有没有价值？

当然有。

它可以做文案、总结、润色、解释代码，也可以做一些通用问答。但它有一个明显的问题：

它回答的是模型已有知识，不是你企业里的真实知识。

你让它解释“什么是应收账款”，它可能答得不错。你让它回答“我们公司应收账款逾期超过 45 天以后，具体由谁跟进、走哪条审批、是否冻结发货”，它就不一定知道了。

因为这些东西不在模型参数里。它不知道你的合同，不知道你的制度，不知道你的客户资料，也不知道你系统里的业务规则。

这时候就必须进入第二层：RAG。

RAG 不是万能药，它只解决一件事：让模型先看资料再回答

RAG，全称 Retrieval Augmented Generation，中文常说“检索增强生成”。

这个词听起来很大，其实思想不复杂：

用户提问以后，系统先去知识库里检索相关资料，再把资料连同问题一起交给模型，让模型基于这些资料回答。

Spring AI 官方对 RAG 的定义也很明确：RAG 是为了缓解大模型在长文本、事实准确性和上下文感知上的限制；Spring AI 支持你自己搭建 RAG 流程，也提供基于 Advisor API 的开箱方案。

这句话很关键。

RAG 解决的不是“模型会不会思考”。它解决的是“模型回答之前有没有看到正确资料”。

这就像公司来了一个很聪明的新员工。

你问他：“我们售后补发流程怎么走？”如果他没看过你们的制度，只能凭经验猜。

但如果你先把售后手册、合同条款、内部 FAQ、历史工单处理规范都给他，他再回答，靠谱程度就完全不一样。

所以 RAG 的核心不是神秘算法，而是一套流程：

资料进入系统 → 切分成片段 → 转成向量 → 存进向量库 → 用户提问时检索 → 把相关内容塞进 Prompt → 模型基于资料回答

这条链路只要任何一环做差，最终答案都会不稳定。

RAG 工作流程图

Spring Boot 里做 RAG，最小结构应该长什么样

如果我们用 Spring Boot 做一个最小 RAG Demo，我建议先别做得太复杂。

第一期项目场景可以这样定：

企业知识问答助手

它先只解决一件事：员工可以问公司内部资料，比如售后流程、产品说明、交付规范、常见问题，系统基于已有文档回答。

不要一开始就接 CRM。不要一开始就查订单。不要一开始就自动建工单。

那些是后面的 Tool 和 Agent 阶段。

第二期我们只做：

让 AI 先知道资料，并且尽量基于资料回答。

架构可以很简单：

用户问题 ↓Spring Boot Controller ↓ChatService ↓RAG Advisor ↓VectorStore 检索相关文档片段 ↓ChatClient 调用模型 ↓返回答案

资料导入这边则是另一条链路：

PDF / Markdown / Word / 文本资料 ↓DocumentReader 读取 ↓DocumentTransformer 切分、清洗、补元数据 ↓Embedding Model 生成向量 ↓VectorStore 写入

Spring AI 的 ETL Pipeline 文档也是类似思路：它把 RAG 场景里的数据处理拆成 Extract、Transform、Load，核心组件包括 DocumentReader、DocumentTransformer 和 DocumentWriter；Document 可以包含文本、metadata，也可以包含其他媒体类型。

这就很适合 Java / Spring Boot 工程师理解了。

不用一上来就被“向量数据库”“embedding”“检索增强”这些词吓住。本质上还是我们熟悉的工程流程：

读数据、洗数据、拆数据、存数据、查数据、组装结果。

最小 Demo 里，先准备三类知识就够了

做第一版 RAG，资料不要贪多。

我建议先准备三类文档：

第一类，产品说明文档。比如产品功能、适用行业、价格规则、常见限制。

第二类，售后与交付流程。比如客户报修流程、补发流程、验收标准、延期处理。

第三类，FAQ 或历史问答。比如销售、客服、实施经常被问到的问题。

这三类文档非常适合做 RAG，因为它们有几个共同点：

内容相对稳定。业务价值明确。问答场景高频。即使答错，也不会立刻触发高风险业务动作。

这点很重要。

刚开始做 RAG，不要一上来就让它回答财务结算、合同法律责任、自动审批这种高风险内容。先从“知识辅助”开始，而不是从“自动决策”开始。

企业 AI 落地最忌讳的就是：系统还不稳，就急着让它做关键动作。

RAG 的三个常见坑

RAG 的第一个坑：资料脏，答案一定脏

很多人做 RAG，第一反应是找个向量库，把文档丢进去。

丢完以后发现效果不好，就开始怀疑模型不行、向量库不行、embedding 不行。

但真实问题经常是：

你的资料本来就是乱的。

比如：

一个制度文档里有旧版本和新版本产品说明里价格过期了FAQ 里有员工随手写的口语化答案Word 转文本后格式全乱PDF 里表格被拆碎了同一个问题在不同文档里有相互冲突的说法

这种情况下，RAG 检索出来的上下文本身就不可靠。模型再强，也只能在垃圾上下文里做“看起来合理”的总结。

所以做 RAG 前，第一件事不是调参，而是整理资料。

你至少要处理这几个问题：

文档有没有版本号内容是否过期是否存在互相冲突的规则表格是否能被正确解析标题层级是否保留每个片段是否知道自己来自哪个文档是否能追溯到原始来源

很多企业 AI 项目失败，不是败在模型，而是败在知识库本身。

这句话一点都不夸张。

RAG 的第二个坑：切分太粗或太碎，都会影响效果

RAG 里有一个很容易被忽略的细节：chunk，也就是文档切片。

你把整份文档直接塞进去，不现实。太长，超上下文，也不利于检索。

但你切得太碎，也会出问题。一句话一个片段，模型拿到的是零散信息，缺少上下文。

比如售后流程原本是这样：

1. 客户反馈少件后，客服需先核对订单和发货清单。2. 若确认仓库漏发，由仓库主管审批补发。3. 若客户签收超过 7 天，需要销售负责人确认。4. 补发单生成后，客服需在原工单中备注处理结果。

如果切得太碎，系统可能只检索到第 2 条，没拿到第 1 条和第 3 条。模型就会误以为只要仓库主管审批就能补发，忽略了“签收超过 7 天”的限制。

所以切片不是简单按字数切。更好的方式是结合：

标题层级段落语义表格结构业务流程完整性必要的上下文 overlapmetadata 标记

Spring AI 的 ETL 体系里，DocumentTransformer 就是负责这类转换处理的角色；官方示例中也把 TokenTextSplitter 作为 DocumentTransformer，把 VectorStore 作为 DocumentWriter 来组成处理链路。

技术上看，这是数据处理。业务上看，这是在决定“AI 回答问题时，到底能看到什么材料”。

这个环节做不好，后面调模型基本都是白费力气。

RAG 的第三个坑：只返回答案，不返回依据

企业项目里，RAG 不能只追求“答得像”。

更重要的是：它凭什么这么答？

一个企业知识助手，最好在回答后面带上来源：

来自哪份文档哪个章节哪个版本更新时间是什么命中了哪些片段

否则用户没法判断它的答案能不能信。

尤其是内部制度、合同条款、售后规则、产品参数这类内容，AI 只给结论是不够的。

比如它回答：

该客户签收超过 7 天，需要销售负责人确认后才能进入补发流程。

这句话后面最好能带上依据：

来源：《售后补发处理规范》v1.3，第 4 节，少件补发规则。

这不仅是用户体验问题，也是企业 AI 的安全边界。

AI 可以帮你总结，但它不能假装自己就是最终权威。真正权威的，还是原始资料、业务规则和系统数据。

Spring AI 里的 QuestionAnswerAdvisor，适合做第一版 RAG

如果只是做第一版企业知识问答，Spring AI 的 QuestionAnswerAdvisor 就很适合入门。

官方文档里说得很清楚：向量数据库存放模型不知道的数据；当用户问题发给模型时，QuestionAnswerAdvisor 会查询向量数据库中和问题相关的文档，再把向量库返回的内容追加到用户文本中，作为模型生成回答的上下文。

最小代码感觉大概是这样：

@Configurationpublic class AiConfig { @Bean ChatClient chatClient(ChatClient.Builder builder, VectorStore vectorStore) { return builder .defaultSystem(""" 你是一个企业知识助手。 回答时必须优先依据检索到的资料。 如果资料中没有明确答案，请直接说明“当前知识库没有找到明确依据”，不要编造。 """) .defaultAdvisors( QuestionAnswerAdvisor.builder(vectorStore).build() ) .build(); }}

然后 Controller 里继续保持简单：

@RestController@RequestMapping("/knowledge")public class KnowledgeQaController { private final ChatClient chatClient; public KnowledgeQaController(ChatClient chatClient) { this.chatClient = chatClient; } @GetMapping("/ask") public String ask(@RequestParam String question) { return chatClient.prompt() .user(question) .call() .content(); }}

这段代码不是为了炫技，而是为了说明一个核心思想：

RAG 不应该散落在业务代码里，而应该被封装成一条稳定的问答链路。

Controller 不应该关心怎么检索。业务层不应该到处拼 prompt。检索、上下文注入、模型调用，最好由一套稳定的组件组合起来。

否则你后面加 Tool、加 Memory、加 Planner 时，代码会越来越乱。

但第一版 RAG，一定要提前加一句“不会就说不会”

这点非常重要。

很多 RAG 项目效果差，不是因为它回答不出来，而是因为它太爱回答了。

资料里没有明确依据，它也会硬编一个看似合理的答案。这就是企业项目里最危险的地方。

所以第一版 system prompt 里，我一定会加类似这样的约束：

你必须优先依据检索到的资料回答。如果资料中没有明确依据，请直接说明“当前知识库没有找到明确答案”。不要根据常识或猜测补充企业内部规则。涉及金额、合同、审批、法律责任、财务结算等高风险问题时，必须提示用户以正式文件或人工确认为准。

这不是废话。

这是把 AI 从“自信胡说”往“谨慎辅助”拉回来。

企业里的 AI 助手，很多时候不是越会说越好，而是越知道边界越好。

这个阶段，不要急着做记忆

很多人会问：第二期要不要直接加 Chat Memory？

我建议：可以知道，但先不要作为主线。

因为这一期核心是 RAG。先让 AI 能基于企业知识回答。

记忆是下一层问题。Spring AI 文档里也明确区分了 Chat Memory 和 Chat History：Chat Memory 是模型为了维护当前对话上下文而使用的信息，不等于完整聊天档案；完整历史如果要长期保存，应该走另一套持久化方案。

这点后面我们会专门讲。

这里先记住一句话：

RAG 管“知识从哪里来”，Memory 管“对话和任务怎么不丢”。

这两个东西经常一起用，但不是一回事。

如果你第一版就把 RAG、Memory、Tool、Agent 全塞进去，最后很容易每一层都没做好。

企业知识问答助手 Demo

这一期 Demo 的边界，我建议这样定

这一期我们的最小 Demo 可以叫：

企业知识问答助手 v1

它只做四件事：

第一，导入几份企业资料。比如产品说明、售后流程、交付规范。

第二，把资料切分后写入向量库。保留标题、来源、版本、更新时间等 metadata。

第三，用户提问时检索相关片段。通过 Advisor 把检索结果加入上下文。

第四，模型基于资料回答。如果资料不足，就明确说“不确定”。

不要做这些：

不查真实订单不自动生成工单不修改业务数据不发消息给客户不做复杂多步任务

这些不是不能做，而是应该放到后面。

到了 Tool 那一期，我们再让它查订单。到了 MCP 那一期，我们再讨论外部系统标准化接入。到了 Memory 那一期，我们再解决多轮上下文和长期记忆。到了 Planner / Agent 那一期，我们再让它拆任务、分步骤执行。

这样每一层才不会混。

真正做 RAG，要从“答案漂亮”转向“答案可信”

很多人测试 RAG，只看一句话：

“它回答得像不像？”

我觉得这不够。

企业知识助手至少要看五个指标：

第一，能不能找到正确资料。问题问得不标准时，也能不能召回相关内容。

第二，能不能拒绝无依据回答。知识库没有的内容，它敢不敢说不知道。

第三，能不能保持业务边界。规则没写清楚时，不擅自替公司做承诺。

第四，能不能带出处。用户能不能追溯答案来自哪里。

第五，能不能持续维护。资料更新后，向量库能不能同步更新，旧版本能不能失效。

如果这五点没做好，就算页面再漂亮，也只是一个看起来高级的聊天框。

AI 在企业里最怕的不是不会说，最怕的是说得很顺，但没人知道它对不对。

第二期真正想讲明白的事

这一期我们其实只做了一件事：

把 Chat 从“通用聊天”推进到“基于企业资料的知识问答”。

这一步看起来不如 Agent 酷，但它是后面所有东西的地基。

因为 Agent 想执行任务，必须先知道规则。Tool 想调用系统，必须先理解用户意图。Memory 想沉淀经验，也得知道哪些知识是稳定的、哪些只是临时对话。Skill 想复用方法，更需要建立在清楚的业务流程之上。

所以别急。

Spring Boot 做 AI，第一步先把 Chat 跑通。第二步，就是把 RAG 做稳。

等它能基于企业资料靠谱回答了，我们再往前走一步：

让它不只是知道，还能调用系统能力。

下一期我们就开始进入 Tool。

到下一期，AI 就不再只是根据资料回答问题了。它会开始调用我们 Spring Boot 后端里的真实能力：查订单、查库存、查客户、甚至生成一张工单草稿。也就是从“知识助手”，正式走向“业务助手”。

也就是从“会说”，开始走向“会做”。

一步步搭建可用的业务助手

我会持续分享真实场景下的产品 UI/ AI / Agent /软件产品 思考与实践

我会持续记录：

AI Agent 的设计逻辑产品从 0 → 1 的过程产品 UI 设计和思考技术如何变成“能用的工具”AI 怎么让产品变得“更智能”用 AI 做项目 → 赚钱

关注我，一起见证代码和 AI 如何真正走进普通人的工作与生活。