1. 为什么 RAG 的瓶颈往往不在模型本身做 RAG 项目做久了你会发现一个很反直觉的现象换更大的模型、调更高的 temperature、甚至把 embedding 模型从英文换成多语言效果提升可能只有几个百分点但把 chunk 策略改一改、把检索从纯向量换成混合检索、再加一层 rerank整体回答质量能肉眼可见地往上跳一个台阶。这不是玄学而是 RAG 系统的信息流决定的——检索阶段决定了模型能看到什么生成阶段只是把看到的东西组织成话。如果检索回来的内容本身就是残缺的、错位的、或者被无关段落稀释的再强的模型也只能在垃圾上做文章。Spring AI 2.0 这一代把 RAG 的各个可插拔环节做得比 1.x 清晰很多VectorStore、DocumentRetriever、Advisor这几层的职责边界明确了也就意味着我们有了更多可以下手优化的地方。但工具变多之后很多人反而不知道从哪开始调。我见过不少项目上来就堆 rerank 模型结果 chunk 切得稀碎rerank 再准也救不回来也见过 chunk 切得很讲究但检索只用单一向量相似度遇到关键词精确匹配的场景直接翻车。这篇内容我想按信息流的顺序把 Chunking、混合检索、Rerank 这三段拆开讲每一段都给出可落地的配置思路、参数取舍的理由以及我在实际项目里踩过的坑。适合已经在用 Spring AI 搭 RAG、但效果卡在某个瓶颈上不去的同学也适合刚开始接触 RAG 工程、想少走弯路的开发者。核心关键词会围绕Spring AI、RAG、Chunking、混合检索、Rerank这几个点展开但不会停留在概念层面而是尽量给到能直接抄的配置和判断标准。先说一个我自己的判断RAG 优化是有优先级的顺序错了投入产出比会差好几倍。我的经验顺序是 Chunking 混合检索 Rerank。原因很简单Chunking 决定了信息的最小单元它是地基混合检索决定了召回的质量和覆盖面Rerank 是在召回结果里做精排它只能优化已经召回的候选集救不了根本没召回来的内容。下面逐段展开。2. Chunking决定 RAG 上限的地基工程2.1 固定长度切分为什么在真实文档上总是翻车刚上手的时候几乎所有人都会用TokenTextSplitter或者固定字符数切分设个 chunkSize800、overlap100 就开跑。在结构规整的文档上比如一段一段的说明文这招还能用但一旦遇到真实业务文档——带表格的、带多级标题的、代码和正文混排的、问答对格式的——固定长度切分的问题就暴露得很彻底。最典型的问题是语义截断。一个完整的操作步骤被从中间切开前半段在 chunk A后半段在 chunk B。检索时如果只召回了 A模型看到的就是一个半截指令生成出来的答案要么缺步骤要么把不完整的步骤当成完整的。我遇到过一个特别坑的案例一份配置文档里修改端口后需要重启服务这句话被切到了下一个 chunk结果模型给出的答案里永远少了重启这一步用户照着做怎么都不生效。第二个问题是噪声稀释。固定长度切分不关心内容边界一个 chunk 里可能混了三个不同主题的段落。向量化之后这个 chunk 的 embedding 是三个主题的平均跟任何一个具体问题的相似度都不高。检索时它可能勉强被召回但排名靠后而且塞进上下文后反而干扰模型判断。提示判断你的 chunk 是否切得合理有个很土但很有效的办法——随机抽 20 个 chunk 打印出来人工读一遍。如果你自己读着都觉得这段话说了一半那模型大概率也理解不了。2.2 按文档结构切分TokenTextSplitter 之外的几个选择Spring AI 2.0 里可用的切分器比 1.x 丰富除了基础的TokenTextSplitter还有基于段落、基于句子、以及可以自定义分隔符的实现。我的建议是优先按文档的天然结构切而不是按长度切。具体做法上Markdown 文档按标题层级切是最自然的。一级标题下的内容作为一个大块如果超过阈值再按二级标题拆以此类推。这样每个 chunk 天然带有一个语义主题embedding 的纯度高很多。代码文档可以按函数或类切问答对按 Q-A 边界切表格尽量整表保留表格被切开基本就废了。Spring AI 的DocumentTransformer接口允许你在切分前先做预处理我一般会写一个自定义的 transformer把文档按标题结构解析成树再自底向上合并小节点、自顶向下拆分大节点。核心逻辑是先按结构切再对超长节点做二次切分对过短节点做向上合并。这样既保留了语义边界又控制了 chunk 大小。关于 chunk 大小的取值没有万能数字但有个经验区间可以参考文档类型建议 chunk 大小tokenoverlap理由技术文档/API 说明400-60050-80段落短主题集中小 chunk 精度高长篇文章/报告600-900100-150段落长需要更多上下文才能完整表达问答对/FAQ按 Q-A 对切0天然边界不需要 overlap代码文档按函数/类切视情况函数完整性优先于长度overlap 的作用是缓解边界截断但也不是越大越好。overlap 太大会导致相邻 chunk 高度重复检索时召回一堆相似内容浪费上下文窗口。我一般控制在 chunk 大小的 10%-15%。2.3 元数据被大多数人忽略的检索增强利器Chunking 阶段还有一个经常被忽略的点给每个 chunk 打上元数据。Spring AI 的Document对象支持 metadata这个字段在检索阶段能做很多事。最基础的元数据包括来源文件名、章节标题、页码、文档类型。这些信息在检索后可以用来做过滤比如只在某个文档范围内检索也可以拼进上下文帮助模型定位信息以下内容来自《XX 配置手册》第 3 章。更进阶一点可以给 chunk 打上主题标签、时间戳、权限等级配合VectorStore的 filter 表达式做精细化检索。我做过一个项目文档更新频繁不同版本的配置项含义不同。如果只按语义检索很容易把旧版本的说明召回给用户。后来在 chunk 元数据里加了version和effectiveDate检索时用 filter 限定只查当前生效版本问题直接解决。这个改动成本很低但效果立竿见影。注意元数据的字段设计要在入库前想清楚因为一旦向量库里有大量数据后期补元数据是很痛苦的事。建议至少保留source、section、chunkIndex这三个字段。3. 混合检索让召回既懂语义又认关键词3.1 纯向量检索在什么场景下会失灵向量检索的强项是语义匹配——用户问怎么改端口文档里写的是修改服务监听端口字面不一样但语义一致向量能召回。但它的弱项同样明显对精确关键词、专有名词、编号、代码标识符不敏感。我踩过最典型的一个坑是产品型号检索。用户问XX-2000 支持哪些协议向量检索召回的却是一堆XX-1000XX-3000的文档因为型号在 embedding 空间里距离很近模型分不清这几个数字的差异。还有 API 名称、错误码、配置项 key 这类内容向量检索经常召回一堆看起来相关但实际不对的结果。另一个场景是长尾查询。用户问的是一个很冷门的组合条件向量检索因为训练数据的偏差可能根本召不回正确文档。这时候关键词检索BM25 这类反而能靠字面匹配命中。所以结论很清楚纯向量检索不够纯关键词检索也不够混合检索才是正解。混合检索的核心思路是同时跑两路召回然后做融合。3.2 Spring AI 里怎么搭一套可用的混合检索Spring AI 2.0 本身对混合检索没有开箱即用的一键方案但它的抽象层设计让你可以比较自然地组合。我的做法是实现一个自定义的DocumentRetriever内部持有两个检索器一个基于VectorStore的语义检索一个基于关键词的检索可以用 Lucene、Elasticsearch或者简单点用内存倒排索引。流程是这样的用户 query 进来同时发给两路检索器各自返回 top-K 候选然后用融合算法合并成一个统一排序的列表。融合算法最常用的是RRFReciprocal Rank Fusion它的好处是不依赖两路检索的分数尺度只看排名鲁棒性好。RRF 的公式很简单对每个文档得分 Σ 1/(k rank)其中 rank 是它在某一路检索结果里的排名k 是个平滑常数一般取 60。两路都排在前面的文档融合后得分最高。这个算法不需要调参实测下来比加权求和稳定得多因为向量相似度和 BM25 分数根本不在一个量纲上硬加权很容易翻车。在 Spring AI 里实现的时候我建议把两路检索的 top-K 设得比最终需要的候选数大一些。比如最终要 10 个候选给 rerank那每路召回 20-30 个融合后再截断。这样能保证召回率给后面的 rerank 留足空间。3.3 关键词检索这一路用什么实现最省心关键词检索的实现选择取决于你的数据规模和部署条件。小规模几万 chunk 以内用内存倒排索引完全够用启动时把 chunk 内容建索引查询时走内存延迟很低。规模再大就上 Elasticsearch 或 OpenSearch它们原生支持 BM25还能顺便做分词和同义词扩展。中文场景要特别注意分词。英文按空格切就行中文必须用分词器IK、jieba 之类否则 BM25 的效果会很差。我见过有人中文文档直接用空格分词结果关键词检索这一路基本等于没开。分词器的词典最好能导入业务专有名词不然型号、术语还是会被切碎。还有一个细节关键词检索的字段权重。标题、章节名这些字段的匹配应该比正文权重高因为标题往往概括了内容主题。Elasticsearch 里可以用 boost 控制内存索引的话就在打分时手动加权。这个调整对召回质量的影响比想象中大。检索方式强项弱项适用场景向量检索语义匹配、同义改写精确关键词、编号、专名自然语言提问关键词检索精确匹配、专名、编号同义改写、语义泛化型号、API、错误码查询混合检索兼顾两者实现复杂度高真实业务通用场景4. Rerank在候选集里做精排的最后一公里4.1 Rerank 到底解决了什么问题混合检索解决了召回得到的问题但召回结果里往往还是混着不少相关性一般的内容。向量检索和关键词检索都是粗排它们追求的是快和召回率对相关性的判断比较粗糙。Rerank 的作用就是在这个候选集上做一次精排用更强的模型通常是 cross-encoder 结构逐对计算 query 和文档的相关性把真正相关的顶上来。Cross-encoder 和双塔bi-encoder也就是 embedding 模型的区别在于双塔是 query 和文档分别编码再算相似度快但精度有限cross-encoder 是把 query 和文档拼在一起过模型能捕捉两者之间的细粒度交互精度高但慢。所以工程上的标准做法就是双塔负责召回cross-encoder 负责精排各司其职。Rerank 带来的提升在什么场景下最明显我的观察是候选集越大、噪声越多rerank 的价值越大。如果召回阶段已经很准top-5 里全是相关文档rerank 提升有限但如果召回 top-20 里只有一半相关rerank 能把相关的那一半顶到前面效果就很显著。4.2 在 Spring AI 里接入 Rerank 的几种姿势Spring AI 2.0 的DocumentRetriever抽象让接入 rerank 变得比较自然。基本思路是混合检索返回候选列表后不直接返回而是过一层 rerank 再返回。实现上可以包一个RerankDocumentRetriever内部持有混合检索器和 rerank 客户端。Rerank 模型的部署方式有几种选择。如果追求省心可以用现成的 rerank API 服务如果要求数据不出内网就本地部署开源 rerank 模型。本地部署的话模型体积和推理速度要权衡小模型几百 MB延迟低但精度一般大模型精度好但需要 GPU。我一般建议先用小模型跑通链路确认 rerank 确实有收益再考虑要不要上大模型。接入的时候有个容易忽略的点rerank 的输入长度限制。Cross-encoder 对 querydocument 的总长度有上限如果 chunk 太长会被截断截断后精度下降。所以 chunk 大小和 rerank 模型的最大长度要匹配chunk 别切太大。这也是为什么我在第 2 节强调 chunk 要控制在合理范围。4.3 Rerank 的收益评估与参数取舍Rerank 不是免费的它增加了一次模型推理延迟会上升。所以上线前一定要评估收益是否值得这个延迟。我的评估方法是准备一批真实 query 和标注好的相关文档对比混合检索直接返回 top-5和混合检索rerank 返回 top-5的命中率。如果提升明显比如从 60% 到 80%那延迟增加是值得的如果提升只有几个百分点就要考虑是不是召回阶段的问题更大先优化召回。参数上主要调两个候选集大小和最终返回数量。候选集太小rerank 没有发挥空间太大延迟高且收益递减。我的经验是候选集取最终返回数的 3-5 倍比较合适比如最终要 5 个候选集取 15-25 个。最终返回数量则取决于下游模型的上下文窗口和你的 prompt 设计一般 3-8 个。还有一个实践细节rerank 分数可以做阈值过滤。如果所有候选的 rerank 分数都很低说明知识库里可能根本没有相关内容这时候与其硬塞几个不相关的 chunk 给模型不如直接告诉用户没有找到相关信息。这个兜底逻辑能显著减少幻觉。5. 三段优化的联动与实测踩坑记录5.1 优化顺序错了会怎样一个真实的反例前面说了优化优先级是 Chunking 混合检索 Rerank这里讲一个我亲眼见过的反例。有个团队一上来就上了 rerank模型选的是当时效果最好的结果整体效果提升微乎其微。排查下来发现他们的 chunk 是固定 1000 字符切的很多 chunk 本身就是半截话rerank 再准也只能在这些残缺内容里排序排出来的第一名依然是残缺的。后来他们把 chunk 策略改成按标题结构切同样的 rerank 模型命中率直接涨了一大截。这个案例说明rerank 是在候选集里做选择它无法创造候选集里不存在的好内容。地基没打好上层怎么优化都是白费。反过来如果 chunk 切得好、混合检索召回也全但没上 rerank效果通常也不会太差只是 top 结果里可能混着几个相关性一般的。所以我的建议是先把 Chunking 做扎实再上混合检索最后用 rerank 收尾。每一步都验证收益不要跳步。5.2 各阶段的验证方法怎么知道这一步优化有没有用优化最怕的是感觉变好了但说不清好在哪。我一般会给每个阶段准备一套小规模的评测集20-50 个真实 query每个 query 标注 1-3 个应该被召回的相关 chunk。然后看两个指标召回率相关 chunk 有没有出现在候选集里和MRR相关 chunk 排在第几位。Chunking 阶段主要看召回率因为切分影响的是内容能不能被找到。混合检索阶段看召回率和 MRR 的综合提升。Rerank 阶段主要看 MRR因为它优化的是排序。这套评测集不需要很大但一定要用真实 query自己编的 query 往往太标准测不出真实问题。评测集还有个好处是可以防止回归。RAG 系统调参很容易顾此失彼改了 A 参数 B 指标掉了。有了固定评测集每次改动跑一遍心里有数。5.3 几个容易忽略的工程细节最后分享几个实操中容易忽略但影响不小的细节。第一embedding 模型和 rerank 模型要匹配语言。中文场景用英文为主的 embedding 模型效果会打折扣。选模型时先确认它对中文的支持程度最好用业务数据实测一下。第二向量库的索引类型影响检索速度和召回。HNSW 快但内存占用高IVF 省内存但需要训练且召回可能略低。数据量不大的话 HNSW 是首选参数上efSearch调大能提升召回但增加延迟需要权衡。第三上下文拼接的顺序有讲究。给模型的 chunk 不要随便堆按相关性从高到低排并且标注来源。模型对靠前的内容注意力更集中把最相关的放前面能提升回答质量。第四注意 token 预算。召回的 chunk 加上 prompt 模板、对话历史很容易超出模型上下文窗口。要在拼接前算好 token 数超了就截断或减少召回数量。这个逻辑最好做成可配置的不同模型窗口不一样。第五缓存。相同 query 的检索结果可以缓存尤其是 rerank 这种耗时操作。缓存 key 用 query 的归一化形式能省不少重复计算。提示RAG 优化是个系统工程不要指望某一个环节的调整能带来质变。真正有效的做法是每一段都做到及格线以上然后靠整体协同把效果拉起来。6. 关于 Spring AI 2.0 RAG 工程化的一点个人体会做了一段时间 Spring AI 2.0 的 RAG 项目我最大的体会是框架把抽象做得好是为了让你能替换每一层而不是让你不用管每一层。VectorStore、DocumentRetriever、Advisor这些抽象确实让组合变得灵活但灵活也意味着你需要对每一层的原理有判断否则很容易在错误的层上使劲。Chunking 这块我现在的习惯是任何新文档进来先人工看一遍结构再决定切分策略而不是套一个默认配置了事。混合检索这块关键词那一路的分词和字段权重值得花时间调它带来的召回提升往往被低估。Rerank 这块先确认召回质量再上别把它当成万能药。还有一点RAG 的效果评估一定要有数据支撑不能靠感觉。我见过太多项目在感觉优化了和感觉又变差了之间反复横跳最后谁也说不清到底哪个版本好。一套小而真实的评测集比任何调参技巧都重要。如果你正在做 Spring AI 的 RAG 项目卡在效果上不去我的建议是回到 Chunking 这一层重新审视一遍。很多时候问题不在模型而在你喂给模型的那几段文字本身。