前沿重器[61] | Agentic RAG综述解读

向量数据库大模型云通信

前沿重器

栏目主要给大家分享各种大厂、顶会的论文和分享,从中抽取关键精华的部分和大家分享,和大家一起把握前沿技术。具体介绍:仓颉专项:飞机大炮我都会,利器心法我还有。(算起来,专项启动已经是20年的事了!)

2024年文章合集最新发布!在这里:再添近20万字-CS的陋室2024年文章合集更新

往期回顾

最近留意到一篇Agentic RAG的综述论文,相对比较完整地总结了Agentic RAG方向的一些主要方案,今天带大家详细看看,并给出一些我自己的想法。

RAG我本身已经写了不少文章了,有兴趣可以传送过去看看:

本文重点还是聚焦在Agentic RAG这个概念,看看他的概念以及一些常用的方案,进一步我们一起分析在现实使用中可以吸纳的思路。

  • 回顾RAG整体发展历程
  • Agent核心原则和背景
  • Agentic RAG系统分类体系
  • 文章读完后自己的想法

回顾RAG整体发展历程

根据原文的说法,RAG经历了4个阶段才发展到Agentic RAG,具体的阶段相信大家也比较熟悉:

  • Naive RAG :最基础的RAG模块,使用关键词的检索,然后扔给大模型完成生成。
  • Advanced RAG :更高级的RAG模块,开始使用向量召回、基于上下文的重排等,也会带有一些多跳的搜索。
  • Modular RAG :发展出更多更灵活的模块,支持多种检索方式,使得RAG系统更为灵活泛化。
  • Graph RAG :引入图进行信息建模,支持更为复杂的推理。

大致的类目可以参考吧,但是这篇文章对这4个类目的边界划分以及评价,尤其是前三个的优缺点分析,我自己不敢苟同,前3者的划分我自己比较认同这两篇文章的描述(前沿重器[40] | 高级RAG技术——博客阅读前沿重器[41] | 综述-面向大模型的检索增强生成(RAG)),详细的每个阶段的边界,大家可以仔细体会上面的划分和这两篇文章内的差别。

不过上述4个阶段下来,RAG仍然存在一些问题:

  • 上下文内容整合。即多次检索以及检索策略下获取的内容,并没有进行完整的、贯通地整理,来协助大模型做推理。
  • 可拓展性和延迟问题。随着数据规模扩大,查询和排序的会非常耗费时间。(说实话,现在的RAG里面,更多的耗时其实还是在大模型上,一般的检索查询,只要做的比较好,基本在1s内就能一次检索的所有任务,除非搜索内大模型用的过多或者是搜索引擎做得很差)
  • 一般的RAG对工作流的适应能力较低,不同任务需要尽可能定制工作流,难以应对现实复杂动态的任务。

这便是作者认为的Agentic RAG的机会,Agentic能让RAG系统更灵活地应对复杂任务。

Agent的核心原则和背景

在进一步讨论Agentic RAG之前,还需要把Agent讲明白。AI Agent主要由如下部分组成:

  • 具备任务或角色定义的大模型。智能体的主要推理引擎和对话接口,需要理解并完成用户问题,并生成回复以确保对话流畅性。
  • 记忆系统。保存交互过程中上下文和相关数据。
  • 规划器。通过反思、查询路由、自我批评等模式,引导智能体迭代推理过程,把复杂问题分解成可管理的步骤。
  • 工具利用。拓展RAG能力范围,使之不局限在文本生成,还能访问外部资源或者其他专业计算。

picture.image

在这几个组分的通力合作下,Agent形成了4个关键模式,可用于完成整个推理的工作流。

  • 反思能力。引入反思能力,能让模型不断自我评估并完善其输出结果。
  • 规划能力。能把困难问题拆解成几个简单可控的小问题,提升其解决核心难题的能力。
  • 工具使用。Agent具有意识,会选用特定的工具完成特定的问题,将其整合进入系统后,便能更便利地完成任务。
  • 多智能体。多个智能体之间能配合。

基于此,构造了很多Agent的工作流模式,用以应对不同的任务:

  • 提示词链接(Prompt Chaining) :利用提示词串联多个任务,这个任务构造起来相对比较简单,但耗时会很长。
  • 路由(Routing) :对query进行分类,将query分发到合适的处理流程下来完成。(这个事放以前就叫做意图识别...)
  • 并行化(Parallelization) :将任务同时分发给多个模块,分段并行处理,并通过投票等方式进行合并。
  • 编排者-工作者模式(Orchestrator-Workers) :构造一个自动化任务编排的模块,动态分解任务,并分别执行。
  • 评估者-优化者(Evaluator-Optimizer) :循环进行生成、反思,对提升回复质量有好处。

Agentic RAG系统分类体系

基于这些工作流模式,我们就可以把Agentic RAG构造出来。

单Agent的Agentic RAG:路由模式

在query进来后,用路由进行决策分类,使用合适的数据源进行查询,最后利用大模型进行整合回复。

picture.image

这个模式的关键特性如下:

  • 集中化的简洁性。
  • 效率和资源的优化。
  • 动态路由能力。
  • 多样化工具支持。
  • 适合简化系统。

多智能体的Agentic RAG系统

为了处理更复杂的场景,构造了多个agent,能分别处理更多任务。

picture.image

从图中可以看到,作者把多个工具分别拆开,由路由进行多个任务的分配。其特点和优势如下:

  • 模块化设计。
  • 良好的可拓展性。
  • 任务专业化。
  • 处理效率。
  • 应用多样性。

但也存在问题。

  • 协调复杂性。
  • 计算开销大。
  • 数据整合难度。

层次化Agentic RAG

对Agent划分层级,高层Agent负责监督并对底层Agent内容进行整合,底层Agent负责执行小任务。看着就是对多智能体的Agentic RAG系统的进一步升级,对路由等模块进行进一步丰富,自己就变成更为完善的Agent。

picture.image

Agentic 纠正式 RAG

参考前面Evaluator-Optimizer的模式,对大模型的结果进行不断地迭代更新自我纠正,提升回复质量,重点考虑文档相关性、查询优化增强、外部知识动态检索、响应综合生成,这个思想在self-RAG、CRAG之类的文章里也有提到(前沿重器[42] | self-RAG-大模型决策的典型案例探究前沿重器[43] | 谷歌中科院新文:CRAG-可矫正的检索增强生成)。

图RAG

文章中把Agent-GGeAR 分开讲了,我此处一起讲,前者强调把图知识库放入RAG系统里,后者则是考虑图的检索机制。

picture.image

智能体文档工作流

在文档处理的流程内融入Agent的思想进行处理,主要包括:

  • 文档解析和信息结构化。
  • 跨流程状态管理。
  • 智能知识检索。
  • 智能体协调管理。
  • 可操作输出生成。

读到这里,总让我感觉,这里很多部分其实和Agent好像并不相干,或者说这些概念似乎在Agent概念出来之前就已经有的,例如文档解析和信息结构化。

Agentic RAG的应用场景

在这章,作者列举了多个场景大量的应用案例,举一些例子:

  • 客户支持与虚拟助手:例如能通过网络搜索等方式获取实时数据并制定销售策略或回复用户问题。
  • 通过病史与医疗知识,帮助病人进行个性化医疗。
  • 根据法律和客户实际情况进行法律咨询问答。
  • 金融和风险分析,简化某些手续的流程,提升效率。

Agentic RAG工具

最后作者提供了一些工具和数据,数据不再赘述了,但是工具大家可以参考,大部分其实还是我们比较熟悉的部分吧:

  • LangChain和LangGraph
  • LlamaIndex
  • Hugging Face Transformers和Qdrant
  • CrewAI和AutoGen
  • OpenAI Swarm
  • Vertex AI
  • Semantic Kernel
  • Amazon Bedrock
  • IBM Watson
  • Neo4j与向量数据库

文章读完后自己的想法

终于写到这部分了,可以自己多发挥一些,说说自己的看法。

首先,很重的感觉,感觉整个Agentic RAG下的很多技术,甚至是Agent下,很多都不是什么很新的东西,只是经过包装和整合融入到这个体系里面,实际上这些技术在很多场景下的任务,甚至就是RAG下,就有被广泛使用。举例子,路由模式,说白了就是把大的搜索任务进行拆分,拆成多个小任务专项处理以达到提升上线的效果,路由说白了就是意图识别,后续的多智能体下的每个“智能体”,就是每个“意图”下专项处理的定制模块,在对话系统里通常叫做“技能”,内部的所谓各种搜索、计算工具,也在众多对话系统和搜索系统中被广泛使用。与之类似的,类似Agentic纠正式,在之前的prompt工程(前沿重器[55] | prompt综述的解释和个人思考)有提到的Self-Criticism,都有这个思想在内,甚至是完全一样。

进一步,有一种神奇的体验,因为阅历和经历的积累,其实已经积累了不少技术,而在后续看到很多新的东西后,发现里面有挺多内容都是之前已经玩过的,而经过新的包装和组合,能够达到更加优秀的结果,尤其是思想上的,例如同样是意图识别,现在仍旧是有必要使用的,思想层面可以理解为“拆分”的分治思想,将场景细分后专门处理,能有效提升各自的效果,这种模式逐步做好能提升整个系统最终的效果。

不知道为什么,Agent也好还是前面的模块化RAG也好,有几个现象。

  • 不太关注中间结果。任务的拆分、各自子任务的处理结果等,在Agent里尤其明显,在现实应用中,一个是子任务的拆分边界一般难以确定,另一个则是误差累计,很多时候尽管流程很合理但是落到最终会存在效果累计,或者是尽管指标很好看但实际上有严重问题,很多时候指标的解释很单薄,例如仅仅偏差一点和完全不对都算错,但是体现不出来,最终的大模型整合又会掩盖一些问题,导致潜在风险很高。这个效果监控的意识,某种程度是一名算法工程师应有的意识。
  • 过分信任大模型。大模型的能力诚然很强,但是直接在线地进行拆分、执行,在现阶段仍旧无法完全信任,尤其是步骤比较多的流程,大模型在开放域下效果很好但是在垂直领域,每个行业有自己的“江湖规矩”,例如某些业务流程,或者是日新月异的各种规定,这些规则的说法,大模型的适应能力非常有限,进一步仍旧需要微调、RAG(其实就是套娃,但很有必要)之类的机制来规范。

Agent的规划能力,确实能给人带来很多启发。尽管直接上线有一些风险,但是在离线下,我们可以参考大模型的建议做任务的划分和拆分,有一些抽取、检索的任务我们再根据实际情况来选型,总之就是多一些思路的参考。

虽然前文我有说到现有的很多架构、模块了设计的思想并不新鲜,但是对新人而言肯定还算是新东西,我们也不能因为东西老了之类的原因就不学,当个思想被多个场景或者时代所认可(殊途同归吧算是,我自己也感觉找到这种共同点后对这些东西的理解又高了一层),足以说明其含金量,再者Agent的一些概念解释某种程度相比原有的技术下沉了很多(应该就是为了方便传播的),变得更加通俗,借此进行提炼学习的作用还是很大的,因此,Agent有关技术还是有必要看的。

回到论文本身,这篇论文在前半段,在研究的历史、RAG技术发展历程上,是有比较完善的总结的,但是后续的组件、思路包括后续的应用,其实并没有达到“综述”的水平,更多是一些标杆论文的展示,没有形成很明确的或者方向思路,一定程度可能是因为Agentic RAG有关概念和论文的数量不足,还有待积累吧。另外有一些概念和总结的说法,可能还存在争议,我自己是感觉可以更多阅读一些论文或综述在一起看会更好一些。

picture.image

0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
火山引擎大规模机器学习平台架构设计与应用实践
围绕数据加速、模型分布式训练框架建设、大规模异构集群调度、模型开发过程标准化等AI工程化实践,全面分享如何以开发者的极致体验为核心,进行机器学习平台的设计与实现。
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论