ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0.5em 1em;color: rgb(63, 63, 63);text-shadow: rgba(0, 0, 0, 0.1) 2px 2px 4px;">
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">在 AI 问答系统中，你是否遇到过这些尴尬场景？
用户问 “那个功能咋用”，系统因 query 模糊召回率不足 40%；多轮对话到第 15 轮，上下文 token 直接超限；不同数据源返回的文档重复率超 60%，生成答案满是冗余信息；检索不到结果时，系统要么报错要么 “一本正经地胡说八道”……ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">传统 “单点 RAG”（仅靠一次向量召回）在这些场景中早已力不从心。而Spring AI 框架通过模块化设计给出了破局之道 —— 用 “组合策略” 替代 “单点依赖”，让检索精度与召回率实现质的飞跃。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(15, 76, 129);">Spring AI框架通过模块化设计与组合策略，构建了“检索前优化→多源检索→检索后处理”的全链路技术方案，从根本上解决上述痛点。本文将深入拆解核心组件的技术原理，通过架构图、时序图与对比表可视化技术流程，同步附源码解析与参数调优模板。建议结合原文技术细节深入学习，掌握从“检索失效”到“精准召回”的工程化落地方法。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0.3em 1em;color: rgb(255, 255, 255);background: rgb(15, 76, 129);border-radius: 8px;box-shadow: rgba(0, 0, 0, 0.1) 0px 4px 6px;">一、为什么 “组合策略” 是 RAG 的破局关键？ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">传统 RAG 的痛点本质是 “单点脆弱性”：一次向量检索、一个静态 query、一套固定流程，缺乏容错与优化机制根本无法应对复杂场景的变化。而 Spring AI 的 “组合策略” 通过“三阶段九组件”的模块化拆分，让每个环节专注解决一类问题，将复杂问题拆解为可独立优化的技术单元，实现检索精度与系统稳定性的双重提升最终实现 “1+1＞2” 的效果。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;padding-left: 12px;color: rgb(63, 63, 63);">核心痛点与技术解法对照表 | ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;padding: 0.25em 0.5em;color: rgb(63, 63, 63);word-break: keep-all;background: rgba(0, 0, 0, 0.05);"> | | |
|---|
| | MultiQueryExpander生成3-5条变体+RewriteQueryTransformer精准改写 | |
| 历史上下文超限（＞4k token），向量嵌入失真 | CompressionQueryTransformer智能压缩，保留核心信息 | |
| | ConcatenationDocumentJoiner双重去重+置信度排序 | |
| | ContextualQueryAugmenter优雅提示+FallbackAdvisor降级策略 | |
核心技术组件：MultiQueryExpander（查询扩展）、RewriteQueryTransformer（查询改写）、CompressionQueryTransformer（上下文压缩）、ConcatenationDocumentJoiner（文档合并）、ContextualQueryAugmenter（上下文增强）构成Spring AI RAG的“技术五件套”，下文将逐一解析其工作原理与工程实践。
二、全局架构：把 “一次问答” 变成 “工业流水线”
Spring AI 将 RAG 拆解为Pre-Retrieval（检索前）、Retrieval（检索中）、Post-Retrieval（检索后） 三阶段，就像把 “问答” 变成一条可拆解、可优化、可观测的工业流水线。每个阶段只干一件事，接口清晰、可插拔，还能轻松做 A/B 测试。
优化后Query原始文档集结构化ContextPost-Retrieval检索后处理文档去重ConcatenationDocumentJoiner置信度重排DocumentRanker上下文注入ContextualQueryAugmenter长度控制DocumentCompressorRetrieval多源检索向量检索VectorStoreDocumentRetriever关键词检索ElasticsearchRetriever多源并行ExecutorService调度Pre-Retrieval检索前优化Query压缩CompressionQueryTransformerQuery改写RewriteQueryTransformerQuery扩展MultiQueryExpander用户原始QueryGeneration生成回答最终Answer
1. Pre-Retrieval：让问题 “问得更聪明”
目标是把原始 query 处理成 “高信噪比、无歧义、上下文对齐” 的检索指令，核心动作包括：
指代消解：用 CompressionQueryTransformer 把 15 轮对话压缩成一句背景，token 直降 80%
改写精炼：RewriteQueryTransformer 把 “那个咋用？” 变成 “Spring AI 如何开启日志？”
扩展召回：MultiQueryExpander 将 1 条 query 变成 3 条，覆盖同义词、英文、口语化表述
关键指标：压缩率（历史 token / 压缩后 token）、扩展命中率（扩展 query 召回文档与原 query 的交集比例）。
2. Retrieval：让文档 “找得更全”
目标是在限定时间内，把 “最相关、不重复、符合过滤条件” 的文档一次性拿齐，核心能力包括：
向量召回：VectorStoreDocumentRetriever 支持 top-k、相似度阈值、过滤条件三重控制
多路召回：多向量库并行（如 PgVector 语义检索 + Elasticsearch 关键词检索）
合并去重：ConcatenationDocumentJoiner 通过内容哈希或语义相似度去重，消除冗余
关键指标：Recall@k（答案是否在返回的 k 条文档中）、去重率（合并后文档数 / 合并前文档数）。
3. Post-Retrieval：让上下文 “喂得更准”
目标是把 N 条文档转化为 “干净、有序、符合 Prompt 长度” 的上下文，核心动作包括：
重排：DocumentRanker 用 cross-encoder 重算置信度，置顶高相关文档
精选：DocumentSelector 只保留与问题真正相关的段落，剔除无关信息
压缩：DocumentCompressor 通过 LLM 二次摘要，防止 token 溢出
注入：ContextualQueryAugmenter 按模板拼接 context+query，规范 Prompt 格式
关键指标：Context Faithfulness（答案是否仅依赖给定文档）、Token Utilization（Prompt 有效信息占比）。
各阶段技术目标与关键指标
三、核心组件技术解析：从源码逻辑到工程实践
1. MultiQueryExpander：解决“单一查询覆盖不足”的扩展机制
当用户输入模糊查询（如“如何配置存储”），单一检索易因表述差异漏检相关文档。MultiQueryExpander的核心技术原理是：通过LLM生成3-5条语义等价但表述不同的查询变体，扩大检索覆盖范围，提升召回率。
技术原理流程图
向量存储（PgVector）大语言模型（GPT-3.5-turbo）MultiQueryExpander用户原始Query（"如何配置存储"）向量存储（PgVector）大语言模型（GPT-3.5-turbo）MultiQueryExpander用户原始Query（"如何配置存储"）输入模糊查询渲染扩展提示（指定数量与规则）返回3条变体查询1."SpringAI如何配置向量存储"2."SpringAI存储组件设置步骤"3."如何在SpringAI中启用存储功能"多变体并行检索（top4/变体）合并召回结果（覆盖更多相关文档）
核心源码关键逻辑解析
@Override
publicList<Query>expand(Query query){
// 1. 构建提示模板，定义变体生成规则
Map<String, Object> vars = Map.of(
"query", query.text(),
"history", formatHistory(query.history()),
"numberOfQueries",3, // 生成3条变体
"requirements","保留核心实体，避免引入新实体，使用不同句式"
);
Stringprompt=promptTemplate.render(vars);
// 2. 调用LLM生成变体（带超时与重试保护）
ChatClientchatClient=chatClientBuilder
.defaultRequest(ChatClientRequest.builder()
.timeout(Duration.ofSeconds(3)) // 超时控制
.build())
.build();
Stringresponse=chatClient.prompt()
.user(prompt)
.call()
.content();
// 3. 解析变体并构建Query列表
List<String> lines = Arrays.stream(response.split("\\n"))
.map(String::trim)
.filter(s -> !s.isEmpty())
.toList();
List<Query> result = lines.stream()
.map(l -> Query.builder()
.text(l)
.history(query.history())
.build())
.toList();
// 4. 可选：追加原始查询（防止变体漂移）
if(includeOriginal) {
result.add(query);
}
returnresult;
}
线上调优实战经验
- •电商客服场景：将temperature从默认0.7降至0.5，减少“天马行空”的变体，节省15% token消耗，同时变体相关性提升20%
- •技术文档场景：开启
includeOriginal=true，保留原始查询，避免因变体语义漂移导致的核心信息丢失 - •高并发场景：通过
executor参数注入自定义线程池，控制并行检索数量（建议≤CPU核心数×2）
想了解LLM提示模板的精细化设计与变体质量评估方法？阅读原文获取完整参数调优表与A/B测试结果→
2. CompressionQueryTransformer：多轮对话上下文“瘦身”技术
多轮对话中，历史消息随轮次线性膨胀（如15轮对话token数超4k），导致向量嵌入质量下降、LLM上下文窗口溢出。CompressionQueryTransformer通过LLM智能压缩，在保留核心实体与诉求的前提下，将历史长度减少60%+。
压缩效果对比表
核心技术逻辑与源码解析
- 1.动态触发机制：通过token估算（基于字符数×0.75）判断是否需要压缩（默认阈值：maxHistoryTokens=500）
- 2.历史摘要生成：调用LLM生成结构化摘要，保留实体、关系、关键诉求与上下文关联
- 3.轻量替换：用压缩摘要替换原始历史，减少后续组件的处理负担
@Override
publicQuerytransform(Query query){
// 估算token数，未超标直接返回
inttokenCount=estimateTokens(query.history());
if(tokenCount <= maxHistoryTokens) {
returnquery;
}
// 1. 构建历史字符串（带角色标识）
StringhistoryStr=query.history().stream()
.map(m -> m.getRole() +": "+ m.getContent())
.collect(Collectors.joining("\\n"));
// 2. 渲染压缩提示
Stringprompt=promptTemplate.render(Map.of(
"history", historyStr,
"query", query.text(),
"requirements","保留实体、问题诉求与上下文关联，长度≤"+ maxHistoryTokens
));
// 3. 调用LLM压缩历史（带失败回退）
String compressed;
try{
compressed = chatClientBuilder.build()
.prompt()
.user(prompt)
.call()
.content();
}catch(Exception e) {
// 压缩失败回退策略：保留最近3轮历史
if(enableFallback) {
returnfallbackToRecentHistory(query);
}
throwe;
}
// 4. 构建新Query（压缩历史+当前查询）
Messagesummary=newSystemMessage("历史摘要："+ compressed);
returnQuery.builder()
.text(query.text())
.history(List.of(summary)) // 替换原始历史
.build();
}
高阶优化策略
- •分层压缩：最近3轮保留原文，更早轮次仅保留相关信息，比全局压缩的指代消解准确率提升12%
- •缓存复用：用Caffeine缓存压缩结果（key=会话ID+历史哈希），30分钟内重复对话无需重新压缩，降低LLM调用成本
- •动态阈值：根据LLM模型窗口动态调整maxHistoryTokens（如GPT-3.5-turbo设300，GPT-4设800）
想获取压缩Prompt模板的精细化设计与失败回退策略？阅读原文查看实战代码示例与性能对比→
3. ConcatenationDocumentJoiner：多源文档去重与合并技术
多数据源检索（如PgVector语义检索+Elasticsearch关键词检索）常返回重复或低质文档（重复率超60%），导致LLM生成冗余或错误内容。该组件通过双重去重策略与置信度排序，输出“无冗余、高相关”的文档集。
去重策略技术对比表
| | | | | |
|---|
| | | | | |
| | similarityThreshold=0.85-0.95 | | | |
合并流程示意图
多源原始文档（PgVector返回6条+ES返回6条）质量过滤（剔除相似度＜0.6的文档）一级去重CONTENT_HASH去重→剩余9条二级去重SEMANTIC_SIMILARITY去重→剩余7条置信度排序按相似度得分降序排列长度截断保留top8高相关文档元数据增强（补充来源/时间戳/置信度）输出优化文档集（无冗余，有序，结构化）
核心合并逻辑源码
@Override
publicList<Document>join(List<List<Document>> documents){
// 1. 扁平化多源文档并过滤低质内容
List<Document> allDocuments = documents.stream()
.flatMap(Collection::stream)
.filter(this::isQualified) // 过滤低相似度文档
.collect(Collectors.toList());
// 2. 按策略去重
Map<String, Document> uniqueDocuments =newLinkedHashMap<>();
for(Document doc : allDocuments) {
Stringkey=generateDeduplicationKey(doc); // 根据策略生成key
uniqueDocuments.merge(key, doc,this::selectBetterDocument); // 保留高分文档
}
// 3. 按置信度排序并截断
returnuniqueDocuments.values().stream()
.sorted(Comparator.comparing(Document::getScore).reversed())
.limit(topK) // 控制返回数量
.collect(Collectors.toList());
}
// 生成去重key（策略分支）
privateStringgenerateDeduplicationKey(Document doc){
returnswitch(deduplicationStrategy) {
caseCONTENT_HASH -> sha256(doc.getContent()); // 内容哈希
caseSEMANTIC_SIMILARITY -> vectorHash(doc.getEmbedding()); // 向量哈希
caseNONE -> doc.getId(); // 不处理
};
}
场景化去重阈值配置
想了解不同业务场景的去重阈值设置与性能优化？阅读原文获取完整配置矩阵与压测数据→
四、多轮会话全链路技术流程图
多轮对话的核心挑战是“上下文膨胀”与“指代消解”（如用户说“它怎么配置”中的“它”）。Spring AI通过“压缩→改写→扩展→检索→合并”的流水线技术，实现长对话场景下的精准问答。
生成模型（GPT-3.5-turbo）ContextualQueryAugmenterConcatenationDocumentJoiner向量存储（PgVector+ES）MultiQueryExpanderRewriteQueryTransformerCompressionQueryTransformer用户（15轮历史+新查询："它怎么配置？"）生成模型（GPT-3.5-turbo）ContextualQueryAugmenterConcatenationDocumentJoiner向量存储（PgVector+ES）MultiQueryExpanderRewriteQueryTransformerCompressionQueryTransformer用户（15轮历史+新查询："它怎么配置？"）若检索无结果→触发Fallback策略原始查询+15轮历史（4231token）调用压缩提示生成历史摘要历史摘要（634token）："用户之前询问SpringAI存储组件的安装，现在问配置方法"压缩后历史+原始查询调用改写提示消除歧义改写后查询："SpringAI存储组件如何配置？"改写后查询生成3条扩展变体变体列表（含同义词/不同句式）3条变体并行检索（top4/变体）多路召回文档（共12条，含重复）去重排序后文档（8条高相关）拼装Prompt：context+改写后查询精准回答（基于压缩历史与相关文档）
关键技术协同点解析
- 1.组件调用顺序：必须遵循“压缩→改写→扩展”的顺序，避免先扩展再压缩导致的语义漂移
- 2.上下文对齐：压缩后的历史需与新查询强关联，为改写阶段的指代消解提供依据
- 3.并行优化：MultiQueryExpander的变体检索采用并行执行，总延迟≈单变体检索时间（而非累加）
- 4.异常处理：每个环节均设置超时与回退策略（如LLM超时用缓存结果，检索空用热门文档）
想获取多轮对话的组件调用代码与异常处理策略？阅读原文查看完整工程实现与测试用例→
五、企业级场景配置模板与技术选型
不同场景对RAG的技术需求差异显著，以下为经过线上验证的配置模板，可直接复用或作为基准优化。
1. 客服对话场景（低延迟优先）
| | | |
|---|
| | CQT+RQT+MQE(轻量)+CONTENT_HASH去重 | QPS=50时，RT=980ms，错误率=0.2% |
配置示例
spring:
ai:
# RAG（检索增强生成）核心配置
rag:
# 查询扩展配置（解决模糊查询召回率问题）
query-expansion:
# 生成的查询变体数量（3个变体可平衡召回率与性能）
number-of-queries:3
# 查询转换配置（处理多轮对话上下文）
query-transformation:
# 压缩后历史对话的最大token数（500适用于多数平衡场景）
max-history-tokens:500
# 文档合并配置（处理多源文档冗余问题）
document-joiner:
# 语义去重的相似度阈值（0.9表示仅剔除高度相似文档）
similarity-threshold:0.9
2. 企业知识库场景（高精准优先）
| | | |
|---|
| | MQE+CDJ(语义去重)+DocumentRanker | |
| 配置示例 | | | |
spring:
ai:
# RAG（检索增强生成）核心配置
rag:
# 查询扩展配置（提升召回率）
query-expansion:
number-of-queries:4 # 生成4条查询变体，覆盖更多语义表达
temperature:0.5 # 控制变体创造性，0.5平衡多样性与准确性
# 检索参数配置（控制文档召回质量）
retrieval:
top-k:8 # 每轮检索返回8条候选文档，保证覆盖度
similarity-threshold:0.85# 相似度阈值0.85，过滤低相关文档
# 文档合并配置（处理冗余与排序）
document-joiner:
deduplication-strategy:semantic_similarity# 采用语义相似度去重，处理近似内容
3. 站内搜索场景（平衡型）
spring:
ai:
# 检索增强生成(RAG)核心配置
rag:
# 查询扩展模块：解决单一查询表述局限
query-expansion:
number-of-queries:3# 生成3条语义等价变体，平衡召回广度与处理成本
# 查询转换模块：优化多轮对话上下文
query-transformation:
max-history-tokens:500# 历史对话压缩后最大token数，平衡上下文完整性与效率
# 文档合并模块：处理多源文档冗余
document-joiner:
similarity-threshold:0.9# 语义去重阈值，0.9表示仅合并高度相似文档，保留信息丰富度
想获取完整application.yml配置与Java代码实现？阅读原文获取可直接运行的工程模板与测试数据→
六、多模态扩展：让RAG支持图片、音频、视频
Spring AI的RAG架构支持无缝扩展至多模态场景，通过统一的Document接口兼容文本、图片、音频、视频等内容，实现“图文混合检索”“语音问答”等高级功能。
多模态检索技术架构图
多模态输入（文本+图片+音频）模态转换（图片→向量+字幕；音频→文本+声纹）统一向量化（CLIP/Whisper/TextEmbedding）向量存储（PgVector多模态向量库）多模态检索（文本向量+图像向量+音频向量）多模态文档合并（MultiModalDocumentJoiner）多模态Prompt拼装（图文/音文融合）LLM生成多模态回答
典型多模态场景技术方案
- •图片检索：用CLIP模型将图片与文本编码到同一向量空间，支持“以文搜图”“以图搜图”
- •音频问答：通过Whisper将语音转文本，同时提取声纹特征，支持“按说话人+内容”双重检索
- •视频检索：提取关键帧（1fps）+字幕OCR，融合图像与文本向量，按时间戳定位相关片段
想了解多模态检索的工程实现与参数配置？阅读原文查看完整技术方案与代码示例→
总结：从技术原理到工程落地的RAG优化路径
Spring AI RAG的核心优势在于“模块化拆解与组合优化”：通过MultiQueryExpander解决“召回不足”，RewriteQueryTransformer解决“歧义理解”，CompressionQueryTransformer解决“上下文膨胀”，ConcatenationDocumentJoiner解决“文档冗余”。这套技术体系将传统RAG的“单点赌博式检索”升级为“全链路可控的工程化系统”。
从技术原理到源码解析，从参数调优到场景落地，本文提供了系统化的优化思路。建议结合原文深入学习三大技术点：核心组件的源码细节与扩展方法、多轮对话的时序优化与异常处理、多模态场景的技术扩展方案，让你的RAG系统从“偶尔准确”变成“持续可靠”，从“能用”真正走向“好用”。
#SpringAI#RAG优化#检索增强生成#MultiQueryExpander#CompressionQueryTransformer#向量检索#多轮对话优化#企业级AI架构#检索精度提升
