RAGFlow：领先开源 RAG 与 Agent 融合引擎

RAGFlow：以深度文档理解为基座的 RAG 引擎

它是什么

RAGFlow 是 InfiniFlow 开源的一套检索增强生成（RAG）引擎，官方描述它为"把前沿 RAG 与 Agent 能力融合、为 LLM 构建更优上下文层"的工具。换成更直白的说法：它不是一个模型，也不是一个单纯的向量数据库，而是一条从"原始文档"到"可被大模型可靠引用"的完整流水线——负责把文件解析干净、切成合适的片段、存进可检索的索引，再在提问时把最相关的证据找出来交给大模型作答。

它出现的原因在于，RAG 落地时真正难的部分往往不在生成端。很多方案的文档处理环节非常粗暴：把 PDF 当纯文本硬切，遇到多栏排版、跨页表格、扫描件、图注就会产生大量噪声；切完之后既无法解释、也无法回溯，检索自然不准，大模型只能靠"编"来补全答案。RAGFlow 的差异化切入点是深度文档理解（deep document understanding）：先在解析与分块阶段把文档结构还原出来，让后续的检索和生成建立在可解释的切片之上。项目以 Apache-2.0 协议开源，主要部署形态是容器化自托管，同时也提供云端托管版本。

核心功能 / 内容清单

深度文档理解与模板化切分：针对 PDF、Word、Excel、PPT、图片、扫描件、网页等异构输入，借助版面分析与表格识别把内容按语义单元还原；同时允许选用或自定义分块模板（chunk template），使切分结果可解释、可逐项调优，而不是切完就只能接受黑盒结果。
带引用的回答（grounded citation）：生成答案时同步给出所依据的原文片段，并在界面上把切片与引用位置可视化。这直接回应了"幻觉不可追溯"的问题——答案从哪来一目了然，也便于人工抽检和纠错。
多路召回配合融合重排：把向量检索与关键词／全文检索等路径并行使用，再对候选结果做融合与重排序。单一向量检索在专有名词、编号、条款号这类查询上容易漏召，多路补充正是为了覆盖这类场景。
可替换的模型配置：LLM 与 Embedding 模型均可配置，支持对接自建或第三方模型服务，便于团队按成本、语言能力和数据合规要求做取舍，而不被单一供应商锁死。
Agent 与工作流编排：在检索之上叠加 Agent 能力，把检索、工具调用、多步推理串成可编排的流程，用于处理"一次检索答不完"的复合任务。
面向集成的 API：对外提供接口，供业务系统调用知识库检索与问答能力，便于把 RAG 能力嵌进既有产品而不是另起一个孤岛系统。

典型使用场景

企业内部知识库问答。 当公司把制度文档、产品手册、会议纪要、历史工单分散在网盘和 Wiki 里，员工检索靠关键词命中率很低。典型做法是：在 RAGFlow 中建立对应的知识库，按文档类型选择解析与分块模板，配置好 embedding 模型完成索引；之后员工用自然语言提问，系统返回带原文出处的答案。因为答案附带引用，业务方可以自己判断可信度，而不用每次都找文档维护者确认。

长文档密集型的专业问答。 合同、研报、标书、专利这类文档的特点是篇幅长、表格多、条款交叉引用频繁。RAGFlow 的价值在于把表格和标题层级当作结构信息保留下来，而不是压成一长串文本——这样"某条款的违约责任怎么写的""这份年报里研发投入的变化"这类需要定位到具体片段的问题才有稳定答案，同时每条回答都能回溯到原文位置，方便交付给需要复核的岗位。

需要审计与合规留痕的客服／支持场景。 在金融、医疗、法务等对"答案有据可查"有硬性要求的领域，答案必须能指向权威来源。把 RAGFlow 的可视化引用与 API 接进现有客服或工单系统，可以让回复既快又留有依据，降低合规风险。

适合谁用

企业 IT 与平台团队：需要一套可自托管、数据不出内网的知识库底座，并希望有界面给业务方直接用，而不是只交付一套 SDK。
AI 应用与算法工程师：需要一个可调参、可替换模型的 RAG 框架来快速验证检索效果，并把精力放在分块策略与召回优化上，而不是从零搭解析管线。
产品与业务侧负责人：评估 RAG 方案能否支撑自家文档形态时，可以用它做一轮接近真实数据的可行性验证。
不太适合：只想调一个托管 API、不愿承担任何部署与运维成本的个人开发者；以及文档格式极其单一、已有成熟检索方案且无引用追溯需求的团队——引入完整引擎的收益可能有限。

快速上手

主路径是容器化部署：获取仓库代码后进入 Docker 相关目录，用 Docker Compose 拉起全部服务，随后通过浏览器访问本机服务端口进入 Web 界面（默认走 80 端口）。启动后一般需要查看服务日志确认各组件就绪，再到界面里完成模型配置、创建知识库、上传文档并等待解析索引完成，最后在对话界面或通过 API 发起提问。

由于涉及多个后端组件与模型下载，首次启动耗时较长，建议预留足够的机器资源并保持网络通畅。具体的镜像标签、目录结构、环境变量与端口映射，以官方 README 为准；版本迭代过程中这些细节可能变化，照抄旧教程容易踩坑。

注意事项

资源要求不低：完整的解析、索引与检索链路需要多核 CPU、较大内存与充足磁盘空间，官方 README 对 CPU 核数、内存、磁盘及 Docker／Docker Compose 版本都给出了最低要求，部署前应逐条核对，否则容易出现服务起不来或解析中途失败。
首次启动依赖网络：需要拉取容器镜像和模型文件，网络受限环境要先做好镜像与模型的离线准备。
解析质量取决于文档本身：扫描件、手写体、复杂版式的识别效果受 OCR 与版面模型能力制约，清晰度差的文档仍可能出错，重要场景建议抽样人工校验分块结果。
分块策略需要调：模板化切分是优势也是工作量来源，直接使用默认配置未必适配自家文档，投入一些时间试不同模板通常能明显改善召回。
协议与依赖：项目本身为 Apache-2.0，允许商用与修改，但所接入的第三方模型、Embedding 服务以及 Docker 镜像内的其他组件各有其许可与使用条款，商用前应逐一确认。
版本演进较快：接口与界面在版本间可能有调整，升级前建议先看 Release 说明并做好数据备份；自托管与云端版本在功能与配置上也可能存在差异，注意区分对应文档。