在本篇文章中,介绍一种优化ReAct冗余问题的方法,REWOO。
一、REWOO的概念
REWOO的全称是Reason without Observation,是相对ReAct中的Observation 来说的。它旨在通过以下方式改进 ReACT 风格的Agent架构:
第一,通过生成一次性使用的完整工具链来减少token消耗和执行时间,因为ReACT模式的Agent架构需要多次带有冗余前缀的 LLM 调用;
第二,简化微调过程。由于规划数据不依赖于工具的输出,因此可以在不实际调用工具的情况下对模型进行微调。
ReWOO 架构主要包括三个部分:
- Planner:规划器,负责将任务分解并制定包含多个相互关联计划的蓝图,每个计划都分配给Worker执行。
- Worker:执行器,根据规划器提供的蓝图,使用外部工具获取更多证据或者其他具体动作。
- Solver:合并器,将所有计划和证据结合起来,形成对原始目标任务的最终解决方案。
下图是REWOO的原理:
- Planner接收来自用户的输入,输出详细的计划Task List,Task List由多个Plan(Reason)和 Execution(Tool[arguments for tool])组成;
- Worker接收Task List,循环执行完成task;
- Woker将所有任务的执行结果同步给Solver,Solver将所有的计划和执行结果整合起来,形成最终的答案输出给用户。
详细对比一下ReAct和REWOO,如下图所示。
左侧是ReAct方法,当User输入Task后,把上下文Context和可能的样本Example输入到LLM中,LLM会调用一个目标工具Tool,从而产生想法Thought,行动Action,观察Observation。由于拆解后的下一次循环也需要调用LLM,又会调用新的工具Tool,产生新的Thought,Action,Observation。如果这个步骤变得很长,就会导致巨大的重复计算和开销。
右侧ReWOO的方法,计划器Planner把任务进行分解,分解的依据是它们内部哪些用同类Tool,就把它分成同一类。在最开始,依旧是User输入Task,模型把上下文Context和Examplar进行输入。这里与先前有所不同的是,输入到Planner中,进行分解,然后调用各自的工具Tool。在得到了所有的Tool的输出后,生成计划结果Plan和线索,放到Solver进行总结,然后生成回答。这个过程只调用了两次LLM。
二、REWOO的实现过程
下面,通过实际的源码,详细介绍REWOO模式的实现方法。