RAG和长上下文，正在联手骗你

KNOWLEDGE ACCESS · 知识获取路径对决

RAG 每次查询 $0.012，Long Context 每次 $0.60：50 倍价差锁不死谁？

从 KV Cache 物理约束到 Needle-in-a-Haystack 基准， RAG vs 长上下文的硬核对账

KV Cache 328KB/token · Prefill 二次复杂度 · Context Rot · 检索精度 49.0% · 多跳推理断层

KEY TAKEAWAY

1. Long Context 在准确率上全面优于 RAG（56.3% vs 49.0%），但代价是每次查询 50 倍的 Token 成本（0.60 vs 0.012）和 2 分钟以上的 Prefill 延迟（128K 上下文在 128×H100 上仍需 3.8 秒）。

2. KV Cache 是长上下文的物理瓶颈：Llama 3.1 70B 每 token 消耗 328 KB KV 缓存，128K 上下文需 40 GB，1M 上下文需 328 GB——超过 4 张 H100 的显存总量。

3. 两者不是替代关系。最优解是混合架构：RAG 做粗筛（从百万文档中检索 Top-K），Long Context 做精读（把 Top-K 结果塞入上下文窗口做推理）。关键在于找到检索精度和上下文成本的交叉甜点。

阅读提示：本文面向 AI 应用架构师 / 后端工程师 / 技术决策人。不做基础科普，假设你已了解 Transformer Attention、Vector Embedding、Tokenization 等基础概念。预计阅读 16 分钟。

TABLE OF CONTENTS

01 · 为什么 2026 年"RAG 已死"和"Long Context 万能"同时刷屏

02 · 物理约束钉在墙上：KV Cache 公式、Prefill 二次复杂度、单查询成本

03 · 为什么两条路都比看起来更难：Context Rot、检索断层、分块边界

04 · 甜点区划分：按语料规模 × 查询模式的四层 Bracket

05 · 没人谈的工程陷阱：检索精度 × 多跳推理的复合塌方

06 · 四种架构模式与成本曲线：Pure RAG / Pure LC / Hybrid / Cache-Augmented

07 · SOTA vs 现实：六个基准横评表

08 · 单位经济学：三个场景的年度对账

09 · Checklist：12 项架构决策清单

01 · 为什么 2026 年"RAG 已死"和"Long Context 万能"同时刷屏

2025 年末到 2026 年中，两股叙事在技术社区反复碰撞。一边是 Google 发布 Gemini 2.5 Pro（1M token 上下文窗口）和 Gemini 3.1 Pro（1M，多跳推理准确率 100%），社区开始喊"RAG 已死"。另一边是企业实际部署数据揭示 Long Context 的单次查询成本是 RAG 的 50 倍（

两方都有数据支撑，但都在推销片面结论。arXiv 2501.01880 的横评在 12 个 QA 数据集上测试了 13,628 个问题：Long Context（GPT-4o）准确率 56.3%，RAG 准确率 49.0%——差距 7.3 个百分点。但同一篇论文指出，RAG 的最佳检索器（RAPTOR）在复杂场景下准确率仅 38.5%，意味着每 5 次检索有 3 次拿不到正确答案。

这篇文章把两条路径的物理约束、成本公式、准确率曲线算清楚——在什么语料规模、什么查询量、什么精度要求下，你应该走哪条路。

02 · 物理约束钉在墙上：KV Cache 公式、Prefill 二次复杂度、单查询成本

在讨论"谁更好"之前，先把两条路径的物理约束用公式写出来。每一个后续结论都必须追溯到这张表里的数字。

图 1 · RAG vs Long Context 架构 DNA——50 倍成本差 vs 7.3 个百分点精度差

KV Cache 的主公式是所有推导的起点。对于采用 Grouped Query Attention（GQA）的模型：

# KV Cache 内存公式

KV_mem = 2 × L × h_kv × d_h × seq_len × dtype_bytes

# Llama 3.1 70B 参数：L=80, h_kv=8 (GQA), d_h=128, FP16=2 bytes

KV_per_token = 2 × 80 × 8 × 128 × 2 = 327,680 bytes ≈ 328 KB

# 不同上下文长度的 KV Cache 内存

KV@8K   = 328 KB × 8,000   = 2.5 GB

KV@32K  = 328 KB × 32,000  = 10 GB

KV@128K = 328 KB × 128,000 = 40 GB

KV@1M   = 328 KB × 1,000,000 = 328 GB

# 对比：H100 80GB 显存，模型权重 ~140 GB（70B×FP16）

# 128K 上下文：140 GB（权重）+ 40 GB（KV）= 180 GB → 至少 3×H100

# 1M 上下文：140 GB + 328 GB = 468 GB → 至少 6×H100

# 注：以上 GB 为十进制（10⁹ bytes），Binary GiB 下约为 39.1 GiB @128K / 305 GiB @1M

Prefill 阶段的二次复杂度是第二道硬墙。标准 Transformer Attention 的计算量为 O(n²)，这意味着：

图 2 · KV Cache 内存增长——Llama 3.1 70B 在 1M 上下文时需 328 GB，RAG 恒为 ~1 GB

10K tokens：~1 亿次注意力计算 → TTFT <1 秒

128K tokens：~164 亿次注意力计算 → TTFT ~3.8 秒（128×H100）

1M tokens：~1 万亿次注意力计算 → TTFT >2 分钟

从 128K 到 1M，token 数增长 8 倍，但注意力计算量增长 64 倍。

结论：Long Context 的物理瓶颈不是模型参数，而是 KV Cache 的线性增长和 Prefill 的二次复杂度。128K 上下文需要 40 GB KV Cache（至少 3×H100），1M 上下文需要 328 GB（至少 6×H100），而 Prefill 延迟在 1M 时超过 2 分钟。RAG 通过"只检索 Top-K"把这两个约束压到了 1 GB KV Cache 和 <1 秒 TTFT。

数据来源：Bytebell KV Cache Math（Llama 3.1 70B GQA FP16）、Introl Long-Context Infrastructure Blog（128×H100 TTFT 数据）、Spheron GPU Memory Guide（H100 80GB 规格）。

03 · 为什么两条路都比看起来更难：Context Rot、检索断层、分块边界

约束表给出了理论边界。但在工程实践中，两条路径各有三个比理论值更难对付的问题。

Long Context 的第一个问题是 Context Rot（上下文腐化）。Chroma 的研究表明，即使模型在 Needle-in-a-Haystack 测试中拿到 100%，当 needle 和 question 的语义相似度降低时，准确率会显著下降。也就是说，模型擅长"在 100 万 token 里找一句精确匹配的话"，但不擅长"在 100 万 token 里理解分散在多个段落中的隐含逻辑"。上下文越长，模型的注意力分布越倾向于头尾（U-shape attention bias），中间位置的信息被忽略的概率越高。

Long Context 的第二个问题是多跳推理断层。arXiv 2605.02173 的 1M token 多跳推理测试显示：Gemini 3.1 Pro 100%，Claude Opus 4.6 80%，GPT-5.1 73%，Qwen3.6-plus 60%，DeepSeek V4 Pro 40%。差距从 100% 到 40% 横跨 60 个百分点——这意味着对于需要跨多个文档段落进行推理的任务，不同模型的长上下文能力差异极大。"上下文窗口大"不等于"能有效利用整个窗口"。

Long Context 的第三个问题是成本不可压缩。即使使用 Prompt Caching（Anthropic 缓存读取 0.30/M tokens），200K token 的查询仍然需要 0.06/次。而缓存只在连续使用相同前缀时有效——如果每次查询的上下文内容不同（不同的文档被塞入），缓存命中率接近零。

RAG 的第一个问题是检索精度天花板。arXiv 2501.01880 的 12 数据集横评显示，RAG 整体准确率 49.0%，最佳检索器（RAPTOR）仅 38.5%。也就是说，在复杂查询场景下，RAG 检索出的 Top-K chunks 有超过 60% 的概率不包含回答问题所需的关键信息。检索阶段犯错，生成阶段无法弥补——这是 RAG 管道最致命的单点故障。

RAG 的第二个问题是分块边界效应。把文档切分成 512-token chunks 时，一个跨越两个 chunk 边界的因果关系会被完全切断。Firecrawl 的 2026 年分块策略基准测试表明，固定大小分块（fixed-size chunking）的检索准确率通常低于语义感知分块（semantic chunking），但后者需要额外的分块模型和更高的预处理成本。分块大小的选择本身就是一个精度-成本的 trade-off：256 tokens 更精确但 chunks 数更多（检索噪声更大），1024 tokens 更完整但包含更多无关信息（生成质量下降）。

RAG 的第三个问题是多跳推理的指数衰减。如果一个问题的答案需要跨越 3 个文档段落推理（A→B→C），而每跳的检索准确率为 49%，那么三跳全对的概率是 49%³ ≈ 11.8%。即使检索准确率提升到 70%，三跳全对也仅 34.3%。这是 RAG 在复杂推理任务上天然弱于 Long Context 的根本原因。

结论：Long Context 在准确率上更强，但受限于 Context Rot、多跳断层（40%–100%）和不可压缩的成本。RAG 在成本上更优，但受限于检索精度（49.0%）、分块边界和多跳指数衰减（三跳全对仅 11.8%）。两条路各自的短板恰好指向对方——这是混合架构存在的基本理由。

04 · 甜点区划分：按语料规模 × 查询模式的四层 Bracket

既然两条路各有硬伤，那在什么条件下走哪条路是最优的？用语料规模（token 数）和查询模式（单跳 vs 多跳 / 高频 vs 低频）两个轴做四层 Bracket：

图 3 · 架构决策树——按语料规模和查询模式选择最优路径

BRACKET 1 · <32K TOKENS

Long Context 甜区 · "直接把文档塞进去"

语料规模：≤32K tokens（~24 页文档，~48,000 英文单词）。KV Cache 成本：328 KB × 32,000 = 10 GB（Llama 3.1 70B），单张 H100 可容纳。TTFT：<1 秒。准确率：Long Context 56.3% 显著优于 RAG 49.0%（arXiv 2501.01880），且 Context Rot 在 32K 以内不显著。成本：

BRACKET 2 · 32K–200K TOKENS

交叉区 · "取决于查询量和精度要求"

语料规模：32K–200K tokens（~24–150 页文档）。KV Cache 成本：10–62 GB，需要 1–2 张 H100。TTFT：1–5 秒。准确率：Long Context 仍有优势，但 Context Rot 开始显现（尤其在 >128K 时）。成本：

BRACKET 3 · 200K–1M TOKENS

RAG 必要区 · "塞得进去但用不起"

语料规模：200K–1M tokens（~150–750 页文档）。KV Cache 成本：62–328 GB，需要 2–6 张 H100。TTFT：5 秒–2 分钟以上。准确率：Context Rot 显著，多跳推理断层（GPT-5.1 @1M 仅 73%）。成本：0.60–3.00/查询（无缓存），0.06–0.30（缓存命中）。判定：RAG 是唯一经济可行的方案。除非是极低频、极高价值任务（如季度合规审计），否则 Long Context 的延迟和成本都不可接受。

BRACKET 4 · >1M TOKENS

RAG 垄断区 · "物理上塞不进去"

语料规模：>1M tokens（~750+ 页文档，企业级知识库）。 KV Cache 成本：>328 GB，超出任何单节点 GPU 集群配置。 准确率：即使 Gemini 3.1 Pro 宣称 1M 窗口，Qwen3.6-plus 在 1M 时单针检索准确率已跌至 39%，多跳 60%——"窗口大"不等于"窗口有效"。 成本：$3.00+/查询，且延迟超过 2 分钟，用户体验不可接受。 判定：RAG 是唯一选项。Long Context 在 >1M 的场景下既贵、又慢、又不准确。

结论：<32K 用 Long Context，>200K 用 RAG，32K–200K 是交叉区需要按查询量和精度要求选择。语料规模的四个 Bracket 决定了 80% 的架构决策，剩下 20% 由查询频率和多跳推理需求决定。

05 · 没人谈的工程陷阱：检索精度 × 多跳推理的复合塌方

RAG 系统有一个被严重低估的工程陷阱：检索精度的误差会在多跳推理中被指数放大，而且这个放大效应在 benchmark 中几乎不被测量。

标准的 RAG 评估流程是：给定一个问题 → 检索 Top-K chunks → 用 LLM 生成答案 → 评估答案正确性。这个流程假设答案可以在一个检索步骤内完成。但现实中大量的企业查询需要多跳推理：

• "我们 Q3 营收最高的产品线是什么？该产品线的毛利率和去年同期相比变化了多少？"（2 跳：产品线识别 → 毛利率对比）

• "根据最新的合规要求，我们的数据处理流程需要修改哪些步骤？这些修改会影响哪些下游系统？"（3 跳：合规要求 → 流程步骤 → 下游系统）

• "上次我们遇到类似的数据库性能问题时，最终的根因是什么？那个修复方案在当前架构下还适用吗？"（3 跳：历史问题 → 根因 → 适用性判断）

多跳推理的准确率衰减模型是乘法而非加法：

# 多跳推理准确率 = 每跳检索准确率的 N 次方

P_correct(n hops) = retrieval_accuracy ^ n

# RAG 整体准确率 49.0%（arXiv 2501.01880）

P_correct(1 hop)  = 0.49 ^ 1 = 49.0%

P_correct(2 hops) = 0.49 ^ 2 = 24.0%

P_correct(3 hops) = 0.49 ^ 3 = 11.8%

P_correct(4 hops) = 0.49 ^ 4 = 5.8%

# 即使优化到 70% 单跳准确率

P_correct(3 hops, 70%) = 0.70 ^ 3 = 34.3%

# 对比：Long Context 把全部文档塞入窗口

# 不存在检索步骤 → 无多跳衰减

# Gemini 3.1 Pro @1M 多跳准确率 = 100%（arXiv 2605.02173）

# GPT-5.1 @1M 多跳准确率 = 73%

这个衰减模型揭示了 RAG 和 Long Context 之间最本质的区别：RAG 把"检索"和"推理"分成了两个独立步骤，每个检索步骤都引入误差；Long Context 把所有信息放在同一个上下文窗口里，由模型一次性完成所有推理步骤，不存在检索误差的累积。

缓解多跳衰减有两种路径。第一种是 Iterative Retrieval（迭代检索）：在第一跳检索结果的基础上，生成后续查询再检索。这可以把每跳准确率从 49% 提升到 60–65%，但代价是 2–3 倍的检索延迟和 Token 成本。第二种是 GraphRAG（图检索增强）：把文档间的关系建模为知识图谱，在图上做多跳遍历而非向量相似度检索。微软的 GraphRAG 在需要全局理解的查询上显著优于标准 RAG，但构建和维护知识图谱的工程成本远高于向量数据库。

结论：RAG 的多跳推理存在指数衰减陷阱——49% 单跳准确率在三跳后退化为 11.8%。Long Context 因为没有独立的检索步骤，不存在这个衰减。如果你的应用场景中多跳推理是核心需求（合规审查、技术故障排查、跨文档分析），Long Context 或 Hybrid 架构是必须考虑的选项，即使成本更高。

06 · 四种架构模式与成本曲线：Pure RAG / Pure LC / Hybrid / Cache-Augmented

把 RAG 和 Long Context 的组合方式归纳为四种架构模式，每种有不同的成本结构和适用场景：

图 4 · 延迟对比——RAG 端到端 1.1–3.1 秒 vs Long Context 5.8 秒–2+ 分钟

Pattern A · Pure RAG

流程：Query → Embedding → Vector Search → Top-K Chunks → LLM Generate。成本结构：Embedding API 0.02/M tokens + Vector DB 0.001/query + LLM Generation 0.01/query ≈ 0.012/query。延迟：Embedding ~50ms + Vector Search ~20ms + Generation ~1–3s ≈ 1.1–3.1 秒。准确率：49.0%（arXiv 2501.01880），多跳场景指数衰减。适用：大规模语料（>200K tokens）、高频查询（>1K 次/天）、单跳问答。

Pattern B · Pure Long Context

流程：所有文档 → Tokenize → 塞入上下文窗口 → LLM 一次性推理。成本结构：Input tokens × 1.25/M（Gemini 2.5 Pro ≤200K）+ Output tokens × 10/M ≈ 0.25–0.60/query。延迟：Prefill ~3.8s @128K / >2min @1M + Generation ~2–5s ≈ 5.8 秒–2+ 分钟。准确率：56.3%（arXiv 2501.01880），多跳无衰减（Gemini 3.1 Pro 100% @1M）。适用：小规模语料（<32K tokens）、低频高精度需求（法律、医学）、多跳推理密集型任务。

Pattern C · Hybrid（RAG 粗筛 + Long Context 精读）

流程：Query → RAG 检索 Top-20 Chunks → 重排序（Reranker）取 Top-5 → 塞入 Long Context 窗口 → LLM 推理。成本结构：RAG 检索 0.005 + Reranker 0.002 + LLM Generation ~0.05（5 chunks ≈ 5K tokens）≈ 0.057/query。延迟：检索 ~200ms + 重排序 ~100ms + Generation ~2–4s ≈ 2.3–4.3 秒。准确率：显著高于 Pure RAG（Reranker 提升检索精度 10–15 个百分点），接近 Pure LC 但成本仅为后者的 1/4–1/10。适用：中大规模语料（32K–1M tokens）、需要多跳推理但预算有限的场景。

Pattern D · Cache-Augmented Generation

流程：常用文档 → 预加载到 Prompt Cache → Query 命中缓存时直接推理，未命中时走 RAG 补充。成本结构：缓存写入 3.75/M（一次性）+ 缓存读取 0.30/M + 偶尔 RAG 0.012 ≈ 0.03–

结论：四种架构模式的成本区间为 $0.012（Pure RAG）→ $0.03–0.06（Cache-Augmented）→ $0.057（Hybrid）→ $0.25–0.60（Pure LC）。Hybrid 模式是 32K–1M 语料规模下的最优平衡点——用 RAG 的成本获得接近 Long Context 的准确率。

07 · SOTA vs 现实：六个基准横评表

把 RAG 和 Long Context 在六个关键基准上做横评。每个基准给出具体数值、来源和一行工程解读。

图 5 · 六维基准雷达——Long Context 在准确率维度全面领先，RAG 在成本和延迟维度占优

横评表里有三个值得注意的细节。

第一，Needle-in-Haystack 单针测试的高分具有误导性。Gemini 3.1 Pro 在 1M token 的单针检索中拿到 100%，但同一测试中 Qwen3.6-plus 仅 39%，DeepSeek V4 Pro 仅 72%。单针测试只测量"能否在长文本中找到一句精确匹配的信息"，不测量理解、推理、综合能力。用 NiH 分数来证明"Long Context 已经完美"是过度推断。

第二，RAG 的 49.0% 准确率包含了大量"检索正确但生成错误"的案例。如果只看检索精度（Top-K chunks 是否包含答案），RAG 的分数会更低。49.0% 是端到端准确率——检索 + 生成的复合结果。这意味着检索阶段的瓶颈比表面数字更严重。

第三，成本差距可以通过架构优化缩小但无法消除。Prompt Caching 把 Long Context 的 0.60 降到 0.06（10×），但缓存只在连续使用相同前缀时有效。对于语料库经常变化或查询模式多样的场景，缓存命中率低于 50%，实际成本仍然在

08 · 单位经济学：三个场景的年度对账

用三个具体场景算清楚年度成本。所有计算基于 Gemini 2.5 Pro 定价（1.25/10 per 1M tokens ≤200K，2.50/15 >200K），RAG 系统使用 text-embedding-3-small（0.02/M tokens）+ Pinecone（70/月 serverless）。

图 6 · 三个场景年度成本——RAG 始终最低，Hybrid 在法律场景接近 RAG 但准确率接近 LC

场景 A · 内部知识库问答（1K 查询/天，平均 50K tokens 语料命中）

Pure RAG：0.012 × 1,000 × 365 = 4,380/年 + 基础设施 840/年 ≈ 5,220/年Pure Long Context：50K tokens × 1.25/M = 0.0625/query + Output ~0.02 = 0.0825 × 365,000 = 30,113/年Hybrid：0.057 × 365,000 =

场景 B · 法律合同审查（50 查询/天，平均 150K tokens 语料，多跳推理密集）

Pure RAG：0.012 × 50 × 365 = 219/年 + 基础设施 840/年 ≈ 1,059/年（但多跳准确率仅 ~24%，不可接受）Pure Long Context：150K tokens × 1.25/M = 0.1875 + Output ~0.05 = 0.2375 × 18,250 = 4,334/年Hybrid：0.057 × 18,250 = 1,040/年（准确率接近 Pure LC，多跳推理有 Reranker 增强）价差：Hybrid 和 Pure RAG 成本几乎相同（1,040 vs

场景 C · 客户支持 SaaS（10K 查询/天，平均 30K tokens 上下文）

Pure RAG：0.012 × 10,000 × 365 = 43,800/年 + 基础设施 2,400/年 ≈ 46,200/年Pure Long Context：30K × 1.25/M = 0.0375 + Output ~0.015 = 0.0525 × 3,650,000 = 191,625/年Cache-Augmented：缓存命中 70% → 0.045 × 0.7 + 0.012 × 0.3 = 0.0351 × 3,650,000 =

结论：在三个场景中，Pure RAG 年度成本最低（$1,059–$46,200），Pure Long Context 最高（$4,334–$191,625），价差范围 2.8×–5.8×。但法律合同审查场景揭示了一个关键例外：当多跳推理准确率是核心需求时，Hybrid 以几乎等于 Pure RAG 的成本（$1,040 vs $1,059）提供了接近 Long Context 的准确率——这是 Hybrid 架构 ROI 最高的场景。

09 · Checklist：12 项架构决策清单

如果你正在为一个新项目选择知识获取架构，以下 12 项可以逐步推导出最优方案：

1 量化语料规模：计算你的总语料 token 数。<32K → Bracket 1（Long Context），32K–200K → Bracket 2（交叉区），>200K → Bracket 3/4（RAG 必要）

2 量化查询频率：日均查询数 × 单次成本 = 年度预算。>1K 次/天时 RAG 的成本优势被放大，<50 次/天时成本差异可忽略

3 评估多跳推理需求：如果核心查询需要跨 2+ 文档推理，Pure RAG 的多跳衰减（49%→24%→11.8%）不可接受，必须引入 Hybrid 或 Long Context

4 计算 KV Cache 预算：用 328 KB/token × 最大上下文长度，确认你的 GPU 配置能否容纳。128K 需 40 GB（3×H100），1M 需 328 GB（6×H100）

5 测量 TTFT 容忍度：用户体验要求 <2 秒响应 → 上下文必须 <32K 或使用 RAG。法律/审计场景可接受 10+ 秒 → Long Context 可行

6 选择分块策略：如果走 RAG 路径，分块大小直接影响精度。256 tokens 高精度高噪声，1024 tokens 低精度低噪声。建议从 512 tokens + 50 token overlap 开始调优

7 添加 Reranker：如果走 Hybrid 路径，Reranker（Cohere Rerank、BGE Reranker）可以把 Top-20 粗筛结果重排到 Top-5，检索精度提升 10–15 个百分点

8 评估缓存命中率：如果你的查询符合 80/20 分布（20% 文档覆盖 80% 查询），Cache-Augmented 模式（Pattern D）可以把成本从 0.60 降到 0.03–0.06

9 实测目标模型的 Needle-in-Haystack：不要信任厂商宣称的上下文窗口大小。用你自己的数据跑 NiH + 多跳测试，确认有效上下文长度

10 监控 Context Rot：如果走 Long Context 路径，定期检测模型在不同上下文长度下的准确率衰减。Chroma 的研究表明 Context Rot 在语义相似度低时加速恶化

11 建立评估 Pipeline：不管选哪条路径，建立包含 Recall@K、Faithfulness、Answer Relevancy 三个指标的自动评估系统。没有评估 = 没有优化方向

12 预留架构迁移路径：语料规模会增长，查询模式会变化。从 RAG 起步 → 添加 Reranker（Hybrid）→ 引入 Cache-Augmented → 在关键任务上叠加 Long Context。不要一开始就锁死架构

结语

RAG 和 Long Context 之间不存在"谁取代谁"的叙事。它们是两条互补的知识获取路径，各自的物理约束决定了各自的适用边界。Long Context 在准确率上更强（56.3% vs 49.0%），且不存在多跳推理的指数衰减（Gemini 3.1 Pro 100% vs RAG 三跳 11.8%），但代价是 50 倍的查询成本（

语料规模是最强的决策信号：<32K tokens 用 Long Context，>200K tokens 用 RAG，32K–200K 是交叉区需要按查询频率和多跳需求选择。这个 80% 的决策可以用一个数字（语料 token 数）做出。剩下 20% 需要评估多跳推理的重要性、TTFT 容忍度、和缓存命中潜力。

对于 AI 应用架构师来说，核心行动项不是"选 RAG 还是选 Long Context"，而是"为不同规模的知识获取任务设计不同层次的架构"。从 Pure RAG 起步，按需叠加 Reranker、Prompt Cache 和 Long Context 精读——这是 ROI 最高的演进路径。

FINAL TAKEAWAY

RAG = $0.012/query · <1s TTFT · 49.0% 准确率 · 多跳 11.8%（3 跳）→ 低成本、低延迟、大规模语料首选

Long Context = $0.60/query · 3.8s–2min TTFT · 56.3% 准确率 · 多跳 100%（Gemini 3.1）→ 高精度、多跳推理、小规模语料首选

最优解 = Hybrid（RAG 粗筛 + LC 精读）：$0.057/query · 接近 LC 准确率 · 1/4–1/10 成本 → 32K–1M 语料规模下的平衡点

REFERENCES

[1] arXiv 2501.01880, "Long Context vs. RAG for LLMs: An Evaluation and Revisits"（2025.01）— 12 数据集 13,628 问题横评，LC 56.3% vs RAG 49.0%

[2] arXiv 2605.02173, "Retrieval and Multi-Hop Reasoning in 1M-Token Context Windows"（2026.05）— NiH 单针 + 多跳推理横评，Gemini 100% / Claude 80% / GPT 73%

[3] Bytebell, "KV Cache Memory Math: Calculating Exactly How Much VRAM You Need" — Llama 3.1 70B GQA FP16 每 token 328 KB，128K = 39.1 GB

[4] Introl Blog, "Long-Context LLM Infrastructure" — TTFT 数据（3.8s @128K on 128×H100）、KV Cache ~15GB/user @1M

[5] MindStudio / Anthropic, "Flat-Rate Long-Context Pricing" — RAG

[6] Chroma Research, "Context Rot: How Increasing Input Tokens Impacts LLM Performance" — 语义相似度低时准确率加速衰减

#RAG #LongContext #KVCache #NeedleInHaystack #HybridRAG #TokenEconomics

本文数据截至 2026 年 6 月，所有数值来自公开论文、官方定价页面与基础设施技术博客。欢迎指正。