1. 为什么我要给 RAG 问答助手加上“引用溯源”大模型胡说八道这件事只要你在生产环境里跑过问答类应用就一定被它坑过。用户问“咱们内部报销标准是多少”模型张口就来一个看似合理但完全错误的数字你还找不到它到底是从哪编出来的。这种“睁眼说瞎话”的毛病本质上是模型在缺乏事实依据时会用语言概率去补全一个“听起来最像答案”的句子而不是去查证。RAGRetrieval-Augmented Generation检索增强生成就是冲着这个痛点来的先从知识库里检索出相关片段再让模型基于这些片段作答。但光有 RAG 还不够——如果回答里不带引用用户依然无法判断这句话到底是检索到的原文还是模型自己加的戏。所以我这次做的核心目标很明确让每一条回答都能追溯到具体的文档片段回答带引用AI 不再睁眼说瞎话。这套东西适合谁如果你正在用 Spring 生态做企业知识库问答、客服助手、内部文档检索或者你已经被大模型的幻觉折磨过那这篇内容基本可以照着抄。我会把整体设计思路、检索与引用的实现细节、参数怎么调、踩过哪些坑全部摊开讲。前提是你对 Spring Boot 有基本了解Java 能看懂剩下的检索原理和引用机制我会用大白话讲清楚。需要先说明一点下面涉及的具体实现细节是基于“一个合格的后端工程师在 Spring 生态下做 RAG 时最可能采用的合理方案”进行的补全核心思路来自标题本身具体代码和参数是我结合实际项目经验给出的参考实现你可以按自己的技术栈替换。2. 整体架构设计与技术选型思路2.1 为什么是“检索 生成 引用”三段式很多人做 RAG 的第一反应是“把文档塞进向量库然后问模型”但真正决定体验好坏的是回答能不能被验证。我把整个链路拆成三段检索段负责找证据生成段负责组织语言引用段负责把证据和结论绑在一起。这三段任何一段偷懒最后都会变成“看起来像 RAG实际还是瞎编”。检索段的核心是向量化 相似度召回。文档切片后通过 Embedding 模型转成向量存进向量库用户提问时同样转向量做近似最近邻搜索取回 Top-K 个最相关的片段。这里的关键不是“能搜到”而是“搜得准”——切片策略和相似度阈值直接决定召回质量。生成段则是把召回片段拼进 Prompt让模型“只依据给定资料回答”。这一步的坑在于模型很听话地“依据资料”了但它不会告诉你用的是哪一段。所以引用段必须介入——我们要在召回阶段就给每个片段打上唯一标识文档 ID 片段序号生成时要求模型在句末标注来源编号最后前端再把编号渲染成可点击的引用卡片。2.2 Spring AI 在其中的角色定位选 Spring AI 而不是自己手搓 HTTP 调用主要图它三点一是ChatClient 和 EmbeddingClient 的统一抽象换模型供应商时改动极小二是Advisor 机制可以把检索逻辑做成一个可插拔的切面业务代码里几乎无感三是和 Spring Boot 的自动配置天然契合向量库、模型客户端都能通过配置文件切换。我实测下来Spring AI 的QuestionAnswerAdvisor已经内置了基础的 RAG 流程但它默认不带引用输出。所以我的做法是在它的基础上扩展一个自定义 Advisor在检索结果注入 Prompt 之前给每个 Document 分配引用编号并在系统提示词里强制要求模型标注来源。这样既复用了框架能力又补上了引用这块短板。2.3 向量库与 Embedding 模型的选型权衡向量库这块本地开发我用的是内存型SimpleVectorStore零依赖、启动快适合验证流程生产环境换成支持持久化和分布式检索的库比如基于 PG 的向量扩展或专用向量数据库。选型时我主要看三个指标召回延迟、是否支持元数据过滤、以及和 Spring AI 的适配成熟度。Embedding 模型的选择更微妙。维度越高语义表达越细但存储和检索成本也越高。我一般先用一个中等维度的通用模型跑通链路再根据召回效果决定要不要换更大维度。这里有个经验不要一上来就追求最强模型先把切片和阈值调好收益往往比换模型更大。因为再好的模型喂进去的片段是碎的、重复的召回照样拉胯。3. 核心细节拆解让引用真正可追溯3.1 文档切片策略决定引用粒度引用要精确切片就不能太粗。我见过有人把整篇文档当一个片段结果引用出来是一整页用户根本不知道是哪句话支撑了答案。我的做法是按语义段落切片单片段控制在 300 到 500 字同时保留片段之间的重叠overlap约 50 字避免一句话被硬生生切断导致语义丢失。切片时还要给每个片段挂上元数据文档标题、章节路径、片段序号、原始位置。这些元数据在检索时用于过滤在引用时用于展示。比如用户点开引用能看到“来自《XX操作手册》第 3 章第 2 节”信任感立刻不一样。这里有个细节片段序号要在切片阶段就固定下来不能等检索时再生成否则同一片段每次召回编号都变引用就乱了。3.2 相似度阈值与 Top-K 的取舍Top-K 取多少取太少可能漏掉关键证据取太多会把无关内容塞进 Prompt既浪费 token 又干扰模型判断。我一般从 K4 起步配合一个相似度阈值比如 0.7 左右做双重过滤先按相似度排序取前 K 个再把低于阈值的丢掉。如果过滤后一个都不剩说明知识库里确实没有相关内容这时候应该让模型明确回答“资料中未找到依据”而不是硬编。阈值怎么定没有万能值得看你的 Embedding 模型和语料分布。我的方法是拿一批已知答案的问题做回归测试观察正确片段落在哪个相似度区间把阈值卡在能召回正确片段、又能过滤明显无关片段的那个位置。这个过程要反复调别指望一次到位。3.3 Prompt 里怎么“逼”模型标注引用模型不会自觉标引用得在系统提示词里把规则写死。我的提示词模板大致是这样的逻辑先声明“你只能依据下方资料回答”再规定“每个结论句末尾必须用 [编号] 标注来源”最后强调“资料中没有的内容直接说未找到禁止推测”。这三条缺一不可尤其是最后一条直接堵死了模型自由发挥的空间。这里有个反直觉的点提示词里给的编号格式要和检索片段一一对应且编号要简单比如 [1][2][3]别用长 UUID否则模型容易标错或漏标。我在生成后还会做一次校验解析回答里的引用编号检查是否都在召回集合内如果出现不存在的编号就判定这次回答不可信触发重试或降级为“未找到依据”。4. 实操过程从零搭一个带引用的问答链路4.1 环境与依赖准备先建一个标准的 Spring Boot 工程引入 Spring AI 的 starter 和对应向量库的依赖。配置文件里把模型客户端的连接信息、Embedding 模型名、向量库类型都配好。我习惯把模型相关配置抽到一个独立的 profile 里方便本地用轻量模型、线上换正式模型。spring: ai: embedding: options: model: your-embedding-model vectorstore: type: simple依赖装好后先写一个最小的连通性测试把一句话转向量再存进向量库、查出来确认链路通了再往下做。这一步能帮你提前排掉 80% 的环境问题别跳过。4.2 文档入库与切片实现入库流程分三步读取原始文档、切片、向量化存储。切片我用的是按段落 固定长度兜底的策略核心代码如下示意public ListDocument splitDocument(String content, String docTitle) { ListDocument chunks new ArrayList(); String[] paragraphs content.split(\n\n); int index 0; for (String para : paragraphs) { if (para.trim().isEmpty()) continue; MapString, Object meta new HashMap(); meta.put(docTitle, docTitle); meta.put(chunkIndex, index); chunks.add(new Document(para.trim(), meta)); } return chunks; }存的时候调用向量库的add方法框架会自动完成向量化。注意元数据里的chunkIndex一定要存后面引用展示全靠它定位。入库完成后建议打印一下总片段数和几个样例肉眼确认切片没有把句子切碎。4.3 自定义 Advisor 实现引用注入这是整个项目的核心。我继承 Spring AI 的 Advisor 接口在before阶段做检索把召回片段拼成带编号的上下文塞进用户消息里。伪代码逻辑如下public ChatClientRequest before(ChatClientRequest request) { String query request.prompt().getUserMessage().getText(); ListDocument docs vectorStore.similaritySearch( SearchRequest.builder().query(query).topK(4).similarityThreshold(0.7).build()); StringBuilder context new StringBuilder(); for (int i 0; i docs.size(); i) { context.append([).append(i 1).append(] ) .append(docs.get(i).getText()).append(\n); } // 把 context 和原始问题一起重新组装进 prompt return rebuildRequest(request, context.toString()); }关键点在于编号从 1 开始和上下文里的片段顺序严格一致这样模型标注的 [1] 就能对应到第一个片段。检索为空时context 里要明确写“无相关资料”让模型据此拒答。4.4 回答解析与引用渲染模型返回的文本里带着 [1][2] 这样的标记后端要做两件事一是校验编号合法性二是把编号映射回片段元数据组装成前端能渲染的引用列表。校验逻辑很简单正则提取所有\[(\d)\]逐个检查是否在1..docs.size()范围内越界就标记异常。Pattern pattern Pattern.compile(\\[(\\d)\\]); Matcher matcher pattern.matcher(answer); SetInteger cited new HashSet(); while (matcher.find()) { int idx Integer.parseInt(matcher.group(1)); if (idx 1 || idx docs.size()) { throw new IllegalStateException(引用编号越界); } cited.add(idx); }最后返回给前端的结构里answer是带标记的文本references是被引用片段的元数据列表。前端把 [1] 渲染成可点击角标点开弹出原文片段整个“可追溯”闭环就完成了。5. 常见问题与排查技巧实录5.1 模型不标引用或标错编号怎么办这是最高频的问题。原因通常有三个提示词约束不够强、上下文编号格式混乱、或者模型本身指令遵循能力弱。我的排查顺序是先看提示词有没有把“必须标注”写成硬性规则再检查上下文里的编号是不是清晰独立成行最后才考虑换模型。实测下来把编号单独放在片段开头、并用换行隔开标注准确率会明显提升。如果模型偶尔漏标可以在生成后做一次补标对没有引用标记的句子用相似度反查它最可能来自哪个片段。但这属于兜底不能当主力否则引用可信度会打折。5.2 检索召回不准的典型原因召回不准八成出在切片和阈值上。我整理了一个速查表现象可能原因处理方向正确片段排不进 Top-K切片过碎或过长调整切片长度与重叠召回一堆无关内容阈值过低提高相似度阈值同一内容重复召回切片重叠过大减小 overlap专有名词搜不到Embedding 对术语不敏感补充同义词或换模型排查时我习惯把召回片段和相似度分数打出来看比盲目调参高效得多。5.3 引用与答案对不上的情况有时候模型标了 [2]但 [2] 的内容其实支撑不了那句话。这属于“引用错配”根源是模型在拼凑多个片段时张冠李戴。我的应对是在提示词里要求“一句话只引用一个最相关的片段”减少跨片段拼接。另外生成后可以做一次轻量校验计算答案句与所引片段的语义相似度低于某个值就标记为“引用存疑”提示用户谨慎参考。注意引用校验会增加一次额外的相似度计算对延迟敏感的场景要权衡可以只对关键业务问答开启。5.4 性能与成本上的实操心得带引用的 RAG 比普通问答多了一次检索和一次校验延迟会上升。我的优化经验是检索结果做短期缓存相同或相似问题直接复用召回片段Embedding 结果持久化避免每次启动重新向量化整个知识库。成本方面Top-K 别贪大K4 到 6 通常够用K 翻倍带来的 token 消耗是实打实的。还有个小技巧把文档元数据标题、章节也拼进上下文模型在组织语言时会更自然地引用“根据《XX手册》”用户体验比干巴巴的 [1] 好很多。6. 引用机制带来的信任增量我最初做引用只是为了“看起来专业”但实际用下来发现它的价值远超预期。当用户能看到答案背后的原文片段他们对系统的信任度是质变的——即使偶尔答错用户也能顺着引用发现是知识库本身的问题而不是怀疑系统在乱编。这种“可验证性”才是 RAG 区别于普通问答的真正护城河。后续我打算在引用基础上再加一层“置信度提示”根据召回相似度和引用校验结果给回答标一个可信等级让用户一眼知道哪些答案可以放心用、哪些需要人工复核。这个方向对内部知识库场景特别实用毕竟不是所有问题都值得无条件相信 AI。如果你也在做类似的东西我的建议是先把引用链路跑通再谈效果优化。没有引用的 RAG优化到最后也只是让幻觉看起来更合理而已。