Spring AI 私有知识库实战：用最小 RAG 做一个不乱答的智能客服

李福春

发布于 2026-07-28 12:12:16

1790

客服机器人最危险的，不是回答慢，而是把一条不存在的退款规则说得像真的一样。

我是老李。今天不堆概念，也不搭一套吃内存的“全家桶”，我们只做一个星河商城客服：把三份 Markdown 售后文档放进项目，用户询问退货、发票、物流时，系统先检索知识库，再依据命中的原文作答；查不到就明确转人工。

这篇文章会把 RAG 最容易被教程略过的细节摊开：文档怎样切块、向量检索到底返回什么、相似度阈值怎么挡住乱答、来源怎样跟着答案返回。正式架构使用 Redis 8.8.0 保存和检索向量；考虑到低配机器不适合同时运行数据库和大模型，案例准备了两个模式：默认模式只启动 Java，用内存测试替身验证整条 RAG 管道；真实模式再接 Redis 与 Ollama 轻量模型。你可以先把框架跑明白，再去有条件的机器验证真实组件。

01、智能客服真正的问题不是“不会聊”

普通大模型知道很多通用知识，却不知道企业昨天刚更新的售后政策。直接问它“签收七天还能退吗”，它可能给出常见规则，也可能把别的平台政策拼进来。语言越流畅，业务风险反而越隐蔽。

私有知识库客服至少要守住三条边界：

答案只能来自企业提供的资料；
用户能看到命中了哪份文档、哪一章节；
知识库没有依据时必须拒答，不能靠模型补全。

所以目标不是做一个“更会聊天”的机器人，而是做一个有证据、能拒答、可追踪的业务问答系统。RAG 正适合解决这个问题。

02、RAG 不是数据库加模型，而是一条证据链

RAG 是 Retrieval-Augmented Generation，也就是检索增强生成。它把一次问答拆成两段：先从私有资料中检索相关片段，再把片段连同问题交给模型生成答案。

在这个案例里，完整链路只有六步：

Markdown 文档 → 按章节切块 → 计算向量 → 写入向量库 → 相似度检索 → 带来源生成答案

这里有两个常见误区。第一，向量库保存的不是“答案”，而是文档片段、向量和元数据；第二，大模型并不会自动遵守知识库，必须在提示词中明确“仅依据上下文回答”，并在进入模型前设置检索阈值。否则即使命中了一段不相关内容，模型仍可能顺着它编下去。

我们还会把 source、title、score 一起返回前端。这样用户看到的不只是一句话，还有“售后政策.md / 七天无理由退货 / 0.99”这样的证据。

拿“退款多久到账”举例。系统不应该把整份售后手册都塞给模型，而应先找到“退款到账时间”这一小段。若用户换成“电子发票多久开出”，检索结果就应转向发票文档。问题虽然都带有“多久”，真正决定语义的却是“退款”和“发票”。嵌入向量的价值，就是让含义接近的问句与片段在向量空间里靠近，而不只做关键词完全匹配。

03、最小技术选型：只保留四个组件

项目使用 Java 21、Spring Boot 4.0.7 和 Spring AI 2.0.0。Spring AI 2.0.0 已在 2026 年 6 月正式发布，支持 Spring Boot 4.0 与 4.1。Web 页面由 Spring Boot 直接托管，不再引入 Node 服务。

向量存储选择 Redis 8.8.0。Redis 8 已把 Search、JSON 和向量检索等能力合并进 Redis Open Source，Spring AI 又提供了 spring-ai-starter-vector-store-redis 自动配置：一个依赖、一段连接配置，就能得到 VectorStore。对需要持久化、元数据过滤和后续扩展的客服来说，这比同时维护业务缓存和另一套专用向量数据库更简单。

项目准备两个 profile：

local-test：默认模式。用 Java 写的确定性嵌入、内存向量库测试替身和答案生成器，不启动 Redis 与模型，专门验证加载、切块、检索、阈值、来源和拒答。
ollama：真实模式。向量库使用 Redis 8.8.0，聊天模型使用 qwen3:0.6b，嵌入模型使用 qwen3-embedding:0.6b。

为什么不直接用一个聊天模型包办向量？因为“理解问题并作答”和“把文本映射为可比较的向量”是两项不同任务。拆开以后，检索效果更稳定，模型也更容易替换。

这个选型还遵循一个原则：正式架构只引入确实需要的进程。Redis 同时承担持久化向量与相似度检索，不再叠加另一套向量数据库；Spring Boot 直接托管页面，不引入独立前端服务。低配机器的测试 profile 则用同一 VectorStore 接口替换外部服务，不会污染正式配置。

04、先看架构：索引与问答是两条链

索引链在应用启动时执行。程序读取 resources/knowledge 下的 Markdown 文件，以二级标题为边界切块，再为每个片段补上文件名和章节名。随后嵌入模型把片段变成向量，Redis 使用 HNSW 索引保存向量、正文与元数据。

问答链在每次请求时执行。用户问题先被转换为向量，再用余弦相似度寻找最接近的三个片段。只有分数达到 0.55 的片段才能进入下一步；没有片段达标，系统直接返回“知识库中没有找到相关信息，请转人工客服”。

达标后，系统把问题、命中片段和限制性提示词一起交给答案生成器。真实模式由 Ollama 生成自然语言；Java 验收模式则从命中片段中提取预置答案。两种模式共享同一个加载器、VectorStore 接口、检索服务、接口和页面，因此能在低配机器上先验证大部分工程链路。

05、动手搭建：先让知识流起来

第一步，在 pom.xml 中引入 Web、Validation、Ollama Starter 和 Redis Vector Store Starter，并通过 Spring AI BOM 统一版本。不要为每个 Spring AI 模块单独写版本，否则升级时很容易出现接口错配。

第二步，建立最小知识库。案例只放三份文档：售后政策.md、发票说明.md、物流说明.md。每个二级标题只描述一个问题，例如“七天无理由退货”“电子发票开具时间”。这种按语义边界切块的方式，比粗暴地每五百字切一刀更适合短规则。

Document chunk = Document.builder()
    .text(sectionText)
    .metadata("source", fileName)
    .metadata("title", sectionTitle)
    .build();
vectorStore.add(chunks);

第三步，把检索条件写明白，不要依赖默认值。topK=3 控制最多取三段上下文，similarityThreshold=0.55 负责过滤弱相关结果。

SearchRequest request = SearchRequest.builder()
    .query(question)
    .topK(3)
    .similarityThreshold(0.55)
    .build();
List<Document> hits = vectorStore.similaritySearch(request);

第四步，先判断 hits 是否为空，再决定要不要调用模型。这一行分支就是客服不乱答的第一道闸门。答案返回时，把文档元数据和相似度一并映射成 sources。

第五步，用一个知识库之外的问题做反向验收。比如“星河商城的创始人是谁”，三份资料都没有答案，页面必须拒答，而且来源列表为空。

在当前低配机器上，执行 mvn test 就能验证上述流程，不需要启动 Redis 或下载模型。要验证真实组件，再到内存更充足的机器启动代码附带的 Redis 8.8.0 容器，安装 Ollama 并依次拉取两个模型，然后以 ollama profile 启动。代码、配置和验收问题都随文章提供，不把“理论可行”冒充“本机已经跑过真实模型”。

真实模式的配置也应显式写进 application-ollama.yaml：服务地址、聊天模型名、嵌入模型名和温度都由配置管理。温度设为 0.1，是希望客服表达稳定而不是追求创意。切换 profile 时，业务接口不变，页面也不需要修改。

06、三个细节决定 RAG 是演示还是系统

第一，切块按语义，不按字数。 如果“退货条件”和“退款时效”被塞进同一个大段，检索虽然可能命中，模型却容易混淆条件。短规则优先按标题切；长手册再考虑递归字符切分，并保留少量重叠。

第二，topK 和阈值要一起调。 topK 太小会漏证据，太大会把噪声送进模型；阈值太高容易拒答，太低容易错答。最有效的方法不是拍脑袋，而是准备一组“应该回答”和“必须拒答”的问题，观察命中片段及分数，再调整参数。

第三，拒答必须发生在模型之前。 仅在提示词里写“没有资料就说不知道”并不可靠。检索为空时由 Java 代码直接返回固定文案，可以省下一次推理，也切断了模型自由发挥的机会。生产环境还应记录问题、命中片段、分数、模型和耗时，才能定位一次错答究竟发生在检索还是生成。

评测时不要只准备正确问题。至少要包含同义改写、口语表达、跨章节问题、资料外问题和带错误前提的问题。例如把“七天无理由”改写成“拆箱后不满意能退吗”，能检查语义召回；询问“你们承诺十五天无理由，对吧”，能检查系统是否会迎合用户。一个小而稳定的评测集，比人工随便聊几句更能暴露回归。

07、从 Demo 走向可用，按这张清单升级

先别急着增加 Agent、工作流和多模型路由。一个能用的私有知识库客服，应按风险从低到高演进：

给知识文档增加版本号、生效时间、业务线和权限元数据；
用固定评测集持续观察召回率、拒答率和错误引用；
为 Redis 配置持久化、访问密码、备份恢复和高可用，索引名按环境隔离；
文档更新时做增量索引，避免每次启动全量重建；
对答案展示引用，对后台保存完整检索轨迹；
最后再加入对话记忆、改写查询、重排序和人工转接。

顺序很重要：先让证据链可靠，再让回答更聪明。否则功能越多，错误来源越难定位。

私有知识库还要特别关注权限。销售政策、内部工单和客户资料不能因为都进了向量库，就对所有用户可检索。生产实现应在元数据中写入租户、部门或角色，并在相似度检索时先做权限过滤。模型看不到无权访问的片段，才是真正的数据边界；只在页面隐藏来源，无法阻止敏感内容进入答案。

08、写在最后

这个案例刻意保持“小”：三份 Markdown、一个 Redis 向量库、一个检索接口、一个聊天页面。但它覆盖了 RAG 的核心闭环——知识入库、语义检索、阈值过滤、受控生成、来源引用和无答案拒答。

在低配机器上，先用纯 Java 模式理解和验证框架；换到合适环境，再切换真实 Ollama 模型。你不需要一上来就维护数据库、模型服务和前端工程，也不需要相信一张漂亮架构图。先问三个问题：退款能否命中正确章节？发票答案能否带来源？资料之外的问题能否拒答？这三关过了，才算真正迈进 RAG 的门。

09、参考资料与关键概念

Spring AI 2.0.0 GA 发布说明：https://spring.io/blog/2026/06/12/spring-ai-2-0-0-GA-available-now/
Spring AI 官方入门文档：https://docs.spring.io/spring-ai/reference/getting-started.html
Spring AI RAG 官方文档：https://docs.spring.io/spring-ai/reference/api/retrieval-augmented-generation.html
Spring AI 向量库文档：https://docs.spring.io/spring-ai/reference/api/vectordbs.html
Spring AI Redis Vector Store：https://docs.spring.io/spring-ai/reference/api/vectordbs/redis.html
Redis Open Source 8.8 发布说明：https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisce/redisos-8.8-release-notes/
Spring AI Ollama Chat：https://docs.spring.io/spring-ai/reference/api/chat/ollama-chat.html
Spring AI Ollama Embedding：https://docs.spring.io/spring-ai/reference/api/embeddings/ollama-embeddings.html
Spring AI 官方源码：https://github.com/spring-projects/spring-ai
Spring AI 官方示例：https://github.com/spring-projects/spring-ai-examples
Ollama qwen3:0.6b：https://ollama.com/library/qwen3:0.6b
Ollama qwen3-embedding:0.6b：https://ollama.com/library/qwen3-embedding:0.6b

本文默认 profile 中的内存向量库仅是测试替身，正式 profile 使用 Redis；真实组件步骤是可复现方案，当前机器未启动 Redis、Ollama，也未下载模型。自动化测试用于验证 RAG 工程链路，不用于代表真实语义模型的质量。