写于2025年8月

结论先行（给忙人看的几点）

1. 要做“拿来即用的企业 RAG 平台（含可视化、工作流、权限/多应用管理）”

• 首推 Dify（插件生态+工作流最成熟、矢量库选择最多、上手门槛最低）；
• RAGflow 在复杂文档解析（表格/版面/OCR/图文）与可解释/可视化切块方面优势明显，适合知识库复杂、文档质量参差的客服/流程场景；并且与 Infinity 数据库配合可做多路混合检索+RRF/ColBERT 式重排来提升准确率与吞吐。

1. 要做“深度可定制、工程化、和现有后端强集成”的，选LangChain(+LangGraph)/LlamaIndex/Haystack更合适（它们是库而不是成品平台）。

• LangChain+LangGraph 在Agentic RAG/状态机编排/可回溯检查点上最灵活；多种Ensemble/多查询/重排组件齐全。
• LlamaIndex 在分层切块/父子节点合并/路由检索/多模态索引很强，适合需要“检索质量微调”的团队。
• Haystack 提供可视化/代码化的流水线（Pipeline）与交叉编码器重排，工业级稳健。

1. 多模态能力

• RAGflow：深度文档理解（图、表、扫描件）走的是解析→结构化→可视化切块路线；并在 2025 年开始引入多模态模型理解 PDF/DOCX 内图片。
• Dify：在工作流节点中启用 Vision 模型（如 GPT-4 系列等）即可做图像理解，但文档结构化深解析更多依赖上游 Loader/第三方。
• LlamaIndex/LangChain：均可用多模态模型与多向量/多索引方案支撑图文混合检索。

综上所述，对当前的 Keep 知识库业务来说，目前只面向 C 端用户，知识种类及数量不多，且大多数为结构化的知识，不涉及深度文档理解，Dify 完全足以胜任。如果将来考虑投入资源单独搭建一个 RAG 系统，同时面向内部外部使用（比如内部规章制度、客服知识等），知识的类别与结构都比较多样化，那 RAGFlow 更加合适。 反之，如果在当前业务状况下，或者不考虑做综合性的RAG系统，使用RAGFlow是成本大于收益的。原因有如下几点： 硬件成本：部署RAGFlow需要开通单独的服务器，还要部署MinIO、ES、Infinity、Redis、MySQL等前置依赖项目，对于目前 C 端每天约 600-800 条的提问量来说，属于硬件资源的浪费； 用户体验：当前的技能都是基于 Dify 构建，如果 Dify 与 RAGFlow 通过 API 通信，加大时间成本，降低用户体验，如果将 WIKI 技能迁到 RAGFlow 上，反而造成整个 Agent 调用技能时候的复杂性，得不偿失； 公司收益：针对当前的数据量与业务来说，从 Dify 内置的 RAG 系统迁到 RAGFlow 效果提升不大，因为 RAGFlow 主要是针对复杂文本和非结构化数据做了很多优化，用在当前 Keep 的知识库上属于“大炮打蚊子”，就像一道可以用简单方法解决的数学题非要用微积分来无限逼近精确答案，带来的提升可能只有0.1，开销却翻了十倍。 如果考虑单独建立RAG系统，内部外部同时使用，替代掉一些客服知识库、商城知识库之类的系统，那就另当别论。

也可以用一套组合拳：以 Dify 做企业统一“应用与工作流”外壳，部分知识库用 RAGflow 构建/清洗后接入为外部 KB；前台统一在 Dify 内路由到不同 KB/服务。这样既保留 Dify 的生态与低门槛，又利用 RAGflow 的强解析与可解释性，但是会牺牲一些速度上的体验。这样做的好处是先投入较小的成本来观察效果的改善，效果不好可以及时止损，也不会影响现有业务。

一、从RAG的前世今生谈起

如果你已经对 RAG 技术的发展了如指掌，请跳过这部分内容

1. Naive RAG

2020年10月，Meta团队在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中首次定义Naive RAG架构，确立了”索引-检索-生成”三阶段流程：

• 索引（Indexing）：索引首先清理和提取各种格式的原始数据，如 PDF、 HTML、 Word 和 Markdown，然后将其转换为统一的纯文本格式。为了适应语言模型的上下文限制，文本被分割成更小的、可消化的块（chunk）。然后使用嵌入模型将块编码成向量表示，并存储在向量数据库中。这一步对于在随后的检索阶段实现高效的相似性搜索至关重要。
• 检索（Retrieval）：在收到用户查询（Query）后，RAG 系统采用与索引阶段相同的编码模型将查询转换为向量表示，然后计算索引语料库中查询向量与块向量的相似性得分。该系统优先级和检索最高 k （Top-K）块，显示最大的相似性查询。这些块随后被用作 prompt 中的扩展上下文。
• 生成（Generation）：提出的查询（Query）和选定的文档（Chunks）被合成为一个连贯的提示，大语言模型负责生成回复。

2. Advanced RAG

Advanced RAG 的雏形源于对 Naive RAG（索引→检索→生成）的局限性突破。早期研究者发现单纯依赖向量检索存在 语义鸿沟 （如用户提问模糊或需多跳推理时检索失效）和 信息冗余 （检索结果重复或无关）等问题。为此，Meta、微软等团队开始探索全流程优化框架，提出检索前预处理 、检索后精炼以及Embedding模型优化等方向。

预索引优化

• 多粒度分块策略：引入滑动窗口分割、语义分块等策略，解决长文本切分导致的语义断裂问题（如将文档按段落、章节动态划分）
• 引入元数据：把元数据嵌入块中提升检索效率（标题、摘要、作者、时间、实体信息）
• 混合索引：结合 BM25关键词匹配与向量语义检索，平衡精确召回与语义理解能力。
• 假设性问题：让LLM为每个块生成一个问题，保存问题与文本块的映射关系，将这些问题存入向量数据库中。在检索时，先基于向量问题数据库进行查询搜索，找到相似问题后，然后在检索后路由到原始文本块，并将它们作为上下文发送给LLM以获得答案。这种方法通过查询与假设性问题之间更高的语义相似性，提高了搜索质量。
• HyDE（Hypothetical Document Embeddings）：通过逆向逻辑方法，让LLM给定查询生成一个假设性回应，然后使用其向量和查询向量来提高搜索质量。

后索引优化

• ReRank：重新排序以将最相关的信息重新定位到提示的边缘是一个简单的想法。
• Prompt Compression：重点在于压缩不相关的上下文，突出关键段落，并减少整体上下文长度。删减非关键内容，保留语义核心，从而在不影响模型表现的前提下，降低推理成本。

Embedding

• Fine-tuning Embedding：微调的目的是增强检索内容和查询之间的相关性。通常，微调嵌入的方法分为在特定领域上下文中调整嵌入和优化检索步骤。特别是在处理进化或稀有术语的专业领域，这些定制的嵌入方法可以提高检索相关性。
• Dynamic Embedding：动态嵌入根据单词出现的上下文进行调整，不同于为每个单词使用单个向量的静态嵌入，理想情况下，嵌入应该包含尽可能多的上下文，以确保“healthy”的结果。

查询转换

• 查询转换利用LLM作为推理引擎来修改用户输入，以提高检索质量。对于更复杂的用户查询，可以基于LLM将其进行子查询拆解，分别得到子查询的关联上下文信息后整合到一起提供给LLM生成初始复杂问题的最终答案。当涉及到多轮上下文对话中，如果利用历史对话补齐当前对话信息完整性，以实现更准确的信息检索同样涉及到查询转换。

3. Modular RAG

Modular RAG是RAG范式的又一演变，强调灵活性、多样化和定制化。ModularRAG通过将检索和生成流程分解为独立、可重用的组件，实现了针对特定领域的优化和任务适应性。

技术特点

• Modular RAG 将传统 RAG 系统的线性流程拆分为 独立可插拔的模块 （如检索器、预处理器、生成器等），每个模块专注于特定功能（如查询优化、混合检索、生成控制），支持像“乐高积木”一样自由组合，比如今天用向量检索+BM25，明天改成Graph RAG+多模态检索，只需要换模块，不动其他部分。
• 动态流程编排能力：通过路由（Routing）、调度（Scheduling）和知识图谱融合机制，实现多路径检索与智能决策。
  • 线性编排：整个RAG流由各个Module线性串联起来，为最简单的模式。

• 条件编排(Conditional Pattern)：RAG流中会添加一些Route条件判断，增强系统的灵活性。

• 分支(并行)编排(Branching)：RAG流中存在多个并行的分支，各自处理后随之合并到一起，这种情况多用于要增加生成结果的多样性而引入。

• 循环编排(Loop Pattern)

• Interative retrieval(循环检索): 单次检索和生成无法有效解决需要大量知识的复杂问题，每次循环后会把当前Generate的输出作为匹配源再去检索内容,直到循环结束，整体类似HyDE检索增强方法。ITER-RETGEN是一种实现循环检索的架构。

• rescursive retrieval(递归检索): 与循环检索类似，但更明确的指出依赖前一步的各个内容（如利用上一次的query改写内容），不断深化检索，不断明确用户查询（消除歧义），有更明确的退出循环的条件。TOC RAG流是一种实现，关键在Tree of Clarification中，通过澄清树结构，在不断迭代中消除用户输入的歧义。

• Interative和rescursive的比较：

• Adaptive retrieval(自适应检索)：引入LLM Agent 概念，在系统关键环节使用LLM判断是否应该怎么行动。如可以在pre-retrieval环节使用LLM判断是否需要去检索外部知识。同Adaptive Agentic RAG。

• 混合检索策略与工具集成：支持稀疏检索（BM25）与密集检索（向量模型）结合，并集成外部 API、数据库等工具。

处理环节

• Query Decompose（查询拆解）：面对复杂问题（如 “苹果 / 英伟达财务表现、市场对比及投资建议”），先拆成子问题：
  • 子问题 1：过去三年财务表现（营收、利润等）
  • 子问题 2：市场地位、增长潜力对比
  • 子问题 3：投资价值判断（谁更值得投）
  • 作用：让大模型分模块处理，降低单步推理难度。
• 多源数据整合：
  • 整合财报（如苹果 / 英伟达年报）、结构化数据（SQL 数据库存财务指标）、知识图谱（KG，梳理公司 - 财报 - 指标关系）。
  • 作用：为后续检索提供 “数据源仓库”，覆盖文本、结构化数据，保证信息全面性
• Hybrid Retrieval（混合检索）：
  • 结合稀疏检索（Sparse，如关键词匹配） + 稠密检索（Dense，如向量相似度），从多源数据中找与子问题相关的内容。
  • 作用：平衡 “精准匹配”（稀疏）和 “语义理解”（稠密），提升检索召回率。
• Selection（筛选）：过滤无关片段（如剔除和子问题不相关的财报内容）。
• Rerank（重排）：按相关性排序，把最相关的内容优先喂给大模型。
  • 作用：减少噪音，让大模型只处理高价值信息，节省内存 & 提升回答质量。
• 分支并行生成：对每个子问题，用检索到的内容（Relevant Chunks）生成 “临时答案（Temp Answer）”，再汇总所有子答案。
  • 示例：子问题 1→拉取苹果 / 英伟达 2021-2023 营收、利润数据；子问题 2→对比市场策略、增长潜力…
• 答案校验：大模型判断是否回答完整，不完整则 “Query Rewrite（重写问题）” 再次检索，直到覆盖需求。
• 输出（Answer）

4. Graph RAG

传统 RAG 用向量相似度检索（vector search）找和查询最接近的文档块，然后喂给 LLM。Graph RAG 在这基础上引入知识图谱（Knowledge Graph, KG）或语义图（Semantic Graph），用节点 + 边来表示实体和它们之间的关系。LLM 不仅能检索局部相似文档，还能沿着图的关系链扩展检索范围，从而获取更全局、语义连贯的上下文。

特点

• 节点连接性：捕获并推理实体之间的关系。
• 层次知识管理：通过基于图的层次结构处理结构化和非结构化数据。
• 上下文丰富：通过利用基于图的路径添加关系理解。

核心思路

• 文档解析 → 实体和关系抽取
  • 用 LLM/NLP 工具从文本中识别实体（人物、地点、事件、概念）和关系（属于、依赖、导致等）；
  • 形成三元组 (实体1, 关系, 实体2)，存进图数据库（如 Neo4j）或图向量引擎（如 Memgraph、Weaviate Graph 模块）。
• 构建图索引
  • 节点可能带有文本描述和向量嵌入；
  • 给节点描述做嵌入（node embedding）；
  • 给文档块也做嵌入（chunk embedding）；
  • 可选：给关系做短描述嵌入（edge embedding）；
  • 边表示实体间的关联，可以是显式（文中直接提到）或隐式（模型推断出来）。
• 增量更新
  • 新文档进入 → 只对受影响的节点/边重抽取与重嵌入。
  • 低置信边在被多次引用后提升权重；冲突边降权或人工审核。
• 查询理解
  • 意图分类：事实问答 / 解释型 / 路径型（“A 与 B 如何关联？”）/ 规划生成（“给我一套练习/学习路径”）。
  • 实体定位：提取查询中的实体候选与别名，做**实体链接（EL）**到图中节点。
  • 约束解析：时间、年级、难度、题型、教材版本等
• 种子检索
  • 综合向量相似 + 关键字 + 别名匹配找到种子节点/文档块
• 子图扩展与路径选择
  • 有约束的多跳：从种子做 1–2 跳 BFS/DFS，限定关系类型与最大分支数（防止爆炸）。
  • 路径打分：
    • 路径相关性 = 节点相关性均值 + 关系类型权重（例如 prerequisite 对学习路径更重要）；
    • 连贯性 = 相邻节点嵌入相似度的均值；
    • 惩罚过长路径（长度正则）。
  • 多样化：MMR 或基于社区（community）抽样，覆盖不同知识支路。

• 候选构成：Top-K 路径 或 Top-M 子图社区。
• 上下文组装与压缩（Context Building）

典型两种模式（可并用）：

• Local 模式（路径证据包）：把 Top-K 路径涉及的节点说明 + 关键原文片段拼装，严格带引用锚点。通过扩展到特定 Entity 的邻居和相关概念，对特定 Entity 进行推理；

本地搜索工作流程

• Global 模式（社区摘要卡）：通过利用 Community 摘要，对涉及整个数据语料库的整体性问题进行推理；

全局搜索工作流程

• Token 预算：优先保留“路径上的原文证据”；摘要压缩次要旁枝；
  • 去重与重排：相似块合并，按“回答所需 → 解释所需 → 拓展参考”的顺序排布。
• 生成阶段
  • LLM 在这些“关系链上下文”基础上生成答案，不仅回答问题，还能解释为什么（因为图保存了推理链）。

解决了哪些痛点

局限性

• 可扩展性有限：依赖图结构可能会限制可扩展性，特别是在数据源广泛时；
• 数据依赖：高质量的图数据对于有意义的输出至关重要，限制了其在非结构化或注释不佳的数据集中的适用性；
• 集成复杂性：将图数据与非结构化检索系统集成增加了设计和实现的复杂性；
• 非常消耗 Token：从文本处理到生成的全流程需要多次 LLM 参与，会消耗大量 Token。

5. Agentic RAG

Agentic RAG，最早由 Chidaksh Ravuru 等人于 2024 年 8 月 18 日在 arXiv 上发表的论文《Agentic Retrieval-Augmented Generation for Time Series Analysis》中正式提出，在RAG的基础上引入了AI“代理”（Agent）。在Agentic RAG中，AI代理模块负责协调检索和生成过程，而不是简单地遵循固定的单次检索-生成流程。通过将RAG的知识检索能力与AI代理的决策能力相结合，突破传统RAG在多源异构数据整合和多跳推理任务上的局限。

技术性突破

• Agentic RAG不再局限于单一知识源，可以聚合来自多个地方或服务的信息。通过代理可以访问各种工具或数据源，包括用于私有文档索引的向量搜索引擎、用于通用知识或实时信息的网络搜索 API、用于计算的计算器，以及其他内部API（如数据库、电子邮件等）；
• Agentic RAG引入了迭代推理和验证，不再局限于单一次的检索。Agentic RAG系统围绕 Agent 代理核心组织，该代理负责协调这些步骤。代理实际上位于管道的中间，决定如何路由查询和数据。这意味着 Agentic RAG 通常涉及反馈循环或迭代过程，而不是单次通过；
• 此外，Agentic RAG 支持多代理架构：你可以有一个路由代理，将复杂任务分配给多个专门的检索代理，每个代理负责不同的领域（一个代理负责内部文档，一个代理负责网络数据等），然后由一个协调（主）代理汇总发现结果；
• 更好的适应性：Agentic RAG 体现了“计划和执行”的范式——它可以即时调整策略以应对新的或不断发展的查询。代理的包含记忆和规划能力意味着系统可以在没有明确重新编程的情况下适应上下文变化或不可预见的情况。从静态查找思维模式转变为自适应问题解决思维模式。Agentic RAG 不受开发人员预期场景的限制；代理可以利用其一般推理能力来处理新的问题类型或数据源，使系统在需求增长时更加稳健。

核心思想

Agentic RAG 在 RAG 里加入了一个控制循环（Planning → Action → Observation → Reasoning）：

• 任务规划：分析问题，拆解成子任务
• 行动：选择最合适的检索/工具执行子任务
• 观察：读取工具输出（检索结果、API 返回等）
• 推理：基于新信息调整下一步计划
• 循环执行，直到满足停止条件（找到完整答案或达到轮数限制）

它有点像一个“会用 RAG 的 AI Agent”。

典型流程

• 传统RAG
  • 向量检索一次 → 找到一个包含推导的文档 → 直接生成答案
  • 如果文档里只有牛顿第二定律，没有胡克定律推导，就答不完整
• Agentic RAG
  • 分析任务 → 发现需要两个知识点 + 推导
  • 子任务1：检索“牛顿第二定律” → 获得公式 F = m·a
  • 子任务2：检索“胡克定律” → 获得 F = −k·x
  • 推理合成：结合两者，得到 m·a = −k·x
  • 再查：检索“简谐运动周期公式推导” → 得到 T = 2π√(m/k)
  • 最终生成答案 + 附引用

关键模块

设计模式

Agentic RAG 常用的两种设计：

• ReAct + RAG
  • ReAct 负责推理与动作（Reasoning + Acting）
  • 动作调用不同的 RAG 检索接口
• Multi-Agent + RAG
  • Planner Agent：分解任务、调度
  • Retriever Agent：执行检索
  • Synthesizer Agent：合成结果
  • Verifier Agent：验证并优化

二、开源的 RAG 平台（框架）们

看完了 RAG 的前世今生，我们就可以来看看当下热门的 RAG 平台（框架）用到了什么思想和技术，以及各自有什么优缺点。

1. LangChain

LangChain（Github地址）是一个广受欢迎的 LLM 应用开发库，用于将大型语言模型与各种工具和数据源连接。提供了丰富的模块（如Prompt模板、记忆、工具调用等）来灵活构建LLM应用，但它本身并非完整的RAG解决方案，而是可用于实现RAG的工具箱。开发者需自行搭建文档检索和调用逻辑。LangChain 优点是生态非常丰富，已有上百种现有工具和向量库接口可直接使用，适合需要高度定制化且有一定技术实力的公司与团队，但缺点是需要编程，有一定学习曲线，对于非技术人员不够友好。

• 核心定位

通用型 LLM 应用开发框架，提供模块化组件（Chains, Agents, Retrievers）构建包括 RAG 在内的复杂 AI 流程，支持从快速原型验证到企业级系统落地。

• RAG 技术特性
  • 检索增强生成：
    • 支持向量检索（FAISS、Chroma）与关键词检索（Elasticsearch）的混合召回策略，检索准确率达 85%。
    • 提供RetrievalQA链，自动将检索结果与用户问题拼接为 Prompt，支持流式响应和引用标注。
  • 文档处理：
    • 内置 100 + 文档加载器（如 PyPDFLoader、CSVLoader），支持 PDF、Excel、HTML 等格式的解析和分块。
    • 支持基于滑动窗口的文本分块，允许自定义块大小和重叠率。
  • Agent 集成：
    • 提供ReAct、SelfAsk等 Agent 类型，支持动态调用检索工具（如搜索引擎、数据库）补充知识。
    • 支持多 Agent 协作，例如法律场景中同时调用法规检索 Agent 和案例分析 Agent。
• 技术优势
  • 生态兼容性：支持 50 + 向量数据库（如 Pinecone、Milvus）和 25 + 嵌入模型（如 OpenAI Embeddings、Hugging Face BGE）。
  • 开发灵活性：允许通过CallbackHandler自定义流程监控，支持与 Airflow 等工作流引擎集成。
  • 社区支持：GitHub 星标超 30k，Stack Overflow 月均提问量超 2000 条，拥有完善的教程和企业级案例库。

2. LlamaIndex（原 GPT Index）

LlamaIndex （Github地址）是一个侧重于索引构建和数据接入的RAG框架。它提供多样化的索引结构（如列表索引、树索引、图索引等），方便将私有或领域数据与LLM连接。LlamaIndex 强调模块化的数据整合与查询能力，帮助开发者将复杂的数据准备、分块、索引和查询流程封装简化。它支持将LLM与外部知识桥接，在查询时自动检索相关片段并注入提示，从而提升答案的上下文相关性和准确性。LlamaIndex上手难度适中，适合需要灵活定制索引/检索策略的场景。

• 核心定位

数据密集型场景的 RAG 首选，专注于连接 LLM 与外部数据的 RAG 框架，提供强大的数据索引、摄入和检索优化工具集，与 LangChain 形成互补。

• RAG 技术特性
  • 高级索引结构：
    • 支持树索引（Tree Index）、关键词表索引（Keyword Table Index）、知识图谱索引（KG Index）等 8 种索引类型。
    • 例如，医疗场景中通过树索引将病历按科室 - 疾病 - 症状层级组织，检索效率提升 3 倍。
  • 检索策略优化：
    • 提供融合检索（Hybrid Search）、句子窗口检索（Sentence Window Search）等高级检索策略，在法律合同审查中准确率达 92%。
    • 支持基于 BM25 的稀疏检索与向量检索的混合排序，可通过Reranker插件自定义排序逻辑。
  • 多模态支持：
    • 支持图片描述生成（需结合多模态 LLM）和表格数据的结构化提取。
    • 例如，财报分析场景中自动识别表格中的关键指标并生成趋势分析报告。
• 技术优势
  • 数据处理深度：内置DocumentTransformer支持数据清洗、元数据提取和实体识别，可处理非结构化数据中的隐含关系。
  • 性能优化：采用 Lazy Evaluation 机制，仅在查询时触发索引构建，适合处理 TB 级文档库。
  • 学术支撑：与斯坦福、CMU 等高校合作，实现了如HyDE（假设文档嵌入）等前沿算法的工程化落地。

3. Haystack

Haystack（Github地址） 是由 deepset 提供的成熟 RAG 开源框架，定位于端到端问答和搜索系统。Haystack 提供模块化Pipeline架构，可组合多种组件执行文档检索、问答、生成功能。其主要特点包括：支持多种文档存储后端（Elasticsearch、FAISS、Milvus、SQL 等）和检索模型（BM25、DPR 等），集成Transformer阅读器（如BERT系列用于从文档片段提取精确答案），并可扩展接入LLM作为生成式回答器。Haystack 设计注重可扩展性，可处理大规模文档，并提供易用的API来构建自定义NLP流水线。相对而言，Haystack社区成熟度高，文档完备；但其针对LLM的最新特性更新稍慢，需要结合 Haystack 最新版本或其商用产品(deepset Cloud)来获得更完整的LLM支持。

• 核心定位

由 deepset 开发的端到端 RAG 框架，专注于构建高性能的问答和搜索系统，尤其适合大规模知识库场景。

• RAG 技术特性
  • 检索增强生成：
    • 支持基于 DPR（Dense Passage Retrieval）的密集检索，在金融法规知识库中条款召回准确率达 92%。
    • 提供CrossEncoder重排序器，可通过微调提升检索结果的相关性。
  • 文档处理：
    • 支持 PDF 文本提取和图像 OCR（需安装 Tesseract），扫描件解析准确率达 95%。
    • 提供可视化分块工具，允许手动调整文本块的边界。
  • 企业级特性：
    • 支持分布式部署（如 Kubernetes 集群），可处理 PB 级文档库。
    • 提供DocumentStore抽象层，支持 Elasticsearch、Weaviate 等存储引擎的热切换。
• 技术优势
  • 性能优化：采用异步处理和批量化操作，千页 PDF 解析时间缩短至 15 分钟（RAGFlow 需 2 小时）。
  • 监控体系：内置 Prometheus 指标和 Grafana 仪表盘，可实时监控检索延迟、模型吞吐量等关键指标。

4. Dify

一个开源的 LLM 应用开发平台，由 LangGenius 开发。Dify 提供接近生产级的完整解决方案，融合了后端即服务和 LLMOps 理念，允许开发者快速搭建各种生成式AI应用。它内置了高质量的RAG引擎、可视化的 Prompt 编排界面、稳健的 Agent 框架以及灵活的工作流工具。简单说，Dify 像是一套搭建LLM应用的“脚手架”，封装了常用功能，非技术人员也可以通过图形界面参与应用构建和数据维护。Dify 支持数百种主流开源/闭源模型，支持多模态（语音识别、富文本），并提供可视化的知识库管理、模型管理、日志监控等一系列企业所需功能。其优势在于功能完整、界面友好（强调“简单、克制、迭代迅速”），劣势是平台相对重量级，需要部署数据库等后端，且RAG检索能力在早期版本中稍显薄弱（目前已通过引入混合检索+重排得到加强）。

5. 相互对比

综上，各方案各有所长：LangChain 和 LlamaIndex 偏底层库，适合需要高度自定义的开发者；Haystack 提供经典问答管道，稳定可靠；Dify 和 RAGFlow（详见下文）属于新兴的一体化平台，更适合希望开箱即用构建企业级 RAG 应用的团队

三、何为 RAGFlow

RAGFlow 是一款开源 RAG 引擎，强调深度文档理解与端到端问答流程。它由 InfiniFlow 开源，于 2024 年4月正式发布，当天即收获上千⭐Star，引发关注。RAGFlow 提供从数据接入到问答生成的一整套模块，主要功能模块和用途如下：

1. 知识库与数据集管理

RAGFlow 将上传的文件组织为“知识库（Knowledge Base）”，每个知识库可包含多个数据集（文档集合）。支持的文件类型非常丰富，包括文档（PDF、DOC/DOCX、TXT、Markdown）、表格（CSV、XLS/XLSX）、图片（JPEG/PNG/TIF 等）、幻灯片（PPT/PPTX）等。同类平台中，RAGFlow 的文件格式支持范围处于领先地位。

2. 文档解析与结构化处理

这是 RAGFlow 的核心特色模块。RAGFlow 没有采用现有通用文本分块方案，而是重新研发了一套智能文档理解系统。该系统通过 AI 模型自动识别文档版面布局，包括标题、段落、换行、以及图片和表格等复杂元素。特别地，对于PDF这类半结构化文档，RAGFlow 内置了表格结构识别（TSR）能力，以提取表格的行列关系。不同文档类型可选择不同解析模板（如 Q&A型文档、简历、论文、手册、法律文件等），针对性提取关键信息。解析完成后，文档会被切分为若干内容块（chunk）。RAGFlow 提供可见且可干预的分块结果查看界面：用户可以查看每个chunk的内容（原文截片），必要时对划分不合理的地方进行人工调整或添加关键词提升检索权重。这一可干预机制确保数据质量，从而实现“Garbage In, Garbage Out 转化为 Quality In, Quality Out”。在实际场景中，这意味着对于关键的企业文档，运营人员可以微调解析结果（例如合并/拆分段落、纠正OCR错误、为重要段落加标签），以确保后续检索的准确性。这一模块适用于长篇幅、结构复杂文档的处理，如合同、财报、技术规范等，在RAGFlow中都能得到结构化的解析。

• DeepDoc 多模态结构化文档解析链（文档理解引擎）
  • OCR（文字识别）：适用于扫描版 PDF，可集成 Tesseract、PaddleOCR 等模型，对表格/页眉页脚/文本块结构保留良好。
  • TSR（表格结构识别）：用于识别文档中表格的边界、行列关系和表头语义，有助于切片时保留语义上下文。
  • DLR（文档版面分析）：基于视觉 Transformer 的布局分析组件，准确区分页眉/目录/正文/图片/图注/侧边栏等模块。
  • 可配置是否使用 DeepDoc，每个步骤（OCR、TSR、DLR）可启用/禁用/替换模型，适应不同精度和算力需求。
• 模板化切片与可视化治理
  • 内置超过 10 种文档类型模板（Paper、Manual、Resume、Law、QA、General、Book、Form 等），适配常见企业文档格式。
  • 可自定义模板规则，包括切片粒度、逻辑块识别方式、保留表格、标题识别、关键词加权等。
  • 提供 切片可视化 UI 工具，支持手动干预和标注，包括：
    • 指定切片权重
    • 调整关键词
    • 设置文本可召回窗口
    • 添加自定义 metadata
  • 具备失败回退机制：若复杂文档结构化失败，可回退为纯文本切片。

3. 检索与排序系统（Retrieval & Ranking）

RAGFlow 会为解析后的文档内容块生成向量表征，并构建内部的检索索引。当前支持将索引存储在 Elasticsearch（用于稀疏关键词检索）或 InfiniFlow 自研的 Infinity 向量数据库中。Infinity 是一个“AI原生数据库”，号称提供业界最快的多路召回和融合排序能力。实际上，RAGFlow 的检索阶段采用了多策略结合：同时支持关键词检索（例如利用ES的BM25）和文本向量相似度检索，并通过融合排序或重排序模型（如 v0.9 集成的 xinference 重排器）来优化最终结果相关性。这种混合检索策略可以兼顾召回率和精确性：即既能找到语义相关的段落，又不漏掉关键词匹配的细节。对于用户提问，RAGFlow 默认检索 topK 个最相关片段。在管理界面中，提供“检索测试”功能，允许开发者输入样例问题，立即查看检索到的文档片段及其相关度分数。如结果不理想，可据此调整分块或增加关键词权重。这种所见即所得的调试方式提升了检索调优的便捷性。

• 多路召回（Multi-Recall）
  • 向量检索：基于 Sentence Transformers（如 BGE、BCE、MiniLM）等 Embedding 模型，通过余弦距离/向量近邻召回候选文本块。
  • 关键词反向索引：基于 Elasticsearch 的倒排索引，支持 BM25、TF-IDF 查询召回。
  • 结构化检索：基于文档 metadata 进行条件过滤与召回，例如文档类别、创建时间、文档来源等。
  • PageRank 跨库权重传播：在多文档知识库之间基于链接/关键词传播权重，用于 PageRank 召回评分融合。
• 融合重排（Fusion + Reranking）
  • 将多路召回结果合并为候选集合后，使用重排序模型进行精排（可选模型包括 BGE-Reranker、BCE-Reranker、Jina Ranker）。
  • 支持的排序算法：
    • 点对点排序（pairwise ranker）
    • 点到集合排序（listwise ranker）
    • 多语言重排（适配中英文）
  • 排序可视化界面展示：重排前后得分、模型评分、来源片段对比。
• 长文检索优化（RAPTOR 支持）

• 引入 RAPTOR 结构化检索框架，将长文嵌套成标题-子段落层级嵌套嵌入，提升检索精度与生成逻辑连贯性。
  • 层次级联检索策略：先检索标题段，再扩展子段内容。

4. 问答生成与引用

检索得到的相关内容片段会与用户问题一起发送给 LLM，生成答案。RAGFlow 并不内置LLM模型，但可以灵活对接主流LLM服务。它支持调用 OpenAI、Anthropic 等云模型API，以及通过 Ollama、LocalAI、Xinference 等工具部署的本地模型。用户可在界面上配置多个模型的API密钥，并设置系统默认的“对话模型”和“嵌入模型”等。RAGFlow 支持每个聊天会话选择不同的模型，从而适配不同需求。

在回答生成时，RAGFlow 的目标是提供有依据的回答，最大限度减少幻觉。因此，它在答案中自动附加引用来源，每条答案都标注了相应原文片段的引用链接。用户在前端界面可悬停查看引用内容，包括引自原文的句子或图表，点击还可跳转定位至原始文档中的位置。这种设计确保最终用户可以追溯答案依据，提高了回答的可信度和可审核性，是RAGFlow 作为RAG系统的重要优势之一。在企业内部知识问答、对外客服答疑等场景中，有据可依的答案往往更受信任。

5. 对话与多知识库支持

RAGFlow 提供了一个交互式聊天界面，支持基于单个或多个知识库进行问答对话。用户可以新建“Assistant”（助手），为其指定关联的知识库范围。如果关联多个知识库，RAGFlow 会在更大的资料池中检索答案，适用于例如同时查询技术文档和业务手册的场景。对话配置中还可以设置当检索不到答案时的行为：要么回复预设的短语（如“很抱歉，未找到相关信息”），要么让 LLM 自由发挥（可能产生不基于知识库的回答，但具创造性）。通过这样的配置，企业可选择更严格或更开放的问答策略。

此外，还可调整对话时使用的提示词模版（Prompt Engine）以及上下文长度限制等，从而控制助手的回答风格和引用长度。这个模块使RAGFlow不仅能用于一问一答，还能支持多轮对话，在上下文中记忆之前的问题和引用，从而实现更自然的交互体验。

6. 插件和扩展能力

虽然RAGFlow 主打问答，但它也开始融合 Agent 等能力。例如，RAGFlow 内置了代码执行插件（Code Executor），允许 LLM 在回答过程中执行一段沙箱代码，以处理计算类请求（需额外开启 gVisor 隔离沙箱以确保安全）。这一特性类似 ChatGPT 的 Code Interpreter 插件，当用户问题需要数据计算、格式转换时，RAGFlow 能运行Python代码给出结果。

此外，RAGFlow v0.9 起新增了对 GraphRAG 的支持，即引入知识图谱增强。系统可利用 LLM 从文档中抽取实体关系，构建知识图谱，并将其融合到检索流程中。GraphRAG 的引入提升了对复杂问答和推理场景的支持，使答案更加精准、可解释。例如在医学/法律等领域，关键实体的关联可通过图谱明确呈现。

总体而言，目前 RAGFlow 的扩展插件不算多，但架构足够模块化，可以接入新的 LLM、检索引擎，官方也计划引入更多企业数据源（如数据库 binlog、爬虫接口）等以拓展应用范围。

7. 适用场景

综合以上功能，RAGFlow 非常适合用于企业级知识库问答场景，特别是在多格式文档（扫描件、表格、图文并茂PDF）众多的情况下。它的深度文档解析确保即使原始资料很复杂，也能提取出结构化的知识进行问答。例如：企业内部的政策制度库问答、产品说明书QA、法律法规查询、技术资料检索等。

对于客服场景，RAGFlow可作为知识底座，为Chatbot提供准确答复依据（并能让客服/用户查看原文依据）。在流程自动化方面，借助其Agent插件和API，RAGFlow也能和业务系统集成，实现如自动报表生成（从数据库检索数据并利用LLM生成总结）等任务。此外，RAGFlow 通过REST API和Python SDK开放了功能，方便开发者将其集成到自有应用或服务中。例如，可以将RAGFlow部署为公司内部的问答服务，通过API供多个应用调用，实现统一的知识问答平台。

8. 技术架构

RAGFlow 的整体系统架构遵循标准的 多层可插拔模块化设计，以便应对复杂企业级应用需求、保证系统稳定性与可维护性。

关键模块

• 查询入口（Query Layer）
  • 支持 HTTP API / WebSocket / LangChain 接入；
  • 查询统一转化为标准检索请求结构；
  • 多种 Query Adapter：文本查询、图像查询、SQL 查询、工具任务查询。
• 检索调度与执行引擎（Retriever Engine）
  • 调度多路召回器（向量/关键词/结构化/长文层级）；
  • 对各路召回进行评分融合；
  • 启用重排器完成最终排序；
  • 按需选择候选片段 N 条进入 LLM；
• 应用层
  • 每个 Agent 可配置 Prompt 模板、调用工具集、检索路径；
  • 工作流以 DAG 流程图方式管理，状态持久化；
  • 代码沙箱引擎异步执行（via gVisor）；
  • MCP 网络节点由 API 管理器连接；
• 模型管理模块
  • 模型类型分为：
    • Embedding 模型（用于切片/召回）
    • 重排模型（用于 rerank）
    • LLM（用于回答生成/Agent）
    • 多模态模型（图文理解）
  • 模型源支持：
    • 云端（OpenAI、Moonshot、Claude）
    • 本地部署（Ollama、Xinference）
    • 第三方模型代理（LocalAI）
• 存储层细节
  • Elasticsearch / Infinity：用于索引向量/稀疏/结构化字段，适配多种召回需求；
  • MySQL / PostgreSQL：用于存储切片元信息、用户数据、任务状态；
  • MinIO：用于原始文档和图像等对象存储；
  • Redis：中间态缓存，提升响应速度。

四、怎么选

多维比较