从 RAG 到 Context —— RAG 2025 年度回顾

2025年12月22日阅读时长 37 分钟

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 提供外部知识的范式主要分为四类：

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

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

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

巨大的 Token 消耗：实体提取、去重和社区摘要（community summarization）消耗的 Token 可能是原始文本的数倍至数十倍。
预期的实体提取质量与实际存在差距：传统知识图谱由领域专家精心设计和验证，具有极高的质量，适用于直接的视觉分析和交互。相比之下，GraphRAG 自动提取的实体和关系往往包含大量噪声、冗余或错误。用视觉知识图谱的标准来衡量它们往往会导致失望——“好看但不中用”。
知识破碎化：即使图算法发现了相关的社区并生成了摘要，输出结果仍然是围绕特定主题的“知识片段”集合。基于这些离散片段生成最终答案对 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 上下文通常需要精心组装三类数据：

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

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

对企业私有、非结构化领域文档数据的检索——即 RAG。
对 Agent 交互过程中生成的对话历史和状态数据（尤其是 LLM 生成的内容）的检索——即记忆（Memory）。
对来自封装好的企业服务和 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 正式从早期的“手工作坊”阶段过渡到“平台化、规模化、可持续运营”的工业时代。

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

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

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

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

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

模态转换路径：利用 OCR 或 VLM 将图像、表格等转换为纯文本描述。这将多模态问题简化为单模态文本检索问题。它与现有的文本 RAG 架构兼容，但存在丢失原始视觉布局、颜色和精细特征的风险。
原生多模态路径：直接对图像进行视觉 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 基础设施。

参考文献

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