作者： 深度学习与NLP 来源： 深度学习与NLP

亚马逊 RAG 新突破：REAPER 技术开启大型智能对话助手新境界

发布时间：2024 年 07 月 26 日

RAG

REAPER: Reasoning based Retrieval Planning for Complex RAG Systems

复杂的对话系统常借助检索证据来提供准确回答。RAG 系统从庞大的异构数据源中检索信息，这些数据源通常由多个索引或 API 构成，而非单一整体数据库。针对特定查询，系统需从众多可能的检索源中筛选出相关证据。复杂查询甚至可能涉及多步骤检索，例如，零售网站上的对话代理在回答过往订单相关问题时，需先检索订单信息，再结合产品上下文提取相关证据。多数 RAG 系统通过交替推理与检索步骤来应对这类思维链任务，但每一步推理都会增加系统延迟，对于大型模型而言，延迟可达数秒。多代理系统虽能将查询定向至特定检索源的代理，但小型分类模型的性能却制约了大型语言模型的发挥。为此，我们推出了 REAPER——一种基于 LLM 的规划器，用于生成对话系统中的检索计划，显著降低了延迟，并能灵活适应新场景。该方法虽适用于各类 RAG 系统，但我们以亚马逊的对话购物助手 Rufus 为例，展示了其应用成效。

https://arxiv.org/abs/2407.18553

Rufus：亚马逊新一代智能购物助手

今年 2 月份，亚马逊在新一代大语言模型和 RAG 技术的赋能下，推出了新的智能购物助手：Rufus。

Rufus 能够解答顾客关于购物需求、产品对比等问题，并基于这些信息提供建议，帮助顾客发现产品。Rufus 采用了 RAG（检索增强生成）框架，通过大型语言模型（LLM）结合一个或多个检索来源的证据来生成对顾客查询的回应。

作为一个复杂的对话系统，Rufus 覆盖了非常多的用户关心的领域，因此必须从庞大的数据存储和索引中提取证据。这些庞大的数据并不是存储在一个庞大的数据库，而是分散在多个数据源。为了实现高效的检索，对话系统需要决定查询哪些索引，甚至在何时让 LLM 依靠自身的知识来回答问题，而不是依赖于检索到的证据。

• • 在某些情况下，当 Rufus LLM利用其预训练的知识回答问题*时，甚至不需要检索证据。

• • 每个检索来源或检索器都与延迟和硬件成本相关，因此 Rufus 不能对每个查询都调用所有检索器，而是需要决定对特定查询调用哪些检索器。当检索过程本身可能涉及多步骤时，情况会更加复杂。

如上图所示，将查询从“Galaxy 手机有多少内存”更改为“我的 Galaxy 手机有多少内存”会显著改变检索策略。

在第一种情况下，检索到的证据基于关于 Galaxy 手机的一般信息，大多数大型通用 LLM 都能从其预训练知识中回答这个问题。对于第二个问题，我们首先需要识别顾客购买的具体手机型号，并提供与该手机相关的详细信息。

虽然 Agent 系统通过执行多次检索和推理操作，可以解决检索的复杂性问题，但是每一步推理都会直接导致系统响应时间的延长（这种延迟往往是秒级）。

多 Agent 系统利用分类器，将用户查询导向合适的智能体、让多个智能体共同生成候选答案，再由一个最终智能体挑选出最佳选项，这无疑增加了硬件成本和系统延迟。

因此，作者推出了 REAPER——一种基于推理的规划器，专为处理复杂查询的高效检索而设计。

2. 什么是 REAPER？

REAPER 仅用一个更小巧的 LLM，便能制定出一份详尽的计划，明确了所需调用的工具、调用顺序及其参数 。REAPER 在挑选合适工具序列的准确度高达 95%，并且在生成正确工具参数方面** 准确度达到 92%**。

REAPER 融合了自适应 RAG、问题配对和 ReWOO 的理念，利用一个较小的大语言模型通过 CoT 来推理制定检索计划。相比过去的 Rufus，使用的是一个大型 LLM，大大降低了因为大型模型产生的高延迟、和高硬件成本。

如上图所示，一个需要多步检索的查询示例。对于 Rufus 而言，客户对亚马逊产品的相关查询是常见场景，通常在可能的情况下，将产品信息作为 REAPER 的上下文。

上图展示了用户在有或没有产品上下文的情况下提出问题的提示词。会话系统的上下文可以根据需要扩展，包括对话历史、提问的时间/日期、用户信息、问题所在页面的 URL 或标识符等。为了生成检索计划，REAPER 需要：

• • 1.完全理解所有用于生成证据的工具。

• • 2.制定一个检索计划，能够应对无证据检索、单步检索和多步检索。由于 REAPER 很可能是进入对话系统的首站，所有这些计划都应使用相同的提示生成。

• • 3.鉴于 REAPER 的失误可能会直接影响到客户响应，REAPER 在选择工具、安排顺序以及工具的格式和参数方面必须达到高准确度。

• • 4.为了减少延迟和硬件成本，REAPER LLM 的规模应显著小于对话系统的答案生成 LLM。

• • 5.REAPER 应能够轻松扩展到新的检索器或工具，而无需大量新的数据和训练。

• • 6.REAPER 不应为它以前未见过的用例虚构新工具，并应能够适应工具集合的变化。因此，它需要保持良好的指令遵循能力，尽管不需要在一般用途的指令遵循上表现卓越，因为其主要任务是检索计划。

3. 如何打造一个 REAPER？

为了满足 REAPER 的需求，作者尝试寻找一个小巧却能精准遵循指令的 LLM。考虑到 Mistral-7B-Instruct-v0.2 在开放 IFT 基准测试中的卓越表现，作者选择了该模型。

但是即使是经过精心设计的提示词调整和多次上下文示例，Mistral 模型仍然会产生幻觉，比如上图给出的示例。

因此，作者对模型进行了定制化微调。接下来将介绍设计 REAPER 提示和筛选微调数据的方法论，以实现维持指令遵循的同时根除幻觉，同时学习检索工具规划的专门技能的目的。

REAPER 旨在调和两个看似矛盾的目标：

• • 首先，模型必须以精确的格式为特定领域的任务生成计划，并确保工具准确性；

• • 其次，模型应能洞察输入的变动，包括指令和工具的细微变化，并据此调整计划。

通过大量精确的 REAPER 计划来训练模型，以满足第一个需求。但这种做法可能会使模型在规划任务上过拟合 ，从而削弱其遵循指令和逻辑推理的能力。

反之，如果训练数据中的计划不够充分，模型则可能产生不切实际的回应。

在对 LLM 进行指令遵循的微调时，一个关键的设计考量是提供多样化的提示和输出对 ，以避免模型过度适应某一特定任务模板，从而丧失严格遵循指令的能力。鉴于我们的主要任务是检索规划，引入指令集多样性的空间相对有限，这使得挑战更为严峻。

为此，作者开发了以下模块，以增强输入和输出数据的多样性。

3.1 工具演化模块（TEvo）

一个创新的模块——工具演化（TEvo，Evolution of Base Tool Prompt），工具提示作为输入，生成语义相近但输出结果保持不变的新提示。与在图像中加入对抗性噪声以训练鲁棒的图像分类器类似。

为了让模型更加关注工具及其描述，会选取针对特定查询所需的工具，以及剩余工具中的随机子集，纳入提示的指令部分。还为每种工具构建了名称变体和描述释义的库，并从中进行抽样。例如，在回答产品相关问题时，我们的工具名称可以是 prod_qna、product_information、product_facts 等，不一而足。最终，还通过从少量人工制定的计划库中抽样，来丰富上下文示例的多样性。

3.2 工具任务生成器（TTG）

之前的研究证明：通过提升简单任务的难度并将其融入到 IFT 训练数据之中，以此增强 LLM 遵循指令的能力。受此启发，作者提出了一种创新的方法来 TTG（Tool-Task Generator）创构与检索规划相关的多样化任务，以此推动 LLM 深入理解工具和检索计划。

设定一个基础任务，即生成一个检索计划 Tprim =(x,y)，这里 x 代表输入，涵盖了查询 q 和上下文 c，我们将这一任务衍生出多个相关子任务。

Ti=fi (Tprimary)

其中 fi 是针对各个子任务特有的转换函数。这些衍生任务旨在培养模型的特定能力，包括：

• • (1) 根据计划生成查询

• • (2) 补全部分计划

• • (3) 识别恰当的工具

• • (4) 完成遮蔽步骤

• • (5) 正确排序步骤

• • (6) 识别遮蔽参数

• • (7) 限定计划中仅使用提示中给出的工具

TTG 模块通过将这些次级任务转换应用于基础任务创造出多样化的任务-目标配对集合。从这个多样化的任务集合中抽样，对 REAPER 模型进行微调，培育模型对任务结构的全面而深入的理解，并提升其针对复杂客户查询生成检索计划的能力。

3.3 多样化查询采样器（DQS）

为了丰富提示词的多样性，不仅采用了工具演化（TEvo）和任务生成器（TTG），还对客户查询的输入进行了多样化处理。

相似的查询可能会使模型陷入对特定查询模式的依赖，这在遇到非典型案例时会导致性能下降。因此，设计了 DQS（Diverse Query Sampler），它能够自动生成语义上差异显著的客户查询样本，并根据对话的上下文为这些样本标注相关的工具和参数。

从一个精心策划的高质量初始客户查询池出发，结合一个更大的生成或采样的客户查询池。

3.4 通用 IFT 数据集

为确保模型维持其遵循指令的能力，在 REAPER 工具规划数据的基础上，融入了通用的指令微调数据集。选用了 ShareClaude 以及 ToolAlpaca 提供的开源工具使用数据，构成了通用 IFT 数据集，简称为“通用 IFT”。

为了加强模型对输入指令中细微变化的适应性，采纳了一个从 EvolInstruct 中汲取灵感的框架，该框架通过在基础指令上增加限制条件并进行采样，自动化地产生更为复杂的 IFT 数据，同时保持了与任务所用提示长度相当的查询复杂性比例，称此数据集为“通用 IFT-Evolve”。

最终，微调数据集 REAPER-IFT，是将通用 IFT、通用 IFTEvolve 与经过 TEvo、TTG 和 DQS 多样化处理的工具注释查询相结合的产物。

4. 效果对比

4.1 开放模型的对比分析

一般而言，大家倾向于利用语言模型通过 iCL 来解决问题。

作者对比了 Mistral-7B-Instruct-v0.2 和 Claude3-Sonnet 通过 iCL 解决问题的效果。两者均没有达到预期水平，并且都出现了幻觉的现象。重要的是，Claude3-Sonnet 的响应延迟大约是每步 2 秒，而相比之下，REAPER 和 Mistral 模型完成整个计划的延迟仅为 207 毫秒——这不仅增加了一个数量级的延迟成本，同时也意味着需要更高性能的硬件来支持 Claude3-Sonnet 的运行。

4.2 与基于分类器的规划器对比分析

从两个维度对模型进行评估：

• • (1) 工具选择：针对单个查询，手动评估模型是否选择了正确的工具并按照适当的顺序执行，以检索证据。由于多步检索在生产系统中仅作为一个类别，这一指标能够与生产系统的分类指标直接对比。使用准确率、精确率、召回率和 F1 分数来衡量这一评估。

• • (2) 参数提取：REAPER 的另一重要方面是对工具输入参数的准确度。当前设置下，仅有两个工具——prod_search 和 shipment_status——需要与客户查询不同的参数。因此，仅针对涉及这些工具的计划进行评估。测试基准采用 Mistral-7B-Instruct-v0.2 模型，通过为每个类别定制的提示来生成参数。而 REAPER 则能在单一提示中完成所有工具的选择及其参数的生成。

上表展示了 REAPER、基线集成模型以及仅通过上下文调整的 Mistral-7B-Instruct-v0.2 在训练数据规模和精确率、召回率及 F1 分数上的表现。鉴于 Mistral 工具的准确度过低，我们并未计算其参数的准确度。

由于 Rufus 是一个新系统，其流量分布目前还倾向于现有的流量模式，而非 Rufus 旨在解决的新用例。因此，并未采用流量抽样来创建评估集，而是采用了一个包含 600 个查询的平衡评估集，以确保相应的计划在工具（类别）上的比例大致相等。

4.3 消融分析

上表中，展示了 TEvo、DQS 和 IFT-Evolve 各自对模型性能的贡献。

除了评估工具选择的准确度，还通过引入一种对抗性提示来检验这些组件如何辅助模型遵循指令。在这种对抗性提示中，特意移除了 prod_qna 工具，并观察 REAPER 在测试数据集上的预测表现。根据模型的指令，它应当避免使用 prod_qna 来制定计划。

集成了所有三个组件的 REAPER 不仅在工具选择准确度上表现最佳，而且在指令遵循上也表现最优，其在对抗性环境中的所有计划均未使用被排除的 prod_qna 工具。

当从训练数据中剔除通用 IFT-Evolve，转而使用通用 IFT 时，工具选择的准确度有所下降。同时，模型在 24%的计划中错误地使用了 prod_qna，显示出其在遵循指令上的能力有所减弱。

当我们从训练中移除 TEvo（任务多样性）和 DQS（输入查询多样性）时，也观察到了准确度的显著下降，尤其是 DQS 的移除对准确度的影响更为明显。这表明，TEvo 对于提升模型的指令遵循能力至关重要，而 DQS 则有助于模型理解多样化的查询形式。

4.4 训练数据配比的效应

上表展示了在训练数据集中试验的不同配比。

在训练数据中融入 ShareClaude（通用 IFT）或其升级版——通用 IFT-Evolve 与 REAPER 计划，是保证模型泛化能力的关键。

缺乏这些通用数据的支持，模型就会对 REAPER 的特定应用场景过拟合，并可能丧失遵循指令的能力。

在最糟糕的情况下，有 77%的查询错误地构建了模型在训练时接触过但指令中未指定的工具（IFT 得分降至 0.23）。反之，如果仅依赖通用-IFT 数据进行训练，模型在本领域内的工具选择准确度将降至 20%。

中间的三行显示，调整了通用 IFT-Evolve 数据所占比例，从 40%到 60%不等，而表的后三行则展示了每个查询对应的 REAPER 规划任务数量的变化。随着 IFT 数据和 REAPER 计划数量的增加，模型在两个指标上都有所提升，但超过某一临界点后，工具选择的准确度会出现下降。

当 REAPER 任务与通用 IFT（通用-IFT-Evolve（全部）+ TTG（4 任务））的比例大致为 1:6 时，模型在准确度和遵循指令的能力上达到了最佳平衡。不过，随着将系统拓展到新的检索器和应用场景，预计还需进一步调整这些超参数以优化性能。

4.5 泛化分析：

4.5.1 REAPER 能否构思出创新的计划？

尽管训练数据仅限于订单状态情境中的多步计划，但 REAPER 仅凭上下文示例便能为它从未遇到过的查询类型生成恰当的工具序列。尽管偶尔会出现幻觉，但当额外引入了 25 个多样化的多步示例后，REAPER 便能够生成无幻觉的精确新计划。下图展示了一些例子：

4.5.2 REAPER 能否在数据有限的情况下进行微调？

REAPER 的一个实际应用场景是，在数据量有限的情况下适应新的检索资源。通过新增一个名为 human_small_talk 的无证据类别来验证这一点。仅向训练数据中添加了 286 个此类别的实例，便发现模型的 F1 得分达到了 0.92，与那些使用数量级更多数据训练的资源相比，表现相当。

4.5.3 REAPER 能否掌握一个全新的工具？

探究了 REAPER 在完全没有训练数据的情况下，仅依靠工具的上下文示例，能否学会使用一个新工具。为此，新增了一个名为 compatible_products 的工具，提供了它的描述和一些示范性示例，并发现 REAPER 能够制定出有效的计划。例如，对于查询“HP 4650 的墨盒”，REAPER 生成了图 6 所示的计划。这也证明了 REAPER 依然保持着遵循指令的能力。

6 结论

模型的两大优势：

• • 1）与常规分类模型相比，REAPER 在数据效率上表现卓越——它仅使用了 6K 个领域内查询进行训练，而分类模型则需 150K；

• • 2）它能够轻松扩展至新的检索资源——通过向训练数据中增加 286 个领域内查询，我们便成功地整合了新的检索资源。

• • 3）REAPER 在速度上也比基于大型（>100B LLM）的代理系统快了一个数量级（207 毫秒对比 2 秒）。

• 来源 | 大模型论文论文跟踪

更多AI工具，参考Github-AiBard123，国内AiBard123