RAG 是什麼？本地 RAG 架構、硬體需求與微調差別

先講結論：RAG 是什麼？

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

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

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

典型 RAG 流程

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

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

RAG 跟微調差在哪？

RAG 和微調都能讓通用模型更貼近特定需求，但改的是不同層次：

問題	RAG	微調
主要目的	讓回答能查到外部、私有或最新資料	改變模型行為、語氣、格式或特定任務表現
資料更新	更新文件與索引即可	通常要重新準備資料並訓練新版本
引用來源	可以把文件、段落或網址帶回回答	模型本身通常不會自動提供資料來源
典型情境	內部知識庫、制度、產品規格、客服文件	固定輸出格式、分類、特定寫作風格或專門任務
能否搭配	可以；檢索負責知識，微調負責行為	可以；但微調不能取代資料權限與即時檢索

如果問題是「公司文件常更新，而且回答要附來源」，通常先做 RAG。若問題是「模型已經知道內容，但輸出格式或任務表現不穩」，才評估微調。兩者都不會自動解決資料品質、權限或評測問題。

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 硬體需求怎麼估？

先不要用一個「RAG 最低規格」回答所有情境。RAG 是一條管線，每一段吃的資源不同：

工作階段	主要工作	常見硬體壓力	先量什麼
文件擷取與清理	解析 PDF、Office、網頁、表格與 OCR	CPU、RAM、儲存讀寫；多模態 OCR 可能用加速器	文件數、頁數、格式、更新頻率
Embedding 與建索引	把片段轉成向量，寫入搜尋或向量索引	CPU／GPU、RAM、儲存容量與寫入速度	片段數、embedding 模型、重建頻率
線上檢索與 rerank	找出相關片段並重新排序	RAM、索引延遲、CPU／GPU、網路	每秒查詢數、top-k、延遲目標
LLM 生成	根據問題與檢索內容產生答案	模型記憶體、GPU／VRAM 或 Unified Memory、吞吐	模型大小、上下文、同時使用人數
服務與治理	API、權限、日誌、監控、備份	RAM、儲存、網路與備援	使用者數、保留期限、可用性要求

因此，本地 RAG 不一定要獨立 GPU：

• 文件、索引與檢索留在公司內部，但生成使用受控雲端 API，小型 PoC 可以先用 CPU、RAM 和 SSD 驗證流程。
• LLM 也要留在本地時，先用實際模型檔、上下文與併發量估記憶體，再決定 GPU、VRAM 或 Unified Memory。
• OCR、VLM、reranker、多人同時查詢或嚴格延遲目標，會增加加速器與服務化需求。
• 正式企業服務還要算備份、監控、權限、更新與故障恢復，不能只看單次推論能不能跑。

NVIDIA 目前的 RAG Blueprint 支援矩陣也明確把 Docker、Kubernetes、模型與選配服務分開列需求；其預設自架堆疊包含大型模型、容器與索引，文件要求約 200GB 可用磁碟並依部署方式配置多張 GPU。這是特定 Blueprint 的參考規格，不是所有 RAG 系統的最低門檻。拿任何廠商的完整企業範例直接套到小型文件問答，通常會高估需求。

什麼情境最適合先做 RAG？

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

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

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

最後更新：2026-08-10；本頁已複查 Microsoft Foundry／Azure AI Search、AWS RAG 與微調比較、NVIDIA RAG Blueprint 系統需求等官方來源。