Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
獨立知識媒體
與任何項目無關聯
探索AI智慧的思維邊界
claude-me.com
最新
開發者的 MCP 實作:從零開始建立你的第一個 MCP Server  ·  非工程師的 MCP 入門:不寫一行代碼,讓 Claude 直接連上你常用的工具  ·  Claude Projects 功能深度評測:用了三個月,這是我真實的使用感受  ·  Claude vs ChatGPT 2026 年老實比較:不是誰更強,而是你該用哪一個  ·  用 Claude Debug 的正確姿勢:不是貼 Error 等答案,而是讓它陪你系統化找問題  ·  用 Claude 寫週報的完整工作流:從亂糟糟的筆記到一份讓老闆滿意的報告
名詞解析 · Core Concepts

Retrieval-Augmented Generation (RAG)

檢索增強生成
Core Concepts 中級

30 秒版 · 給沒耐心的人
讓 AI 在回答前先從外部知識庫檢索相關資料,再根據檢索結果生成回答,解決模型知識過時和幻覺問題的技術架構。
完整解說 +
01 · 這是什麼?
RAG(Retrieval-Augmented Generation,檢索增強生成)是一種讓 AI 在生成回答之前,先從外部知識庫主動檢索相關資料的技術架構。傳統的 LLM 只能依靠訓練時學到的知識回答問題,這意味著它的知識有截止日期、可能過時,而且在不確定時容易「自己發明答案」(幻覺)。RAG 解決的正是這個根本問題。 RAG 的運作方式可以分三步理解:第一步,把使用者的問題轉化為向量(數學表示),在向量資料庫中搜尋語意最相似的文件片段;第二步,把檢索到的文件片段和原始問題一起組成一個新的提示詞,送給 LLM;第三步,LLM 根據這些具體的參考資料生成回答,而不是從記憶中「憑空生成」。 結果是:回答有根據、可追溯來源、幻覺大幅減少。這就是為什麼幾乎所有企業級 AI 應用(客服機器人、內部知識庫問答、文件分析系統)都採用 RAG 架構,而不是直接使用裸 LLM。
02 · 為什麼存在?
RAG 存在的根本原因,是 LLM 的兩個天生缺陷無法靠「訓練更多資料」解決:知識截止日期和幻覺問題。所有 LLM 都只知道訓練資料截止日前的資訊,重新訓練成本高達百萬美元等級。LLM 在不確定時不說「我不知道」,而是生成聽起來合理但可能錯誤的答案。 RAG 的解法:不改變模型,而是改變給模型的輸入。每次問問題前先查資料,把查到的東西給模型看,然後指示它「根據這些資料回答」。成本低、可控、可解釋——這就是為什麼 RAG 成為企業 AI 應用的標準架構。
03 · 如何影響你的決策?
理解 RAG 對你的影響,取決於你在什麼場景下思考這個問題。如果你是一般用戶,Claude Projects 裡上傳的文件,本質上就是在做一個簡化版的 RAG——你把外部知識放進 Context,Claude 根據這些資料回答。理解這個原理,你會更知道什麼文件值得上傳(和問題直接相關的、最新的、精確的)。 如果你是開發者,RAG 是目前最主流的 AI 應用架構,掌握它是構建企業級 AI 應用的基礎技能。核心技術棧包含:Embedding 模型、向量資料庫(Chroma、Pinecone、pgvector)、Chunking 策略、Retrieval 評估。 如果你是企業決策者,RAG 是讓 AI 能夠安全使用你的企業內部知識的關鍵技術,所有回答都可以追溯到原始文件,降低幻覺風險。
04 · 你該怎麼辦?
一般用戶:建立 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 — How It WorksUserQuestionEmbedVectorize query[0.2, 0.8, ...]Knowledge BaseYour docs · DBWeb pages↓ Retrieve top-kRetrievedRelevant chunksTop 3-5 resultsPrompt = Question + Retrieved Context"Answer based only on the following sources:"[retrieved chunks] + [original user question]LLM (Claude)Generates grounded answerGroundedAnswer ✓Source-backed · No hallucinationClaude Me · claude-me.com
歡迎截圖分享,轉載請註明來源
常見誤解 +
✕ 誤解1
× 誤解一:RAG 就是把文件貼給 AI 看,和直接複製貼上沒什麼不同。這個誤解忽略了 RAG 最關鍵的部分:「檢索」。直接貼文件是把所有資料塞進 Context,一份長文件可能瞬間把 Context Window 用完。RAG 的向量檢索是找出「和這個問題語意最相關的片段」,在大型知識庫(數百份文件)下,沒有向量檢索根本無法把所有文件塞進一個 Context 裡。
✕ 誤解2
× 誤解二:用了 RAG 就不會有幻覺。RAG 大幅降低幻覺,但不能完全消除。如果知識庫本身包含錯誤資訊,RAG 只是把錯誤資訊更精確地傳給 LLM。另外,如果使用者的問題和知識庫的內容語意距離太遠,檢索回來的文件片段可能不相關,LLM 仍然可能幻覺。RAG 是工具,不是魔法。
這件事跟你有什麼關係 +
直接影響
RAG 的優點:知識可以持續更新不需重訓模型;回答有根據可追溯;幻覺風險大幅降低;相較 Fine-tuning 成本低得多;可整合私有、敏感、即時資料。 RAG 的缺點:需要建立和維護向量資料庫,有額外基礎設施成本;Chunking 策略不對,檢索品質就差;Embedding 和檢索引入延遲;知識庫品質決定 RAG 品質;無法替代模型的邏輯推理和創意能力。 RAG 特別值得的場景:知識庫大且更新頻繁、對準確性要求高(法律、醫療、金融)、需要追溯來源。不適合的場景:任務不依賴特定知識(創意寫作)、對延遲要求極高、知識庫很小且穩定。
提問
請至少輸入 10 個字