RAGFlow 强在哪？扫描件与复杂版式的文档理解
数据截至 2026-07，价格与限额以各官网为准。
RAGFlow 的差异化不在检索环节，而在检索之前那一步——把文档真正读明白。它是一个开源 RAG 引擎，强项是深度文档理解：分块尊重文档结构，带版面感知的解析，还内置了知识图谱构建。如果你的语料是扫描版 PDF、财报、版式复杂的法律文书这类传统文本解析器搞不定的东西，它值得优先试；如果你的语料本来就是干净的 Markdown 和网页，它的优势基本用不上。
先承认一个很常见的误解：很多人把 RAG 效果不好归因于”嵌入模型不行”或者”没上重排”，于是一路折腾向量库、换嵌入、加 rerank，效果依然半死不活。实际情况往往是——问题出在更前面。文档进系统的时候就已经被切碎成一堆没有上下文的碎片，表格被拉成一行行错位的文字，页眉页脚混进正文，扫描件干脆什么都没提取出来。后面所有的检索优化，都是在给一堆本来就错的内容排序。RAGFlow 想解决的正是这一段。
一、先把”解析”和”检索”当成两个独立的瓶颈
选 RAG 框架最实用的方法，不是看谁名气大，而是先判断自己卡在哪一环。一个可以直接照着做的分诊表：
- 瓶颈在解析（烂 PDF、表格、扫描件）——从 LlamaIndex（LlamaParse）或者 RAGFlow 入手。
- 瓶颈在检索（嵌入、混合检索、重排）——LangChain、Haystack、Cognita 这类可调的旋钮最多。
- 瓶颈在评估（说不清改动到底有没有变好）——不用换框架，在你已有的框架上加挂 RAGAS。
- 语料是有链接关系的结构化内容——考虑图检索，RAGFlow 的 GraphRAG 就属于这一类。
怎么判断自己属于哪一类？有个成本很低的土办法：把你的文档喂进现有管线，然后直接打印出被切出来的分块原文，人工读十条。如果你自己读这十条都拼不出原意——表格散架、序号断裂、一句话被从中间劈开——那问题在解析，换嵌入模型没用。反过来，如果分块读起来都通顺，只是问答时召回的那几条不对题，那才是检索的问题。
这一步的判断成本可能就半小时，但它决定了你接下来几周是不是白忙。
二、版面感知解析：RAGFlow 想解决的核心问题
普通的文本抽取，本质上是把 PDF 里的字符按流的顺序倒出来。对一篇单栏、纯文字的文档，这样做没问题。但真实企业语料往往不长那样：
双栏排版的研究报告，字符流会把左栏一行和右栏一行交替吐出来，读起来完全是乱码级的错位。财报里的三线表，表头和数值在字符流里彻底失去对应关系，“营业收入”和后面那串数字可能相隔几百个字符。法律文书的多级条款编号、脚注、批注，混在正文里没有任何标记区分。合同的骑缝章页、封面页、目录页，全都当成正文一起塞进去。
所谓版面感知解析，做的是另一件事：先识别这一页上有哪些区块——标题、正文段落、表格、图片、页眉页脚——再按区块的语义顺序去组织文本，而不是按字符在文件里的物理顺序。表格被当成表格处理，页眉页脚可以被剔除，标题层级可以保留下来。
这直接决定了下一步分块的质量。RAGFlow 的分块策略是尊重文档结构的：一个章节不会因为凑够了 500 个字符就被从中间切开，一张表不会被拦腰截断成两个互不相干的片段。切出来的每一块，本身是一个语义完整的单位。
对最终效果的影响是很直接的：检索命中的那一块，如果本身就是完整的一节或一张完整的表，模型看到它就能答；如果是半截话，模型只能靠猜，然后你就得到一个听起来很流畅的错误答案。
三、扫描件为什么是分水岭
扫描版 PDF 是个特殊物种：文件后缀是 PDF，但里面其实只有图片，一个可提取的文字都没有。很多团队第一次撞上这个坑的表现是——管线跑完了，没报错，知识库里却什么都查不到，因为入库的内容是空的。
这里给两条可以马上执行的排查动作：
- 拿一份代表性文档，在 PDF 阅读器里试着选中一段文字。选不中、只能框选出一个方块，那就是扫描件。
- 用你现有的解析代码抽一遍，打印字符长度。几十页的文档抽出来只有几百个字符，基本可以确定绝大部分内容没进来。
处理扫描件要做的事情比纯文本多一层：先识别出图上的文字，再判断这些文字在页面上的位置关系，才能还原出段落和表格。RAGFlow 把这套能力做进了引擎里，这也是它被推荐用于扫描版 PDF 这类语料的原因。
需要诚实说明的局限：任何一套方案在扫描件上都不是百分之百准确。纸张倾斜、印章盖住文字、手写批注、复印多代之后的糊字，都会掉识别率。合理的预期是”把不可用变成大部分可用”，而不是”完全准确”。真正涉及金额、条款这类不容出错的字段，稳妥做法是在答案里带上原文出处，让人能翻回原页核对，而不是让模型直接下结论。
四、知识图谱检索适合什么语料
RAGFlow 内置了知识图谱构建能力。这个功能不是万能加分项，它有明确的适用面。
向量检索的逻辑是”找语义最像的片段”。碰到一类问题它天然吃亏：答案不在任何单独一块里，而是要把散落在多处的信息串起来。比如”这家子公司的实际控制人在集团里还担任哪些职务”，人名、职务、公司关系可能分布在三份不同的文档里，任何单独一块都答不全。
图检索的思路是先把实体和它们之间的关系抽出来，检索时沿着关系走，把相关的几跳内容一起带回来。语料本身是有链接的结构化内容时——组织架构、股权关系、产品与部件的从属、法规条款之间的引用——这条路的收益比较明显。
也要说清代价：构建图谱要对全量语料做一遍实体和关系抽取，这一步既费时间也费 token，语料一更新还得增量维护。如果你的问答大部分是”某个概念是什么""某项流程怎么走”这种单点查询，纯向量检索就够用，先别急着开图谱，等确实撞到多跳问题再上。
五、自托管：两种镜像和向量库搭配
RAGFlow 走 Docker 部署，官方提供两种镜像：slim 约 2GB 和 full 约 9GB，区别在于是否内置嵌入模型。
怎么选：
- 你已经有自己的嵌入服务，或者打算调用外部嵌入 API——用 slim，省下的这几 GB 拉取时间和磁盘空间是实打实的。
- 你要的是开箱即用、机器不能出外网、也不想再单独部署一个嵌入服务——用 full。
顺带说一句对照关系：LangChain 和 LlamaIndex 是库，不是服务，所谓”自托管”其实就是你自己跑 Python 进程加一个向量库，没有现成的镜像可拉。RAGFlow 是引擎形态，附带低代码界面来编排 RAG 工作流，这是两种不同的产品形态，别拿”部署难度”直接比较。
向量库这边常见的搭配是 Qdrant，它支持过滤、payload 索引和量化，可以作为独立二进制或者 Docker 容器运行。第三方口径称它在 100 万级以上向量规模下能做到 50ms 以内的检索，这是第三方基准的说法，不是官方指标，实际表现跟你的硬件、量化配置、过滤条件都有关系，务必自己压一遍。向量库怎么挑，可以看向量数据库怎么选这篇。
数据必须留在内网的，就选可自托管的这一类；只想尽快看到效果、不介意搭建环境托管在平台上的，低代码平台能省掉大量部署成本，这是两种不同的取舍，没有谁对谁错。
六、什么情况下不该选 RAGFlow
不打包票，也得把不适用的场景说全：
语料本来就干净。 你的知识库是 Markdown 文档、Confluence 导出、网页正文，文本抽取根本不是问题。这时 RAGFlow 最值钱的那部分能力没有用武之地，你需要的是在检索层多调参数。
你要做的是复杂 agent 循环。 需要多轮工具调用、条件分支、状态回溯的场景，LangChain 这一侧的 chains 和 agents 生态、以及配套的监控接入更成熟，代价是学习曲线更陡。有评测指出 LangChain 的 LCEL 语法能做复杂的查询重写，但相比 LlamaIndex 的直接检索会多出约 15-20% 的延迟开销——这是第三方基准的口径，不是官方数据，你的实际链路结构不同，数字也会不同。想了解 agent 化检索的思路，可以看什么是 Agentic RAG。
你要的是深度 ingestion 连接器和高级索引策略。 LlamaIndex 是数据优先的定位，RAG 专用的原语更贴身；LangChain 的生态更广，但抽象层带来的开销也更高。
你只是想先跑通一个最小可用版本。 拉 9GB 镜像、部署引擎、配置向量库，这套流程对验证”这个需求到底值不值得做”来说太重了。先用几十行代码跑个最简管线看看效果，再决定要不要上工程化方案。
七、别把 star 数当选型依据
一组常被引用的数字：截至 2026 年 1 月的 GitHub star 排名是 LangChain 约 125,000、Dify 约 114,000、RAGFlow 约 70,000、LlamaIndex 约 46,500、Haystack 约 24,000。这些数字来自第三方整理，当前的实际数值以各项目仓库页面为准。
要强调的是：star 数只反映关注度，不代表适用性。LangChain 起步最早、覆盖面最广，star 自然最高，但这不意味着它在扫描件解析上会比 RAGFlow 更合适。你要解决的是自己那批文档的问题，不是给排行榜投票。
同样值得说的是，这些项目不是互斥的。生产环境里一种常见组合是：LlamaIndex 做 ingestion 与索引，LangChain 做编排，LangGraph 做 agent 工作流。同理，你完全可以让 RAGFlow 负责难啃的那批文档，把结果并入你已有的检索链路，不必二选一。各项目的版本能力变化较快，具体功能与部署要求以各项目官方文档当前版本为准。
八、一条可以照着走的验证路径
给一个成本可控的顺序，避免一上来就重构整条管线：
- 挑 5 到 10 份最难啃的代表性文档——最花哨的那份财报、最模糊的那份扫描合同，不要挑最干净的。
- 用现有管线跑一遍，把分块结果打印出来人工读，确认瓶颈到底在解析还是检索。
- 如果确实是解析，用 Docker 起一个 RAGFlow 实例（不确定要不要内置嵌入就先拉 slim），同样这几份文档过一遍，对比分块质量。
- 准备 20 到 30 个有标准答案的真实业务问题，两套管线各跑一次，人工判对错。这一步不能省，凭感觉判断”好像好一点”是最容易自欺的环节。
- 效果确认后再谈规模化，包括向量库选型、增量更新、权限隔离。企业级落地的整体考量可以参考企业 AI 知识库怎么搭建。
对 RAG 的基本原理还不熟悉的话，建议先补一下RAG 是什么，再回来看框架选型，会顺很多。
小结
RAGFlow 的价值集中在文档理解这一段：版面感知的解析、尊重文档结构的分块、可选的知识图谱构建，对扫描件、财报、复杂版式法律文书这类语料针对性明确。选它之前先做一件事——打印分块结果，确认你的瓶颈真的在解析，而不是在检索。自托管有 slim 约 2GB 与 full 约 9GB 两种镜像，区别是是否内置嵌入模型，按你有没有现成嵌入服务来挑。star 数只说明关注度，跟你的语料合不合适没有关系。最后，这些项目可以混着用，让 RAGFlow 处理最难啃的那部分文档，往往比整条链路推倒重来更划算。