RAGFlow：從零搭建企業級本地 RAG 知識庫平台
深度介紹 RAGFlow 這套開源 RAG 平台的核心架構與功能。從 Dataset 知識庫建立、智能體流程設計，到 Memory 跨對話記憶，完整解析如何在本地端打造一個企業可用的 AI 知識查詢與 Agent 系統。
WRITTEN BY
- Name
- Harry Chang
在企業 AI 落地的路上，有一個繞不開的核心問題：如何讓 AI 真正「讀懂」你的內部文件，而不是靠通用知識瞎猜？
這個問題的答案，就是 RAG（Retrieval-Augmented Generation，檢索增強生成）。而 RAGFlow，正是目前開源社群中最完整的 RAG 平台之一。它把知識庫管理、向量搜尋、Agent 流程設計、跨對話記憶全部整合在一個介面裡，讓你不必自己串接一堆工具，就能建立一套可實用的企業知識 AI。
技術棧
| 層次 | 技術 | 版本 | 用途 |
|---|---|---|---|
| 應用程式 | RAGFlow | v0.26.1 | 主平台 |
| 文件解析 | DeepDoc | 內建 | PDF / Word / Excel / 圖片深度解析 |
| 向量資料庫 | Elasticsearch | 8.11.3 | 向量索引與搜尋 |
| 物件儲存 | MinIO | 2026-03-25 | 原始文件儲存 |
| 關聯式資料庫 | MySQL | 8.0.39 | 元數據管理 |
| 快取 | Valkey (Redis) | 8 | Session 與任務佇列 |
| Embedding 模型 | nomic-embed-text (Ollama) | 本地 | 文件向量化 |
| LLM | Claude / OpenRouter | 外部 API | 對話推理 |
| 容器化 | Docker Compose | - | 一鍵部署 |
RAGFlow 是什麼？
RAGFlow 是由 InfiniFlow 開發的開源 RAG 平台，目前在 GitHub 上已累積超過 80,000 顆星。它的核心定位不是一個 LLM，而是一個讓 LLM 變得更精準的基礎設施。
你可以把它想像成一個「AI 的圖書館系統」：
- 你把公司的 SOP、規範、說明書上傳進去
- 系統自動解析、切塊、向量化
- 當員工提問時，AI 先去圖書館找相關段落，再根據找到的內容回答
這樣的設計解決了 LLM 最常被詬病的問題：幻覺（Hallucination）。因為 AI 的每一句話都有文件來源作為依據，不是憑空生成的。
核心架構
RAGFlow 的內部架構可以分為四個層次：
整個系統透過 Docker Compose 一鍵啟動，對使用者完全透明。你只需要管好「上傳什麼文件」和「設計什麼 Agent 流程」，底層的 Elasticsearch 向量索引、MinIO 物件儲存全部自動運作。
五大功能模組
1. Dataset（知識庫）
Dataset 是 RAGFlow 最基礎的功能，也是一切的起點。
你可以把它理解為一個有主題的資料夾。每個 Dataset 對應一個知識領域，例如「IT 手冊」、「採購 SOP」、「產品規格」。
（截圖：Dataset 上傳與解析介面）
文件上傳後，RAGFlow 的 DeepDoc 引擎會自動：
- 解析文件結構（支援 PDF、Word、Excel、圖片）
- 切塊（Chunking）— 把文件分成數十到數百個小段落
- 向量化（Embedding）— 把每個段落轉成數字向量
- 寫入 Elasticsearch — 建立可搜尋的向量索引
切塊的品質直接決定 AI 回答的準確度。RAGFlow 提供多種 Parse 模式（General、Manual、Paper 等），可以根據文件類型調整。
2. 聊天（Chat）
聊天模組是最直觀的入口，讓一般員工不需要懂技術就能使用。
（截圖：聊天對話介面）
每個 Chat Assistant 都可以獨立設定：
- 使用哪個 LLM（Claude、GPT-4o、本地 Ollama 模型）
- 綁定哪些 Dataset（一個或多個知識庫）
- 開場白（引導使用者知道這個助手能回答什麼）
這讓企業可以針對不同部門建立專屬助手：IT 助手只能查 IT 手冊、採購助手只能查採購流程，互不干擾。
3. 搜尋（Search）
搜尋模組提供比聊天更直接的知識庫查詢介面。
（截圖：搜尋查詢介面）
和聊天的差異在於：搜尋不進行對話式推理，而是直接返回最相關的文件片段（Chunks）及其來源頁碼。
這適合以下場景：
- 使用者想快速確認「文件裡有沒有提到 X」
- 需要找到原文出處，而不是 AI 改寫後的摘要
- 作為開發者 Debug 時，驗證向量搜尋是否正常運作
4. 智能體（Agent）
智能體是 RAGFlow 最強大的功能，也是從「問答工具」升級到「自動化工作流」的關鍵。
（截圖：Agent 流程圖編輯器）
RAGFlow 的 Agent 採用視覺化流程圖設計，每個節點代表一個處理步驟：
| 節點類型 | 功能 |
|---|---|
| 開始 | 接收使用者輸入 |
| Retrieval | 從 Dataset 搜尋相關內容 |
| LLM | 呼叫語言模型推理 |
| MCP Tool | 呼叫外部工具（Odoo、API 等） |
| Response | 回傳最終答案 |
透過這種節點式設計，你可以建立複雜的多步驟工作流：先搜尋知識庫、再查詢 ERP 系統、最後綜合生成報告，全程自動化。
RAGFlow 內建多個 Agent 範本，涵蓋客服、市場分析、資料入庫等場景，可以直接套用後修改。
5. Memory（記憶）
Memory 解決了 AI 對話「每次從零開始」的痛點。
（截圖：Memory 建立與設定介面）
RAGFlow 支援四種記憶類型：
| 類型 | 儲存內容 | 適合場景 |
|---|---|---|
| raw | 完整對話記錄 | 稽核、日誌 |
| semantic | 語意摘要（使用者背景、偏好） | 認識使用者 |
| episodic | 事件記憶（發生過什麼事） | 追蹤問題歷史 |
| procedural | 行為習慣（使用者喜好的回答方式） | 個人化體驗 |
對於工廠或企業內部使用，最實用的是 semantic + episodic 的組合：AI 記住每個員工負責什麼設備、遇過什麼問題，下次提問時不需要重新說明背景。
6. 文件管理
文件管理模組提供跨 Dataset 的全域檔案視圖。
（截圖：文件管理介面）
和 Dataset 的差異在於：Dataset 是「按主題分類」，而文件管理是「按檔案視角」，讓你可以：
- 看到所有上傳的原始文件
- 一個文件可以同時加入多個 Dataset
- 集中管理版本更新（舊版文件取代新版）
RAGFlow vs 傳統 RAG 架構
市面上有許多 RAG 實作方式，RAGFlow 的定位與差異如下：
| 比較維度 | 自建 RAG (LangChain) | RAGFlow |
|---|---|---|
| 上手難度 | 高，需要寫程式 | 低，有 UI |
| 部署方式 | 自行組合元件 | Docker 一鍵啟動 |
| 文件解析 | 基本 | DeepDoc 深度解析（表格/圖片） |
| Agent 設計 | 需寫程式碼 | 視覺化流程圖 |
| 適合對象 | 工程師 | 工程師 + 業務人員 |
實際部署心得
我在本機（Windows 11 + Docker）完整跑起了 RAGFlow，整個過程大約花了一個小時。幾個值得注意的地方：
Embedding 模型的選擇很關鍵。RAGFlow 不內建 Embedding，需要自行設定。我選擇了透過 Ollama 在本地運行的 nomic-embed-text（274MB），搭配 Claude 作為聊天模型。這樣的組合在不傳送任何文件內容到外部的前提下，就能完成整個 RAG 流程。
文件 Parse 模式需要根據文件類型調整。預設的 General 模式對 Word 文件產生 4 個 Chunks。
Agent 範本的語言問題：RAGFlow 的 Agent 範本卡片在繁體中文介面下標題無法顯示（已知 Bug，源自 i18n.language 回傳 zh-Hant 但 Template 只有 zh key）。這個問題可以透過修改前端的 template-card.tsx 解決。
結語
RAGFlow 的架構設計有效地將技術複雜度與使用門檻進行了分離。
底層的向量資料庫、Embedding Pipeline 以及 Elasticsearch 索引等技術細節由系統後台處理，而在 RAGFlow 的前端介面中，一般使用者只需透過「上傳文件、解析 (Parse)、提問」三個基本步驟即可進行知識查詢。
這樣的機制讓不同技術背景的人員都能夠參與使用，使開發成果能在組織內部被廣泛應用。
在後續的規劃中，預計會將 RAGFlow 的 Agent 透過 MCP 協定與 ERP 系統串接。這將使系統除了能查詢內部非結構化文件外，還能即時存取訂單、庫存等結構化資料，進一步擴展其在工廠營運場景中的應用範圍。
參考資料 (References)
官方資源與文件