百万级上下文窗口并未终结向量数据库在 RAG 系统中的核心地位

Gemini 1.5 Pro 提供的百万级 Token 上下文窗口，虽然能够规避传统切片导致的语义破碎，但在实际生产环境直接替换向量检索存在阻碍。将长文本比作内存、向量数据库比作硬盘，这种类比在经济性上差异巨大。Transformer 的注意力机制伴随序列增长呈非线性消耗，即便经过线性优化，直接输入 100 万 Token 带来的首字延迟（TTFT）与算力开销，依然远高于提取 3 个相关片段的向量检索，频繁调用极易引发成本失控。

模型在处理长上下文时，存在对中间段落注意力衰减的缺陷，模型在海量信息中“捞针”的准确度不如先由向量库进行预筛选。因此，系统架构正演变为“粗筛→精排→长文本分析”的分层模式。目前推荐的工程策略是利用向量库对海量数据进行低成本初筛，将候选数据控制在 5-10 万 Token，再输入长窗口模型进行深度分析。这种架构中，向量库负责高效索引，长窗口模型负责跨文档推理，二者缺一不可。若向量检索无法提供高质量的候选集，模型后续的推理能力将因上下文噪音过大而失效，此时必须通过重排序（Rerank）进一步提纯数据。

代码层面的优化逻辑已发生变化。旧模式仅检索 top_k 个片段：

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

新的实践流程则是将检索范围提升至 100 个候选，借助 Rerank 器筛选出相似度阈值大于 0.7 的片段，控制在 20 万 Token 以内交给模型。这样既保证了上下文的精准度，也避免了因全量投喂导致的算力浪费。工业级解决方案应将两者配合使用，在成本与模型响应效率间寻找平衡。