前言

这两年，随着大模型的爆发，很多小伙伴都有这样的困惑：OpenAI GPT-4、Claude 3.5这些模型确实很强大，但一旦问到企业内部的具体问题，比如“我们公司去年Q3的营收是多少”，它就傻眼了。

要么回答“我不知道”，要么就开始一本正经地胡说八道——这就是所谓的“AI幻觉”。

大语言模型的知识源于其训练数据，模型在训练时尽力把海量信息压缩进有限参数中，但无法像数据库那样精确记录每一个事实，尤其是那些训练语料中极少提及的细节。

更致命的是，训练数据是有明确截止时间的，无法获取之后的新信息。

因此，大语言模型天然存在知识静态、容易产生幻觉、缺乏专业深度三大缺陷。

RAG（检索增强生成）就是专门解决这个问题的技术。

RAG通过检索外部知识库来增强模型能力，当用户查询最新信息时，RAG先检索外部数据库中的实时内容，再让LLM基于检索结果生成答案，从而将LLM从静态记忆者转变为动态整合者。

今天，我就从零开始，用Java开发者的视角，带大家系统了解RAG到底是什么、怎么工作、如何落地。

更多项目实战在Java突击队网：susan.net.cn

一、什么是RAG？

1.1 核心公式

RAG（Retrieval-Augmented Generation，检索增强生成）的核心思想其实很简单：在让LLM回答问题之前，先从你的私有知识库中找到相关的信息，然后把问题和信息一起交给LLM来回答。

RAG = 检索（Retrieval） + 增强（Augmented） + 生成（Generation）

从学术角度看，RAG通过将生成过程与可验证的最新证据紧密耦合，直接解决了大模型的幻觉问题。

RAG不仅能让LLM回答训练数据中不存在的新问题，还能为生成的答案提供来源引用，大幅提升了可信度和可审计性。

用大白话来说：LLM本身就是一本百科全书，但它不知道你的公司内部资料。RAG就是在每次提问时，先去翻你的资料库，把相关内容找出来，然后连同问题一起交给LLM，让它基于这些资料来回答。

1.2 为什么需要RAG？

有些小伙伴可能会问：为什么不能把企业知识库全部喂给LLM训练呢？

这里有三个现实问题：

1. 知识更新不及时：LLM的训练数据有明确的截止时间。重新训练模型以更新知识成本高昂（数百万至数亿美元），且可能引发灾难性遗忘问题。

2. 无法访问私有数据：你的公司内部文档、客户邮件、合同信息，这些数据不会出现在LLM的训练数据中。RAG通过构建定制化知识基座解决这一问题：将企业内部文档导入向量数据库，使通用LLM瞬间升级为领域专家。

3. 成本极高：重新训练或微调一个LLM需要数万甚至数百万美元，不是普通企业负担得起的。RAG无需重新训练，成本仅为微调的1/10到1/100。

RAG完美解决了这三个问题：它不改变LLM本身，只是让LLM“带着资料回答问题”。

企业级RAG正在快速普及。

据2026年4月百度开发者社区的分析，RAG通过整合外部知识库，弥补了大语言模型在实时性、准确性和专业性上的不足，广泛应用于企业场景。

RAG还通过引入事实边界约束，要求LLM的答案严格基于检索到的权威文档并附带来源链接，这在金融、医疗等合规敏感行业中至关重要。

二、RAG的核心架构

RAG的架构可以清晰地分为两大流程：离线索引和在线检索生成。

2.1 四大核心步骤

一篇2026年发表的全面综述论文将现代RAG架构解构为索引（Indexing）、检索（Retrieval）、融合（Fusion）和生成（Generation） 四个阶段，并梳理了从基础向量RAG到Graph RAG、Agentic RAG、多模态RAG等多种新兴范式。

离线索引阶段（只做一次，或者在文档更新时重新做）：

1. 文档切分（Chunking）：把一篇长文档切成若干个小块（Chunk）。为什么要切？因为LLM的上下文窗口有限，一次也塞不下太多内容。

2. 向量化（Embedding）：使用嵌入模型将文本块转换为向量（数字数组），实现语义相似性计算。

3. 存储：将向量和对应的原始文本一起存入向量数据库，供后续检索使用。

在线检索生成阶段（每次用户提问时执行）：

4. 检索增强生成：将用户问题转化为向量，在向量数据库中执行相似度检索，获取最相关的文档片段，然后与问题一起提交给LLM生成答案。

更多项目实战在Java突击队网：susan.net.cn

三、RAG的关键技术组件

3.1 向量数据库：RAG的“记忆库”

向量数据库是RAG的核心基础设施。它专门用于存储和检索高维向量数据，支持海量数据下的毫秒级相似度检索。

2026年，业内已经形成了清晰的向量数据库选型框架，通常依据检索质量、过滤能力、混合搜索支持、索引选项、运维就绪度、生态集成、安全性和成本模型等维度进行评估。

向量数据库	核心特点	部署方式	适用场景
TiDB Vector Search	SQL+向量一体化，混合搜索强	托管+自托管	RAG+SQL混合负载
Milvus	功能最丰富，开源首选	托管+自托管	大规模专用向量场景
pgvector	PostgreSQL扩展，SQL原生	自托管	已有PG的中小项目
Weaviate	生态友好，混合搜索成熟	托管+自托管	多模态+过滤重应用
Qdrant	Rust编写，高性能	托管+自托管	对性能和延迟敏感
Chroma	轻量级，开箱即用	自托管/本地	原型验证和小型项目
OpenSearch	BM25+向量双强	托管+自托管	关键词+语义混合检索

数据参考：对于典型的RAG工作负载（1536维嵌入，topK=10），经过良好调优的系统可实现90-95%的召回率，p95延迟低于100ms。

没有单一的“最佳”向量数据库，选择完全取决于你的具体工作负载、过滤需求和是否需要向量与事务SQL数据共存。

3.2 Embedding模型：把文字变成“坐标”

Embedding模型负责将文本转换成向量。选型时需要注意：

• 多语言支持：如果你的知识库包含中英文，需要选择支持多语言的模型
• 多模态支持：2026年的RAG已经从纯文本扩展到多模态，支持文本、图像、图表等多种数据类型
• 跨语言能力：中文查询需要能够找到英文文档，反之亦然

据Milvus 2026年3月发布的10款主流嵌入模型基准测试，Gemini Embedding 2是最佳的全能选手，开源模型Qwen3-VL-2B在跨模态任务上甚至超越了闭源API。

如果你需要压缩向量维度以节省存储空间，Voyage Multimodal 3.5或Jina Embeddings v4是更好的选择。

该基准测试发现，MTEB排行榜存在严重局限——它只测试单一语言的文本检索，不包括跨模态检索、跨语言搜索和长文档精确度。

生产型RAG需要的是CCKM（跨模态、跨语言、关键信息、MRL压缩）四维能力，而传统基准恰恰遗漏了这些。

3.3 重排序（Rerank）：提升精准度

向量检索返回的Top-K结果中，排在前面的不一定是最相关的。引入重排序模型可以对候选结果进行二次打分，显著提升检索精度。

3.4 混合检索：BM25 + 向量

结合关键词匹配（BM25）和向量相似度，可以提升召回率。混合检索可以将搜索准确率提升高达45%。

结合多种检索器（BM25捕捉词法匹配、密集检索捕捉语义相似性）能提供互补的信号，显著增强RAG系统的有效性。

四、RAG的评估体系

RAG系统的评估是一个多维度的挑战。

Ragas（Retrieval Augmented Generation Assessment） 是目前最流行的开源评估框架，它引入了一套无需依赖人工标注的自动化评估指标，能够分别衡量检索和生成两个组件的质量。

4.1 三大核心评估指标

Ragas框架通过量化指标评估RAG系统的三大核心能力：

评估维度	衡量内容	计算公式/方法
忠实度（Faithfulness）	生成的答案是否基于检索到的文档，有无幻觉	LLM逐句判断与检索内容的逻辑一致性
答案相关性（Answer Relevancy）	生成的答案是否直接回应用户问题	计算答案中问题相关句子的占比
上下文相关性（Context Relevancy）	检索到的文档是否与问题相关	筛选文档中与问题相关的句子比例

4.2 总体得分计算

在Ragas框架中，各个指标会被组合起来计算出一个RAGAS总体得分，从而全面量化RAG系统的性能。

计算过程包括：选择相关指标并计算它们，将它们标准化为0-1范围，然后计算这些指标的加权平均值。

权重的分配取决于每个用例的优先级。

高级评估扩展：Ragas已被扩展到基于知识图谱的评估范式，支持多跳推理和语义社区聚类，以得出更全面的评分指标。

4.3 指标驱动开发（MDD）

Ragas框架引入了指标驱动开发（Metric-Driven Development） 的理念，用于持续改进RAG应用。

这意味着评估不是一次性的活动，而应该是贯穿整个开发周期的持续流程：建立基线 → 识别短板 → 针对性优化 → 重新评估 → 迭代循环。

五、RAG优化技术

在RAG的实际落地过程中，检索质量是影响最终效果最关键的因素。

以下是最有效的优化技术，每项技术都配有完整的代码示例。

5.1 查询重写（Query Rewriting）

问题场景：用户问“苹果股价咋样了？”，知识库里却是《Apple Inc. (AAPL) 2024年Q2财报与股价分析》。用户的口语表达与知识库的书面术语之间存在鸿沟，导致检索不准确。

优化思路：在检索前，让大模型充当“翻译官”，将用户口语化、模糊的查询改写为更专业、更完整的查询语句。

Spring AI Alibaba实现示例：

import org.springframework.ai.rag.preretrieval.query.transformation.RewriteQueryTransformer;
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class QueryRewriteConfig {
    
    @Bean
    public QueryTransformer queryTransformer(ChatClient.Builder builder) {
        String promptTemplate = """
            你是一个专业的查询改写助手。请将用户的原始问题改写为更清晰、更完整的独立查询。
            
            改写原则：
            1. 将口语表达转为书面表达
            2. 补全缺失的上下文信息（如代词指代）
            3. 使用知识库中常用的专业术语
            4. 保持查询的原始意图不变
            
            原始问题：{original_query}
            改写后的查询：
            """;
        
        return RewriteQueryTransformer.builder()
            .chatClientBuilder(builder)
            .promptTemplate(promptTemplate)
            .targetSearchSystem("vector_store")
            .build();
    }
}

使用示例：

• 原始查询：“苹果股价咋样了？” → 改写后：“查询Apple Inc.公司的最新股票价格”
• 原始查询：“它怎么样？”（多轮对话中）→ 改写后：“查询上一轮提到的产品的详细功能”

效果：在电商客服场景中，实施查询重写后，多轮对话准确率提升超过30%，召回率从72%提升至89%。

5.2 混合检索（Hybrid Search）

问题场景：用户查询“ModelArts平台”，向量检索可能召回“机器学习”、“AI开发”等语义相近但不够精准的内容，而忽略了包含“ModelArts”关键词的文档。单一检索方式各有短板。

优化思路：同时使用BM25关键词检索（精确匹配）和向量语义检索（语义相似），将两种结果融合后返回，取长补短。

Spring AI Alibaba实现示例：

import org.springframework.ai.rag.retrieval.search.HybridDocumentRetriever;
import org.springframework.ai.rag.retrieval.join.JoinDocumentJoiner;
import org.springframework.ai.rag.retrieval.search.VectorStoreDocumentRetriever;
import org.springframework.ai.rag.retrieval.search.KeywordDocumentRetriever;

@Configuration
public class HybridSearchConfig {
    
    @Bean
    public DocumentRetriever hybridRetriever(VectorStore vectorStore) {
        // 向量检索器
        VectorStoreDocumentRetriever vectorRetriever = VectorStoreDocumentRetriever.builder()
            .vectorStore(vectorStore)
            .similarityThreshold(0.7)
            .topK(10)
            .build();
        
        // 关键词检索器（需要先对文档建立BM25索引）
        KeywordDocumentRetriever keywordRetriever = KeywordDocumentRetriever.builder()
            .indexName("knowledge_base")
            .topK(10)
            .build();
        
        // 混合检索：使用 Reciprocal Rank Fusion 融合结果
        return HybridDocumentRetriever.builder()
            .retrievers(List.of(vectorRetriever, keywordRetriever))
            .joiner(JoinDocumentJoiner.reciprocalRankFusion())
            .build();
    }
}

效果：混合检索可以将搜索准确率提升高达45%。在华为云社区实测中，结合查询重写+混合检索后，RAG系统的整体准确率从68%提升到91%。

5.3 结果重排序（Reranking）

问题场景：向量检索返回的10个结果中，第1个和第5个哪个更相关？相似度分数不一定准确。直接取Top-K可能漏掉真正相关的文档，或者把不相关的排在了前面。

优化思路：引入专门的重排序模型（如Cohere Rerank、BGE Reranker），对初步检索到的候选结果进行二次打分，按新分数重新排序。

Spring AI Alibaba实现示例：

import org.springframework.ai.rag.postretrieval.reranking.DiversityReranker;
import org.springframework.ai.rag.postretrieval.reranking.CompressionReranker;
import org.springframework.ai.rag.retrieval.search.DocumentRetriever;
import org.springframework.ai.rag.retrieval.search.VectorStoreDocumentRetriever;

@Configuration
public class RerankingConfig {
    
    @Bean
    public DocumentRetriever rerankedRetriever(VectorStore vectorStore, 
                                               ChatClient chatClient) {
        // 基础向量检索器，召回20个候选
        VectorStoreDocumentRetriever baseRetriever = VectorStoreDocumentRetriever.builder()
            .vectorStore(vectorStore)
            .topK(20)  // 多召回一些候选
            .build();
        
        // 重排序器1：多样性重排（避免返回的内容过于相似）
        DiversityReranker diversityReranker = DiversityReranker.builder()
            .minDegree(0.5)  // 最小多样性阈值
            .build();
        
        // 重排序器2：压缩重排（用LLM提取最相关片段，可减少上下文长度）
        CompressionReranker compressionReranker = CompressionReranker.builder()
            .chatClient(chatClient)
            .maxOutputTokens(500)
            .build();
        
        // 组合使用：先多样性重排，再压缩重排
        return baseRetriever.andThen(diversityReranker).andThen(compressionReranker);
    }
}

效果：在金融研报问答场景中，添加重排序后，答案的准确率从82%提升到94%，同时上下文长度压缩了60%，节省了Token成本。

5.4 多向量检索

问题场景：用户查询“华为云ModelArts平台与阿里云PAI平台的区别”，这是一个多跳推理问题，需要同时检索两个产品的信息并进行对比。单一的向量检索无法同时表达两个独立的语义实体。

优化思路：将查询分解为多个子查询，分别检索后再融合结果。或者使用多路检索器，分别从不同维度（文本语义、关键词、元数据）并行检索，然后合并。

Spring AI Alibaba实现示例：

import org.springframework.ai.rag.preretrieval.query.expansion.MultiQueryExpander;

@Configuration
public class MultiVectorConfig {
    
    @Bean
    public QueryExpander multiQueryExpander(ChatClient.Builder builder) {
        String expansionPrompt = """
            请将以下用户问题扩展为2-4个不同的子查询，每个子查询从不同角度表述，以覆盖更全面的信息。
            子查询之间用换行分隔。
            
            用户问题：{original_query}
            
            扩展的子查询：
            """;
        
        return MultiQueryExpander.builder()
            .chatClientBuilder(builder)
            .promptTemplate(expansionPrompt)
            .numberOfQueries(3)  // 生成3个子查询
            .build();
    }
}

结合使用示例：

@Service
public class AdvancedRagService {
    
    @Autowired
    private QueryExpander queryExpander;      // 查询扩展
    @Autowired
    private DocumentRetriever hybridRetriever; // 混合检索器
    @Autowired
    private Reranker reranker;                 // 重排序器
    
    public String ask(String question) {
        // 1. 查询重写
        String rewritten = rewriteQuery(question);
        
        // 2. 多向量扩展（生成多个子查询）
        List<String> subQueries = queryExpander.expand(rewritten);
        
        // 3. 对每个子查询进行混合检索
        List<Document> allDocs = new ArrayList<>();
        for (String sq : subQueries) {
            allDocs.addAll(hybridRetriever.retrieve(sq));
        }
        
        // 4. 去重 + 重排序
        List<Document> uniqueDocs = deduplicate(allDocs);
        List<Document> reranked = reranker.rerank(uniqueDocs, question);
        
        // 5. 组装Prompt并生成答案
        return generateAnswer(question, reranked);
    }
}

效果：在多跳问答和产品对比类场景中，多向量检索可将召回率提升20-30%，尤其擅长处理“A与B的区别”、“为什么A比B好”这类复杂问题。

六、RAG实战

对于Java开发者，目前最成熟的选择是Spring AI Alibaba框架，它提供了模块化的RAG架构。

6.1 Spring AI Alibaba的RAG优势

Spring AI Alibaba作为阿里巴巴开源的AI开发框架，具有三大核心优势：

1. 与阿里云生态深度集成：支持无缝调用通义千问等大模型，降低技术门槛
2. 模块化设计：提供预处理、检索、生成、后处理等标准化组件，加速开发
3. 企业级支持：内置高并发处理、模型热更新、监控告警等功能，适合生产环境

其核心思路是实现“检索-过滤-生成”的三段式流程：首先从知识库中检索相关文档片段，再通过语义过滤排除无关内容，最后由生成模型合成自然语言回答。

6.2 核心组件详解

Spring AI Alibaba的模块化RAG架构包含以下核心组件：

组件	功能	可选实现
DocumentReader	加载各类文档格式	PDFMiner、Apache Tika、JSON、Markdown
DocumentTransformer	文档预处理和清洗	去除特殊字符、元数据提取
DocumentSplitter	智能分块策略	递归分块、语义边界分块、重叠分块
EmbeddingModel	文本向量化	DashScope、OpenAI、Ollama
VectorStore	向量存储与检索	Milvus、pgvector、Redis、Chroma
ChatClient	LLM调用与Prompt管理	通义千问、OpenAI、Azure

6.3 完整代码实现

第一步：添加依赖

<dependency>
    <groupId>com.alibaba.cloud.ai</groupId>
    <artifactId>spring-ai-alibaba-starter</artifactId>
    <version>1.0.0</version>
</dependency>
<dependency>
    <groupId>com.alibaba.cloud.ai</groupId>
    <artifactId>spring-ai-alibaba-starter-dashscope</artifactId>
    <version>1.0.0</version>
</dependency>

第二步：配置向量数据库和Embedding模型

@Configuration
public class RagConfig {
    
    @Bean
    public ChatClient chatClient(ChatClient.Builder builder) {
        return builder
            .defaultSystem("你是一个专业的智能问答助手，请基于提供的参考资料回答问题。")
            .build();
    }
    
    @Bean
    public VectorStore vectorStore(EmbeddingModel embeddingModel) {
        // 示例：使用内存存储（适合原型验证）
        SimpleVectorStore simpleVectorStore = SimpleVectorStore.builder(embeddingModel).build();
        return simpleVectorStore;
        // 生产环境可替换为 MilvusVectorStore、PgVectorStore 等
    }
    
    @Bean
    public EmbeddingModel embeddingModel() {
        return new DashScopeEmbeddingModel(
            DashScopeEmbeddingOptions.builder()
                .withModel("text-embedding-v3")
                .build()
        );
    }
}

第三步：构建知识库索引

@Service
public class KnowledgeBaseService {
    
    @Autowired
    private VectorStore vectorStore;
    
    @Autowired
    private EmbeddingModel embeddingModel;
    
    public void indexDocument(String content) {
        // 1. 文档切分
        List<Document> chunks = DocumentSplitter.recursive(500, 100).split(content);
        
        // 2. 向量化并存储
        vectorStore.add(chunks);
        
        System.out.println("已索引 " + chunks.size() + " 个文档块");
    }
}

第四步：实现RAG问答接口

@RestController
@RequestMapping("/api/rag")
public class RagController {
    
    @Autowired
    private ChatClient chatClient;
    
    @Autowired
    private VectorStore vectorStore;
    
    @PostMapping("/ask")
    public String ask(@RequestParam String question) {
        // 使用 QuestionAnswerAdvisor 自动完成检索增强
        return chatClient.prompt()
                .user(question)
                .advisors(new QuestionAnswerAdvisor(vectorStore))
                .call()
                .content();
    }
}

只需这几步，一个完整的RAG智能问答系统就搭建完成了！QuestionAnswerAdvisor会自动完成问题向量化、相似度检索和Prompt组装的全部工作。

七、RAG的优缺点

7.1 优点

1. 准确率高：通过检索外部知识，大幅降低模型幻觉，提升事实准确性。RAG通过引入事实边界约束，要求LLM的答案严格基于检索到的权威文档，这在金融、医疗等合规敏感行业中至关重要。

2. 知识实时更新：只需更新向量数据库即可，无需重新训练模型。通过外接动态知识库（如公司文档系统或新闻API），当用户查询最新信息时，RAG先检索外部数据库中的实时内容，再让LLM基于检索结果生成答案。

3. 可解释性强：可以展示检索到的来源文档，让用户知道答案来源，具备可审计性。

4. 成本可控：比微调大模型便宜得多，无需数百万美元的训练成本。

5. 保护数据隐私：私有数据只存储在本地向量库中，不会上传到模型服务端。

6. 领域适配灵活：将企业内部文档导入向量数据库，使通用LLM瞬间升级为领域专家。

7.2 缺点

1. 检索质量决定一切：如果检索不到相关内容，LLM也无能为力。

2. 上下文窗口限制：无法一次性塞入海量资料，需要合理切分。

3. 增加系统复杂度：需要维护向量数据库、Embedding模型、LLM等多个组件。

4. 延迟略高：相比直接调用LLM，RAG多了检索步骤，会增加几十到几百毫秒的延迟。

5. 评估困难：RAG系统需要从检索准确性和生成质量多个维度进行综合评估。

6. 知识冲突处理：检索到的信息可能与LLM的参数化记忆发生冲突，需要设计有效的融合策略。

八、RAG的使用场景

8.1 最适合RAG的场景

• 企业内部知识库问答：把公司的文档、规范、培训材料建成RAG，员工可以随时提问
• 智能客服系统：将产品文档、FAQ接入RAG，让AI客服能够准确回答产品问题
• 法律/合同审查：让AI基于合同文本回答问题，帮助律师快速定位条款
• 金融研报分析：分析师可以直接提问“这份研报中对XX公司的评级是什么”，AI基于报告内容回答
• 合规敏感行业：RAG通过强制LLM基于权威文档回答并附来源，在金融、医疗等合规敏感行业中至关重要

8.2 不适合RAG的场景

• 简单的闲聊：不需要外部知识的对话，直接用LLM就够了
• 需要深度推理的任务：RAG擅长“查资料”，不擅长“推导结论”
• 对延迟极度敏感的场景：检索会增加额外耗时

总结

RAG（检索增强生成）是目前企业落地AI应用最务实的技术方案。

它的核心价值可以概括为：让LLM带着资料回答问题，把AI幻觉降到最低。

核心要点	说明
核心公式	RAG = 检索（Retrieval） + 增强（Augmented） + 生成（Generation）
四大流程	索引 → 检索 → 融合 → 生成
关键技术	向量数据库 + Embedding模型 + 重排序 + LLM
评估指标	忠实度 + 答案相关性 + 上下文相关性
优化方向	查询重写 + 混合检索 + 重排序 + 多向量检索
最佳实践	从简单起步，建立持续评估体系，逐步迭代优化

在Java生态中，Spring AI Alibaba提供了开箱即用的模块化RAG支持。通过遵循最佳实践，可以构建一个高效、可靠的RAG系统，为用户提供准确和专业的回答。

如果你正面临“AI答非所问”的困扰，不妨从RAG开始——这是目前成本最低、见效最快的解决方案。

未来已来，用好RAG，让AI真正成为你的得力助手。