RAG vs Long Context

当需要让 LLM 使用外部知识时，有两种主流方案：RAG（检索+生成）和长上下文（直接将大量文本塞入提示词）。DeepSeek-V4 的 1M token 上下文窗口等技术进步，正在重新挑战 RAG 的默认首选地位。本页从架构原理、成本、延迟、准确性、可扩展性等维度展开对比。

Comparison Overview

RAG 是一个多步骤流水线：文档分割 → 向量化 → 检索 → 重排序 → 上下文组装 → 生成 →（可选）引用验证。每个环节都可能成为质量瓶颈。

长上下文模型只需要一个步骤：将文本拼入提示词。但长上下文的"简单"是表面的——模型需要在海量序列中准确关注到相关信息，attention 退化、"lost in the middle" 等现象是真实挑战。

短文本场景（单段/几段文档，<64K tokens）：RAG 和长上下文成本大致相当。RAG 多了向量检索/重排的固定开销但输入 token 少；长上下文直接输入多但架构简单。
中等文本（64K–256K）：RAG 优势开始显现，因为它只处理最相关的片段。长上下文需要完整的 self-attention 计算。
超长文本（256K–1M）：传统上 RAG 优势巨大。但 DeepSeek V4 的 CSA（Compressed Sparse Attention）架构大幅降低了长上下文的计算开销——在 1M token 下仅需传统 GQA 架构 2% 的 KV cache，每条 token 的 FLOPs 降低到 V3.2 的 27%（Pro）或 10%（Flash）。这让长上下文在超长场景下重新具备经济竞争力。

RAG 的核心优势之一是显式引用：每一个生成结果可以追溯到具体的检索片段，这在合规敏感场景（医疗、法律、金融）中是硬需求。

长上下文模型在信息密度低、核心信息分散的长文档中容易出现"注意力稀释"问题。即使有 1M 上下文窗口，也不意味着模型能有效利用全部 1M token 的信息。

RAG 理论上没有上限——向量数据库可以扩展到数十亿文档。增加文档只需要重新分割、向量化、入库，不需要重新训练或修改模型。

长上下文的上限是模型上下文窗口的物理大小。当前实际部署中，主流在 128K–200K 范围，1M 是前沿但尚未到所有场景的默认选项。

场景	更优方案	理由
企业知识库（百万级文档）	RAG	规模上限无限制、可追溯、可增量更新
合规/审计场景	RAG	显式引用是硬需求
单篇长文档理解（如论文、法律合同）	Long Context	快速投入、无需检索管道
Agent 持续对话 + 上下文累积	Long Context	DeepSeek V4 等模型为 Agent 场景优化长上下文
混合场景	RAG + Long Context	检索核心片段 + 附上全文上下文

核心结论：RAG vs Long Context 不是非此即彼的选择。 实际情况往往是使用 RAG 检索最相关片段，同时将检索结果附上完整上下文一并交给模型处理。DeepSeek V4 的低成本长上下文让这种"RAG + 长上下文"融合方案变得更经济，也更具实操性。