RAG面临挑战
RAG“易用难精”
源于 RAG 系统自身“易用难精”的调优挑战，RAG实际应用效果面临诸多质疑。不过，尽管争议增多且并非处于流量中心，但真正致力于构建核心竞争力、严肃对待 AI 能力建设的企业，尤其是中大型组织，对 RAG 的投入反而更为深入和系统化。RAG 在企业 AI 架构中非但未被边缘化，反而更加稳固地扮演着核心角色，其作为关键基础设施的地位并未动摇。
企业对 RAG “既离不了，又不满意”的普遍心态已形成共识。RAG 降低了接入私有知识的门槛，但其效果的稳定性和准确性（尤其是面对复杂查询时）往往需要大量精细调优，这使得其总拥有成本评估变得复杂。
长上下文和 RAG 之争
谷歌去年发布了 Gemini 1.5 Pro，其具备 100 万 tokens 的上下文窗口，并且在”大海捞针”测试中实现了 99.7%的信息召回率。
这就引出了一个疑问——长上下文（Long Context）能否取代 RAG？
部分对延迟和成本相对不敏感、且查询模式相对固定的场景（如某些类型的合同条款审查、固定格式报告分析），开始尝试直接利用长上下文窗口，将整篇或大量相关文档一次性输入模型，以期绕过 RAG 检索可能带来的信息丢失或噪声问题，直接缓解对话效果不一致的痛点。
RAG将死？
那么长上下文的发展，会不会将RAG送进坟墓呢？
个人认为，RAG 不仅不会死，反而会进化。现在的 RAG 所谓的“过时”，是指那种“简单的切片+向量检索”的粗糙 RAG 过时了。
RAG的本质是包含两个步骤，一是召回（检索），二是推理。大部分人以为RAG只是服务于私有知识库，然而RAG的应用是可以很广泛的。例如我们设计一个带感情色彩的聊天机器人，这个聊天机器人回答的语气的示例（也就是few shot learning）是可以通过RAG来召回的，在这个例子中召回的是示例。再比如，我们让LLM使用外部工具，外部工具可能特别的多，那么可以让RAG来帮忙对工具进行初步的召回和检索，原因是过多的信息（例如塞入全部工具的描述）会增加LLM的失误率，使得容错率降低。
应该将RAG视作一种LLM可以使用的外部工具，在能使用外部工具的前提下，肯定是要优先使用这些工具，好比让人查询文档中的相关内容，人也会根据结构化的标题以及ctrl+f功能进行快速的检索和定位（也就是借助外部工具），而不是从头到尾通读整篇文档。
RAG与长上下文互补
长上下文和 RAG 根本不是替代关系，而是互补关系。
2023年，RAG刚刚兴起时，彼时的LLM窗口小的可怜，大多数开源模型的上下文窗口才4K。RAG开发者需要精打细算选择召回的结果，否则上下文信息将直接被截断。此时，开发者们甚至不得不微调模型，增加上下文窗口长度。
后来，YARN这样的方法被提出，模型上下文窗口进一步扩展，普遍提升到32K、64K。此时RAG也收益与LLM能力增强，迅速发展。
所以。实际上RAG受益于上下文窗口的增长，并且RAG本身的发展也在一定程度上推动了LLM的进步。
到如今，模型普遍支持128K甚至1M的上下文窗口长度，开发者将不必再为如何精确调整分块算法而烦恼。我确实认为这对于 LLM 开发者而言将是巨大的福音。长上下文 LLM 使得原生分块尺寸可以变得更大。假设每个令牌的成本和延迟也会下降，开发者将不再需要费心通过调整分块分隔符、分块大小和细致的元数据注入来将数据拆分成细条。长上下文 LLM 使得分块可以达到整个文档的级别，或者至少是页面组的级别。
另外，开发者将无需在针对单文档调整检索和思维链上花费过多时间。
小分块 top-k RAG 的一个缺陷在于，虽然某些问题可以通过文档的特定片段得到解答，但其他问题需要在不同章节之间或两份文档之间进行深度分析（例如对比查询）。针对这类用例，开发者不再需要依赖思维链智能体对弱检索器执行两次检索，而是可以直接通过单次提示 LLM 即可获得答案。
个性化记忆将变得更优质且更易于构建：构建对话助手的核心挑战在于如何将足够的对话上下文载入提示窗口。对于非常基础的网络搜索代理来说，即使是简单的维基百科页面内容也可能轻易突破 4K 词元的窗口限制。百万至千万级别的上下文窗口将使开发者能更轻松地实现对话记忆功能，减少对向量检索或自动知识图谱构建等压缩技巧的依赖。
所以说，虽然长上下文 LLM 将简化 RAG 流程中的某些环节（例如文本分块），但仍需发展出更先进的 RAG 架构来应对长上下文 LLM 带来的新用例。
长上下文仍然有不足
对于大型文档库而言，1000 万 token 仍然不够——千量级文档检索依然是挑战。1000 万 token 的数据量上限约为 40MB。虽然这对许多”小型”文档库已足够，但企业级知识库往往达到 GB 甚至 TB 级别。要在这些知识库上构建 LLM 驱动的系统，开发者仍需通过某种数据检索机制，为语言模型提供上下文增强。
嵌入模型在上下文长度方面仍处于落后状态。到目前为止，嵌入模型最大上下文窗口来自 together.ai，长度为 32k。这意味着，即使用于长上下文 LLM 合成的文本块可以很大，但用于检索的任何文本块仍然需要小得多。
成本和延迟问题。虽说随着时间推移所有成本与延迟问题都会得到缓解。然而，填满一个 100 万 token 的上下文窗口仍需约 60 秒，按当前价格计算成本可能介于 0.50 美元到 20 美元之间。并且超长的上下文会产生大量的KV Cache，因此会占用大量 GPU 内存。这样的成本是无法被大规模应用所接受的。
RAG新架构
就长上下文 LLM 需要在大型知识库（例如数 GB 级别）上使用检索增强而言，我们将需要”从小到大的检索”方案：对小型文本块进行索引与检索，但让每个检索到的小块关联至更大的文本块，这些大块最终会在信息合成阶段输入给 LLM。
我们之所以希望将文本切分成较小的块进行嵌入和索引，一个原因是当前的嵌入模型在上下文长度方面未能跟上 LLMs 的发展。另一个原因在于，相较于为整篇文档生成单一文档级嵌入，采用多种粒度的嵌入表示实际上能够带来检索优势。如果文档只有一个嵌入向量，则该向量需要承担编码文档全部信息的负担。相反，我们发现嵌入多个较小文本块，并让每个小文本块关联到更大的文本块，能够更有效地检索相关信息。
长上下文 LLMs 的到来将不可避免地引发关于每个用例适合多少上下文的问题。向 LLMs 注入长上下文会带来实际成本和延迟的权衡
RAG的本质是如何将最相关、最有效的信息，以最高性价比的方式纳入模型的上下文处理体系。
从这个角度看，RAG的功能逐渐从检索增强生成变成了动态上下文工程。
通过对上下文组成的解构，我们可以清晰地看到，Context Engineering 的核心任务，仍然是基于 Agent 所需三大类数据源的检索：
- 针对企业私有化、非结构化的领域文档数据的检索——即 RAG。
- 针对 Agent 交互过程中产生的会话历史与状态数据，特别是 LLM 生成内容的检索——即记忆（Memory）。
- 针对企业现有服务与 API 封装而成的工具描述及使用指南数据的检索——可称之为工具检索（Tool Retrieval），这类数据同样可以放入专用区域如 Memory。
由此可见，RAG 技术在 AI Agent 时代将无可争议地升级，它不再仅仅是“检索增强生成”中的一个环节，而是以“检索”为核心能力，扩展其数据范畴，演进为支撑所有上下文组装需求的上下文引擎（Context Engine），真正成为服务于 LLM 应用的、统一的上下文层（Context Layer）与数据底座。
