更大的上下文窗口为什么让RAG变得更重要而非更多余

倘若模型能够读取完所有的相关内容，那么检索增强生成 就此不再具备存在的必要性了，开发者只需将整个代码库及诸多年月生成的聊天记录统统放置到prompt之中，进而促使模型来做自己完成安排，所以人工智能行当耗费掉好多年的时间力图追寻更大的上下文框架窗口，具体是从4K提升到32K，再提升到128K，最终提升到1M tokens。

然而哦,当实实在在于生产环境当中这般去做之际呢,就出现了状况,缘由是答案变得更差了。

在不少实际系统中，更大的上下文窗口反而拖累了模型表现。

问题在于语言模型处理信息的方式这点儿上，LLM 依靠注意力机制来给不同概念分配合适权重，然而模型容量尽管在不断增长，但无关上下文的密度一旦提升，注意力分配的可靠性就会快速衰减。噪声进入之后，两个架构层面的故障跟着就出现了，即注意力稀释与检索崩溃。

注意力稀释

要是想明白注意力稀释，那就得回到模型读取prompt的数学机制那儿去，LLM得把注意力分派到输入的每一个token上，是这样的。

要是处于正在去查询其中一条团队工作空间内里的那个特定决策记录的这种情况。包含答案的那一段文字它仅仅只有一段，然而其周围围绕着五十段完全是毫不相关没联系的闲聊以及自动化系统告警。模型它需要在从数学所具备的那些个意义上来判定到底哪些内容是重要的：当上下文规模一旦变得很大的时候，信噪比也就随之塌了下来。

以一个小上下文的场景来做对照，存在一个 5K token 的窗口，其中有 200 token 的相关信息，信号占比为 4%，此时模型能够轻松锁定事实。再换到 200K token 的窗口，在这个窗口里同样是 200 token 的相关信息，然而信号占比却降到 0.1%。

不计其数涉及无关token评估的计算资源被大量耗用、消耗掉了，如此一来，分配给真正具备有用价值信号的权重便随之被渐渐削弱、变弱了。直接由此引发、导致的后果是输出质量出现下滑：模型会遗漏事实、漏掉事实，给出错误答案，或者运用幻觉手段去填补那些它没能可靠提取到的信息空白之处。

检索崩溃

上下文中的窗口，在足够大了之后，一种常见的诱惑出现了，那是直接要放弃构建检索管道，还要把prompt设置成全部可用的文档。

这与一条基本设计原则相违背，这条原则是，LLM在prompt经过精心挑选的时候，会展现出最佳表现。

标准RAG架构，刻意将上下文限定成具有最高相关性的top - K个片段，约束本身属于特性，它抑制噪声，维持信号密度，迫使模型在有限范围之内进行集中推理，一旦越过过滤步骤，最终回答的质量差不多肯定会降低。

"迷失在中间"效应

上述现象并非单纯的工程直觉，情况它是经由实验验证得出的那种研究的结论，那种对AI后端的设计方式有着直接影响的结论。2023年，来自斯坦福大学的研究人员，在论文《Lost in the Middle: How Language Models Use Long Contexts》中正式描述了这一效应，同时还有来自加州大学伯克利分校的研究人员，以及来自Samaya AI的研究人员。

研究显示出一条“U型”性能曲线，当相关信息于输入上下文的起始处（首因效应）或者结尾处（近因效应）出现时，准确率是最高的，而放置于中间位置时，模型的检索以及推理能力会显著下滑，就算token上限足够大也不会有所不同。更为棘手的是，随着prompt里无关文档的增多，处于中间位置信息的可用性会持续变差，真正具备价值的内容就如同被隐匿于干草堆之中。

RAG 为什么依然更有效

RAG 并非仅仅是被用来绕开上下文长度限制的补丁，它的关键价值在于精准的信息挑选，在于精确的信息筛选。

一套完善的RAG系统具备清晰的流程，先是接收用户发送的查询，紧接着在embedding数据库里开展向量搜索，随后从中提取top - K个片段，最后才将数据传送给LLM。当语言模型参与进来面对的是相关性最强、密度最为集中的内容，并非是200K token的繁杂数据，而是1K到2K token的高信号事实。由于注意力聚焦在此范围内，回答的准确性、可靠性以及响应延迟均会得到实质性提升。

RAG + 大上下文

解决方案并非处于二者选其一的情况。现代人工智能系统将精确检索与大上下文窗口组合到一块儿，借助前者确保信号质量，通过后者容纳旧模型无法放置下的多文档推理。

标准的生产管道是这样的：

接纳用户给出的查询，于向量数据库里查找40个宽泛关联的片段，运用Cross - Encoder重排序模型针对这些片段开展二次评分，借着新的相关性分数挑选出最优的5至7个片段，把筛选之后的上下文传送给LLM。

Python 实现如下：

 # 1. 广泛检索（通过向量搜索实现高召回率）  
 candidates = await vector_db.search(query=user_query, top_k=40)  
 # 2. 精确过滤（通过Cross-Encoder实现高精确率）  
 reranked_results = await reranker.rank(query=user_query, documents=candidates)  
 # 3. 筛选上下文窗口  
 best_chunks = reranked_results[:7]  
 # 4. 生成专注的、高信号的响应  
 response = await llm.generate(prompt=user_query, context=best_chunks)

那些大个数目的上下文窗口所具备的益处在于，当去传递那些密度颇高的片段之际，就不用再去忧心token被截断的状况出现了。它所着手解决的问题是容量方面的瓶颈，而相关性的相关问题依旧得要借助检索管道去实施处理的。

更大的上下文窗口解决的是容量，不是相关性。

语言模型，是那种极为出色的推理引擎，然而呢，其前提是，输入的应当是经过严格过滤的。要是把所有的各种东西都一股脑地倒进去，那么换来的结果只是，那种不可预测的性能衰退。

检索的下一步

纯粹只是关于容量来进行的竞赛，已然来到了收益呈现递减态势的阶段，下一代人工智能系统的重心眼下正在发生转移，具体表现为，要有更好的检索算法，要有更精细的Cross - Encoder排序，还要有智能化的上下文压缩，人工智能架构里真正的瓶颈，从来都不是能够往里面塞进多少token，而是要在源头处寻找到应当往里塞进去的那些信息。

更大的上下文窗口没有取代 RAG。

与之完全相反，优秀的检索已然变得前所未有的重要起来。于AI系统当中，信息的数量与信息的质量属于两码事。

请你明确具体需求哦，比如对这个 URL 相关内容进行改写之类的，仅给出一个链接没办法进行针对性改写呢。

by Tanmay Bansal

相关标签： # RAG # 上下文窗口 # 注意力机制 # 检索增强生成 # 信息质量