Spring AI 与传统 RAG 对照

这页专门回答 4 个问题：

1. Spring AI 到底是什么，它和 RAG 是不是一回事；
2. 常见教程式 RAG 一般怎么做；
3. SmartLive 当前这套实现和传统 RAG 哪里一样、哪里不一样；
4. 为什么“把本地数据库的数据写入向量库”依然是正规的 RAG。

如果你是因为“我这个项目里的 Spring AI 用法是不是和别人不一样”点进来的，这页就是给你准备的。

1. 先说最容易混淆的结论

1.1 Spring AI 不是 RAG

Spring AI 是一个 Java / Spring 体系里的 AI 应用开发框架。

它提供的主要是这些能力：

• 模型接入：ChatClient、ChatModel
• 上下文管理：ChatMemory
• 向量能力：EmbeddingModel、VectorStore
• 工具调用：Tool
• Prompt、Advisor、结构化输出等基础抽象

而 RAG 是一种应用模式，核心是：

先检索外部知识，再让模型基于检索结果生成回答。

所以两者的关系是：

• Spring AI 是实现这件事的一套工具和抽象
• RAG 是你拿这些工具搭出来的一种架构模式

1.2 你这个项目不是“没做 RAG”，而是做的不是文档型 RAG

很多人一提 RAG，脑子里默认是：

• 把 PDF / Markdown / 知识库切块
• 丢进向量库
• 检索后直接拼 Prompt
• 让模型回答

这确实是最常见的教程路线，但它不是 RAG 的唯一合法形态。

SmartLive 当前做的是另一类：

业务数据型、结构化、可执行的 RAG。

---

2. 常见教程式 RAG 长什么样

先看最典型的“教程式 RAG”路径：

文档 -> 切块 -> 向量化 -> 相似度检索 -> 拼接上下文 -> 大模型回答

这种模式最适合回答的问题通常是：

• “这份文档里写了什么？”
• “知识库有没有提到这个概念？”
• “PDF 里关于某个字段怎么定义？”

它的优点很明显：

• 上手快
• 抽象清晰
• 很适合文档问答、客服知识库、论文问答

它的局限也很明显：

• 检索结果多是原始文本片段
• 业务过滤能力通常比较弱
• 面向“业务对象”的可执行能力不足

---

3. SmartLive 当前这套实现是什么类型

SmartLive 的 AI 主链路更适合用下面这句话概括：

业务数据库先增量同步到 Milvus，在线问答再通过 Agent / Tool / RagService 做领域化检索和生成。

也就是两条线：

1. 知识建库线

   • 商品、店铺、评价、博客等业务数据发生变化
   • 业务服务发 MQ 同步消息
   • AI 模块监听后转换成 Document(text + metadata)
   • 再写入对应的 Milvus 集合

2. 在线问答线

   • 用户发起 AI 对话
   • Agent / Tool 判断应该调用哪个领域能力
   • RagService 到向量库检索
   • 检索结果转为 VO、摘要或复合上下文
   • 模型组织答案并通过 SSE 回传

如果你还没看总图，建议先回到：

• AI Agent策略路由与RAG多维增强生成链路

---

4. SmartLive 和传统 RAG 的逐项对照

维度	常见教程式 RAG	SmartLive 当前实现
数据源	PDF、Markdown、FAQ、知识库文档	商品、店铺、评价、博客等业务数据库数据
入库前处理	文本切块	业务实体转 Document(text + metadata)
向量文本	大段 chunk 文本	更偏业务字段组合，如商品标题、副标题、规则、评价内容、店铺名称与地址
过滤方式	多为纯相似度召回	相似度召回 + metadata 精确过滤
检索调用方	多为统一检索器 / Advisor	ShopRagService、ProductRagService、ReviewRagServiceImpl、BlogRagService
编排方式	检索后直接喂给模型	Agent 路由 + Tool 调用 + 业务化 RagService
输出形式	文本回答为主	文本回答、摘要、推荐卡片、下单相关上下文
适合场景	文档问答、知识库检索	本地生活推荐、商品推荐、评价总结、探店内容聚合

你会发现，真正的差异不在“有没有 RAG”，而在：

SmartLive 把检索做成了业务系统里的一层能力，而不是一个孤立的文档问答插件。

---

5. 你的 Spring AI 用法和别人项目哪里不一样

5.1 一样的地方

从基础框架层看，你依然在用标准的 Spring AI 能力：

• ChatClient
• ChatMemory
• EmbeddingModel
• VectorStore
• Tool

也就是说，底座是正统的。

5.2 不一样的地方

真正不同的是你在业务编排层做了更多定制：

维度	常见 Spring AI 项目	SmartLive
向量库接入	自动配置一个默认 VectorStore	手动排除自动配置，自定义多套 VectorStore
检索入口	多是统一 Advisor	手写多个领域 RagService
问答组织	单个 ChatClient 直接对话	多个 ChatClient + Tool + Agent 路由
外部知识	文档块为主	结构化业务对象为主
最终目标	回答问题	回答问题 + 推荐店铺 / 商品 + 经营分析

所以更准确的说法不是“你的 Spring AI 不正规”，而是：

你把 Spring AI 用成了一套更贴近生产业务的 AI 服务底座。

5.3 再往前一步：结构化卡片不是让模型直接拼最终 JSON

这也是 SmartLive 和很多 Demo 最不一样、但很容易被忽略的一点：

• 模型不直接生成最终给前端渲染的完整业务 JSON
• 模型更像是在输出一个控制 JSON：type + selectedIds + replyText
• 后端再根据 Tool / RAG 返回的真实结果，回填最终 recommendations / orderId 等字段

如果你想看这条链路的细图，可以直接看下面这张图：

更完整的说明在：

• AI Agent策略路由与RAG多维增强生成链路

---

6. “把本地数据库写入向量库”为什么仍然是正规的 RAG

这其实是这类讨论里最常见的误区。

很多人会误以为：

• 文档进向量库才叫 RAG
• 数据库进向量库就不算 RAG

这个判断标准其实不对。

判断是不是 RAG，关键看 3 件事：

1. 有没有外部知识源
2. 回答前有没有发生检索
3. 检索结果有没有参与生成

SmartLive 这三点都满足：

6.1 外部知识源存在

Milvus 里存的是从业务数据库抽出来并加工后的知识索引，不是模型参数里自带的知识。

6.2 回答前先检索

用户提问后，不是模型直接拍脑袋回答，而是先由 Tool / RagService 去向量库做相似度检索。

6.3 检索结果参与生成

检索出来的结果会转成业务对象、摘要文本或复合上下文，再参与最终回答生成。

所以从架构定义上，它就是 RAG。

只不过它不是“文档型 RAG”，而是“业务数据型 RAG”。

---

7. SmartLive 这套做法的优势是什么

如果把这套实现放回本地生活业务里看，它的优势其实很直接：

7.1 更贴业务事实

模型回答时引用的不是泛化互联网知识，而是你系统当前真实存在的店铺、商品、评价和博客数据。

7.2 更适合做精确过滤

因为入库时保留了 metadata，所以可以做：

• 指定店铺
• 指定商品分类
• 指定评分区间
• 指定资源类型
• 指定区域或其他业务条件

这比只靠大段文本召回更稳。

7.3 更适合和 Tool / Agent 配合

SmartLive 的模型不是拿到几段文本就结束，而是可以：

• 先搜店
• 再汇总评价
• 再补博客笔记
• 最后给出综合推荐

这就已经从“问答”升级成“决策增强”了。

---

8. SmartLive 这套做法的边界和不足也要知道

这页不是为了把项目讲得无懈可击，边界也应该明确。

8.1 它不是最典型的 Spring AI 默认 RAG 流程

你当前主流程更多是手写业务检索，而不是完全依赖 Advisor 自动注入上下文。

这意味着：

• 灵活度更高
• 但统一抽象和复用成本也更高

8.2 spring.ai.rag.* 配置不是当前主流程的核心控制项

在 SmartLive 里，真正生效的检索逻辑更多在各个 RagService 里手写的 SearchRequest(query, topK, filterExpression)。

所以从表达上要说清楚：

• 你不是没做 RAG
• 而是没走“最标准化的默认 Advisor 流程”

8.3 这套实现更依赖业务建模质量

因为你做的是业务数据型 RAG，所以：

• 文档字段怎么拼成 text
• 哪些字段放到 metadata
• 检索后怎么转成 VO

这些设计会直接影响效果。

也正因为如此，它更像一套业务工程问题，而不只是“接个模型 SDK”。

---

9. 面试时最推荐怎么讲

如果面试官问你：

你这个 Spring AI 跟别人有什么不一样？这算不算正规 RAG？

推荐直接这样回答：

我这套不是最常见的文档问答型 RAG，而是业务数据型 RAG。
Spring AI 在这里主要提供 ChatClient、ChatMemory、EmbeddingModel、VectorStore、Tool 这些基础能力；
真正的业务编排是我自己做的，包括业务数据通过 MQ 增量同步到 Milvus、按商品/店铺/评价/博客拆成多个 RagService、再通过 Agent 和 Tool 选择合适的检索能力。
它当然是正规的 RAG，因为回答前确实发生了“检索外部知识并参与生成”这一步，只不过外部知识不是 PDF，而是业务数据库构建出来的私有知识底座。

---

10. 一句话记住这页

Spring AI 是底座，RAG 是模式；SmartLive 做的是业务数据型、结构化、可执行的 RAG。