RAGFlow 是 InfiniFlow 推出的开源文档 RAG 引擎，重点不是通用聊天或跨应用自动化，而是把 PDF、Word、演示文稿、表格、扫描件和网页等资料解析、切分、索引，再以可追溯引用回答问题。它适合文档结构复杂、需要检查证据的知识库项目；Agent 与工作流能力是扩展项，不能替代数据清理、权限设计和检索评测。
快速结论
如果失败原因主要是复杂版面解析差、表格被切碎、引用无法核对，RAGFlow 值得优先做小规模试点。它提供可视化分块、模板化解析、多路召回与重排，并能自托管。若需求是跨 SaaS 执行业务动作，应比较 n8n；若想用更轻的应用平台搭知识助手，可看 Dify；若核心是跨文档关系与全局主题发现，则比较 GraphRAG。
核心功能
- 深度文档理解：处理复杂版面及多种文件类型，解析结果仍应抽样检查，尤其是扫描质量差、合并单元格和页眉页脚密集的资料。
- 可解释分块：按文档类型选择模板并可视化查看文本块，允许人工干预，而不是把所有文件机械地按固定字符数切开。
- 检索与重排：支持关键词、向量等多路召回和融合重排；效果取决于嵌入模型、阈值、分块与真实查询分布。
- 引用与知识库：回答可关联命中文本，方便核对；引用存在不代表结论必然正确，仍要评测引用是否真的支持答案。
- 模型与接口：可配置生成和嵌入服务，通过 API、SDK 接入业务应用，并提供 Agent、摄取流程和连接器能力。
- 知识图谱选项：可用于实体关系增强，但会增加抽取、索引、调参与维护成本，不应默认对所有语料启用。
适合人群
- 处理合同、研报、手册、招投标文件或扫描资料的知识工程团队。
- 要求回答展示原文证据、支持人工核验的客服、法务和研究场景。
- 希望在自有基础设施中管理文档、索引和模型凭据的企业。
- 愿意维护解析规则、测试集、权限过滤和索引更新流程的开发团队。
- 不适合只要消费级聊天助手，或没有人负责文档治理的组织。
使用场景
典型场景包括内部政策问答、产品手册客服、合同条款检索、研究资料归纳和文档审阅辅助。上线前要用真实问题建立评测集，覆盖无答案、过期文件、冲突版本、表格、图片、跨页段落和权限不同的用户。指标至少包含解析正确率、检索召回、引用支持率、拒答、延迟和单次查询成本。
RAGFlow 更像文档知识基础设施，而不是审批系统。涉及退款、发信、修改订单或发布内容时，应由业务工作流设置确定性校验和人工批准，不要让检索答案直接触发高风险动作。
价格与版本
社区代码采用 Apache 2.0 许可，可免费自托管。官方同时提供 RAGFlow Cloud；云端额度、容量与收费可能调整，应在控制台或销售材料中核对，不记录未经确认的固定套餐。自托管也不是零成本：文档解析、OCR、嵌入、重排、生成调用、对象存储、搜索引擎、备份和运维都会产生费用。
索引通常是成本高峰。首次导入和频繁重建会重复消耗解析、嵌入或图谱抽取资源；查询成本则受召回候选、重排深度和生成上下文长度影响。试点应分别记录每千页索引成本、增量更新时间和每百次查询成本。
国内访问与使用体验
ragflow.io、GitHub 与自托管服务在中国大陆的实际可达性应按团队网络测试，needsVPN: false 只表示产品并非必须依赖受限海外 SaaS。连接哪个模型或外部数据源，会改变网络、合规和延迟条件。
官方仓库当前建议 Docker Compose，自托管基线为至少 4 核 CPU、16 GB 内存、50 GB 磁盘，并要求较新的 Docker；官方预构建镜像主要面向 x86，ARM64 需按文档自行构建。生产环境还要配置搜索/向量引擎、数据库、对象存储、密钥、TLS、备份、监控和升级回滚。默认可用不等于完成生产加固。
文档权限尤其关键。应在摄取时保留来源、租户和 ACL 元数据，在每次检索时按当前用户过滤，并测试用户离职、文件撤权和索引删除是否及时生效。仅把服务部署在内网，不能自动防止越权召回。
优点
- 产品主线聚焦真实企业文档，解析、分块检查、检索和引用形成完整闭环。
- Apache 2.0 社区版可自托管，模型与基础设施选择较灵活。
- 支持多种文件与异构来源，适合从原型扩展到持续摄取流程。
- 引用与分块可视化便于定位“解析错、召回错还是生成错”。
- 项目更新活跃，文档、SDK、Agent 和连接器能力持续扩展。
不足
- 组件较多，自托管的内存、存储、监控和升级负担高于轻量 RAG 库。
- 复杂文档解析并非万能，OCR、表格和专业排版仍需人工抽检。
- 索引、重排和生成的总成本容易被“开源免费”掩盖。
- 权限同步、删除传播和多租户隔离需要团队自行验证与设计。
- 功能迭代快，生产升级应锁定版本并阅读发布说明。
替代品对比
| 工具 | 更适合 | 与 RAGFlow 的关键区别 |
|---|---|---|
| Dify | 低代码构建聊天应用、Agent 和工作流 | 应用编排更直接；RAGFlow 更强调复杂文档解析与检索基础层 |
| GraphRAG | 全局主题总结和跨文档关系发现 | 是研究方法与 Python 管线，不是完整文档知识库产品 |
| LangChain | 代码优先、自定义检索与 Agent 架构 | 组合自由度高，但解析、后台和运营能力需自行组装 |
| n8n | 跨系统自动化和 AI 执行流程 | 侧重触发器、连接器与动作，不以深度文档解析为核心 |
常见问题 FAQ
RAGFlow 是向量数据库吗？
不是。它是包含摄取、解析、分块、检索、生成与应用接口的 RAG 引擎，会使用搜索或向量存储组件。
开源版可以商用吗？
社区仓库标注 Apache 2.0。商用前仍应由法务检查许可证文本、依赖许可、商标和所接模型条款。
自托管后数据就绝对安全吗？
不会。自托管提供位置控制，但密钥、日志、备份、外部模型调用、漏洞修复和检索 ACL 都需要独立治理。
它能完全正确解析扫描 PDF 和表格吗？
不能保证。应按文件类型分层抽样，检查 OCR、阅读顺序、表格结构、脚注与跨页内容，并保留人工修正流程。
为什么索引成本可能很高？
解析、OCR、嵌入、可选图谱抽取与摘要都可能调用计算或模型服务；重建索引会重复这些工作。先小批量估算再扩容。
RAGFlow 和 GraphRAG 应如何选择？
复杂文档摄取、引用问答优先试 RAGFlow；全局主题和关系推理可试 GraphRAG。两者也可组合，但复杂度和成本会叠加。
总结
RAGFlow 的核心价值是把“文档怎样被读入、切开、找回并引用”变成可运营的系统。它适合证据要求高、文档版面复杂且有工程团队维护的项目。采购或上线前，先以权限隔离的真实语料完成小规模索引，记录解析、召回、引用、延迟和总成本，再决定是否扩大范围。