LLM 上下文窗口的滥用：是时候回归检索质量的本质了
摘要
本文探讨了在利用大型语言模型（LLM）进行 RAG（检索增强生成）时，开发者是否过度依赖增大的上下文窗口来容纳信息，而忽视了提升检索质量的重要性。作者指出，即使上下文窗口增大，注意力机制的计算成本依然存在，过多的检索内容可能稀释关键信息，甚至降低模型性能。文章分析了检索过多、块大小不当、提示词冗余等常见问题，并强调了端到端衡量词元数量和优化检索策略（如调整 top_k）的必要性。作者呼吁关注模型处理的向量数量，并分享关于词元预算、检索精度衡量及上下文窗口有效性的实际调优经验。
正文
在本地和 API 部署的 配置调优过程中，一个值得深思的问题是：随着上下文窗口（）的不断增大，我们是否开始将其视为信息存储库，而非真正的注意力预算？
本质上， 处理文本的流程依然是：文本 → （tokens）→ 嵌入（ embeddings）→ 向量间的注意力机制。每一个额外的都会在注意力机制中与其他向量竞争计算资源。即使上下文窗口变大，注意力机制的计算也并非“免费”，它仍然是有限的计算资源在更多位置上的分配。
在实际的 （Retrieval-Augmented Generation）流水线中，遇到的问题往往并非模型本身的智能不足，而是以下几个方面：
- 检索到过多的文本块（chunks）。
- 文本块的大小设置不当，过大或过小。
- 提示词（prompts）设计不佳，接近或超出上下文限制。
- 指令或内容存在重复或冗余。
实践表明，简单地增加检索到的上下文信息量，有时反而会降低输出的一致性，而非提升。特别是当语义相似但信息量低的文本块稀释了真正高价值的内容时，问题尤为突出。
此外，还存在“中间遗忘”（missing in the middle）现象，即在非常长的提示词中，注意力分布可能不均匀，导致模型在中间部分的信息处理效果不佳。
改变作者看法的关键在于，端到端地衡量整个提示词的构成——系统指令、历史对话以及检索到的文本块——并关注每次请求的总数量。这种细致的分析揭示了上下文信息量是如何迅速膨胀的。
在某些案例中，通过减少 top_k（检索结果的数量）并精简冗余上下文，比更换模型更能显著改善输出质量。
作者对以下几点感到好奇，并希望听取社区的实际调优经验：
- 如何为每次请求进行预算控制。
- 如何衡量检索精度（precision）与 top_k 的关系。
- 何时更大的上下文窗口真正能带来帮助。
- 在扩展上下文窗口之前，是否会对提示词构成进行性能剖析。
我们似乎花费了大量篇幅讨论模型规模和窗口大小，却很少关注每次前向传播（forward pass）中，我们要求模型处理多少个向量。作者期待听到真实的调优经验分享。