LongRAG:利用长上下文大语言模型提升检索生成效果

LongRAG:智谱联合清华和中科院推出的双视角鲁棒检索框架 LongRAG是由智谱、清华大学和中国科学院联合推出的双视角鲁棒检索增强生成框架,专为长文本问答设计。该框架通过混合检索器、LLM增强信息提取器、CoT引导过滤器和LLM增强生成器等组件,有效解决了长文本问答中的全局上下文理解和事实细节识别难题。LongRAG在多个数据集上表现优异,提供了自动化微调数据构建管道,增强了系统的“指令跟随”能力和领域适应性。 阅读详情
AI摘要

本文介绍了LongRAG框架,它利用长上下文大语言模型增强开放域问答任务中的检索生成。该框架通过长检索单元、长检索器和长答案生成器协同工作,解决了传统RAG框架的局限性。实验表明,LongRAG在检索和问答任务中表现出色,虽有依赖长文本Embedding模型等局限,但仍为RAG领域提供了新方向。

目录

一、前言

二、LongRAG

三、实现原理

3.1、LongRAG 的三大核心组件

3.2、Long Retriever: 粗粒度召回,化解检索压力

3.3、Long Reader: 深度理解,精准提取答案

四、检索结果

五、问答结果

六、未来展望

七、总结


一、前言

前面我们已经介绍了多种检索增强生成 (RAG) 技术,基本上在保证数据质量的前提下,检索增强生成(RAG)技术能够有效提高检索效率和质量,相对于大模型微调技术,其最大的短板还是在于有限的上下文窗口限制。因为传统的 RAG 框架普遍依赖"短检索单元",这一局限性严重制约了模型的性能表现。

传统的短检索单元就像在浩瀚的图书馆中只能借阅残缺的书页,难以获取完整信息。这种局限性给精准高效的答案提取带来了两大挑战:

1)检索器需在海量数据中精确定位包含答案的段落,犹如大海捞针。这不仅加重了检索器的负担,还需要复杂的重排序机制来筛选有用信息,极大地降低了系统效率。

2)受输入长度限制,传统方法只能截取文档部分内容,导致信息丢失和语义不完整。这种"盲人摸象"式的信息获取方式严重影响了答案的准确性和全面性。

幸运的是,长上下文大语言模型(LLM)的蓬勃发展为打破这一瓶颈带来了新的希望。在此背景下,LongRAG 应运而生。它突破了"短检索单元"的限制,赋予阅读器处理超长文本的能力,实现了对"整本书"信息的全面把握。这种创新设计不仅减轻了检索器的负担,还有效避免了信息丢失,从根本上提升了答案的召回率和准确性。

接下来,我们将深入探讨 LongRAG 框架的具体设计和实现细节,并分析其在开放域问答任务中所展现的巨大潜力。通过这种新型框架,我们有望在信息检索和知识生成领域开辟新的前景。

二、LongRAG

为了克服传统 RAG 框架的局限性,最近来自滑铁卢大学的研究团队 Ziyan Jiang、Xueguang Ma 和 Wenhu Chen 在他们的论文《LongRAG: Enhancing Retrieval-Augmented Generation with Long-context LLMs》[1]中提出了一个创新的框架——LongRAG。其核心目标是利用长上下文大语言模型 (LLM) 增强开放域问答任务中的检索增强生成。LongRAG 的设计理念是平衡检索器和“答案生成器”之间的工作量,提高答案召回率,并减轻检索器的负担。

具体来说,LongRAG 主要包含以下几个关键创新点:

  • 长检索单元: 不同于传统的短检索单元,LongRAG 将维基百科等知识库处理成更长的语义单元, 比如整篇文章甚至多篇文章, 从而提供更完整的信息, 避免信息片段化带来的理解偏差。
  • 长检索器: LongRAG 使用能够处理长文本输入的检索器, 从预处理后的知识库中检索与问题相关的长检索单元, 减轻了传统检索器需要精准定位答案片段的压力。
  • 长答案生成器: LongRAG 利用强大的长上下文 LLM 作为“答案生成器”, 使其能够 "阅读" 由长检索单元提供的完整信息, 并生成更准确、 更全面的答案。

为了进一步优化答案提取过程, LongRAG 采用了两轮方法:

  • 第一轮: 将长检索上下文和问题连接起来作为输入, 让长“答案生成器”生成一个初步的、 可能比较冗长的答案。
  • 第二轮: 使用少量的上下文示例 (例如8个) 来引导长“答案生成器”从第一轮生成的答案中提取最重要的部分, 最终得到简洁准确的答案。

通过长检索单元、 长检索器和长“答案生成器”的协同工作, LongRAG 实现了高效的答案提取, 并在实验中取得了显著的性能提升, 无需依赖复杂的重排序机制。 LongRAG 的提出证明了将 RAG 与长上下文 LLM 相结合的巨大潜力, 为开放域问答系统的发展提供了一种新的思路。

传统的 RAG 在短检索单元上运行,检索器需要扫描大量的单元才能找到相关的部分。相比之下,LongRAG 在长检索单元(长 30 倍)上运行。检索器的负载要少得多,这显著提高了召回率。LongRAG 充分利用长上下文语言模型(阅读器)的能力来实现强大的性能。

三、实现原理

LongRAG 是一种全新的检索增强生成框架,重点解决传统RAG框架中检索器和阅读器之间工作负载不平衡的问题。传统RAG框架通常使用短文本作为检索单元,例如100字左右的段落,这使得检索器需要在庞大的语料库中寻找“针尖”(即包含答案的确切短文本单元)。相反,阅读器只需从检索到的短文本单元中提取答案,工作量相对较轻。这种“重”检索器和“轻”阅读器的不平衡设计会导致性能欠佳。

为了缓解这种不平衡,LongRAG提出了“长检索器”和“长阅读器”的概念,并围绕着4K词的检索单元进行

LongRAG: A Dual-Perspective Retrieval-Augmented Generation Paradigm for Long-Context Question 论文 摘要: 长上下文问答(Long-Context Question answer, LCQA)是一项具有挑战性的任务,其目的是对长上下文文档进行推理,从而得到问题的准确答案。现有的用于LCQA的长上下文大型语言模型(llm)经常与“迷失在中间”的问题作斗争。检索增强生成(RAG)通过提供外部事实证据缓解了这一问题。然而,它的分块策略破坏了全局的长上下文信息,并且由于大量的噪声,它在长上下文中的低质量检索阻碍了llm识别有效的事实细节。为此,我们提出了LongRAG,一个通用的、双视角的、健壮的基于llm的LC 阅读详情

相关推荐

25个RAG模型选型实战手册:从数据特征到工程落地

RAG(检索增强生成)是一种让大语言模型实时调用外部知识的架构范式,其核心在于检索、重加工与生成三环节的协同优化。不同于理论科普,工程落地的关键在于匹配真实业务约束:非结构化文档需多模态RAG支持版面理解,高频更新数据依赖流式索引,边缘设备则要求轻量化嵌入与哈希检索。当前主流方案已超越简单向量召回,涵盖混合检索(BM25+稠密向量)、查询扩展(HyDE)、自我反思(Self-RAG)及领域专用架构(如LegalRAG、DocQuery-RAG)。本文聚焦2024年经生产验证的25个RAG模型,按基础层、增强

weixin_33785108的博客 433

LongRAG: Enhancing Retrieval-Augmented Generation with Long-context LLMs

在传统的RAG框架中,基本检索单元通常很短。像DPR这样的常见检索器通常处理100个单词的维基百科段落。这样的设计迫使检索器在大型语料库上搜索以找到“针”单元。相比之下,读者只需要从检索到的简短单元中提取答案。这种不平衡的“重”检索器和“轻”读取器设计可能导致次优性能。为了缓解这种不平衡,我们提出了一个新的框架LongRAG,由“长检索器”和“长阅读器”组成。LongRAG将整个维基百科处理成4Ktoken单元,比以前长了30倍。通过增加单元大小,我们将总单元从2200万个显著减少到600万个。

c_cpp_csharp的专栏 611

LongRAG: 突破长文本理解的新范式

在人工智能飞速发展的今天,大型语言模型(LLM)已经在多个领域展现出惊人的能力。然而,在处理长文本问答任务时,它们仍然面临着不少挑战。最近,来自中国科学院、清华大学等机构的研究团队提出了一个创新性的解决方案 - LongRAG系统。这个系统巧妙地解决了现有技术的局限性,为长文本智能问答开辟了新天地。

步子哥的博客 256

LLM应用架构之检索增强(RAG,retrieval-augmented generation)的缘起与架构介绍

原创 ullyAI工程化收录于合集#领域技术13个#LLM应用架构3个动手点关注本文是LLM应用架构系列的第一篇,将介绍LLM应用开发里最常见的一种架构模式RAG( Retrieval Augmented Generation),它被广泛应用于知识问答,智能助手等常见LLM应用场景中。在后续文章中还将介绍该模式落地实际过程中的一些常见问题及改进思路,欢迎关注“AI工程化”,持续为大家更新。

具身机器人和通用AI 6722

(17-6-04)检索增强生成(RAG):长文本检索器+多向量检索器

为每个文档创建一个摘要,然后为摘要文本生成一个向量。例如下面是一个使用MultiVectorRetriever生成文件摘要并为摘要文本生成向量的例子。

码农三叔 1678

【愚公系列】《AIGC辅助软件开发》041-如何使用 AI技术提升工作效率:AI辅助软件架构师实践

在数字化转型的浪潮中,软件架构师作为技术团队的核心,承载着系统设计与架构优化的重要责任。然而,随着项目复杂度的增加和技术环境的变化,架构师面临着前所未有的挑战。幸运的是,人工智能(AI)技术的迅猛发展为这一行业带来了新的机遇,帮助架构师提升工作效率、优化决策过程,并改善团队协作。本文将深入探讨AI如何辅助软件架构师的实际工作,具体分析AI在需求分析、架构设计、代码生成、测试和优化等环节的应用。

愚公智库 15万+

NX二次开发(python)-坯料尺寸(一)

一般在产品制造过程中,往往要判断一个模型在出模方向上的最小包容盒尺寸,在NX中可以用坯料尺寸命令实现,当然也有相应的代码实现,这或许可以帮助我们实现一些产品的坯料尺寸批量输出,节省人力。

dasfanfan的博客 816

贴片二极管SOD封装详解:SOD-123/323/523尺寸焊盘设计要点

表面贴装技术中,二极管封装尺寸直接决定PCB布局与焊接可靠性。SOD封装作为小外形二极管的主流形态,其SOD-123、SOD-323、SOD-523三种规格分别对应不同的功耗与占板面积权衡。理解封装尺寸、焊盘设计计算逻辑和钢网开窗原理,是避免立碑、虚焊等工艺缺陷的关键。在可穿戴设备、电源保护等空间受限场景中,合理选择封装不仅能优化散热路径,还能提升量产良率。本文从焊盘计算、工艺要点到选型策略,全面解析SOD封装的工程实践。

weixin_42520780的博客 301

6、Cocos2D游戏开发:精灵添加与角色实现

本文详细介绍了在Cocos2D游戏开发中如何添加背景精灵和玩家角色精灵。通过创建GameScene场景、组织项目资源、使用多分辨率图像适配不同设备,并深入讲解了将角色拆分为上下半身以实现更真实瞄准效果的原理。文章还解析了Cocos2D的图像搜索机制、锚点概念及其应用,以及如何通过父子节点关系管理复合角色。最终实现了猎人角色在场景中的正确显示与定位,为后续动画和交互功能打下基础。

e3f4g5的博客 90

第一章 EB安装

1.DemoWorkspace 是基于EB当前组件配置下的例程,包含了启动文件和中断服务函数以及组件demo。2.Mclsar 下存放的是EB的插件包和静态MCAL的驱动文件。

舊梦的博客 1956

Oracle EBS Interface/API(43) -自定义AP发票状态说明API

在某项目,客户需求获得AP发票的状态说明,例如对账系统或者某些报表。由于标准系统未提供状态说明,需要通过AP发票的标准Form获得相关业务逻辑,然后自定义AP发票状态说明API。

陈显平的专栏-Oracle EBS 605

YOLOv11改进策略【损失函数篇】| Shape-IoU:考虑边界框形状和尺度的更精确度量

本文记录的是改进YOLOv11的损失函数,将其替换成Shape-IoU。现有边界框回归方法通常考虑与之间的几何关系,通过边界框的相对位置和形状计算损失,但忽略了边界框本身的形状和尺度等固有属性对边界框回归的影响。为了弥补现有研究的不足,Shape-IoU提出了一种关注边界框本身形状和尺度的边界框回归方法。

Limiiiing的博客 4595

RK3588 C++ MeloTTS 推理

本文介绍了基于RK3588平台和RKNN工具链实现的端侧语音合成(TTS)系统。该系统支持中英文混合输入处理,通过自动合并英文单词、转换标点符号等方式预处理文本,并将其转换为音素和声调序列。核心推理流程包含编码器、中间处理和解码器三个阶段:编码器将音素序列转为隐藏状态,中间处理调节音调和语速,解码器生成最终波形。代码示例展示了输入数据设置和模型推理过程,利用RK3588内置NPU实现高效语音合成。该系统展现了在边缘计算设备上实现复杂AI任务的能力。

J。 199

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

C# WinForm 基于DirectShow.dll编写的程序,可边预览边保存视频,音频和图片

基于微软的DirectShow.dll的二次开发1.自动识别连接的摄像头跟麦克风且可以对其进行选择(默认选中第一个)2.可录制wmv和avi两种格式的视频并且都带有音频,avi可以录制的分辨率和帧数进行选择,wmv默认进行了淸晰度优化如不喜欢可去除代码中有相关提示3.可在预览点开之后进行拍照,也可边录制视频边拍照4.添加了视频和音频的压缩功能(酌情使用)这次二次开发发现C#对DirectShow的相关信息太少,这次做完也不敢藏私共享出来,还望大家指正

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

上一篇: Cognita:一款面向生产环境的开源、模块化 RAG 框架
下一篇: LightRAG:高效构建和优化大型语言模型应用的 PyTorch 框架
技术狂潮AI
博客等级 码龄3年 1282粉丝 137原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

技术狂潮AI

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值