前言

這兩年，隨著大模型的爆發(fā)，很多小伙伴都有這樣的困惑：OpenAI GPT-4、Claude 3.5這些模型確實(shí)很強(qiáng)大，但一旦問(wèn)到企業(yè)內(nèi)部的具體問(wèn)題，比如“我們公司去年Q3的營(yíng)收是多少”，它就傻眼了。

要么回答“我不知道”，要么就開(kāi)始一本正經(jīng)地胡說(shuō)八道——這就是所謂的“AI幻覺(jué)”。

大語(yǔ)言模型的知識(shí)源于其訓(xùn)練數(shù)據(jù)，模型在訓(xùn)練時(shí)盡力把海量信息壓縮進(jìn)有限參數(shù)中，但無(wú)法像數(shù)據(jù)庫(kù)那樣精確記錄每一個(gè)事實(shí)，尤其是那些訓(xùn)練語(yǔ)料中極少提及的細(xì)節(jié)。

更致命的是，訓(xùn)練數(shù)據(jù)是有明確截止時(shí)間的，無(wú)法獲取之后的新信息。

因此，大語(yǔ)言模型天然存在知識(shí)靜態(tài)、容易產(chǎn)生幻覺(jué)、缺乏專(zhuān)業(yè)深度三大缺陷。

RAG（檢索增強(qiáng)生成）就是專(zhuān)門(mén)解決這個(gè)問(wèn)題的技術(shù)。

RAG通過(guò)檢索外部知識(shí)庫(kù)來(lái)增強(qiáng)模型能力，當(dāng)用戶(hù)查詢(xún)最新信息時(shí)，RAG先檢索外部數(shù)據(jù)庫(kù)中的實(shí)時(shí)內(nèi)容，再讓LLM基于檢索結(jié)果生成答案，從而將LLM從靜態(tài)記憶者轉(zhuǎn)變?yōu)閯?dòng)態(tài)整合者。

今天，我就從零開(kāi)始，用Java開(kāi)發(fā)者的視角，帶大家系統(tǒng)了解RAG到底是什么、怎么工作、如何落地。

更多項(xiàng)目實(shí)戰(zhàn)在Java突擊隊(duì)網(wǎng)：susan.net.cn

一、什么是RAG？

1.1 核心公式

RAG（Retrieval-Augmented Generation，檢索增強(qiáng)生成）的核心思想其實(shí)很簡(jiǎn)單：在讓LLM回答問(wèn)題之前，先從你的私有知識(shí)庫(kù)中找到相關(guān)的信息，然后把問(wèn)題和信息一起交給LLM來(lái)回答。

RAG = 檢索（Retrieval） + 增強(qiáng)（Augmented） + 生成（Generation）

從學(xué)術(shù)角度看，RAG通過(guò)將生成過(guò)程與可驗(yàn)證的最新證據(jù)緊密耦合，直接解決了大模型的幻覺(jué)問(wèn)題。

RAG不僅能讓LLM回答訓(xùn)練數(shù)據(jù)中不存在的新問(wèn)題，還能為生成的答案提供來(lái)源引用，大幅提升了可信度和可審計(jì)性。

用大白話來(lái)說(shuō)：LLM本身就是一本百科全書(shū)，但它不知道你的公司內(nèi)部資料。RAG就是在每次提問(wèn)時(shí)，先去翻你的資料庫(kù)，把相關(guān)內(nèi)容找出來(lái)，然后連同問(wèn)題一起交給LLM，讓它基于這些資料來(lái)回答。

1.2 為什么需要RAG？

有些小伙伴可能會(huì)問(wèn)：為什么不能把企業(yè)知識(shí)庫(kù)全部喂給LLM訓(xùn)練呢？

這里有三個(gè)現(xiàn)實(shí)問(wèn)題：

• 知識(shí)更新不及時(shí)：LLM的訓(xùn)練數(shù)據(jù)有明確的截止時(shí)間。重新訓(xùn)練模型以更新知識(shí)成本高昂（數(shù)百萬(wàn)至數(shù)億美元），且可能引發(fā)災(zāi)難性遺忘問(wèn)題。
• 無(wú)法訪問(wèn)私有數(shù)據(jù)：你的公司內(nèi)部文檔、客戶(hù)郵件、合同信息，這些數(shù)據(jù)不會(huì)出現(xiàn)在LLM的訓(xùn)練數(shù)據(jù)中。RAG通過(guò)構(gòu)建定制化知識(shí)基座解決這一問(wèn)題：將企業(yè)內(nèi)部文檔導(dǎo)入向量數(shù)據(jù)庫(kù)，使通用LLM瞬間升級(jí)為領(lǐng)域?qū)＜摇?/li>
• 成本極高：重新訓(xùn)練或微調(diào)一個(gè)LLM需要數(shù)萬(wàn)甚至數(shù)百萬(wàn)美元，不是普通企業(yè)負(fù)擔(dān)得起的。RAG無(wú)需重新訓(xùn)練，成本僅為微調(diào)的1/10到1/100。

RAG完美解決了這三個(gè)問(wèn)題：它不改變LLM本身，只是讓LLM“帶著資料回答問(wèn)題”。

企業(yè)級(jí)RAG正在快速普及。

據(jù)2026年4月百度開(kāi)發(fā)者社區(qū)的分析，RAG通過(guò)整合外部知識(shí)庫(kù)，彌補(bǔ)了大語(yǔ)言模型在實(shí)時(shí)性、準(zhǔn)確性和專(zhuān)業(yè)性上的不足，廣泛應(yīng)用于企業(yè)場(chǎng)景。

RAG還通過(guò)引入事實(shí)邊界約束，要求LLM的答案嚴(yán)格基于檢索到的權(quán)威文檔并附帶來(lái)源鏈接，這在金融、醫(yī)療等合規(guī)敏感行業(yè)中至關(guān)重要。

二、RAG的核心架構(gòu)

RAG的架構(gòu)可以清晰地分為兩大流程：離線索引和在線檢索生成。

2.1 四大核心步驟

一篇2026年發(fā)表的全面綜述論文將現(xiàn)代RAG架構(gòu)解構(gòu)為索引（Indexing）、檢索（Retrieval）、融合（Fusion）和生成（Generation） 四個(gè)階段，并梳理了從基礎(chǔ)向量RAG到Graph RAG、Agentic RAG、多模態(tài)RAG等多種新興范式。

離線索引階段（只做一次，或者在文檔更新時(shí)重新做）：

• 文檔切分（Chunking）：把一篇長(zhǎng)文檔切成若干個(gè)小塊（Chunk）。為什么要切？因?yàn)長(zhǎng)LM的上下文窗口有限，一次也塞不下太多內(nèi)容。
• 向量化（Embedding）：使用嵌入模型將文本塊轉(zhuǎn)換為向量（數(shù)字?jǐn)?shù)組），實(shí)現(xiàn)語(yǔ)義相似性計(jì)算。
• 存儲(chǔ)：將向量和對(duì)應(yīng)的原始文本一起存入向量數(shù)據(jù)庫(kù)，供后續(xù)檢索使用。

在線檢索生成階段（每次用戶(hù)提問(wèn)時(shí)執(zhí)行）：

4. 檢索增強(qiáng)生成：將用戶(hù)問(wèn)題轉(zhuǎn)化為向量，在向量數(shù)據(jù)庫(kù)中執(zhí)行相似度檢索，獲取最相關(guān)的文檔片段，然后與問(wèn)題一起提交給LLM生成答案。

三、RAG的關(guān)鍵技術(shù)組件

3.1 向量數(shù)據(jù)庫(kù)：RAG的“記憶庫(kù)”

向量數(shù)據(jù)庫(kù)是RAG的核心基礎(chǔ)設(shè)施。它專(zhuān)門(mén)用于存儲(chǔ)和檢索高維向量數(shù)據(jù)，支持海量數(shù)據(jù)下的毫秒級(jí)相似度檢索。

2026年，業(yè)內(nèi)已經(jīng)形成了清晰的向量數(shù)據(jù)庫(kù)選型框架，通常依據(jù)檢索質(zhì)量、過(guò)濾能力、混合搜索支持、索引選項(xiàng)、運(yùn)維就緒度、生態(tài)集成、安全性和成本模型等維度進(jìn)行評(píng)估。

數(shù)據(jù)參考：對(duì)于典型的RAG工作負(fù)載（1536維嵌入，topK=10），經(jīng)過(guò)良好調(diào)優(yōu)的系統(tǒng)可實(shí)現(xiàn)90-95%的召回率，p95延遲低于100ms。

沒(méi)有單一的“最佳”向量數(shù)據(jù)庫(kù)，選擇完全取決于你的具體工作負(fù)載、過(guò)濾需求和是否需要向量與事務(wù)SQL數(shù)據(jù)共存。

3.2 Embedding模型：把文字變成“坐標(biāo)”

Embedding模型負(fù)責(zé)將文本轉(zhuǎn)換成向量。選型時(shí)需要注意：

• 多語(yǔ)言支持：如果你的知識(shí)庫(kù)包含中英文，需要選擇支持多語(yǔ)言的模型
• 多模態(tài)支持：2026年的RAG已經(jīng)從純文本擴(kuò)展到多模態(tài)，支持文本、圖像、圖表等多種數(shù)據(jù)類(lèi)型
• 跨語(yǔ)言能力：中文查詢(xún)需要能夠找到英文文檔，反之亦然

據(jù)Milvus 2026年3月發(fā)布的10款主流嵌入模型基準(zhǔn)測(cè)試，Gemini Embedding 2是最佳的全能選手，開(kāi)源模型Qwen3-VL-2B在跨模態(tài)任務(wù)上甚至超越了閉源API。

如果你需要壓縮向量維度以節(jié)省存儲(chǔ)空間，Voyage Multimodal 3.5或Jina Embeddings v4是更好的選擇。

該基準(zhǔn)測(cè)試發(fā)現(xiàn)，MTEB排行榜存在嚴(yán)重局限——它只測(cè)試單一語(yǔ)言的文本檢索，不包括跨模態(tài)檢索、跨語(yǔ)言搜索和長(zhǎng)文檔精確度。

生產(chǎn)型RAG需要的是CCKM（跨模態(tài)、跨語(yǔ)言、關(guān)鍵信息、MRL壓縮）四維能力，而傳統(tǒng)基準(zhǔn)恰恰遺漏了這些。

3.3 重排序（Rerank）：提升精準(zhǔn)度

向量檢索返回的Top-K結(jié)果中，排在前面的不一定是最相關(guān)的。引入重排序模型可以對(duì)候選結(jié)果進(jìn)行二次打分，顯著提升檢索精度。

3.4 混合檢索：BM25 + 向量

結(jié)合關(guān)鍵詞匹配（BM25）和向量相似度，可以提升召回率?；旌蠙z索可以將搜索準(zhǔn)確率提升高達(dá)45%。

結(jié)合多種檢索器（BM25捕捉詞法匹配、密集檢索捕捉語(yǔ)義相似性）能提供互補(bǔ)的信號(hào)，顯著增強(qiáng)RAG系統(tǒng)的有效性。

四、RAG的評(píng)估體系

RAG系統(tǒng)的評(píng)估是一個(gè)多維度的挑戰(zhàn)。

Ragas（Retrieval Augmented Generation Assessment） 是目前最流行的開(kāi)源評(píng)估框架，它引入了一套無(wú)需依賴(lài)人工標(biāo)注的自動(dòng)化評(píng)估指標(biāo)，能夠分別衡量檢索和生成兩個(gè)組件的質(zhì)量。

4.1 三大核心評(píng)估指標(biāo)

Ragas框架通過(guò)量化指標(biāo)評(píng)估RAG系統(tǒng)的三大核心能力：

4.2 總體得分計(jì)算

在Ragas框架中，各個(gè)指標(biāo)會(huì)被組合起來(lái)計(jì)算出一個(gè)RAGAS總體得分，從而全面量化RAG系統(tǒng)的性能。

計(jì)算過(guò)程包括：選擇相關(guān)指標(biāo)并計(jì)算它們，將它們標(biāo)準(zhǔn)化為0-1范圍，然后計(jì)算這些指標(biāo)的加權(quán)平均值。

權(quán)重的分配取決于每個(gè)用例的優(yōu)先級(jí)。

高級(jí)評(píng)估擴(kuò)展：Ragas已被擴(kuò)展到基于知識(shí)圖譜的評(píng)估范式，支持多跳推理和語(yǔ)義社區(qū)聚類(lèi)，以得出更全面的評(píng)分指標(biāo)。

4.3 指標(biāo)驅(qū)動(dòng)開(kāi)發(fā)（MDD）

Ragas框架引入了指標(biāo)驅(qū)動(dòng)開(kāi)發(fā)（Metric-Driven Development） 的理念，用于持續(xù)改進(jìn)RAG應(yīng)用。

這意味著評(píng)估不是一次性的活動(dòng)，而應(yīng)該是貫穿整個(gè)開(kāi)發(fā)周期的持續(xù)流程：建立基線 → 識(shí)別短板 → 針對(duì)性?xún)?yōu)化 → 重新評(píng)估 → 迭代循環(huán)。

五、RAG優(yōu)化技術(shù)

在RAG的實(shí)際落地過(guò)程中，檢索質(zhì)量是影響最終效果最關(guān)鍵的因素。

以下是最有效的優(yōu)化技術(shù)，每項(xiàng)技術(shù)都配有完整的代碼示例。

5.1 查詢(xún)重寫(xiě)（Query Rewriting）

問(wèn)題場(chǎng)景：用戶(hù)問(wèn)“蘋(píng)果股價(jià)咋樣了？”，知識(shí)庫(kù)里卻是《Apple Inc. (AAPL) 2024年Q2財(cái)報(bào)與股價(jià)分析》。用戶(hù)的口語(yǔ)表達(dá)與知識(shí)庫(kù)的書(shū)面術(shù)語(yǔ)之間存在鴻溝，導(dǎo)致檢索不準(zhǔn)確。

優(yōu)化思路：在檢索前，讓大模型充當(dāng)“翻譯官”，將用戶(hù)口語(yǔ)化、模糊的查詢(xún)改寫(xiě)為更專(zhuān)業(yè)、更完整的查詢(xún)語(yǔ)句。

Spring AI Alibaba實(shí)現(xiàn)示例：

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 = """
            你是一個(gè)專(zhuān)業(yè)的查詢(xún)改寫(xiě)助手。請(qǐng)將用戶(hù)的原始問(wèn)題改寫(xiě)為更清晰、更完整的獨(dú)立查詢(xún)。
            改寫(xiě)原則：
            1. 將口語(yǔ)表達(dá)轉(zhuǎn)為書(shū)面表達(dá)
            2. 補(bǔ)全缺失的上下文信息（如代詞指代）
            3. 使用知識(shí)庫(kù)中常用的專(zhuān)業(yè)術(shù)語(yǔ)
            4. 保持查詢(xún)的原始意圖不變
            原始問(wèn)題：{original_query}
            改寫(xiě)后的查詢(xún)：
            """;
        return RewriteQueryTransformer.builder()
            .chatClientBuilder(builder)
            .promptTemplate(promptTemplate)
            .targetSearchSystem("vector_store")
            .build();
    }
}

使用示例：

• 原始查詢(xún)：“蘋(píng)果股價(jià)咋樣了？” → 改寫(xiě)后：“查詢(xún)Apple Inc.公司的最新股票價(jià)格”
• 原始查詢(xún)：“它怎么樣？”（多輪對(duì)話中）→ 改寫(xiě)后：“查詢(xún)上一輪提到的產(chǎn)品的詳細(xì)功能”

效果：在電商客服場(chǎng)景中，實(shí)施查詢(xún)重寫(xiě)后，多輪對(duì)話準(zhǔn)確率提升超過(guò)30%，召回率從72%提升至89%。

5.2 混合檢索（Hybrid Search）

問(wèn)題場(chǎng)景：用戶(hù)查詢(xún)“ModelArts平臺(tái)”，向量檢索可能召回“機(jī)器學(xué)習(xí)”、“AI開(kāi)發(fā)”等語(yǔ)義相近但不夠精準(zhǔn)的內(nèi)容，而忽略了包含“ModelArts”關(guān)鍵詞的文檔。單一檢索方式各有短板。

優(yōu)化思路：同時(shí)使用BM25關(guān)鍵詞檢索（精確匹配）和向量語(yǔ)義檢索（語(yǔ)義相似），將兩種結(jié)果融合后返回，取長(zhǎng)補(bǔ)短。

Spring AI Alibaba實(shí)現(xiàn)示例：

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();
        // 關(guān)鍵詞檢索器（需要先對(duì)文檔建立BM25索引）
        KeywordDocumentRetriever keywordRetriever = KeywordDocumentRetriever.builder()
            .indexName("knowledge_base")
            .topK(10)
            .build();
        // 混合檢索：使用 Reciprocal Rank Fusion 融合結(jié)果
        return HybridDocumentRetriever.builder()
            .retrievers(List.of(vectorRetriever, keywordRetriever))
            .joiner(JoinDocumentJoiner.reciprocalRankFusion())
            .build();
    }
}

效果：混合檢索可以將搜索準(zhǔn)確率提升高達(dá)45%。在華為云社區(qū)實(shí)測(cè)中，結(jié)合查詢(xún)重寫(xiě)+混合檢索后，RAG系統(tǒng)的整體準(zhǔn)確率從68%提升到91%。

5.3 結(jié)果重排序（Reranking）

問(wèn)題場(chǎng)景：向量檢索返回的10個(gè)結(jié)果中，第1個(gè)和第5個(gè)哪個(gè)更相關(guān)？相似度分?jǐn)?shù)不一定準(zhǔn)確。直接取Top-K可能漏掉真正相關(guān)的文檔，或者把不相關(guān)的排在了前面。

優(yōu)化思路：引入專(zhuān)門(mén)的重排序模型（如Cohere Rerank、BGE Reranker），對(duì)初步檢索到的候選結(jié)果進(jìn)行二次打分，按新分?jǐn)?shù)重新排序。

Spring AI Alibaba實(shí)現(xiàn)示例：

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) {
        // 基礎(chǔ)向量檢索器，召回20個(gè)候選
        VectorStoreDocumentRetriever baseRetriever = VectorStoreDocumentRetriever.builder()
            .vectorStore(vectorStore)
            .topK(20)  // 多召回一些候選
            .build();
        // 重排序器1：多樣性重排（避免返回的內(nèi)容過(guò)于相似）
        DiversityReranker diversityReranker = DiversityReranker.builder()
            .minDegree(0.5)  // 最小多樣性閾值
            .build();
        // 重排序器2：壓縮重排（用LLM提取最相關(guān)片段，可減少上下文長(zhǎng)度）
        CompressionReranker compressionReranker = CompressionReranker.builder()
            .chatClient(chatClient)
            .maxOutputTokens(500)
            .build();
        // 組合使用：先多樣性重排，再壓縮重排
        return baseRetriever.andThen(diversityReranker).andThen(compressionReranker);
    }
}

效果：在金融研報(bào)問(wèn)答場(chǎng)景中，添加重排序后，答案的準(zhǔn)確率從82%提升到94%，同時(shí)上下文長(zhǎng)度壓縮了60%，節(jié)省了Token成本。

5.4 多向量檢索

問(wèn)題場(chǎng)景：用戶(hù)查詢(xún)“華為云ModelArts平臺(tái)與阿里云PAI平臺(tái)的區(qū)別”，這是一個(gè)多跳推理問(wèn)題，需要同時(shí)檢索兩個(gè)產(chǎn)品的信息并進(jìn)行對(duì)比。單一的向量檢索無(wú)法同時(shí)表達(dá)兩個(gè)獨(dú)立的語(yǔ)義實(shí)體。

優(yōu)化思路：將查詢(xún)分解為多個(gè)子查詢(xún)，分別檢索后再融合結(jié)果?；蛘呤褂枚嗦窓z索器，分別從不同維度（文本語(yǔ)義、關(guān)鍵詞、元數(shù)據(jù)）并行檢索，然后合并。

Spring AI Alibaba實(shí)現(xiàn)示例：

import org.springframework.ai.rag.preretrieval.query.expansion.MultiQueryExpander;
@Configuration
public class MultiVectorConfig {
    @Bean
    public QueryExpander multiQueryExpander(ChatClient.Builder builder) {
        String expansionPrompt = """
            請(qǐng)將以下用戶(hù)問(wèn)題擴(kuò)展為2-4個(gè)不同的子查詢(xún)，每個(gè)子查詢(xún)從不同角度表述，以覆蓋更全面的信息。
            子查詢(xún)之間用換行分隔。
            用戶(hù)問(wèn)題：{original_query}
            擴(kuò)展的子查詢(xún)：
            """;
        return MultiQueryExpander.builder()
            .chatClientBuilder(builder)
            .promptTemplate(expansionPrompt)
            .numberOfQueries(3)  // 生成3個(gè)子查詢(xún)
            .build();
    }
}

結(jié)合使用示例：

@Service
public class AdvancedRagService {
    @Autowired
    private QueryExpander queryExpander;      // 查詢(xún)擴(kuò)展
    @Autowired
    private DocumentRetriever hybridRetriever; // 混合檢索器
    @Autowired
    private Reranker reranker;                 // 重排序器
    public String ask(String question) {
        // 1. 查詢(xún)重寫(xiě)
        String rewritten = rewriteQuery(question);
        // 2. 多向量擴(kuò)展（生成多個(gè)子查詢(xún)）
        List<String> subQueries = queryExpander.expand(rewritten);
        // 3. 對(duì)每個(gè)子查詢(xún)進(jìn)行混合檢索
        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);
    }
}

效果：在多跳問(wèn)答和產(chǎn)品對(duì)比類(lèi)場(chǎng)景中，多向量檢索可將召回率提升20-30%，尤其擅長(zhǎng)處理“A與B的區(qū)別”、“為什么A比B好”這類(lèi)復(fù)雜問(wèn)題。

六、RAG實(shí)戰(zhàn)

對(duì)于Java開(kāi)發(fā)者，目前最成熟的選擇是Spring AI Alibaba框架，它提供了模塊化的RAG架構(gòu)。

6.1 Spring AI Alibaba的RAG優(yōu)勢(shì)

Spring AI Alibaba作為阿里巴巴開(kāi)源的AI開(kāi)發(fā)框架，具有三大核心優(yōu)勢(shì)：

1. 與阿里云生態(tài)深度集成：支持無(wú)縫調(diào)用通義千問(wèn)等大模型，降低技術(shù)門(mén)檻
2. 模塊化設(shè)計(jì)：提供預(yù)處理、檢索、生成、后處理等標(biāo)準(zhǔn)化組件，加速開(kāi)發(fā)
3. 企業(yè)級(jí)支持：內(nèi)置高并發(fā)處理、模型熱更新、監(jiān)控告警等功能，適合生產(chǎn)環(huán)境

其核心思路是實(shí)現(xiàn)“檢索-過(guò)濾-生成”的三段式流程：首先從知識(shí)庫(kù)中檢索相關(guān)文檔片段，再通過(guò)語(yǔ)義過(guò)濾排除無(wú)關(guān)內(nèi)容，最后由生成模型合成自然語(yǔ)言回答。

6.2 核心組件詳解

Spring AI Alibaba的模塊化RAG架構(gòu)包含以下核心組件：

6.3 完整代碼實(shí)現(xiàn)

第一步：添加依賴(lài)

<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>

第二步：配置向量數(shù)據(jù)庫(kù)和Embedding模型

@Configuration
public class RagConfig {
    @Bean
    public ChatClient chatClient(ChatClient.Builder builder) {
        return builder
            .defaultSystem("你是一個(gè)專(zhuān)業(yè)的智能問(wèn)答助手，請(qǐng)基于提供的參考資料回答問(wèn)題。")
            .build();
    }
    @Bean
    public VectorStore vectorStore(EmbeddingModel embeddingModel) {
        // 示例：使用內(nèi)存存儲(chǔ)（適合原型驗(yàn)證）
        SimpleVectorStore simpleVectorStore = SimpleVectorStore.builder(embeddingModel).build();
        return simpleVectorStore;
        // 生產(chǎn)環(huán)境可替換為 MilvusVectorStore、PgVectorStore 等
    }
    @Bean
    public EmbeddingModel embeddingModel() {
        return new DashScopeEmbeddingModel(
            DashScopeEmbeddingOptions.builder()
                .withModel("text-embedding-v3")
                .build()
        );
    }
}

第三步：構(gòu)建知識(shí)庫(kù)索引

@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. 向量化并存儲(chǔ)
        vectorStore.add(chunks);
        System.out.println("已索引 " + chunks.size() + " 個(gè)文檔塊");
    }
}

第四步：實(shí)現(xiàn)RAG問(wèn)答接口

@RestController
@RequestMapping("/api/rag")
public class RagController {
    @Autowired
    private ChatClient chatClient;
    @Autowired
    private VectorStore vectorStore;
    @PostMapping("/ask")
    public String ask(@RequestParam String question) {
        // 使用 QuestionAnswerAdvisor 自動(dòng)完成檢索增強(qiáng)
        return chatClient.prompt()
                .user(question)
                .advisors(new QuestionAnswerAdvisor(vectorStore))
                .call()
                .content();
    }
}

只需這幾步，一個(gè)完整的RAG智能問(wèn)答系統(tǒng)就搭建完成了！QuestionAnswerAdvisor會(huì)自動(dòng)完成問(wèn)題向量化、相似度檢索和Prompt組裝的全部工作。

七、RAG的優(yōu)缺點(diǎn)

7.1 優(yōu)點(diǎn)

• 準(zhǔn)確率高：通過(guò)檢索外部知識(shí)，大幅降低模型幻覺(jué)，提升事實(shí)準(zhǔn)確性。RAG通過(guò)引入事實(shí)邊界約束，要求LLM的答案嚴(yán)格基于檢索到的權(quán)威文檔，這在金融、醫(yī)療等合規(guī)敏感行業(yè)中至關(guān)重要。
• 知識(shí)實(shí)時(shí)更新：只需更新向量數(shù)據(jù)庫(kù)即可，無(wú)需重新訓(xùn)練模型。通過(guò)外接動(dòng)態(tài)知識(shí)庫(kù)（如公司文檔系統(tǒng)或新聞API），當(dāng)用戶(hù)查詢(xún)最新信息時(shí)，RAG先檢索外部數(shù)據(jù)庫(kù)中的實(shí)時(shí)內(nèi)容，再讓LLM基于檢索結(jié)果生成答案。
• 可解釋性強(qiáng)：可以展示檢索到的來(lái)源文檔，讓用戶(hù)知道答案來(lái)源，具備可審計(jì)性。
• 成本可控：比微調(diào)大模型便宜得多，無(wú)需數(shù)百萬(wàn)美元的訓(xùn)練成本。
• 保護(hù)數(shù)據(jù)隱私：私有數(shù)據(jù)只存儲(chǔ)在本地向量庫(kù)中，不會(huì)上傳到模型服務(wù)端。
• 領(lǐng)域適配靈活：將企業(yè)內(nèi)部文檔導(dǎo)入向量數(shù)據(jù)庫(kù)，使通用LLM瞬間升級(jí)為領(lǐng)域?qū)＜摇?/li>

7.2 缺點(diǎn)

• 檢索質(zhì)量決定一切：如果檢索不到相關(guān)內(nèi)容，LLM也無(wú)能為力。
• 上下文窗口限制：無(wú)法一次性塞入海量資料，需要合理切分。
• 增加系統(tǒng)復(fù)雜度：需要維護(hù)向量數(shù)據(jù)庫(kù)、Embedding模型、LLM等多個(gè)組件。
• 延遲略高：相比直接調(diào)用LLM，RAG多了檢索步驟，會(huì)增加幾十到幾百毫秒的延遲。
• 評(píng)估困難：RAG系統(tǒng)需要從檢索準(zhǔn)確性和生成質(zhì)量多個(gè)維度進(jìn)行綜合評(píng)估。
• 知識(shí)沖突處理：檢索到的信息可能與LLM的參數(shù)化記憶發(fā)生沖突，需要設(shè)計(jì)有效的融合策略。

八、RAG的使用場(chǎng)景

8.1 最適合RAG的場(chǎng)景

• 企業(yè)內(nèi)部知識(shí)庫(kù)問(wèn)答：把公司的文檔、規(guī)范、培訓(xùn)材料建成RAG，員工可以隨時(shí)提問(wèn)
• 智能客服系統(tǒng)：將產(chǎn)品文檔、FAQ接入RAG，讓AI客服能夠準(zhǔn)確回答產(chǎn)品問(wèn)題
• 法律/合同審查：讓AI基于合同文本回答問(wèn)題，幫助律師快速定位條款
• 金融研報(bào)分析：分析師可以直接提問(wèn)“這份研報(bào)中對(duì)XX公司的評(píng)級(jí)是什么”，AI基于報(bào)告內(nèi)容回答
• 合規(guī)敏感行業(yè)：RAG通過(guò)強(qiáng)制LLM基于權(quán)威文檔回答并附來(lái)源，在金融、醫(yī)療等合規(guī)敏感行業(yè)中至關(guān)重要

8.2 不適合RAG的場(chǎng)景

• 簡(jiǎn)單的閑聊：不需要外部知識(shí)的對(duì)話，直接用LLM就夠了
• 需要深度推理的任務(wù)：RAG擅長(zhǎng)“查資料”，不擅長(zhǎng)“推導(dǎo)結(jié)論”
• 對(duì)延遲極度敏感的場(chǎng)景：檢索會(huì)增加額外耗時(shí)

總結(jié)

RAG（檢索增強(qiáng)生成）是目前企業(yè)落地AI應(yīng)用最務(wù)實(shí)的技術(shù)方案。

它的核心價(jià)值可以概括為：讓LLM帶著資料回答問(wèn)題，把AI幻覺(jué)降到最低。

在Java生態(tài)中，Spring AI Alibaba提供了開(kāi)箱即用的模塊化RAG支持。通過(guò)遵循最佳實(shí)踐，可以構(gòu)建一個(gè)高效、可靠的RAG系統(tǒng)，為用戶(hù)提供準(zhǔn)確和專(zhuān)業(yè)的回答。

如果你正面臨“AI答非所問(wèn)”的困擾，不妨從RAG開(kāi)始——這是目前成本最低、見(jiàn)效最快的解決方案。

未來(lái)已來(lái)，用好RAG，讓AI真正成為你的得力助手。

到此這篇關(guān)于Java程序員必看的RAG入門(mén)實(shí)戰(zhàn)教程的文章就介紹到這了,更多相關(guān)Java RAG入門(mén)教程內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論