Yeats' Wiki

外观

长上下文会取代 RAG 吗：辩证分析 ​

当 Gemini 1.5 Pro 发布并支持 1M Token（甚至 10M）时，整个 AI 社区都在讨论一个问题： RAG (Retrieval-Augmented Generation) 是不是要被淘汰了？ 只要把整本书、整份财报、甚至整个代码库塞进 Context Window，让模型自己找答案，何必还要维护复杂的向量数据库、切片策略、检索算法？ 这听起来很美好，但现实是残酷的。 本文将从准确率、成本、延迟三个维度，深度剖析 RAG 与 Long Context 的优劣。

1. 准确率 (Accuracy)：Lost in the Middle 依然存在 ​

1.1 大海捞针 (Needle in a Haystack) ​

虽然模型号称能处理 1M Token，但在 1M Token 中精准找到那 1 个关键事实（Needle），准确率并非 100%。 特别是当“针”位于 Context 的中间位置时，模型经常会忽略它（参见《长上下文的陷阱》）。 相比之下，RAG 通过先检索，只把最相关的 Top-K 片段（比如 5 个 Chunk，共 2K Token）喂给模型。 此时，模型的注意力非常集中，幻觉率大幅降低。

1.2 干扰信息 (Distractors) ​

长 Context 中充斥着大量无关信息，这些噪音会干扰模型的推理。 RAG 的检索步骤本质上是一个过滤器 (Filter)，把噪音挡在了外面。

2. 成本 (Cost)：Token 是按字算钱的 ​

2.1 每次提问都要读一遍书？ ​

假设你有一本 500 页的书（约 200K Token）。

  • Long Context：每次用户提问，都要把这 200K Token 发送给模型。按 GPT-4-Turbo $10/1M Input 计算，问一次就要 $2。问 100 次就是 $200。
  • RAG：只把相关的 2K Token 发送给模型。问一次只要 $0.02。成本相差 100 倍。

2.2 缓存技术 (Prompt Caching) ​

虽然 Anthropic 推出了 Prompt Caching，可以缓存前缀（Prefix），大幅降低 Input 成本。 但缓存是有 TTL 的，且只对完全相同的前缀有效。 如果每个用户的 Context 都不一样（个性化知识库），缓存很难命中。

3. 延迟 (Latency)：等待是最大的敌人 ​

3.1 首字延迟 (TTFT) ​

处理 1M Token 的 Prefill 需要巨大的算力。 即使在强劲的 H100 集群上，也可能需要数秒甚至数十秒才能吐出第一个字。 用户受得了吗？ RAG 只处理几千 Token，TTFT 通常在 1 秒以内。

3.2 并发能力 ​

长 Context 占用的显存（KV Cache）巨大。 一张 80G 的 A100 可能只能跑 1-2 个并发。 RAG 的并发能力要高得多。

4. 辩证统一：RAG + Long Context ​

RAG 不会死，它会进化。 未来的架构不是二选一，而是融合。

4.1 粗筛 + 精读 ​

  1. RAG 粗筛：从海量文档（100M+ Token）中检索出 Top-50 相关文档（约 50K Token）。
  2. Long Context 精读：把这 50K Token 一次性喂给长窗口模型（如 Claude 3 Haiku）进行综合分析。
    • 既避免了全量 Context 的昂贵，又利用了长窗口的全局理解能力。

4.2 动态决策 ​

  • 简单问题（"特斯拉去年营收多少？"）：走 RAG，精准定位，便宜快。
  • 复杂分析（"对比这三份财报的风险因素"）：走 Long Context，需要跨文档综合推理。

RAG 代表的是索引 (Indexing) 的思想，Long Context 代表的是阅读 (Reading) 的能力。 这就好比图书馆：

  • RAG 是图书管理员（检索系统），帮你找到那本书。
  • Long Context 是你的阅读速度，让你能快速读完那本书。 无论你的阅读速度多快，你都不可能把图书馆里所有的书都读一遍再回答问题。 所以，图书管理员（RAG）永远不会失业。