人工智能咨询培训老师叶梓 转载标明出处

大模型在处理静态知识更新和信息准确性方面仍面临挑战。为了解决这些问题，检索增强型生成（RAG）模型应运而生，它们通过检索文档来辅助语言模型生成更可靠的回答。但现有的RAG研究大多集中在具有明确用户意图和简洁回答的问题场景上。在现实世界中，用户常常会提出宽泛、开放式的查询，这些查询包含多个子意图，并期望得到涵盖多个相关方面的丰富、长形式的答案。针对这一尚未充分探索但非常重要的问题。

来自中国人民大学高瓴人工智能学院的研究者提出了一种新颖的RAG框架——RichRAG，旨在处理用户提出的宽泛、多意图的查询，并提供丰富、全面的回应。这类查询往往需要整合多个相关方面的信息，以充分满足用户的潜在信息需求。

图1展示了一个多方面查询（关于说唱音乐）的例子，比较了传统 RAG（Vanilla RAG）和提出的 RichRAG 在回答丰富性上的差异。Vanilla RAG 提供了一个表面层次的回答，而 RichRAG 则生成了一个包含多个相关方面（如起源、特点和演变）的综合性回答。 

想要掌握如何将大模型的力量发挥到极致吗？2024年10月26日（今晚8点）叶老师带您深入了解 Llama Factory —— 一款革命性的大模型微调工具。

留言“参加”即可来叶老师的直播间互动，1小时讲解让您轻松上手，学习如何使用 Llama Factory 微调模型。互动交流，畅谈工作中遇到的实际问题。

方法

Figure 2展示了RichRAG的整体框架，框架有三个主要组成部分：子方面探索器、多方面检索器和生成式列表排序器。Figure 2展示了这些组件如何处理输入查询，生成候选文档池，并最终生成排名列表。

在标准的RAG设置中，包含了一个知识库C、一个固定的检索器R和一个作为生成器的LLM G。对于一个多面查询q，其下属的各个方面被表示为S={s1, ..., sn}，每个子方面都有相应的子回答A={a1, ..., an}。这些子回答的组合构成了一个长形式的地面真实回答a，它覆盖了所有子方面。RichRAG的目标是生成的回答r不仅要与地面真实答案相匹配，而且要全面覆盖每个子回答，确保回答的丰富性和完整性。

子方面探索器的目的是挖掘用户查询中的潜在子方面。这一组件利用LLM的语言理解和生成能力，接收一个提示pse和一个用户查询q作为输入，并生成一系列子方面Sˆ。为了使子方面探索器与下游数据的输出格式和分布对齐，研究者使用训练查询和标记的子方面对其进行微调。优化子方面探索器使用的是下一个标记预测(NTP)损失函数。

多面检索器的任务是根据查询的子方面收集与各个子方面相关的文档，构建一个多样化的候选池。这个过程包括两个主要步骤：首先是针对每个子方面检索文档，然后将所有检索到的文档合并成一个候选池P。为了减少后续排名器的计算负担，重复的文档被视为单个文档，其关联的子方面形成集合s(d)。

生成式列表排序器的作用是从候选池中筛选出最有价值的顶部k个文档。这些文档需要共同覆盖查询的各个子方面，并符合生成器的偏好。该排序器基于编码器-解码器结构的生成模型T5，它将用户查询、识别的子方面和所有候选项作为输入，并直接生成顶级文档ID的排名列表。为了提高效率，研究者采用了并行编码和池化操作，并在解码器模块中引入了重用策略。

在监督式微调阶段，研究者使用贪婪算法构建银牌目标排名列表，以此来微调排名器。他们设计了一个覆盖效用函数来衡量每个剩余文档的增量方面覆盖增益。

在强化学习阶段，研究者使用强化学习策略来探索更好的排名可能性，并将最终回答的质量作为排名列表的奖励。他们采用了直接偏好优化（DPO）算法，并引入了单边显著性采样策略（US3）来构建有价值的训练样本。

实验

数据集：研究者们选择了两个公开可用的数据集进行实验，分别是WikiPassageQA和WikiAsp。WikiPassageQA数据集提供了人工标注的、质量评估的问题和长形式的答案，这些答案通常涉及问题的多个方面，且答案长度相当长。WikiAsp数据集旨在从20个不同领域生成实体的方面总结。为了支持实验，研究者们对数据进行了预处理，确保每条数据都包含问题、真实答案、问题的子方面以及它们的子回答。

评估指标：为了衡量模型回应与长形式真实答案的匹配程度，研究者们选择了F1分数、Rouge-2、Rouge-L和BERT-Score作为评估指标。此外，还利用了在方程11中引入的com-rouge分数来评估回应对子回答的覆盖程度。为了简洁，这些指标分别用F1、R2、RL、BS、CR2和CRL表示。研究者们还利用GPT-4进行了成对评估，以进一步确认方法的有效性。为了全面评估所提出的排名算法的有效性，研究者们还在附录C中提供了排名性能的比较和分析。

为了评估RichRAG框架的有效性，研究者们构建了不同RAG框架设置的基线模型，包括没有外部参考支持的闭卷设置、没有排名阶段的“检索-生成”设置（即No Ranker），以及使用各种排名算法的“检索-重排-生成”设置。这些基线模型直接根据原始查询检索外部文档。研究者们将RAGFusion框架作为基本的基线，以比较在明确考虑查询方面时所提出框架的优越性。RAGFusion提出了从各个子方面检索文档，并通过简单的互惠排名融合算法提供最终的排名列表。研究者们还结合了上述排名算法构建了RAG-Fusion的各种高级版本，例如RAGFusion+RankT5等。BGM是一个最近的RAG框架，它引入了PPO策略，根据LLM的反馈对列表式排名模型进行微调。

研究者们在两个设置中进行了实验：第一种设置中提供了预测的子方面给检索器和排名器；而在第二种设置中，提供了黄金子方面以充分发挥RichRAG的潜力。整体结果在表1和Figure 3中展示。研究者们得出结论，现有的RAG系统仅考虑查询-文档的相关性，而没有考虑候选者之间的关系，这限制了它们理解用户的多种子意图的潜力，并限制了最终回应的丰富性。与列表式排名算法相比，RichRAG方法仍然展现出更好的性能。即使在RAG社区中存在几个列表式排名算法，如LiT5和BGM，这些算法也没有从用户意图覆盖的全面性的角度明确模拟候选者之间的交互。没有这样的明确指导，这些算法可能会陷入局部最优解，从而影响排名列表的整体质量。

为了评估关键模块的作用，研究者们进行了消融研究，并在Figure 4中展示了结果。这些结果显示了与完整RichRAG相比，消融模型的性能下降程度。消融研究表明，明确考虑用户的子意图，即问题的子方面，对于提供全面回应至关重要。此外，所提出的生成式列表式排名模块能够生成LLM首选的全面排名列表，并且与LLM的偏好对齐对于提升最终回应质量至关重要。

由于候选文档数量庞大，排名模块的效率也很重要。因此，研究者们比较了他们的排名器与点式和列表式排名算法LDIST和LiT5的查询延迟，以测试它们的效率。Figure 5 (a) 展示了随着候选数量的变化，查询延迟的变化。显然，研究者的排名器与点式排名算法具有可比的效率和趋势。然而，随着候选数量的增加，LiT5的时间开销急剧上升。这种现象证明了研究者的排名器能够在有效性和效率之间提供更好的权衡。此外，由于排名器逐步生成文档ID，研究者们还提供了不同生成文档数量的查询延迟趋势，并在Figure 5 (b)中展示了不同候选数量的趋势线。可以发现，随着排名文档数量的增加，所有趋势线缓慢上升，不同候选数量（CCnt）之间的差距限制在1秒以内。这种现象进一步证明了排名器在不同排名设置中的效率的鲁棒性。

论文链接：https://arxiv.org/pdf/2406.12566