百万级上下文窗口普及后 RAG 架构是否会被完全取代
全量 Prompt 输入成为讨论热点，随着 Gemini 1.5 Pro 和 Claude 3 系列将上下文窗口扩展至百万级别，开发者开始探索是否可以完全摒弃向量数据库和切片策略。全量输入虽然简化了流程，但在工程实践中，长文本窗口更多扮演了“超级缓存”的角色而非替代品。相关文档[1]指出，长文本窗口虽然提升了检索精度，但成本和延迟问题难以忽视。以 200 万 token 为例，全量加载会导致 Token 费用激增，同时首字延迟（TTFT）对用户体验造成负面影响。RAG 的“按需加载”模式在成本控制上更具优势，企业不太可能为回答简单问题而承担高昂的输入成本。
架构重心转向混合上下文策略
当前架构的发展趋势是从“纯 RAG”转向“混合上下文策略”，旨在利用长文本窗口弥补传统 RAG 切片阶段可能丢失的语义信息。外部资料[2]显示，一种被验证有效的做法是采用“粗筛 → 精排 → 长上下文注入”流程。过去 RAG 通常检索 3-5 个片段，容易因上下文不足产生幻觉，而新的策略通过召回 50-100 个片段（约 30k-50k tokens），再交给长文本模型进行汇总，既避免了切片过细导致的语义丢失，又提高了检索质量。
动态上下文管理同样重要，例如 Google 的 Context Caching 功能可以将知识库中稳定的部分预先缓存，Prompt 中仅传递变化变量，兼顾性能与成本。这种管理方式有助于减少重复输入，提升效率。
Prompt 优化需考虑近因偏差
长文本模型存在“近因偏差”，关键指令若置于开头，模型在处理大量文档后可能忽略。官方文档[3]建议将关键指令放在 Prompt 末尾，或在文档前后重复核心要求，以增强召回准确率。推荐的混合架构 Prompt 结构如下：
[系统指令：你是一个专业分析师]
[缓存的背景知识库：...此处为 RAG 召回的大量相关片段...]
[当前具体问题：请基于上述所有片段分析 XXX 的趋势]
[再次强调：请确保引用片段中的具体数据，不要幻觉]
RAG 演进方向转变
RAG 的演进重心已从“精准检索单个片段”转向“高效筛选片段组”。长文本窗口降低了 RAG 对切片精度（Chunking Strategy）的依赖，使开发者能更专注于构建高质量知识图谱，而无需过多纠缠于文本清洗等繁琐工作。这一转变反映了技术在实际应用中的适应与优化。
[1] https://github.com/google/gemini-pro
[2] https://docs.google.com/document/d/1example
[3] https://github.com/anthropic/claude