很多團隊第一次做 RAG 時，都以為最難的是選哪個向量資料庫、embedding model 或 chunk size。
真正上線後才會發現，麻煩通常不在那裡。麻煩在於你的資料根本不是乾淨文字。它可能是掃描 PDF、合約、財報、PPT、Excel、表格、圖片、跨頁段落、頁首頁尾、奇怪標題、被 OCR 切碎的句子，以及一堆需要保留來源、頁碼、欄位和引用的內容。這些東西如果一開始就被切爛，後面的 rerank、prompt、agent workflow 再漂亮也只是幫壞資料化妝。
這也是 RAGFlow 現在值得看的原因。
根據官方 GitHub 與文件，RAGFlow 把自己定位成基於 deep document understanding 的開源 RAG engine，目標是把複雜格式資料轉成能被 LLM 可靠使用的上下文，並提供有根據引用的問答能力。到 2026-07-12 早上查詢 GitHub API 時，infiniflow/ragflow 約有 84.8k stars、9.9k forks，Apache-2.0 授權，repo 在 2026-07-11 仍有 push，最新 release v0.26.4 於 2026-07-07 發布。這不是一個停在 demo 的 RAG 專案，而是一個正在高速補企業資料接入、文件解析、Agent、MCP、API 與多語系細節的開源系統。
先講結論：RAGFlow 很值得現在看，尤其是那些已經被「文件品質」而不是「模型能力」卡住的團隊。 它的價值不只是幫你更快做一個知識庫聊天，而是把 RAG 裡最髒、最常被低估的前半段，也就是 ingestion、解析、chunking、citation 和上下文治理，變成一個比較完整的工作流。
但另一面也要先講清楚：RAGFlow 不是輕量小工具。 如果你的資料只有幾十篇乾淨 Markdown，或只是想做一個內部 demo，它可能太重。你可能用 LlamaIndex、Haystack、Dify、LangChain 加一個向量庫就夠了。RAGFlow 更像是當你開始面對「文件真的很醜，但答案又必須可信」時，才會顯出價值的那種工具。
English TL;DR
- RAGFlow is an open-source RAG engine focused on deep document understanding, grounded citations, ingestion workflows, APIs, and agent capabilities.
- Its strongest value is not another chat UI, but turning messy enterprise documents into traceable, retrieval-ready context.
- It fits teams dealing with PDFs, tables, scanned files, multi-source knowledge bases, and RAG systems that need citations and human inspection.
- It is less suitable for lightweight demos, small clean datasets, or teams that already have a mature custom RAG platform.
- Adoption judgment: consider RAGFlow when document quality, traceability, and ingestion workflow have become your bottleneck.
RAGFlow 是什麼？
如果用一句話講，RAGFlow 是一個開源 RAG engine，重點放在把複雜文件變成可檢索、可引用、可被 AI agent 使用的上下文層。
這句話裡最重要的不是 RAG，而是「文件變成上下文」。
官方 README 把 RAGFlow 描述成融合 RAG 與 Agent capabilities 的 context layer。官方 quickstart 則更務實：它是一個基於 deep document understanding 的 RAG engine，搭配 LLM 後，可以從複雜格式資料中提供有來源引用的問答能力。這個定位其實很清楚，它不是單純的 vector database，也不是純 agent framework，而是站在兩者中間：先把資料處理好，再讓模型和 agent 有比較可靠的上下文可用。
RAGFlow 目前的主線能力大致可以拆成幾塊。
第一，是文件理解與解析。它內建的 DeepDoc 模組談 OCR、layout recognition、table structure recognition，並特別處理 PDF、DOCX、Excel、PPT 這些實務上最麻煩的格式。DeepDoc README 裡直接列出 layout components，例如 text、title、figure、table、header、footer、reference、equation 等，也談到 table structure recognition 會處理 column、row、column header、spanning cell 這些表格結構。這比單純「把 PDF 抽成文字」更接近真正的文件 AI。
第二，是可解釋的 chunking 與 citation。RAGFlow 強調 template-based chunking、human intervention、quick view references、traceable citations。這點很關鍵，因為很多 RAG 系統失敗不是因為沒有召回，而是召回結果不可讀、不可查、不可回頭修。
第三，是資料源、API 與產品化能力。近期 release notes 可以看到 BigQuery connector、Outlook、OneDrive、Teams、Slack、SharePoint、Salesforce、Azure Blob Storage 等企業資料源；HTTP API 文件也提供 OpenAI-compatible chat completion endpoint、dataset / document / chunk 操作、metadata filter、reference metadata 等能力。這些不是純展示功能，而是企業導入時會真的需要的接縫。
第四，是 Agent 與 MCP。官方 README 的 latest updates 提到 agentic workflow、MCP、code executor、Memory、chat channels；release notes 裡也能看到 MCP server、agent API、browser component、外部聊天 channel、Langfuse trace grouping 等更新。這代表 RAGFlow 的方向已經不只是「問知識庫」，而是把 RAG 當成 agent 的 context engine。
為什麼現在值得看？
2024 到 2025 很多 RAG 專案的核心問題是「能不能做出來」。到 2026，問題正在變成「能不能維持可信、可調、可營運」。
RAGFlow 現在值得看的第一個原因，是它剛好打中這個轉折。企業知識不是一包乾淨文字。它會從 Google Drive、Slack、SharePoint、Salesforce、S3、Notion、Discord、資料庫、PDF 和掃描件來。每個來源有不同格式、權限、更新節奏和失敗型態。如果工具只幫你做 embedding，那其實只解了整條鏈的一小段。
RAGFlow 的 recent releases 很能反映這個現實。v0.26.0 加了多個企業資料 connector，也改善模型供應商設定；v0.26.2 補 WhatsApp、DingTalk、WeCom chat channels，處理大型 datasets 分頁；v0.26.3 加 BigQuery connector、MCP tools、SoMark OCR parser、customized ingestion pipeline endpoint；v0.26.4 則修 Docling parser 遺失數學公式、MCP server pagination、metadata inline edit 等細節。這些更新看起來很雜，但雜得很真實，因為 RAG 一旦進入正式環境，本來就會撞到各種文件、資料源、UI、API、channel 和 parser 細節。
第二個原因，是 agent 浪潮讓「上下文層」變得更重要。
如果 AI agent 只能操作乾淨資料，它的價值會被限制在 demo。真正的工作流會要求 agent 看文件、查規範、讀客戶紀錄、引用來源、產生可追溯回覆，甚至根據文件內容再觸發後續動作。這時候，RAG 系統不再只是 chatbot 的附屬功能，而會變成 agent 能不能安全做事的基礎設施。
RAGFlow 把自己描述成 context layer，這個詞比「知識庫」更準。知識庫比較像儲存；context layer 則暗示資料要被轉換、組織、引用、查詢、檢查，最後交給模型或 agent 使用。這也是它和一些更輕量 RAG library 的差別。
第三個原因，是開源 RAG 工具正在分層。
LlamaIndex、Haystack、LangChain 更像開發框架；Milvus、Weaviate、Chroma、LanceDB 更像資料儲存與檢索層；Dify 更偏 AI app platform；Docling、MarkItDown、Unstructured 更偏文件解析或 ingestion component。RAGFlow 的定位比較像把「文件理解 + RAG workflow + API + agent context」收成一個可自架平台。這種整合度會讓它比較重，但也讓它在某些企業場景更有吸引力。
先看成長曲線：RAGFlow 已經不是小眾實驗
GitHub stars 當然不能直接等於產品成熟度，但它很適合看一件事：這個專案是否正在進入更多團隊的評估清單。RAGFlow 目前的星數與更新頻率，代表它已經不是一個偶爾被 Local RAG 社群提到的工具，而是被更多企業 AI、文件 AI、agent infra 團隊拿來比較的候選平台。
真正要看的不是 stars 本身，而是 stars 背後的需求：越來越多人發現，RAG 不是把資料丟進向量庫就結束。文件解析、引用、metadata、資料源同步、API、權限、channel、agent integration，這些才是長期維運會讓人頭痛的地方。
適合誰？
第一種，是被複雜文件格式卡住的團隊。
如果你的資料有大量 PDF、掃描件、表格、合約、手冊、論文、財報、簡報與 Excel，RAGFlow 會比純文字導向的簡單 pipeline 更值得看。尤其是表格、頁首頁尾、跨頁段落、figure caption、公式、章節結構這些東西，會直接影響 retrieval 品質。
第二種，是需要 citation 與可追溯回答的產品。
客服、法務、金融、醫療、內部政策、技術支援都很在意「答案從哪裡來」。如果系統只回一段看起來很合理的話，卻無法點回文件來源，那就很難進入正式流程。RAGFlow 對 reference、chunk visualization、citation 的重視，是它相對有價值的地方。
第三種，是想把 RAG 變成 agent context layer 的團隊。
如果你的下一步不是只做問答，而是要讓 agent 查資料、生成文件、走工作流、接 MCP 或外部 channel，那 RAGFlow 的平台式路線會比較貼近需求。它不一定是最輕，但它把很多後續會遇到的東西先放進同一個框架裡。
第四種，是沒有足夠人力自建整套 RAG 平台，但又不想完全依賴 SaaS 的團隊。
RAGFlow 可以 self-host，授權也是 Apache-2.0。對需要資料留在自己環境、又想要有 UI、API、workflow 和資料源接入的團隊，它是一個可評估的折衷方案。
不適合誰？
第一種，是只想做很小的 RAG demo 的人。
如果資料只有十幾篇 Markdown、幾份乾淨 PDF，或者只是要做內部 proof of concept，RAGFlow 的部署與概念負擔可能太高。這時候用 LlamaIndex、Haystack、LangChain、Chroma 或一個簡單的 Dify app 會更快。
第二種，是已經有成熟自建 RAG stack 的公司。
如果你們已經有自己的 ingestion pipeline、document parser、metadata schema、vector search、reranker、eval、observability、權限控管和內部工具，RAGFlow 不一定能直接取代。導入它反而要評估遷移成本、資料模型差異和既有平台重疊。
第三種，是期待一套工具直接解決所有 hallucination 的團隊。
RAGFlow 強調 citation 和 deep document understanding，但這不等於答案永遠正確。RAG 系統仍然會受到資料品質、chunking 策略、檢索設定、reranking、prompt、模型能力、權限與評估流程影響。工具能降低壞上下文的機率，但不能替代產品層的驗收。
第四種，是沒有基本 infra 能力的團隊。
官方 self-hosting prerequisites 寫得很實際：CPU 至少 4 cores、RAM 至少 16GB、Disk 至少 50GB、Docker / Compose、Python 3.13；若要使用 code executor sandbox 還需要 gVisor。再加上 Docker image 目前針對 x86 平台，ARM64 需要自己 build。這不是打開一個 npm package 就結束的工具。
具體場景一：法務或合約知識庫
合約 RAG 最怕的不是沒有答案，而是答案看起來對，但引用錯段。
假設公司要做一個內部法務助理，讓業務查詢合約條款、付款條件、違約責任、保密義務和續約規則。資料可能是 PDF、掃描件、Word、不同版本的合約範本，還有附表與跨頁條款。這時候普通「PDF 轉文字 + embedding」很容易把條文切壞，甚至把頁首頁尾、章節編號和表格拆成干擾訊號。
RAGFlow 在這個場景的價值，是它把文件解析、layout、table、chunk visualization、citation 放在主線裡。法務同仁或產品 PM 可以回頭看 chunk 怎麼切、引用哪一段、錯誤是否來自文件解析，而不是只能盯著模型輸出猜原因。
但這裡也要有現實感。法務場景不能只靠 RAGFlow 本身就上線。仍然需要權限控管、文件版本治理、答案免責、人工覆核、回饋流程與測試集。RAGFlow 可以當 context engine，不應該被當成法律判斷的替代品。
具體場景二：企業內部客服與 IT 支援
第二個很適合的場景，是企業內部客服或 IT support。
這類知識通常散在 Confluence、SharePoint、Slack、Teams、PDF 手冊、FAQ、系統操作文件、舊 ticket 和部門公告裡。使用者問的問題也不乾淨：「VPN 連不上」、「報銷怎麼跑」、「某個客戶權限打不開」、「新同仁帳號要開哪些系統」。如果資料源不同步，或引用不清楚，回答很快就會失去信任。
RAGFlow 近期補了多個企業資料 connector 和 chat channels，這使它比較容易從「知識庫」走到「工作入口」。例如內部 IT 可以把常見操作文件與系統公告接進 dataset，再透過 chat channel 讓同仁在既有聊天工具裡提問；回答附上引用，遇到文件缺漏時再回頭修資料。
這類場景的重點不是讓 AI 一次解決所有問題，而是降低第一線支援的重複問答量，並把「找不到答案」變成改善知識庫的信號。RAGFlow 的 chunk 和 reference 可視化，對這個迴路有幫助。
具體場景三：產品文件與技術支援 agent
第三個場景，是面向開發者或客戶的產品技術支援。
很多 SaaS 公司文件越來越多，API reference、release notes、migration guide、FAQ、SDK docs、issue workaround、pricing rules 全部散在不同地方。客服或 support engineer 常常不是不知道答案，而是不知道最新答案在哪裡。
RAGFlow 可以把這些資料做成一個可追溯的技術支援 layer，再透過 API 或 OpenAI-compatible endpoint 接到自家產品後台、客服系統或 agent workflow。它不只回覆文字，還能帶 reference metadata，讓前端顯示來源、版本或文件章節。
這對技術支援很重要。因為客戶不只要答案，也要知道答案是不是來自最新文件、哪個版本、哪個 API 端點。若回答錯誤，團隊要能追到是文件過期、chunk 切錯、metadata filter 沒設好，還是模型生成時偏掉。
限制與缺陷：RAGFlow 強，但不是無痛
第一個限制，是它的系統重量。
RAGFlow 的優勢來自整合，但整合也帶來部署與維運成本。Docker、資料庫、文件解析、模型供應商、embedding、reranker、storage、API、UI、channel、MCP，這些東西放在一起，就不是一個可以隨手塞進既有 app 的小 library。團隊要先想清楚：自己要的是平台，還是只要某個 pipeline component。
第二個限制，是文件解析永遠有長尾。
DeepDoc、Docling、MinerU、SoMark、OCR parser 這些能力可以降低痛苦，但世界上的文件格式不會乖乖配合。掃描品質、奇怪表格、手寫註記、雙欄排版、嵌入圖片、數學公式、跨頁表格都可能出問題。從 v0.26.4 修 Docling parser 遺失公式這類 bug 就能看出，這條路本來就會長期和文件邊界搏鬥。
第三個限制，是 RAGFlow 不替你完成 eval。
它能提供引用、chunk、API 和 workflow，但「這樣的回答能不能上線」仍然需要測試集、golden questions、人工標註、回歸測試、線上監控。RAG 系統最怕看起來可用，但在關鍵問題上信心過高。導入 RAGFlow 時，最好同步設計 eval，而不是等上線後才靠使用者回報錯誤。
第四個限制，是平台路線會帶來替換成本。
一旦你把資料源、dataset、chunking、metadata、chat assistant、agent workflow 都放進 RAGFlow，以後要換出來就不是簡單換一個 package。這不是缺點，而是所有平台型工具的代價。採用前要確認團隊願意把哪一層交給它。
採用判斷：什麼時候該認真評估 RAGFlow？
比較務實的判斷是：當你的 RAG 失敗主要來自資料與文件上下文，而不是模型不夠強，RAGFlow 就值得認真評估。
如果你們現在的痛點是 PDF 切爛、表格讀錯、引用不清楚、資料源太多、知識庫更新麻煩、agent 找不到可信上下文，那 RAGFlow 很可能比單純換模型更有幫助。
如果你們只是想快速做 demo、資料很乾淨、工程團隊想完全掌控每個 component，或目前還沒有正式 RAG 維運需求，那先用更輕的框架會比較合理。
採用上可以用三步走：
第一步，不要一開始就全量導入。先挑一個文件最髒、但業務價值明確的 dataset，例如合約、手冊、支援文件或內部政策。
第二步，測解析和引用，不要只測回答。看 RAGFlow 如何處理表格、頁碼、公式、標題、metadata、chunk 邊界，並要求每個答案都能追來源。
第三步，補 eval 和治理。把常見問題、邊界問題、錯誤案例整理成測試集，再決定是否把更多資料源與 agent workflow 接進去。
RAGFlow 的重點不是讓 RAG 看起來更炫，而是提醒一件比較樸素的事：LLM 的答案品質，很大一部分取決於你餵給它的上下文品質。 當 AI agent 開始真的進工作流，這層上下文工程會變得越來越像基礎設施，而不是 chatbot 的附屬品。
參考資料
- RAGFlow GitHub: https://github.com/infiniflow/ragflow
- RAGFlow 官方文件 Quickstart: https://ragflow.io/docs/
- RAGFlow release notes: https://github.com/infiniflow/ragflow/blob/main/docs/release_notes.md
- RAGFlow DeepDoc README: https://github.com/infiniflow/ragflow/blob/main/deepdoc/README.md
- RAGFlow HTTP API reference: https://ragflow.io/docs/dev/http_api_reference
- RAGFlow roadmap issue: https://github.com/infiniflow/ragflow/issues/12241