第29回　超长上下文时代——RAG 还有用吗？

卷能铺到万里长，不代表眼能看得清。
把书全塞进嘴里，未必就嚼得明。

前一回我们讲“生产三座山”：并行、缓存、隐私。
这一回江湖忽然又起一阵风：
超长上下文模型来了，动辄十万、百万 token。

于是有人拍桌子说：
“既然能把整库都塞进上下文，RAG 还要它做甚？”

看官别急，我们用两把尺子量一量：

能力尺：整文输入真的更会答吗？
账本尺：整文输入真的划算吗？

2024 已有系统性比较讨论“RAG vs Long-Context LLMs”，并给出混合策略：两者不是谁取代谁，而是互补。¹

一、长上下文的强：省掉切块与检索这套“前戏”

长上下文的最大优点是简单：

文档全塞进去
模型自己找重点
不用你切块、建索引、调检索器

对某些任务它确实很好用：

文档很短（相对窗口来说）
答案要跨很多段落，且段落之间强依赖
你不想维护索引与版本

这像什么？
像你手上只有一本小册子，干脆从头翻到尾，省事。

二、长上下文的弱：贵、慢、还可能“看了也没看见”

1）贵：成本按输入长度涨

你把整篇文档喂进去，就要为每个 token 付费：
不只是钱，还有延迟与显存。

2）慢：吞吐与并发压力更大

输入越长，生成前的计算越多；
并发一上来，系统就更容易堵。

3）还可能“看了也没看见”

长上下文不等于“完美阅读”。
信息越多，噪声越多；
模型可能抓错重点、忽略关键证据，甚至把相互矛盾的段落揉成一句话。

这就像你把整本《字典》摊开让同学找一个词：
他确实能找，但也可能找错页、看错行。

三、RAG 的价值：不是因为窗口不够，而是因为“证据可控”

很多人把 RAG 当成“窗口不够的补丁”。
这话只对一半。

RAG 更关键的价值有三条：

可控性：你可以强行规定“只允许引用这几段证据”
可核查：你能给出引用，让读者追溯
可扩展：文档再大也能检索到局部证据，成本不随库大小线性爆炸

所以即便窗口变长，RAG 也不会消失，反而会升级成“Agentic RAG”：
让模型自己决定何时检索、检索多少、是否再检索，形成办案式循环。²

四、混合路线：长上下文做阅读，RAG 做取证

2024 的比较研究提出“混合”思路：

当文档不长、任务需要通读：走长上下文
当任务需要可引用证据、或库很大：走 RAG
甚至两者一起用：先 RAG 取证，再把证据与关键上下文喂给长上下文模型做深加工

这像办案：

通读卷宗：长上下文
关键证据入卷并标注页码：RAG

五、极简可跑代码：用“账本”比较两种路线的输入成本

我们用一个玩具设定：

一份文档被切成很多段（chunks）
长上下文路线：把所有段都塞进去
RAG 路线：只塞 top-k 段

我们用“字符数/4”粗略当 token 数（只为演示比较，不当真值）。

import random


def approx_tokens(s):
    return max(1, len(s) // 4)


def make_doc(n=60):
    chunks = []
    for i in range(n):
        chunks.append("段落%02d：" % i + ("内容" * random.randint(10, 40)))
    return chunks


def cost_long_context(chunks):
    return sum(approx_tokens(c) for c in chunks)


def cost_rag(chunks, k):
    picked = chunks[:k]
    return sum(approx_tokens(c) for c in picked)


if __name__ == "__main__":
    random.seed(0)
    chunks = make_doc(n=60)
    full = cost_long_context(chunks)
    for k in [3, 6, 10]:
        rag = cost_rag(chunks, k)
        print("k=", k, "rag_tokens=", rag, "full_tokens=", full, "ratio=", round(rag / full, 3))

你会看到一个稳定事实：
当库很大时，RAG 的输入成本可以远低于“全塞”。

这还没算：

检索缓存带来的重复提问省钱
权限隔离带来的安全收益
引用与审计带来的可追责

所以真实系统里，“全塞”往往只能用于小库与局部任务；
大库、长周期、强合规场景，RAG 仍是主力。

六、给看官一张决策图：什么时候用谁？

你可以按四个问题决策：

文档总量大不大？大就倾向 RAG
是否必须引用与可核查？要就倾向 RAG
是否需要通读全篇推理？要就倾向长上下文或混合
成本/延迟是否敏感？敏感就倾向 RAG（再配缓存与压缩）

记住：
长上下文解决“能装下”，RAG 解决“能取证”。
两者不是仇敌，是分工。

下一回（第30回）我们再加一种更强的记忆形式：图。
当证据不是一段段，而是“实体与关系”的网络时，
你会发现“图”比纯文本更适合做多跳推理的账本。

欲知后事如何，且听下回分解。

幻觉核查

“RAG vs Long-Context”比较与混合结论：可核对 2024 研究对两类方法的对比设置与结论表述。¹
Agentic RAG 的趋势：可核对导读引用的综述对“把规划/反思/工具使用嵌入检索流程”的归纳。²
本回 token 估算为粗略教学近似，用于展示“输入长度与成本比例”的直觉，不用于真实计费。

逻辑审计

与第28回衔接：第28回讲成本与风险，本回把“长上下文 vs RAG”落到能力尺与账本尺。
与导读一致：导读强调“可核查与事实校验”，本回把 RAG 的核心价值定位为“取证可控”，而非仅仅扩窗。
为第30回铺路：当证据需要多跳连接，纯文本检索会显得笨重；图结构能把“线索网络”显式化。

引用与溯源

Li, Z., et al. Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach arXiv:2407.16833 (v2: 2024-10-17) https://arxiv.org/abs/2407.16833 ↩ ↩²
Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG arXiv:2501.09136 (2025-01) https://arxiv.org/abs/2501.09136 ↩ ↩²

第29回 超长上下文时代——RAG 还有用吗？