LLM Agent-指令微调方案

上一章我们介绍了基于Prompt范式的工具调用方案，这一章介绍基于模型微调，支持任意多工具组合调用，复杂调用的方案。多工具调用核心需要解决3个问题，在哪个位置进行工具调用(where), 从众多工具中选择哪一个(Which), 工具的输入是什么(What)。Where + Which + What，我称之为3W原则，3H它兄弟哈哈哈哈~

其实如何教大模型使用工具，和教人类使用工具没啥区别。就像上周末我想给我妈买的可以防弹，超重的岩板餐桌按个滑轮需要使用电钻，那我学习使用电钻的途径无非有三种

基于历史经验：我之前都是手动的没用过电动的，我凭借自信直接上手结果拧歪了......对应到LLM其实就是本章要提到的工具微调，我们让模型先学习在在不同的场景使用什么工具，如何使用，再利用大模型的迁移泛化能力泛化到更多的场景。
从工具说明书中学习：我去翻了翻说明书，奈何写的太抽象没看懂......对应到LLM简单版的就是上一章的zero-shot prompt方案，告诉大模型工具的使用场景和用法；升级版就是之后会提到的优化方案，我们可以动态召回工具的完整说明书和使用范例作为上文输入模型
通过观察他人使用工具来学习：最终我打开小红书看短视频学习了下，一点就通，于是我拥有了可丝滑移动的防弹餐桌！对应到LLM简单版就是上一章介绍的few-shot prompt方案，我们让LLM看到在其他场景它是如何使用工具的；升级版就是之后会提到的动态few-shot prompt的方案。

下面我们看下通过微调为模型注入工具使用经验的两个方案：Toolformer和Gorilla

Toolformer

TALM: Tool Augmented Language Models

Toolformer: Language Models Can Teach Themselves to Use Tools

填充式工具使用 + InContext制造自监督样本

Toolformer是工具调用领域的前辈，使用LM监督微调得到可以进行Inline工具调用的模型。解码时，模型会在恰当的位置生成API调用的请求，并中止解码，去调用API得到返回值，把返回值拼接到"->"字符之后，再继续模型解码，如下

Toolformer的创新主要在API调用的样本构造，因此我们先来看下样本构造的部分

样本

Toolformer单一API的样本构造主要包含以下3个步骤

Sampling API

以QA API为例，作者会先编写几个样本作为In-Context，得到以下的FewShot指令样本

然后针对新的长度为N的输入文本，作者会计算每个位置得到<API>前缀的条件解码概率，并保留超过阈值的TopK个最优可能出现<API>的位置。然后每个位置，基于上文，让模型随机解码m次生成m个候选的API调用请求。这样我们就得到了候选样本集，每一段文本，最多有K个可能进行工具调用的位置，且每个位置有至多m个候选请求{c1,...cm}。

Executing API Calls

执行以上得到的候选请求，每个请求得到一个对应的返回值{r1,....rm}。可以是计算器的结果，维基百科的搜索返回等等

Filtering API Calls

最后是过滤筛选，原理是好的工具调用样本，应该会让工具调用位置后面的文本解码概率提高，Perplexity降低。因此作者计算了在工具调用位置之后，所有token的加权条件解码概率。

以上加权的权重计算如下，离工具调用位置越远权重越小

条件解码概率的条件Z，分别是[工具调用+返回值]，[工具调用+无返回值]，[无工具调用]，这三者中Loss较小的一个,过滤方案是[工具调用+工具返回值]的Loss降幅超过阈值，则保留该样本

整体量级上，1个API生成了25K左右的样本用于微调，样本长度1024

微调

使用以上样本生成方案得到多API调用的样本集混合后得到增强训练样本。样本的构建方式是在原始文本中直接插入API调用的语句x1:i−1,e(ci,ri),xi:n�1:�−1,�(��,��),��:�,如下

The Nile has an approximate length of QA(What is the approximate length of the Nile?)->6,853 km 6,853 kilometers, the White Nile being its main source

这样通过微调，模型会学习到在什么位置使用什么样的工具，以及工具的请求输入。同时和解码的格式保持一致，后文会依赖API调用结果进行解码。微调使用了GPT-J模型，Batch=128， lr=1e-5，warmup=10%，训练了2K step，常规的LM Loss.

总结

Toolformer的创新主要在使用模型的Few-shot理解能力，使用少量的人工标注样本制造大量的自监督样本。这样Tooformer理论上可以支持任意的API工具。但Toolformer有一些局限性

工具独立：论文中每个API调用的样本是独立构造的，工具之间没有交互，且同一工具的多次调用之间也是独立，不依赖上文的调用返回。
常规解码：没有引入思维链推理，限制了最终效果

Gorilla

HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in HuggingFace

TaskMatrix.AI: Completing Tasks by Connecting Foundation Models with Millions of APIs

Gorilla：Large Language Model Connected with Massive APIs

https://github.com/ShishirPatil/gorilla

Gorilla在HuggingGPT，TaskMatrix.AI这两个API调用的前辈的基础上，加入了指令微调来提升API调用效果。Gorilla支持TorchHub，TensorflowHub，Huggingface总共1645个API，且可以泛化到新的API上。

样本

Gorilla使用Self-Instruct来构建指令样本，用的是GPT4模型。构建方案是以上3个API Hub, 每个Hub各人工编写6个指令样本。每一轮随机从6个样本中采样3个作为Few-Shot，并通过指令让GPT4随机生成10个真实世界的使用case，总共生成16450个指令样本，生成的指令样本如下

同时Gorilla加入了Retriever-Aware，也就是在以上的指令样本中，指令后面会拼接上API的使用说明:"Use this API documentation for reference: <retrieved_API_doc_JSON>"

这样在推理阶段，会先根据用户的指令召回最相关、最新的API使用说明。降低模型幻觉的同时，使得模型有更好的泛化性，可以适应全新的API接口，或者已有API接口的参数变化。

微调&推理

微调的部分比较常规就是在LLama-7B模型上，使用以下参数在8*A100(40G)进行指令微调。

在推理阶段会同样加入API Retriever根据用户的指令召回最相关的API使用说明，和用户输入拼接，喂进模型推理。召回方案作者尝试了BM25和GPT的Embedding，不过不同召回方案的效果和API本身相关，没有谁一定更好这一说。

效果上微调后7B的LLama模型使用GPT Embedding召回工具说明，在工具调用上的准确率可以显著超越GPT3.5使用Prompt方案的调用效果

总结

对比上一章基于Prompt的方案Self Ask，ReAct和这一章基于微调的方案Toolformer，Gorilla，指令微调的方案有以下优势

planning效果更好：微调方案比Prompt方案在复杂问题规划上效果更好，尤其适合本身In-Context能力有限的小模型
工具调用准确率更高：针对复杂工具调用的准确率更高
不受模型迭代影响：GPT3.5->GPT4的升级，让不少基于Prompt指令的应用们需要集体进行prompt调整，因为模型指令变了.......以及不同模型之间的指令或有不同。但微调方案不受这一点影响，因为指令微调本身就是对齐的过程，因此更robust

缺点自然是没有开箱即用的Prompt方案灵活，所以不妨用prompt方案来进行前期测试，后期用微调来提升效果。

但其实不论是prompt方案还是微调方案，其实都是LLM Agent应用中的工具调用规划这一个子模块，要真正搭建可以落地的大模型应用，需要更系统的整体设计，这块我们放在下一章说~

前两章，我们分别介绍了基于微调和prompt的工具调用方案，核心都是如何让大模型和工具进行交互，包括生成工具调用语句和处理工具调用请求。不过在实际应用中，想要设计一个可以落地的LLM Agent，需要更全面整体的系统设计。本章我们以搜索工具为例，介绍如何更好和搜索引擎进行交互的LLM Agent。

搜索Agent方案

为啥需要整体方案，直接调用搜索接口取Top1返回不成嘛？要是果真如此Simple&Naive，New Bing岂不是很容易复刻->.->

我们先来看个例子，前一阵火爆全网的常温超导技术，如果想回答LK99哪些板块会涨，你会得到以下搜索答案

从以上的搜索结果不难发现，Top1答案并不能回答问题，在和搜索引擎交互中几个可能的问题有

Query：用户的query不适配搜索引擎，导致搜索不到有效内容；或者问题需要通过类似Self Ask的思维链拆解通过多轮搜索来解决
Ranking：细看langchain的搜索Wrapper，会发现它默认只使用搜索的Top1返回，但是除了传统百科问题，这类问题因为做过优化，Top1往往是最优答案。但其他场景，例如当前问题，第三个内容显然更合适。当前传统搜索引擎并非为大模型使用设计，因此需要后接一些优化排序模块，例如REPLUG论文
Snippet: Bing的网页标题下面会默认展示150字左右根据query定位的正文摘要内容，也是langchain等框架使用的网页结果。但是不难发现，snippet太短或者定位不准会导致snippet缺乏有效信息

为了解决上述提到的3个主要问题，我们会基于WebGPT，WebGLM，WebCPM的3篇论文，详述如何更有效的和搜索引擎进行交互，来解决长文本开放问答LFQA问题。和搜索引擎的交互主要分成以下4个模块

Search：生成搜索请求query，或基于结果进行query改写，请求搜索API。类似self-Ask里面的Thought，只不过selfask强调问题拆解，而这里的search还有query改写，追问等功能
Retrieve：从搜索返回的大段内容中，定位可以回答query的支撑性事实，进行抽取式摘要、生成式摘要。类似React里面的LookUp行为，只不过更加复杂不是简单的定位文字。
Synthesis: 对多个内容进行组装，输入模型进行推理得到答案
Action: 针对需要和搜索引擎进行自动化多轮交互的场景，需要预测下一步的行为，是继续搜索，抽取摘要，还是停止搜索，组装内容进行推理等等，对应LLM Agent中的规划模块。其实就是丰富了React/SelfAsk里面的Action，加入了更多和搜索引擎交互的行为，例如继续浏览，翻页等等

虽然论文的发布顺序是webcpm>webglm>webgpt，但考虑webcpm开源了很全面的中文数据哈哈，手动点赞！我会以webcpm作为基准详细介绍，再分别介绍webglm和webgpt的异同点。