RAGFlow 深度評測：功能、部署與自建 RAG 取捨指南

AI
, ,
1

RAGFlow 是專為複雜文件設計的開源 RAG 平台。這篇完整評估涵蓋 DeepDoc 文件理解、混合檢索、Agent 工作流程、自架步驟與實務社群的真實反饋，並與自建 LangChain 方案比較，幫助你判斷是否值得導入企業知識庫場景。

一分鐘結論

評估項目 判斷
最強場景 複雜 PDF、表格、掃描文件、企業知識庫、法律與財務文件
主要優勢 DeepDoc 文件理解、可視化 chunking、hybrid retrieval、引用追蹤、Agent workflow、MCP
主要缺點 系統重量較高、自架複雜、文件 ingestion 較慢、local model 整合仍需工程工作
適合誰 想快速建立企業 RAG 產品、又不想自行整合 parser、search、reranker 與 UI 的團隊
不適合誰 只需要輕量 local RAG、希望完全掌控 vector database，或只想 import 一個 Python library 的開發者
總評 值得實際 benchmark；尤其適合「文件結構比純語意更重要」的資料，但不應直接假設它在所有 corpus 都優於自建 pipeline

RAGFlow 是什麼

RAGFlow 是由 InfiniFlow 維護的開源、端到端 RAG 與 Agent 平台。與 LangChain 或 LlamaIndex 這類嵌入 Python 專案的 library 不同，RAGFlow 更像一個可部署的企業級產品：它包含前端、後端、資料處理、搜尋引擎、儲存服務與管理介面，並將以下能力整合在同一系統中：

  • 文件上傳與資料集管理
  • PDF、DOC、DOCX、PPT、PPTX、XLS、XLSX、CSV、圖片、掃描文件與網頁解析
  • OCR、版面辨識、表格結構辨識
  • 基於模板的 chunking
  • 稠密向量搜尋與 BM25 全文檢索
  • 多重召回與融合重排序
  • LLM、embedding model、image-to-text model 設定
  • 可檢視與人工修改 chunk 的 UI
  • 附來源與引用的回答
  • Chat app 與 HTTP/Python API
  • Visual Agent workflow 與 MCP（Model Context Protocol）

官方將其定位為「AI Agent 的上下文層」（context layer for AI agents），提供經過解析、檢索、排序與引用驗證的上下文，而不只是傳統問答機器人。

核心技術能力

1. Deep Document Understanding

一般 RAG pipeline 常見流程為：

textPDF → extract text → split text → embed → vector search

RAGFlow 的 DeepDoc 則企圖處理成：

textPDF / scanned document
text  → OCR → layout recognition → headings / paragraphs / tables / images → structure-aware chunking → hybrid retrieval → reranking → cited generation

這對以下文件特別有價值：

  • 多欄位 PDF
  • 表格跨頁的財務報告
  • 有標題層級與章節結構的技術文件
  • 掃描版合約與法律文件
  • 圖文混合的產品手冊
  • 表格欄列關係對答案有直接影響的資料

使用者可以檢視解析後的 chunks，並手動增加關鍵字或修改內容，以改善特定查詢的排名。

2. Template-based Chunking

RAGFlow 不只用固定的 recursive character splitting，而是根據資料型態選擇不同 chunking template，讓文件的標題、段落、表格與語意區塊能在 ingestion 階段保留下來。

優點：可解釋性高——當答案品質不佳時，工程師能直接查看文件被切成什麼樣子，而非只調整不可見的 chunk size 參數。

缺點：較複雜的 parser 與 chunking pipeline 通常會增加 ingestion 時間與 CPU/GPU 使用量。許多 production 使用者提到，RAGFlow 在複雜文件上的 retrieval precision 較好，但需要更多資源，且 parsing latency 明顯高於簡單的 recursive chunking。

3. Hybrid Retrieval

檢索流程包含：

  • Vector search
  • BM25 全文檢索
  • Custom scoring
  • Multiple recall
  • Fused reranking

這種設計對企業資料特別重要，因為純向量搜尋容易遺漏 SKU、股票代號、法條編號、合約編號、API endpoint、產品型號、人名與特殊縮寫。BM25 補足精確字串匹配，vector search 處理語意相似度，兩者結合理論上更適合企業知識庫。實際效果仍取決於 embedding model、索引設定、query rewriting、reranker 與資料品質。

4. 可追蹤引用

RAGFlow 的回答可帶有來源 chunk 與引用，並可回看原始資料，適合法律研究、財務分析、內部政策問答、技術支援與需要 audit trail 的企業應用。不過「有 citation」不代表回答一定正確，仍需要建立 evaluation dataset 檢查 citation correctness、context precision、context recall 與 answer faithfulness。

5. Agent 與 MCP

RAGFlow 已擴展至 Agentic workflow 與 MCP，支援多模態文件處理、code executor、外部資料同步與多種聊天管道。可想像的 workflow：

text使用者問題 → 判斷問題類型 → 搜尋內部 dataset → 呼叫外部 MCP tool → 執行資料整理或程式計算 → rerank context → 產生附引用的回答

官方展示了股票研究、法律 precedent analysis、設備維護指引等 workflow，產品方向已從「RAG chatbot」擴展到「企業資料 Agent 平台」。

系統架構與部署

自架所需資源

  • x86 CPU，至少 4 cores
  • RAM 至少 16 GB
  • Disk 至少 50 GB
  • Docker 24.0.0 以上
  • Docker Compose v2.26.1 以上
  • Python 3.13 以上
  • 使用 code executor 時需要 gVisor
  • Elasticsearch 或 Infinity 作為文件引擎
  • MinIO、Redis、MySQL 等服務參與部署

啟動前需將 vm.max_map_count 設定為至少 262144，否則 Elasticsearch 可能啟動失敗。

官方提供的預建 Docker image 主要針對 x86，尚未提供 ARM64 版本；在 Apple Silicon Mac 上通常需要自行 build image。

Apple Silicon Mac 注意事項

  • 可透過 Docker Desktop 嘗試 ARM64 build，但官方 image 不保證可直接使用。
  • x86 emulation 可能造成效能與相容性問題。
  • 大型文件 ingestion 不應以 MacBook Docker Desktop 作為 production environment。
  • 建議準備 x86 Linux VM 或雲端主機（如 Hetzner、AWS）進行長期測試。

合理的架構：

textMacBook Pro → 本地開發、API 整合、workflow 設計
textx86 Linux server → RAGFlow、Elasticsearch/Infinity、MinIO、Redis、MySQL
textExternal or local LLM provider → chat、embedding、reranker、image-to-text

若需要 code executor，應將 sandbox 與主服務隔離，並以 gVisor 限制任意程式碼執行。

自架流程

最簡化的部署流程：

bash
git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker
git checkout v0.26.4
docker compose -f docker-compose.yml up -d

啟動後需要：

  1. 確認 container 已完成初始化
  2. 進入伺服器 IP 開啟管理介面
  3. 設定 LLM provider（chat model、embedding model、image-to-text model）
  4. 建立 dataset
  5. 上傳文件
  6. 選擇 chunking template
  7. 執行 parsing
  8. 檢查與人工修正 chunks
  9. 建立 chat 或 Agent workflow

注意：dataset 一旦使用某個 embedding model 解析文件，通常不能直接改成另一個 embedding model，因為同一 dataset 必須維持在同一 embedding space。更換 embedding model 時，需重新建立索引與重新解析資料。

雲端與商業模式

RAGFlow 同時提供 hosted cloud service，方案概覽：

方案 Apps Team members Dataset storage Credits API key
Free 5 1 0.1 GB 500 / month 不提供
Starter 50 5 5 GB 5,000 / month 提供
Pro Unlimited 20 50 GB 20,000 / month 提供
Enterprise 客製 客製 BYOC / on-premise 客製 提供

商業模式可理解為：

  • 開源 self-hosted：適合資料敏感、需要控制基礎設施的企業。
  • Hosted cloud：適合快速驗證與不想維護基礎服務的團隊。
  • Enterprise / BYOC：適合需要私有化、SLA、專屬支援與內網部署的公司。

實務社群觀察

社群對複雜文件解析的興趣很高，但實際部署體驗存在分歧。

正面觀察：

  • UI 相對完整且容易理解
  • 對 PDF layout 與 table recognition 有潛力
  • Apache-2.0 license 具有商業採用彈性
  • 內建 ingestion、retrieval、chat 與 citation，減少自行拼裝元件的工作
  • 對複雜文件的 retrieval precision 明顯優於一般 recursive chunking

常見疑慮：

  • Docker stack 服務數量較多，Elasticsearch 本身需要資源
  • OCR 與 layout analysis 增加 ingestion latency
  • 大量文件時需要獨立擴充 parsing workers 與 query services
  • Query latency 受 Elasticsearch 或 Infinity 配置影響
  • 完全 local 的 OCR、embedding、LLM pipeline 不是開箱即用
  • 早期版本設定 local model 不夠直覺，需要額外工程調整
  • 早期 Docker 啟動階段曾出現警告訊息，後續版本已修正

關鍵提醒：

  • 不要使用 nightly 作為 production 部署，應固定 stable tag
  • 將 docker-compose.yml、.env、資料 volumes 與版本一起備份
  • 升級前先在 staging 環境 restore backup
  • 確認 image、entrypoint 與 source code 版本一致

RAGFlow 與自建 RAG 的取捨

面向 RAGFlow 自建 LangChain / LlamaIndex pipeline
上手速度 UI 與元件完整，較快建立 prototype 初期需要自行整合
文件解析 強調 layout、OCR、table 可自由選擇 Unstructured、Docling、MinerU、LlamaParse 等
Search 內建 vector + BM25 + reranking 自行決定 Elasticsearch、OpenSearch、Qdrant、pgvector 等
Agent 內建 visual workflow、MCP 方向 彈性高，但 orchestration 需自行維護
可控性 平台規範較多 每個 pipeline 元件都能替換
Debug 可透過 UI 看 chunk，但底層較複雜 程式碼與 logs 更容易客製化
Infrastructure 需要完整服務 stack 可做成較輕量的單體服務
Local model 可行但可能需要設定 通常更容易直接指定 endpoint
Scaling 需要理解 parsing/query worker 分離 可根據 workload 自由設計
商業化 適合快速包裝 enterprise RAG 適合打造高度差異化產品
最適合 複雜文件與快速產品化 需要極致控制、低延遲或特殊 workflow

如何測試 RAGFlow

建議建立一個小型但具代表性的 evaluation set：

文件集合

  • 10 份純文字文件
  • 10 份多欄 PDF
  • 10 份含跨頁表格的財報或報表
  • 10 份掃描文件
  • 10 份法律、政策或合約文件
  • 10 份圖文混合技術手冊

問題集合

每種文件設計：

  • Exact lookup questions
  • Multi-hop questions
  • Table aggregation questions
  • Cross-document questions
  • Negative questions（資料中沒有答案的問題）
  • Citation verification questions
  • 多輪追問

需要記錄的指標

指標 目的
Context precision 檢索結果是否大多相關
Context recall 是否找得到真正需要的內容
Answer faithfulness 回答是否只根據 context
Citation correctness 引用是否真的支持答案
No-answer accuracy 沒有資料時是否拒答
P50/P95 latency 一般與尾端延遲
Ingestion throughput 每小時能處理多少頁或文件
Resource usage CPU、RAM、GPU、disk
Manual correction rate 需要人工修正多少 chunks

建議 baseline 比較

textRAGFlow vs Markdown/PDF parser + recursive chunking + pgvector/Qdrant vs Elasticsearch hybrid search + custom reranker

若目標是企業知識庫場景，可加入：

textRAGFlow + external reranker RAGFlow + local embedding RAGFlow + Ollama RAGFlow + Claude/OpenAI

結論

RAGFlow 最值得研究的地方不是它是不是另一個 RAG framework，而是它試圖把複雜文件理解、混合檢索、引用、Agent 與 MCP 統一成一個可部署平台。對財務報告、法律文件、技術手冊與企業內部文件，它的方向明顯比單純的 PDF → text → embeddings pipeline 更合理。

但社群也揭示了重要限制：RAGFlow 需要較多基礎設施資源，ingestion 速度較慢，local model 整合與部署體驗曾不夠順暢，而且在簡單文件上未必勝過較精簡的自建 RAG pipeline。

適合採用的情境：

  • 客戶文件格式混亂
  • PDF 與表格是主要資料來源
  • 需要在 UI 中檢查與修正 chunk
  • 需要可追蹤引用
  • 希望快速交付一個企業 RAG MVP
  • 不想自行維護 parser、全文搜尋、vector search、reranker 與管理 UI
  • 需要進一步加入 Agent workflow 與 MCP
  • 具備 x86 Linux、Docker 與 Elasticsearch 維運能力

不建議直接採用的情境：

  • 只有 Markdown 或純文字資料
  • 只需要一個小型 local chatbot
  • 目標是極低 latency
  • 需要完全使用自訂 vector database
  • 想將 RAG 嵌入現有應用程式而非部署獨立平台
  • 需要在 Apple Silicon 上直接使用官方 image
  • 團隊沒有能力維護 Elasticsearch、資料 volumes 與 Docker service stack
  • 需要完全 air-gapped、所有元件 local 且希望零設定

把 RAGFlow 當成複雜文件 RAG 的候選 production platform，而不是無條件取代自建 RAG 的萬用解決方案。建議以固定版本 v0.26.4 部署到 x86 staging server，使用自己的真實文件建立 benchmark；若它在 table recall、citation correctness 與人工修正成本上明顯勝過既有 pipeline，再考慮將其包裝成企業知識庫或 Agent backend。