别再盲目追求超长窗口，RAG 与长上下文的取舍路径

盲目追求 2 M 甚至 10 M 的上下文容量，常常忽视了模型的“装载能力”与“检索精度”之间的差距。多轮压测显示，这两者并非可以直接互换的关系。

以 Claude 3.5 Sonnet 与 Gemini 1.5 Pro 为例，面对超过十万字的技术手册时，即便官方宣称支持超长上下文，一旦关键信息埋在正文的中段（即常说的 Needle In A Haystack 场景），模型的召回率会出现明显下降。相对而言，传统的检索增强生成（RAG）方案在同样条件下表现更为稳健。关于 Claude 3.5 Sonnet 的上下文上限，可在官方文档中查阅。

不同任务下的表现差异

• 全局逻辑梳理

当目标是概括一本二十万字小说的人物关系演变，需要跨章节的对比与整体理解时，RAG 往往难以胜任。因为 RAG 采用切片（Chunk）方式检索，只能捕获碎片信息，难以还原完整的逻辑链。此时直接将全文喂给 Gemini 1.5 Pro，效果显著好于任何 RAG 组合。

• 精准参数查询

在查阅上千页的云服务文档，定位特定冷门 API 的错误码时，直接使用超长上下文容易导致模型产生幻觉或返回“未提及”。采用 BGE‑M3 进行向量检索，再配合简单的重排序（Rerank），可以在秒级内锁定目标段落，准确率接近 100%。

核心劣势拆解

• 超长上下文的缺点

1. 显存占用与 Token 成本随窗口增长呈指数上升，每次推理都需要重新计算整个窗口，导致成本高、速度慢。
2. 注意力分布随文本长度稀释，模型对细节的敏感度随之下降。

• RAG 的局限

1. 极度依赖切片策略：切片过细会导致上下文断裂，切片过粗则会引入大量噪声。
2. 检索失败直接影响后续生成，表现出明显的首因效应。

工程实践建议

在实际项目中，无需在超长上下文与 RAG 之间做二选一的抉择，最佳做法是构建混合架构。先利用 RAG 完成初步筛选，提取 5‑10 条高相关性片段，再结合必要的背景信息交给支持 128 K 窗口的模型进行最终处理。

若需要实现基础的检索过滤逻辑，可参考如下伪代码：

# 伪代码：混合检索流程
def hybrid_retrieval(query, doc_store):
    # 1. 向量检索获取语义相关片段
    vector_results = vector_db.search(query, top_k=20)
    # 2. BM25 关键词检索补全硬匹配
    keyword_results = bm25.search(query, top_k=20)
    # 3. Rerank 重排序，只取前 5 个最准的
    final_context = reranker.rank(vector_results + keyword_results, query)[:5]
    return final_context

综上所述，超长上下文扩展了模型的“阅读广度”，而 RAG 则保证了“检索精度”并控制了计算成本。在企业级场景中，RAG 可作为底层支撑，长上下文则充当更宽裕的“临时缓存”。