我们不再用「能塞进 prompt 多少个 token」来衡量检索质量。
长上下文模型出现后，很多人都做了同样的假设——如果 LLM 能读 128K token，检索似乎就没那么重要了。何必费心筛选文档，让模型直接读全部不就行了？
听起来合理，但实践中完全不是这么回事。
更多上下文，更差的答案
想象一下，你问内部助手：「我们为什么放弃了微服务？」
为什么我们放弃了微服务？
检索返回三十份相关文档——一份架构决策记录（ADR）、几个 Jira 工单、Slack 讨论、会议记录、术语页面——每份都和问题相关，但几乎没有任何一份真正回答了问题。
真正的决策在一个几个月前写的 ADR 中。它解释了团队规模、延迟、部署复杂度、运营成本等权衡。但这份文档和查询「不像」——它没有重复相同的词汇，甚至不怎么提到「微服务」。
于是它被埋没了。
模型现在收到了三十份相关文档，做了一件语言模型非常擅长的事：生成一个连贯的解释。
但问题是，连贯不等于忠实。
模型不是找回原始的决策，而是从检索文档的重复主题中「合成」了一个答案。听起来合理，但不是当初做出的那个决定。
更大的窗口修不好检索
研究已经表明模型在处理超长上下文中的信息时会吃力。著名的 Lost in the Middle 论文就是其中最有名的证据。
但我们遇到的问题还要更深一层。有时候答案丢失不是因为上下文太长，而是因为检索阶段无法区分「含有决策的文档」和「仅仅讨论同一主题的文档」。
增加上下文不一定能解决这个问题——有时反而给了模型更多材料去「平均」出一个看似合理但错误的答案。
我们在优化错误的东西
有一段时间，我们把检索当成「填装练习」——能塞进 prompt 多少有用的块？
后来问题变了：这份文档为什么会在这里？它应该在这里吗？它解释的是决策，还是仅仅提到了同一个技术？
这些问题比上下文窗口的大小重要得多。
检索是一个选择问题
最大的转变不是从 8K 到 128K token。而是意识到检索不是把更多信息塞进 prompt，而是选出那几块真正能解释答案的信息。
长上下文窗口非常有用。但它们不能弥补弱检索。甚至可能更糟——它们让弱检索看起来很有说服力，让你以为系统工作得很好，实际上它只是在「编」而不是在「找」。
原文出处：Bigger Context Windows Didn't Make Our RAG Smarter — dev.to
