长文本上下文窗口在 RAG 架构中能否完全取代向量数据库？

Gemini 1.5 Pro 这种百万级 Token 窗口的出现，让很多人开始质疑 RAG（检索增强生成）的必要性：既然我可以把整个代码库或几本书直接塞进上下文，为什么还要费劲地去做 Embedding、切片和维护向量数据库？

但从工程实践来看，长文本窗口是对 RAG 的能力补充，而非底层取代。

把长文本窗口比作“内存”，向量数据库就是“硬盘”。即便内存扩大到 1TB，你依然不会把所有文件都常驻内存，因为成本和效率是两回事。

首先是推理成本的线性增长。目前的 Transformer 架构，注意力机制的计算量随序列长度增加而剧增。虽然有线性注意力机制的优化，但直接输入 100 万 Token 的 Prompt，其 Token 消耗和响应延迟（TTFT）远高于从向量数据库中检索出最相关的 3 个片段。对于高频调用的商业应用，全量上下文意味着账单爆炸。

其次是“迷失在中间”（Lost in the Middle）的现象依然存在。即便窗口足够大，模型对文本中间部分的注意力依然会下降。在 RAG 架构中，通过向量检索精准定位到关键片段，实际上是给模型做了一次“预筛选”，让模型在极小且高相关度的范围内进行推理，这比让模型在百万字中大海捞针的准确率要高得多。

对开发者而言，这意味着架构逻辑的演进：从「检索 → 生成」变为「粗筛 → 精排 → 长文本分析」。

未来的最佳实践大概率是：用向量数据库做海量数据的低成本初筛，过滤出 5-10 万字的候选集，然后再利用长文本窗口进行深度的跨文档推理。

如果你在构建知识库，不要急着抛弃向量库，建议尝试这种组合方案：
向量检索（找相关片段） → 重排序（Rerank） → 喂给长窗口模型（深度理解）。

这种模式下，代码实现逻辑不再是简单的：

# 旧 RAG: 检索 top_k -> 拼接 prompt -> 生成
context = vector_db.search(query, k=3)

而应该是：

# 新模式: 检索 top_100 -> Rerank 过滤到 20k tokens -> 长上下文推理
candidates = vector_db.search(query, k=100)
refined_context = reranker.filter(candidates, threshold=0.7) 
# 此时 refined_context 依然在长窗口可承受范围内，且质量极高

长文本窗口解决了 RAG 中最头疼的“切片截断导致语义丢失”问题，但它无法解决大规模数据存储的索引效率问题。两者结合才是目前的工业级最优解。