Advanced RAG 11：对用户输入的内容进行「分类处理」和「再优化」

2024-08-12 286

编者按： 你是否曾经遇到过这些情况：你向 AI 助手提出了一个比较复杂的问题，但它给出的回答却比较浅显，甚至完全偏离了你的意图🤔？或者，你询问了一个非常简单的问题， AI 助手却给出了一大堆不必要的信息，让你感到烦恼😣？

传统的 RAG 技术虽然能有效减少 AI 回答内容中的错误，但并不能改进用户最初提交的 query 内容，因此可能会出现以下这些问题：

对于用户提交的简单 query ，系统可能会消耗过多的计算资源，浪费用户时间和增加资源消耗。

面对复杂的 query，直接使用原始的 query 进行检索往往无法整理到足够的信息，导致回答不完整或不准确。

对于含义模糊、模棱两可的 query ，仅凭原始的 query 进行信息检索更是远远不够，可能会误解用户的真实意图。

那么，我们如何才能缓解这些问题，提高 AI 系统的理解能力和回答质量呢？本文将介绍两种技术方案：query classification 和 query refinement，并通过代码实例加以阐释，同时还在本文中记录了作者对这些技术方案的理解和思考内容。

作者 | Florian June

编译 | 岳扬

处理简单的 queries 时，该 RAG 系统可能会消耗过多的计算资源。
面对复杂的 queries 时，直接使用 original query （译者注：未经任何改动的 query 内容，由用户最初提交的搜索请求。）进行检索常常无法收集到足够的信息。
对于可能存在多个答案的模糊不清的 queries，仅凭 original query 进行信息检索是远远不够的。

本文将探讨两种进阶策略：query classification 和 query refinement， 两者均通过训练小模型提升了系统的整体性能。文章最后，作者还将分享对这两个算法的理解与思考。

01 Adaptive-RAG：根据问题复杂程度分类处理（Adapt）的检索增强型 LLMs

1.1 Overall Process

Adaptive-RAG 提出了一种创新的 adaptive framework （译者注：该系统可以根据 query 的复杂程度动态选择最合适的信息检索和生成策略。）。如图 2 所示，该系统可根据 query 的复杂度，动态选择最合适的 LLMs 使用策略（包含从最简单（the simplest）到最复杂（the most complex）的多种策略）。

图 2：对比不同检索增强型 LLMs（retrieval-augmented LLM）的解答策略差异。资料来源：Adaptive-RAG[1]

图 2（A）描绘的是一种单步方法（single-step approach） ，这种方法会先检索出相关文档，然后生成答案。但这一方法对于那些需要多级逻辑推理（multi-step reasoning）的复杂 query 而言，可能精度不足。

图 2（B）是一种分多个步骤进行处理（multi-step process） 的方法，包括迭代进行文档检索（document retrieval）及生成中间答案（generation of intermediate responses）等步骤。虽然这种方法效果比较好，但由于需多次调用大语言模型（LLMs）和检索器（retrievers），处理简单 queries 时效率不太高。

图 2（C）是一种 adaptive （译者注：可根据具体情况选择具体的策略。）的方法，通过精心设计的分类器（classifiers），我们能够更精准地判断、选择最佳检索策略（是选择迭代检索（iterative）、一次性检索（single），还是不使用检索方法（no retrieval methods））。

为了帮助大家更直观地理解 Adaptive-RAG 的工作流程，本文会结合具体代码来加以说明。目前，该技术存在四个不同版本的代码实现，它们分别是官方版本（official version）[2]、Langchain** 版本[3]、LlamaIndex 版本[4]以及 Cohere 版本[5]。本文将以 LlamaIndex 版本作为示例介绍该技术。

想要了解更多详细信息，可以查看这份文档[6]。考虑到代码量比较大，在本文将着重描述其中的核心代码片段。

图 3：Different tools of Adaptive-RAG. Image by author, inspired by LlamaIndex version[4].

代码的运行方式会根据 query 的复杂程度而产生变化，并相应地调用不同的工具：

面对复杂的 queries：需要多个工具协同工作。这些工具会从多份文档中提取信息，具体示例可见于图 3 的右上方。
针对简单的 queries：仅需单个工具从单个文档中获取所需上下文，如图 3 左上方所示。
处理直接明了的 queries：直接调用 LLMs 给出答案，这一过程如图 3 底部所示。

如图 2（C）所示，我们可以通过分类器（classifier）来挑选合适的工具。但与官方版本不同，此处使用的分类器并未针对该应用场景进行过针对性地训练，而是直接应用现成的 LLMs ，这一做法在图 4 中有明确描述。

图 4：Tools selection of Adaptive-RAG. Image by author, inspired by LlamaIndex version[4].

1.2 构建分类器（Classifier）

虽然 LlamaIndex 版本的代码实现并没有分类器的构建这一环节，但深入了解分类器的构建过程，对于我们的后续开发工作有着至关重要的作用。

1.3 构建数据集（Dataset）

在该技术的实现过程中面临一个重大挑战，我们缺乏带有 query-complexity pairs（译者注：query 与其相应的复杂度（complexity）的配对数据。）的训练数据集。那么，我们该如何应对这一问题呢？Adaptive-RAG 采用了两种策略，以自动化的方式创建所需的训练数据集（training dataset）。

根据 Adaptive-RAG 提供的数据集[7]，我们可以看到，其对分类器训练集的数据标注工作，是依托于那些已经公开并带有标签🏷的问答数据集完成的。

存在两种处理策略：

对于用户上传的 query ，若使用最简易的、非基于检索的方法能够得出正确答案 ，那么对应的 query 就会被打上 'A' 的等级标签。同样的逻辑，通过单步方法（single-step approach）能够得到正确答案的 query 会标记为 'B' 等级 ，而通过分多个步骤进行处理（multi-step process）的方法正确解答的 query 则会被标记为 'C' 等级。不过有一点需要在此强调，较为简单的模型优先级更高。也就是说，当单步法（single-step）和多步法（multi-step）均能给出正确答案，但非基于检索的方法无法做到时，就会给该 query 打上 'B' 的等级标签，如图 5 所示。

图 5：Adaptive-RAG 数据集的样本示例，截图出自原文作者

倘若上述三种方法均未能生成正确答案，则说明有些问题仍未被标注分类。这种情况下，我们会直接根据公开数据集进行分类。具体而言，单步数据集（single-hop dataset）中的 query 会被标注为 'B' 等级，而多步数据集（multi-hop dataset）中的 query 则会被标注为 'C' 等级。

1.4 Training and Inference

训练方法采用交叉熵损失函数（cross-entropy loss），基于这些自动收集的 query-complexity pairs （译者注：query 与其相应的复杂度（complexity）的配对数据。）来训练分类器。

然后，在推理过程中，我们将 query 输入至分类器，即可判定 query 的复杂度等级，该等级标签可为 'A'、'B' 或 'C' 中的任意一种：o = Classifier(q)。

1.5 选择分类器模型的 Size（Selection of Classifier Size）

图 6：不同规模（size）分类模型的实验结果。来源：Adaptive-RAG[1]从图 6 可以看出，无论分类器模型的 size 如何，其性能表现并无明显差异。 即便是小型模型也能维持相同水平的性能，有利于提高资源利用效率。

接下来，我们将介绍一种 query 优化技术：RQ-RAG。

02 RQ-RAG: 一种 RAG 系统中的 Queries 优化技术方案

针对上述挑战，RQ-RAG 提出了三项优化方法，如图 7 所示。

图 7：RQ-RAG 使用的模型可根据需求进行信息检索，必要时能对 query 进行重写（rewrite）、分解（decompose）和歧义消除（disambiguate）等操作。来源：RQ-RAG[8]。

对于日常问候（daily greetings）等这类简单 query，加入额外的上下文反而可能降低大模型的回复质量。对于这种情况，大语言模型应当直接做出响应，而非添加不必要的上下文信息，以避免造成大模型的回答质量下降。换句话说，如图 7 左上方所示，模型应具备按需应答（respond on demand）的能力。
面对复杂的 query ，RQ-RAG 会将其细分为若干个更易于解答的 subquery。逐一检索 subquery 的相关信息，从而形成对原始复杂 query 的完整响应，如图 7 右上方所示。
遇到含义模糊、可能有多重解释的 query 时，仅使用原始的 query 文本进行检索是远远不够的。大语言模型必须掌握 query 文本的具体细节、理解用户的真实意图并制定出针对性的检索方案。

这种方法确保了检索到的信息既全面又精准，从而更加有效地回答问题，如图 7 底部所示。

RQ-RAG 通过端到端（end-to-end）的方式 training （译者注：Llama2 是一个预训练模型，此处的 training 应当是指微调。）一个 Llama2 7B 模型。使得该模型能够动态地通过重写（rewriting）、分解（decomposing）和消除 query 中的歧义来增强 query 的检索效果。

由于 RQ-RAG[9] 的代码目前正处于重构阶段[10]，某些功能尚未完全实现，因此本文暂无法进行演示。

2.1 构建数据集

考虑到 RQ-RAG 系统的端到端（end-to-end）特性，关注数据集的构建流程至关重要。

图 8：数据集的构建流程。来源：RQ-RAG[8]

数据集的构建[11]主要包括以下几个步骤：

首先，搜集一个涵盖多种使用场景的语料库（如图 9 所示），包括但不限于多轮对话（multi-turn dialogues）、需分解的 query 语句及需消解歧义的 query 语句。依据该语料库，构建一个任务池（task pool）。

图 9：数据集结构。来源：RQ-RAG[8]

第二步，任务池中的任务被划分为三大类型：多轮对话（multi-turn dialogue）、分解 query 语句（decomposition）和消除 query 中的歧义（disambiguation）。例如，多轮对话数据集中的每一个样本都会被归入为多轮对话类型（multi-turn dialogue category）。
第三步，首先使用 ChatGPT** 对各类 query 进行优化。接着，使用这些优化后的 query 语句向外部数据源检索信息。一般情况下，DuckDuckGo 是主要的信息检索来源，而这个检索过程被视为一个不透明的"黑盒"（black box）。
第四步，指示 ChatGPT 根据优化后的 query 及相应的上下文，生成修正后的模型响应。通过重复执行这一流程，我们得以积累了总计约 40,000（40k）个实例。

图 10、11 及 12 呈现了与 ChatGPT 交互时所使用的提示词模板。其中，蓝色文字部分代表了应根据具体情况输入的具体内容。

图 10：构建数据集时采用的多轮对话提示词模板。来源：RQ-RAG[8]

图 11：构建数据集时采用的 query 分解提示词模板。来源：RQ-RAG[8]

图 12：构建数据集时运用的 query 消歧提示词模板。来源：RQ-RAG[8]

当上述步骤全部完成后，我们将得到图 13 右侧所示的训练样本。

图 13：Training sample。来源：RQ-RAG[8]

每个训练样本实质上都是一个带有特定 tokens（special tokens）的操作序列（operation sequence），其中：

'Xorigin' 和 'Yorigin' 表示原始数据集中的一组输入与输出的对应关系（input-output pair）。
'Type' 是指优化操作（optimization action）：可能是重写 query（rewrite）、分解 query（decompose），或是消除歧义（eliminate ambiguity）。
'i' 表示迭代轮数。
'SPECIALtype' 表示优化类型（type of optimization）。
'Qi, type' 指代在第 i 次迭代中，依据特定 tokens（special tokens）进行优化后的 query 文本。
'[Di1, Di2, . . . , Dik]' 表示第 i 次迭代中检索出的前 k 个文档。
'Ynew' 是在最后一次迭代中产生的新答案。

2.2 Training

在得到训练数据集后，我们便能以常规的自回归方式（auto-regressive）[12]来训练大语言模型（LLM）。具体的训练目标函数（Training objective）如图 14 所示。

图 14：RQ-RAG 模型的训练目标函数（Training objective）。来源：RQ-RAG[8]

说白了，训练的核心在于微调模型参数，确保在每一个步骤 i 中，面对原始的输入 x 、优化后的 query qi 及检索出的文档 di 时，模型 M 能够对模型响应 y 给出最大化的概率预测（highest probability）。

2.3 Answer Selection

每次迭代时，该模型都会针对特定需求生成多种用于检索的 query 语句，比如对 query 进行重写、分解或消除其歧义。这些 query 反过来又能获得不同的上下文，有助于模型更全面、更灵活地处理复杂任务（leading to the diversification of expansion paths）。

图 15：面对不同情况（paths），我们制定了三种不同的策略 ------ 基于困惑度（PPL）、基于置信度（confidence）和基于集成学习（Ensemble）的选择方法。来源：RQ-RAG[8]

正如图 15 所示，RQ-RAG 研发了一套树形解码策略（tree decoding strategy），并使用了三种选择机制[13]：基于困惑度（PPL）的选择方法 、基于置信度（Confidence）的选择方法 以及基于集成学习（Ensemble）的选择方法。

在基于困惑度（PPL）的选择方法中，模型会选择所有输出中困惑度（PPL）最低的答案。基于置信度（Confidence）的选择方法则是选择所有置信度最高的结果。而基于集成学习的选择方法，则倾向于选取累积置信度分数（confidence score）最高的最终结果。

03 Insights and Thoughts

3.1 这些技术与 Self-RAG 和 CRAG 进行对比

不同于 Adaptive-RAG 和 RQ-RAG 在检索前对原始 query 进行优化的做法，Self-RAG[14] 和 CRAG[15] 的关注重点在于判断何时执行检索（retrieval）操作以及如何优化检索操作之后的信息处理效率。特别值得一提的是，CRAG 通过重写用于网络检索的 query 语句，提升了检索结果的信息质量。

RQ-RAG 和 Self-RAG 均通过训练小型语言模型的方式来替代原有的大模型（LLMs）。相比之下，Adaptive-RAG 和 CRAG 保留了原有模型，仅是新增了对 query 进行分类或评估的两个功能层。

后起之秀 Adaptive-RAG 和 RQ-RAG 都声称自己的性能优于 Self-RAG，在它们的论文中都有对应的实验报告。

从生成流程（generation process）的角度考量，Self-RAG、CRAG 及 Adaptive-RAG 因未采用复杂的树形解码策略（tree decoding），显得更为简洁明快。

3.2 技术实践过程中发现的一些问题（About Engineering Implementation）

当 query 转化为多轮对话的情况时，利用大语言模型处理冗长的提示词数据可能会造成响应延时。根据我目前的理解，采用并行处理技术（parallelization）或许能有效解决这一问题。

此外，无论是 Adaptive-RAG 还是 RQ-RAG 技术，它们都对 query 进行了分类。但这些分类方式是否真正达到了最优状态？它们是否能完美适用于特定的生产场景？有没有可能采用其他分类策略能取得更好的效果？需要通过一系列对比实验（comparative experiments）来验证这些观点。

3.3 小模型（Small Model）亦可大放异彩

RQ-RAG 的实践过程表明，即使是一个 7B 参数量的模型，只要数据集构建得当、生成流程精细， 7B 参数量的模型也能创造卓越的性能表现。

盲目追求模型规模的庞大并不一定等同于更高的性价比。对于那些资源有限的团队而言，专注于优化数据集与精进算法或许是更为明智的选择。

04 Conclusion

在本文中，我们探讨了 query classification 与 query refinement 这两项技术方案，并通过代码实例加以阐释，同时还在本文中介绍了作者对这些技术的理解和思考。

倘若您对检索增强生成（RAG）技术感兴趣，请随时浏览本系列其他文章

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

Florian June

AI researcher, focusing on LLMs, RAG, Agent, Document AI, Data Structures. Find the newest article in my newsletter:

https://florianjune.substack.com/

END

参考资料

[1]https://arxiv.org/pdf/2403.14403

[2]https://github.com/starsuzi/Adaptive-RAG

[3]https://github.com/langchain-ai/langgraph/blob/main/examples/rag/langgraph_adaptive_rag_cohere.ipynb

[4]https://github.com/mistralai/cookbook/blob/e200507fba4e3404564f9249b345c89f83d73a10/third_party/LlamaIndex/Adaptive_RAG.ipynb

[5]https://github.com/cohere-ai/notebooks/blob/main/notebooks/react_agent_adaptive_rag_cohere.ipynb

[6]https://github.com/mistralai/cookbook/blob/e200507fba4e3404564f9249b345c89f83d73a10/third_party/LlamaIndex/Adaptive_RAG.ipynb

[7]https://github.com/starsuzi/Adaptive-RAG/blob/0c88670af8707667eb5c1163151bb5ce61b14acb/data.tar.gz

[8]https://arxiv.org/pdf/2404.00610

[9]https://github.com/chanchimin/RQ-RAG

[10]https://github.com/chanchimin/RQ-RAG/tree/96b4ec981d4a4399e8402da1b75e16f7812aedfe

[11]https://github.com/chanchimin/RQ-RAG/blob/96b4ec981d4a4399e8402da1b75e16f7812aedfe/data_curation/main_multiturn_answer_generate.py

[12]https://github.com/chanchimin/RQ-RAG/blob/96b4ec981d4a4399e8402da1b75e16f7812aedfe/retrieval_lm/finetune.py

[13]https://github.com/chanchimin/RQ-RAG/blob/96b4ec981d4a4399e8402da1b75e16f7812aedfe/retrieval_lm/output/sample_from_tree.py

[14]https://medium.com/ai-advances/advanced-rag-08-self-rag-c0c5b5952e0e

[15]https://ai.gopubby.com/advanced-rag-10-corrective-retrieval-augmented-generation-crag-3f5a140796f9

原文链接：

https://ai.gopubby.com/advanced-rag-11-query-classification-and-refinement-2aec79f4140b

微信关注我们

原文链接：https://my.oschina.net/IDP/blog/15277535

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

横扫鸿蒙弹窗乱象，SmartDialog出世

前言但凡用过鸿蒙原生弹窗的小伙伴，就能体会到它们是有多么的难用和奇葩，什么AlertDialog，CustomDialog，SubWindow，bindXxx，只要大家用心去体验，就能发现他们有很多离谱的设计和限制，时常就是一边用，一边骂骂咧咧的吐槽实属无奈，就把鸿蒙版的SmartDialog写出来了 flutter的自带的dialog是可以应对日常场景，例如：简单的打开一个弹窗，非UI模块使用，跨页面交互之类；flutter_smart_dialog 是补齐了大多数的业务场景和一些强大的特殊能力，flutter_smart_dialog 对于flutter而言，日常场景是锦上添花，特殊场景是雪中送炭但是 ohos_smart_dialog 对于鸿蒙而言，日常场景就是雪中送炭！单单一个使用方式而言，就是吊打鸿蒙的CustomDialog，CustomDialog的各种限制和使用方式，我不想再去提及和吐槽了有时候，简洁的使用，才是最大的魅力鸿蒙版的SmartDialog有什么优势？单次初始化后即可使用，无需多处配置相关Component 优雅，极简的用法非UI区域内使用，自...

2024-08-11

241

NGINX 向云原生演进，All inOpenNJet 1. 背景需求访问日志是目前web server，proxy最常用的问题跟踪、统计分析的源头。所以尽管由于IO，产生访问日志对系统的的影响很大（据客户的实际反馈，因打开访问日志，系统性能有50%以上的损耗），但在正式的上线环境中应该尽量打开访问日志。然后，产生的日志作为源头，会被输出到ES等统一的日志平台进行分析处理，或被各式各样的日志分析工具进行分析。比如一款开源的基于c编写的日志分析工具goaccess，就可以既在命令行下使用，也提供HTML格式的报表。其产生的报表可以有命令行的：或 html格式的：以上图片来源于：https://goaccess.io/ 当然，NJet针对落盘影响性能这个问题也做了很多优化，比如：动态配置访问日志，仅仅在某个具体的访问url，仅仅在分析故障阶段打开，并在分析定位完成后尽快关闭; 动态输出日志到远端，避免磁盘IO的影响。但这个优化是减少了IO，也少输出了记录，影响了用户分析自己的网站的完整性。在分析了goaccess的代码后，我们觉得，可以把NJet和goaccess结合起来，由N...

2024-08-12

280

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。