大模型并非万能:RAG依然是提高AI系统信息质量的关键

大模型并非万能,RAG依旧重要!本文分析了大token上下文窗口的局限性,强调了RAG在信息筛选方面的核心价值,以及二者结合的必要性。

原文标题:打破误区:大 token 不是万能的,RAG 从未过时

原文作者:数据派THU

冷月清谈:

本文探讨了大语言模型(LLM)中大上下文窗口的局限性,以及检索增强生成(RAG)方法的核心价值。尽管增大上下文窗口似乎能让模型处理更多信息,但实际应用中却可能因注意力稀释和检索崩溃导致性能下降。“迷失在中间”效应进一步验证了这一问题,即模型在处理位于上下文中间的信息时准确率明显降低。RAG 的优势在于其精确的信息筛选机制,通过向量搜索和重排序,将高相关性的信息片段提供给 LLM,从而提高回答的准确性和可靠性。因此,未来的AI系统应将精确检索与大上下文窗口相结合,侧重于优化检索算法、精细化排序和智能化上下文压缩,RAG 在 AI 系统中变得前所未有地重要。

怜星夜思:

1、文章提到“迷失在中间”效应,那么在实际应用中(例如撰写长篇文章或报告),我们应该如何优化信息呈现方式,才能更好地利用大模型的处理能力,避免关键信息被忽略?
2、文章中提到了 RAG 结合大上下文窗口的优势,那么在选择 top-K 个片段时,K 值应该如何确定?过大或过小分别会带来什么问题?
3、文章提到更好的检索算法是未来的发展方向,大家认为在检索算法上,除了向量检索和Cross-Encoder重排序,还有哪些潜在的优化方向?

原文内容

图片
来源:DeepHub IMBA
本文约1500字,建议阅读5分钟
本文介绍了大上下文窗口的局限及 RAG 仍具优势的原因。


一旦模型能读完所有内容检索增强生成(RAG)就没有存在的必要了,开发者只需要把整个代码库或者多年的聊天记录塞进 prompt,让模型自行处理,所以AI行业花了好几年追逐更大的上下文窗口: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年,来自斯坦福大学、加州大学伯克利分校和 Samaya AI 的研究人员在论文 《Lost in the Middle: How Language Models Use Long Contexts》中正式描述了这一效应。


研究揭示了一条"U型"性能曲线:相关信息出现在输入上下文的开头(首因效应)或结尾(近因效应)时准确率最高,放在中间位置时模型的检索和推理能力明显下滑,即便 token 上限足够大也不例外。更麻烦的是随着 prompt 中无关文档的增多,中间位置信息的可用性持续恶化,真正有价值的内容等于被藏进了干草堆。


RAG 为什么依然更有效


RAG 从来不只是用来绕过上下文长度限制的补丁,它的核心价值在于精确的信息筛选。


一套成熟的 RAG 系统有明确的管道:接收用户查询,在 embedding 数据库上执行向量搜索,抽取 top-K 个片段,之后才把数据交给 LLM。等语言模型介入时,它面对的只有相关性最高、密度最集中的内容:不再是 200K token 的杂乱数据,而是 1K 到 2K token 的高信号事实。注意力集中在这样的范围上,回答的准确性、可靠性和响应延迟都会有实质改善。


RAG + 大上下文


解决方案不在二选一。现代 AI 系统把精确检索和大上下文窗口结合在一起,用前者保证信号质量,用后者容纳旧模型放不下的多文档推理


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


  1. 接收用户查询。

  2. 向量数据库中检索 40 个宽泛相关的片段。

  3. Cross-Encoder 重排序模型对这些片段做二次评分。

  4. 按新的相关性分数筛出最优的 5 到 7 个片段。

  5. 将筛选后的上下文发送给 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 截断的问题。它解决的是容量瓶颈,相关性的问题仍然需要检索管道来处理。


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


语言模型是出色的推理引擎,但前提是输入经过严格过滤。把所有东西都倒进去,换来的只是不可预测的性能衰退。


检索的下一步


纯容量的竞赛已经进入收益递减的阶段,下一代 AI 系统的重心正在转移:更好的检索算法、更精细的 Cross-Encoder 排序、智能化的上下文压缩。AI 架构中真正的瓶颈从来不是能塞进多少 token,而是在源头找到该塞进去的那些信息。


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


恰恰相反,好的检索变得前所未有地重要。在 AI 系统中,信息量和信息质量是两回事。


by Tanmay Bansal


编辑:于腾凯
校对:刘红利

关于我们

数据派THU作为数据科学类公众号,背靠清华大学大数据研究中心,分享前沿数据科学与大数据技术创新研究动态、持续传播数据科学知识,努力建设数据人才聚集平台、打造中国大数据最强集团军。




新浪微博:@数据派THU

微信视频号:数据派THU

今日头条:数据派THU

还可以试试Prompt engineering结合function calling。在RAG之前,先用一个Prompt让模型分析用户的query,判断需要哪些信息,然后通过function calling调用不同的API或者工具来获取这些信息。这样可以更精准地定位信息来源,避免大海捞针。举个例子,如果用户问“北京今天天气怎么样”,我们可以先让模型识别出用户需要的是天气信息,然后调用天气API获取北京的天气数据,再将这些数据作为上下文输入给LLM。

提升RAG的输入质量,我觉得可以考虑以下几个方向: 1. 数据增强:通过同义词替换、回译等方式增加训练数据的多样性,提高模型的泛化能力。 2. 查询改写:对用户query进行改写或扩展,更准确地表达用户意图,提高检索的准确率。 3. 知识图谱:利用知识图谱对检索结果进行过滤和增强,引入更丰富的上下文信息。 4. 上下文压缩:在保证关键信息不丢失的前提下,对检索到的文档进行压缩,减少噪声干扰。

Cross-Encoder跟传统的Bi-Encoder不同,它不是先将query和document各自编码成向量,然后计算向量相似度。而是将query和document拼接在一起,输入到Transformer模型中进行联合编码,直接预测query和document的相关性得分。这样做的好处是可以更充分地考虑query和document之间的语义关系,从而提高排序的准确性。在RAG系统中,Cross-Encoder通常用于对初步检索结果进行重排序,选出最相关的片段,提高最终生成质量。但是计算量也更大,通常只对top-k个结果进行重排序。

这题我会!斯坦福的研究表明,LLM对prompt的开头和结尾最为敏感,所以解决“迷失在中间”的关键在于如何将重要信息“搬运”到prompt的两端。我的建议是,使用summary或者QA的方式,先让模型粗略阅读全文,然后将提取出的关键信息以列表或者问答的形式放在prompt的开头或者结尾。这样既能保证关键信息不被淹没,又能充分利用大模型的推理能力。

我觉得“迷失在中间”效应有点像人看书,重要的信息如果被淹没在大量不重要的信息中,就容易被忽略。避免这个效应,可以尝试以下方法:1)信息前置/后置:重要的信息尽量放在开头或结尾,方便模型快速抓取;2)分段处理:将长文本拆分成小段,逐段输入模型,减少中间信息干扰;3)突出重点:使用粗体、颜色等方式标记关键信息,提高模型对重点的关注度;4)Prompt引导:在Prompt中明确要求模型关注特定部分的信息,引导模型注意力。

简单理解,向量检索(例如用HNSW)是为了快,效果差点没关系,先捞回来再说。Cross-Encoder是为了准,但是慢一点也没关系,反正只需要对前面捞回来的少量结果做精细化计算。一个负责海选,一个负责精选,分工明确!

针对“迷失在中间”效应,我的理解是可以从两个方面入手:一是优化输入,二是优化模型。优化输入方面,可以尝试将关键信息放在prompt的开头或结尾,利用首因效应和近因效应;或者将长文本进行分段处理,逐段输入模型。优化模型方面,可以考虑使用一些专门针对长文本处理的模型架构,或者在模型训练过程中加入对中间位置信息的关注度。当然,RAG方案仍然是最靠谱的,在检索阶段就要做好过滤,交给LLM的都是精华!

从我的角度,可以从源头治理和过程优化两方面入手。源头治理是指,在构建知识库时,就要保证信息的质量,比如进行去重、纠错、信息对齐等处理。过程优化是指,在RAG流程中,可以加入一些自动化工具,例如关键词提取、命名实体识别等,辅助进行信息过滤和增强。更进一步,还可以引入人工审核,对关键信息进行标注和校对,确保万无一失。

Cross-Encoder就像一个精明的裁判,它能更准确地判断哪些选手(检索到的文档片段)和给定的问题(query)最匹配。传统的检索方法(比如向量搜索)就像初赛,先海选出一批可能相关的选手,但水平参差不齐。Cross-Encoder就相当于复赛,它会仔细分析每个选手和问题的契合度,给出更精确的评分,确保最终选出的都是最优秀的选手。简单来说,它通过更复杂的模型结构和计算,提升了RAG系统中信息筛选的准确性。

可以考虑将长文本拆解为多个章节或段落,并在每个章节或段落的开头/结尾处设置明确的“信息锚点”,引导模型在处理过程中更加关注关键信息。此外,利用大模型的总结能力,先让模型对各个章节/段落进行摘要,再将摘要与原文一同输入,或许也能提升关键信息的识别率。

我个人认为,K值不能一概而论,应该和检索算法结合起来考虑。如果检索算法本身就比较精准,能够保证返回的片段相关性都比较高,那么K值可以适当大一些。但如果检索算法不够精准,返回的片段中混杂着大量噪音,那么K值就应该小一些,避免噪音干扰。

我有个大胆的想法,既然模型容易忽略中间信息,那我们能不能人为地给信息分级?比如用标签或者特殊格式标记不同等级的信息重要程度,然后训练一个模型,让它更关注高等级的信息。这可能需要一些定制化的训练,但或许能有效解决问题!