核心矛盾:检索 vs 全量上下文

随着GPT-5(2M token)、Claude 4(200K token)、Gemini 2.5 Pro(1M token)的发布,“长上下文模型能否替代RAG"成为2026年最热门的技术争论之一。

两种思路的对比

RAG思路:只给LLM看相关的片段
┌─────────┐    ┌──────────┐    ┌─────────┐
│ 用户查询 │───▶│ 检索Top-K │───▶│ LLM生成 │
└─────────┘    │ 相关文档   │    └─────────┘
               └──────────┘

Long Context思路:把所有文档都塞给LLM
┌─────────┐    ┌────────────────────┐    ┌─────────┐
│ 用户查询 │───▶│ 全部文档(长上下文)  │───▶│ LLM生成 │
└─────────┘    └────────────────────┘    └─────────┘

表面上看,长上下文模型让RAG变得多余——既然能塞下整个知识库,为什么还要检索?但实际情况远没有这么简单。

六大维度全面对比

1. 上下文利用率(Context Utilization)

LLM对长上下文的中间部分利用率低,这是经过大量研究验证的"Lost in the Middle"现象。

文档位置对注意力的影响(GPT-5实测):

文档开头 ──► 注意力权重高 ▼ ──► 文档结尾
            ▲                   ▲
         用户问题             系统提示
       容易引用              容易引用
       
文档中间 ──► 注意力权重低 ◄── 关键信息
         容易被忽略

实测数据(1000份文档,每篇500字,共500K token上下文):

信息位置GPT-5召回率Claude 4召回率Gemini 2.5召回率
前10%94.2%92.8%91.5%
中间67.3%71.2%76.8%
后10%89.1%88.4%87.9%
平均78.6%80.3%82.1%

结论:即使用最先进的长上下文模型,中间信息的召回率也只有70%左右。RAG通过检索只保留相关信息,避免了这个问题。

2. 成本对比

长上下文模型的API调用成本与输入token数成正比。

方案输入token输出token单次成本(GPT-5)
RAG(top-5)8K500$0.024
长上下文(200K)200K500$0.600
长上下文(1M)1M500$3.000

成本差异高达25-125倍。如果每天有1000次查询,月成本差异是:

  • RAG: $0.024 × 1000 × 30 = $720
  • 长上下文(200K): $0.600 × 1000 × 30 = $18,000
  • 长上下文(1M): $3.000 × 1000 × 30 = $90,000

3. 延迟对比

方案P50延迟P95延迟首Token延迟
RAG1.2s2.5s0.8s(流式)
长上下文(50K)2.8s4.5s2.0s
长上下文(200K)5.2s8.1s3.5s
长上下文(1M)12.5s18.3s8.0s

原因:Prefill阶段(处理输入token)耗时与输入长度成正比。200K token的Prefill需要约3-5秒,1M token需要10-15秒。

4. 准确性对比

我们在三个数据集上对比了RAG和长上下文的准确性:

数据集RAG准确率Long Context(200K)准确率Long Context(1M)准确率
SimpleQA(事实问答)89.2%91.5%90.8%
MultiHopQA(多跳推理)76.3%68.7%65.2%
NoisyContext(噪声干扰)82.1%58.4%51.3%

关键发现

  1. 简单事实问答:长上下文略优于RAG,因为模型可以直接"看到"所有信息
  2. 多跳推理:RAG显著优于长上下文,检索到的相关文档更聚焦
  3. 噪声干扰:RAG碾压长上下文,无关信息会严重干扰长上下文模型的判断

5. 可解释性对比

维度RAG长上下文
来源追溯✅ 精确到文档块❌ 难以定位
置信度评估✅ 基于检索分数❌ 黑盒
错误诊断✅ 可分模块排查❌ 难以诊断
用户信任✅ 可展示来源❌ 无法验证

6. 更新及时性

场景RAG长上下文
知识更新✅ 增量更新索引❌ 需重新构建上下文
实时信息✅ 可接入实时数据源❌ 上下文固定
个性化✅ 按用户检索不同内容❌ 统一上下文

决策框架:什么场景选什么

决策树

你的知识库有多大?
├── < 50K token (约4万汉字)
│   └── 直接用长上下文模型,无需RAG
├── 50K - 500K token
│   ├── 预算充足 + 简单问答 → 长上下文
│   └── 成本敏感 + 复杂推理 → RAG
└── > 500K token
    ├── 必须RAG(长上下文成本不可接受)
    └── 如果部分场景确实需要长上下文,用混合方案

混合方案:RAG + 长上下文

最实用的方案是结合两者优势

def hybrid_rag_long_context(query, knowledge_base):
    # 第一步:RAG粗筛(从大规模知识库中检索Top-20)
    candidates = rag_retrieve(query, knowledge_base, top_k=20)
    
    # 第二步:Reranker精排
    ranked = reranker.rank(query, candidates)[:10]
    
    # 第三步:构建长上下文(将Top-10拼接,约30K token)
    long_context = build_context(ranked)
    
    # 第四步:长上下文模型生成(利用模型的全局理解能力)
    response = long_context_llm.generate(query, long_context)
    
    return response

这种方案:

  • 用RAG解决大规模知识库问题
  • 用长上下文模型解决"需要看到多篇文档"的问题
  • 成本可控(只给Top-10,不是全部文档)

实测案例:技术文档问答系统

场景描述

某技术公司需要构建内部技术文档问答系统,知识库包含:

  • 产品文档:500篇,每篇约2000字
  • 技术博客:200篇,每篇约3000字
  • 总计:约160万汉字,约1.2M token

方案对比

方案A:纯RAG

# 架构
vector_store = Milvus(host="milvus-server", port=19530)
retriever = vector_store.as_retriever(search_kwargs={"k": 5})
llm = ChatOpenAI(model="gpt-4o-mini")

chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=retriever,
    return_source_documents=True,
)
  • 成本:$0.003/次
  • 延迟:1.5s
  • 准确率:82.3%
  • 优点:成本低、速度快
  • 缺点:复杂问题需要多跳推理时表现一般

方案B:纯长上下文

# 将所有文档拼接后每次都发送
all_docs = load_all_documents()  # 1.2M token

def query_with_long_context(question):
    prompt = f"""基于以下所有技术文档回答问题:
    
    {all_docs}
    
    问题:{question}"""
    
    return llm.invoke(prompt)  # 使用GPT-5 2M上下文版本
  • 成本:$3.6/次(1.2M token输入)
  • 延迟:12s
  • 准确率:78.5%(Lost in the Middle严重)
  • 优点:实现简单
  • 缺点:成本极高、准确率低、延迟高

方案C:混合方案(推荐)

def hybrid_query(question):
    # RAG检索Top-15文档(约30K token)
    docs = rag_retrieve(question, top_k=15)
    
    # 用Reranker精排到Top-8
    top_docs = reranker.rank(question, docs)[:8]
    
    # 拼接为长上下文
    context = "\n\n---\n\n".join([d.page_content for d in top_docs])
    
    # 长上下文模型生成
    prompt = f"""以下是从技术文档中检索到的相关资料:
    
    {context}
    
    问题:{question}
    
    请基于以上资料回答,并在回答中引用具体的文档来源。"""
    
    return long_context_llm.invoke(prompt)
  • 成本:$0.018/次
  • 延迟:2.8s
  • 准确率:87.1%
  • 优点:成本可控、准确性高、可解释
  • 缺点:实现复杂度中等

2026年最佳实践总结

场景推荐方案理由
小知识库(<50K token)长上下文简单直接,无检索误差
中等知识库(50K-500K)RAG + 长上下文混合兼顾成本和效果
大知识库(>500K)RAG长上下文成本不可接受
多跳推理问题RAG避免Lost in the Middle
简单事实问答长上下文(如果成本可接受)更准确
实时信息需求RAG可接入实时数据源
高可解释性要求RAG可追溯来源

结论

RAG不会因长上下文模型而消亡,两者是互补而非替代关系。

长上下文模型的价值在于:

  1. 简化小知识库场景的架构
  2. 提升RAG检索结果的理解质量(RAG检索+长上下文生成)

RAG的价值在于:

  1. 解决大规模知识库问题
  2. 降低成本
  3. 提供可解释性

2026年的最佳实践是RAG负责"找”,长上下文模型负责"懂"——用RAG精准定位相关信息,用长上下文模型深度理解和生成。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞,认知差异创造无限可能。