长上下文刚普及那阵子，我们内部有个共识：检索这活要慢慢退场了。窗口都128K了，能捞的都捞进去，模型自己会挑。这个想法特别合理地死掉了——实际跑起来，窗口越大，回答质量反而肉眼可见地变差，不是持平，是变差。
复盘的时候翻到一个挺典型的例子。有人问“为什么我们放弃微服务”，系统捞回来三十份文档：ADR、Jira工单、Slack讨论、会议纪要、词汇表。每一份都在聊微服务，语义上全都沾边。唯一真正记录了当初那个决策的单一ADR文档，被排到很后面——因为它跟查询的词汇重叠太少，向量距离不够近。问题不是模型没看到它，是检索这层就把最该用的那份漏掉了。这个例子我后来反复想，真正的教训不是“检索不够好”这种笼统的感叹，而是：检索和窗口做的事，压根是两个维度的事。
检索解决的是“该看哪几份”，窗口解决的是“这几份能不能都摆上台面”。把检索漏掉的东西塞进大窗口，模型拿到的是二十九份“相关但没答到点上”的材料。它不会说“我不知道”。它会把这些材料里反复出现的主题综合一下，生成一个读起来特别顺的解释——有引文，有出处，逻辑自洽，看起来有据可查。问题是它忠实的是文档里反复出现的主题，不是当初那个原始决策。
这个动作从机制上几乎是不可避免的。说人话就是：模型拿三十份文档做平均——出现频率最高的主题拎出来，拼成一个最像答案的东西。它不是在编，它是在取统计最大公约数。问题是真正的决策往往只存在于一份文档里，平均化把它平均没了。
这里最容易被搞混的是：不是大窗口没用。跨大量文档做综合的时候，窗口大就是有用。可它替代不了检索，它只会放大你喂进去的材料的说服力。弱检索配小窗口，结果虽然烂，但你一眼能看出来它漏了东西；弱检索配大窗口，结果听起来头头是道，你反倒不容易发现问题是出在检索那层。
我们过去一直把检索当成一个打包问题：怎么在有限的窗口里塞进更多有用片段。这个框架从一开始就是错的。检索本质上是选择问题——挑出那少数几份能真正解释答案的片段，而不是塞得越多越好。8K窗口的时代你被迫做选择，因为塞不下；128K的时代你以为不用选了，其实选择这步从没消失，只是被窗口的变大盖住了。你放弃做选择，模型就得替你选，而它选的逻辑只能是“主题出现频率”，不是“哪一份才真的能回答这个问题”。
所以说到底，大窗口不是来救检索的，它是来给检索的漏洞做包装的。检索没做对，窗口再大也只是把错的东西喂得更饱——喂出来的答案还特别像真的，比直接漏掉更难发现。