## 01、痛点

我是老李。最近团队在做一个内部知识库问答，产品经理丢过来一份两百多页的 Spring AI 官方文档 PDF，说“我们把这个喂给模型，让它直接回答用户问题”。我一开始也觉得挺简单：PDF 解析成文本，拼接成一大段，塞进上下文，然后问模型。结果上线当天就被打脸。用户问“如何配置向量存储”，模型回答了一堆关于 Embedding 的内容，还把版本号搞错；用户问“怎样限制输出 token”，模型居然引用了一段完全不存在的章节。最让人头疼的是：答案没有出处，无法核对。我们试过把几万字的文档硬塞进去，结果模型只读懂了开头和结尾，中间细节大量丢失，还出现了“幻觉引用”。这就是典型的长文档直接问答的坑——没有检索，没有证据，只有上下文堆砌。为什么现在要讲这件事？因为 RAG 是当前解决这类问题最务实的方案，但很多人对它有误解，以为就是“向量数据库 + 大模型”。今天我想把这段从踩坑到跑通最小闭环的过程讲清楚。

## 02、是什么

RAG 的全称是 Retrieval-Augmented Generation，也就是检索增强生成。它的核心逻辑一句话：先从外部知识库找到与问题相关的内容，再把这些内容放进模型上下文，让模型基于这些内容生成答案。注意两个关键点：第一，必须有“检索”这一步；第二，模型的输入是“问题 + 相关证据”，而不是整个知识库。最小链路可以写成：Question → Retrieve → Context → Prompt → LLM → Answer。用户提出一个问题，系统去检索相关段落，把检索到的片段作为上下文拼进模板，再调用大模型生成最终答案。这个过程里，模型不是凭记忆回答，而是被限定在给定证据上作答。

在 Spring AI 的语境里，这个链路被抽象成模块化的 RAG 组件：文档读取、文本切分、向量化、向量存储、检索器、模板、模型调用。你可以把这些模块替换成不同实现，比如向量存储可以用内存实现，也可以用 Redis、PGVector 等。但无论怎么替换，链路的主干不变。

## 03、为什么

为什么要费这个劲？直接把整个 PDF 给模型不行吗？从实践看有三个问题。第一，上下文窗口有限。虽然现在很多模型支持超长上下文，但“能塞进去”不等于“能理解好”。长文本中间的信息容易被忽略，模型对文档中段内容的理解准确率下降明显。第二，事实准确性。模型生成文本是概率采样，如果知识全在模型参数里，它可能“记错”版本号、参数名，甚至会编造一个看起来合理但实际不存在的说法。第三，知识更新与溯源。文档更新后，重新训练模型不现实；而如果直接把全文塞进去，每次请求都携带大量重复内容，成本高且无法回答“你的依据是哪一页”。

RAG 的解决思路是把“知识”和“生成”解耦。知识放在外部存储里，查询时按需检索最相关的片段，生成时只关注这些片段。这样即使文档很长，模型只需要处理几百到几千字的证据；即使知识更新，只需要更新检索库；更重要的是，答案可以携带来源编号，形成可核对、可追溯的证据链。

这里回答一个常见问题：为什么把整个 PDF 一次塞给模型不是 RAG？因为缺少“检索”这个动作，也没有形成“问题 → 证据 → 答案”的约束链。你只是做了上下文填充，模型依然可以在整个文档范围内自由发挥，依然可能忽略关键段落或编造引用。RAG 的“检索”不是可有可无的附加步骤，而是让模型“先看证据再说话”的核心机制。

## 04、架构

Spring AI 里的 Modular RAG 把检索增强生成拆成几个清晰的模块。我按照实际链路讲一下：

- 文档读取：负责把 PDF、Markdown、网页等原始格式转成纯文本。常见实现有 Apache PDFBox、Tika。
- 文本切分：把长文档切成小块（chunk），每块通常几百到一千字。切分策略会直接影响检索效果，比如按段落、按标题、按固定长度加重叠。
- 向量化：用嵌入模型把每个文本块转成向量。这里会调用 Embedding 服务，比如 OpenAI、Azure、本地模型。
- 向量存储：保存文本块及其向量，支持相似度检索。Spring AI 支持内存向量库、Redis、PGVector、Milvus 等。
- 检索器：接收用户问题，生成查询向量，去向量存储里找最相似的 TopK 个文本块。
- 模板与模型调用：把检索到的文本块拼进一个 Prompt 模板，要求模型基于这些文本块回答，并标注引用编号。最后调用大模型生成结果。

这个架构的好处是模块化：你可以单独替换切分器、嵌入模型、向量库，而不需要改动整体流程。比如先从内存向量库开始，后面数据量大了换成 PGVector；先用简单的按段落切分，后面再改成带标题层级的切分。模块化 RAG 的初衷就是让你能先跑通最小闭环，再逐步优化每个模块。

要注意的是，Spring AI 的 Modular RAG 不是让你一开始就上复杂配置，而是先把组件抽象出来，让你知道每一层是干什么的，后面替换才有方向。

## 05、实战

我以“Spring AI 官方文档问答助手”为例，讲讲我是怎么从零跑通的。

第一步，准备文档。从 Spring AI 官网下载最新 PDF，注意版本一致性。然后把 PDF 解析成纯文本。解析后要检查有没有乱码、分页符、页眉页脚干扰。如果有页眉页脚重复出现，最好清除，否则会污染检索。

第二步，切分文本。我先用最简单的按段落切分，每段不超过 800 字，相邻块之间保留 100 字重叠。切分后得到几百个小块。每个块要带上元数据：来源文档名、页码、章节标题（如果解析得到）。这些元数据后面要用来输出出处。

第三步，向量化并写入向量库。调用 Spring AI 的 EmbeddingClient 把每个块转成向量，连同文本和元数据写入向量存储。我用的是内存向量库先跑通，后面再考虑换 PGVector。

第四步，实现检索。用户问题进来后，同样用 EmbeddingClient 把问题转成向量，然后调用向量库的相似度查询，取 TopK=5。这里 TopK 不要贪多，先固定 5，方便对比。

第五步，组装上下文。把检索到的 5 个文本块按顺序拼接，每个块前面加上编号 `[1]`、`[2]`...，并附上来源页码。同时在模板中明确写：`请仅根据以下资料回答，如果资料中没有答案，就说不知道。回答时在句末标注引用编号，例如 [1][3]`。这一步是“回答必须携带原文来源”的关键。模型只被允许引用给定的资料编号，不能凭空引用。

第六步，调用模型。我使用的是具有较强指令遵循能力的对话模型。输入就是“系统指令 + 资料列表 + 用户问题”。输出结果里会包含答案文本和引用编号。我后端再把引用编号映射回元数据，转换成实际来源文件、页码，作为响应中的 `sources` 字段返回。

跑通之后，我找了几个同事问 Spring AI 文档里的问题，比如“如何配置 Redis 向量存储”“Embedding 模型支持哪些”“如何实现对话记忆”等。大多数答案都能给出正确出处，偶尔有引用不准确，但至少能追踪到是检索问题还是生成问题。

## 06、洞见

做到这里，我最大的感受是：RAG 的核心不是 Vector Database，而是建立“问题 → 证据 → 答案”的 Grounding 链。很多人一聊 RAG 就急着选向量库、调嵌入模型、比召回率，却忽略了最根本的问题：你有没有让模型基于证据回答？你有没有把证据和答案绑定在一起？如果没有这条 grounding 链，向量库再快、嵌入再准，模型依然可能自由发挥。

为什么说不是 Vector Database？因为向量数据库只是实现检索的一种手段，不是目标。你完全可以用关键词检索、数据库查询、甚至规则匹配来替代向量检索，只要能把相关证据找出来并约束模型。RAG 的“检索”可以不是向量检索，但必须有“检索 + 约束生成”的组合。如果你把整个 PDF 塞给模型，哪怕你预先把 PDF 存进了向量库，但没有进行相似度检索，也不是 RAG；如果你检索出了段落，但没有要求模型基于段落回答、没有引用编号，那 grounding 链是断的，答案依然不可信。

所以，判断一个系统是不是 RAG，不要看它有没有向量库，要看它有没有形成“问题 → 证据 → 答案”的闭环，并且这个闭环可以被评测和追溯。证据是 grounding 的锚点，向量只是找到锚点的手段。

## 07、行动

基于上面的理解，我给团队定的行动原则是：第一版只做最简单的 TopK + Context，先建立可评测基线。

具体做法：先准备一个小型评测集，比如从文档里挑 50 个有明确答案的问题，人工写好参考答案和预期引用段落。然后跑通最小闭环：固定切分策略、固定 TopK=5、固定指令模板。评测三个指标：检索命中率（相关段落是否出现在 TopK 里）、答案准确率（答案是否与参考答案一致）、引用准确率（答案标注的引用是否确实包含回答依据）。有了这个基线，再去优化切分、嵌入模型、重排、混合检索等。每改一个变量，跑一遍评测集，看指标变化。没有基线的优化都是玄学。

如果团队资源有限，可以先不做自动评测，用人工抽查 20 个问题的结果，记录哪些答错、哪些引用错，逐步改进。但一定要有基线意识：先跑通，再迭代。

## 08、小结

RAG 不是一个新名词包装，而是解决模型长文理解弱、事实不准、知识难更新的实用工程方案。它的核心链路是：先检索证据，再基于证据生成答案，并强制要求携带出处。向量数据库只是检索实现的一种，不是 RAG 的本质。要做出可用的 RAG 问答助手，最好的路径是先跑通 TopK + Context 的最小闭环，建立评测基线，再逐步优化模块。别一上来就想着把整个 PDF 喂给模型，那不是 RAG，那是把问题丢给概率。

## 09、链接与概念说明

- RAG：Retrieval-Augmented Generation，检索增强生成。先检索相关文档片段，再让模型基于片段生成答案。
- Spring AI：一个面向 Java 生态的 AI 应用开发框架，提供多模型调用、向量存储、RAG 组件等能力。
- Modular RAG：将 RAG 流程拆成可替换模块的设计，如读取、切分、向量化、存储、检索、生成。
- 向量检索：把文本转成向量，通过相似度计算找到最相近的文本块。
- TopK：检索时返回相似度最高的 K 个结果，K 通常取 5-10。
- Embedding：把文本映射成稠密向量的过程，向量距离反映语义相似度。
- Grounding：让模型基于外部证据作答，减少幻觉，提升答案可追溯性。
- 上下文窗口：模型一次能处理的最大 token 数，长文档直接塞入容易超限或中间迷失。
- 官方文档：Spring AI 参考文档可在 spring.io 官方站点获取，建议使用与项目版本一致的 PDF。

我是老李。最近团队在做一个内部知识库问答，产品经理丢过来一份两百多页的 Spring AI 官方文档 PDF，说“我们把这个喂给模型，让它直接回答用户问题”。我一开始也觉得挺简单：PDF 解析成文本，拼接成一大段，塞进上下文，然后问模型。结果上线当天就被打脸。用户问“如何配置向量存储”，模型回答了一堆关于 Embedding 的内容，还把版本号搞错；用户问“怎样限制输出 token”，模型居然引用了一段完全不存在的章节。最让人头疼的是：答案没有出处，无法核对。我们试过把几万字的文档硬塞进去，结果模型只读懂了开头和结尾，中间细节大量丢失，还出现了“幻觉引用”。这就是典型的长文档直接问答的坑——没有检索，没有证据，只有上下文堆砌。为什么现在要讲这件事？因为 RAG 是当前解决这类问题最务实的方案，但很多人对它有误解，以为就是“向量数据库 + 大模型”。今天我想把这段从踩坑到跑通最小闭环的过程讲清楚。

《Spring AI 2.0实战》第9招 RAG先做最小闭环

通过 Spring AI 官方文档问答助手实战，讲清 RAG 的最小闭环、模块化架构，以及为什么 RAG 的价值在于证据链而非向量库。

架构师

人工智能

后端

开发工具

从SpringAI长文档问答踩坑到跑通RAG最小闭环的实战解析。通过检索增强生成架构，将文档切分、向量化并建立"问题→证据→答案"的Grounding链，解决模型幻觉和引用无出处问题。采用TopK+Context方案，实现答案可溯源、知识可更新，附模块化架构与代码实现细节。

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring AI 2.0实战》第9招 RAG先做最小闭环-腾讯云开发者社区-腾讯云

《Spring AI 2.0实战》第9招 RAG先做最小闭环

《Spring AI 2.0实战》第9招 RAG先做最小闭环

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐