RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow 是 infiniflow 開源的 RAG（Retrieval-Augmented Generation，檢索增強生成）引擎。它的目標不是只做一個「上傳文件然後問答」的知識庫外殼，而是把文件解析、切分、檢索、重排、引用溯源、模型配置、Agent 能力和 API 整合放進一套完整工作流裡。

如果你正在做企業知識庫、文件問答、客服助手、內部資料檢索，或者想給 LLM 加一層更可靠的上下文來源，RAGFlow 屬於值得重點看的開源方案。

01 RAGFlow 解決什麼問題

普通 RAG 系統最容易遇到的問題有三個：

文件解析品質不穩定，尤其是 PDF、掃描件、表格、圖片、複雜排版文件。
切分策略不透明，命中結果看起來像是「搜到了」，但上下文並不完整。
回答缺少可靠引用，使用者很難判斷答案來自哪裡。

RAGFlow 的重點正好放在這些地方。專案 README 裡強調了 Deep document understanding、模板化切分、可視化 chunk、引用溯源和多路召回加重排。換句話說，它更關注「高品質資料進入，高品質答案輸出」，而不是只把向量資料庫和聊天框接起來。

02 核心功能

1. 深度文件理解

RAGFlow 支援從複雜格式的非結構化資料中抽取知識。README 中列出的資料類型包括 Word、PPT、Excel、TXT、圖片、掃描件、結構化資料、網頁等。

這對企業知識庫很關鍵。真實資料通常不是乾淨的 Markdown，而是合約、報告、表格、掃描 PDF、產品手冊、截圖和網頁混在一起。如果解析品質不夠，後面的向量檢索和 LLM 回答都會被拖垮。

2. 模板化切分

RAGFlow 提供模板化 chunking。它的價值在於：切分策略不是黑盒，可以根據文件類型選擇更合適的方式。

例如普通文章、論文、表格、問答文件、圖片說明、合約條款，對 chunk 的粒度和邊界要求都不一樣。模板化切分可以減少「句子被切碎」「表格上下文丟失」「標題和正文分離」這類問題。

3. 可追溯引用

RAGFlow 強調 grounded citations，也就是回答要能追溯到來源片段。它還提供 chunk 可視化，方便人工干預解析和切分結果。

這點對生產環境尤其重要。企業內部問答不是只要「看起來像答案」，還要能查證來源。對於政策、合規、財務、技術文件、客戶支持資料來說，引用和溯源幾乎是剛需。

4. 自動化 RAG 工作流

RAGFlow 把 RAG 流程做成相對完整的鏈路：

建立知識庫
上傳或同步資料
解析文件
查看和干預 chunk
配置 LLM 與 embedding 模型
執行多路召回與重排
建立聊天助手
透過 API 整合到業務系統

這讓它更像一個 RAG 平台，而不是單點工具庫。對團隊來說，UI、可視化和 API 都有價值：非研發人員可以維護知識庫，研發人員可以把能力接入既有系統。

5. Agent、MCP 與工作流能力

RAGFlow 的近期更新裡已經包含 Agentic workflow、MCP、Agent Memory、程式碼執行元件等內容。這說明它不只想做傳統知識庫問答，也在向 Agent 場景延伸。

典型方向是：Agent 在執行任務時，可以把 RAGFlow 作為可靠的企業知識上下文層；需要查資料時從知識庫召回，生成回答時保留引用，必要時再組合工具呼叫或工作流。

03 基本使用流程

按照官方快速開始文件，RAGFlow 的常見使用路徑可以概括成下面幾步。

1. 準備執行環境

官方 README 給出的基礎要求是：

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

如果要使用程式碼執行器的沙箱功能，還需要 gVisor。另外要注意，官方 Docker 映像主要面向 x86 平台；如果是 ARM64，需要依照官方說明自行建置映像。

2. 拉取專案

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. 檢查 `vm.max_map_count`

RAGFlow 部署會依賴 Elasticsearch / OpenSearch 這類元件，因此在 Linux 上通常需要確認：

`1`	`sysctl vm.max_map_count`

如果數值低於 262144，可以暫時設定：

`1`	`sudo sysctl -w vm.max_map_count=262144`

如果希望重開機後仍然生效，需要寫入 /etc/sysctl.conf。

4. 使用 Docker Compose 啟動

CPU 模式可以直接啟動：

`1`	`docker compose -f docker-compose.yml up -d`

如果要用 GPU 加速 DeepDoc 任務，README 中給出的方式是在 .env 中啟用 DEVICE=gpu 後再啟動：

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

啟動後查看日誌：

`1`	`docker logs -f docker-ragflow-cpu-1`

看到服務啟動完成後，再透過瀏覽器訪問伺服器地址。預設配置下，通常可以直接訪問：

`1`	`http://IP_OF_YOUR_MACHINE`

5. 配置模型 API Key

RAGFlow 需要配置 LLM 和 embedding 模型。README 提到可以在 service_conf.yaml.template 中選擇預設 LLM factory，並更新對應的 API_KEY。

實際使用時，你需要根據自己的模型供應商配置：

聊天模型
embedding 模型
rerank 模型
多模態模型（如果要理解 PDF / DOCX 中的圖片）

6. 建立知識庫並上傳文件

服務啟動後，典型操作是：

登入 Web UI。
建立 dataset / knowledge base。
上傳文件或配置資料源同步。
等待解析完成。
查看 chunk 結果，必要時人工調整。
建立聊天助手，選擇知識庫。
測試問答效果和引用來源。

如果要接入業務系統，可以繼續使用 RAGFlow 的 API 或 SDK，把知識庫檢索和聊天能力接到自己的應用裡。

04 適合哪些場景

RAGFlow 適合這些需求：

企業內部知識庫問答
產品手冊、技術文件、FAQ 檢索
客服助手和售前支持助手
合約、報告、制度文件的可追溯問答
多格式資料統一整理
需要 UI 維護知識庫，同時又要 API 整合的團隊
想把 RAG 能力作為 Agent 上下文層的系統

它尤其適合文件格式複雜、需要引用溯源、希望人工干預解析結果的場景。

05 使用時要注意什麼

第一，RAGFlow 不是輕量腳本。它對機器資源有要求，官方建議至少 4 核 CPU、16GB 記憶體和 50GB 磁碟。如果只是給少量 Markdown 做問答，可能沒必要上這麼完整的平台。

第二，文件品質仍然重要。RAGFlow 能改善解析和切分，但不能讓低品質、過期、互相矛盾的資料自動變得可靠。真正上線前，知識庫治理仍然要做。

第三，模型配置會直接影響效果。embedding、rerank、聊天模型、多模態模型的選擇，都會影響召回和回答品質。RAGFlow 提供了工作流，但效果仍然要靠資料、模型和參數一起調。

第四，生產環境要關注權限和資料安全。企業知識庫裡往往有內部資料，部署方式、訪問控制、日誌、API Key、模型供應商資料策略都要提前設計。

06 簡短判斷

RAGFlow 的優勢在於把 RAG 裡最麻煩的部分做成了平台化能力：複雜文件解析、可解釋切分、引用溯源、多路召回、重排、模型配置、Web UI、API 和 Agent 擴展。

如果你要做的是可驗證、可維護、可接入業務系統的企業知識庫，RAGFlow 比「向量庫 + 簡單聊天 UI」的方案更完整。反過來，如果只是個人小規模資料問答，或者資料格式非常簡單，輕量 RAG 框架可能更省資源。

知識庫 on KnightLi的博客

RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法

01 RAGFlow 解決什麼問題

02 核心功能

1. 深度文件理解

2. 模板化切分

3. 可追溯引用

4. 自動化 RAG 工作流

5. Agent、MCP 與工作流能力

03 基本使用流程

1. 準備執行環境

2. 拉取專案

3. 檢查 `vm.max_map_count`

4. 使用 Docker Compose 啟動

5. 配置模型 API Key

6. 建立知識庫並上傳文件

04 適合哪些場景

05 使用時要注意什麼

06 簡短判斷

相關連結

知識庫 on KnightLi的博客

RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法

01 RAGFlow 解決什麼問題

02 核心功能

1. 深度文件理解

2. 模板化切分

3. 可追溯引用

4. 自動化 RAG 工作流

5. Agent、MCP 與工作流能力

03 基本使用流程

1. 準備執行環境

2. 拉取專案

3. 檢查 vm.max_map_count

4. 使用 Docker Compose 啟動

5. 配置模型 API Key

6. 建立知識庫並上傳文件

04 適合哪些場景

05 使用時要注意什麼

06 簡短判斷

相關連結

3. 檢查 `vm.max_map_count`