RAGFlow 值不值得折腾，取决于你的文档是不是真的“难啃”。它是 InfiniFlow 在 GitHub 上开源的 RAG 引擎，主打深度文档解析：扫描版 PDF、带表格和版式的文档、图文混排的材料，都能先被拆解成带结构的片段再入库，回答时附上引用。你的知识库如果只是少量干净的纯文本网页，解析能力用不上，折腾的意义就小得多。
官方仓库信息写清在正文里：平台是 GitHub，组织名是 InfiniFlow，项目名是 RAGFlow，许可证是 Apache 2.0。系统由多个容器组成：RAGFlow 本体负责界面、接口和任务执行，Elasticsearch 或 Infinity 做文档引擎，MySQL 存元数据，Redis 排队解析任务，对象存储放上传文件。模型要自己接，1.0 开源版里解析用的 DeepDoc 走 CPU 推理，负责版式分析、OCR 和表格识别。
部署成本：先按推荐配置起步
官方给出的推荐起步配置是 4 核 CPU、16GB 内存、50GB 磁盘，Docker 24.0.0 以上、Docker Compose v2.26.1 以上。部署路径是拉取仓库后进入 docker 目录，用 Docker Compose 启动预构建镜像；用 Elasticsearch 时宿主机要把 vm.max_map_count 设到 262144 以上。预构建镜像目前只提供 x86 版本，ARM64 机器要留意官方说明。实际开销随文档量、解析任务数和并发走，批量解析扫描件时 CPU 是瓶颈，第一次跑先拿几十份真实文档做全流程测试，再定正式配置。
真实坑点有四处。第一，解析质量依赖文档本身，扫描模糊、表格跨页、版式特殊的材料要先抽检，解析错了再调分块也救不回来。第二，模型要自己配，聊天、向量、重排三个模型选错，回答质量和成本一起出问题，部署前先定好来源和计费。第三，多容器栈的运维是持续成本，升级、备份、磁盘清理都要有人管，只想“装一次就不管”的人容易在几个月后遇到无人维护的旧版本。第四，回答附引用不等于引用一定对，涉及合同、合规材料的场景要抽查原文，权限隔离也要按实际组织结构配置。
适合的人是：手头有大量 PDF、扫描件、表格文档，需要可追溯回答的团队或个人开发者。不适合的人是：文档少、格式干净、只想快速搭个问答 demo 的人，用更轻的方案或托管服务更快；以及没有运维时间、希望开箱即用的人，解析能力再强，也补不上没人管的运维缺口。先用云端服务试解析效果，确认过关再自托管。
