LLM Agent 指令微调与搜索代理方案

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

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

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，指令微调的方案有以下优势：

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

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

搜索 Agent 方案

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

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

我们先来看个例子，如果想回答 LK99 哪些板块会涨，你会得到以下搜索答案。从以上的搜索结果不难发现，Top1 答案并不能回答问题。在和搜索引擎交互中几个可能的问题有：

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

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

1. Search（搜索）

生成搜索请求 query，或基于结果进行 query 改写，请求搜索 API。类似 self-Ask 里面的 Thought，只不过 self-ask 强调问题拆解，而这里的 search 还有 query 改写、追问等功能。这要求模型具备理解用户意图并将其转化为搜索引擎可识别关键词的能力。

2. Retrieve（检索）

从搜索返回的大段内容中，定位可以回答 query 的支撑性事实，进行抽取式摘要、生成式摘要。类似 React 里面的 LookUp 行为，只不过更加复杂不是简单的定位文字。这一步通常需要结合 RAG（检索增强生成）技术，利用向量数据库或关键词匹配来提取高相关性片段。

3. Synthesis（综合）

对多个内容进行组装，输入模型进行推理得到答案。当检索到的信息分散在不同来源时，模型需要整合这些信息，消除矛盾，形成连贯的回答。这涉及到上下文窗口管理和信息融合策略。

4. Action（行动）

针对需要和搜索引擎进行自动化多轮交互的场景，需要预测下一步的行为，是继续搜索，抽取摘要，还是停止搜索，组装内容进行推理等等，对应 LLM Agent 中的规划模块。其实就是丰富了 React/SelfAsk 里面的 Action，加入了更多和搜索引擎交互的行为，例如继续浏览、翻页、点击链接等。

虽然论文的发布顺序是 webcpm > WebGLM > WebGPT，但考虑 webcpm 开源了很全面的中文数据，我会以 webcpm 作为基准详细介绍，再分别介绍 WebGLM 和 WebGPT 的异同点。这些工作共同推动了 Agent 从单一工具调用向复杂任务规划的演进。

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