从 RAG 到 Context：2025 年 RAG 技术年终总结

显示全部楼层

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">过去的2025年，对于检索增强生成（RAG）技术而言，是经历深刻反思、激烈辩论与实质性演进的一年。

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">尽管围绕其“临时性”与“被替代性”的疑云一直笼罩，但纵观全年发展轨迹，RAG 并未如部分激进观点所预言的那样黯然退场，反而在企业级 AI 落地的深水区中，愈发彰显出其作为数据基础设施的不可替代性。

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">回顾全年，RAG 的发展态势可谓错综复杂：

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">一方面，其实际应用效果面临诸多质疑，部分源于 RAG 系统自身“易用难精”的调优挑战；另一方面，其舆论关注度也似乎被 2025 年大模型应用的绝对焦点——AI Agents 所分流。

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">然而，一个颇具意味的现象是，尽管争议增多且并非处于流量中心，但真正致力于构建核心竞争力、严肃对待 AI 能力建设的企业，尤其是中大型组织，对 RAG 的投入反而更为深入和系统化。

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">

ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;color: rgb(31, 35, 41);margin: 0px 0px 4px;word-break: break-all;min-height: 20px;">RAG 在企业 AI 架构中非但未被边缘化，反而更加稳固地扮演着核心角色，其作为关键基础设施的地位并未动摇，正如下图所示，它构成了企业智能能力的坚实底座。

因此，我们首先需要超越表面的争议，深入审视 RAG 技术本身的生命力：它究竟只是一种弥补大模型知识缺陷的过渡性“创可贴”方案，还是具备持续演进、并能成为下一代 AI 应用基石的架构？

要回答这个问题，我们必须系统盘点其在技术改进、架构演进以及在 Agent 时代所扮演的新角色。

RAG 还能改进么？

长上下文和 RAG 之争

进入2025年，围绕RAG的诸多争议，其根源可归结为一个核心矛盾：企业对 RAG “既离不了，又不满意”的普遍心态已形成共识。RAG 降低了接入私有知识的门槛，但其效果的稳定性和准确性（尤其是面对复杂查询时）往往需要大量精细调优，这使得其总拥有成本评估变得复杂。

因此，2024 年学术界与投资界热烈探讨的“长上下文（Long Context）能否取代 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 个数量级的差距。方案 2 即将所有文档数据经 LLM 前向传播处理为张量后存入专门的 KV Cache 系统，其成本相比 RAG 仍高出至少一个数量级。

即便将 KV Cache 升级为数据库与推理一体化引擎（如 AlayaDB【文献 1】所倡导的路径），在技术层面仍存在多重根本性限制：

1.大数据量与检索性能的矛盾：
若预处理后的张量数据总量远超 GPU 显存容量，则系统必须引入二级存储和相应的检索机制来实现按需加载。这将导致推理过程变为“边生成边搜索”，对 I/O 延迟和检索速度的要求变得极其苛刻。
为了满足极低延迟，通常不得不将整个数据集和 LLM 推理服务强绑定部署于同一物理机或高性能计算集群的紧密网络域内，这在架构上极大地牺牲了灵活性与可扩展性，限制了业务部署形态。

2.场景局限性：
该方法主要适用于相对静态的、以事实性知识问答为主的文本库，难以灵活、低成本地结合企业内部复杂多变的业务规则、实时更新的知识以及进行多样化的组合查询。

3.技术融合趋势：
该方法与 RAG 并不冲突。即该方法未来走向实用，也极有可能被 RAG 技术体系所吸纳和融合，成为 RAG 架构中的一个优化组件。

方案 3（无索引 RAG）因 Claude Code 为其代码助手 Agent 引入而受到一定关注。那么，一个朴素的问题是：在特定领域，简单的字符串匹配（Grep）能否取代复杂的基于检索的 RAG 架构？

对于组织良好、格式纯粹、术语固定的代码库或某些高度结构化的文本数据（如日志文件），基于规则的Grep或关键词搜索或许能以极低成本获得不错的效果，从而节约索引构建与维护的开销。

但对于绝大多数企业环境中的多模态、非结构化或半结构化数据（如产品手册、会议纪要、设计图纸、含表格和图片的报告），此方法则完全失效。

事实上，即使是看似规则的代码搜索，领先的产品如 Augment Code 也未采用简单的Grep，而是专门微调了适用于代码语义的 Embedding 模型。

原因在于，为代码助手提供有效的上下文，不仅需要精确的字符串匹配（找函数名），更需要语义近似的代码片段（实现相似功能的不同写法）、相关的 API 文档以及代码块的依赖关系。

至于企业级应用所必需的多样化自然语言查询、高并发、低延迟响应以及结合业务元数据的过滤与排序等需求，则更非 Grep 所能覆盖。

因此，RAG 及其前身——企业搜索引擎，始终是面向复杂企业级需求的综合性技术与架构解决方案，其价值在于提供一种系统化、可扩展、可治理的知识接入与管理能力。

RAG 对话效果的优化路径

回归 RAG 技术本质，其回答不准确、不稳定的常见根源，源于传统“分块-嵌入-检索”流水线中存在一个结构性矛盾：使用单一粒度、固定大小的文本块（Chunk）同时承担两项存在内在冲突的任务：

语义匹配（召回）：为了在语义空间中进行相似度搜索时获得高精度召回，需要文本块较小（如100-256个 Token），使其语义焦点明确，减少无关信息的干扰。
上下文理解（利用）：为了向 LLM 提供足够完整、连贯的上下文以生成优质回答，需要文本块较大（如 1024 甚至更多 Token），以保证逻辑的完整性和背景信息的充足。

这导致系统设计者不得不在“精准但碎片化”与“完整但模糊”之间进行艰难权衡，常常顾此失彼。小切片可能导致检索到的信息支离破碎，LLM 无法理解全貌；大切片则可能引入噪声，降低检索精度，并且由于向量表示是对整个块的概括，也会丢失内部细节的区分度。

因此，一个根本性的改进思路是将 RAG 流程从“一步走”解耦为两个逻辑阶段——“搜索（Search）”与“检索（Retrieve）”——并允许它们采用不同的文本粒度：

搜索（Search）：类比“扫描”或“定位”，核心目标是快速、精准地从海量数据中找出所有可能相关的“线索点”。此阶段应使用较小的、语义纯净的文本单元，以实现高召回率与高精度。像"扫描"或"定位"，需使用小块文本以实现高精度的语义匹配。

检索（Retrieve）：类比“阅读”或“理解”，核心目标是为 LLM 组装出用于生成答案的“阅读材料”。此阶段应基于搜索阶段得到的线索，动态地聚合、拼接或扩展出更大、更完整、更连贯的上下文片段。

RAGFlow 提出 TreeRAG 技术，正是这一思想的实践。它通过借助 LLM 在离线阶段自动化地分析文档，构建出层次化的树状目录摘要结构，从而巧妙地桥接了“小粒度搜索”与“大粒度阅读”之间的鸿沟。其核心工作流体现了“先精准定位，再展开阅读”的智慧：

离线处理（知识结构化）：文档切分后，先送入 LLM 进行分析，生成对应的多级树状目录摘要（例如，章->节->子节->关键段落梗概）。同时，还可以为每个节点或原始切片进一步衍生出摘要、关键词、实体、可能的问题、元数据、关联的图片上下文描述等丰富的语义增强信息。研究表明【文献3】，在离线处理阶段，对原始切片的精细度要求可以适当放宽，过于复杂的切分策略有时反而会破坏语义单元，简单且重叠的切片策略往往在实践中更有效和健壮。

在线检索（动态 Context 组装）：当用户查询到来时，首先使用最细粒度的“小片段”（原始切片或其摘要）进行相似度搜索，实现快速、精准的初步召回。然后，利用离线构建的“树状目录”这一导航图，根据召回的切片节点，迅速定位到其所在的父节点、兄弟节点及相邻节点，将这些语义相关的片段自动组合成一个逻辑完整的“大片段”，最后提供给 LLM。这种方法有效解决了因固定粒度切片造成的上下文碎片化问题，确保了提供给模型的材料既包含了精准匹配的核心信息，也具备了理解该信息所需的周边语境。

类似的工作还有 PageIndex【文献2】，它更侧重于解析和利用文档本身（如 PDF）固有的物理或逻辑目录结构。

这种方法在文档结构清晰、格式规范时非常高效，但其局限性在于高度依赖源文档的质量，当文档缺乏清晰目录或目录不准确时，其自动定位能力就会大打折扣。

TreeRAG 及其同类技术有效缓解了因切片不当导致的“Lost in the Middle”痛点。

然而，对于某些更为复杂的查询，例如问题答案分散在数十个互不相邻的切片中、或需要综合多个独立文档的信息进行推理的情况，仅靠树状结构可能仍无法全面覆盖所有关联。

此时，业界很自然地将目光投向另一条技术路径：GraphRAG。GraphRAG 通过从文档中抽取实体及实体间关系，构建知识图谱，利用图查询与图推理来发现间接关联的信息片段。

然而，GraphRAG 自诞生以来，同样让许多尝试者处于“爱恨交加”的境地，其主要挑战源于以下几个方面：

1.Token消耗巨大：
实体抽取、去重、社区摘要等步骤会导致数倍乃至数十倍于原文的 Token 消耗。
2.实体抽取质量与预期存在落差：
传统知识图谱经过领域专家精心设计与校验，图谱质量高，可直接用于可视化分析与交互。而 GraphRAG 自动抽取的实体和关系常包含大量噪声、冗余或错误，若以可视化知识图谱的标准去审视和使用它，往往会感到失望，陷入“图表美观但实用性不强”的尴尬境地。
3.知识碎片化：
即便通过图算法发现了关联社区并生成了摘要，其产出仍然是围绕特定主题的“知识片段”集合。基于这些离散的片段去生成最终答案，对 LLM 的整合与连贯叙述能力提出了极高要求，容易产生回答缺乏逻辑主线或遗漏重要侧面信息的问题。实体和关系得到的是离散的知识点，即便围绕社区生成的摘要也是碎片化的信息，基于此生成的回答难免缺乏连贯性。

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

因此，无论是 TreeRAG、GraphRAG，还是两者融合的混合架构（可以统称为“长上下文 RAG”），其共同的核心范式都是在传统 RAG 流水线的基础上，引入了额外的语义增强与结构构建层：

在数据写入（Ingestion）阶段，不仅进行切片，更利用LLM进行深度的语义理解、摘要生成和结构提取；

在检索（Retrieval）阶段，则不仅仅依赖搜索，还结合了基于预定义结构（树、图）的导航、关联查询和动态组装能力。

因此，RAG 技术远非陷入停滞，其改进方向正日益清晰：借助 LLM 本身的能力，在数据生命周期的早期阶段就尽力弥合原始数据与最终问答之间的语义鸿沟。

通过在写入阶段使用不同指令的提示词，多轮次、多角度地请求 LLM 分析文本，从中提取出丰富、多层次的语义信息（元数据），并在检索阶段，以这些增强语义为“导航图”，在单纯的向量相似度搜索之外，智能地完成上下文的筛选、聚合与填充。

这才是解决复杂、开放域问答挑战的更可靠之道。

RAGFlow 等产品已在此方向展开深入实践，其未来演进将围绕这些核心点持续深化。简而言之，现代 RAG 系统的设计哲学是：充分协同“强大检索与推理能力”与“有限但宝贵的 LLM 上下文窗口”，通过智能的预处理与动态组装，在效果、性能与成本之间寻求最优平衡。

从知识库到数据底座

我们常强调 RAG 本身是一种架构范式而非具体应用，但不可否认，知识库是 RAG 最直观和成功的应用形态。

随着 AI Agent 开发的蓬勃兴起，一个显著的趋势是：Agent 的复杂任务执行越来越离不开对海量、多样化企业数据的实时访问与理解。因此，企业级的 RAG 产品开始超越“问答知识库”的单一定位，向更底层、更通用的 Agent 数据基座演进。它需要承担起为各类 Agent 提供统一、高效、安全的非结构化数据访问服务的角色。

为此，一个健壮、可扩展和可配置的数据注入管道（Ingestion pipeline）已成为现代 RAG 引擎不可或缺的核心功能模块。它承担着“接管”企业内部纷繁复杂的非结构化数据（文档、图片、音视频、代码、邮件等），并将其“消化”成 RAG 引擎可索引、可检索的标准格式的全过程。

如果说 ETL/ELT 是现代数据栈中处理结构化数据的工业化标准管线（以 dbt、 Fivetran、 Airbyte 等工具为代表），为数据仓库和数据湖提供了统一、灵活且可靠的数据集成方案，那么，面向非结构化数据的 Ingestion pipeline（或可称为PTI: Parse-Transform-Index）就是其在 AI 时代对等的关键基础设施。

两者在架构定位与处理哲学上高度相似，但在具体技术手段上因数据特质不同而有所区分，其核心环节对比如下图所示：

具体来看各个环节的异同：

Extract 与 Parsing：传统 ETL/ELT 的“Extract”阶段主要从关系型数据库、API、日志文件等结构化或半结构化源中抽取数据。而 Ingestion pipeline 在此基础上，强化了“Parsing”环节，以专门攻克非结构化数据的信息提取难题。

该环节需要综合利用各种解析器，例如：用于 PDF /Word 的格式解析器、RAGFlow 自带的 DeepDoc 专用文档智能解析模型、基于视觉语言模型（VLM）微调的 OCR 模型等。其目标是将多模态、多格式的原始文档，转化为纯净、结构化的文本表示，并尽可能保留原始的逻辑结构（如标题、列表、表格）和元信息（如作者、日期）。

Transform：这是两者差异最大的环节。传统 ETL/ELT 的“Transform”侧重于基于 SQL 或代码进行数据清洗、格式标准化、业务逻辑计算（如聚合、关联）等。

而 Ingestion pipeline 的“Transform”阶段，则是以 LLM 为核心的一系列语义理解与增强算子。它们负责把 Parser 输出的原始文本流，转变成检索阶段所需的各种高级“素材”。除了基础的文本分块（Chunking）外，前述的树状结构生成、知识图谱（实体-关系）抽取、摘要生成、问题生成、关键词提取等所有旨在提升检索效果与精度的处理，都在这个步骤完成。这个阶段是注入“智能”的关键，决定了数据被“理解”的深度。

Load 与 Indexing：传统 ETL/ELT 将处理后的干净数据加载（Load）到目标数据仓库或数据湖表中。而 RAG 引擎则通过“Indexing”模块，将 Transform 阶段产出的丰富内容（原始文本块、摘要、向量、元数据、图关系等）构建成适合多种检索方式的高效索引。

这是因为 RAG 引擎本质上是一个高并发、低延迟的检索服务层（Serving layer），它需要支持混合检索（向量检索+关键词检索+元数据过滤）、并可能集成上述的树检索、图查询等高级能力。

无论是处理结构化数据的 ETL，还是处理非结构化数据的 PTI，中间的“转换（Transform）”步骤都是价值创造的核心环节。

对于 ETL，工程师需要根据具体的业务分析需求，精心设计转换逻辑（SQL）；对于PTI，由于 Ingestion pipeline 必须与最终的检索（Retrieval）需求端到端协同设计，因此需要根据上层应用（如问答、摘要、分析）对精度、速度、成本的不同要求，来决定 Transform 阶段应该采用何种粒度的切片、生成何种类型的增强语义、构建何种复杂度的索引结构。

因此，构建优秀 RAG 系统的关键点，并非仅仅在于选择了某个最先进的 Parser 模型或某款高性能的向量数据库，而在于对整个“数据注入 -> 语义增强 -> 索引构建 -> 检索服务”链路的协同设计与持续调优。

当 RAG 系统具备了这样强大、灵活且智能的 Ingestion pipeline，它就真正从一个“问答系统”升级为企业级非结构化数据的统一处理与访问平台。它能够以标准化、自动化的方式，消化企业内部散落各处的知识资产，并将其转化为可供 AI Agent 随时调用的“燃料”。

这也是为何今天，当企业决心构建统一的AI能力中台时，该中台的核心与基石必然，也只能是这样一个以 RAG 引擎为核心的、具备强大数据处理能力的数据底座。它为企业所有的AI应用提供了唯一可信、实时更新的知识来源。

从 RAG 到 Context

2025年LLM应用侧最火热、最引人注目的无疑是各式各样的 AI Agent。

从 Agent 框架的视角来看，它可以视 RAG 为一个提供外部知识访问能力的工具（Tool），就如同调用计算器、查询天气 API 或操作数据库的工具一样。这种工具化的视角，加之“Agentic RAG”（利用 Agent 的规划、反思等能力来增强 RAG 流程本身）概念的兴起，使得“RAG 将被更通用的 Agent 取代”或“RAG 只是 Agent 的一种普通工具”的论调在 2025 年尤其盛行。

然而，这种观点可能过于简化，甚至误解了 RAG 在 Agent 生态中的根本价值与地位。

它忽视了 RAG 架构的本质——其核心能力与价值基石在于检索（Retrieval），而并非仅仅在于“增强生成”。正是“高效、准确、可扩展地从海量私有数据中检索相关信息”这一核心能力，使得 RAG 有潜力成为，且正在成为 Agent 最不可或缺、最基础的数据底座。

因为无论多么智能的 Agent，其决策与行动的质量，在根本上都取决于它所获得的上下文（Context）的质量与相关性。如何为不同的任务、在不同的时刻，动态地、智能地组装出最有效的上下文，成为了 2025 年下半年业界最热门的技术探索与实践指导原则，这就是上下文工程（Context Engineering）。

让我们深入剖析 Context Engineering 所涉及的主要数据类型和技术，来理解为何“检索”处于其绝对的核心：

Context Engineering 之所以成为一个独立的工程领域，正是因为实践反复证明：简单粗暴地将所有可能相关的数据都塞进 LLM 的上下文窗口，不仅会导致成本无法承受，更会因信息过载而严重损害 LLM 的理解、推理与工具调用能力。因此，智能地筛选、排序、拼接上下文成为必须。

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

1.领域知识数据：
对于作为核心工具的知识库（即 RAG 系统）来说，检索结果的质量直接决定答案成败。返回过多无关片段会引入噪声，干扰答案生成；遗漏关键片段则必然导致事实性错误或答案不完整。因此，RAG 本身就可以被视作最早期的、针对领域知识的上下文工程 1.0 实践。

2.工具数据：
对于其他功能工具，特别是通过模型上下文协议（Model Context Protocol, MCP）等标准封装的大量工具而言，其描述信息（名称、功能、参数说明）本身也是上下文的一部分。当可用工具只有少数几个时，可以将其描述全部硬编码在提示词中。但在企业级场景下，通过 MCP 包装的内部服务、API、函数可能达到数百甚至上千个，每次对话都由人工或静态规则指定调用哪几个工具是不现实的。

这个“工具选择”难题直到 2025 年底才被部分用户深刻感知，甚至引发了《诞生才一周年，MCP凉了》这样的标题党文章【文献 9】。

实际上，文章作者抱怨错了对象——问题症结在于将所有工具描述不加区分地堆进上下文，导致 LLM “选择困难症”爆发，而非 MCP 协议本身。MCP 是一个极重要的协议，其目标在于统一工具调用的接口标准，但它并不负责、也无法解决“在特定情境下该选择哪个工具”的决策问题。

那么，这个决策责任应该由谁承担？这正是当前多数 Agent 框架缺失的关键一环。

答案依然是检索 (Retrieval)。我们需要通过对所有工具描述信息进行语义搜索，并结合对过往工具使用历史中形成的“技巧”（Skills）、“操作手册”（Playbook）或“最佳实践指南”（Guideline）进行检索，才能动态地、精准地为当前 Agent 的当前任务，筛选出最相关、最可能被正确使用的工具子集和工具调用参数放入上下文。

这远非当前的 Anthropic Skills 等产品特性所能涵盖。如何将 Skills / Playbook / Guideline 的生成、检索与使用形成闭环并产品化，是 Context Engineering 必须解决的核心问题，这本质上是一个数据基础设施（Infra）问题，而非单纯的模型能力问题。

3.会话和状态数据：
除了静态知识和工具，上下文还需要包含动态的、与当前交互相关的数据，例如：当前会话的历史消息、用户的个性化信息与偏好、以及部分 Agent 的内部状态信息（例如 Human-in-the-loop 中的人工输入）。
这类数据的管理与访问常被形象地称为“记忆（Memory）”，它在 2025 年上半年至年中成为独立的热门概念。但从技术实现内核看，记忆系统的核心能力——对历史交互信息的存储、索引与检索——与 RAG 并无本质区别，可以看作是针对特定数据源（会话日志）和特定使用模式（更强调时序和会话关联）的检索系统特化版。

通过对上下文组成的解构，我们可以清晰地看到，Context Engineering 的核心任务，仍然是基于 Agent 所需三大类数据源的检索：

1.针对企业私有化、非结构化的领域文档数据的检索——即 RAG。
2.针对 Agent 交互过程中产生的会话历史与状态数据，特别是 LLM 生成内容的检索——即记忆（Memory）。
3.针对企业现有服务与 API 封装而成的工具描述及使用指南数据的检索——可称之为工具检索（Tool Retrieval），这类数据同样可以放入专用区域如 Memory。

由此可见，RAG 技术在 AI Agent 时代将无可争议地升级，它不再仅仅是“检索增强生成”中的一个环节，而是以“检索”为核心能力，扩展其数据范畴，演进为支撑所有上下文组装需求的上下文引擎（Context Engine），真正成为服务于 LLM 应用的、统一的上下文层（Context Layer）与数据底座。

Agent所需的Retrieval vs 传统搜索

理解这种演进，需要对比传统搜索时代与 Agent 时代检索范式的根本差异：

在传统搜索时代（如使用谷歌或企业内搜索），检索的发起者、执行者和结果消费者都是人。用户提出问题，搜索引擎返回一系列相关文档链接，用户需要自己打开多个链接，阅读、比较、综合信息，最终形成答案或决策。这是一个“人机协同、人工主导”的循环。

而在 Agent 时代，检索的发起者和初级消费者是 Agent（由 LLM 驱动）。其典型工作流是：LLM 首先对用户复杂问题进行理解与拆解（假设/规划），然后代表用户自动发起一次或多次检索请求，接着对检索返回的原始结果进行理解、核验与提炼（反思），最后将加工后的信息拼接成最终生成答案的上下文。检索的内容也从单一的网页或文档，扩展到工具使用、记忆片段等。

整个“问题理解 -> 检索 -> 结果处理 -> 上下文组装”的闭环是由 Agent 自动完成的。

因此，Agent 所需的检索系统面临着前所未有的新要求：

请求频率极高（可能会超过传统搜索时代人类发出的检索请求次数的一到两个数量级）、查询类型多样化（对文档的语义查询、对工具的关键词匹配、对工具使用指导的参数匹配、对记忆的关联查询）、延迟要求苛刻（直接影响 Agent 的响应速度）、需要与 Agent 的推理流程紧密耦合。

这远非一个独立的搜索引擎或向量数据库所能满足。它需要在存储与索引层之上，构建一个智能的中间服务层，该层理解 Agent 的意图，能根据上下文组装策略，动态地协调对背后不同数据源（文档库、记忆库、工具库）的检索请求，并对结果进行必要的融合、去重、排序与格式化，最终打包成 LLM-ready 的上下文。

这种使用模式，意味着 Agent 开发中最为繁琐和专业的“上下文工程”部分，有望从高度手工、嵌入在提示词硬编码中的状态，走向声明式配置甚至自动化，从而大幅降低 Agent 开发与维护的复杂度，提升其效果的一致性与可复用性。

工具也是需要搜索的

工具的多样性直接决定了 Agent 能够解决问题的广度和深度。

在简单的演示或原型开发中，常见的做法是将所有可用工具的描述（通常是一段自然语言文本）一次性全部嵌入 Agent 的提示词中。

然而，当工具数量从几个增长到几十个、几百个时，这种做法的弊端将暴露无遗：首先，它占用了大量宝贵的上下文 Token，这些 Token 本可用于容纳更重要的任务描述和中间结果；其次，过多的选项会给 LLM 的工具选择逻辑带来巨大负担，增加其“幻觉”调用或选择错误工具的概率。

特别是在企业级场景中，工具的数量可能达到惊人的规模。因为从理念上讲，几乎所有现有的企业内部服务、数据库、API和工作流，都可以被包装成 Agent 可以理解和调用的标准化工具接口。这正是 MCP 等协议致力于解决的问题——成为 Agent 时代的“TCP/IP”，解决连通性问题。

但必须清醒认识到，MCP 解决的是“如何调用”的协议问题，而不是“应该调用哪个”的决策问题。优秀的模型（如一些正在研发的 SOTA 模型）或许能在上下文中勉强处理数百个工具描述，但这绝非高性价比的解决方案。将上下文窗口视为稀缺资源，尽可能少地填入无效或低概率使用的信息，对于控制成本和提升整体系统效果都是至关重要的设计原则。

因此，工具检索（Tool Retrieval）在 2025 年底开始受到学术界和业界的前沿关注。

其核心思想是：为所有工具建立一个专门的描述信息索引库（可以是向量索引，也可以是关键词索引，或两者混合）。当 Agent 需要调用工具时，先根据当前对话的上下文和任务目标，生成一个针对工具功能的“查询”，去这个索引库中进行快速检索，只召回最相关的少数几个（例如Top-3）工具描述，并将其动态插入到当前上下文中，供 LLM 进行最终的选择和调用。

研究表明【文献 10】，即使是简单的 BM25 关键词检索算法，在这个任务上也能作为一个很强的基线（Baseline）方法。当然，使用经过微调的专用嵌入模型，能够获得更精准的匹配结果。

除了工具本身的描述信息，在 Agent 的开发、测试和实际使用过程中，还会自然沉淀出一系列关于“如何正确使用工具”的元知识。例如：“在处理客户退款请求时，应依次调用 A 工具验证订单、B 工具检查库存、C 工具执行退款，且参数 X 必须来自会话历史 Y。”这类“操作手册”或“攻略”性文本，是比工具描述更丰富、更具指导性的上下文素材。

它们同样应该被纳入可检索的体系：当 Agent 面临一个复杂任务时，可以先检索相关的任务指南，将指南作为上下文的一部分，这样 LLM 就能像“开卷考试”一样，遵循最佳实践来规划行动。

这类关于工具使用的指南数据，其数量和数据密度可能远大于工具描述本身，对其的高效利用毫无疑问必须依赖于检索技术。早期的探索如 Dspy 框架中的 GEPA优化器【文献 11】，它利用遗传算法自动演化出更好的提示词（可能包含工具使用逻辑），但其焦点在于优化提示词文本本身。

而更系统的工作如 ACE（Agentic Context Engineering）框架【文献 12】，开始体系化地研究如何生成、管理和利用这类指导性上下文。虽然这不属于本文的重点，但我们必须认识到，这代表了 Context Engineering 向深度发展的一个重要方向，而这类工作产生的结果，必然毫无疑问需要被纳入到 Retrieval 需要涵盖的体系之中，连同工具描述一起提供上下文。

Memory 值得成为单独的 Infra 么？

“记忆”在 2025 年的技术讨论中获得了远高于 RAG 的关注度，常被各类文章和产品宣传列为 Agent 基础设施层的核心组件之一，甚至出现了“记忆将取代 RAG ”等模糊边界的观点。

那么，记忆究竟是什么？层出不穷的开源记忆项目与 RAG 系统在底层上有何区别与联系？

简而言之，记忆系统的出现，最初是为了满足对 Agent 历史交互信息进行有效管理和再利用的需求。

其基本使用模式与 RAG 如出一辙：当新的对话发生时，系统根据当前查询，从存储的历史会话记录中检索出相关的过往对话片段（例如，同一用户之前的提问、LLM之前的回答、用户的反馈等），然后将这些片段作为上下文的一部分，与新问题一起提交给LLM，以便模型能保持对话的连贯性、记住用户偏好或避免重复。因此，从功能接口和核心技术（检索）上看，记忆与 RAG 共享同一内核。

它们的核心区别在于数据来源与管理目标：

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

随着研究的深入，记忆系统内部的数据组织也出现了更精细的划分，借鉴了认知科学中的概念，通常包括 Working Memory ，Episodic Memory，Semantic Memory，Meta Memory 等。这些不同的“记忆区域”，在实现上可以类比为数据库中的不同表或集合。

记忆系统的复杂性不仅在于存储和检索，更在于记忆的管理逻辑：新产生的原始对话何时、以何种方式被写入记忆？何时触发 LLM 对一段对话进行摘要，并将摘要存入语义记忆？如何建立不同记忆片段之间的关联？这些“记忆的流转、加工与生命周期管理”功能，其地位完全等价于 RAG 系统中的 Ingestion pipeline，只不过它处理的是动态产生的流式数据。

如果我们把视野放大，在记忆系统中专门划分出一个区域（或单独建立一个紧密关联的知识库）来存储和检索上文提到的工具使用指南，那么，一个支撑 AI Agent 的完整数据基座的蓝图就清晰浮现了：

这个蓝图清晰地表明：记忆（处理动态交互数据）与 RAG（处理静态领域知识）在技术上同源（均基于检索），在功能上互补，共同构成了AI Agents 赖以生存的完整数据基座。

所有 Agent对数据的访问需求——无论是已有的非结构化文档（通过RAG）、实时产生的交互日志（通过记忆），还是结构化的服务接口（通过 MCP 封装，其元数据、使用指导和攻略的检索可纳入专用知识库）——都可以被统一规划、治理和接入到一个一体化的平台中。

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

从上下文工程到上下文平台

“Context Platform” 这一前瞻性提法，可能最早由投资机构 Theory Ventures 在其系列文章中系统阐述【文献 13, 14】。事实上，这家富有远见的机构早在 2024 年就旗帜鲜明地指出了检索对于 LLM 应用的根本重要性【文献15】。

时至今日，如何将技术视角的 Retrieval Engine 升级为 Context Engine，正在成为决定 AI Agent 能否在企业中规模化、低成本落地的关键胜负手。

从前文的全面分析可见，许多所谓“Agent 智能”要解决的问题，其本质仍然是在正确的时间，为 LLM 找到并呈现正确的信息。如果 Agent 能拥有一个强大的“外脑”（Context Engine），帮助它高效地查找、筛选、验证和梳理所有相关数据，那么用户最终获得的体验和结果将远超一个仅依靠庞大参数和复杂提示词的“裸”模型。

从 Context Engineering 到 Context Engine / Platform，这标志着上下文的创建、管理与交付，正从一项高度依赖专家经验的手工艺术，向高度自动化、产品化和可运维的平台科学演进。

当前企业在开发定制 Agent 时，往往需要投入大量工程师和数据科学家手工编写复杂的提示词模板，精心设计上下文拼接逻辑，并硬编码到工作流编排中。这种方式难以维护、无法规模化，且上下文的所有权和更新流程混乱。

未来的上下文平台将致力于改变这一现状：

上下文的创建将通过与数据源的深度集成自动完成，并持续同步更新。
上下文的交付将不再是硬编码的，而是根据每次对话的实时意图，通过平台统一的检索与编排层，动态地从各类数据源中检索、组装而成。
上下文的维护将从供应商主导的手动服务，转变为客户可自主管理、可视化配置的自动化流程，上下文的所有权和控制权将明确归属于客户。

这带来的范式转变是巨大的：企业 AI 落地的核心价值，正从追求“最智能的模型”和“最巧妙的提示词”，回归到构建“最丰富、最准确、最易用的上下文”。

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

多模态RAG进展

在2024年的年终回顾中，我们曾预测以“延迟交互”为基座的多模态 RAG 将成为 2025 年的技术关键词。然而，这一预测并未完全成为现实。

这是否意味着多模态 RAG 缺乏实际意义？

答案显然是否定的。以专门针对医疗文献设计的基准数据集 M3Retrieve【文献 4】的测试结果为例，多模态 RAG 的价值与定位已得到清晰印证：

在图文结合任务中表现卓越：在视觉上下文检索、基于图像的问答等场景下，多模态 RAG 能够综合利用文本与视觉信息，表现显著优于纯文本方案。
在文本主导任务中优势不显：对于摘要生成、纯文本病例检索等任务，成熟的单模态 RAG 凭借其高效与精准，依然占据优势。

由此可见，产品级的多模态 RAG 并非简单地将图像与文本模型拼接，其核心需求在于实现真正高效的跨模态检索与理解。从技术演进脉络看，多模态 RAG 无疑是 RAG 体系深入发展、覆盖更广泛数据类型的必然方向。

当前，处理图文等多模态文档主要存在两种技术路径：

1.模态转换路径：
借助 OCR 或 VLM（视觉语言模型），将图像、表格等内容转化为纯文本描述，从而将多模态问题降维为单模态的文本检索问题。这种方法兼容现有文本 RAG 架构，但可能丢失原始视觉布局、颜色、细微特征等关键信息。
2.原生多模态路径：
将图像直接进行视觉分词（Tokenize），与文本 Token 一同输入统一的多模态编码器，生成融合的多向量（Multi-Vector）表示。在检索排序阶段，则借助延迟交互（Late Interaction）模型进行精细化的相似度计算。

其流程可概括为下图：

Google DeepMind 在今年 9 月发表的理论指导文章【文献 5】明确指出，基于单一的全局向量进行检索存在固有的语义损失，而使用多向量（即高维张量）表示能够更完整地保留文档的细粒度语义信息。

既然理论优势如此明确，为何在 2025 年仍未涌现出成熟的、产品化的多模态 RAG 解决方案？

其根本原因在于从技术原型到稳定产品的工程化挑战尚未被完全攻克。

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

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

尽管上述方案在技术上均可行，但它们共同面临一个棘手的工程化瓶颈：因 Token 数量爆炸导致的张量数据存储与计算开销激增。

假设使用类似 ColPali 的模型，默认每页图像输出1024个Token（每个Token对应一个特征向量），每个向量维度为 128，采用 float32 精度存储，那么仅一页图像对应的张量数据就需占用约 512KB 空间。对于一个百万页级别的文档库，其索引体积将膨胀至TB级别，这对存储成本、内存加载和检索延迟都是巨大挑战。

要推动多模态 RAG 走向工程实用化，目前主要有两条技术路径可供实践：

1.张量量化压缩：
对张量中的每个向量进行二值化或低比特量化（如用 1 个比特表示），可将存储压缩至原来的 1/32 甚至更低。代价是会引入一定的精度损失。这条路径的可行性，取决于能否训练出对量化操作鲁棒性强的专用嵌入模型。

2.Token 剪枝：
显著减少每页图像生成的 Token 数量，例如从 1024 个降至 128 个或更少。具体实现方法包括：

随机投影：将大量 Token 对应的向量投影到单个高维（如 1 万维）向量中，如 MUVERA 算法【文献 6】。这种方法计算高效，但会损失较多的细粒度信息。

Token 聚类：对生成的 Token 对应的向量进行无监督聚类，用聚类中心代表原始集合。该方法不依赖模型改动，但同样会牺牲精度。

模型端 Token 剪枝：改造 Embedding 模型（特别是其底层的 VLM），使其能够根据内部注意力机制主动输出更少但信息量更大的“精炼” Token。这是最根本的方法。

因此，多模态 RAG 的成熟不仅要求底层检索引擎具备对张量索引（Tensor Index）和张量重排器（Tensor Reranker）的原生高效支持，更有赖于整个 AI 社区涌现出更多对量化友好、支持自适应 Token剪枝的下一代多模态 Embedding 模型。

这两者的发展相辅相成：缺乏成熟易用的 Retrieval Engine，会阻碍新模型在真实场景中的验证与迭代；而没有高效的模型，Retrieval Engine 也无用武之地。所幸的是，这个话题已经引起了广泛重视，专门以延迟交互为主题的 Workshop 也将在 26年上半年举行【文献 7】。

展望2026年，随着 AI 基础设施层对张量计算与存储的支持日益完善，我们有望看到更多为工程化量身定制的优秀多模态模型问世，从而真正解锁跨模态RAG的实用潜力。

而它的工程化落地，将自然而然地催生多模态上下文的普遍需求——例如，能够同时理解和记忆文本、图像乃至视频的“多模态记忆”系统已不再是理论设想，而是进入了原型研发阶段【文献 16】。

展望 2026

迈入 2026 年，企业对 LLM 应用的关注点，必将从概念验证与早期尝鲜，转向规模化落地与投资回报的务实阶段。在这一进程中，作为整个 AI 应用数据基座层的 RAG 技术，将迎来更为坚实、体系化的建设浪潮。

如果说 AI Agent 在企业复杂场景中的终极价值与形态尚处于广泛探索期，那么 RAG 对于所有 Agent 乃至 LLM 应用的基础支撑作用，已成为越来越多技术决策者的共识。

一个明显的趋势是：许多企业已率先启动以“AI 中台”或“智能数据底座”为核心的能力建设，而其枢纽正是以 RAG引擎为基座的非结构化数据处理与供给平台。相比之下，上层Agent的具体构建与引入，反而可以基于这一稳固底座，以更灵活、更循序渐进的节奏展开。

若要用一句话概括从 2025 到 2026 年 RAG 技术的演进轨迹与未来展望，那便是：RAG 将完成其自身的深刻蜕变，从“检索增强生成”的特定模式，升维为以“智能检索”为核心能力的“上下文引擎（Context Engine）”。这一演进趋势已不可逆转，并必将从技术后台走向战略前台，成为企业构建下一代智能化基础设施时不可或缺的核心组件。

而 RAGFlow，正是为这一宏大而确定的未来图景而生。

我们所构建的，不仅仅是一个开源的高效 RAG 系统，更是通往“上下文引擎”时代的关键基石与推进器。从深耕多模态解析与语义增强的 DeepDoc，到探索 TreeRAG 等前沿架构以弥合语义鸿沟，再到打造服务于 Agent的上下文引擎——RAGFlow 的每一次迭代，都旨在将文中探讨的技术方向，转化为稳定、易用、高性能的产品能力，推动企业智能化从构想稳步迈向现实。

我们坚信，以检索为核心的 Context Engine，是释放 LLM 与 Agent 全部潜能的关键。