RAGFlow:基于深度文档理解的 RAG 引擎

一、一个做知识库的同事，被「垃圾回收站式的 PDF」整破防了

我有个同事在做企业知识库，把几百份产品手册、合同、扫描版 PDF 丢进向量库做问答，结果用户一问「这张表格第三行写的啥」，模型就开始瞎编。他复盘发现：问题不在模型，在于那些 PDF 是多栏、带表格、甚至是扫描件，普通切分直接把一段话从中间切断，检索到的压根不是完整语义。后来他换了 RAGFlow——一个主打「深度文档理解」的开源 RAG 引擎，同样那批 PDF，问答准确率肉眼可见上去了。他说最爽的是：终于不用自己写一堆解析规则去伺候各种奇葩排版。

RAGFlow 是 infiniflow 开源的检索增强生成引擎，slogan 就是「基于深度文档理解的 RAG」。它和普通「文档→切块→向量化→问答」的最大区别，在于切块之前先做了一层文档结构理解：识别标题层级、表格、图片、多栏布局，甚至对扫描件做 OCR，再据此切成「语义完整」的块。上层再接任意主流大模型当生成器。

二、它和「LangChain + 向量库」差在哪

LangChain 是「胶水框架」，你要把解析、切块、检索、生成自己拼起来，切块质量全看你写的规则。RAGFlow 把「解析 + 切块」这层做成了开箱即用的能力，你只管喂文档、选模型、问问题。简单说：LangChain 给你乐高，RAGFlow 给你一台调好的机器。

三、拆开看：一份 PDF 是怎么变成「能问答」的

流水线分四段。第一，解析：用文档理解模型把 PDF/Word/扫描件还原成结构化元素（段落、表格、标题、图），扫描件先过 OCR。第二，智能切块：不是按字数硬切，而是按语义边界切，表格整块保留、跨页不断开。第三，向量化检索：块进向量库，问问题时召回最相关几块。第四，生成：把召回内容塞给大模型（OpenAI、DeepSeek、Qwen、Ollama 等任选）出答案，并附带引用来源。它这两年还加了 Agentic RAG——检索不再是一步到位，而是让 Agent 多轮分解问题、交叉验证，再给最终答案，对付「对比 A 和 B 差异」这类复合问题明显更稳。

它进过 GitHub Octoverse 榜单，社区活跃度在那摆着，文档和示例也跟得上。对中文用户友好的一点：内置对中文排版、中文模型的适配，喂一堆中文合同也能正常解析，不用自己额外折腾分词。

举个最典型的坑：一份财报 PDF，左边文字、右边带数字的表格，还跨了三页。普通切块常把表格从中间切断，检索时只召回半句，模型自然答错。RAGFlow 会先把表格识别成完整块、保留行列结构再单独切块，问「第二季度营收多少」能精确命中那张表。这种「先理解、再切」的代价是解析更慢、更吃资源，但换来的是检索质量——对真实文档，这步省不得。它还能按文档类型选不同解析策略（论文、法律文书、网页各有侧重），不是一套参数打天下。

四、踩坑提醒：这几条先记好

1. 它是一个完整应用，不是轻量库。 比起在代码里 import 一个 RAG 函数，RAGFlow 更像一个要部署的服务，体积和资源占用都不小。

2. 解析模型吃资源。 深度文档理解依赖模型推理，纯 CPU 能跑但慢，量大建议上 GPU；docker 镜像本身也不小，拉取要点时间。

3. 生成环节仍要 API Key。 RAGFlow 只管检索，最终回答用的是你配的大模型，Key 和费用还是你的。

4. 别神话它。 源文件本身模糊、缺页，它也没法无中生有；喂干净文档，效果才对得起这套解析。

5. 检索质量也看嵌入模型。 解析再好，向量化用的 embedding 模型拉胯，召回照样差。中文场景优先选对中文友好的嵌入模型，别默认用英文那套。

五、想试？Docker 一条命令起

官方最稳的方式是拉仓库起编排：

适合谁？要做企业/个人知识库问答、吃大量非结构化文档（手册、合同、研报、扫描件）的团队。我的建议：先拿你最头疼的那几份「破 PDF」丢进去对比效果，如果回答质量明显比现有方案稳，再考虑把它接进正式流程。RAG 的成败，七分在解析、三分在模型——RAGFlow 的价值，正好是把那七分替你做扎实了。

最后给个选型判断：如果你的文档干净、结构单一（纯 Markdown、规整 CSV），普通 LangChain 方案就够了，不值得为 RAGFlow 的体量买单；但凡你要对付扫描件、多栏 PDF、带表格的合同研报，直接上 RAGFlow，省下的调试时间远超部署成本。它免费的社区版对绝大多数个人和中小团队已经够用，先把「问答准不准」这件事验证通，再谈接不接入生产。

如果你的目标是把检索能力嵌进自己的产品，RAGFlow 也提供 Python / HTTP API，可以当服务调用，不必非走 Web 界面；前端只管问、后端只管答，中间那套复杂的解析与切块完全不用你碰。对开发者来说，这比从零拼一套文档管线省的事，不止一点半点——你拿到的是一个调好的「文档理解引擎」，而不是一堆要自己调参的零件。这层抽象，正是它作为「引擎」而非「玩具」的价值所在。