2025 年进入尾声，检索增强生成（RAG）领域经历了一场深刻的反思、激烈的辩论和显著的进化。它并没有像某些大胆预测所言的那样随着时间推移而过时——尽管对其所谓“过渡性角色”的质疑声不断——RAG 反而在企业 AI 落地的严苛战场上，作为数据基础设施的核心基石稳固了自己的地位。

回顾过去，RAG 在这一年的轨迹是复杂的。一方面，其实际效果面临了巨大的怀疑，部分原因在于 RAG 系统固有的“易上手、难精通”的调优挑战。另一方面，其在公众视野中的关注度似乎被 2025 年 LLM 应用毫无疑问的焦点——AI Agents（智能体）所掩盖。

然而，一种有趣的趋势出现了。尽管存在争议且未处于聚光灯下，真正致力于构建核心 AI 能力的企业——尤其是大中型组织——却在加深并系统化对 RAG 的投入。RAG 并没有被边缘化，反而巩固了其在企业 AI 架构中的核心角色。其作为关键基础设施的地位依然不可动摇，构成了企业智能的坚实基础。

因此，我们必须首先超越表面的争论，审视 RAG 技术的内在生命力。它仅仅是一个修补 LLM 知识缺口的临时“补丁”，还是一个能够持续演化为下一代 AI 应用基石的架构？为了回答这个问题，我们必须系统地回顾其技术改进、架构演进以及在 Agent 时代的新角色。

RAG 还能改进吗？

关于长上下文（Long Context）与 RAG 的辩论

2025 年，许多关于 RAG 的辩论核心源于一个广为人知的矛盾：企业感到“离不开 RAG，却又对其现状感到不满”。RAG 降低了访问私有知识的门槛，但要获得稳定且准确的结果——尤其是针对复杂查询——通常需要进行大量精细的优化，这使得总拥有成本（TCO）的评估变得复杂。

因此，2024 年被热烈讨论的理论问题——“长上下文能否取代 RAG？”——在 2025 年迅速进入了实践测试阶段。一些对延迟和成本较不敏感、且查询模式相对固定的场景（例如：某些合同审查、固定格式报告分析）开始尝试直接使用长上下文窗口。他们将整批或大量相关文档一次性喂给模型，希望以此绕过 RAG 检索可能带来的信息损失或噪声，直接解决对话质量不稳定的问题。

然而，2024 年以来的研究为这种技术对比提供了更清晰的图景。机械地将长文本塞进 LLM 的上下文窗口本质上是一种“暴力”策略。它不可避免地会分散模型的注意力，通过“迷失在中间（Lost in the Middle）”或“信息泛滥”效应显著降低回答质量。更重要的是，这种方法的成本高昂——处理长上下文的计算开销呈非线性增长。

因此，对于企业而言，实际问题并不是参与“RAG 已死”之类的简单辩论，而是回到核心挑战：如何以最佳的性价比，将最相关且最有效的信息纳入模型的上下文处理系统。这恰恰是 RAG 技术的原始设计目标。

长上下文能力的提升并未预示 RAG 的终结。相反，它们促使人们更深入地思考两者如何协作。例如，RAG 系统可以利用长上下文窗口来容纳更完整、语义连贯的检索切片，或者汇总中间结果进行多步检索和反思。这种“检索先行，长上下文容纳”的协同作用，是新兴的“上下文工程（Context Engineering）”领域背后的关键驱动力。它标志着从优化单一“检索算法”到系统化设计端到端“检索-上下文组装-模型推理”流水线的转变。

目前，向 LLM 提供外部知识的范式主要分为四类：

1. 仅依赖 LLM 的长上下文能力。
2. 利用 KV Cache（键值缓存）。
3. 使用简单的搜索方法（如 Grep）。
4. 采用完整的 RAG 架构。

在成本方面，方案 1 和方案 4 之间大约存在两个数量级的差距。方案 2 涉及通过 LLM 的前向传播将所有文档数据处理成张量（tensor），并存储在专门的 KV Cache 系统中。其成本仍比 RAG 高出至少一个数量级。即使将 KV Cache 升级为集成的数据库与推理引擎（如 AlayaDB [Ref 1] 所倡导的），仍面临根本性的技术限制：

1. 数据量 vs. 检索性能的困境：如果预处理的张量数据超过 GPU 显存容量，系统必须引入二级存储和相应的检索机制进行按需加载。这使得推理变成了一个“边搜边生成”的过程，对 I/O 延迟和检索速度提出了极其严苛的要求。为了满足超低延迟，整个数据集和 LLM 推理服务通常必须紧密共存于同一台物理机或高性能计算集群的近端网络域内。这极大牺牲了架构的灵活性和可扩展性，限制了部署选项。
2. 场景局限性：这种方法主要适用于相对静态、基于事实的文本库。它难以灵活且经济地纳入企业中常见的复杂且不断变化的业务规则、实时知识更新以及各种复合查询。
3. 技术融合趋势：这种方法与 RAG 并不冲突。即使它变得实用，也极有可能作为优化组件被吸纳到 RAG 架构中。

方案 3（无索引 RAG）在 Claude Code 为其编程助手 Agent 引入后获得了一些关注。随之产生了一个简单的问题：在特定领域，基础的字符串匹配（Grep）能否取代复杂的基于检索的 RAG 架构？对于组织良好、格式纯净、术语固定的代码库或高度结构化的文本数据（如日志文件），基于规则的 Grep 或关键词搜索可能以极低的成本交付不错的结果，节省了索引构建和维护的开销。

然而，对于绝大多数企业的跨模态、非结构化或半结构化数据（如产品手册、会议纪要、设计图纸、带有表格和图像的报告），这种方法完全失效。事实上，即使是看似规则的代码搜索，Augment Code 等领先产品也会避免使用简单的 Grep。相反，他们会针对代码语义微调专门的 Embedding 模型。原因在于，为编程助手提供有效的上下文不仅需要精确的字符串匹配（查找函数名），还需要语义相似的代码片段（相同功能的不同实现）、相关的 API 文档以及代码块依赖关系。

此外，多样化的自然语言查询、高并发、低延迟响应以及配合业务元数据的过滤/排序——这些对企业应用至关重要的功能——都远超出了 Grep 的范畴。因此，RAG 及其前身——企业级搜索引擎——仍然是满足复杂企业需求的全面技术和架构解决方案。它们的价值在于提供系统化、可扩展且可治理的知识访问与管理能力。

RAG 对话质量的优化

回到 RAG 的核心，回答不准确或不稳定的一个常见根源在于传统“切片-嵌入-检索（chunk-embed-retrieve）”流水线中的结构性冲突：即使用单一粒度、固定大小的文本切片来执行两个本质上冲突的任务：

• 语义匹配（召回）：为了在语义相似度搜索中实现高精度召回，需要较小的切片（例如 100-256 tokens）。这能提供清晰的语义焦点并减少无关信息。
• 上下文理解（利用）：为了给 LLM 提供足够完整且连贯的上下文以生成高质量回答，需要较大的切片（例如 1024+ tokens）以确保逻辑完整性和背景充足。

这迫使系统设计者在“精确但碎片化”和“完整但模糊”之间进行艰难权衡，往往顾此失彼。小切片可能检索出碎片化的信息，导致 LLM 无法把握全貌；大切片可能引入噪声，降低检索精度，并由于向量表示概括了整个切片而丢失内部细节的差异化。

一个根本性的改进是将 RAG 过程解构为两个逻辑阶段——“搜索（Search）”和“检索（Retrieve）”——允许每个阶段使用不同的文本粒度：

• 搜索（Search）：类比于“扫描”或“定位”，其核心目标是从海量数据中快速、精确地识别出所有潜在相关的“线索”。此阶段应使用较小的、语义纯净的文本单位，以实现高召回率和高精度。
• 检索（Retrieve）：类比于“阅读”或“理解”，其核心目标是为 LLM 生成答案组装“阅读材料”。基于搜索阶段发现的线索，此阶段应动态聚合、拼接或扩展成更大、更完整且连贯的上下文片段。

RAGFlow 的 TreeRAG 技术体现了这一思路。它在离线阶段使用 LLM 自动分析文档，构建层级化的树状目录摘要结构。这巧妙地填补了“细粒度搜索”与“粗粒度阅读”之间的鸿沟。其核心工作流反映了“先精确准定位，再扩展阅读”的智慧：

• 离线处理（知识结构化）：文档拆分后，切片被发送给 LLM 进行分析，生成多级树状目录摘要（例如：章 -> 节 -> 小节 -> 关键段落摘要）。同时，每个节点或原始切片都可以通过摘要、关键词、实体、潜在问题、元数据和关联的图像上下文描述进行语义增强。研究 [Ref 3] 表明，在离线处理期间，可以放宽细粒度切片的要求。过度复杂的拆分会破坏语义单元；简单的重叠切片在实践中往往更有效且更鲁棒。
• 在线检索（动态上下文组装）：收到用户查询后，首先使用最细粒度的“小片段”（原始切片或其摘要）进行相似度搜索，以实现快速、精确的初始召回。然后，利用离线构建的“树状目录”作为导航图，系统迅速定位召回切片节点的父节点、兄弟节点及相邻节点。它自动将这些语义相关的片段组合成逻辑完整的“大片段”提供给 LLM。这有效地缓解了由固定大小切片引起的上下文碎片化问题，确保提供给模型的内容既包含精确匹配的核心信息，又包含理解这些信息所需的周边背景。

类似的工作还包括 PageIndex [Ref 2]，它更侧重于解析和利用文档固有的物理或逻辑目录（例如 PDF 中的目录）。当文档结构清晰且格式标准时，这种方法非常高效。其局限性在于高度依赖源文档质量；当文档缺乏清晰或准确的目录时，其自动定位能力会减弱。

TreeRAG 及类似技术有效地解决了由糟糕切片引起的“迷失在中间”痛点。然而，对于更复杂的查询——即答案散布在数十个不相邻的切片中，或需要整合来自多个独立文档的信息进行推理时——单靠树状结构可能无法捕捉到所有相关的关联。行业自然而然地转向了另一条技术路径：GraphRAG。

GraphRAG 从文档中提取实体和关系以构建知识图谱，利用图查询和推理来发现间接相关的知识片段。然而，GraphRAG 自诞生以来也让许多从业者感到复杂且纠结，主要源于以下挑战：

1. 巨大的 Token 消耗：实体提取、去重和社区摘要（community summarization）消耗的 Token 可能是原始文本的数倍至数十倍。
2. 预期的实体提取质量与实际存在差距：传统知识图谱由领域专家精心设计和验证，具有极高的质量，适用于直接的视觉分析和交互。相比之下，GraphRAG 自动提取的实体和关系往往包含大量噪声、冗余或错误。用视觉知识图谱的标准来衡量它们往往会导致失望——“好看但不中用”。
3. 知识破碎化：即使图算法发现了相关的社区并生成了摘要，输出结果仍然是围绕特定主题的“知识片段”集合。基于这些离散片段生成最终答案对 LLM 的整合和连贯叙述能力提出了很高要求，往往导致回答缺乏逻辑主线或遗漏关键方面。

因此，结合 TreeRAG 和 GraphRAG 的优势有望进一步缓解 RAG 的痛点。TreeRAG 擅长解决由物理切片引起的局部语义断裂，提供连贯的上下文；而基于实体关系网络的 GraphRAG 则可以利用图遍历算法（如个性化 PageRank）帮助发现语义高度相关但在原始文档中物理距离较远、甚至跨文档的内容片段。

因此，无论是 TreeRAG、GraphRAG 还是它们的混合架构（统称为“长上下文 RAG”），其核心范式都是在传统 RAG 流水线之上引入了一个额外的语义增强和结构构建层。在数据摄入阶段，除了切片，还利用 LLM 进行深层语义理解、摘要生成和结构提取。在检索阶段，它超越了简单的搜索，结合了基于预定义结构（树、图）的导航、关系查询和动态组装。

RAG 技术远非停滞不前。其改进方向日益清晰：在数据生命周期的早期阶段利用 LLM 自身的能力来弥合原始数据与最终问答之间的语义鸿沟。在摄入时，使用不同指令的 Prompt 请求 LLM 从多角度、多轮次分析文本，提取丰富的多层语义信息（元数据）。在检索时，利用这些增强的语义作为“导航图”来智能过滤、聚合和填充上下文，超越简单的向量相似度搜索。这是应对复杂的开放域问答挑战更可靠的路径。

像 RAGFlow 这样的产品正深入探索这一方向，未来的演进将围绕这些核心点展开。简而言之，现代 RAG 系统的设计哲学是充分协调“强大的检索和推理能力”与“有限但珍贵的 LLM 上下文窗口”。通过智能预处理和动态组装，寻求效果、性能和成本之间的最佳平衡。

从知识库到数据基座

我们经常强调 RAG 是一种架构范式，而非具体应用。然而，知识库无疑是 RAG 最直观、最成功的应用形式。随着 AI Agent 开发的迅速兴起，一个明显的趋势正在显现：Agent 的复杂任务执行越来越依赖于对海量、多样化企业数据的实时访问和理解。

因此，企业级 RAG 产品正在从单一的“问答知识库”角色演变为更基础、通用的 Agent 数据基座。它们需要作为所有类型 Agent 的统一、高效且安全的非结构化数据访问服务。

为了实现这一目标，一个健壮、可扩展且可配置的摄入流水线（Ingestion Pipeline）已成为现代 RAG 引擎不可或缺的核心组件。它处理“接管”企业内复杂的非结构化数据（文档、图像、音频/视频、代码、邮件等）并将其“消化”为 RAG 引擎可索引、可检索的标准格式的全过程。

如果说 ETL/ELT（以 dbt、Fivetran、Airbyte 为代表）是现代数据栈中处理结构化数据的工业化标准流水线——为数据仓库和数据湖提供统一、灵活且可靠的数据集成——那么非结构化数据的摄入流水线（或称 PTI：解析-转换-索引，Parse-Transform-Index）则是其在 AI 时代对应的关键基础设施。它们共享类似的架构定位和处理哲学，但因数据特性而在技术方法上有所不同。

审视每个阶段的异同：

• 提取（Extract） vs. 解析（Parsing）：传统 ETL/ELT 的“提取”阶段主要从关系数据库、API 和日志文件等结构化或半结构化源中拉取数据。摄入流水线在此基础上强调“解析”阶段，以应对从非结构化数据中提取信息的挑战。它采用各种解析器：用于 PDF/Word 的格式解析器、像 RAGFlow 的 DeepDoc 这样专门的文档智能模型，以及在视觉语言模型 (VLM) 上微调的 OCR 模型。其目标是将多模态、多格式的原始文档转换为干净、结构化的文本表示，并尽可能保留原始逻辑结构（标题、列表、表格）和元数据（作者、日期）。
• 转换（Transform）：这一阶段显示出最大的分歧。传统 ETL/ELT 的“转换”侧重于使用 SQL 或代码进行数据清洗、格式标准化和业务逻辑计算（聚合、关联）。摄入流水线的“转换”阶段则是一系列以 LLM 为核心的语义理解和增强组件。它们将来自解析器的原始文本流转换为检索所需的进阶“材料”。除了基础的文本切片，所有旨在提高检索效果和精度的过程——如树状结构生成、知识图谱（实体关系）提取、摘要生成、问题生成和关键词提取——都发生在这里。这一阶段是注入“智能”的关键，决定了数据“理解”的深度。
• 加载（Load） vs. 索引（Indexing）：传统 ETL/ELT 将处理后的干净数据加载到目标数据仓库/数据湖表中。RAG 引擎则通过其“索引”组件，从转换阶段产生的丰富内容（原始文本切片、摘要、向量、元数据、图关系）构建高效索引。这支持了各种检索方法。RAG 引擎本质上是一个高并发、低延迟的服务层。它必须支持混合检索（向量 + 关键词 + 元数据过滤），并可能整合前文提到的基于树或基于图的检索等高级能力。

无论是结构化数据的 ETL 还是非结构化数据的 PTI，中间的“转换”步骤都是核心价值创造阶段。对于 ETL，工程师根据特定的业务分析需求设计转换逻辑 (SQL)。对于 PTI，由于摄入流水线必须与最终检索需求进行端到端协同设计，关于转换阶段切片粒度、生成的增强语义类型以及索引结构复杂性的决策，都取决于上层应用（如问答、摘要、分析）对精度、速度和成本的要求。

因此，构建出色的 RAG 系统不仅仅是选择最先进的解析器模型或最高性能的向量数据库。它取决于整个“数据摄入 -> 语义增强 -> 索引构建 -> 检索服务”流水线的协同设计和持续调优。

拥有了这样一个强大、灵活且智能的摄入流水线，RAG 系统才真正从一个“问答系统”进化为企业非结构化数据的统一处理与访问平台。它可以标准化并自动化地消化散落的内部知识资产，将它们转化为 AI Agent 随时可用的“燃料”。

这解释了为什么今天当企业致力于构建统一的 AI 能力平台时，其核心和基础必须是这样一个以 RAG 引擎为中心、具备强大数据处理能力的数据基座。它为所有企业 AI 应用提供单一事实来源（SSOT）和实时更新的知识。

从 RAG 到 Context

在 2025 年，LLM 应用中最具活力和引人注目的方面无疑是各种 AI Agent。从 Agent 框架的角度来看，RAG 可以被视为一种提供外部知识访问的工具——类似于调用计算器、查询天气 API 或操作数据库的工具。

这种以工具为中心的视角，加上“Agentic RAG”（利用 Agent 的规划、反思等能力来增强 RAG 过程本身）的兴起，助长了 2025 年的一些叙事，暗示“RAG 将被更通用的 Agent 取代”或“RAG 只是另一个普通的对象工具”。

然而，这种观点简化了 RAG，并可能误解了 RAG 在 Agent 生态系统中的根本价值和地位。它忽视了 RAG 架构的本质——其核心能力和价值基础在于检索（Retrieval），而不仅仅是“增强生成（Augmented Generation）”。

正是这种“高效、准确且可扩展地从海量私有数据中检索相关信息”的核心能力，使得 RAG 能够成为、并且正在成为 Agent 最不可或缺的基础数据基座。因为无论 Agent 多么智能，其决策和行动的质量从根本上取决于它接收到的上下文（Context）的质量和相关性。

如何为不同任务、在不同时刻动态且智能地组装最有效的上下文，成为了 2025 年下半年最热门的技术探索和指导原则，并由此催生了“上下文工程（Context Engineering）”。

让我们分析上下文工程涉及的主要数据类型和技术，以理解为什么“检索”处于其绝对核心地位：

上下文工程之所以成为一个独立领域，是因为实践反复证明：不加选择地将所有潜在相关数据塞进 LLM 的上下文窗口不仅成本高昂得令人望而却步，而且会由于信息过载严重损害 LLM 的理解、推理和工具调用能力。因此，智能地过滤、排序和拼接上下文至关重要。

典型的 Agent 上下文通常需要精心组装三类数据：

1. 领域知识数据：对于作为核心工具的知识库（即 RAG 系统），检索结果的质量直接决定了回答的成败。返回过多无关片段会引入噪声，干扰回答生成；缺失关键片段则不可避免地导致事实错误或回答不完整。因此，RAG 本身可以被看作是针对领域知识的最早的“上下文工程 1.0”实践。
2. 工具数据：对于其他功能性工具，尤其是通过模型上下文协议（MCP）等标准封装的大量工具，其描述信息（名称、功能、参数规格）本身就是上下文的一部分。当只有少数工具可用时，它们的描述可以硬编码在提示词中。但在企业级场景下，内部服务、API 以及通过 MCP 封装的函数可能多达数百或数千个。手动或静态地为每次对话指定调用哪些工具是不切实际的。这种“工具选择”问题直到 2025 年底才被部分用户深刻感受到，甚至引发了诸如《MCP 仅面世一年就已夭折》之类的标题党文章 [Ref 9]。事实上，作者归咎错了对象——核心问题在于不加区分地将所有工具描述塞进上下文中，导致大语言模型产生“选择困难症”，而非 MCP 协议本身的问题。MCP 是一个旨在标准化工具调用接口的极其重要的协议，但它不能也不可能解决“在特定情况下选择哪种工具”的决策问题。那么，谁应该承担这一决策责任？这是目前大多数 Agent 框架中缺失的关键环节。答案依然是检索（Retrieval）。我们需要对所有工具描述进行语义搜索，并结合从历史工具使用记录中形成的“技能（Skills）”、“剧本（Playbooks）”或“指南（Guidelines）”进行检索。这样就能动态且精准地过滤出与当前 Agent 任务最相关、最可能被正确使用的工具子集和参数。这远超 Anthropic Skills 等当前功能所覆盖的范围。如何闭环生成、检索和使用这些技能/剧本/指南并将其产品化，是上下文工程（Context Engineering）必须解决的核心问题。这从根本上是一个数据基础设施（Infra）问题，而不仅仅是模型能力问题。
3. 对话和状态数据：除了静态知识和工具，上下文还需要包含与当前交互相关的动态数据：对话历史、用户个性化/偏好以及一些 Agent 内部状态（如人机协作中的人工输入）。管理和访问这些数据通常被称为“记忆（Memory）”，这在 2025 年早中期成为了一个独立的热门话题。但从技术上讲，记忆系统的核心能力——存储、索引和检索历史交互信息——与 RAG 并没有本质区别。它可以被看作是针对特定数据源（对话日志）和使用模式（强调时间相关性和对话相关性）的专门检索系统。

解构上下文构成清晰地表明，上下文工程的核心任务仍然是基于 Agent 所需的三大主要数据源进行检索：

1. 对企业私有、非结构化领域文档数据的检索——即 RAG。
2. 对 Agent 交互过程中生成的对话历史和状态数据（尤其是 LLM 生成的内容）的检索——即记忆（Memory）。
3. 对来自封装好的企业服务和 API 的工具描述及使用指南数据的检索——称为工具检索。这些数据也可以驻留在像记忆这样的专门区域。

因此，在 AI Agent 时代，RAG 技术无疑将会演进。它不再仅仅是“检索增强生成”中的一个步骤。以“检索”为核心能力，通过扩大其数据范围，它演变为一个支持所有上下文组装需求的上下文引擎（Context Engine），成为服务于 LLM 应用的统一上下文层和数据基座。

Agent 时代的检索与搜索时代有何不同？

理解这一演变需要对比传统搜索时代与 Agent 时代检索范式的根本差异。

在传统搜索时代（例如使用 Google 或企业搜索），检索的发起者、执行者和消费者都是人类。用户提出问题，搜索引擎返回相关文档链接列表，用户必须打开多个链接，阅读、比较并综合信息以形成答案或决策。这是一个“人机协同、以人为主”的闭环。

在 Agent 时代，检索的发起者和主要消费者是 Agent（由 LLM 驱动）。一个典型的工作流是：LLM 首先理解并分解用户的复杂问题（假设/规划），然后代表用户自动发起一次或多次检索请求。接着，它理解、验证并提炼原始检索结果（反思），最后将处理后的信息拼接进上下文中，以生成最终答案。检索的内容从单一网页/文档扩展到包含工具使用、记忆片段等。整个“问题理解 -> 检索 -> 结果处理 -> 上下文组装”的闭环由 Agent 自动化完成。

因此，面向 Agent 的检索系统面临着前所未有的新需求：极高的请求频率（可能比传统搜索时代的人类请求高出一到两个数量级）、多样化的查询类型（针对文档的语义查询、针对工具的关键词匹配、针对工具使用指南的参数匹配、针对记忆的关联查询）、严苛的延迟要求（直接影响 Agent 的响应速度），以及与 Agent 推理流紧密耦合的需求。

单一的搜索引擎或向量数据库远不足以支撑这些。它需要基于存储和索引构建一个智能中间服务层。该层理解 Agent 意图，根据上下文组装策略动态协调对不同底层数据源（文档库、记忆库、工具库）的检索请求，并对结果进行必要的融合、去重、重排序和格式化，最后将它们封装成 LLM 随时可用的上下文。

这种使用模式意味着，Agent 开发中最复杂、最专业的“上下文工程”部分——目前高度依赖人工并在 Prompt 中硬编码——有潜力向声明式配置甚至自动化方向发展。这可以显著降低 Agent 的开发和维护难度，同时提高一致性和可复用性。

工具也需要搜索

工具的多样性直接决定了 Agent 解决问题的广度和深度。在简单的演示或原型中，常见的做法是将所有可用工具的描述（通常是自然语言文本）全部嵌入到 Agent 的 Prompt 中。然而，当工具数量从几个增长到数十个或数百个时，弊端就显现出来了。

首先，它消耗了大量珍贵的上下文 Token，而这些 Token 本可以用来容纳更重要的任务描述和中间结果。其次，过多的选项加重了 LLM 的工具选择负担，增加了产生“幻觉”调用或错误工具选择的概率。

特别是在企业场景下，工具数量可能达到惊人的规模。原则上，几乎所有现有的内部服务、数据库、 API 和工作流都可以封装成 Agent 可理解、可调用的标准化工具接口。这就是像 MCP 这样的协议旨在解决的问题——成为 Agent 时代的“TCP/IP”，解决连接性问题。

但我们必须清醒地认识到一个事实：MCP 解决了“如何调用”的协议问题，而非“调用哪一个”的决策问题。虽然进阶模型（如一些研发中的 SOTA 模型）可能具备处理上下文数百个工具描述的能力，但这很难说是一种经济高效的方案。将上下文窗口视为稀缺资源，并尽量减少无效或低概率使用信息的载入，是控制成本和提高系统整体有效性的关键设计原则。

因此，工具检索（Tool Retrieval）在 2025 年底开始受到学术界和工业界的关注。其核心思路是：为所有工具描述建立一个专门的索引库（向量、关键词或混合索引）。当 Agent 需要调用工具时，它首先根据当前的对话上下文和任务目标生成一个针对工具功能的“查询（query）”。该查询对索引库进行快速搜索，仅召回最相关的少数几个（例如 Top-3）工具描述。这些描述被动态插入当前上下文，供 LLM 进行最终的选择和调用。

研究 [Ref 10] 表明，即使是简单的 BM25 关键词检索，也能为此任务提供强大的基线。当然，使用微调过的专用嵌入模型会带来更精确的匹配。

除了工具描述本身，Agent 的开发、测试和使用过程自然会积累一系列关于“如何正确使用工具”的元知识。例如：“处理客户退款请求时，依次调用工具 A 验证订单、工具 B 检查库存、工具 C 执行退款，其中参数 X 来自对话历史 Y。”这类“剧本”或“指南”文本是比工具描述更丰富、更具指导意义的上下文材料。

这些也应被纳入可检索系统：当 Agent 面临复杂任务时，它可以先检索相关的任务指南，将其作为上下文的一部分。这让 LLM 能够“开卷考试”，按照最佳实践规划行动。

这类工具使用指南数据的量级和数据密度可能远超工具描述本身。高效利用无疑依赖于检索技术。Dspy 框架中的 GEPA 优化器 [Ref 11] 等早期探索使用遗传算法来演化出更好的 Prompt（可能包含工具使用逻辑），但其焦点在于优化 Prompt 文本本身。

更系统化的工作，如 ACE（Agentic Context Engineering）框架 [Ref 12]，开始研究如何以结构化的方式生成、管理和利用这些指导性上下文。虽然这不是本文的重点，但我们必须认识到这代表了上下文工程深化的一个重要方向。此类工作的成果不可避免地需要被纳入检索涵盖的体系中，与工具描述一起提供上下文。

记忆值得成为一个独立的基础设施吗？

在 2025 年的技术讨论中，“记忆（Memory）”获得的关注远超 RAG，在文章和产品推介中常被列为核心 Agent 基础设施组件，甚至出现了“记忆将取代 RAG”这种模糊边界的观点。那么，记忆到底是什么？无数开源记忆项目与 RAG 系统在核心上有何异同？

简单来说，记忆系统的出现最初是为了满足有效管理和重用历史 Agent 交互信息的需求。其基本使用模式与 RAG 完全一致：当新的对话发生时，系统根据当前查询从存储的历史记录中检索相关的过去对话片段（例如：同一用户的先前问题、LLM 之前的回答、用户反馈）。然后，这些片段随新问题一起提交给 LLM，帮助模型保持对话连贯性、记住用户偏好或避免重复。

因此，从功能接口和核心技术（检索）来看，记忆与 RAG 源出一脉。

它们的根本区别在于数据源和管理目标：

• RAG：主要处理预先存在的、相对静态的企业私有知识资产（文档、手册、知识库文章）。其目标是提供领域事实和背景知识。
• 记忆：主要处理 Agent 运行过程中动态生成的交互日志及派生数据（用户输入、LLM 输出、可能的交互状态、LLM 生成的摘要/反思）。其目标是维持对话连续性，实现个性化，并从历史经验中学习。

随着研究的深入，记忆系统内部的数据组织出现了更精细的划分，借鉴了认知科学的思想和概念：工作记忆、情节记忆、语义记忆、元记忆等。这些不同的“记忆区域”可以类比为数据库中的不同表或集合。

记忆系统的复杂性不仅在于存储和检索，更多在于记忆管理逻辑：何时以及如何将新生成的原始对话写入记忆？何时触发 LLM 对对话片段进行总结并存储在语义记忆中？如何在不同记忆片段之间建立关联？

这些“记忆流转、处理和生命周期管理”的功能与 RAG 系统中的摄入流水线完全相同，只不过它们处理的是动态生成的流式数据。

如果我们放宽视野，在记忆系统内划定一个区域（或建立一个紧密链接的知识库）来存储和检索上述工具使用指南，那么一个支持 AI Agent 的完整数据基座蓝图就浮现了出来：

这张蓝图清晰地显示：记忆（处理动态交互数据）和 RAG（处理静态领域知识）在技术上同源（均基于检索），在功能上互补。它们共同构成了 AI Agent 所依赖的完整数据基座。

所有的 Agent 数据访问需求——无论是现有的非结构化文档（通过 RAG）、实时生成的交互日志（通过记忆），还是结构化的服务接口（通过 MCP 封装，其元数据、使用指南和教程可在专门知识库中检索）——都可以在一个集成平台内统一、治理和访问。

这个平台正是 RAGFlow 等系统正在进化的方向：上下文引擎（Context Engine）或上下文平台。它不再是一个孤立的检索工具，而是一个为 AI 应用提供全面、智能的上下文组装服务的基础设施。

具有前瞻性的术语“上下文平台（Context Platform）”最初可能是由投资公司 Theory Ventures 在其系列文章中系统阐述的 [Ref 13, 14]。事实上，这家富有远见的公司早在 2024 年就明确强调了检索对 LLM 应用的根本重要性 [Ref 15]。今天，如何将侧重技术的检索引擎升级为上下文引擎，正在成为 AI Agent 能否实现规模化、经济高效的企业级应用的关键决定因素。

正如上述综合分析所示，许多所谓的“Agent 智能”问题本质上仍在于能否在正确的时间找到正确的信息并呈现给 LLM。如果 Agent 有一个强大的“外脑”（上下文引擎）帮助其高效搜索、过滤、验证并组织所有相关数据，最终的用户体验和结果将远超仅依赖庞大参数和复杂 Prompt 的“裸”模型。

从上下文工程到上下文引擎/平台的演进预示着，上下文的创建、管理和交付正从高度依赖专家的手工活转向高度自动化、产品化和运营化的平台科学。

目前，开发自定义 Agent 通常需要投入大量的工程和数据科学精力，手动编写复杂的 Prompt 模板，精心设计上下文拼接逻辑，并将其硬编码进工作流编排中。这种方法难以维护、无法扩展，且会导致混乱的上下文所有权和更新流程。

未来的上下文平台旨在改变现状：

• 自动化：上下文创建将通过与数据源的深度整合实现自动化，并保持持续同步和更新。
• 动态化：上下文交付将不再是硬编码。相反，平台统一的检索和编排层将根据每次对话的实时意图，动态地从各种数据源中检索并组装上下文。
• 可治理：上下文维护将从供应商主导的人工服务转向自动化、客户可管理、视觉化配置的过程。上下文的所有权和控制权将明确归属于客户。

这种范式转变是巨大的。企业 AI 落地的核心价值正从追求“最聪明的模型”和“最巧妙的 Prompt”回归到构建“最丰富、最准确、最可用的上下文”。

上下文的质量、实时性、动态组装能力和产品化水平将直接决定下一代企业 AI 应用的竞争力。上下文产品将是解锁大规模 AI 应用的最后一把钥匙。它标志着企业 AI 正式从早期的“手工作坊”阶段过渡到“平台化、规模化、可持续运营”的工业时代。

多模态 RAG 进展如何？

在我们的 2024 年度回顾中，我们曾预测基于“延迟交互（late interaction）”的多模态 RAG 将成为 2025 年的技术关键词。然而，这一预测并未完全兑现。这是否意味着多模态 RAG 缺乏实际意义？答案显然是否定的。

以针对医学文献设计的基准数据集 M3Retrieve [Ref 4] 的测试结果为例，多模态 RAG 的价值和定位得到了清晰展示：

• 在文本-图像结合任务中表现卓越：在视觉上下文检索或基于图像的问答等场景下，同时利用文本和视觉信息的多模态 RAG 表现显著优于纯文本方案。
• 在以文本为主的任务中优势较小：对于摘要生成或纯文本病历检索等任务，成熟的单模态 RAG 凭借其效率和精度依然保持优势。

因此，生产级多模态 RAG 绝非简单拼接图像和文本模型。其核心需求是实现真正的跨模态检索与理解。从技术上讲，多模态 RAG 无疑是 RAG 系统深化并覆盖更广泛数据类型的必然方向。

目前，处理图像和其他多模态文档存在两条主要技术路径：

1. 模态转换路径：利用 OCR 或 VLM 将图像、表格等转换为纯文本描述。这将多模态问题简化为单模态文本检索问题。它与现有的文本 RAG 架构兼容，但存在丢失原始视觉布局、颜色和精细特征的风险。
2. 原生多模态路径：直接对图像进行视觉 Token 化，与文本 Token 一起输入统一的多模态编码器，生成融合的多向量表示。在检索排序期间，延迟交互模型支持进行细粒度的相似度计算。

Google DeepMind 在今年 9 月发布的一篇理论指导性文章 [Ref 5] 指出：基于单一全局向量的检索存在固有的语义损失，而使用多向量（高维张量）则能更完整地保留文档的细粒度语义信息。

既然有如此明显的理论优势，为什么 2025 年还没有出现成熟的产品化多模态 RAG 方案？根本原因在于从原型到稳定产品的工程挑战尚未完全克服。

跨模态检索工程化的首要挑战是确定召回单元和策略。将文档“页面”作为召回单元是常见的做法。具体的实现方案包括：

• 混合索引方案：为文本内容构建全文和单向量索引，为图像构建独立的张量索引。检索时进行混合搜索并融合这三个索引的结果。
• 文本先行、张量重排方案：仅利用从 PDF 解析出的文本构建全文和单向量索引进行初始召回。然后，使用从整页图像生成的张量表示对初始结果进行更精细的重排序。该方案也可用于纯文本检索以获得更好的语义召回。
• 纯张量检索方案：完全依赖张量索引。对于跨模态页面，分别计算查询与文本张量及图像张量的相似度，取最大值作为页面的最终相关性得分。

虽然技术上可行，但这些方案都面临一个棘手的工程瓶颈：由于 Token 数量巨大导致张量数据激增，进而引发存储和计算成本爆炸。

假设像 ColPali 这样的模型为每个页面图像输出 1024 个 Token（每个对应一个特征向量），向量维度为 128 且采用 float32 精度，则单个页面的张量数据约占 512KB。对于百万页规模的文档库，索引大小将激增至 TB 级别——这对存储成本、内存加载和检索延迟都是巨大的挑战。

为了推动多模态 RAG 迈向实际工程化，目前主要有两条技术路径：

• 张量量化压缩：对张量中的每个向量进行二值化或低比特量化（如 1-bit），将存储空间压缩至原始大小的 1/32 或更低。代价是会有一定的精度损失。可行性取决于能否训练出对量化具有鲁棒性的专用嵌入模型。
• Token 剪枝：显著减少每个页面图像生成的 Token 数量，例如从 1024 个减少到 128 个或更少。具体方法包括：
  • 随机投影：将大量 Token 的向量投影到单个高维向量（如 10k 维），如 MUVERA 算法 [Ref 6]。计算效率高，但会丢失大量细粒度信息。
  • Token 聚类：对生成的 Token 向量进行无监督聚类，使用聚类中心代表原始集合。这不需要修改模型，但也会牺牲精度。
  • 模型侧 Token 剪枝：修改 Embedding 模型（尤其是其底层的 VLM），使其基于内部注意力机制主动输出更少但信息更丰富的“精炼”Token。这是最根本的方法。

因此，多模态 RAG 的成熟不仅需要底层检索引擎原生且高效地支持张量索引（Tensor Index）和张量重排（Tensor Reranker）组件，还依赖于更广泛的 AI 社区生产出更多对量化友好且支持自适应 Token 剪枝的下一代多模态 Embedding 模型。

这些发展是协同的：缺乏成熟易用的检索引擎会阻碍新模型在真实场景中的验证和迭代；而没有高效模型，检索引擎也无用武之地。所幸，这一话题正受到广泛关注，一场专门讨论延迟交互的研讨会已定于 2026 年初举行 [Ref 7]。

展望 2026 年，随着 AI 基础设施层对张量计算和存储支持的完善，我们可以预见更多量身定制、更优越的多模态工程化模型将会涌现，从而真正解锁跨模态 RAG 的实践潜力。

其工程化实现将自然催生出对多模态上下文的广泛需求。例如，能够同时理解和记忆文本、图像甚至视频的“多模态记忆”系统已不再仅仅是理论概念，而是已经进入了原型开发阶段 [Ref 16]。

展望 2026 年

进入 2026 年，企业对 LLM 应用的关注将不可避免地从概念验证和早期实验转向务实的大规模采用和投资回报率（ROI）。在这一过程中，RAG 技术作为所有 AI 应用的基础数据层，将迎来一波更稳健、更系统化的建设浪潮。

尽管 AI Agent 在复杂企业场景中的最终价值和形式仍处于广泛探索中，但 RAG 对所有 Agent——乃至所有 LLM 应用——的基础支撑作用，已成为越来越多技术决策者的共识。

一个明显的趋势是，许多企业已率先开始构建以“AI 中台”或“智能数据基座”为核心的能力，其核心正是基于 RAG 引擎构建的非结构化数据处理和供给平台。相比之下，上层 Agent 的具体开发和部署则可以在这一稳定的基础上以更灵活、更渐进的节奏进行。

如果用一句话概括 2025 年至 2026 年 RAG 技术的演进轨迹和未来展望：RAG 正在经历深刻的自我蜕变，从“检索增强生成”的具体模式进化为以“智能检索”为核心能力的“上下文引擎”。

这一演进趋势现已不可逆转。它将从技术后端走向战略前沿，成为企业构建下一代智能基础设施不可或缺的核心组件。

而 RAGFlow 正是为这一宏大且明确的未来愿景而打造。我们构建的不仅是一个开源、高效的 RAG 系统，更是通往“上下文引擎”时代的关键基石和驱动力。

从我们在 DeepDoc 多模态解析和语义增强方面的深耕，到探索 TreeRAG 等前沿架构以弥合语义鸿沟，再到构建服务于 Agent 的上下文引擎——RAGFlow 的每一次迭代都旨在将本文讨论的技术方向转化为稳定、易用且高性能的产品能力，稳步将企业智能从概念推向现实。

我们坚信，以检索为中心的上下文引擎是释放 LLM 和 Agent 全部潜力的关键。

请持续关注 RAGFlow 的演进，访问 GitHub 为我们点亮 star，并与全球开发者一起见证并构建下一代企业 AI 基础设施。

参考文献

1. AlayaDB: 支撑高效且有效的长上下文 LLM 推理的数据基座 https://arxiv.org/abs/2504.10326?
2. https://github.com/VectifyAI/PageIndex
3. 企业知识检索的系统化框架：利用 LLM 生成的元数据增强 RAG 系统 https://arxiv.org/abs/2512.05411
4. M3Retrieve：医学多模态检索基准测试 https://arxiv.org/abs/2510.06888
5. 关于基于嵌入的检索的理论局限性 https://arxiv.org/abs/2508.21038
6. MUVERA：通过固定维度编码实现多向量检索 https://arxiv.org/abs/2405.19504
7. https://www.lateinteraction.com/
8. https://hugging-face.cn/blog/QuentinJG/introducing-vidore-v3
9. 诞生才一周年，MCP凉了 https://mp.weixin.qq.com/s/LskoLb8g6t_PCGNSvlLh6g
10. https://hugging-face.cn/datasets/bowang0911/ToolSearch
11. Dspy GEPA https://dspy.org.cn/api/optimizers/GEPA/overview/
12. Agentic Context Engineering：为自我改进的语言模型演进上下文 https://arxiv.org/abs/2510.04618
13. 为什么业务上下文层是让 AI 在企业中发挥作用的关键 https://theoryvc.com/blog-posts/business-context-layer
14. 从上下文工程到上下文平台 https://theoryvc.com/blog-posts/from-context-engineering-to-context-platforms
15. https://www.linkedin.com/pulse/every-llm-company-search-hard-future-retrieval-systems-7zigc/
16. MemVerse：终身学习智能体的多模态记忆 https://arxiv.org/abs/2512.03627

背景

从 0.22.0 版本开始，RAGFlow 不再提供内置 Embedding 模型的完整 Docker 镜像。此前，部分用户依赖该镜像中捆绑的 Embedding 模型来构建数据集。

升级到 0.22.0 后，这些模型不再可用，导致了几个问题：数据集原先使用的 Embedding 模型丢失；无法添加新文档；数据集中的检索功能无法正常工作；并且由于旧的逻辑限制，无法切换到新的 Embedding 模型。为了解决升级后的这些兼容性问题，我们在 0.22.1 版本中引入了重要的改进。

0.22.1 版本功能

包含已解析数据的知识库现支持更换嵌入模型

从 RAGFlow 0.22.1 开始，引入了更安全、自动化的 Embedding 兼容性检查，允许用户在已有数据的数据集上切换 Embedding 模型。为确保新的 Embedding 模型不会破坏原有的向量空间结构，RAGFlow 会执行以下检查：

1. 样本提取：从当前数据集中随机选择几个（例如 5-10 个）chunk 作为代表性样本。
2. 重新编码：使用用户选择的新 Embedding 模型为抽样的 chunk 生成新向量。
3. 相似度计算：对每个 chunk，计算新旧向量之间的余弦相似度。
4. 切换决策：如果平均相似度达到 0.9 或以上，则认为新旧模型在向量空间上足够一致，允许切换。如果低于 0.9，则拒绝模型切换请求。

为何使用 0.9 阈值？

阈值设为 0.9，是因为来自不同模型提供商的同名模型可能存在微小的版本差异，并且 RAGFlow 的 Embedding 也会因策略和参数而异，因此新模型无法完美复现旧的 Embedding 环境。这些“微小差异”通常仍能得到 0.9 以上的平均相似度，所以 0.9 可以很好地作为“可安全替换”模型的临界值。相比之下，来自完全不同模型家族的 Embedding（例如，从 MiniLM 到 BGE-M3）的相似度往往在 0.3–0.6 之间，因此它们会低于此阈值并被正确阻止，从而防止向量空间被打乱。

如何更换嵌入模型

1. 在模型设置界面配置一个新模型，以替换无法使用的默认模型。

2. 进入数据集的配置页面，从新的提供商中选择相同的模型名称，并等待模型切换完成。

如果切换 Embedding 模型失败，将出现错误消息。

3. 进入检索测试，自行评估新的 Embedding 模型。

现在，聊天应用中涉及数据集检索的功能等已能正常工作。

我们未来的版本将提供更完善的升级工具和自动化功能，简化从旧版本的迁移过程，并减轻用户的维护负担。

1. 创建 Google Cloud 项目

您可以为 RAGFlow 创建一个专用项目，也可以使用现有的 Google Cloud 外部项目。

步骤

1. 打开项目创建页面
   https://console.cloud.google.com/projectcreate
2. 在 Audience 中选择 External
3. 点击 Create

2. 配置 OAuth 同意屏幕

1. 前往 API 和服务 → OAuth 同意屏幕
2. 确保 User Type = External
3. 通过输入电子邮件地址在 Test Users 下添加您的测试用户

3. 创建 OAuth 客户端凭据

1. 导航至
   https://console.cloud.google.com/auth/clients
2. 创建一个 Web Application
3. 为客户端输入一个名称
4. 添加以下 已获授权的重定向 URI

https://:9380/v1/connector/google-drive/oauth/web/callback

如果使用 Docker 部署：

已获授权的 JavaScript 来源

https://:80

如果从源码运行：

已获授权的 JavaScript 来源

https://:9222

5. 保存后，点击 Download JSON。该文件稍后将上传到 RAGFlow 中。

4. 添加作用域（Scopes）

1. 打开 数据访问 → 添加或移除范围

2. 粘贴并添加以下条目

https://www.googleapis.com/auth/drive.readonly
https://www.googleapis.com/auth/drive.metadata.readonly
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.user.readonly

3. 更新并保存更改

5. 启用所需的 API

导航到 Google API 库
https://console.cloud.google.com/apis/library

启用以下 API

• Google Drive API
• Admin SDK API
• Google Sheets API
• Google Docs API

6. 在 RAGFlow 中添加 Google Drive 作为数据源

1. 在 RAGFlow 中进入 数据源

2. 选择 Google Drive

3. 上传先前下载的 JSON 凭据

4. 输入共享的 Google Drive 文件夹链接 (https://drive.google.com/drive)，例如：

5. 点击 Authorize with Google。浏览器窗口将出现。 点击：- Continue - Select All → Continue - 授权应成功 - 选择 OK 以添加数据源

0.22 亮点介绍

构建一个 RAGFlow 数据集涉及三个主要步骤：文件上传、解析和分块。0.21.0 版本通过引入“摄入管道”（Ingestion pipeline）使解析和分块阶段变得更加灵活。

这次发布的 0.22.0 版本重点关注数据上传步骤，旨在帮助开发者更快地构建数据集。

我们还增加了以下关键改进

• “摄入管道”中的解析器（Parser）组件现在提供了更多模型选择，以实现更好的文件解析效果。
• 我们优化了智能体（Agent）的 检索（Retrieval） 和 等待响应（Await response） 组件。
• 全新的管理员界面（Admin UI）为您提供更清晰、更便捷的系统管理方式。

支持丰富的外部数据源

新增的“数据源”模块允许您将外部数据连接到数据集中。现在，您可以将来自不同位置的文件直接同步到 RAGFlow 中。

在您的个人中心使用“数据源”菜单，可以添加和设置 Confluence、AWS S3、Google Drive、Discord 和 Notion 等数据源。这让您能在一个地方管理所有数据，并实现自动同步。

示例：S3 配置

1. 请确保您的 AWS 账户中有一个 S3 存储桶。

2. 将您的 S3 详细信息添加到 S3 数据源表单中。

3. 添加后，点击设置图标查看数据源详情。

4. 如果您将“刷新频率（Refresh Freq）”设置为“1”，系统将每分钟检查一次新文件。
5. RAGFlow 会监控您指定的 S3 存储桶（例如 ragflow-bucket）。如果发现新文件，它会立即开始同步。
6. 同步完成后，系统会等待一分钟再进行下一次检查。您随时可以使用“暂停”按钮来开启或关闭此自动刷新功能。

将数据源关联至数据集

1. 创建一个新数据集（例如，TEST_S3）。
2. 点击 Configuration 并滚动到页面底部。
3. 点击 Link Data Source 并选择您想要的数据源（例如 S3）。

成功链接后，您将看到三个图标

• 重建（Rebuild）： 点击此按钮将删除数据集中的所有文件和日志，并重新导入所有内容。
• 设置（Settings）： 在这里查看同步日志。
• 取消链接（Unlink）： 这会断开数据源的连接。它会保留数据集中已有的所有文件，但停止新的同步。

日志中的状态消息

• 已计划（Scheduled）： 任务已进入队列，等待下一次检查文件。
• 运行中（Running）： 系统正在移动文件。
• 成功（Success）： 已完成新文件的检查。
• 失败（Failed）： 上传失败。请查看错误消息以获取详细信息。
• 取消（Cancel）： 您已暂停传输。

您可以将多个数据源链接到一个数据集中，一个数据源也可以为多个数据集提供数据。

增强型解析器

MinerU

RAGFlow 现在支持 MinerU 2.6.3 作为解析 PDF 的另一个选项。它支持多种后端，如 pipeline、vlm-transformers、vlm-vlm-engine 和 http-client。

原理很简单：RAGFlow 请求 MinerU 解析文件，读取结果，然后将它们添加到您的数据集中。

关键环境变量

启动

• 如果您使用 vlm-http-client 后端，请通过 MINERU_SERVER_URL 设置服务器地址。
• 要连接到远程的 MinerU 解析器，请使用 MINERU_APISERVER 提供其地址。

如何启动

1. 从源码启动： 单独安装 MinerU（其依赖项可能与 RAGFlow 的冲突）。然后设置环境变量并启动 RAGFlow 服务器。
2. 使用 Docker： 在 docker/.env 文件中设置 USE_MINERU=true 并重启您的容器。

Docling

RAGFlow 还支持 Docling 作为另一个 PDF 解析器。它的工作方式与 MinerU 相同。

Docling 会在文档中查找文本、公式、表格和图像。然后 RAGFlow 会使用 Docling 的发现。

Docling 的功能

1. 提取文本（段落、标题、列表）。
2. 提取数学公式。
3. 识别表格和图像（并保存它们）。
4. 标记所有内容的位置。

启动： 在 docker/.env 文件中设置 USE_DOCLING=true 并重启您的容器。

Agent 优化

检索现已支持元数据

您现在可以向数据集中的文件添加标签（元数据）。在检索过程中，智能体可以利用这些标签来筛选结果，从而只查看特定文件，而不是整个知识库。

示例： 假设有一个充满 AI 论文的数据集。其中一些是关于 AI 智能体的，另一些是关于 AI 评估的。如果您想要一个只回答评估问题的问答助手，可以为相关的论文添加一个标签，如 "Topic": "Evaluation"。当智能体检索信息时，它将筛选出带有该标签的文件。

以前，这只能在聊天应用中实现。现在，智能体的“检索”组件也可以做到这一点。

更出色的 Agent 协作能力

您现在可以在 等待响应（Await Response） 组件的消息中使用上游智能体的输出。

旧方式： “等待响应”组件中的消息总是静态文本。

新方式： 您可以插入工作流中较早步骤的动态内容，比如来自规划智能体的计划。

这对于“深度研究”智能体或任何需要人工在继续之前检查工作的场景都非常有用。它也是未来“摄入管道”改进的关键部分。

您可以在智能体模板库中找到这个用例，作为一个即用型模板。

管理后台 UI

该版本增加了一个全新的 管理员界面（Admin UI），这是一个为系统管理员设计的可视化仪表盘。

它将您过去需要通过命令完成的任务整合到一个简单的界面中，使管理变得更加容易。

即时查看系统状态

服务状态（Service Status） 仪表盘显示所有核心服务的健康状况。它列出了服务的名称、类型、主机、端口和状态。如果出现问题（例如 Elasticsearch 超时），您可以快速找到问题所在，并复制地址进行测试，而无需登录到不同的服务器。

该界面还显示服务详情。您可以看到详细的日志和连接信息（如数据库密码），而无需接触服务器命令行。这使得解决问题更快，并保持系统更透明、更安全。

轻松管理用户

用户管理（User Management） 部分允许您创建、启用、禁用、重置密码和删除用户。您可以按电子邮件或昵称快速查找用户，并查看他们拥有的数据集和智能体。

结语

RAGFlow 0.21.0 为您提供了强大的数据“摄入管道”。现在，RAGFlow 0.22.0 连接到您数据所在的所有地方。它们共同帮助您打破“数据孤岛”，将所有内容汇集一处，为您的 LLM 提供动力。

我们还改进了智能体与人的协作方式。现在您可以介入智能体的工作流程并指导它，以团队合作的方式获得比完全自动化更准确、更好的结果。

我们将继续添加更多的数据源、更好的解析器和更智能的管道，使 RAGFlow 成为您 LLM 应用的最佳数据基础。

GitHub: https://github.com/infiniflow/ragflow

参考

1. https://ragflow.com.cn/docs/faq#how-to-use-mineru-to-parse-pdf-documents

在金融机构投研部门的实际工作中，分析师每天都会接触到海量的行业和公司分析报告、第三方研究数据以及实时市场动态，信息来源多样且分散。金融分析师的工作是基于上述信息迅速制定清晰的投资建议，例如具体推荐买入哪些股票、如何调整投资组合配置，或预测行业的下一个走向。因此，我们开发了“智能投研助手”来帮助金融分析师快速整理信息。它可以自动捕获公司数据、整合财务指标并汇编研究报告观点，使分析师能够在几分钟内确定某只股票是否值得买入，无需在堆积如山的资料中搜寻，从而将时间集中在真正的投资决策上。为了实现这一目标，我们设计了一套完整的技术流程。

技术方案围绕一个核心业务流程展开

当分析师提出问题时，系统会从问题中识别公司名称或简称，并借助搜索引擎检索出相应的股票代码。如果识别失败，则直接返回公司代码的提示。成功获取股票代码后，系统从数据接口中调取该公司的核心财务指标，对数据进行整理和格式化，生成一张清晰的财务表格。在此基础上，智能分析进一步整合研报信息：一方面，它会采集最新的权威研报和市场观点；另一方面，它会从内部知识库中检索相关的研报内容。最终，这些整理好的财务数据和研报信息被组合成一份全面的回复，方便分析师快速审阅关键指标和核心观点。

编排后的工作流如下

本案例利用 RAGFlow 实现了一套完整的工作流程，从股票代码的提取，到公司财务报表的生成，再到最终研报信息的整合输出。

下文将详细介绍本方案的实现过程。

1. 准备数据集

1.1 创建数据集

本示例所需的数据集可以从 Hugging Face Datasets 下载1。

创建一个名为“内部股票研究报告”的数据集，并导入相应的数据集文档。

1.2 解析文档

对于“内部股票研究报告”数据集中的文档，我们选择了名为 Paper 的解析和切片方法。

研究报告文档通常包括摘要、核心观点、专题分析、财务预测表和风险提示等模块。整体结构更遵循论文式的逻辑递进，而非严格的层级目录。如果根据最低级别的标题进行切片，很容易破坏段落和表格之间的连贯性。

因此，RAGFlow 更适合采用“Paper”切片方法，以章节或逻辑段落为基本单位。这种方法不仅保留了研究报告结构的完整性，还有助于模型在检索时快速定位关键信息。

切片后的财务报告预览如下

2. 构建智能代理

2.1 创建应用程序

创建成功后，系统将在画布上自动生成一个“开始”节点。

在“开始”节点中，您可以设置助手的初始问候语，例如：“您好！我是您的股票研究助理。”

2.2 构建“提取股票代码”功能

2.2.1 Agent 提取股票代码

使用一个 Agent 节点并附加一个 TavilySearch 工具，用于从用户的自然语言输入中识别股票名称或简称，并返回一个唯一的标准股票代码。当未找到匹配项时，统一输出“未找到”。

在金融场景中，用户的自然语言往往是模糊的。例如：

• “帮我查一下苹果公司的研究报告。”
• “英伟达的财务表现如何？”
• “今天上证指数的情况怎么样？”

这些请求都包含与股票相关的信息，但系统只有在准确识别出股票代码后，才能进一步查询财务报告、研究报告或市场数据。

这就是为什么我们需要一个具有“提取股票代码”功能的 Agent。

以下是此 Agent 的系统提示词

<role> 

Your responsibility is: to identify and extract the stock name or abbreviation from the user's natural language query and return the corresponding unique stock code. 

</role> 



<rules> 

1. Only one result is allowed: - If a stock is identified → return the corresponding stock code only; - If no stock is identified → return “Not Found” only. 

2. **Do not** output any extra words, punctuation, explanations, prefixes, suffixes, or newline prompts. 3. The output must strictly follow the <response_format>. </rules>


<response_format>
Output only the stock code (e.g., AAPL or 600519)
Or output “Not Found”
</response_format>


<response_examples>
User input: “Please check the research report for Apple Inc.” → Output: AAPL
User input: “How is the financial performance of Moutai?” → Output: 600519
User input: “How is the Shanghai Composite Index performing today?” → Output: Not Found
</response_examples>


<tools> - Tavily Search: You may use this tool to query when you're uncertain about the stock code. - If you're confident, there's no need to use the tool. 

</tools> 



<Strict Output Requirements> - Only output the result, no explanations, prompts, or instructions allowed. - The output can only be the stock code or “Not Found,” otherwise, it will be considered an incorrect answer.

 </Strict Output Requirements>

2.2.2 识别股票代码的条件节点

使用一个条件节点来评估前一个 Agent 节点的输出结果，并根据不同的结果引导流程走向

• 如果输出是股票代码：表示成功识别了股票，流程将进入“Case1”分支。
• 如果输出包含“未找到”：表示未从用户输入中识别出有效的股票名称，流程将进入“Else”分支，执行一个回复无关消息的节点，输出“您的查询不支持”。

2.3 构建“公司财务报表”功能

此功能的数据来源于雅虎财经提供的财务数据。通过调用此 API，我们获取指定股票的核心财务数据，包括营业收入、净利润等，从而驱动“公司财务报表”的生成。

2.3.1 Yahoo Finance 工具：请求财务数据

通过使用“雅虎财经工具”节点，选择“资产负债表”并将上游 Agent 输出的 stockCode 作为参数传递。这使您能够获取相应公司的核心财务指标。

返回的结果包含总资产、总权益和有形账面价值等关键数据，用于生成“公司财务报表”功能。

2.3.2 Code 节点生成财务表格

利用代码节点，通过 Python 脚本对雅虎财经工具返回的财务数据进行字段映射和数值格式化，最终生成一个带有双语指标对比的 Markdown 表格，从而实现“公司财务报表”的清晰直观展示。

代码

import re

def format_number(value: str) -> str:
    """Convert scientific notation or floating-point numbers to comma-separated numbers"""
    try:
        num = float(value)
        if num.is_integer():
            return f"{int(num):,}"  # If it's an integer, format without decimal places
        else:
            return f"{num:,.2f}"  # Otherwise, keep two decimal places and add commas
    except:
        return value  # Return the original value if it's not a number (e.g., — or empty)

def extract_md_table_single_column(input_text: str) -> str:
    # Use English indicators directly
    indicators = [
        "Total Assets", "Total Equity", "Tangible Book Value", "Total Debt", 
        "Net Debt", "Cash And Cash Equivalents", "Working Capital", 
        "Long Term Debt", "Common Stock Equity", "Ordinary Shares Number"
    ]
  
    # Core indicators and their corresponding units
    unit_map = {
        "Total Assets": "USD",
        "Total Equity": "USD",
        "Tangible Book Value": "USD",
        "Total Debt": "USD",
        "Net Debt": "USD",
        "Cash And Cash Equivalents": "USD",
        "Working Capital": "USD",
        "Long Term Debt": "USD",
        "Common Stock Equity": "USD",
        "Ordinary Shares Number": "Shares"
    }

    lines = input_text.splitlines()

    # Automatically detect the date column, keeping only the first one
    date_pattern = r"\d{4}-\d{2}-\d{2}"
    header_line = ""
    for line in lines:
        if re.search(date_pattern, line):
            header_line = line
            break

    if not header_line:
        raise ValueError("Date column header row not found")

    dates = re.findall(date_pattern, header_line)
    first_date = dates[0]  # Keep only the first date
    header = f"| Indicator | {first_date} |"
    divider = "|------------------------|------------|"

    rows = []
    for ind in indicators:
        unit = unit_map.get(ind, "")
        display_ind = f"{ind} ({unit})" if unit else ind

        found = False
        for line in lines:
            if ind in line:
                # Match numbers and possible units
                pattern = r"(nan|[0-9\.]+(?:[eE][+-]?\d+)?)"
                values = re.findall(pattern, line)
                # Replace 'nan' with '—' and format the number
                first_value = values[0].strip() if values and values[0].strip().lower() != "nan" else "—"
                first_value = format_number(first_value) if first_value != "—" else "—"
                rows.append(f"| {display_ind} | {first_value} |")
                found = True
                break
        if not found:
            rows.append(f"| {display_ind} | — |")

    md_table = "\n".join([header, divider] + rows)
    return md_table

def main(input_text: str):
    return extract_md_table_single_column(input_text)

我们也收到了大家希望不通过编码提取 JSON 字段的请求，我们将在未来的版本中逐步提供解决方案。

2.4 构建“研报信息提取”功能

利用信息提取代理，根据 stockCode 调用 AlphaVantage API 提取最新的权威研究报告和见解。同时，它调用内部研究报告检索代理以获取完整研究报告的全文。最后，它以固定结构分别输出这两部分内容，从而实现高效的信息提取功能。

系统提示词

<role> 

You are the information extraction agent. You understand the user’s query and delegate tasks to alphavantage and the internal research report retrieval agent. 

</role> 

<requirements>

 1. Based on the stock code output by the "Extract Stock Code" agent, call alphavantage's EARNINGS_CALL_TRANSCRIPT to retrieve the latest information that can be used in a research report, and store all publicly available key details.


2. Call the "Internal Research Report Retrieval Agent" and save the full text of the research report output. 

3. Output the content retrieved from alphavantage and the Internal Research Report Retrieval Agent in full. 

</requirements>


<report_structure_requirements>
The output must be divided into two sections:
#1. Title: “alphavantage”
Directly output the content collected from alphavantage without any additional processing.
#2. Title: "Internal Research Report Retrieval Agent"
Directly output the content provided by the Internal Research Report Retrieval Agent.
</report_structure_requirements>

2.4.1 配置 MCP 工具

添加 MCP 工具

在代理下添加 MCP 工具并选择所需的方法，例如“EARNINGS_CALL_TRANSCRIPT”。

2.4.2 内部研报检索 Agent

构建内部研究报告检索代理的关键在于准确识别用户查询中的公司或股票代码。然后，它调用检索工具从数据集中搜索研究报告并输出全文，确保数据、观点、结论、表格和风险提示等信息不被遗漏。这实现了研究报告内容的高保真提取。

系统提示词

<Task Objective> 

Read user input → Identify the involved company/stock (supports abbreviations, full names, codes, and aliases) → Retrieve the most relevant research reports from the dataset → Output the full text of the research report, retaining the original format, data, chart descriptions, and risk warnings. 

</Task Objective>



<Execution Rules> 

1. Exact Match: Prioritize exact matches of company full names and stock codes. 

2. Content Fidelity: Fully retain the research report text stored in the dataset without deletion, modification, or omission of paragraphs. 

3. Original Data: Retain table data, dates, units, etc., in their original form. 

4. Complete Viewpoints: Include investment logic, financial analysis, industry comparisons, earnings forecasts, valuation methods, risk warnings, etc. 

5. Merging Multiple Reports: If there are multiple relevant research reports, output them in reverse chronological order. 

6. No Results Feedback: If no matching reports are found, output “No related research reports available in the dataset.”



 </Execution Rules>

2.5 添加研报生成 Agent

研究报告生成代理自动提取并结构化组织财务和经济信息，为投资银行分析师生成专业、保留差异化且可直接用于投资研究报告的基础数据和内容。

<role> 

You are a senior investment banking (IB) analyst with years of experience in capital market research. You excel at writing investment research reports covering publicly listed companies, industries, and macroeconomics. You possess strong financial analysis skills and industry insights, combining quantitative and qualitative analysis to provide high-value references for investment decisions. 

**You are able to retain and present differentiated viewpoints from various reports and sources in your research, and when discrepancies arise, you do not merge them into a single conclusion. Instead, you compare and analyze the differences.** 


</role> 




<input> 

You will receive financial information extracted by the information extraction agent.

 </input>


<core_task>
Based on the content returned by the information extraction agent (no fabrication of data), write a professional, complete, and structured investment research report. The report must be logically rigorous, clearly organized, and use professional language, suitable for reference by fund managers, institutional investors, and other professional readers.
When there are differences in analysis or forecasts between different reports or institutions, you must list and identify the sources in the report. You should not select only one viewpoint. You need to point out the differences, their possible causes, and their impact on investment judgments.
</core_task>


<report_structure_requirements>
##1. Summary
Provide a concise overview of the company’s core business, recent performance, industry positioning, and major investment highlights.
Summarize key conclusions in 3-5 sentences.
Highlight any discrepancies in core conclusions and briefly describe the differing viewpoints and areas of disagreement.
##2. Company Overview
Describe the company's main business, core products/services, market share, competitive advantages, and business model.
Highlight any differences in the description of the company’s market position or competitive advantages from different sources. Present and compare these differences.
##3. Recent Financial Performance
Summarize key metrics from the latest financial report (e.g., revenue, net profit, gross margin, EPS).
Highlight the drivers behind the trends and compare the differential analyses from different reports. Present this comparison in a table.
##4. Industry Trends & Opportunities
Overview of industry development trends, market size, and major drivers.
If different sources provide differing forecasts for industry growth rates, technological trends, or competitive landscape, list these and provide background information. Present this comparison in a table.
##5. Investment Recommendation
Provide a clear investment recommendation based on the analysis above (e.g., "Buy/Hold/Neutral/Sell"), presented in a table.
Include investment ratings or recommendations from all sources, with the source and date clearly noted.
If you provide a combined recommendation based on different viewpoints, clearly explain the reasoning behind this integration.
##6. Appendix & References
List the data sources, analysis methods, important formulas, or chart descriptions used.
All references must come from the information extraction agent and the company financial data table provided, or publicly noted sources.
For differentiated viewpoints, provide full citation information (author, institution, date) and present this in a table.
</report_structure_requirements>


<output_requirements>
Language Style: Financial, professional, precise, and analytical.
Viewpoint Retention: When there are multiple viewpoints and conclusions, all must be retained and compared. You cannot choose only one.
Citations: When specific data or viewpoints are referenced, include the source in parentheses (e.g., Source: Morgan Stanley Research, 2024-05-07).
Facts: All data and conclusions must come from the information extraction agent or their noted legitimate sources. No fabrication is allowed.
Readability: Use short paragraphs and bullet points to make it easy for professional readers to grasp key information and see the differences in viewpoints.
</output_requirements>


<output_goal>
Generate a complete investment research report that meets investment banking industry standards, which can be directly used for institutional investment internal reference, while faithfully retaining differentiated viewpoints from various reports and providing the corresponding analysis.
</output_goal>



<heading_format_requirements>
All section headings in the investment research report must be formatted as N. Section Title (e.g., 1. Summary, 2. Company Overview), where:
The heading number is followed by a period and the section title.
The entire heading (number, period, and title) is rendered in bold text (e.g., using <b> in HTML or equivalent bold formatting, without relying on Markdown ** syntax).
Do not use ##, **, or any other prefix before the heading number.
Apply this format consistently to all section headings (Summary, Company Overview, Recent Financial Performance, Industry Trends & Opportunities, Investment Recommendation, Appendix & References).
</heading_format_requirements>

2.6 添加回复消息节点

回复消息节点用于输出工作流程最终产出的“财务报表”和“研究报告内容”。

2.7 保存并测试

点击“保存”-“运行”- 并查看执行结果。整个过程大约需要 5 分钟才能运行。执行结果

日志：整个过程大约需要 5 分钟才能运行。

总结与展望

本案例研究使用 RAGFlow 构建了一个完整的股票研究报告工作流程，包含三个核心步骤

1. 利用 Agent 节点从用户输入中提取股票代码。
2. 通过雅虎财经工具和代码节点获取并格式化公司财务数据，以生成清晰的财务报表。
3. 调用信息提取代理和内部研究报告检索代理，并使用研究报告生成代理分别输出最新的研究报告见解和完整研究报告的全文。

整个过程实现了从股票代码识别到财务和研究报告信息整合的自动化处理。

我们观察到几个可持续发展的方向：可以纳入更多的数据源，使分析结果更全面，同时提供一种无代码的数据处理方法以降低入门门槛。该系统还有潜力分析同一行业内的多家公司，跟踪行业趋势，甚至覆盖更广泛的投资工具，如期货和基金，从而协助分析师形成更优的投资组合。随着这些功能的逐步实现，智能投研助手不仅能帮助分析师更快地做出判断，还能建立一套高效、可复用的研究方法论，使团队能够持续产出高质量的分析成果。

GitHub 2025年度Octoverse报告的发布，对开源生态系统而言是一个关键时刻，对于像RAGFlow这样的项目也是如此。今年，RAGFlow已成为贡献者增长最快的开源项目之一。凭借其在贡献者参与度上高达2596%的同比增长，RAGFlow不仅仅是获得了关注，更是在定义下一波由AI驱动的开发浪潮。

检索增强生成（RAG）在生产环境中的崛起

正如Octoverse报告所强调的，人工智能已不再是实验性的，而是基础性的。GitHub上现在有超过430万个与AI相关的代码仓库，并且有超过110万个公共仓库导入了LLM SDK，同比增长了178%。在这样的背景下，RAGFlow的迅速普及标志着一个明显的转变：开发者正在从原型验证阶段转向生产级的AI工作流。

RAGFlow——一个内置Agent功能的端到端检索增强生成引擎，完美地满足了这一需求。它使开发者能够构建可扩展、具备上下文感知能力的AI应用程序，这些应用既强大又实用。正如报告所指出的，“AI基础设施正成为吸引开源贡献的主要磁石”，而RAGFlow正好处在AI基础设施与实际可用性的交汇点上。

为什么 RAGFlow 在 AI 时代引发共鸣

Octoverse报告中强调的几个趋势与RAGFlow的设计和使命紧密相连

• 从Notebook到生产环境：报告指出，项目正从Jupyter Notebooks（同比增长75%）转向Python代码库，这表明AI项目正在走向成熟。RAGFlow通过提供一个结构化、可复现的框架来支持这一转变，用于在生产环境中部署RAG系统。
• Agent工作流正成为主流：随着GitHub Copilot编程Agent的推出和AI辅助开发的兴起，开发者越来越依赖能够自动化复杂任务的工具。RAGFlow内置的Agent功能允许团队自动化检索、推理和响应生成——这些都是现代AI应用的关键组成部分。
• 安全性和可扩展性是首要考虑：报告还强调了“失效的访问控制”漏洞同比增长了172%，凸显了设计安全的AI系统的必要性。RAGFlow专注于企业级部署，帮助团队直面这些挑战。

一个处于活跃开发中的项目

RAGFlow的演进反映了一段深思熟虑的历程——从解决基础的RAG挑战，到塑造下一代企业AI基础设施。

该项目最初通过集成技术创新，系统性地解决了核心RAG的局限性，从而崭露头角。凭借深度文档理解（用于解析复杂格式）、融合多种搜索策略的混合检索，以及内置的GraphRAG和RAPTOR等先进工具，RAGFlow将自己打造为一个端到端的解决方案，极大地提升了检索准确性和推理性能。

现在，基于这一坚实的技术基础，RAGFlow正朝着一个更大胆的愿景迈进：成为企业级Agent的卓越上下文引擎。从一个专业的RAG引擎演变为一个统一、有弹性的上下文层，RAGFlow正将自己定位为企业中大语言模型（LLM）的必要数据基础——使任何类型的Agent都能访问丰富、精确且安全的上下文，确保在所有任务中可靠且有效地运行。

RAGFlow 是一款开源的检索增强生成（RAG）引擎，旨在构建生产级 AI 应用。欲了解更多信息或参与贡献，请访问 RAGFlow GitHub 仓库。

本文灵感源自 GitHub Octoverse 2025 报告 的洞察。特别鸣谢 GitHub 团队，为全球各地的开源建设者发声。

自开源以来，RAGFlow 一直持续受到社区的广泛关注。其核心模块 DeepDoc 利用内置的文档解析模型，为多种业务场景提供了智能化的文档分片能力，确保 RAGFlow 在检索和生成阶段都能提供准确、高质量的回答。目前，RAGFlow 预集成了十余种文档分片模板，覆盖了各类业务场景和文件类型。

然而，随着 RAGFlow 在生产环境中的应用日益广泛，原有的十余种固定分片方式已难以满足所遇到的复杂多样的数据源、文档结构和文件类型。具体挑战包括：

• 需要根据特定业务场景，灵活配置不同的解析和分片策略，以适应多变的文档结构和内容逻辑。
• 文档解析和录入不仅涉及将非结构化数据分割成文本块，还包含一系列关键的预处理步骤，以弥合RAG检索过程中的“语义鸿沟”。这通常需要利用模型为原始内容丰富语义信息，如摘要、关键词和层次结构。
• 除了本地上传的文件，大量的数据、文件和知识源于各种渠道，包括云盘和在线服务。
• 随着多模态视觉语言模型（VLM）的成熟，涌现出像 MinerU 和 Docling 这样在解析复杂布局、表格和图文混排文档方面表现出色的模型。这些模型在不同应用场景中展现出独特的优势。

为应对这些挑战，RAGFlow 0.21.0 推出了开创性的 Ingestion Pipeline。该流水线重构了非结构化数据的清洗流程，允许用户根据特定业务需求构建定制化的数据处理流水线，并实现对异构文档的精准解析。

Ingestion Pipeline 本质上是一个为非结构化数据量身定制的可视化 ETL 流程。它基于 Agent 构建，将一个典型的 RAG 数据录入工作流——通常包含文档解析、文本分块、向量化和索引构建等关键阶段——重构为三个不同的阶段：Parser、Transformer 和 Indexer。这些阶段分别对应文档解析、数据转换和索引构建。

• 文档解析（Document Parsing）：作为数据清洗的关键步骤，该模块集成了多种解析模型，DeepDoc 是其中的代表。它将原始的非结构化数据转换为半结构化内容，为后续处理奠定基础。
• 数据转换（Data Transformation）：目前提供两类核心算子，包括 Chunker 和 Transformer。该阶段旨在将清洗后的数据进一步处理成适合各种索引访问方式的格式，从而确保高质量的召回性能。
• 索引构建（Index Construction）：负责最终的数据写入。RAGFlow 内在采用多路召回架构以保证检索效果。因此，Indexer 集成了多种索引方法，允许用户灵活配置。

下面，我们将通过一个具体示例来演示 Ingestion Pipeline 的构建和使用。

首先，在“Agent”页面点击“创建Agent”。您可以选择“从空白创建”来从头构建一个 Ingestion Pipeline。

或者，您也可以选择“从模板创建”，利用预配置的 Ingestion Pipeline 模板。

接下来，我们将开始编排流水线所需的各种算子。从零开始创建时，初始画布上仅显示 Begin 和 Parser 算子。随后，您可以从现有算子的右侧拖拽并连接具有不同功能的其他算子。

首先，需要配置 Parser 算子。

解析器 (Parser)

Parser 算子负责读取和解析文档：识别其布局、提取其结构和文本信息，并最终获得结构化的文档数据。

这是一种“高保真、结构化”的提取策略。Parser 能够智能地适应并保留不同文件的原始特征，无论是 Word 文档的层级大纲、电子表格的行列布局，还是扫描版 PDF 的复杂版式。它不仅提取正文，还完整保留标题、表格、页眉和页脚等辅助信息，并将它们转化为适当的数据形式，具体内容将在下文详述。这种结构化的区分至关重要，为后续的精细化处理提供了必要的基础。

目前，Parser 算子支持 8 大类共 23 种文件类型的输入，总结如下：

使用时，只需在 Parser 节点内点击“添加 Parser”并选择所需的文件类别（如 PDF、Image 或 PPT）。当 Ingestion Pipeline 运行时，Parser 节点会自动识别输入文件，并将其路由到相应的解析器进行解析。

在此，我们对几种常见文件类别的解析器作进一步说明：

• 对于 PDF 文件，RAGFlow 提供了多种解析模型选项，统一输出为 JSON 格式：

  1. 默认 DeepDoc：这是 RAGFlow 的内置文档理解模型，能够识别布局、分栏和表格。它适用于处理扫描文档或格式复杂的文档。
  2. MinerU：目前业界优秀的文档解析模型之一。除了解析复杂的文档内容和布局外，MinerU 还为数学公式等复杂文件元素提供了出色的解析能力。
  3. Naive：一种不使用任何模型的纯文本提取方法。它适用于没有复杂结构或非文本元素的文档。

• 对于 Image 文件，系统将默认调用 OCR 从图像中提取文本。此外，用户还可以配置支持视觉识别的 VLM（视觉语言模型）来处理它们。
• 对于 Audio 文件，需要配置一个支持语音转文本的模型。Parser 将从音频中提取文本内容。用户可以在首页的“模型提供商”页面配置支持此类解析的模型提供商的 API 密钥。之后，他们可以返回 Parser 节点并在下拉菜单中选择它。这种“先配置后选择”的逻辑也适用于 PDF、Image 和 Video 文件。
• 对于 Video 文件，需要配置一个支持多模态识别的大模型。Parser 将调用此模型对视频进行全面分析，并以文本格式输出结果。
• 在解析 Email 文件时，RAGFlow 提供了字段选项，允许用户仅选择所需字段，如“主题”和“正文”。Parser 将精确提取这些字段的文本内容。

• Spreadsheet 解析器会以 HTML 格式输出文件，完整保留其行列结构，确保表格数据在转换后依然清晰可读。
• Word 和 PPT 类型的文件将被解析并输出为 JSON 格式。对于 Word 文件，文档的原始层级结构，如标题、段落、列表、页眉和页脚，都将被保留。对于 PPT 文件，内容将逐页提取，区分每张幻灯片的标题、正文和备注。
• Text & Markup 类别会自动剥离 HTML 和 MD（Markdown）等文件的格式标签，只输出最纯净的文本内容。

分块器 (Chunker)

Chunker 节点负责将上游节点输出的文档分割成 Chunk 片段。Chunk 是 RAG 技术引入的一个概念，代表召回的单元。用户可以根据需要选择是否添加 Chunker 节点，但通常建议使用它，主要有两个原因：

1. 如果将整个文档作为召回单元，最终生成阶段传递给大模型的数据可能会超出上下文窗口限制。
2. 在典型的 RAG 系统中，向量搜索是一种重要的召回方法。然而，向量本身存在语义表示不准确的问题。例如，用户可以选择将单个句子转换为向量，或将整个文档转换为向量。前者丢失了全局语义信息，而后者丢失了局部信息。因此，选择一个合适的片段长度，使其在用单个向量表示时能达到较好的平衡，是一种必要的技术手段。

在实际工程系统中，Chunk 的切分结果往往显著影响 RAG 的召回质量。如果包含答案的内容被分割到不同的 Chunk 中，而检索阶段无法保证所有这些 Chunk 都被召回，就可能导致答案生成不准确和产生幻觉。因此，Ingestion Pipeline 引入了 Chunker 节点，允许用户更灵活地切分文本。

当前系统内置了两种切分方法：基于文本 token 和标题的切分。

按 token 切分是最常见的方法。用户可以自定义每个片段的大小，默认设置为 512 个 token，这是一个为检索效果和模型兼容性优化的平衡值。在设置片段大小时，必须考虑权衡：如果片段 token 数仍然过大，超出模型限制的部分仍会被丢弃；如果设置得太小，可能会导致原文中连贯的语义被过度分割，破坏上下文并影响检索效果。

为了解决这个问题，Chunker 算子提供了片段重叠功能，它允许前一个片段的末尾部分被复制为下一个片段的开头，从而增强语义连续性。用户可以增加“重叠百分比”来提高片段之间的关联性。

此外，用户可以通过定义“分隔符”来进一步优化切分规则。系统默认使用 \n（换行符）作为分隔符，这意味着切分器将优先尝试沿着自然段落进行分割，而不是在句子中间突然截断，如下图所示。

如果文档本身具有清晰的章节结构，按 token 切分文本可能不是最佳选择。在这种情况下，可以选择 Chunker 中的 Title 选项，根据文档的标题进行切分。这种方法主要适用于具有技术手册、学术论文和法律条款等布局的文档。我们可以在 Title 节点中为不同级别的标题自定义表达式。例如，一级标题（H1）的表达式可以设置为 ^#[^#]，二级标题（H2）的表达式可以设置为 ^##[^#]。基于这些表达式，系统将严格按照预定义的章节结构对文档进行切分，确保每个片段都代表一个结构完整的“章节”或“小节”。用户还可以在配置中自由添加或减少标题级别，以匹配文档的实际结构，如下图所示。

注意：在当前的 RAGFlow v0.21 版本中，如果同时配置了 Chunker 的 Token 和 Title 选项，请确保 Title 节点连接在 Token 节点之后。否则，如果 Title 节点直接连接到 Parser 节点，对于 Email、Image、Spreadsheet 和 Text&Markup 类型的文件可能会出现格式错误。这些限制将在后续版本中进行优化。

转换器 (Transformer)

Transformer 算子负责转换文本内容。仅仅解决文本解析和切分的准确性并不能保证最终的检索准确率。这是因为用户的查询与包含答案的文档之间总是存在所谓的“语义鸿沟”。通过使用 Transformer 算子，用户可以利用大模型从输入文档内容中提取信息，从而弥合“语义鸿沟”。

当前的 Transformer 算子支持摘要生成、关键词生成、问题生成和元数据生成等功能。用户可以选择将该算子加入其流水线，以这些内容补充原始数据，从而提升最终的检索准确率。与其他涉及大模型的场景类似，Transformer 节点也为大模型提供了三种模式：即兴（Improvise）、精确（Precise）和平衡（Balance）。

• 即兴模式（Improvise）鼓励模型展现更大的创造力和联想思维，非常适合生成多样化的问题。
• 精确模式（Precise）严格约束模型，确保其输出高度忠实于原文，适合生成摘要或提取关键词。
• 平衡模式（Balance）在两者之间取得平衡，适用于大多数场景。

用户可以选择这三种风格之一，或者通过自行调整 Temperature 和 Top P 等参数来实现更精细的控制。

Transformer 节点可以生成四种类型的内容：摘要（Summary）、关键词（Keywords）、问题（Questions）和元数据（Metadata）。RAGFlow 还将每种内容的提示词（prompt）公开，这意味着用户可以通过修改系统提示词来丰富和个性化文本处理。

如果需要实现多种功能，例如同时总结内容和提取关键词，用户需要为每个功能配置一个独立的 Transformer 节点，并在流水线中将它们串联起来。换句话说，一个 Transformer 节点可以紧接在 Parser 之后，处理整个文档（例如，生成全文摘要），也可以连接在 Chunker 之后，处理每个文本片段（例如，为每个 Chunk 生成问题）。此外，一个 Transformer 节点可以连接在另一个 Transformer 节点之后，以级联方式执行复杂的内容提取和生成。

请注意：Transformer 节点不会自动从其前置节点获取内容。它实际处理的信息来源完全取决于用户提示词（User prompt）中引用的变量。在用户提示词中，必须通过输入 / 符号来手动选择和引用上游节点输出的变量。

例如，在一个 Parser - Chunker - Transformer 的流水线中，尽管 Transformer 在视觉上连接在 Chunker 之后，但如果用户提示词中引用的变量是来自 Parser 节点的输出，那么 Transformer 实际上将处理整个原始文档，而不是 Chunker 生成的块。

同样，当用户选择串联多个 Transformer 节点时（例如，第一个生成摘要，第二个生成关键词），如果第二个 Transformer 引用了第一个 Transformer 生成的摘要变量，它将处理这个摘要作为“新的原文”进行进一步处理，而不是处理更上游 Chunker 的文本块。

索引器 (Indexer)

前面的 Parser、Chunker 和 Transformer 节点处理了数据流入、切分和优化。然而，流水线中最终的执行单元是 Indexer 节点，它负责将处理后的数据写入检索引擎（RAGFlow 目前支持 Infinity、Elasticsearch 和 OpenSearch）。

检索引擎的核心能力是为数据建立各种类型的索引，从而提供搜索能力，包括向量索引、全文索引以及未来的张量索引能力等。换句话说，它是 RAG 这个术语中“检索”（Retrieval）的最终体现。

由于不同类型索引的能力各不相同，Indexer 同时提供了创建不同索引的选项。具体来说，Indexer 节点内的“搜索方法”（Search method）选项决定了用户数据如何被“找到”。

全文（Full-text）指的是传统的“关键词搜索”，这是精确召回的必要选项，例如搜索特定的产品编号、人名或代码。而嵌入（Embedding）则代表了现代由人工智能驱动的“语义搜索”。用户可以用自然语言提问，系统可以“理解”问题的含义并检索内容上最相关的文档块。同时启用两者进行混合搜索是 RAGFlow 的默认选项。有效的多渠道召回可以平衡精确度和语义，最大限度地发现答案所在的文本片段。

注意：在 Indexer 节点内无需选择特定的嵌入模型，因为它会自动调用创建知识库时设置的嵌入模型。此外，RAGFlow 中的聊天（Chat）、搜索（Search）和 Agent 功能支持跨知识库检索，这意味着一个问题可以同时在多个知识库中进行搜索。但是，要启用此功能，必须满足一个先决条件：所有同时选择的知识库必须使用相同的嵌入模型。这是因为不同的嵌入模型会将相同的文本转换为完全不同且不兼容的向量，从而无法进行跨库检索。

此外，通过“文件名嵌入权重”（Filename embedding weight）和“字段”（Field）选项可以实现更精细的检索设置。文件名嵌入权重是一个微调滑块，允许用户将文档的“文件名”视为语义信息的一部分，并为其分配特定权重。

而“字段”选项则决定了要索引的具体内容和检索策略。目前提供了三种不同的策略选项：

• 处理后的文本（Processed Text）：这是默认选项，也是最直观的。它意味着 Indexer 将对来自前置节点的处理后的文本块进行索引。
• 问题（Questions）：如果在 Indexer 之前使用了 Transformer 节点来生成“每个文本块可以回答的潜在问题”，那么这些问题可以在这里被索引。在许多场景中，匹配“用户问题”与“预生成的问题”比匹配“问题”与“答案”（即原文）产生的相似度要高得多，从而有效提高检索准确率。
• 增强上下文（Augmented Context）：这涉及使用摘要（Summaries）代替原文进行检索。它适用于需要快速进行广泛主题匹配而不想被原文细节干扰的场景。

将 Ingestion Pipeline 关联到知识库

构建好 Ingestion Pipeline 后，下一步是将其与相应的知识库关联起来。在创建知识库的页面，找到并点击“Ingestion pipeline”选项卡下的“选择流水线”选项。随后，从下拉菜单中选择已创建的 Pipeline 以建立关联。一旦设置，此 Pipeline 将成为该知识库的默认文件解析流程。

对于一个已经创建的知识库，用户可以随时进入其“Ingestion pipeline”模块，重新调整和选择关联的解析流程。

如果用户希望为单个文件调整 Ingestion pipeline，也可以通过点击“解析位置”来进行调整。

最后，在弹出的窗口中进行调整并保存更新。

日志 (Logs)

Ingestion Pipeline 的执行可能需要相当长的时间，因此可观测性是不可或缺的能力。为此，RAGFlow 为 Ingestion Pipeline 提供了日志面板，记录了每个文件解析操作的全链路日志。对于通过 Ingestion Pipeline 解析的文件，用户可以深入了解每个处理节点的操作细节。这为后续的问题审计、流程调试和性能洞察提供了全面的数据支持。

下图是一个步骤日志的示例图。

案例参考

创建 Pipeline 时，您可以选择“Chunk Summary”模板作为构建的基础，当然您也可以选择其他模板作为后续构建的起点。

“Chunk Summary”模板的编排设计如下：

接下来，将 Transformer 节点中的大模型切换为您希望使用的模型，并将“结果目标”字段设置为“元数据”。此配置意味着大模型对文本块的处理结果（如摘要）将直接存储在文件的元数据中，为后续的精确检索和过滤提供能力支持。

点击右上角的“运行”并上传文件以测试流水线。

您可以点击“查看结果”来检查测试运行的结果。

总结

以上内容全面介绍了当前 Ingestion Pipeline 的使用方法和核心能力。展望未来，RAGFlow 将在数据导入和解析的清晰度方面持续演进，包括以下具体增强：

1. 扩展数据源支持：除了本地文件上传，我们将逐步集成各种数据源，如 S3、云存储、电子邮件、在线笔记等。通过自动和手动同步机制，我们将实现数据无缝导入知识库，并自动应用 Ingestion Pipeline 完成文档解析。
2. 增强解析能力：我们将在 Parser 算子中集成更多文档解析模型，如 Docling，以覆盖不同垂直领域的解析需求，全面提升文档信息提取的质量和准确性。
3. 开放自定义切片功能：除了内置的 Chunker 类型，我们将逐步开放底层的切片能力，允许用户编写自定义切片逻辑，实现更灵活可控的文本组织。
4. 加强语义增强的扩展性：在现有总结、关键词提取和问题生成能力的基础上，我们将以可编程的方式进一步支持可定制的语义增强策略，为用户提供更多优化检索和排序的技术手段。

通过这些增强，RAGFlow 将不断提升检索准确率，为向大模型提供高质量上下文提供坚实支持。

最后，感谢您的关注与支持。欢迎您在 GitHub 上为 RAGFlow 点亮星星，与我们共同见证大模型技术的持续演进！

GitHub: https://github.com/infiniflow/ragflow

为了满足系统运维监控以及用户账户管理的精细化需求，特别是针对 RAGFlow 用户目前面临的“用户无法自行找回遗失密码”、“账户状态难以有效管控”等实际问题，RAGFlow 正式推出了一款专业的后端管理命令行工具。

该工具基于清晰的客户端-服务器架构，通过采用功能分离的设计理念，构建了一个高效、可靠的系统管理通道，使管理员能够在底层实现系统恢复和权限控制。

具体的架构设计如下图所示

通过此工具，RAGFlow 用户可以一站式地了解 RAGFlow Server 以及 MySQL、Elasticsearch、Redis、MinIO 和 Infinity 等组件的运行状态。它还支持全面的用户生命周期管理，包括账户创建、状态控制、密码重置和数据清理。

启动服务

如果您通过 Docker 部署 RAGFlow，请修改 docker/docker_compose.yml 文件，在服务启动命令中添加参数。

command:
  - --enable-adminserver

如果您从源代码部署 RAGFlow，可以直接执行以下命令来启动管理服务器

python3 admin/server/admin_server.py

服务器启动后，默认监听 9381 端口，等待客户端连接。如果您需要使用其他端口，请修改 docker/.env 文件中的 ADMIN_SVR_HTTP_PORT 配置项。

安装客户端并连接至管理服务

建议使用 pip 安装指定版本的客户端

pip install ragflow-cli==0.21.0

0.21.0 版本是当前的最新版本。请确保 ragflow-cli 的版本与 RAGFlow 服务器的版本相匹配，以避免兼容性问题。

ragflow-cli -h 127.0.0.1 -p 9381

这里，-h 指定服务器IP，-p 指定服务器端口。如果服务器部署在不同的地址或端口，请相应地调整参数。

首次登录时，输入默认的管理员密码 admin。成功登录后，建议及时在命令行工具中更改默认密码以增强安全性。

命令使用指南

通过客户端输入以下命令，您可以方便地管理用户并监控服务的运行状态。

交互功能说明

• 支持使用方向键移动光标和查看历史命令。
• 按 Ctrl+C 可以随时终止当前的交互。
• 如果您需要复制内容，请避免使用 Ctrl+C 以防意外中断进程。

命令格式规范

• 所有命令不区分大小写，且必须以分号 ; 结尾。
• 用户名和密码等文本参数需要用单引号 ' 或双引号 " 括起来。
• 密码中禁止使用 \、' 和 " 等特殊字符。

服务管理命令

LIST SERVICES;

• 列出 RAGFlow 后端服务及所有关联中间件的运行状态。

使用示例

admin> list services;
Listing all services
+-------------------------------------------------------------------------------------------+-----------+----+---------------+-------+----------------+---------+
| extra                                                                                     | host      | id | name          | port  | service_type   | status  |
+-------------------------------------------------------------------------------------------+-----------+----+---------------+-------+----------------+---------+
| {}                                                                                        | 0.0.0.0   | 0  | ragflow_0     | 9380  | ragflow_server | Timeout |
| {'meta_type': 'mysql', 'password': 'infini_rag_flow', 'username': 'root'}                 | localhost | 1  | mysql         | 5455  | meta_data      | Alive   |
| {'password': 'infini_rag_flow', 'store_type': 'minio', 'user': 'rag_flow'}                | localhost | 2  | minio         | 9000  | file_store     | Alive   |
| {'password': 'infini_rag_flow', 'retrieval_type': 'elasticsearch', 'username': 'elastic'} | localhost | 3  | elasticsearch | 1200  | retrieval      | Alive   |
| {'db_name': 'default_db', 'retrieval_type': 'infinity'}                                   | localhost | 4  | infinity      | 23817 | retrieval      | Timeout |
| {'database': 1, 'mq_type': 'redis', 'password': 'infini_rag_flow'}                        | localhost | 5  | redis         | 6379  | message_queue  | Alive   |
+-------------------------------------------------------------------------------------------+-----------+----+---------------+-------+----------------+---------+

列出 RAGFlow 后端服务及所有关联中间件的运行状态。

SHOW SERVICE <id>;

• 查询指定服务的详细运行状态。
• <id>: 执行命令 LIST SERVICES; 后显示结果中的服务标识符 ID。

使用示例

1. 查询 RAGFlow 后端服务

admin> show service 0;
Showing service: 0
Service ragflow_0 is alive. Detail:
Confirm elapsed: 4.1 ms.

响应表明 RAGFlow 后端服务在线，响应时间为 4.1 毫秒。

2. 查询 MySQL 服务

admin> show service 1;
Showing service: 1
Service mysql is alive. Detail:
+---------+----------+------------------+------+------------------+------------------------+-------+-----------------+
| command | db       | host             | id   | info             | state                  | time  | user            |
+---------+----------+------------------+------+------------------+------------------------+-------+-----------------+
| Daemon  | None     | localhost        | 5    | None             | Waiting on empty queue | 86356 | event_scheduler |
| Sleep   | rag_flow | 172.18.0.6:56788 | 8790 | None             |                        | 2     | root            |
| Sleep   | rag_flow | 172.18.0.6:53482 | 8791 | None             |                        | 73    | root            |
| Query   | rag_flow | 172.18.0.6:56794 | 8795 | SHOW PROCESSLIST | init                   | 0     | root            |
+---------+----------+------------------+------+------------------+------------------------+-------+-----------------+

响应表明 MySQL 服务在线，当前的连接和执行状态如上表所示。

3. 查询 MinIO 服务

admin> show service 2;
Showing service: 2
Service minio is alive. Detail:
Confirm elapsed: 2.3 ms.

响应表明 MinIO 服务在线，响应时间为 2.3 毫秒。

4. 查询 Elasticsearch 服务

admin> show service 3;
Showing service: 3
Service elasticsearch is alive. Detail:
+----------------+------+--------------+---------+----------------+--------------+---------------+--------------+------------------------------+----------------------------+-----------------+-------+---------------+---------+-------------+---------------------+--------+------------+--------------------+
| cluster_name   | docs | docs_deleted | indices | indices_shards | jvm_heap_max | jvm_heap_used | jvm_versions | mappings_deduplicated_fields | mappings_deduplicated_size | mappings_fields | nodes | nodes_version | os_mem  | os_mem_used | os_mem_used_percent | status | store_size | total_dataset_size |
+----------------+------+--------------+---------+----------------+--------------+---------------+--------------+------------------------------+----------------------------+-----------------+-------+---------------+---------+-------------+---------------------+--------+------------+--------------------+
| docker-cluster | 8    | 0            | 1       | 2              | 3.76 GB      | 2.15 GB       | 21.0.1+12-29 | 17                           | 757 B                      | 17              | 1     | ['8.11.3']    | 7.52 GB | 2.30 GB     | 31                  | green  | 226 KB     | 226 KB             |
+----------------+------+--------------+---------+----------------+--------------+---------------+--------------+------------------------------+----------------------------+-----------------+-------+---------------+---------+-------------+---------------------+--------+------------+--------------------+

响应表明 Elasticsearch 集群运行正常，具体指标包括文档数、索引状态、内存使用情况等。

5. 查询 Infinity 服务

admin> show service 4;
Showing service: 4
Fail to show service, code: 500, message: Infinity is not in use.

响应表明 Infinity 当前未被 RAGFlow 系统使用。

admin> show service 4;
Showing service: 4
Service infinity is alive. Detail:
+-------+--------+----------+
| error | status | type     |
+-------+--------+----------+
|       | green  | infinity |
+-------+--------+----------+

启用 Infinity 并再次查询后，响应表明 Infinity 服务在线且状态良好。

6. 查询 Redis 服务

admin> show service 5;
Showing service: 5
Service redis is alive. Detail:
+-----------------+-------------------+---------------------------+-------------------------+---------------+-------------+--------------------------+---------------------+-------------+
| blocked_clients | connected_clients | instantaneous_ops_per_sec | mem_fragmentation_ratio | redis_version | server_mode | total_commands_processed | total_system_memory | used_memory |
+-----------------+-------------------+---------------------------+-------------------------+---------------+-------------+--------------------------+---------------------+-------------+
| 0               | 3                 | 10                        | 3.03                    | 7.2.4         | standalone  | 404098                   | 30.84G              | 1.29M       |
+-----------------+-------------------+---------------------------+-------------------------+---------------+-------------+--------------------------+---------------------+-------------+

响应表明 Redis 服务在线，版本号、部署模式和资源使用情况如上表所示。

用户管理命令

LIST USERS;

• 列出 RAGFlow 系统中的所有用户。

使用示例

admin> list users;
Listing all users
+-------------------------------+----------------------+-----------+----------+
| create_date                   | email                | is_active | nickname |
+-------------------------------+----------------------+-----------+----------+
| Mon, 13 Oct 2025 15:58:42 GMT | admin@ragflow.io     | 1         | admin    |
| Mon, 13 Oct 2025 15:54:34 GMT | lynn_inf@hotmail.com | 1         | Lynn     |
+-------------------------------+----------------------+-----------+----------+

响应表明系统中当前有两名用户，状态均为启用。

其中，admin@ragflow.io 是管理员账号，在系统初始启动时自动创建。

SHOW USER <username>;

• 通过邮箱查询用户详细信息。
• <username>: 用户的邮箱地址，必须用单引号 ' 或双引号 " 括起来。

使用示例

1. 查询管理员用户

admin> show user "admin@ragflow.io";
Showing user: admin@ragflow.io
+-------------------------------+------------------+-----------+--------------+------------------+--------------+----------+-----------------+---------------+--------+-------------------------------+
| create_date                   | email            | is_active | is_anonymous | is_authenticated | is_superuser | language | last_login_time | login_channel | status | update_date                   |
+-------------------------------+------------------+-----------+--------------+------------------+--------------+----------+-----------------+---------------+--------+-------------------------------+
| Mon, 13 Oct 2025 15:58:42 GMT | admin@ragflow.io | 1         | 0            | 1                | True         | English  | None            | None          | 1      | Mon, 13 Oct 2025 15:58:42 GMT |
+-------------------------------+------------------+-----------+--------------+------------------+--------------+----------+-----------------+---------------+--------+-------------------------------+

响应结果显示 admin@ragflow.io 是超级管理员，且当前状态为已启用 (enabled)。

2. 查询普通用户

admin> show user "lynn_inf@hotmail.com";
Showing user: lynn_inf@hotmail.com
+-------------------------------+----------------------+-----------+--------------+------------------+--------------+----------+-------------------------------+---------------+--------+-------------------------------+
| create_date                   | email                | is_active | is_anonymous | is_authenticated | is_superuser | language | last_login_time               | login_channel | status | update_date                   |
+-------------------------------+----------------------+-----------+--------------+------------------+--------------+----------+-------------------------------+---------------+--------+-------------------------------+
| Mon, 13 Oct 2025 15:54:34 GMT | lynn_inf@hotmail.com | 1         | 0            | 1                | False        | English  | Mon, 13 Oct 2025 15:54:33 GMT | password      | 1      | Mon, 13 Oct 2025 17:24:09 GMT |
+-------------------------------+----------------------+-----------+--------------+------------------+--------------+----------+-------------------------------+---------------+--------+-------------------------------+

响应结果显示 lynn_inf@hotmail.com 是一个通过密码登录的普通用户，最后登录时间显示为提供的时间戳。

CREATE USER <username> <password>;

• 创建一个新用户。
• <username>: 用户的邮箱地址，必须符合标准的邮箱格式规范。
• <password>: 用户的密码，不得包含 \、' 或 " 等特殊字符。

使用示例

admin> create user "example@ragflow.io" "psw";
Create user: example@ragflow.io, password: psw, role: user
+----------------------------------+--------------------+----------------------------------+--------------+---------------+----------+
| access_token                     | email              | id                               | is_superuser | login_channel | nickname |
+----------------------------------+--------------------+----------------------------------+--------------+---------------+----------+
| be74d786a9b911f0a726d68c95a0776b | example@ragflow.io | be74d6b4a9b911f0a726d68c95a0776b | False        | password      |          |
+----------------------------------+--------------------+----------------------------------+--------------+---------------+----------+

已成功创建一个普通用户。昵称和头像等个人信息可由用户在登录后访问个人资料页面自行设置。

ALTER USER PASSWORD <username> <new_password>;

• 更改用户密码。
• <username>: 用户邮箱地址
• <password>: 新密码（不得与旧密码相同，且不得包含特殊字符）

使用示例

admin> alter user password "example@ragflow.io" "psw";
Alter user: example@ragflow.io, password: psw
Same password, no need to update!

当新密码与旧密码相同时，系统提示无需更改。

admin> alter user password "example@ragflow.io" "new psw";
Alter user: example@ragflow.io, password: new psw
Password updated successfully!

密码已成功更新。此后用户可以使用新密码登录。

ALTER USER ACTIVE <username> <on/off>;

• 启用或禁用用户。
• <username>: 用户邮箱地址
• <on/off>: 启用或禁用状态

使用示例

admin> alter user active "example@ragflow.io" off;
Alter user example@ragflow.io activate status, turn off.
Turn off user activate status successfully!

用户已成功禁用。只有处于禁用状态的用户才能被删除。

DROP USER <username>;

• 删除用户及其所有关联数据
• <username>: 用户邮箱地址

重要提示

• 只有已禁用的用户才能被删除。
• 在继续操作之前，请确保所有需要保留的必要数据（如知识库和文件）已转移给其他用户。
• 此操作将永久删除以下用户数据

用户创建的所有知识库、上传的文件、配置的智能体，以及用户在他人知识库中上传的文件都将被永久删除。此操作不可逆，请极其谨慎操作。

• 删除命令具有幂等性。如果在删除过程中系统发生故障或操作中断，可以在排除故障后重新执行该命令以继续删除剩余数据。

使用示例

1. 用户成功删除

admin> drop user "example@ragflow.io";
Drop user: example@ragflow.io
Successfully deleted user. Details:
Start to delete owned tenant.
- Deleted 2 tenant-LLM records.
- Deleted 0 langfuse records.
- Deleted 1 tenant.
- Deleted 1 user-tenant records.
- Deleted 1 user.
Delete done!

响应表明用户已成功删除，并列出了数据清理的详细步骤。

2. 删除超级管理员（禁止操作）

admin> drop user "admin@ragflow.io";
Drop user: admin@ragflow.io
Fail to drop user, code: -1, message: Can't delete the super user.

响应表明删除失败。超级管理员账户受到保护，即使处于禁用状态也无法删除。

数据与 Agent 管理命令

LIST DATASETS OF <username>;

• 列出指定用户的所有知识库
• <username>: 用户邮箱地址

使用示例

admin> list datasets of "lynn_inf@hotmail.com";
Listing all datasets of user: lynn_inf@hotmail.com
+-----------+-------------------------------+---------+----------+-----------------+------------+--------+-----------+-------------------------------+
| chunk_num | create_date                   | doc_num | language | name            | permission | status | token_num | update_date                   |
+-----------+-------------------------------+---------+----------+-----------------+------------+--------+-----------+-------------------------------+
| 8         | Mon, 13 Oct 2025 15:56:43 GMT | 1       | English  | primary_dataset | me         | 1      | 3296      | Mon, 13 Oct 2025 15:57:54 GMT |
+-----------+-------------------------------+---------+----------+-----------------+------------+--------+-----------+-------------------------------+

响应显示该用户有一个私有知识库，文档和分段数量等详细信息如上表所示。

LIST AGENTS OF <username>;

• 列出指定用户的所有智能体
• <username>: 用户邮箱地址

使用示例

admin> list agents of "lynn_inf@hotmail.com";
Listing all agents of user: lynn_inf@hotmail.com
+-----------------+-------------+------------+----------------+
| canvas_category | canvas_type | permission | title          |
+-----------------+-------------+------------+----------------+
| agent_canvas    | None        | me         | finance_helper |
+-----------------+-------------+------------+----------------+

响应表明该用户有一个私有智能体，详细信息如上表所示。

其他命令

• ? 或 \help

显示帮助信息。

• \q 或 \quit

后续计划

我们始终致力于提升系统管理体验和整体安全性。在现有强大功能的基础上，RAGFlow 后端管理工具将持续演进。除了当前高效灵活的命令行界面外，我们即将推出专业的系统管理 UI，使管理员能够在一个更安全、更直观的图形化环境中执行所有运维任务。

为了加强权限控制，当前在普通用户界面中可见的系统状态信息将被撤销。未来专业的管理 UI 上线后，系统核心运行状态的访问权限将仅限于管理员。这将有效解决当前权限暴露过多的问题，进一步加固系统的安全边界。

此外，我们还将陆续推出更多精细化的管理功能，包括

• 对数据集和智能体的精细化控制
• 用户团队协作管理机制
• 增强的系统监控和审计能力

这些改进将建立一个更全面的企业级管理生态系统，为管理员提供更全方位、更便捷的系统控制体验。

简介

在 RAG（检索增强生成）和 LLM（大语言模型）记忆中，向量检索被广泛采用。在各种方案中，基于图的索引因其高精度和高性能而成为最常见的选择，其中 HNSW（分层导航小世界）索引最具代表性1 2。

然而，在我们将 HNSW 应用于 RAGFlow 的实践过程中，我们遇到了以下两个主要瓶颈：

1. 随着数据规模的持续增长，向量数据的内存消耗变得非常巨大。例如，十亿个1024维的浮点向量将需要大约 4TB 的内存空间。
2. 在复杂数据集上构建 HNSW 索引时，检索准确率存在瓶颈。达到某个阈值后，仅通过调整参数很难进一步提高准确率。

为解决这一问题，Infinity 基于 HNSW 实现了一系列改进算法。用户可以通过调整 HNSW 的索引参数来选择不同的索引方案。每种 HNSW 索引变体都具有独特的特性，适用于不同的场景，允许用户根据实际需求构建相应的索引结构。

索引方案介绍

原始 HNSW 作为一种常用的基于图的索引，表现出优异的性能。

其结构由两部分组成：

一组原始向量数据，以及由跳表和邻接表共同构建的图结构。以 Python 接口为例，可以按以下方式构建和使用索引：

## Create index
table_obj.create_index(
    "hnsw_index",
    index.IndexInfo(
        "embedding",
        index.IndexType.Hnsw, {
            "m": 16,
            "ef_construction": 200,
            "metric": "l2"
        },
    )
)
## Vector retrieval
query_builder.match_dense('embedding', [1.0, 2.0, 3.0], 'float', 'l2', 10, {'ef': 200})

为了解决高内存消耗和准确率瓶颈的问题，Infinity 提供了以下解决方案：

1. 引入 LVQ 和 RaBitQ 量化方法，以减少图搜索过程中原始向量的内存开销。
2. 引入 LSG 策略，优化 HNSW 的图索引结构，提升其准确率阈值和查询效率。

为了方便用户在本地测试不同索引的性能，Infinity 提供了一个基准测试脚本。您可以按照 Infinity 在 GitHub 上提供的教程设置环境并准备数据集，然后使用基准测试来测试不同的索引方案。

######################   compile benchmark  ######################
cmake --build cmake-build-release --target hnsw_benchmark

###################### build index & execute query ######################
#           mode : build, query
# benchmark_type : sift, gist, msmarco
#     build_type : plain, lvq, crabitq, lsg, lvq_lsg, crabitq_lsg
##############################################################
benchmark_type=sift
build_type=plain
./cmake-build-release/benchmark/local_infinity/hnsw_benchmark --mode=build --benchmark_type=$benchmark_type --build_type=$build_type --thread_n=8
./cmake-build-release/benchmark/local_infinity/hnsw_benchmark --mode=query --benchmark_type=$benchmark_type --build_type=$build_type --thread_n=8 --topk=10

其中，原始 HNSW 对应参数 build_type=plain。本文对所有变体索引的查询性能进行了统一测试，实验环境配置如下：

1. 操作系统：Ubuntu 24.04 LTS (Noble Numbat)
2. CPU：第13代 Intel(R) Core(TM) i5-13400
3. 内存：64G

该 CPU 为 16 核规格。为了与大多数用户的实际设备环境保持一致，基准测试中的并行计算参数统一设置为 8 线程。

方案 1：原生 HNSW + LVQ 量化器 (HnswLvq)

LVQ 是一种标量量化方法，它将原始向量中的每个 32 位浮点数压缩为 8 位整数3，从而将内存占用降低至原始向量的四分之一。

与简单的标量量化方法（如均值标量量化）相比，LVQ 通过统计分析每个向量的残差来减少误差，有效地最小化了量化向量距离计算中的信息损失。因此，LVQ 仅需约30%的原始内存占用，即可准确估算原始向量之间的距离。

在 HNSW 算法中，原始向量用于距离计算，这使得 LVQ 可以直接与 HNSW 集成。我们将这种组合方法称为 HnswLvq。在 Infinity 中，用户可以通过设置参数 "encode": "lvq" 来启用 LVQ 编码。

## Create index
table_obj.create_index(
    "hnsw_index",
    index.IndexInfo(
        "embedding",
        index.IndexType.Hnsw, {
            "m": 16,
            "ef_construction": 200,
            "metric": "l2",
            "encode": "lvq"
        },
    )
)
## Vector retrieval
query_builder.match_dense('embedding', [1.0, 2.0, 3.0], 'float', 'l2', 10, {'ef': 200})

HnswLvq 的图结构与原始 HNSW 保持一致，关键区别在于它使用量化向量在图内执行所有距离计算。通过这一改进，HnswLvq 在索引构建和查询效率方面均优于原始 HNSW 索引。

构建效率的提升源于量化向量的长度更短，从而减少了使用 SIMD 指令进行距离计算的时间。查询效率的提升则归因于量化带来的计算加速，其效果超过了精度损失所带来的负面影响。

总之，HnswLvq 在保持出色查询性能的同时，显著降低了内存使用。我们建议用户在大多数场景下将其作为主要索引。为复现此实验，用户可以在基准测试中设置参数 build_type=lvq。具体的实验结果将在方案二中与 RaBitQ 量化器方案一并比较。

方案 2：原生 HNSW + RaBitQ 量化器 (HnswRabitq)

RaBitQ 是一种二值标量量化方法，其核心思想与 LVQ 类似，都旨在用更少的编码位替换原始向量中的32位浮点数。不同之处在于，RaBitQ 采用二值标量量化，仅用1位表示每个浮点数，从而实现了极高的压缩比。

然而，这种极端压缩也会导致向量中更显著的信息丢失，从而导致距离估计的准确性下降。为了缓解这一问题，RaBitQ 在预处理阶段引入了旋转矩阵来预处理数据集，并保留了更多的残差信息，从而在一定程度上减少了距离计算中的误差4。

尽管如此，二值量化在精度方面有明显局限性，与 LVQ 相比存在较大差距。直接使用 RaBitQ 编码构建的索引查询性能较差。

因此，Infinity 中实现的 HnswRabitq 方案是先为数据集构建一个原始 HNSW 索引，然后通过 optimize 方法中的 compress_to_rabitq 参数将其转换为 HnswRabitq 索引。

在查询过程中，系统首先使用量化向量进行初步检索，然后使用原始向量对用户指定的 ef 个候选结果进行重新排序。

## Create index
table_obj.create_index(
    "hnsw_index",
    index.IndexInfo(
        "embedding",
        index.IndexType.Hnsw, {
            "m": 16,
            "ef_construction": 200,
            "metric": "l2"
        },
    )
)
## Construct RaBitQ coding
table_obj.optimize("hnsw_index", {"compress_to_rabitq": "true"})
## Vector retrieval
query_builder.match_dense('embedding', [1.0, 2.0, 3.0], 'float', 'l2', 10, {'ef': 200})

与 LVQ 相比，RaBitQ 可以将编码向量的内存占用进一步减少近70%。在某些数据集上，由于二值量化后距离计算效率更高，HnswRabitq 的查询效率甚至超过了 HnswLvq。

但是，需要注意的是，在某些数据集（如 sift1M）上，量化过程可能导致严重的精度损失，使得这类数据集不适合使用 HnswRabitq。

总之，如果用户的数据集对量化误差不敏感，采用 HnswRabitq 索引可以在显著降低内存开销的同时，仍然保持相对较好的查询性能。

在这种情况下，建议优先使用 HnswRabitq 索引。用户可以通过设置基准测试参数 build_type=crabitq 来复现上述实验。

方案 3：LSG 图构建策略

LSG（局部缩放图）是一种基于图索引算法（如 HNSW、DiskANN 等）改进的图构建策略5。

该策略通过统计分析数据集中每个向量的局部信息——邻域半径，来缩放任意两个向量之间的距离（如 L2 距离、内积距离等）。缩放后的距离被称为 LS 距离。

在图索引构建过程中，LSG 统一使用 LS 距离替代原始距离度量，实际上是对原始度量空间进行了一次“局部缩放”。通过理论证明和实验，该论文表明，在这个缩放后的空间中构建图索引，可以在原始空间中获得更优的查询性能。

LSG 在多个方面优化了 HNSW 索引。当准确率要求相对宽松（< 99%）时，LSG 相比原始 HNSW 索引表现出更高的 QPS（每秒查询数）。

在高精度场景（> 99%）下，LSG 提升了图索引的质量，使 HNSW 能够突破其原有的准确率限制，达到原始 HNSW 索引难以企及的检索精度。这些改进在 RAGFlow 的实际应用中，为用户带来了更快的响应时间和更精确的查询结果。

在 Infinity 中，LSG 作为 HNSW 的一个可选参数提供。用户可以通过设置 build_type=lsg 来启用此图构建策略，我们将相应的索引称为 HnswLsg。

## Create index
table_obj.create_index(
    "hnsw_index",
    index.IndexInfo(
        "embedding",
        index.IndexType.Hnsw, {
            "m": 16,
            "ef_construction": 200,
            "metric": "l2",
            "build_type": "lsg"
        },
    )
)
## Vector retrieval
query_builder.match_dense('embedding', [1.0, 2.0, 3.0], 'float', 'l2', 10, {'ef': 200})

LSG 本质上是在索引构建过程中改变了度量空间。因此，它不仅可以应用于原始 HNSW，还可以与量化方法（如 LVQ 或 RaBitQ）结合，形成 HnswLvqLsg 或 HnswRabitqLsg 等变体索引。用户接口的使用方式与 HnswLvq 和 HnswRabitq 保持一致。

LSG 能够提升绝大多数图索引和数据集的性能，但代价是在图构建阶段需要额外计算局部信息——邻域半径，因此会在一定程度上增加构建时间。例如，在 sift1M 数据集上，HnswLsg 的构建时间约为原始 HNSW 的1.2倍。

总之，如果用户对索引构建时间不敏感，可以放心启用 LSG 选项，因为它能够稳定地提升查询性能。用户可以通过将基准测试参数设置为 build_type=[lsg/lvq_lsg/crabitq_lsg] 来复现上述实验。

索引性能评估

为了评估 Infinity 中各种索引的性能，我们选择了三个具有代表性的数据集作为基准，包括向量索引评估中广泛使用的 sift 和 gist 数据集。

鉴于 Infinity 在当前场景中常与 RAGFlow 结合使用，在 RAG 类型数据集上的检索效果对于用户评估索引性能尤为关键。

因此，我们还加入了 msmarco 数据集。该数据集是通过使用 Cohere Embed English v3 模型对 TREC-RAG 2024 语料库进行编码生成的，包含了1.135亿个文本段落的嵌入向量，以及来自 TREC-Deep Learning 2021-2023 的1677条查询指令对应的嵌入向量。

从各数据集的测试结果可以看出，在大多数情况下，HnswRabitqLsg 实现了最佳的综合性能。例如，在 RAG 场景的 msmarco 数据集上，RaBitQ 在实现内存使用减少90%的同时，在99%召回率下提供了5倍于原始 HNSW 的查询性能。

基于以上实验结果，我们为 Infinity 用户提供以下实践建议：

1. 与 HnswLvq 和 HnswRabitq 相比，原始 HNSW 可以达到更高的准确率上限。如果用户有极高的准确率要求，应优先考虑此策略。
2. 在可接受的准确率范围内，对于大多数数据集，可以放心选择 HnswLvq。对于不易受量化影响的数据集，HnswRabitq 通常是更好的选择。
3. LSG 策略能够提升所有索引变体的性能。如果用户对索引构建时间不敏感，建议在所有场景中都启用此选项以提高查询效率。此外，由于其算法特性，LSG 能显著提高准确率上限。因此，如果使用场景要求极高的准确率（>99.9%），强烈建议启用 LSG 以优化索引性能。

Infinity 仍在不断迭代和完善。我们欢迎大家的持续关注并提出宝贵的反馈和建议。

RAGFlow 0.21.0 正式发布

此版本将重心从增强在线 Agent 能力转向夯实数据基础，从根本上优先提升易用性和对话质量。0.21.0 版本直接解决了 RAG 的常见痛点——从数据准备到长文档理解，带来了关键升级：一个灵活、可编排的注入管道（Ingestion Pipeline）、用于弥合复杂文件中语义鸿沟的长文本 RAG，以及一个用于简化运维的新版管理后台命令行工具。总而言之，这些元素构成了 RAGFlow 全新的数据管道核心，为构建稳健高效的 RAG 应用提供了更坚实的基础。

可编排的解析流水线

如果说早期的 Agent 主要解决在线数据的编排问题——正如我们在 Workflow 和 Agentic Workflow 中所见——那么注入管道则通过将相同的技术架构应用于编排离线数据注入，体现了这一能力。它的引入使用户能够在一个统一的框架内构建高度定制化的 RAG 数据管道。这不仅简化了定制开发，也更充分地体现了 RAGFlow 中的“Flow”。

一个典型的 RAG 注入过程涉及文档解析、文本分块、向量化和索引构建等关键阶段。当 RAGFlow 于 2024 年 4 月首次发布时，它已经集成了一套先进的工具链，包括基于 DeepDoc 的解析引擎和模板化的分块机制。这些顶尖的解决方案是其早期被广泛采用的基础。

然而，随着行业的快速发展和实践应用的深入，我们观察到了新的趋势和需求：

• 视觉语言模型（VLM）的崛起：日益成熟的 VLM 推动了一波微调文档解析模型的发展。这些模型为具有复杂布局或图文混排的非结构化文档提供了显著提高的准确性。
• 对灵活分块的需求：用户现在寻求更定制化的分块策略。面对多样化的知识库场景，RAGFlow 原有的内置分块模板已证明不足以覆盖所有特定情况，这可能会影响最终问答结果的准确性。

为此，RAGFlow 0.21.0 正式引入了注入管道，其核心能力包括：

• 可编排的数据注入：基于底层的 Agent 框架，用户可以创建多样化的数据注入管道。每个管道可以应用不同的策略来连接数据源与最终的索引，将先前内置的数据写入过程转变为用户可定制的工作流。这提供了更灵活、更符合特定业务逻辑的注入方式。
• 上传与清洗解耦：该架构将数据上传与清洗分离，为未来的批量数据源建立了标准接口，并为扩展数据预处理工作流奠定了坚实的基础。
• 重构的解析器：解析器（Parser）组件经过重新设计，以实现可扩展性，为集成 DeepDoc 之外的先进文档解析模型奠定了基础。
• 可定制的分块接口：通过解耦分块步骤，用户可以接入自定义的分块器，以更好地适应不同知识结构的切分需求。
• 优化复杂 RAG 的效率：对 IO/计算密集型任务（如 GraphRAG 和 RAPTOR）的执行进行了彻底改革。在管道化之前的架构中，处理每个新文档都会触发一个完整的计算周期，导致性能缓慢。新的管道支持批量执行，显著提高了数据吞吐量和整体效率。

如果说 ETL/ELT 代表了现代数据栈中处理结构化数据的标准管道——dbt 和 Fivetran 等工具为数据仓库和数据湖提供了统一灵活的数据集成解决方案——那么 RAGFlow 的注入管道则定位为非结构化数据的等效基础设施。下图展示了这一架构类比：

具体来说，ETL/ELT 中的提取（Extract）阶段负责从各种来源拉取数据，而 RAGFlow 注入管道则通过一个专门的解析（Parsing）阶段来增强这一过程，以从非结构化数据中提取信息。该阶段集成了多种解析模型，以 DeepDoc 为首，将多模态文档（例如，文本和图像）转换为适合处理的单模态表示。

在转换（Transform）阶段，传统的 ETL/ELT 侧重于数据清洗和业务逻辑，而 RAGFlow 则构建了一系列以 LLM 为中心的 Agent 组件。这些组件经过优化，以解决检索中的语义鸿沟，其核心使命可以概括为：提升召回率和排序准确性。

在数据加载（Load）方面，ETL/ELT 将结果写入数据仓库或数据湖，而 RAGFlow 使用索引器（Indexer）组件将处理过的内容构建成一种为检索优化的索引格式。这反映了 RAG 引擎的混合检索架构，该架构必须支持全文、向量以及未来的张量检索，以确保最佳的召回率。

因此，现代数据栈服务于结构化数据的商业分析，而带有注入管道的 RAG 引擎则专注于非结构化数据的智能检索——为 LLM 提供高质量的上下文。两者在各自的领域中占据着等效的生态位。

关于处理结构化数据，这并非 RAG 引擎的核心职责。它由构建在引擎之上的上下文层（Context Layer）处理。该层利用 MCP（模型上下文协议）——被称为“AI 时代的 TCP/IP”——以及配套的上下文工程（Context Engineering）来自动填充所有类型的上下文。这是 RAGFlow 下一开发阶段的重点关注领域。

以下是 v0.21.0 中注入管道的初步展示；更详细的指南将随后发布。我们将用于解析、分块和其他非结构化数据处理任务的组件引入了 Agent 画布，使用户能够自由地编排其解析工作流。

编排一个注入管道可以自动化解析文件并按长度分块的过程。然后，它利用大语言模型生成摘要、关键词、问题甚至元数据。以前，这些元数据必须手动输入。现在，一次配置即可大幅减少维护开销。

此外，管道过程是完全可观测的，会记录并显示每个文件的完整处理日志。

0.21.0 版本中注入管道的实现是基础性的一步。在下一个版本中，我们计划通过以下方式显著增强它：

• 增加对更多数据源的支持。
• 提供更广泛的解析器选择。
• 引入更灵活的转换器（Transformer）组件，以促进编排更丰富的语义增强模板。

长文本 RAG

进入 2025 年，检索增强生成（RAG）面临着由两个主要因素驱动的显著挑战。

传统 RAG 的根本局限性

传统的 RAG 架构通常无法保证强大的对话性能，因为它们依赖于以文本块为主要单位的检索机制。这使得它们对分块质量高度敏感，并且可能因上下文不足而导致结果质量下降。例如：

• 如果一个连贯的语义单元被分割到不同的块中，检索可能会不完整。
• 如果一个块缺乏全局上下文，呈现给 LLM 的信息就会被削弱。

虽然自动检测章节标题并将其附加到块中等策略有助于提供全局语义，但它们受到标题识别准确性和标题自身完整性的限制。

先进预处理技术的成本效益问题

现代预处理方法——GraphRAG、RAPTOR 和上下文检索——旨在向原始数据中注入额外的语义信息，以提高复杂查询的搜索命中率和准确性。然而，它们都存在成本高和效果不可预测的问题。

• GraphRAG：这种方法消耗的 token 数量通常是原始文本的数倍，并且自动生成的知识图谱常常不尽人意。其在复杂多跳推理中的有效性受到不可控推理路径的限制。作为原始块之外的补充检索，知识图谱也丢失了源文件中的一些细粒度上下文。
• RAPTOR：该技术产生的聚类摘要作为独立的块被召回，但自然缺乏源文本的细节，重新引入了上下文不足的问题。

上下文检索：此方法通过关键词或潜在问题等额外语义来丰富原始块。它存在一个明确的权衡：

• 更有效的选项是每个块多次查询 LLM，同时使用全文和当前块作为上下文，这能提升性能，但会将 token 成本推高至原始文本的数倍。
• 更便宜的选项仅基于当前块生成语义信息，节省了成本，但提供的全局上下文有限，性能提升也有限。过去几年，出现了新的 RAG 方案。
• 完全放弃检索：一些方法让 LLM 直接读取文档，根据上下文窗口将其分割成块，并执行多阶段搜索。首先，LLM 决定哪个全局文档是相关的，然后是哪些块，最后加载这些块来回答问题。虽然这避免了召回不准确的问题，但它损害了响应延迟、并发性和大规模数据处理能力，使得实际部署变得困难。
• 放弃嵌入或索引，转而使用 grep 等工具：这将 RAG 演变为 Agentic RAG。随着应用程序变得越来越复杂，用户查询也日益多样化，将 RAG 与 Agent 结合变得越来越不可避免，因为只有 LLM 才能将原始查询转换为结构化的检索命令。在 RAGFlow 中，这一能力早已实现。放弃索引而使用 grep 是在个人或小规模场景下为了简化 Agent 开发而做出的妥协；在企业环境中，一个强大的检索引擎仍然至关重要。
• 长文本 RAG：作为 0.21.0 版本引入的功能，与 GraphRAG、RAPTOR 和上下文检索同属一类，该方法使用 LLM 来丰富原始文本的语义以提高召回率，同时保留索引和搜索。检索仍然是核心。长文本 RAG 模仿了人们查阅信息的方式：通过目录确定相关章节，然后找到确切的页面获取详细信息。在索引期间，LLM 提取章节信息并将其附加到每个块中，以提供全局上下文；在检索期间，它找到匹配的块，并利用目录结构来填补因分块造成的语义碎片化带来的空白。
• 当前体验与未来方向：用户可以通过“TOC 提取”（目录）功能尝试长文本 RAG，尽管它目前处于测试阶段。下一个版本将添加一个注入管道。改进 RAG 的一个关键路径是在不完全摒弃检索的情况下，使用 LLM 来丰富内容语义。因此，一个允许用户组装基于 LLM 的内容转换组件的灵活管道，是提升 RAG 检索质量的重要方向。

后端管理 CLI

RAGFlow 的发展已从核心模块开发转向加强管理和运营能力。

• 在早期版本中，尽管解析和检索增强生成功能有所改进，但系统管理功能却相对滞后。管理员无法修改密码或删除账户，这给部署和维护带来了复杂性。
• 随着 RAGFlow 0.21.0 的发布，基础的系统管理功能得到了显著提升。一个新的命令行管理工具为管理员提供了一个集中、便捷的界面。其核心功能包括：
  • 服务生命周期管理：监控 RAGFlow 内置服务，以实现更大的操作灵活性。
  • 全面的用户管理：
    • 创建新的注册用户。
    • 直接修改登录密码。
    • 删除用户账户。
    • 启用或禁用账户。
    • 查看所有注册用户的详细信息。
  • 资源概览：列出注册用户下创建的知识库和 Agent，以进行系统范围的监控。

这次升级凸显了 RAGFlow 对强大功能和企业级应用所必需的基础管理能力的承诺。展望未来，团队计划推出一个企业级的网页管理面板及配套的用户界面，以简化管理、提高效率并增强最终用户体验，从而支持更高的成熟度和稳定性。

结语

RAGFlow 0.21.0 标志着一个重要的里程碑，它在以往进展的基础上，勾勒出未来的发展蓝图。它首次将检索（RAG）与编排（Flow）相结合，形成一个智能引擎，以支持 LLM 上下文层，并以非结构化数据 ELT 和强大的 RAG 能力集为基础。

从赋予用户能力的注入管道，到缓解语义碎片化的长文本 RAG，再到确保可靠运行的管理后台，每一项新功能都旨在使 RAG 系统更智能、更灵活、更适合企业级应用。这不仅仅是功能的堆砌，更是一次架构的演进，为未来的发展奠定了坚实的基础。

我们持续关注的重点仍然是 LLM 上下文层：为 LLM 构建一个强大、可靠的数据基础，并有效地服务于所有 Agent。这仍然是 RAGFlow 的核心目标。

我们邀请您继续关注我们的项目并为其点赞（star），与我们共同成长。

GitHub: https://github.com/infiniflow/ragflow

目前，电商零售平台广泛使用智能客服系统来处理大量的用户咨询。然而，传统的智能客服往往难以满足用户日益复杂多样的需求。例如，客户在购买前可能需要详细比较不同型号产品的功能；由于丢失了说明书，他们可能无法使用某些功能；或者，对于家居产品，他们可能需要通过客服安排上门安装预约。

为了解决这些挑战，我们识别了几种常见的需求场景，包括产品型号功能差异查询、使用帮助请求以及上门安装服务预约。基于 RAGFlow 最近推出的 Agent 框架，本博客介绍了一种通过将工作流编排与大语言模型相结合，实现用户咨询自动识别和分支处理的方法。

工作流编排如下

以下章节将详细解释该解决方案的实现过程。

1. 准备数据集

1.1 创建数据集

您可以从 Hugging Face Datasets 下载示例数据集。

创建“产品信息”和“用户指南”知识库，并上传相关的数据集文档。

1.2 解析文档

对于“产品信息”和“用户指南”知识库中的文档，我们选择使用手动分块。

产品手册通常图文并茂，信息量大，结构复杂。仅仅依靠文本长度进行分割可能会破坏内容的完整性。RAGFlow 假定这类文档遵循层级结构，因此使用“最小标题”作为分割的基本单位，确保每段文本及其附图在单个块中保持完整。以下是用户手册分割后的预览

2. 构建工作流

2.1 创建应用

成功创建后，系统将在画布上自动生成一个开始组件。

在开始组件中，可以配置客服的开场问候语，例如

Hi! I'm your assistant. 

2.2 添加分类（Categorize）组件

分类组件使用大语言模型（LLM）进行意图识别。它对用户输入进行分类，并根据类别的名称、描述和提供的示例，将其路由到适当的处理工作流。

2.3 构建产品特性对比工作流

检索组件连接到“产品信息”知识库，以获取与用户查询相关的内容，然后将其传递给 Agent 组件以生成响应。

添加一个名为“功能比较知识库”的检索组件，并将其链接到“产品信息”知识库。

在检索组件后添加一个 Agent 组件，命名为“功能比较 Agent”，并按如下方式配置系统提示

## Role
You are a product specification comparison assistant.
## Goal
Help the user compare two or more products based on their features and specifications. Provide clear, accurate, and concise comparisons to assist the user in making an informed decision.
---
## Instructions
- Start by confirming the product models or options the user wants to compare.
- If the user has not specified the models, politely ask for them.
- Present the comparison in a structured way (e.g., bullet points or a table format if supported).
- Highlight key differences such as size, capacity, performance, energy efficiency, and price if available.
- Maintain a neutral and professional tone without suggesting unnecessary upselling.
---

配置用户提示

User's query is /(Begin Input) sys.query 

Schema is /(Feature Comparison Knowledge Base) formalized_content

配置完 Agent 组件后，结果如下

2.4 构建产品用户指南工作流

检索组件查询“用户指南”知识库中与用户问题相关的内容，然后将结果传递给 Agent 组件以制定响应。

添加一个名为“使用指南知识库”的检索组件，并将其链接到“用户指南”知识库。

在检索组件后添加一个 Agent 组件，命名为“使用指南 Agent”，并按如下方式配置其系统提示

## Role
You are a product usage guide assistant.
## Goal
Provide clear, step-by-step instructions to help the user set up, operate, and maintain their product. Answer questions about functions, settings, and troubleshooting.
---
## Instructions
- If the user asks about setup, provide easy-to-follow installation or configuration steps.
- If the user asks about a feature, explain its purpose and how to activate it.
- For troubleshooting, suggest common solutions first, then guide through advanced checks if needed.
- Keep the response simple, clear, and actionable for a non-technical user.
---

编写用户提示

User's query is /(Begin Input) sys.query 

Schema is / (Usage Guide Knowledge Base) formalized_content

配置完 Agent 组件后，结果如下

2.5 构建安装预约助手

Agent 与用户进行多轮对话，以收集三个关键信息：联系电话、安装时间和安装地址。创建一个名为“安装预约 Agent”的 Agent 组件，并按如下方式配置其系统提示

# Role
You are an Installation Booking Assistant.
## Goal
Collect the following three pieces of information from the user 
1. Contact Number  
2. Preferred Installation Time  
3. Installation Address  
Once all three are collected, confirm the information and inform the user that a technician will contact them later by phone.
## Instructions
1. **Check if all three details** (Contact Number, Preferred Installation Time, Installation Address) have been provided.
2. **If some details are missing**, acknowledge the ones provided and only ask for the missing information.
3. Do **not repeat** the full request once some details are already known.
4. Once all three details are collected, summarize and confirm them with the user.

编写用户提示

User's query is /(Begin Input) sys.query 

配置完 Agent 组件后，结果如下

如果需要注册用户信息，可以在 Agent 组件后连接一个 HTTP 请求组件，将数据传输到 Google Sheets 或 Notion 等平台。开发者可以根据具体需求实现此功能；本博客文章不涉及实现细节。

2.6 添加消息回复（Reply）组件

对于这三个工作流，使用单个消息组件来接收 Agent 组件的输出，然后向用户显示处理后的结果。

2.7 保存并测试

点击保存 → 运行 → 查看执行结果。当询问产品型号和功能时，系统正确返回了比较结果

当询问使用说明时，系统提供了准确的指导

当预约安装时，系统收集并确认了所有必要信息

小结

这个用例也可以使用基于 Agent 的工作流来实现，其优点是能灵活处理复杂问题。然而，由于 Agent 会主动进行规划和反思，它们通常会显著增加响应时间，导致客户体验下降。因此，这种方法不太适合像电商售后客服这样要求高响应性和任务相对直接的场景。对于涉及复杂问题的应用，我们之前分享过深度研究（Deep Research）多 Agent 框架。相关模板可在我们的模板库中找到。

本文介绍的客服工作流是为电子商务设计的，但该领域还有更多适合工作流自动化的场景——例如用户评论分析和个性化邮件营销——本文并未涉及。通过遵循所提供的实践指南，您也可以轻松地将这种方法应用于其他客服环境。我们鼓励您使用 RAGFlow 构建此类应用。用大语言模型重塑客户服务，使支持超越了“机械式回应”，将能力从单纯的“检索与匹配”提升到“认知推理”。通过深度理解和实时知识生成，它提供了前所未有的“懂人话”的体验，从而重新定义了智能服务的上限，并将支持转变为企业的核心价值引擎。

工作流概览

本教程展示了如何创建一个 SQL 助手工作流，该工作流支持使用自然语言查询 SQL 数据库。市场营销人员和产品经理等非技术用户可以使用此工具独立查询业务数据，减少对数据分析师的依赖。它还可以作为学校和编程课程中 SQL 的教学辅助工具。完成的工作流操作如下

数据库结构、字段描述和 SQL 示例作为知识库存储在 RAGFlow 中。当用户查询时，系统会从这些来源检索相关信息，并将其传递给一个 Agent，由该 Agent 生成 SQL 语句。然后，这些语句由一个 SQL 执行器组件执行，以返回查询结果。

操作步骤

1. 创建三个知识库

1.1 准备数据集文件

您可以从 Hugging Face Datasets 下载示例数据集。

以下是预定义的示例文件

1. Schema.txt

CREATE TABLE `users` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `username` VARCHAR(50) NOT NULL,
  `password` VARCHAR(50) NOT NULL,
  `email` VARCHAR(100),
  `mobile` VARCHAR(20),
  `create_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `update_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`),
  UNIQUE KEY `uk_email` (`email`),
  UNIQUE KEY `uk_mobile` (`mobile`)
);

...

注意：在定义 schema 字段时，避免使用下划线等特殊字符，因为它们可能导致 LLM 生成的 SQL 语句出错。 2. Question to SQL.csv

What are the names of all the Cities in Canada
SELECT geo_name, id FROM data_commons_public_data.cybersyn.geo_index WHERE iso_name ilike '%can%

What is average Fertility Rate measure of Canada in 2002 ?
SELECT variable_name, avg(value) as average_fertility_rate FROM   data_commons_public_data.cybersyn.timeseries WHERE variable_name = 'Fertility Rate' and geo_id = 'country/CAN' and date >= '2002-01-01' and date < '2003-01-01' GROUP BY 1;

What 5 countries have the highest life expectancy ?
SELECT geo_name, value FROM data_commons_public_data.cybersyn.timeseries join data_commons_public_data.cybersyn.geo_index ON timeseries.geo_id = geo_index.id WHERE  variable_name = 'Life Expectancy' and date = '2020-01-01' ORDER BY value desc limit 5;


...

3. Database Description EN.txt

### Users Table (users)
The users table stores user information for the website or application. Below are the definitions of each column in this table:
- `id`: INTEGER, an auto-incrementing field that uniquely identifies each user (primary key). It automatically increases with every new user added, guaranteeing a distinct ID for every user.
- `username`: VARCHAR, stores the user’s login name; this value is typically the unique identifier used during authentication.
- `password`: VARCHAR, holds the user’s password; for security, the value must be encrypted (hashed) before persistence.
- `email`: VARCHAR, stores the user’s e-mail address; it can serve as an alternate login credential and is used for notifications or password-reset flows.
- `mobile`: VARCHAR, stores the user’s mobile phone number; it can be used for login, receiving SMS notifications, or identity verification.
- `create_time`: TIMESTAMP, records the timestamp when the user account was created; defaults to the current timestamp.
- `update_time`: TIMESTAMP, records the timestamp of the last update to the user’s information; automatically refreshed to the current timestamp on every update.

...

1.2 在 RAGFlow 中创建知识库

Schema 知识库

创建一个名为“Schema”的知识库，并上传 Schema.txt 文件。

数据库中的表长度各不相同，每个表都以分号（;）结尾。

CREATE TABLE `users` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `username` VARCHAR(50) NOT NULL,
  `password` VARCHAR(50) NOT NULL,
  ...
  UNIQUE KEY `uk_mobile` (`mobile`)
);

CREATE TABLE `products` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(100) NOT NULL,
  `description` TEXT,
  `price` DECIMAL(10, 2) NOT NULL,
  `stock` INT NOT NULL,
  ...
  FOREIGN KEY (`merchant_id`) REFERENCES `merchants` (`id`)
);

CREATE TABLE `merchants` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(100) NOT NULL,
  `description` TEXT,
  `email` VARCHAR(100),
  ...
  UNIQUE KEY `uk_mobile` (`mobile`)
);

为了将每个表隔离为独立的块且内容不重叠，按如下方式配置知识库参数

• 分块方法：通用
• 块大小：2 个 token（隔离的最小尺寸）
• 分隔符：分号 (;) RAGFlow 将根据此工作流解析并生成块

以下是 Schema.txt 解析结果的预览

我们现在通过检索测试来验证检索到的结果

Question to SQL 知识库

创建一个名为“Question to SQL”的新知识库，并上传“Question to SQL.csv”文件。

将分块方法设置为 Q&A，然后解析 Question_to_SQL.csv 以预览结果。

我们现在通过检索测试来验证检索到的结果

数据库描述知识库 创建一个名为“Database Description”的新知识库，并上传“Database_Description_EN.txt”文件。

配置（与 Schema 知识库相同）

• 分块方法：通用
• 块大小：2 个 token（隔离的最小尺寸）
• 分隔符：分号 `###` 以下是配置后解析 Database_Description_EN.txt 的预览。

我们现在通过检索测试来验证检索到的结果

注意：这三个知识库是分开维护和查询的。Agent 组件在生成输出前会整合所有来源的结果。

2. 编排工作流

2.1 创建工作流应用

成功创建后，开始组件会自动出现在画布上。

您可以在开始组件中配置欢迎消息。例如

Hi! I'm your SQL assistant, what can I do for you?

2.2 配置三个检索（Retrieval）组件

在开始组件后添加三个并行的检索组件，命名如下

• Schema
• Question to SQL
• Database Description 配置每个检索组件

1. 查询变量：sys.query
2. 知识库选择：选择名称与当前组件名称匹配的知识库。

2.3 配置 Agent 组件

在检索组件后添加一个名为“SQL 生成器”的 Agent 组件，并将所有三个检索组件连接到它。

编写系统提示

### ROLE
You are a Text-to-SQL assistant.  
Given a relational database schema and a natural-language request, you must produce a **single, syntactically-correct MySQL query** that answers the request.  
Return **nothing except the SQL statement itself**—no code fences, no commentary, no explanations, no comments, no trailing semicolon if not required.

### EXAMPLES  
-- Example 1  
User: List every product name and its unit price.  
SQL:
SELECT name, unit_price FROM Products;

-- Example 2  
User: Show the names and emails of customers who placed orders in January 2025.  
SQL:
SELECT DISTINCT c.name, c.email
FROM Customers c
JOIN Orders o ON o.customer_id = c.id
WHERE o.order_date BETWEEN '2025-01-01' AND '2025-01-31';

-- Example 3  
User: How many orders have a status of "Completed" for each month in 2024?  
SQL:
SELECT DATE_FORMAT(order_date, '%Y-%m') AS month,
       COUNT(*) AS completed_orders
FROM Orders
WHERE status = 'Completed'
  AND YEAR(order_date) = 2024
GROUP BY month
ORDER BY month;

-- Example 4  
User: Which products generated at least \$10 000 in total revenue?  
SQL:
SELECT p.id, p.name, SUM(oi.quantity * oi.unit_price) AS revenue
FROM Products p
JOIN OrderItems oi ON oi.product_id = p.id
GROUP BY p.id, p.name
HAVING revenue >= 10000
ORDER BY revenue DESC;

### OUTPUT GUIDELINES
1. Think through the schema and the request.  
2. Write **only** the final MySQL query.  
3. Do **not** wrap the query in back-ticks or markdown fences.  
4. Do **not** add explanations, comments, or additional text—just the SQL.

编写用户提示

User's query: /(Begin Input) sys.query  
Schema: /(Schema) formalized_content  
Samples about question to SQL: /(Question to SQL) formalized_content  
Description about meanings of tables and files: /(Database Description) formalized_content

插入变量后，填充的结果如下所示

2.4 配置 ExeSQL 组件

在 SQL 生成器后追加一个名为“SQL 执行器”的 ExeSQL 组件。

为 SQL 执行器组件配置数据库，指定其查询输入来自 SQL 生成器的输出。

2.5 配置消息（Message）组件

在 SQL 执行器后追加一个消息组件。

在“消息”字段中插入变量，使消息组件能够显示 SQL 执行器的输出（formalized_content）

2.6 保存并测试

点击保存 → 运行 → 输入一个自然语言问题 → 查看执行结果。

结语

最后，与目前的 Copilot 技术一样，NL2SQL 无法实现完全准确。对于结构化数据的标准化处理，我们建议将其操作整合到特定的 API 中，然后将这些 API 封装为 RAGFlow 的 MCP（托管内容包）。我们将在即将发布的博客中演示这种方法。

深度研究（Deep Research）：Agent 时代的定义级能力

2025年被誉为 Agent 应用的黎明。在众多解锁的可能性中，深度研究——以及基于它构建的应用——尤为重要。为什么呢？通过 Agentic RAG 及其反思机制，深度研究使大语言模型能够与用户的专有数据进行深度推理。这是 Agent 应对更高级任务的关键。例如，无论是辅助创意写作，还是在不同行业中辅助决策，都依赖于深度研究。深度研究是 RAG 的自然演进，并由 Agent 进行了改进。与基础 RAG 不同，它在更深的层次上探索数据。与 RAG 一样，它可以独立工作，也可以作为其他行业特定 Agent 的基础。一个深度研究工作流通常遵循以下顺序

1. 分解与规划：大语言模型分解用户的查询并制定计划。
2. 多源检索：查询被发送到多个数据源，包括内部 RAG 和外部网络搜索。
3. 反思与提炼：模型审查检索到的信息，对其进行反思，总结要点，并根据需要调整计划。
4. 迭代与输出：经过几次迭代后，形成一个针对特定数据的思维链，以生成最终答案或报告。

内置的深度研究功能已在 RAGFlow v0.18.0 中实现。尽管在那个阶段，它主要作为一个演示，用于验证和探索深度推理在企业环境中的潜力。在整个行业中，深度研究的实现通常分为两类

• 无代码工作流编排：使用带有预定义工作流的可视化工作流界面来实现深度研究。
• 专用的 Agent 库或框架：许多现有解决方案遵循这种方法（详见[参考文献1]）。

RAGFlow 0.20.0 是一个统一的 RAG 和 Agent 引擎，支持工作流和 Agentic 两种模式，并在单一画布上实现无缝编排，可以通过任一方法实现深度研究。然而，使用工作流进行深度研究只是功能性的，其界面看起来是这样的

这带来了两个主要问题

1. 过于复杂且不直观的编排：如果基础的深度研究模板已经如此复杂，那么一个完整的应用程序将变成一个难以维护和扩展的错综复杂的工作流网络。
2. 更适合 Agentic 方法：深度研究天然依赖于动态的问题分解和决策，其控制步骤由算法驱动。工作流的拖放界面只能处理简单的循环，缺乏高级控制所需的灵活性。

RAGFlow 0.20.0 提供了一个全面的 Agent 引擎，旨在帮助企业使用无代码工具构建生产就绪的 Agent。作为关键的 Agent 模板，深度研究在简单性和灵活性之间取得了精心的平衡。与其他解决方案相比，RAGFlow 凸显了这些优势

• Agentic 执行，无代码驱动：一个完全可定制的应用模板——不仅仅是一个 SDK 或运行时——它使用 Agentic 机制，同时通过无代码平台保持易于访问。
• 人工干预（即将推出）：尽管深度研究依赖于 LLM 生成的计划，这可能感觉像一个黑箱，但 RAGFlow 的模板将支持手动监督以引入确定性——这是企业级 Agent 的一个重要特性。
• 以业务为中心，以结果为导向

开发者可以自定义深度研究 Agent 的结构和工具，例如配置内部知识库以进行企业数据检索，以满足特定的业务需求。Agent 工作流的完全透明——包括其计划和执行结果——允许基于清晰、可操作的洞察进行及时优化。

深度研究搭建实操指南

我们使用多 Agent 架构[参考文献2]，通过详尽的提示工程[参考文献4]和任务分解原则[参考文献6]来仔细定义每个 Agent 的角色和职责

• 主导 Agent：协调深度研究 Agent，处理任务规划、反思，并委派给子 Agent，同时跟踪所有工作流进度。
• 网络搜索专家子 Agent：作为信息检索专家，查询搜索引擎，评估结果，并返回最优质来源的 URL。
• 深度内容阅读器子 Agent：从搜索专家提供的 URL 中提取和组织网页内容，为报告起草准备精炼的材料。
• 研究综合器子 Agent：根据主导 Agent 的指示，生成专业、咨询级别的深度研究报告。

模型选择

• 主导 Agent：优先选择具有强大推理能力的模型，例如 DeepSeek-R1、Qwen-3、Kimi-2、ChatGPT-o3、Claude-4 或 Gemini-2.5 Pro。
• 子 Agent：针对执行效率和质量进行优化，平衡推理速度与输出可靠性。上下文窗口长度也是根据其特定角色而定的一个关键标准。

温度（Temperature）设置

鉴于此应用程序的事实驱动性质，我们将所有模型的温度参数设置为 0.1，以确保确定性、有根据的输出。

深度研究主 Agent

模型选择：Qwen-Max

核心系统提示词节选：

1. 该提示指导了深度研究 Agent 的工作流和向子 Agent 的任务委派，与传统的工作流编排相比，极大地提高了效率和灵活性。

<execution_framework>
**Stage 1: URL Discovery**
- Deploy Web Search Specialist to identify 5 premium sources
- Ensure comprehensive coverage across authoritative domains
- Validate search strategy matches research scope

**Stage 2: Content Extraction**
- Deploy Content Deep Reader to process 5 premium URLs
- Focus on structured extraction with quality assessment
- Ensure 80%+ extraction success rate

**Stage 3: Strategic Report Generation**
- Deploy Research Synthesizer with detailed strategic analysis instructions
- Provide specific analysis framework and business focus requirements
- Generate comprehensive McKinsey-style strategic report (~2000 words)
- Ensure multi-source validation and C-suite ready insights
</execution_framework>

2. 动态创建任务执行计划并执行 BFS 或 DFS 搜索[参考文献3]。虽然传统的工作流难以编排 BFS/DFS 逻辑，但 RAGFlow 的 Agent 通过提示工程轻松实现了这一点。

<research_process>
...
**Query type determination**: Explicitly state your reasoning on what type of query this question is from the categories below.
...
**Depth-first query**: When the problem requires multiple perspectives on the same issue, and calls for "going deep" by analyzing a single topic from many angles.
...
**Breadth-first query**: When the problem can be broken into distinct, independent sub-questions, and calls for "going wide" by gathering information about each sub-question.
...
**Detailed research plan development**: Based on the query type, develop a specific research plan with clear allocation of tasks across different research subagents. Ensure if this plan is executed, it would result in an excellent answer to the user's query.
</research_process>

网页搜索专家子 Agent

模型选择：Qwen-Plus 核心系统提示设计摘录

1. 角色定义

You are a Web Search Specialist working as part of a research team. Your expertise is in using web search tools and Model Context Protocol (MCP) to discover high-quality sources.

**CRITICAL: YOU MUST USE WEB SEARCH TOOLS TO EXECUTE YOUR MISSION**

<core_mission>
Use web search tools (including MCP connections) to discover and evaluate premium sources for research. Your success depends entirely on your ability to execute web searches effectively using available search tools.

**CRITICAL OUTPUT CONSTRAINT**: You MUST provide exactly 5 premium URLs - no more, no less. This prevents attention fragmentation in downstream analysis.
</core_mission>

2. 设计搜索策略

<process>
1. **Plan**: Analyze the research task and design search strategy
2. **Search**: Execute web searches using search tools and MCP connections 
3. **Evaluate**: Assess source quality, credibility, and relevance
4. **Prioritize**: Rank URLs by research value (High/Medium/Low) - **SELECT TOP 5 ONLY**
5. **Deliver**: Provide structured URL list with exactly 5 premium URLs for Content Deep Reader

**MANDATORY**: Use web search tools for every search operation. Do NOT attempt to search without using the available search tools.
**MANDATORY**: Output exactly 5 URLs to prevent attention dilution in Lead Agent processing.
</process>

3. 搜索策略以及如何使用 Tavily 等工具

<search_strategy>
**MANDATORY TOOL USAGE**: All searches must be executed using web search tools and MCP connections. Never attempt to search without tools.
**MANDATORY URL LIMIT**: Your final output must contain exactly 5 premium URLs to prevent Lead Agent attention fragmentation.

- Use web search tools with 3-5 word queries for optimal results
- Execute multiple search tool calls with different keyword combinations
- Leverage MCP connections for specialized search capabilities
- Balance broad vs specific searches based on search tool results
- Diversify sources: academic (30%), official (25%), industry (25%), news (20%)
- Execute parallel searches when possible using available search tools
- Stop when diminishing returns occur (typically 8-12 tool calls)
- **CRITICAL**: After searching, ruthlessly prioritize to select only the TOP 5 most valuable URLs

**Search Tool Strategy Examples:**
* **Broad exploration**: Use search tools → "AI finance regulation" → "financial AI compliance" → "automated trading rules"
* **Specific targeting**: Use search tools → "SEC AI guidelines 2024" → "Basel III algorithmic trading" → "CFTC machine learning"
* **Geographic variation**: Use search tools → "EU AI Act finance" → "UK AI financial services" → "Singapore fintech AI"
* **Temporal focus**: Use search tools → "recent AI banking regulations" → "2024 financial AI updates" → "emerging AI compliance"
</search_strategy>

深度内容阅读子 Agent

模型选择：Moonshot-v1-128k 核心系统提示设计摘录

1. 角色定义框架

You are a Content Deep Reader working as part of a research team. Your expertise is in using web extracting tools and Model Context Protocol (MCP) to extract structured information from web content.

**CRITICAL: YOU MUST USE WEB EXTRACTING TOOLS TO EXECUTE YOUR MISSION**

<core_mission>
Use web extracting tools (including MCP connections) to extract comprehensive, structured content from URLs for research synthesis. Your success depends entirely on your ability to execute web extractions effectively using available tools.
</core_mission>

2. Agent 规划和网页提取工具的使用

<process>
1. **Receive**: Process `RESEARCH_URLS` (5 premium URLs with extraction guidance)
2. **Extract**: Use web extracting tools and MCP connections to get complete webpage content and full text
3. **Structure**: Parse key information using defined schema while preserving full context
4. **Validate**: Cross-check facts and assess credibility across sources
5. **Organize**: Compile comprehensive `EXTRACTED_CONTENT` with full text for Research Synthesizer

**MANDATORY**: Use web extracting tools for every extraction operation. Do NOT attempt to extract content without using the available extraction tools.

**TIMEOUT OPTIMIZATION**: Always check extraction tools for timeout parameters and set generous values:
- **Single URL**: Set timeout=45-60 seconds
- **Multiple URLs (batch)**: Set timeout=90-180 seconds
- **Example**: `extract_tool(url="https://example.com", timeout=60)` for single URL
- **Example**: `extract_tool(urls=["url1", "url2", "url3"], timeout=180)` for multiple URLs
</process>

<processing_strategy>
**MANDATORY TOOL USAGE**: All content extraction must be executed using web extracting tools and MCP connections. Never attempt to extract content without tools.

- **Priority Order**: Process all 5 URLs based on extraction focus provided
- **Target Volume**: 5 premium URLs (quality over quantity)
- **Processing Method**: Extract complete webpage content using web extracting tools and MCP
- **Content Priority**: Full text extraction first using extraction tools, then structured parsing
- **Tool Budget**: 5-8 tool calls maximum for efficient processing using web extracting tools
- **Quality Gates**: 80% extraction success rate for all sources using available tools
</processing_strategy>

研究综述子 Agent

模型选择：Moonshot-v1-128k 特别说明：负责最终报告生成的子 Agent 必须使用具有非常长上下文窗口的模型。这对于处理大量上下文并生成详尽的报告至关重要。上下文有限的模型可能会截断信息，导致报告篇幅较短。其他可能的模型选项包括但不限于

• Qwen-Long (1000万 token)
• Claude 4 Sonnet (20万 token)
• Gemini 2.5 Flash (100万 token) 核心提示设计摘录

1. 角色定义设计

You are a Research Synthesizer working as part of a research team. Your expertise is in creating McKinsey-style strategic reports based on detailed instructions from the Lead Agent.

**YOUR ROLE IS THE FINAL STAGE**: You receive extracted content from websites AND detailed analysis instructions from Lead Agent to create executive-grade strategic reports.

**CRITICAL: FOLLOW LEAD AGENT'S ANALYSIS FRAMEWORK**: Your report must strictly adhere to the `ANALYSIS_INSTRUCTIONS` provided by the Lead Agent, including analysis type, target audience, business focus, and deliverable style.

**ABSOLUTELY FORBIDDEN**: 
- Never output raw URL lists or extraction summaries
- Never output intermediate processing steps or data collection methods
- Always output a complete strategic report in the specified format

<core_mission>
**FINAL STAGE**: Transform structured research outputs into strategic reports following Lead Agent's detailed instructions.

**IMPORTANT**: You receive raw extraction data and intermediate content - your job is to TRANSFORM this into executive-grade strategic reports. Never output intermediate data formats, processing logs, or raw content summaries in any language.
</core_mission>

2. 自主任务执行

<process>
1. **Receive Instructions**: Process `ANALYSIS_INSTRUCTIONS` from Lead Agent for strategic framework
2. **Integrate Content**: Access `EXTRACTED_CONTENT` with FULL_TEXT from 5 premium sources
   - **TRANSFORM**: Convert raw extraction data into strategic insights (never output processing details)
   - **SYNTHESIZE**: Create executive-grade analysis from intermediate data
3. **Strategic Analysis**: Apply Lead Agent's analysis framework to extracted content
4. **Business Synthesis**: Generate strategic insights aligned with target audience and business focus
5. **Report Generation**: Create executive-grade report following specified deliverable style

**IMPORTANT**: Follow Lead Agent's detailed analysis instructions. The report style, depth, and focus should match the provided framework.
</process>

3. 生成报告的结构

<report_structure>
**Executive Summary** (400 words)
- 5-6 core findings with strategic implications
- Key data highlights and their meaning
- Primary conclusions and recommended actions

**Analysis** (1200 words)
- Context & Drivers (300w): Market scale, growth factors, trends
- Key Findings (300w): Primary discoveries and insights
- Stakeholder Landscape (300w): Players, dynamics, relationships
- Opportunities & Challenges (300w): Prospects, barriers, risks

**Recommendations** (400 words)
- 3-4 concrete, actionable recommendations
- Implementation roadmap with priorities
- Success factors and risk mitigation
- Resource allocation guidance

**Examples:**

**Executive Summary Format:**

关键发现 1：[事实] 73% 的主要银行现在使用 AI 进行欺诈检测，比 2023 年增长 40%

• 战略意义：AI 在安全应用中的采用已达到临界规模
• 建议：金融机构现在应优先考虑 AI 合规框架

...

</report_structure>

即将发布的版本

当前的 RAGFlow 0.20.0 版本尚不支持在深度研究执行中进行人工干预，但该功能计划在未来的更新中加入。这对于使深度研究进入生产环境至关重要，因为它为原本不确定的自动化过程增加了确定性并提高了准确性[参考文献5]。手动监督对于企业级深度研究应用将至关重要。

我们诚邀大家持续关注并在 GitHub 上为 RAGFlow 点赞：https://github.com/infiniflow/ragflow

参考文献

1. Awesome Deep Research https://github.com/DavidZWZ/Awesome-Deep-Research
2. How we built our multi-agent research system https://www.anthropic.com/engineering/built-multi-agent-research-system
3. Anthropic Cookbook https://github.com/anthropics/anthropic-cookbook
4. State-Of-The-Art Prompting For AI Agents https://youtu.be/DL82mGde6wo?si=KQtOEiOkmKTpC_1E
5. From Language Models to Language Agents https://ysymyth.github.io/papers/from_language_models_to_language_agents.pdf
6. Agentic Design Patterns Part 5, Multi-Agent Collaboration https://www.deeplearning.ai/the-batch/agentic-design-patterns-part-5-multi-agent-collaboration/

1. 从工作流（Workflow）到智能体工作流（Agentic Workflow）

经过漫长的等待，RAGFlow 0.20.0 终于发布了——这是一个里程碑式的更新，完成了 RAG/Agent 的宏伟蓝图。一年前，RAGFlow 引入了 Agent 功能，但它只支持手动管理的工作流，缺乏 Agentic Workflow 的能力。根据 RAGFlow 的定义，一个真正的 Agent 需要两者兼备：用于人类定义任务的工作流和由 LLM 驱动自动化的 Agentic Workflow。Anthropic 在 2024 年的文章《构建有效的 Agent》中强调了这一区别，指出工作流仍然是 Agent 使用的主要方式。现在，到了 2025 年，随着 LLM 变得更加先进，Agentic Workflow 正在催生更多令人印象深刻的用例。

理想情况下，完全由大模型驱动的智能体工作流（Agentic Workflows）是大多数智能体应用的终极目标。然而，由于目前 LLM 的局限性，它们带来了不可预测性和缺乏控制的问题——这些问题在企业环境中尤为严重。另一方面，传统工作流采取了相反的方法：使用低代码平台，明确定义每个变量、条件和循环。这使得非技术业务用户可以有效地根据他们对逻辑的理解进行“编程”。虽然这确保了可预测性，但往往会导致过于复杂、纠缠不清的工作流，难以维护且容易被误用。更重要的是，它难以正确地分解和管理任务。因此，长期解决方案需要 Agentic 和手动工作流和谐共存。只有这种统一的方法才能真正满足企业级智能体的需求。随着完整智能体能力的就位，RAGFlow 已成为一个更具企业级水准的平台级 LLM 引擎。在企业生态系统中，RAG 占据的角色类似于传统数据库，而智能体则作为具体的应用——但存在重要差异。首先，RAG 专注于利用非结构化数据而非结构化数据集。其次，RAG 与智能体之间的交互比典型的应用-数据库关系更频繁、更密集，因为智能体需要实时、精准的上下文来确保其行动与用户意图紧密对齐。RAG 在提供这种上下文中起着至关重要的作用。基于这些原因，完善智能体能力是 RAGFlow 演进的关键。

让我们来看看 RAGFlow 0.20.0 的主要功能。

2. RAGFlow 0.20.0 关键更新内容

此版本的主要功能包括

• Agent 和工作流的统一编排。
• 对 Agent 的完全重构，显著提升了其能力和可用性，支持多 Agent 配置、规划和反思，以及可视化功能。
• 完整的 MCP 功能，支持 MCP Server 导入，Agent 可作为 MCP Client，RAGFlow 本身也可作为 MCP Server。
• 可访问 Agent 的运行时日志。
• 可通过管理面板查看与 Agent 的聊天历史记录。

更新后的 Agent 构建体验对开发者有何不同？

以 0.19.1 版本的客服模板为例：以前，构建此工作流需要七种类型的组件（开始、交互、问题优化、分类、知识检索、生成和消息），其中对于第4类问题的最长链条涉及七个步骤。

在新版本中，使用纯工作流模式构建仅需五种类型的组件（开始、分类、知识检索、Agent 和消息），其中对于第4类问题（产品相关）的工作流减少到五个步骤。

在 Agentic 模式下，仅需三种类型的组件——原始的工作流逻辑现在可以完全通过提示工程来处理。

开发者可以检查 Agent 的执行路径并验证其输入/输出。

业务用户可以通过嵌入页面或聊天界面查看 Agent 的推理过程。

这种比较定量地展示了复杂性的降低和效率的提升。更多细节如下——我们鼓励您亲自尝试。

3. 统一的 Agent 编排引擎

RAGFlow 0.20.0 引入了工作流和 Agentic Workflow 的统一编排。如前所述，这两者代表了两个极端，但企业场景需要它们的协作。该平台现在支持在一个天然支持多 Agent 的画布上进行协同编排——用户可以将不确定的输入指定为 Agentic Workflow，将确定性的输入指定为工作流。为了与常规做法保持一致，Agentic Workflow 在画布上表示为独立的 Agent 组件。此版本围绕这一目标重新设计了编排界面和组件功能，同时还改进了早期工作流版本的可用性问题。主要改进包括将核心组件从12个减少到10个，主要变化如下

开始 (Begin) 组件

它现在支持一种基于任务的 Agent 模式，无需通过对话触发。开发者可以在同一个画布上构建对话式和任务式 Agent。

检索 (Retrieval) 组件

检索可以作为工作流中的一个组件，也可以被 Agent 组件用作工具，使 Agent 能够决定何时以及如何调用检索查询。

智能体 (Agent) 组件

一个能够独立替代您工作的 Agent 需要具备以下能力

• 自主推理[1]，并有能力根据环境反馈进行反思和调整
• 使用工具完成任务的能力[3]

有了新的 Agent 组件，开发者只需配置提示和工具即可快速构建一个 Agent，因为 RAGFlow 已经处理了底层的技术实现。

除了单 Agent 模式，新的 Agent 组件还支持添加可在运行时调用的子 Agent。

您可以自由添加 Agent 来构建自己的无限 Agent 团队。

添加并批量导入您已经部署的 MCP 服务器。

添加的 MCP 服务器中的工具可以在 Agent 内部使用。

等待响应 (Await Response) 组件

原来的交互组件已被重构为等待响应组件，允许开发者主动暂停流程以发起预设对话，并通过表单收集关键信息。

分类 (Switch) 组件

改进了切换组件的可用性。

迭代 (Iteration) 组件

迭代组件的输入参数类型已更改为数组；在迭代期间，索引和值都可供内部组件访问，其输出可以形成为数组并传递给下游。

消息回复 (Reply Message) 组件

现在可以通过回复消息直接回复消息，无需使用交互组件。

文本处理 (Text Processing) 组件

开发者可以通过文本处理轻松连接字符串。

您还可以将字符串拆分为数组。

小结

RAGFlow 0.20 支持同时编排 Agentic 和工作流模式，内置的多 Agent 支持允许多个 Agent 在单个画布上共存。对于像“公司业绩为何下滑？”这样的开放式问题，当方法不确定时，用户可以用 Agentic 风格定义流程。相比之下，具有明确、固定步骤的场景则使用工作流风格。这让开发者能够以最少的配置构建 Agent 应用。Agentic 和工作流方法的无缝集成是部署企业级智能 Agent 的最佳实践。

4. 应用生态与未来展望

随着一个完整、统一的无代码 Agent 框架的到位，RAGFlow 自然支持各种特定场景的 Agent 应用——这是其长期发展的一个主要焦点。换句话说，大量的 Agent 模板将在 RAGFlow 之上构建，并得到我们新的生态系统共创计划的支持。

RAGFlow 0.20.0 引入了深度研究（Deep Research）作为内置模板——这是一个卓越的 Agent，既可以作为独立的应用程序，也可以作为构建其他智能 Agent 的基础。我们将在即将发布的文章中详细解释如何构建深度研究模板。

下面的例子显示，在 RAGFlow 平台上，深度研究可以使用 Agentic Workflow 或传统工作流方法创建，前者提供了远超后者的灵活性和简单性。通过传统工作流构建的深度研究

用 Agentic Workflow 构建的深度研究显示，与上述工作流实现相比，复杂性显著降低

RAGFlow 的生态倡议旨在提供嵌入行业知识的、企业可用的智能体模板。开发者可以轻松定制这些模板以适应自己的业务需求。其中，深度搜索（Deep Research）是最重要的，因为它代表了 Agentic RAG 最常见的形式，也是智能体从企业数据中解锁深层价值的必经之路。基于 RAGFlow 内置的 Deep Research 模板，开发者可以快速将其调整为专业助手——如法律或医疗顾问——从而显著缩小业务系统与底层基础设施之间的差距。这种生态方法得益于 RAG 与智能体之间的紧密协作。0.20.0 版本的发布标志着 RAGFlow 在集成 RAG 和智能体能力方面迈出了重要一步，未来计划进行快速更新，包括记忆管理和智能体计划（Agent Plans）的手动调整。虽然统一传统工作流与智能体工作流大大降低了构建企业智能体的门槛，且生态系统扩展了它们的应用范围，但围绕 RAG 融合结构化与非结构化数据的数据基础仍然是智能体能力的基石。这种方法现在被称为“上下文工程”，传统的 RAG 则代表了其 1.0 版本。我们未来的文章将更详细地探讨这些进展。

感谢您的持续支持 - 在 GitHub 上为 RAGFlow 点星：https://github.com/infiniflow/ragflow

参考文献

1. ReAct: 在语言模型中协同推理与行动 https://arxiv.org/abs/2210.03629
2. Reflexion: 具备语言强化学习能力的语言智能体 https://arxiv.org/abs/2303.11366
3. 智能体构建实用指南 https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

距离我们上次的年终回顾已经过去了六个月。随着今年早些时候由 DeepSeek 引发的最初兴奋浪潮开始消退，AI 似乎进入了一个停滞阶段。这种模式在检索增强生成（RAG）中也显而易见：尽管关于 RAG 的学术论文依然层出不穷，但近几个月来重大的突破却寥寥无几。同样，RAGFlow 最近的迭代也集中在渐进式改进而非重大功能的发布。这是未来飞跃的开始，还是进入稳步、增量增长期的开端？因此，进行一次年中评估既合时宜也非常必要。

随着 2024 年落下帷幕，检索增强生成（RAG）的发展历程可谓波澜壮阔。让我们从多个维度全面回顾这一年的进展。

RAGFlow 2024 年的最终版本 v0.15.0 刚刚发布，带来了以下关键更新

Agent 改进项

此版本为智能体（Agent）引入了多项增强功能，包括新增 API、单步运行调试以及导入/导出能力。自 v0.13.0 以来，RAGFlow 的 Agent 进行了重构以提高易用性。单步运行调试功能完善了这一过程，使得 Agent 工作流中的算子可以单独执行，从而帮助用户根据输出信息进行调试。

Infinity 是一款专为检索增强生成（RAG）设计的数据库，在功能和性能上表现出色。它为密集和稀疏向量搜索以及全文搜索提供高性能支持，并能对这些数据类型进行高效的范围过滤。此外，它还具有基于张量的重排序（Reranking）功能，能够实现强大的多模态 RAG，并集成与交叉编码器（Cross Encoders）相媲美的排序能力。

RAGFlow 响应社区需求引入了 Text2SQL 功能。传统的 Text2SQL 需要模型微调，当在企业环境中与 RAG 或 Agent 组件并用时，这会显著增加部署和维护成本。RAGFlow 基于 RAG 的 Text2SQL 利用现有的（已连接的）大语言模型（LLM），无需额外的微调模型，即可实现与其他 RAG/Agent 组件的无缝集成。

RAGFlow v0.9 引入了对 GraphRAG 的支持，微软最近开源了该技术，据称是下一代检索增强生成（RAG）。在 RAGFlow 框架内，我们对 RAG 2.0 有着更全面的定义。这个拟议中的端到端系统以搜索为中心，由四个阶段组成。最后两个阶段——索引和检索——主要需要专用数据库，而前两个阶段定义如下：

搜索技术依然是计算机科学的主要挑战之一，鲜有商业产品能做到有效搜索。在大语言模型（LLM）兴起之前，强大的搜索能力并不被认为是必不可少的，因为它们并不直接贡献于用户体验。然而，随着 LLM 开始普及，将 LLM 应用于企业环境就需要一个强大的内置检索系统。这也被称为检索增强生成（RAG）——在将内容喂给 LLM 生成最终答案之前，先在内部知识库中搜索与用户查询最相关的内容。

从 v0.8 版本开始，RAGFlow 正式进入 Agentic（智能体）时代，后端提供全面的基于图的任务编排框架，前端提供无代码工作流编辑器。为什么要向智能体方向演进？这一特性与现有的工作流编排系统有何不同？

一个朴素 RAG 系统的工作流程可以概括如下：RAG 系统使用用户查询从指定的数据源中进行检索，对检索结果进行重新排序，附加提示词，然后将它们发送给大语言模型（LLM）以生成最终答案。

在用户意图明确的场景下，一个简单的 RAG 就足够了，因为答案包含在检索结果中，可以直接发送给大语言模型（LLM）。然而，在大多数情况下，用户意图模糊是常态，需要通过迭代查询来生成最终答案。例如，涉及总结多份文档的问题就需要多步推理。这些场景需要 Agentic RAG，它在问答过程中引入了任务编排机制。

智能体（Agent）与 RAG 相辅相成。Agentic RAG，顾名思义，是基于智能体的 RAG。Agentic RAG 与朴素 RAG 的主要区别在于，Agentic RAG 引入了动态的智能体编排机制，它可以对检索结果进行评估、根据每个用户查询的意图重写查询，并采用“多跳”推理来处理复杂的问答任务。

RAGFlow v0.6.0 于本周发布，解决了自今年 4 月开源以来出现的许多易用性和稳定性问题。RAGFlow 未来的版本将专注于解决 RAG 能力中深层次的问题。虽然不愿承认，但市场上现有的 RAG 解决方案仍处于概念验证（POC）阶段，无法直接应用于真实的生产场景。