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. 拉取專案
|
|
3. 檢查 vm.max_map_count
RAGFlow 部署會依賴 Elasticsearch / OpenSearch 這類元件，因此在 Linux 上通常需要確認：
|
|
如果數值低於 262144，可以暫時設定：
|
|
如果希望重開機後仍然生效，需要寫入 /etc/sysctl.conf。
4. 使用 Docker Compose 啟動
CPU 模式可以直接啟動：
|
|
如果要用 GPU 加速 DeepDoc 任務，README 中給出的方式是在 .env 中啟用 DEVICE=gpu 後再啟動：
|
|
啟動後查看日誌：
|
|
看到服務啟動完成後，再透過瀏覽器訪問伺服器地址。預設配置下，通常可以直接訪問：
|
|
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 框架可能更省資源。
相關連結
- GitHub 專案：https://github.com/infiniflow/ragflow
- 官方文件：https://ragflow.io/docs/dev/
- 線上 Demo：https://cloud.ragflow.io