[AI 分享] RAG是否已死

 [AI 分享] RAG是否已死

摘要 : RAG並未過時；雖然大模型上下文變長，但在成本、效率與私有知識接入上，RAG仍具重要價值。

內容:

RAG（Retrieval Augmented Generation，檢索增強生成）是近年大模型領域中相當成熟的一項技術。不過，最近有不少自媒體開始宣稱「RAG已死」，因此本文希望從原理、價值與爭議三個角度，重新梳理RAG的前世今生，看看這個說法是否站得住腳。

從名稱來看，RAG本質上是一種「用檢索來增強生成效果」的方法。傳統做法是把問題直接交給大模型作答；而在RAG架構中，會在問題與大模型之間加入一個檢索模組，先從外部知識庫中找出相關內容，再將問題與檢索結果一併交給模型。這樣做的根本原因在於：原始問題所需的資訊，往往不完整存在於大模型本身，因此需要透過外部知識庫來補足，尤其是企業私有資料、內部文件或特定領域知識。

那麼，為什麼不直接把整個外部知識庫全部丟給大模型？原因很簡單，因為大模型有上下文長度限制。即使上下文已經比以前大很多，把所有知識一次性輸入，不但可能超出限制，也會讓模型分析與計算的成本大幅上升，因此仍需要一套有效率的篩選與檢索機制。

RAG的基本流程大致如下。首先，外部知識庫會先被切分成多個較小的文本分片。這樣做的目的是讓系統在每次檢索時，更容易找到和問題最相關的局部內容，而不是從龐大原文中無差別處理。這些分片，就是之後會提供給大模型參考的文本材料。

接著，這些文本分片需要經過向量化（embedding）處理。由於電腦本質上處理的是數值而不是文字，因此必須將文本轉換為向量，映射到向量空間中。在這個空間裡，語意相近的文本應該彼此靠近，語意差異大的文本則距離較遠。也就是說，若兩段內容意思相近，經過向量化之後，它們在向量空間中的位置也應該相近。

當使用者提出問題時，問題本身也會先被向量化。接著，系統會拿這個問題向量去比對知識庫中各個文本分片的向量，找出最接近、也就是語意上最相關的幾個分片。最後，再把問題與這些相關分片一起送進大模型，讓模型在有額外上下文支援的情況下生成答案。這也是RAG能提升回答準確度的核心原因。

這裡有一個很重要的前提：知識分片與使用者問題在向量化時，應採用一致的向量化模型或演算法。只有在同一套語意映射規則下，系統才能保證語意相近的內容在向量空間中也足夠接近，進而讓檢索結果具有可靠性。

雖然RAG的整體流程看起來不複雜，但真正進入工程實作時，仍有許多細節需要最佳化。首先是分片策略。分片如果切得不好，就可能破壞語意完整性，例如把同一句話、同一條法規或同一段關鍵說明拆散，導致檢索時拿到的是殘缺資訊。以法律文件為例，理想情況是以完整法條作為切分單位，而不是把一條法規拆到不同分片裡。因此，不同場景下需要不同的分片邏輯。

第二個關鍵點是向量化演算法的選擇。RAG是否能準確找回相關內容，很大程度取決於向量模型是否能正確表達語意相似性。實務上常常需要針對不同資料集，測試多種向量化方案，挑選效果與效能兼顧的方法。

第三個重點是檢索策略本身。系統可以只取最相近的兩個分片，也可以擴大到三個、五個甚至更多。檢索條件設得太嚴，可能漏掉重要資訊；設得太寬，則可能帶入太多雜訊。因此，檢索數量與門檻也需要依應用場景做客製化調整。

那麼，為什麼會有人說「RAG已死」？其中一個主要理由，是因為現在大模型發展很快，上下文長度越來越大。像 DeepSeek、Gemini 等模型都已支援非常長的上下文，於是有人認為，既然模型可以一次讀進大量內容，就不再需要額外的檢索流程，只要把所有相關資料直接給模型即可。

但這樣的推論其實並不充分。即便上下文夠大，把所有資料一股腦交給模型，仍然會面臨兩個現實問題：第一是效率，因為大模型推理本來就慢，輸入內容越多，整體處理時間越長；第二是成本，更多的上下文代表更高的計算資源消耗。因此，僅因上下文變長就斷言RAG失去價值，並不合理。

另一種批評則來自效果面。有人認為，RAG依賴分片檢索，容易造成語意遺失，因此最終效果不如預期。這個問題確實存在，但它更像是「RAG做得不夠好」，而不是「RAG沒有用」。因為RAG本質上是一個框架，真正的效果高度依賴分片方式、向量化品質與檢索策略。只要這些環節有足夠細緻的最佳化，RAG仍然可以產生相當不錯的結果。

總結來說，RAG並沒有死。相反地，它仍然是在私有知識接入、大模型回答增強、控制成本與提升效率等場景中非常重要的方法。大模型上下文變長，確實會改變RAG的使用方式，但不代表它會被完全取代。更準確地說，RAG正在演進，而不是消失。