长上下文 vs RAG：什么时候还需要检索，什么时候直接塞

现在的主流模型动辄支持几十万甚至上百万 token 上下文，「把整个知识库塞进 prompt 不就行了，还要 RAG 干嘛？」——这是 2026 年最常被问的问题。

答案是：长上下文和 RAG 不是替代关系，而是各有成本与边界，选错会又贵又慢还更不准。

背景：两种「让模型知道更多」的路

长上下文是一次性把大量资料放进对话窗口，模型自己读。 **RAG（检索增强生成）**是先根据用户问题，从知识库里搜出最相关的几段，只把这几段喂给模型。 二者的核心差别在于：模型到底要「读全部」还是「读精华」。

怎么选

核心取舍

• 成本：长上下文按全部 token 计费，100 万字和 1000 字单价一样，烧钱极快；RAG 只付「检索到的几段」，便宜一两个数量级。
• 准确率（信噪比）：上下文越长，模型越容易在噪声里迷失、甚至「中间遗忘」（lost in the middle）。RAG 只给最相关片段，反而更准。
• 实时性与新鲜度：RAG 可以检索实时更新的库；长上下文里塞的是「提问那一刻」的快照，过期不管。
• 可溯源：RAG 天然返回引用来源，长上下文很难说清答案来自哪一句。

一个最小可运行的例子

RAG 的检索侧，常用向量数据库做语义搜索：

hits = vector_db.search(embed(question), top_k=3)   # 用户提问 → 向量检索最相关的 3 段 → 拼进 prompt
context = "\n".join(h["text"] for h in hits)
prompt = f"根据资料回答：\n{context}\n\n问题：{question}"
answer = model(prompt)

注意这里检索到的 top_k=3 片段，就是模型真正会读的全部，成本与噪声都被压到最低。

Tips

• 资料少、要整体通读（如整份合同、一篇长文），直接用长上下文，省事。
• 资料海量、要精准定位、要低成本，坚定用 RAG。
• 需要答案可溯源、可审计，RAG 几乎是唯一选择。
• 二者可混用：RAG 粗筛 + 长上下文对命中片段精读。
• 别盲目追长上下文「偷懒」——多数生产场景，RAG 的性价比更高。