多智能体微调实践：α-UMi 开源

01

背景

近年来，为了加强大型语言模型(Large-Language Models, LLM）实时信息处理、解决专业问题的能力，催生了工具调用智能体（Tool Integrated Agent）概念，该方向旨在让LLM智能地决定何时及如何利用外部工具解决复杂问题。目前工具调用智能体的研究不仅限于闭源LLM如GPT-4，还聚焦于通过在工具使用数据集上微调开源LLM，开发可定制化工具调用智能体系统，以实现更广泛的应用场景。

工具调用智能体的复杂性在于，它要求LLM不仅要准确理解用户的查询意图，还要具备高超的任务规划能力、精准的工具选择与调用技巧，以及出色的总结归纳技能。其中，任务规划依赖于模型的逻辑推理能力；工具的选择与调用，则考验模型能否准确无误地编写请求；而工具调用结果的总结，则是对模型归纳总结技能的一次全面检验。传统的方法往往试图在单个开源LLM框架内整合所有这些复杂的能力，这一做法在面对容量更小的小型开源LLM时，其性能局限性尤为突出。

更为严峻的是，现实世界中的工具更新迭代速度极快，这意味着一旦外部工具发生变化，整个LLM系统可能都需要重新训练和调整，这不仅耗费大量资源，也给模型的维护和升级带来了前所未有的挑战。因此，如何设计出既能保持灵活性和适应性，又能有效应对工具更新带来的挑战的LLM代理系统，成为了当前研究亟待解决的关键问题。

为了应对上述的挑战，通义实验室提出了一种名为“α-UMi”的多LLM工具调用智能体框架。“α-UMi”将单一LLM的能力分解为三个部分模型执行：规划器、调用器和总结器。每个部分由单个LLM执行，专注于特定的功能。规划器依据系统当前状态生成策略，决定是否选择调用器或总结器生成后续输出。调用器根据策略调用具体工具，而总结器则在规划器的指导下，根据执行轨迹构建最终的用户答案。这些组件协同工作，共同完成任务。与先前的方法相比，α-UMi框架具有三大优势：

• 每个组件针对特定角色进行训练，确保了各自功能的优化。
  
• 其次，模块化设计允许各组件按需独立更新，保证了系统的适应性和维护效率。
  
• 由于每个组件聚焦于单一功能，缓解了模型等容量限制，意味着可以在小型LLM对工具调用智能体进行部署。
  

同时，为了有效训练这一多LLM框架，α-UMi引入了一种全新的全局到局部渐进式微调策略（GLPFT），以渐进式的增加多LLM对工具调用任务的整体理解和对单一子任务的性能提升。

总之，研究工作做出了三项重要贡献：

• 本研究揭示了小型LLM在工具学习方面的弱点，并提出了“α-UMi”多LLM框架，该框架在工具使用方面超越了现有的单一LLM方法。
  
• 本研究提出了一种GLPFT微调策略，该研究是训练多LLM框架的有效实践策略。
  
• 本研究进行了深入分析，探讨了数据放缩定律，并探究了多LLM框架性能优越性背后的原理。
  
• 
  

完整内容详见研究工作：

Small LLMs Are Weak Tool Learners: A Multi-LLM Agent

• https://arxiv.org/pdf/2401.07324
  
• modelscope paperreading：
  

https://modelscope.cn/papers/30539/summary

02

方法

α-UMi 多LLM框架

传统的工具学习智能体系统广泛采纳了ReACT框架，其核心是一个大语言模型。在接收到用户指令和系统提示后，智能体逐步解决问题。在第步中，LLM根据当前指令和系统状态生成推理依据和动作：

其中，代表前一步骤的执行轨迹。α-UMi框架对上述ReACT过程进行了拆分，以缓解工具调用智能体的复合能力需求对单个小模型对工作负载。该框架将工具学习任务分解为三个子任务，并将每个子任务分配给专门的LLM。图2展示了α-UMi的框架示意图，它包含三个独立的LLM组件：规划器、调用器 以及总结器 。每个组件模型都有其独特的任务定义、系统提示和模型输入。当接收到用户指令后，规划器逐步生成推理依据。调用器模型接收推理依据并调用工具，这种规划器-调用器-工具的迭代循环持续进行，直到规划器判断已收集到足以解决指令的信息为止。此时，规划器指导总结器生成最终答案。

全局-局部渐进式微调策略GLPFT

有效地微调上述多模型协作系统是一项复杂的任务：一方面，在训练过程中，推理依据、动作和最终答案可以相互促进，增强模型对整个代理任务的理解。另一方面，模型容量的限制使得在我们很难微调小模型同时在生成推理依据、动作和最终答案上达到性能峰值。鉴于这两点考虑，α-UMi提出了一种从全局到局部的渐进式微调（GLPFT）策略。这一策略背后的动机是首先利用推理依据、动作和最终答案生成过程中的相互增强机制。然后，一旦单一语言模型达到其性能上限，就将其拆分为规划器、调用器和总结器进行进一步的微调，以增强其在子任务上的能力，并缓解因模型容量有限导致的性能约束。

如图3所示，这一GLPFT策略包含了两个不同的阶段。第一阶段为全局微调，在该阶段中，LLM底座在原始训练数据集上进行微调，不区分具体的子任务。经过这一阶段后，LLM底座具备了如ReACT范式按顺序输出推理依据、动作和答案的能力。接着进入第二阶段：局部微调，在该阶段中，创建了三个一阶段微调结果的副本，分别作为规划器、调用器和总结器，并根据每个LLM的角色重新组织训练数据集。随后，分别对规划器、调用器和总结器在其子任务数据集上进行微调，以进一步增强它们在各自子任务上的特定能力。

下图的训练loss曲线展示了当单模型agent底座在第2个epoch结束之后拆分成planner、caller和summarizer三个模型，并获得进一步的优化空间。也揭示了这种多阶段训练的本质：当单模型agent在工具调用agent任务中到达性能上界之后，通过进一步拆分和子任务微调，多模型协作agent能够在各个子任务中获得更好的表现。

03

效果评测

静态评估

在静态评估中，本文主要在ToolBench上与其他闭源大模型和开源单模型智能体方案进行了对比，并对多项子能力进行的细粒度评价：规划准确度、动作准确度、幻觉率、工具调用参数准确度、生成回答准确度。具体实验结论如下：

• α-UMi系统表现显著超过了ChatGPT 和工具调用开源模型ToolLLaMA，性能与GPT-4比肩。值得一提的是，ToolLLaMA需要8192的输出长度以获得令人满意的结果，当输入长度为4096时，其效果急剧下降，幻觉率飙升，而对比之下α-UMi只需要4096的输入长度，这得益于多模型框架带来的更灵活的prompt设计。
  
• 对比本文作者团队复现的单模型agent框架，α-UMi也取得了性能的显著提高。
  
• 在多模型协作框架模型的微调方案对比上，直接微调三个模型、或单个模型多任务微调均无法使多模型协作框架发挥效果，只有使用多阶段微调GLPFT才能达到最佳性能，突出了文章提出的GLPFT在多模型协作框架微调中的必要性。
  

动态评估

单纯与标注比对无法全面展示agent框架性能，因此作者也在ToolBench数据集上引入了一种真实api调用的评估方式，该评估方式对比agent框架完成任务的成功率（pass rate）和agent框架与标准baseline框架（ChatGPT-ReACT）对比的胜率（win rate）。实验结果如下：

在该真实api调用实验结果中， α-UMi依然战胜了ChatGPT和ToolLLaMA，并在成功率上取得了与GPT-4相当的结果。

数据放缩定

通过比对不同训练数据下的模型表现，我们可以发现两点结论：

除了rouge-L指标外，多模型协作的α-UMi在不同训练数据量、不同指标下都一致地超过了单模型agent架构。特别是在Plan ACC和Aug F1这类关系到工具调用agent到规划能力和工具调用能力的指标上，α-UMi对比单模型agent的表现提升更加明显，反映了文章提出的多模型协作架构对于工具调用agent的适用性。

可以观察到，单模型agent在各项指标上达到峰值所需的数据量是不同的，而α-UMi却能随着数据量的增加，在各个指标上都获得稳定的表现提升，这更加凸显了多模型协作的必要性：我们很难找到一个在所有指标上达到峰值的数据量和模型检查点，而通过多模型协作，我们可以解决这个问题。

开销分析

多模型协作会引入更多成本，作者探究了多模型协作框架在训练、推理及储存阶段的开销对比：

总体来说，多模型协作框架确实会在训练和模型参数储存上引入更高的开销，但其推理速度与单模型框架相当。当然，考虑到多模型协作agent框架使用7B底座的性能远超13B单模型agent性能，总开销也更少。这意味着我们可以选择小模型为底座的多模型协作agent框架来降低开销，并超过大模型的单模型agent框架。

样例分析

下面让我们来看几个系统执行的记录，首先是一个简单的case：

在上面的case里，用户在指令中指定了可用的一些工具，让工具调用流程变得更简单，α-UMi框架也在planner，caller和summarizer的协作中在两步之内完成了工作。

当然，现实中更复杂的情况是：用户没有指定工具，需要系统自己选择工具，并且由于工具状态变化，经常会出现工具被下架或工具所需参数定义变化等情况。让我们来看看在这种情况下α-UMi是如何通过反思解决问题的：

在上面这个case中，α-UMi在第0步试图使用video_for_simple_youtube_search来获取视频详细信息，但发现这个api已经被破坏，无法调用，因此planner转换思路，告诉caller需要尝试另外一个api，并最终通过尝试新的api发现了详细信息，最终解决了用户的任务。

04

代码实践

代码框架：

https://github.com/X-PLUG/Multi-LLM-Agent

魔搭社区开源模型：

• 一阶段微调底座-7b：https://modelscope.cn/models/iic/alpha-umi-backbone-7b
  
• 规划器模型-7b：https://modelscope.cn/models/iic/alpha-umi-planner-7b
  
• 调用器模型-7b：https://modelscope.cn/models/iic/alpha-umi-caller-7b
  
• 总结器模型-7b：https://modelscope.cn/models/iic/alpha-umi-summarizer-7b
  

魔搭社区开源数据：https://modelscope.cn/datasets/iic/toolbench_for_alpha_umi

一阶段全局微调

cd ./GLPFT
LLAMA_PATH="" # your path for initial LLM checkpoint
NNODE=8
PORT=12345
BSZ=6
GA=1
EXP_NAME=/toolbench/backbone  # path to save model
export PYTHONPATH=./
torchrun --nproc_per_node=$NNODE --master_port=$PORT train_mem.py \
    --model_name_or_path $LLAMA_PATH  \
    --data_path dataset/toolbench/train/train_backbone.json\
    --output_dir saved_models/$EXP_NAME \
    --num_train_epochs 2 \
    --per_device_train_batch_size $BSZ \
    --per_device_eval_batch_size $BSZ \
    --gradient_accumulation_steps $GA \
    --evaluation_strategy "no" \
    --eval_steps 0 \
    --save_strategy "steps" \
    --save_steps 500 \
    --save_total_limit 8 \
    --learning_rate 5e-5 \
    --warmup_ratio 0.4 \
    --lr_scheduler_type "cosine" \
    --gradient_checkpointing True \
    --deepspeed ds_configs/stage3-a100.json \
    --bf16 \
    --logging_steps 2 \
    --model_max_length 4096 \
    --report_to none \
    --lazy_preprocess True

二阶段局部微调

cd ./GLPFT
NNODE=8
PORT=12345
BSZ=6
GA=1
BB_PATH="saved_models/toolbench/backbone"
EXP_NAME=/toolbench/planner
export PYTHONPATH=./
torchrun --nproc_per_node=$NNODE --master_port=$PORT train_mem.py \
    --model_name_or_path $BB_PATH  \
    --data_path dataset/toolbench/train/train_planner.json \
    --output_dir saved_models/$EXP_NAME \
    --num_train_epochs 1 \
    --per_device_train_batch_size $BSZ \
    --per_device_eval_batch_size $BSZ \
    --gradient_accumulation_steps $GA \
    --evaluation_strategy "no" \
    --eval_steps 0 \
    --save_strategy "steps" \
    --save_steps 500 \
    --save_total_limit 8 \
    --learning_rate 1e-5 \
    --weight_decay 0.01 \
    --warmup_ratio 0.2 \
    --lr_scheduler_type "cosine" \
    --gradient_checkpointing True \
    --bf16 \
    --logging_steps 2 \
    --model_max_length 4096 \
    --report_to none \
    --lazy_preprocess True
EXP_NAME=/toolbench/caller
export PYTHONPATH=./
torchrun --nproc_per_node=$NNODE --master_port=$PORT train_mem.py \
    --model_name_or_path $BB_PATH  \
    --data_path dataset/toolbench/train/train_caller.json \
    --output_dir saved_models/$EXP_NAME \
    --num_train_epochs 1 \
    --per_device_train_batch_size $BSZ \
    --per_device_eval_batch_size $BSZ \
    --gradient_accumulation_steps $GA \
    --evaluation_strategy "no" \
    --eval_steps 0 \
    --save_strategy "steps" \
    --save_steps 500 \
    --save_total_limit 8 \
    --learning_rate 1e-5 \
    --weight_decay 0.01 \
    --warmup_ratio 0.2 \
    --lr_scheduler_type "cosine" \
    --gradient_checkpointing True \
    --bf16 \
    --logging_steps 2 \
    --model_max_length 4096 \
    --report_to none \
    --lazy_preprocess True
EXP_NAME=/toolbench/summarizer
export PYTHONPATH=./
torchrun --nproc_per_node=$NNODE --master_port=$PORT train_mem.py \
    --model_name_or_path $BB_PATH  \
    --data_path dataset/toolbench/train/train_summarizer.json \
    --output_dir saved_models/$EXP_NAME \
    --num_train_epochs 2 \
    --per_device_train_batch_size $BSZ \
    --per_device_eval_batch_size $BSZ \
    --gradient_accumulation_steps $GA \
    --evaluation_strategy "no" \
    --eval_steps 0 \
    --save_strategy "steps" \
    --save_steps 500 \
    --save_total_limit 8 \
    --learning_rate 1e-5 \
    --weight_decay 0.01 \
    --warmup_ratio 0.4 \
    --lr_scheduler_type "cosine" \
    --gradient_checkpointing True \
    --bf16 \
    --logging_steps 2 \
    --model_max_length 4096 \
    --report_to none \
    --lazy_preprocess True

点击链接👇，直达开源地址

https://github.com/X-PLUG/Multi-LLM-Agent?from=alizishequ__text