RAG 是什麼？

RAG 的一句話理解

RAG 是 Retrieval-Augmented Generation。白話說，就是：

使用者提問後，系統先去查可信資料，再把查到的內容交給模型生成回答。

它不是把公司所有文件塞進模型裡訓練，也不是讓模型憑記憶回答。RAG 的價值在於讓模型接上外部資料，尤其是公司內部文件、制度、SOP、產品規格、客服知識庫、技術文件、合約和資料庫。

典型 RAG 流程

步驟	做什麼	常見風險
資料擷取	從 PDF、Word、網頁、資料庫、SharePoint 等來源拿資料	格式亂、版本舊、權限不清
切分	把長文件切成可檢索片段	切太碎沒脈絡，切太大浪費 token
建立索引	用關鍵字、向量、混合搜尋或 semantic ranking 建立查詢能力	embedding 不合、欄位設計不佳、更新流程缺失
檢索	使用者提問後找相關內容	找不到、找太多、找錯權限資料
生成	模型根據檢索結果回答	引用不足、過度推論、回答不穩
評測與更新	追蹤錯誤、改善資料與索引	沒有人維護，越用越亂

真正難的通常不是「讓模型講話」，而是讓它查對資料、尊重權限、附上來源，並且在資料更新後仍然可靠。

Classic RAG 和 Agentic Retrieval

Classic RAG 可以先想成：一次使用者問題，系統做一次或一組檢索，然後交給模型回答。

Agentic retrieval 則更進一步。Microsoft Azure AI Search 的文件把它描述成用 LLM 做 query planning，將複雜問題拆成多個子查詢，並行查詢多個來源，回傳 grounding data、citations 和 query activity。它比較適合 agent、複雜對話、跨資料源與需要追蹤查詢過程的企業場景。

但 agentic retrieval 也不一定適合所有 PoC。它可能增加延遲、成本與系統複雜度。簡單問題或低延遲需求，classic RAG / hybrid search 可能更務實。

RAG 為什麼跟 AI 硬體有關？

RAG 不是純軟體題。當資料變多、使用者變多、權限變複雜，硬體與部署會開始影響體驗：

• RAM：文件處理、索引、向量資料庫、服務容器會吃 RAM。
• 儲存：文件庫、索引、向量資料、版本和備份需要容量。
• GPU / VRAM：若模型也在本地跑，推論速度和模型大小會受影響。
• 網路：內部資料源、使用者、API 和檔案服務都要連接。
• 監控與日誌：要追蹤問題是檢索錯、資料錯、權限錯還是模型亂答。

所以企業 RAG 不是只買一台很強的 AI 主機就結束，而是資料、權限、檢索、模型、硬體和維護的整套工程。

什麼情境最適合先做 RAG？

本站建議優先從這些場景開始：

• 公司制度與 SOP 查詢。
• 客服知識庫。
• 業務產品規格問答。
• 技術文件、API 文件、維運手冊。
• 合約或內部政策查詢。
• 新人訓練與內部知識搜尋。

這些場景共同點是：答案常常存在公司資料裡，而且需要引用來源。RAG 比純聊天模型更能接近實際工作流。

最後更新：2026-06-11；本頁已複查 Microsoft RAG / Azure AI Search 與 NVIDIA RAG 相關來源。