检索增强生成胜出：选择性检索比全量填充更高效可靠

背景

大模型的上下文窗口已经从原来的 4K token 扩展到 100K、甚至 1M token，理论上可以一次性读取完整代码库或文档集。很多开发者因此产生“上下文足够大，检索不再必要”的错觉。然而，窗口大小只决定 能看到多少，而 应该看到哪些 才是决定效率和可靠性的关键。本文基于 OpenAI 的 gpt-4o 与 text-embedding-3-small，对同一 10 条企业政策文档进行 RAG（检索增强生成） 与 全量填充（Context Stuffing） 两种方式的严格对比。

实验设计

1. 文档集合：10 篇结构化政策文档，总计约 650 token，涵盖退款、运费、账号安全、API 限流等核心条款。
2. 检索模型：使用 text-embedding-3-small 生成向量索引，检索 Top‑3 相关文档。
3. 生成模型：gpt-4o，温度 0，记录输入 token、输出 token、调用时延及费用。
4. 对比场景：
   • RAG：先检索 → 仅将检索到的片段拼接成 Prompt（约 278 token）。
   • 全量填充：直接把全部 10 条文档一次性注入 Prompt（约 775 token）。
5. 额外实验：模拟 “Lost in the Middle” 场景，把关键条款埋在数千 token 的噪声中，验证模型在大噪声下的注意力分散程度。

关键结果

• 效率提升：RAG 的输入 token 仅为全量填充的 36%，整体成本和时延均约为后者的一半。
• 答案一致性：两种方式均给出正确答案，说明在小规模文档上全量填充仍能工作。
• 规模放大效应：当文档规模从十条扩大到上千条时，填充的 token 量将呈指数增长，导致费用、时延和模型注意力的衰减远超 RAG 的线性增长。
• Lost in the Middle 实验：在 3 700 token 噪声中仍能找出关键 90 天退款条款，但输入 token 比仅 67 token 的聚焦版本高出 55 倍，成本和时延同样呈线性上升。

启示

1. 大模型并非万能的检索器：即使上下文窗口足够大，模型仍会受到注意力稀释的限制，关键信息可能被“埋”在噪声中。
2. 检索是成本控制的根本手段：在企业级问答、代码辅助、合规审查等场景，RAG 能把所需信息压缩到几百 token，显著降低 API 费用。
3. 混合策略更具前景：在极端长文档（如法律条款、技术手册）上，先用向量检索定位相关章节，再进行局部上下文扩展，可兼顾准确性与效率。
4. 监控指标不可忽视：开发者在部署时应实时监测 token 使用、延迟和成本，防止因盲目扩大上下文导致不可预期的费用飙升。

“上下文窗口大了，检索仍然重要。”——作者实验结论

实践建议

• 构建向量索引：使用轻量级的 text-embedding-3-small 或者更强的 text-embedding-3-large，确保每条文档都有高质量向量。
• 设定 Top‑K：根据业务需求调节检索返回条数，常规问答 3‑5 条已足够。
• Prompt 结构化：在 RAG Prompt 中明确标注来源（如 [Source: Refund Policy]），帮助模型聚焦。
• 成本模型：以每百万 token $2.5 为基准，定期评估 RAG 与全量填充的费用比，及时切换策略。

通过上述实验与分析，可见 选择性检索是大模型落地的必备利器，而“全量填充”只能在极小规模、低成本实验中勉强使用。