文章强调了检索增强生成RAG系统中检索和生成之间的处理环节对系统性能的关键影响。指出大语言模型对上下文位置敏感首因和近因效应需要通过重排序、去重、矛盾处理等优化检索结果。合理管理token预算使用清晰的提示词架构并注意检索指标无法反映的失败模式。生产级系统应采用混合搜索、重排序、控制文本块数量等最佳实践真正决定模型是否有效利用检索内容的是检索和生成之间的增强层。“检索独占了所有的聚光灯但真正决定系统在暗处成败的却是检索与生成之间的环节。”检索效果堪称完美。返回了五个文本块相关性分数均在0.85以上恰好是用户需要的政策文档。答案就在第三个文本块中。但回复遗漏了关键细节。这不算是完全的幻觉。更像是模型浏览了一遍而没有仔细阅读。你调试检索器调优嵌入模型调整文本块大小。但检索本身从来不是问题所在。问题出在其他地方这些文本块是如何被组合成提示词的。它们出现的顺序如何。它们周围有多少上下文信息。模型是否真的能够利用你检索到的内容。这是没人警告你的那一层检索和生成之间发生了什么。你的向量数据库传递相关文本块。你的大语言模型生成回复。中间的增强层决定了你的检索是否真的有意义。位置仍然重要大语言模型不会均匀地读取上下文。斯坦福大学和Meta的研究人员在2023年发现了这一点。他们将关键事实埋藏在检索文档的不同位置然后测量准确率。结果是什么一条U形曲线。模型对最先出现的内容首因效应和最后出现的内容近因效应关注强烈。中间的部分被忽视了。这种情况有所改善。GPT-4o和Claude 3.5 Sonnet在位置处理上不像GPT-3.5-Turbo那样吃力。这种效应并未消失。它被削弱了但并未消除。架构原因依然存在Transformer的注意力机制通过softmax归一化和注意力sink的quirks仍然对早期token分配了不成比例的权重。所以把你最好的文本块放在最前面。这不费吹灰之力还能防范位置效应。无论你使用哪种模型都有效。RAG提示词示意图文本块3具有最高的相关性分数0.91但位于第3位。最优位置将其放在首位。所有插图均由作者提供解决方案重新构建你的提示词。将最高相关性的文本块移到开头。将次要上下文放在中间。对于复杂查询考虑在末尾添加摘要。重排序算法最佳文本块保持在位置1首因效应第二好的移到末尾近因效应其余填充中间部分。2023年研究中的U形注意力曲线。虽然较新的模型使这条曲线趋于平缓但这种模式并未完全消失。检索之后实际发生了什么大多数RAG教程展示的是一个简洁的图示查询 → 检索器 → 大语言模型 → 回复检索器和大语言模型之间的箭头隐藏了整整一个处理管道。其实那个箭头隐藏了很多东西你的检索器返回候选结果通常是按嵌入相似度排名前20-50的文本块。那些原始结果存在问题。有些文本块重叠重复相同的信息。有些相互矛盾。有些是基于关键词匹配但并不能真正回答你的问题。将它们直接输入大语言模型会浪费token并引入噪声。处理管道将这些原始候选结果转换为优化的上下文。它通过相关性阈值进行过滤。它移除近似重复项。它使用比嵌入相似度更能理解查询-文档关系的模型进行重排序。它处理矛盾。它扩展有前景的文本块以包含周围上下文。然后最终它将所有内容组装成大语言模型实际可以使用的提示词结构。跳过这些步骤中的任何一个你都是在放弃质量。检索和生成之间的隐藏管道50个候选文本块通过过滤、重排序和去重缩减为4-6个优化后的文本块。重排序是收益最大的地方。向量相似度快速但浅层。它比较文档的压缩表示为了速度牺牲了细微差别。交叉编码器重排序器通过完整的Transformer注意力机制一起处理你的查询和每个文档捕捉嵌入遗漏的关系。有效的模式广泛检索前50个候选精确重排序保留前5个。Pinecone的基准测试显示这种两阶段方法比单纯的向量搜索提高了14-30%的检索质量。生产系统显示的数字也类似。双编码器检索快速但浅层。交叉编码器重排序缓慢但深层。两者结合给你速度和精度。对于重排序模型Cohere Rerank可以很好地处理大多数用例。如果你不是所有文档都是英文它的 multilingual 特性会有所帮助。对于自托管部署BAAI的bge-reranker-ver2-m3在不产生API成本的情况下提供了相当的质量。去重解决了一个你可能不会注意到直到它给你带来代价的问题。使用滑动窗口的文本分块策略会产生重叠。检索五个文本块其中三个可能包含相同的段落。这不仅仅是浪费token。重复可能使模型偏向于过度强调重复的内容。最大边际相关性MMR很好地处理这个问题。理念是你添加的每个新文本块应该是相关的但也应该与你已经选择的内容不同。没有理由包含三个说同样事情的文本块。矛盾处理更难。当你的检索器返回相互矛盾的文本块时模型应该怎么做系统经常自信地引用错误的来源因为它在上下文中最先出现。对于时间矛盾解决方案是元数据。包括时间戳并在新内容涵盖相同领域时过滤旧内容。LlamaIndex有一个EmbeddingRecencyPostprocessor可以自动完成这个任务。对于权威冲突对你的来源进行加权。官方文档应该覆盖用户生成的内容。主要来源应该击败摘要。明确的元数据标签让你在管道中实现这些偏好。当存在合法的模糊性时诚实的方法是用清晰的归属呈现两种观点。强迫虚假的共识会产生听起来自信但会误导用户的回复。没人教你的Token预算上下文窗口有上限。这个你知道。但在这些限制内的预算分配是没人教的部分。128K的上下文窗口听起来很大直到你考虑到所有竞争空间的东西。你的系统提示词需要空间。用户的查询占用token。你需要为回复本身预留容量。剩下的才是你检索上下文的实际预算。一个合理的分配系统提示词1500 token用户查询500 token输出预留4000 token。在128K模型上这为上下文留下了约122,000个token。足够多了对吧理论上是的。在实践中更多并不总是更好。即使改进的长上下文模型在某个点之后也存在收益递减额外的文本块添加的是噪声而不是信号。模型必须筛选更多内容才能找到相关的内容。Token分配现实只是因为你能够填满128K并不意味着你应该这样做。质量优先于数量。最佳点通常是大多数查询的4-6个文本块。在此之后每个额外的文本块都与已包含的文本块竞争相关性。除非新文本块包含真正独特的信息否则它会稀释而不是丰富内容。当你需要更多上下文时压缩胜于截断。微软的LongLLMLingua实现了4倍压缩同时在问答基准测试上提高了21%的准确率。它使用困惑度对token重要性进行评分并保留与查询相关的内容同时丢弃填充内容。压缩后的上下文包含的文本更少但信号更多。替代方案RECOMP提供提取式压缩选择关键句子和抽象式压缩生成摘要。任何一种方法都优于naive截断后者基于位置而非重要性丢弃内容。压缩在处理相关信息分散的长文档时效果最好。对于检索场景良好分块的内容保持在4-6个高质量文本块内比压缩更大的集合效果更好。真正有效的提示词架构你如何构建最终提示词比大多数教程承认的更重要。基本架构有两层建立规则的持久系统提示词以及注入查询时上下文的动态用户提示词。混合这些层会导致不一致。将它们保持分开。你的系统提示词应该定义• 角色和人格“你是某公司的技术支持助手…”• grounding规则“仅使用提供的上下文回答。如果上下文不包含答案请说明。”• 格式规范“使用[1]、[2]符号引用来源”• 拒绝模式“不要回答关于竞品的问题”此提示词在查询间保持不变。规则普遍适用。你的用户提示词应该包含• 检索到的上下文清晰界定• 实际的用户查询• 任何特定于查询的指令分隔符的选择影响解析准确率。XML标签在Claude和受过结构化数据训练的模型上优于markdown和纯文本。我使用、和作为边界。一个效果良好的结构如下Naive排序将关键信息埋在注意力死角。优化位置利用首因效应和近因效应。documentsdocument sourcepolicy-handbook.pdf page12[chunk content here]/documentdocument sourcefaq-updated-2024.md[chunk content here]/document/documentsquery[users question here]/query源元数据启用引用。页面编号让用户能够验证。清晰的结构帮助模型从指令中解析内容。你应该包含什么元数据源标题是的。时间敏感内容的时间戳是的。如果需要引用页面编号是的。你应该排除什么内部相关性分数、文件系统路径、编码信息、调试数据。这些消耗token但不帮助生成。如果元数据不能帮助模型更好地推理就不要包含。日志中不显示的失败良好的检索指标不能保证良好的回复。注意检索成功后发生的失败模式。引用幻觉是偷偷摸摸的。回复听起来权威包含括号引用但完全错误地说了哪个来源说了什么。事实可能是正确的。但归属不是。这是因为引用准确性和事实准确性是独立的。模型可以从上下文中提取正确的信息同时如果这个词甚至适用于大语言模型的话误记它来自哪个文本块。生产系统需要验证将具体的主张追溯到具体的来源。上下文中毒是我称之为当低相关性文本块挤掉好的文本块时。你的检索器返回十个文本块。七个是中等水平。三个正是你需要的。那七个稀释了信号不是通过位置而是通过音量。模型试图使用一切而不是找到最好的部分。更严格的相关性阈值有帮助。限制你的文本块数量也有帮助。如果你不确定宁可要更少的好文本块也不要更多平庸的。当你的索引缺乏新鲜度信号时就会出现时间陈旧。检索器返回一个2022年的政策文档因为它完美地匹配了查询术语。那项政策在2024年被替换了。但你的管道不知道这一点。基于元数据的过滤可以捕获这个但前提是你索引时间戳并以新鲜度感知进行查询。对于快速变化的领域考虑将新鲜度作为与相关性并列的排名因素。推理碎片化扼杀多跳查询。用户提出的问题需要连接来自多个文本块的事实。每个文本块都检索成功。模型无法合成它们因为它们在提示词中语义上相距甚远缺乏桥接上下文。分层文本分块在这里有所帮助。LlamaIndex的句子窗口检索在检索时嵌入单个句子但在查询时扩展到周围的段落。桥接上下文自动随之而来。真正有效的方法在构建生产级RAG系统之后这些模式是经得起检验的检索混合搜索结合BM25关键词匹配和密集嵌入通过Reciprocal Rank Fusion合并。这能捕获任一方法单独会遗漏的查询。Anthropic关于Contextual Retrieval的研究显示混合方法减少了67%的检索失败。重排序云部署用Cohere Rerank自托管用bge-reranker。始终重排序。延迟成本是值得的。去重MMR的lambda值约为0.6。你想要相关性但也想要多样性。文本块数量大多数查询4-6个。只有当你确实需要跨多个来源综合时才更多。位置策略最佳文本块放在前面。支撑上下文填充中间。如果有空间末尾放摘要。利用提示词的两端。提示词结构XML标签用于上下文界定。包含源和时间戳元数据。排除内部管道数据。评估将检索指标精确率、召回率与生成指标忠实度、 groundedness分开。当回复失败时你需要知道哪个组件失败了。这不是唯一有效的方法。但它可以防止你调试错误的层。赚取其价值的层大多数RAG讨论聚焦于检索。这是有道理的。如果你没有检索到正确的文本块下游的任何东西都无法拯救你。但与增强相比检索是一个已解决的问题。向量数据库是成熟的。嵌入模型很好而且越来越好。重排序正在成为标准。检索层有明确的最佳实践和可衡量的基准。增强层检索和生成之间的空间更年轻且更混乱。位置效应、压缩策略、提示词架构、在检索指标中不显示的失败模式。纸上看起来相同的系统在这里在生产中分道扬镳。当你的RAG系统表现不佳时抵制首先责备检索器的本能。检查你把文本块放在提示词的什么地方。检查你是否包含了太多上下文。检查你的提示词结构是帮助还是阻碍模型解析相关信息的能力。检索可能没问题。真正决定模型是否真正使用你找到的东西的是接下来发生的事情。AI大模型从0到精通全套学习大礼包我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。只要你是真心想学AI大模型我这份资料就可以无偿共享给你学习。大模型行业确实也需要更多的有志之士加入进来我也真心希望帮助大家学好这门技术如果日后有什么学习上的问题欢迎找我交流有技术上面的问题我是很愿意去帮助大家的如果你也想通过学大模型技术去帮助就业和转行可以扫描下方链接大模型重磅福利入门进阶全套104G学习资源包免费分享01.从入门到精通的全套视频教程包含提示词工程、RAG、Agent等技术点02.AI大模型学习路线图还有视频解说全过程AI大模型学习路线03.学习电子书籍和技术文档市面上的大模型书籍确实太多了这些是我精选出来的04.大模型面试题目详解05.这些资料真的有用吗?这份资料由我和鲁为民博士共同整理鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。所有的视频由智泊AI老师录制且资料与智泊AI共享相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念通过动态追踪大模型开发、数据标注伦理等前沿技术趋势构建起前沿课程智能实训精准就业的高效培养体系。课堂上不光教理论还带着学员做了十多个真实项目。学员要亲自上手搞数据清洗、模型调优这些硬核操作把课本知识变成真本事如果说你是以下人群中的其中一类都可以来智泊AI学习人工智能找到高薪工作一次小小的“投资”换来的是终身受益应届毕业生无工作经验但想要系统学习AI大模型技术期待通过实战项目掌握核心技术。零基础转型非技术背景但关注AI应用场景计划通过低代码工具实现“AI行业”跨界。业务赋能 突破瓶颈传统开发者Java/前端等学习Transformer架构与LangChain框架向AI全栈工程师转型。获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】