RAG(Retrieval-Augmented Generation,檢索增強生成)是一種讓 AI 在生成回答之前,先從外部知識庫主動檢索相關資料的技術架構。傳統的 LLM 只能依靠訓練時學到的知識回答問題,這意味著它的知識有截止日期、可能過時,而且在不確定時容易「自己發明答案」(幻覺)。RAG 解決的正是這個根本問題。
RAG 的運作方式可以分三步理解:第一步,把使用者的問題轉化為向量(數學表示),在向量資料庫中搜尋語意最相似的文件片段;第二步,把檢索到的文件片段和原始問題一起組成一個新的提示詞,送給 LLM;第三步,LLM 根據這些具體的參考資料生成回答,而不是從記憶中「憑空生成」。
結果是:回答有根據、可追溯來源、幻覺大幅減少。這就是為什麼幾乎所有企業級 AI 應用(客服機器人、內部知識庫問答、文件分析系統)都採用 RAG 架構,而不是直接使用裸 LLM。
RAG 存在的根本原因,是 LLM 的兩個天生缺陷無法靠「訓練更多資料」解決:知識截止日期和幻覺問題。所有 LLM 都只知道訓練資料截止日前的資訊,重新訓練成本高達百萬美元等級。LLM 在不確定時不說「我不知道」,而是生成聽起來合理但可能錯誤的答案。
RAG 的解法:不改變模型,而是改變給模型的輸入。每次問問題前先查資料,把查到的東西給模型看,然後指示它「根據這些資料回答」。成本低、可控、可解釋——這就是為什麼 RAG 成為企業 AI 應用的標準架構。
理解 RAG 對你的影響,取決於你在什麼場景下思考這個問題。如果你是一般用戶,Claude Projects 裡上傳的文件,本質上就是在做一個簡化版的 RAG——你把外部知識放進 Context,Claude 根據這些資料回答。理解這個原理,你會更知道什麼文件值得上傳(和問題直接相關的、最新的、精確的)。
如果你是開發者,RAG 是目前最主流的 AI 應用架構,掌握它是構建企業級 AI 應用的基礎技能。核心技術棧包含:Embedding 模型、向量資料庫(Chroma、Pinecone、pgvector)、Chunking 策略、Retrieval 評估。
如果你是企業決策者,RAG 是讓 AI 能夠安全使用你的企業內部知識的關鍵技術,所有回答都可以追溯到原始文件,降低幻覺風險。
一般用戶:建立 Claude Project,上傳你真正想讓 Claude「依據這些」回答的文件;問問題時明確說「根據我上傳的文件」;優先上傳具體的、最新的、和你的問題直接相關的文件。
開發者入門路徑:理解 RAG 管道的四個步驟(Indexing → Retrieval → Augmentation → Generation);推薦工具 LangChain 或 LlamaIndex + Chroma;Claude API 接入時明確指定「只根據以下資料回答,如果資料不足請說明」。
企業評估 RAG 導入:從一個有明確需求的場景開始(例如內部 HR 政策 Q&A);先評估文件品質(垃圾進、垃圾出);建立評估機制量化 RAG 系統的回答準確率。
陳小姐是一家有 200 名員工的科技公司的 HR 主管,有一份 80 頁的員工手冊。每天她要回答大量員工的重複問題。
導入 RAG 之前:員工發 email 問「我生病請假三天需要什麼文件?」,陳小姐每天處理 15-20 封這樣的信,大量時間浪費在重複查手冊。
導入 RAG 之後:開發團隊把員工手冊切割成段落,建立向量索引,接上 Claude API 做成內部問答機器人。員工直接問機器人,系統把問題向量化,在手冊向量索引裡找到「請假規定」第 3.2 條,把這段規定和原始問題一起送給 Claude,Claude 回答:「依員工手冊第 3.2 條,病假超過兩天需提供醫院診斷書,假單須在回來上班後三個工作天內提交 HR。」
結果:陳小姐的重複問答工作量降低約 70%,回答可追溯到具體條款,員工信任度提升。
RAG 的優點:知識可以持續更新不需重訓模型;回答有根據可追溯;幻覺風險大幅降低;相較 Fine-tuning 成本低得多;可整合私有、敏感、即時資料。
RAG 的缺點:需要建立和維護向量資料庫,有額外基礎設施成本;Chunking 策略不對,檢索品質就差;Embedding 和檢索引入延遲;知識庫品質決定 RAG 品質;無法替代模型的邏輯推理和創意能力。
RAG 特別值得的場景:知識庫大且更新頻繁、對準確性要求高(法律、醫療、金融)、需要追溯來源。不適合的場景:任務不依賴特定知識(創意寫作)、對延遲要求極高、知識庫很小且穩定。