在 AI 问答系统中，你是否遇到过这些尴尬场景？
用户问 “那个功能咋用”，系统因 query 模糊召回率不足 40%；多轮对话到第 15 轮，上下文 token 直接超限；不同数据源返回的文档重复率超 60%，生成答案满是冗余信息；检索不到结果时，系统要么报错要么 “一本正经地胡说八道”……

传统 “单点 RAG”（仅靠一次向量召回）在这些场景中早已力不从心。而Spring AI 框架通过模块化设计给出了破局之道 —— 用 “组合策略” 替代 “单点依赖”，让检索精度与召回率实现质的飞跃。

Spring AI框架通过模块化设计与组合策略，构建了“检索前优化→多源检索→检索后处理”的全链路技术方案，从根本上解决上述痛点。本文将深入拆解核心组件的技术原理，通过架构图、时序图与对比表可视化技术流程，同步附源码解析与参数调优模板。建议结合原文技术细节深入学习，掌握从“检索失效”到“精准召回”的工程化落地方法。

一、为什么 “组合策略” 是 RAG 的破局关键？

传统 RAG 的痛点本质是 “单点脆弱性”：一次向量检索、一个静态 query、一套固定流程，缺乏容错与优化机制根本无法应对复杂场景的变化。而 Spring AI 的 “组合策略” 通过“三阶段九组件”的模块化拆分，让每个环节专注解决一类问题，将复杂问题拆解为可独立优化的技术单元，实现检索精度与系统稳定性的双重提升最终实现 “1+1＞2” 的效果。

核心痛点与技术解法对照表

核心技术组件：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. "Spring AI如何配置向量存储"2. "Spring AI存储组件设置步骤"3. "如何在Spring AI中启用存储功能"多变体并行检索（top4/变体）合并召回结果（覆盖更多相关文档）

核心源码关键逻辑解析

@Override
public List<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);
    }
    return result;
}

线上调优实战经验

• • 电商客服场景：将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. 1. 动态触发机制：通过token估算（基于字符数×0.75）判断是否需要压缩（默认阈值：maxHistoryTokens=500）
2. 2. 历史摘要生成：调用LLM生成结构化摘要，保留实体、关系、关键诉求与上下文关联
3. 3. 轻量替换：用压缩摘要替换原始历史，减少后续组件的处理负担

@Override
public Query transform(Query query) {
    // 估算token数，未超标直接返回
    inttokenCount= estimateTokens(query.history());
    if (tokenCount <= maxHistoryTokens) {
        return query;
    }

    // 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) {
            return fallbackToRecentHistory(query);
        }
        throw e;
    }

    // 4. 构建新Query（压缩历史+当前查询）
    Messagesummary=newSystemMessage("历史摘要：" + compressed);
    return Query.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生成冗余或错误内容。该组件通过双重去重策略与置信度排序，输出“无冗余、高相关”的文档集。

去重策略技术对比表

合并流程示意图

多源原始文档（PgVector返回6条+ES返回6条）质量过滤（剔除相似度＜0.6的文档）一级去重CONTENT_HASH去重→剩余9条二级去重SEMANTIC_SIMILARITY去重→剩余7条置信度排序按相似度得分降序排列长度截断保留top8高相关文档元数据增强（补充来源/时间戳/置信度）输出优化文档集（无冗余，有序，结构化）

核心合并逻辑源码

@Override
public List<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. 按置信度排序并截断
    return uniqueDocuments.values().stream()
        .sorted(Comparator.comparing(Document::getScore).reversed())
        .limit(topK)  // 控制返回数量
        .collect(Collectors.toList());
}

// 生成去重key（策略分支）
private String generateDeduplicationKey(Document doc) {
    returnswitch (deduplicationStrategy) {
        case CONTENT_HASH -> sha256(doc.getContent());  // 内容哈希
        case SEMANTIC_SIMILARITY -> vectorHash(doc.getEmbedding());  // 向量哈希
        case NONE -> doc.getId();  // 不处理
    };
}

场景化去重阈值配置

想了解不同业务场景的去重阈值设置与性能优化？阅读原文获取完整配置矩阵与压测数据→

四、多轮会话全链路技术流程图

多轮对话的核心挑战是“上下文膨胀”与“指代消解”（如用户说“它怎么配置”中的“它”）。Spring AI通过“压缩→改写→扩展→检索→合并”的流水线技术，实现长对话场景下的精准问答。

生成模型（GPT-3.5-turbo）ContextualQueryAugmenterConcatenationDocumentJoiner向量存储（PgVector+ES）MultiQueryExpanderRewriteQueryTransformerCompressionQueryTransformer用户（15轮历史+新查询："它怎么配置？"）生成模型（GPT-3.5-turbo）ContextualQueryAugmenterConcatenationDocumentJoiner向量存储（PgVector+ES）MultiQueryExpanderRewriteQueryTransformerCompressionQueryTransformer用户（15轮历史+新查询："它怎么配置？"）若检索无结果→触发Fallback策略原始查询+15轮历史（4231 token）调用压缩提示生成历史摘要历史摘要（634 token）："用户之前询问Spring AI存储组件的安装，现在问配置方法"压缩后历史+原始查询调用改写提示消除歧义改写后查询："Spring AI存储组件如何配置？"改写后查询生成3条扩展变体变体列表（含同义词/不同句式）3条变体并行检索（top4/变体）多路召回文档（共12条，含重复）去重排序后文档（8条高相关）拼装Prompt：context+改写后查询精准回答（基于压缩历史与相关文档）

关键技术协同点解析

1. 1. 组件调用顺序：必须遵循“压缩→改写→扩展”的顺序，避免先扩展再压缩导致的语义漂移
2. 2. 上下文对齐：压缩后的历史需与新查询强关联，为改写阶段的指代消解提供依据
3. 3. 并行优化：MultiQueryExpander的变体检索采用并行执行，总延迟≈单变体检索时间（而非累加）
4. 4. 异常处理：每个环节均设置超时与回退策略（如LLM超时用缓存结果，检索空用热门文档）

想获取多轮对话的组件调用代码与异常处理策略？阅读原文查看完整工程实现与测试用例→

五、企业级场景配置模板与技术选型

不同场景对RAG的技术需求差异显著，以下为经过线上验证的配置模板，可直接复用或作为基准优化。

1. 客服对话场景（低延迟优先）

配置示例

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. 企业知识库场景（高精准优先）

 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架构 #检索精度提升