身边不少做后端的朋友最近都在琢磨同一件事怎么把大模型接到自己的业务系统里而不是停留在“调 API 玩 demo”的阶段。我上个月刚好把一个企业内部知识库问答项目从零搭到了线上核心方案就是标题里这几个关键词的组合——Spring AI、RAG以及后面花了最多时间的“调优”。这套东西跑通不难但真要回答得准、引得出出处、扛得住线上问题里面全是细节。先说结论Spring AI 是 Java 生态里让我觉得“终于有位了”的 AI 应用开发框架RAG 则是目前解决模型知识过期、私有数据不可见、回答容易瞎编这些问题的主流方案。它俩配合起来等于你用熟悉的 Java 技术栈把企业内部文档切成片段、向量化、存进向量数据库再让大模型基于检索到的内容生成回答。本文不打算讲太虚的架构图就按我实际动手的顺序把 RAG 的最佳实践、参数调优和踩坑实录一条条写清楚适合正在做知识库问答、客服助手、内部文档检索这类场景的 Java 开发者。1. 为什么我最后选了 Spring AI 而不是自己拼一套 RAG1.1 RAG 解决的到底是什么问题在动手之前得先对齐一个基本认知大模型再强它知道的也只是训练时见过的公开内容。企业内部有一个几十万字的运维手册、产品白皮书、项目复盘文档模型完全没见过。如果硬把这些问题抛给模型它要么答“我不知道”要么一本正经地编一个答案也就是常说的幻觉。RAG 的做法很直接先把文档拆成小块并转成向量用户提问时先从向量库里检索出最相关的几个片段再把“问题 相关资料”一起交给大模型回答。模型不需要记住你的私有文档它只是在“开卷考试”时临时查阅材料。这样一来回答就能限定在给定资料范围内幻觉问题大幅减少而且答案还能追溯出处这对企业内部应用来说是刚需。1.2 自己拼 RAG 会遇到的真实麻烦刚开始我也考虑过自己写一个文档解析服务、一个文本切分工具、一个向量库里检索的接口再手动拼 prompt 调大模型。看起来每个环节都不难但真正连起来的时候会发现自己写的胶水代码越来越多。文档格式五花八门要适配切分参数要自己管理向量库的客户端要维护对话多轮历史得自己塞更别说切换不同模型服务商时接口差异带来的改动。Spring AI 吸引我的地方是它把这些反复出现的环节抽象成了几个稳定接口文档读取、文档转换、Embedding 模型、向量存储、以及一个负责“检索后回答”的顾问组件。我只需要按接口去接实现剩下的流程由框架串起来。对于 Java 团队来说这意味着整体架构更统一测试和替换组件也更方便而不是在业务代码里散落一堆 AI 相关的胶水逻辑。1.3 我理解中的最佳实践边界必须说清楚Spring AI 并不是万能的。它更擅长把“RAG 的骨架”搭好但每个环节的效果比如切多长、检索多少个片段、相似度阈值设多少仍然需要按业务数据去调。后面几节的内容我会把从“能跑”到“好用”中间涉及的参数和经验全部摊开来讲这些比我当时看官方文档学到的要实在得多。2. 先把 RAG 的完整链路拆明白再写第一行代码2.1 一个标准 RAG 项目在线上是怎么工作的我习惯把 RAG 拆成两条链路来理解一条是“写入链路”一条是“读取链路”。写入链路负责把文档变成可检索的向量文档加载从本地文件、对象存储、数据库或网页里取出原始内容文档清洗去掉页眉页脚、重复模板、无意义符号文本切分把长文档切成固定大小或按语义边界切分成块向量化用 Embedding 模型把每块文本变成一个高维向量存储把向量和原始文本、文档元数据一起写入向量数据库读取链路负责回答用户问题问题向量化把用户问题转成同一种 Embedding 模型的向量相似度检索在向量库里找与问题向量最接近的 TopK 个片段组装上下文把检索到的片段按顺序拼进 prompt并附上原文标识生成回答把完整 prompt 交给大模型让模型基于上下文作答后处理整理引用格式必要时做关键词过滤或答案校验你可能觉得这不就是把一些开源组件串起来吗是但真正影响效果的几乎全在切分参数、检索参数和提示词模板这些“看不见的地方”而不是框架本身。2.2 Spring AI 对这两条链路的核心抽象我用 Spring AI 时最常用的几个接口实际就对应了上面两条链路的关键节点。文档加载和转换这边有专门的 Reader 和 Transformer 概念。Reader 负责从不同来源读取数据Transformer 负责切分、清洗。向量化有统一的 EmbeddingModel 接口底层是某个模型服务的 API。检索和存储则是 VectorStore 的职责它屏蔽了不同向量数据库的差异。读取链路中最关键的是 Advisor。Spring AI 提供了一组 Advisor可以在调用模型前后插入逻辑。其中用于 RAG 的顾问组件会做这么几件事接收用户问题、从 VectorStore 检索相关文档、把文档合并进 prompt、再把模型回答返回。这个设计非常实用因为抽掉了检索和提示词拼接的样板代码业务里只需要设置好顾问参数。2.3 我的一次最小化工程配置当时搭建基础工程时我只加了一个客户端依赖、一个向量数据库依赖然后在一份配置里指定模型服务地址、Embedding 模型名称和向量库连接信息。整个工程启动后不需要自己写 HTTP 调用、不需要手动维护连接池这一点对 Java 开发者应该很有吸引力。配置上有一个容易忽略的点Embedding 模型必须和查询时用的模型保持一致。如果写入文档时用一种模型查询时换了另一种向量空间不对齐检索结果基本不可用。这个坑在第一次切换模型时很容易踩我后面专门讲。3. 写入链路里的隐性门槛文档切分和向量化调优3.1 文档加载先统一格式再谈效果很多 RAG 项目效果差不是因为模型不行而是文档加载阶段就没做好。我在项目里处理过 Word 文档、PDF、Markdown、HTML 和纯文本每种格式都有各自的坑。PDF 最容易出问题有些是从扫描件生成的本质是图片直接读取只会得到空白有些排版是多栏按顺序读取会把内容切成错乱的句子。我的处理方式是先转成文本再用正则把多余空行、页眉页脚、目录页码清掉最后人工抽查 20 到 30 个片段确认内容顺序是通顺的。这一步如果省掉后面检索到的片段可能是语义不完整的答案自然奇奇怪怪。Word 文档相对友好但要注意里面的表格和图片说明。表格如果被拍平成纯文本行和列的关系会丢失这块信息检索时容易误导。常用的补救办法是在切分之前把表格转成结构化描述或直接丢弃不重要表格。3.2 文本切分chunkSize 和 overlap 怎么定文本切分是写入链路里最影响效果的一环。切得太小单块文本语义不完整切得太大向量化后的语义容易被噪声稀释并且塞进 prompt 时可能超长。一开始我用的固定字符数切分每块 500 个字符块与块之间重叠 100 个字符。重叠的目的是避免一句话被从中间切断后下半句找不到上下文。但后来我意识到不同文档的最优切分参数完全不一样。技术文档句子长、术语密需要更小的块操作手册步骤性强按标题和段落切更合适。我的建议是准备一组真实文档作为测试样本按不同参数跑一遍再人工看几个典型问题的检索结果。参数可以围绕一个表格来选参数经验范围作用切分长度300 到 800 字符决定每块文本的语义完整度重叠长度50 到 200 字符缓解句子被切断带来的上下文缺失是否按标题分段建议开启尽量让一块文本围绕同一个主题是否去掉多余换行建议开启避免向量化时出现无意义符号切换分长度时不要只看“召回率”这种抽象指标直接看最典型的 5 个问题检索出来的片段是不是真的有答案。如果一个片段里只有半句话经常缺上下文那就调大 overlap如果一个块里塞了多个主题导致检索命中但答案混乱那就调小切分长度或按标题拆分。3.3 Embedding 模型选型与向量维度的影响Embedding 模型决定了文本进入向量空间后的表示质量。当时我在选型时主要对比了几类通用型、代码/技术文档型、中文优化型。不同模型在中文场景下的表现差距很大主要体现在专业术语的近义召回上比如“合同违约”和“违约责任”能不能被理解为相关。向量维度高不一定更好。高维度向量存储开销大、检索慢而且如果模型本身训练数据不够贴合业务维度再高也没用。我最后选了一个在中文通用场景下表现稳定、接口延迟也低的模型维度是 1024。这里有一个经验上线后每周抽几十个新增问题人工看命中片段如果发现某类术语总召回不到再考虑换模型或加同义词扩展。4. 检索侧调优从“能查到”到“查得准”4.1 检索的本质先召回再精排用户问“服务器内存满了怎么办”如果向量检索返回的是“内存条采购流程”那显然不相关。检索环节要解决的核心问题是把最相关的若干个片段从几百个候选里找出来。我一开始只关注一个参数返回多少条也就是 TopK。但实践下来发现单纯调大 TopK 会导致 prompt 里塞进太多无关内容模型容易被干扰。更合理的思路是先理解召回和精排的差异向量检索负责“别漏掉”后续的阈值过滤和重排负责“别错给”。Spring AI 里的检索通常支持设置检索条数和相似度阈值有的向量库还支持关键字检索和向量检索的混合方式。对于包含大量专业编号、型号、代码片段的业务纯向量检索容易忽略精确匹配混合检索的效果明显更稳。4.2 TopK、相似度阈值与关键参数实证我在调优时反复改动的参数主要有这几个参数最初值调优后调优原因TopK353 条经常漏掉关键内容5 条在可控范围内相似度阈值0.70.750.7 会引入明显不相关内容0.75 更干净上下文最大长度不限制2000 字符左右避免超出模型输入限制也降低干扰是否启用重排否是答案相关性明显提升TopK 和阈值的配合需要多测几轮。阈值设太高可能一条都检索不到模型会因为没有上下文而开始胡编阈值设太低每轮的 prompt 都很长回答质量反而下降。我通常用“十问十查”的方法拿 10 个真实业务问题跑一遍检索看每个问题命中片段里是否包含答案出处然后根据漏召回和虚召回的比例调整。相似度阈值还有一个容易踩的细节不同 Embedding 模型产出的相似度分布不一样。有的模型普遍相似度高0.8 才算相关有的模型普遍相似度低0.6 已经不错。所以不要照搬别人的阈值至少要拿 50 组真实问答对去画一下分布。4.3 重排让最相关的内容排到最前面向量检索返回的前几名不一定是最合适的。业务问题里经常有同义词、简称、不同表述向量相似度可能把语义相近但不太相关的片段排到前面。我之前的一个案例用户问的是“备份失败的处理”向量检索返回的片段里包含“备份策略”相似度也不低但真正能回答问题的内容排在第三。重排的做法是先取相对大的候选集比如 TopK 设为 10再用重排环节根据 prompt 相关的交叉编码分数重新排序最后取前 3 到 5 条进入 prompt。这个环节成本会高一些但效果非常直接。如果项目对延迟敏感可以把重排模型换成轻量版本或只在离线评估时开启。5. 提示词与引用模型回答得再像样也要管住它别乱说5.1 提示词模板明确告诉模型“只看材料”RAG 的答案质量不只取决于检索内容还取决于 prompt 怎么写。我第一次实现时只是简单拼接了“请根据以下内容回答问题”结果模型经常会补充一些材料里没有的常识甚至强行推理出一个结论。后来我把模板改成了明确约束先说明你是一个知识库助手然后说明“只允许依据提供的资料回答如果资料不足直接说明不知道回答时列出对应资料编号”。这一步看起来简单但对抑制幻觉非常有效。Spring AI 里可以用提示词模板的方式维护这段内容把检索片段和用户问题各自作为变量填充进去结构清晰。5.2 引用来源是内部知识库的命门企业内部做问答回答里必须能指出“这句话来自哪篇文档”。这不仅是审计要求也能让使用者验证答案降低模型出错时的信任危机。我在文档切分阶段就给每个片段保存了元数据包括文档标题、章节路径、页码或链接检索时这些信息会跟着向量一起返回。组装 prompt 时我给每段检索内容加一个编号例如资料[1]来自《运维手册》第三章内容… 资料[2]来自《故障排查指南》附录内容…然后要求模型回答时标注 [1]、[2]。这样前后端展示引用时只要解析文本里的编号就能映射到真实文档地址。这个做法实现成本很低但价值极高。5.3 控制上下文总量防止“信息淹没”检索结果不是越多越好。模型对输入里“重点信息”的敏感度有限一旦塞了 5000 字不相关或弱相关的内容真正有用的答案反而会被淹没。我的经验是把最终进入模型的上下文控制在 2000 字符左右如果单篇文档的命中片段太多就要靠重排或内容摘要再压缩一层。如果业务文档很长而检索到的片段都很碎可以考虑把命中片段做一次“片段拼合”把同一文档里相邻的且都命中的片段合并成一个更大的上下文块保留标题层级信息。这样模型能看到更完整的语境回答的连贯性会好很多。6. 上线后最常踩的坑从检索失效到回答失控6.1 向量库里没数据日志永远比代码诚实我在项目里遇到过不止一次启动一切正常但问什么都答不出来甚至答非所问。排查第一步先看向量库的集合里到底有没有数据。有时候是写入链路静默失败了比如文档读取抛异常被吞掉或者 Embedding 接口限流导致部分向量写不进去。我养成了一个习惯在写入链路的最后做一个统计任务每处理完一批文档就对比源文档数和向量条数偏差超过 5% 就告警。这个告警帮我在一次接口升级时及时发现了问题不然线上用户会先发现问题。6.2 检索不到相关片段先怀疑切分和图谱再怀疑模型“文档明明有这句话为什么检索不到”这是最常见的提问。我排查时一般按三步走第一步看切分后的文本是否完整有没有被截断第二步看问题里的关键词和文档里的表述是否差异很大比如文档写“MySQL”问题问“数据库”向量模型能不能把二者关联起来第三步才是怀疑 Embedding 模型不行。第二步的教训很深。有一次用户问“报销流程”文档里写的是“费用申请”两者在字面上毫无重叠向量检索怎么也召不回。后来我加了同义词扩展在写入时给关键文档补充别名标签效果立竿见影。6.3 答案和检索内容对不上提示词背大锅如果检索结果明明相关但答案跑偏问题通常出在提示词或参数配置。我遇到过一次顾问组件把检索到的上下文正确拼进了 prompt但是模型回答时还在使用自己的知识补充结论原因是提示词里没有明确“只能用资料内容回答”。把模板改成强约束之后基本没有再出现这种失控情况。还要检查多轮对话的历史有些对话框架会把用户多轮历史全部塞进 prompt导致上下文窗口被历史占满检索内容反而被截断。处理方式是把历史压缩成摘要或者只保留最近两三轮。6.4 性能与成本检索慢、调用贵检索太慢最常见的原因是向量库索引参数没调或者检索时返回的候选集太大。建议给向量字段建立合适的索引同时限制相似度计算时的候选范围。成本方面一方面要控制 TopK 和上下文长度另一方面要做好缓存相同或相似的问题短时间内重复查询直接返回缓存结果。我做了另一件事把文档按业务域分成不同的向量集合。比如“人力制度”和“技术运维”分开存放用户提问时先做一次简单的分类或关键词路由只检索对应集合。这样既提升精度又减少向量库扫描压力成本也降了。7. 把调优变成一个可持续的循环RAG 上线不是终点。文档会更新用户提问方式会变化Embedding 模型也可能升级所以调优必须是一个持续动作。我目前的做法是每周抽 50 个真实用户问题人工标记回答是否命中、是否有引用、是否跑题然后汇总成一张问题清单。连续两周出现同一类问题的优先处理检索侧零星出现的先看是不是提示词边界问题。另外给 RAG 链路建立可观测性是值得投入的。我在日志里记录了每个问题的检索片段列表、相似度分数、进入 prompt 的上下文长度、模型回答耗时。这样每次线上反馈“答得不对”都可以回放当时的链路现场而不是靠猜。最后再分享一个实际经验调 RAG 时不要只看单条回答好不好而是要建一组自己的评测问题集。我拿业务里最典型的 30 个问题反复跑每次改完参数就全量回归一遍用“命中是否相关、答案是否准确、引用是否存在”三个维度打分。这个方法看起来笨却是我所有调优里收益最大的一件事。如果你正准备在 Java 项目里落地 RAG不妨先把这套评测集建起来再开始调参你会少走很多弯路。
身边不少做后端的朋友最近都在琢磨同一件事怎么把大模型接到自己的业务系统里而不是停留在“调 API 玩 demo”的阶段。我上个月刚好把一个企业内部知识库问答项目从零搭到了线上核心方案就是标题里这几个关键词的组合——Spring AI、RAG以及后面花了最多时间的“调优”。这套东西跑通不难但真要回答得准、引得出出处、扛得住线上问题里面全是细节。先说结论Spring AI 是 Java 生态里让我觉得“终于有位了”的 AI 应用开发框架RAG 则是目前解决模型知识过期、私有数据不可见、回答容易瞎编这些问题的主流方案。它俩配合起来等于你用熟悉的 Java 技术栈把企业内部文档切成片段、向量化、存进向量数据库再让大模型基于检索到的内容生成回答。本文不打算讲太虚的架构图就按我实际动手的顺序把 RAG 的最佳实践、参数调优和踩坑实录一条条写清楚适合正在做知识库问答、客服助手、内部文档检索这类场景的 Java 开发者。1. 为什么我最后选了 Spring AI 而不是自己拼一套 RAG1.1 RAG 解决的到底是什么问题在动手之前得先对齐一个基本认知大模型再强它知道的也只是训练时见过的公开内容。企业内部有一个几十万字的运维手册、产品白皮书、项目复盘文档模型完全没见过。如果硬把这些问题抛给模型它要么答“我不知道”要么一本正经地编一个答案也就是常说的幻觉。RAG 的做法很直接先把文档拆成小块并转成向量用户提问时先从向量库里检索出最相关的几个片段再把“问题 相关资料”一起交给大模型回答。模型不需要记住你的私有文档它只是在“开卷考试”时临时查阅材料。这样一来回答就能限定在给定资料范围内幻觉问题大幅减少而且答案还能追溯出处这对企业内部应用来说是刚需。1.2 自己拼 RAG 会遇到的真实麻烦刚开始我也考虑过自己写一个文档解析服务、一个文本切分工具、一个向量库里检索的接口再手动拼 prompt 调大模型。看起来每个环节都不难但真正连起来的时候会发现自己写的胶水代码越来越多。文档格式五花八门要适配切分参数要自己管理向量库的客户端要维护对话多轮历史得自己塞更别说切换不同模型服务商时接口差异带来的改动。Spring AI 吸引我的地方是它把这些反复出现的环节抽象成了几个稳定接口文档读取、文档转换、Embedding 模型、向量存储、以及一个负责“检索后回答”的顾问组件。我只需要按接口去接实现剩下的流程由框架串起来。对于 Java 团队来说这意味着整体架构更统一测试和替换组件也更方便而不是在业务代码里散落一堆 AI 相关的胶水逻辑。1.3 我理解中的最佳实践边界必须说清楚Spring AI 并不是万能的。它更擅长把“RAG 的骨架”搭好但每个环节的效果比如切多长、检索多少个片段、相似度阈值设多少仍然需要按业务数据去调。后面几节的内容我会把从“能跑”到“好用”中间涉及的参数和经验全部摊开来讲这些比我当时看官方文档学到的要实在得多。2. 先把 RAG 的完整链路拆明白再写第一行代码2.1 一个标准 RAG 项目在线上是怎么工作的我习惯把 RAG 拆成两条链路来理解一条是“写入链路”一条是“读取链路”。写入链路负责把文档变成可检索的向量文档加载从本地文件、对象存储、数据库或网页里取出原始内容文档清洗去掉页眉页脚、重复模板、无意义符号文本切分把长文档切成固定大小或按语义边界切分成块向量化用 Embedding 模型把每块文本变成一个高维向量存储把向量和原始文本、文档元数据一起写入向量数据库读取链路负责回答用户问题问题向量化把用户问题转成同一种 Embedding 模型的向量相似度检索在向量库里找与问题向量最接近的 TopK 个片段组装上下文把检索到的片段按顺序拼进 prompt并附上原文标识生成回答把完整 prompt 交给大模型让模型基于上下文作答后处理整理引用格式必要时做关键词过滤或答案校验你可能觉得这不就是把一些开源组件串起来吗是但真正影响效果的几乎全在切分参数、检索参数和提示词模板这些“看不见的地方”而不是框架本身。2.2 Spring AI 对这两条链路的核心抽象我用 Spring AI 时最常用的几个接口实际就对应了上面两条链路的关键节点。文档加载和转换这边有专门的 Reader 和 Transformer 概念。Reader 负责从不同来源读取数据Transformer 负责切分、清洗。向量化有统一的 EmbeddingModel 接口底层是某个模型服务的 API。检索和存储则是 VectorStore 的职责它屏蔽了不同向量数据库的差异。读取链路中最关键的是 Advisor。Spring AI 提供了一组 Advisor可以在调用模型前后插入逻辑。其中用于 RAG 的顾问组件会做这么几件事接收用户问题、从 VectorStore 检索相关文档、把文档合并进 prompt、再把模型回答返回。这个设计非常实用因为抽掉了检索和提示词拼接的样板代码业务里只需要设置好顾问参数。2.3 我的一次最小化工程配置当时搭建基础工程时我只加了一个客户端依赖、一个向量数据库依赖然后在一份配置里指定模型服务地址、Embedding 模型名称和向量库连接信息。整个工程启动后不需要自己写 HTTP 调用、不需要手动维护连接池这一点对 Java 开发者应该很有吸引力。配置上有一个容易忽略的点Embedding 模型必须和查询时用的模型保持一致。如果写入文档时用一种模型查询时换了另一种向量空间不对齐检索结果基本不可用。这个坑在第一次切换模型时很容易踩我后面专门讲。3. 写入链路里的隐性门槛文档切分和向量化调优3.1 文档加载先统一格式再谈效果很多 RAG 项目效果差不是因为模型不行而是文档加载阶段就没做好。我在项目里处理过 Word 文档、PDF、Markdown、HTML 和纯文本每种格式都有各自的坑。PDF 最容易出问题有些是从扫描件生成的本质是图片直接读取只会得到空白有些排版是多栏按顺序读取会把内容切成错乱的句子。我的处理方式是先转成文本再用正则把多余空行、页眉页脚、目录页码清掉最后人工抽查 20 到 30 个片段确认内容顺序是通顺的。这一步如果省掉后面检索到的片段可能是语义不完整的答案自然奇奇怪怪。Word 文档相对友好但要注意里面的表格和图片说明。表格如果被拍平成纯文本行和列的关系会丢失这块信息检索时容易误导。常用的补救办法是在切分之前把表格转成结构化描述或直接丢弃不重要表格。3.2 文本切分chunkSize 和 overlap 怎么定文本切分是写入链路里最影响效果的一环。切得太小单块文本语义不完整切得太大向量化后的语义容易被噪声稀释并且塞进 prompt 时可能超长。一开始我用的固定字符数切分每块 500 个字符块与块之间重叠 100 个字符。重叠的目的是避免一句话被从中间切断后下半句找不到上下文。但后来我意识到不同文档的最优切分参数完全不一样。技术文档句子长、术语密需要更小的块操作手册步骤性强按标题和段落切更合适。我的建议是准备一组真实文档作为测试样本按不同参数跑一遍再人工看几个典型问题的检索结果。参数可以围绕一个表格来选参数经验范围作用切分长度300 到 800 字符决定每块文本的语义完整度重叠长度50 到 200 字符缓解句子被切断带来的上下文缺失是否按标题分段建议开启尽量让一块文本围绕同一个主题是否去掉多余换行建议开启避免向量化时出现无意义符号切换分长度时不要只看“召回率”这种抽象指标直接看最典型的 5 个问题检索出来的片段是不是真的有答案。如果一个片段里只有半句话经常缺上下文那就调大 overlap如果一个块里塞了多个主题导致检索命中但答案混乱那就调小切分长度或按标题拆分。3.3 Embedding 模型选型与向量维度的影响Embedding 模型决定了文本进入向量空间后的表示质量。当时我在选型时主要对比了几类通用型、代码/技术文档型、中文优化型。不同模型在中文场景下的表现差距很大主要体现在专业术语的近义召回上比如“合同违约”和“违约责任”能不能被理解为相关。向量维度高不一定更好。高维度向量存储开销大、检索慢而且如果模型本身训练数据不够贴合业务维度再高也没用。我最后选了一个在中文通用场景下表现稳定、接口延迟也低的模型维度是 1024。这里有一个经验上线后每周抽几十个新增问题人工看命中片段如果发现某类术语总召回不到再考虑换模型或加同义词扩展。4. 检索侧调优从“能查到”到“查得准”4.1 检索的本质先召回再精排用户问“服务器内存满了怎么办”如果向量检索返回的是“内存条采购流程”那显然不相关。检索环节要解决的核心问题是把最相关的若干个片段从几百个候选里找出来。我一开始只关注一个参数返回多少条也就是 TopK。但实践下来发现单纯调大 TopK 会导致 prompt 里塞进太多无关内容模型容易被干扰。更合理的思路是先理解召回和精排的差异向量检索负责“别漏掉”后续的阈值过滤和重排负责“别错给”。Spring AI 里的检索通常支持设置检索条数和相似度阈值有的向量库还支持关键字检索和向量检索的混合方式。对于包含大量专业编号、型号、代码片段的业务纯向量检索容易忽略精确匹配混合检索的效果明显更稳。4.2 TopK、相似度阈值与关键参数实证我在调优时反复改动的参数主要有这几个参数最初值调优后调优原因TopK353 条经常漏掉关键内容5 条在可控范围内相似度阈值0.70.750.7 会引入明显不相关内容0.75 更干净上下文最大长度不限制2000 字符左右避免超出模型输入限制也降低干扰是否启用重排否是答案相关性明显提升TopK 和阈值的配合需要多测几轮。阈值设太高可能一条都检索不到模型会因为没有上下文而开始胡编阈值设太低每轮的 prompt 都很长回答质量反而下降。我通常用“十问十查”的方法拿 10 个真实业务问题跑一遍检索看每个问题命中片段里是否包含答案出处然后根据漏召回和虚召回的比例调整。相似度阈值还有一个容易踩的细节不同 Embedding 模型产出的相似度分布不一样。有的模型普遍相似度高0.8 才算相关有的模型普遍相似度低0.6 已经不错。所以不要照搬别人的阈值至少要拿 50 组真实问答对去画一下分布。4.3 重排让最相关的内容排到最前面向量检索返回的前几名不一定是最合适的。业务问题里经常有同义词、简称、不同表述向量相似度可能把语义相近但不太相关的片段排到前面。我之前的一个案例用户问的是“备份失败的处理”向量检索返回的片段里包含“备份策略”相似度也不低但真正能回答问题的内容排在第三。重排的做法是先取相对大的候选集比如 TopK 设为 10再用重排环节根据 prompt 相关的交叉编码分数重新排序最后取前 3 到 5 条进入 prompt。这个环节成本会高一些但效果非常直接。如果项目对延迟敏感可以把重排模型换成轻量版本或只在离线评估时开启。5. 提示词与引用模型回答得再像样也要管住它别乱说5.1 提示词模板明确告诉模型“只看材料”RAG 的答案质量不只取决于检索内容还取决于 prompt 怎么写。我第一次实现时只是简单拼接了“请根据以下内容回答问题”结果模型经常会补充一些材料里没有的常识甚至强行推理出一个结论。后来我把模板改成了明确约束先说明你是一个知识库助手然后说明“只允许依据提供的资料回答如果资料不足直接说明不知道回答时列出对应资料编号”。这一步看起来简单但对抑制幻觉非常有效。Spring AI 里可以用提示词模板的方式维护这段内容把检索片段和用户问题各自作为变量填充进去结构清晰。5.2 引用来源是内部知识库的命门企业内部做问答回答里必须能指出“这句话来自哪篇文档”。这不仅是审计要求也能让使用者验证答案降低模型出错时的信任危机。我在文档切分阶段就给每个片段保存了元数据包括文档标题、章节路径、页码或链接检索时这些信息会跟着向量一起返回。组装 prompt 时我给每段检索内容加一个编号例如资料[1]来自《运维手册》第三章内容… 资料[2]来自《故障排查指南》附录内容…然后要求模型回答时标注 [1]、[2]。这样前后端展示引用时只要解析文本里的编号就能映射到真实文档地址。这个做法实现成本很低但价值极高。5.3 控制上下文总量防止“信息淹没”检索结果不是越多越好。模型对输入里“重点信息”的敏感度有限一旦塞了 5000 字不相关或弱相关的内容真正有用的答案反而会被淹没。我的经验是把最终进入模型的上下文控制在 2000 字符左右如果单篇文档的命中片段太多就要靠重排或内容摘要再压缩一层。如果业务文档很长而检索到的片段都很碎可以考虑把命中片段做一次“片段拼合”把同一文档里相邻的且都命中的片段合并成一个更大的上下文块保留标题层级信息。这样模型能看到更完整的语境回答的连贯性会好很多。6. 上线后最常踩的坑从检索失效到回答失控6.1 向量库里没数据日志永远比代码诚实我在项目里遇到过不止一次启动一切正常但问什么都答不出来甚至答非所问。排查第一步先看向量库的集合里到底有没有数据。有时候是写入链路静默失败了比如文档读取抛异常被吞掉或者 Embedding 接口限流导致部分向量写不进去。我养成了一个习惯在写入链路的最后做一个统计任务每处理完一批文档就对比源文档数和向量条数偏差超过 5% 就告警。这个告警帮我在一次接口升级时及时发现了问题不然线上用户会先发现问题。6.2 检索不到相关片段先怀疑切分和图谱再怀疑模型“文档明明有这句话为什么检索不到”这是最常见的提问。我排查时一般按三步走第一步看切分后的文本是否完整有没有被截断第二步看问题里的关键词和文档里的表述是否差异很大比如文档写“MySQL”问题问“数据库”向量模型能不能把二者关联起来第三步才是怀疑 Embedding 模型不行。第二步的教训很深。有一次用户问“报销流程”文档里写的是“费用申请”两者在字面上毫无重叠向量检索怎么也召不回。后来我加了同义词扩展在写入时给关键文档补充别名标签效果立竿见影。6.3 答案和检索内容对不上提示词背大锅如果检索结果明明相关但答案跑偏问题通常出在提示词或参数配置。我遇到过一次顾问组件把检索到的上下文正确拼进了 prompt但是模型回答时还在使用自己的知识补充结论原因是提示词里没有明确“只能用资料内容回答”。把模板改成强约束之后基本没有再出现这种失控情况。还要检查多轮对话的历史有些对话框架会把用户多轮历史全部塞进 prompt导致上下文窗口被历史占满检索内容反而被截断。处理方式是把历史压缩成摘要或者只保留最近两三轮。6.4 性能与成本检索慢、调用贵检索太慢最常见的原因是向量库索引参数没调或者检索时返回的候选集太大。建议给向量字段建立合适的索引同时限制相似度计算时的候选范围。成本方面一方面要控制 TopK 和上下文长度另一方面要做好缓存相同或相似的问题短时间内重复查询直接返回缓存结果。我做了另一件事把文档按业务域分成不同的向量集合。比如“人力制度”和“技术运维”分开存放用户提问时先做一次简单的分类或关键词路由只检索对应集合。这样既提升精度又减少向量库扫描压力成本也降了。7. 把调优变成一个可持续的循环RAG 上线不是终点。文档会更新用户提问方式会变化Embedding 模型也可能升级所以调优必须是一个持续动作。我目前的做法是每周抽 50 个真实用户问题人工标记回答是否命中、是否有引用、是否跑题然后汇总成一张问题清单。连续两周出现同一类问题的优先处理检索侧零星出现的先看是不是提示词边界问题。另外给 RAG 链路建立可观测性是值得投入的。我在日志里记录了每个问题的检索片段列表、相似度分数、进入 prompt 的上下文长度、模型回答耗时。这样每次线上反馈“答得不对”都可以回放当时的链路现场而不是靠猜。最后再分享一个实际经验调 RAG 时不要只看单条回答好不好而是要建一组自己的评测问题集。我拿业务里最典型的 30 个问题反复跑每次改完参数就全量回归一遍用“命中是否相关、答案是否准确、引用是否存在”三个维度打分。这个方法看起来笨却是我所有调优里收益最大的一件事。如果你正准备在 Java 项目里落地 RAG不妨先把这套评测集建起来再开始调参你会少走很多弯路。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
