LLMs通过纯文本语言（例如英语）执行命令的能力使得能够完成用户查询的代理系统得以实现，通过协调正确的工具集合（例如ToolFormer、Gorilla）。这个能力以及最近的多模态努力，比如GPT-4o或Gemini-1.5模型，已经扩展了AI代理的可能性范围。虽然这非常令人兴奋，但这些模型的庞大尺寸和计算需求通常需要在云端进行推理。这可能会为它们的广泛应用带来几个挑战。首先，将视频、音频或文本文档等数据上传到云端的第三方供应商可能会导致隐私问题。其次，这需要云端/Wi-Fi连接，这并不总是可能的。例如，部署在现实世界中的机器人可能并不总是有稳定的连接。除此之外，延迟也可能成为一个问题，因为上传大量数据到云端并等待响应可能会减慢响应时间，导致解决问题的时间不可接受。如果将LLM模型部署到边缘，这些挑战可以得到解决。
然而，目前的LLMs，如GPT-4o或Gemini-1.5，对于本地部署来说过于庞大。一个导致这种情况的因素是模型尺寸的很大一部分用于将世界的一般信息存储到其参数内存中，这对于特定的下游应用可能并不是必要的。例如，如果你向这些模型提出一个关于历史事件或著名人物的一般事实问题，它们可以使用其参数内存产生结果，即使在提示中没有额外的上下文。然而，这种将训练数据隐式存储到参数内存中的现象与LLMs中的“出现”现象相关，例如上下文学习和复杂推理，这已经成为扩展模型尺寸的推动力。
然而，这引出了一个有趣的研究问题：
一个参数内存显著较少的小型语言模型能否模拟这些较大语言模型的这种出现能力？
实现这一点将显著减少代理系统的计算占用，并因此实现高效和隐私保护的边缘部署。研究表明，通过对不需要回忆通用世界知识的专门化、高质量数据进行训练，这对于小型语言模型是可行的。
这样的系统在语义系统中尤其有用，其中AI代理的角色是理解用户以自然语言提出的查询，并且不是用ChatGPT类型的问答响应来回答，而是协调正确的工具集合和API来完成用户的命令。例如，在类似Siri的应用程序中，用户可能会要求语言模型创建一个具有特定与会者的日历邀请。如果已经存在用于创建日历项的预定义脚本，那么LLM只需要学会如何使用正确的输入参数（例如与会者的电子邮件地址、事件标题和时间）来调用此脚本。这个过程不需要从维基百科等来源回忆/记忆世界知识，而是需要推理和学习如何调用正确的函数并正确协调它们。
教LLMs进行功能调用
图1：LLMCompiler功能调用规划器概述。该规划器理解用户查询并生成一系列具有相互依赖关系的任务。然后，LLMCompiler框架分派这些任务以完成用户命令。在这个示例中，任务2被一起获取以独立检索Sid和Lutfi的电子邮件地址。在执行每个任务后，结果被转发到创建日历事件的任务3之前，LLMCompiler会用实际值替换占位符变量（例如，在任务1和$2）。
如上所述，主要关注的是将用户查询转换为一系列函数调用以完成任务的应用程序。在这种应用程序中，模型不需要自己编写函数定义，因为这些函数（或API）大多是预定义的并且已经可用。因此，模型需要做的是确定（i）调用哪些函数，（ii）相应的输入参数，以及（iii）根据函数调用之间所需的相互依赖关系确定调用这些函数的正确顺序（即函数编排）。
第一个问题是找到一种有效的方法来使SLMs执行函数调用。像GPT-4这样的大型模型能够执行函数调用，但是如何才能用开源模型实现这一点呢？LLMCompiler是研究人员最近提出的一个框架，它通过指示LLM输出一个包含它需要调用的函数集合以及输入参数和它们的依赖关系的函数调用计划来实现这一点（参见图1中的示例）。生成了这个函数调用计划后，可以解析它并根据依赖关系调用每个函数。
关键部分在于教会模型使用正确的语法和依赖关系创建这个函数调用计划。原始的LLMCompiler论文只考虑了大型模型，如LLaMA-2 70B，当在提示中提供足够的指令时，这些模型具有复杂的推理能力来创建计划。然而，小型模型是否可以通过相同的方式提示以输出正确的函数调用计划呢？不幸的是，实验表明，诸如TinyLLaMA-1.1B（甚至更大的Wizard-2-7B模型）之类的现成的小型模型无法输出正确的计划。错误的范围包括使用错误的函数集、虚构的名称、错误的依赖关系、不一致的语法等。
这是可以预料的，因为这些小型模型是在通用数据集上进行训练的，主要是为了在一般基准测试中实现良好的准确性，这些测试主要测试模型的世界知识和一般推理或基本指令遵循能力。为了解决这个问题，研究人员探索了是否可以在专门为函数调用和规划而策划的高质量数据上对这些模型进行微调，从而提高这些小型语言模型对目标任务的准确性，有可能胜过更大的模型。
数据生成图2：TinyAgent是一个助手，可以与各种MacOS应用程序进行交互，以帮助用户。命令可以通过聚光灯输入或语音传达给它。
作为驱动应用程序，考虑了解决用户日常任务的苹果Macbook的本地代理系统，如图2所示。特别是，该代理程序配备了16种不同的功能，可以与Mac上的不同应用程序进行交互，包括：
电子邮件：撰写新邮件或回复/转发邮件 联系人：从联系人数据库检索电话号码或电子邮件地址 短信：向联系人发送短信 日历：创建具有标题、时间、参与者等详细信息的日历事件 备忘录：设置各种活动和任务的提醒 文件管理：在不同的文件路径中打开、阅读或总结文档 Zoom 会议：安排和组织 Zoom 会议
每个这些功能/工具都有预定义的Apple脚本，模型只需利用这些预定义的API，并确定正确的函数调用计划来完成特定任务，就像图1中所示的那样。但是正如之前所讨论的，需要一些用于评估和训练小型语言模型的数据，因为它们的现成函数调用能力不尽如人意。
创建具有不同功能调用计划的手工数据既具有挑战性，又不具备可扩展性。然而，可以使用像GPT-4-Turbo这样的LLM来策划合成数据。这种方法正在变得越来越普遍，其中一个能力强大的LLM被指示生成类似于给定样本示例或模板的数据（请参见LLM2LLM和Self-Instruct）。研究人员采用了类似的方法，但是没有向LLM提供通用的用户查询作为模板，而是提供了各种功能集，并指示它生成需要这些功能才能完成任务的逼真用户查询，以及相关的函数调用计划和输入参数，就像图1中所示的示例一样。为了验证生成数据的有效性，研究人员对函数调用计划进行了合理性检查，以确保它们形成可行的图表，以及函数名称和输入参数类型是正确的。通过这种方法，研究人员创建了80K个训练数据、1K个验证数据和1K个测试数据，总成本仅为约500美元。
为改进函数调用推理进行微调
图3：图同构成功率。仅当生成的计划的有向无环图（DAG）与地面实况计划的DAG同构时，模型的成功率才为1；否则为0。在上面的例子中，对于顶部情况，虽然获取电子邮件地址的顺序与地面实况计划不同（地面实况计划在获取Sid的电子邮件地址之前获取Lutfi的电子邮件地址，而生成的计划在获取Sid的电子邮件地址之前获取Lutfi的电子邮件地址），但由于两个DAG彼此同构，因此该计划的成功率为1。对于底部情况，由于预测的DAG包含一个错误的节点，对应错误的函数调用，因此该计划的成功率为0。
有了数据集，现在可以继续微调现成的SLMs以增强它们的函数调用能力。研究人员从两个基本的小型模型开始：TinyLlama-1.1B（instruct-32k版本）和Wizard-2-7B。对于这些模型的微调，首先需要定义一个指标来评估它们的性能。目标是使这些模型能够准确地生成正确的计划，这不仅涉及选择正确的函数集，还涉及以正确的顺序对它们进行正确的编排。因此，研究人员定义了一个成功率指标，如果两个标准都满足则分配为1，否则为0。检查模型是否选择了正确的函数集是很简单的。为了确保这些函数的编排是正确的，另外构建了一个基于依赖关系的函数调用的有向无环图（DAG），如图3所示，其中每个节点代表一个函数调用，从节点A到B的有向边表示它们的相互依赖关系（即函数B只能在函数A执行之后执行）。然后，比较这个DAG是否与地面实况计划的DAG相同，以验证依赖关系的准确性。
在定义了评估指标之后，研究人员应用了LoRA对模型进行了3个时期的微调，使用了学习率为7e-5的80K个训练示例，并根据验证性能选择了最佳检查点。对于微调，提示不仅包括地面实况函数的描述（即地面实况计划中使用的函数），还包括其他无关的函数作为负样本。研究人员发现负样本对教授模型如何为给定查询选择适当的工具特别有效，从而改善了训练后的性能。此外，研究人员还包括了几个上下文示例，展示了如何将查询转换为函数调用计划。这些上下文示例是通过基于训练数据中的用户查询的检索增强生成（RAG）过程选取的。
使用上述设置，微调了TinyLlama-1.1B/Wizard-2-7B模型。微调后，1.1B模型的成功率从12.71%提高到78.89%，而7B模型的性能从41.25%提高到83.09%，比GPT-4-Turbo高出约4%。
使用 RAG 工具进行高效推理
图4：基于用户输入的高效工具选择。并非所有用户输入都需要所有可用工具；因此，选择正确的工具集以最小化提示大小并提高性能至关重要。在这种情况下，LLM只需要在其提示中包含获取电子邮件地址和创建日历事件的函数，就可以完成其任务。
主要目标是能够在Macbook上本地部署TinyAgent模型，与像GPT这样的闭源模型部署在的GPU相比，Macbook的计算和内存资源有限。为了实现低延迟的高效性能，需要确保不仅模型大小小，而且输入提示尽可能简洁。后者是延迟和计算资源消耗的重要因素，因为注意力对序列长度的二次复杂度。
前面讨论过的微调的TinyAgent模型在其提示中包含了所有可用工具的描述。然而，这是相当低效的。可以通过仅根据用户查询包含相关工具的描述来显著减小提示大小。例如，考虑上图中显示的示例，在该示例中，用户要求创建一个与两个人的日历邀请相关的任务。在这种情况下，LLM只需要在其提示中包含获取电子邮件地址和创建日历事件的函数。
为了利用这一观察结果，需要确定完成用户命令所需的函数，将其称为工具RAG，因为它与检索增强生成（RAG）的工作方式相似。然而，有一个重要的细微之处。如果使用基本的RAG方法，其中计算用户查询的嵌入并使用该嵌入来检索相关工具，会得到非常低的性能。这是因为完成用户的查询通常需要使用几个辅助工具，如果辅助工具的嵌入与用户查询不相似，则简单的RAG方法可能会忽略这些工具。例如，上图中显示的示例需要调用获取电子邮件地址函数，即使用户查询只是询问如何创建日历邀请。
这可以通过将问题视为哪些工具是必需的分类来解决。为此，在训练数据上微调了一个DeBERTa-v3-small模型，以进行16路分类，如图5所示。用户查询作为输入提供给此模型，然后通过一个大小为768x16的简单全连接层传递最后的CLS标记，将其转换为一个16维向量（这是工具的总大小）。这一层的输出经过一个sigmoid层，产生选择每个工具的概率。在推断过程中，选择概率大于50%的工具，并在提示中包含它们的描述。平均而言，注意到仅检索到3.97个工具，召回率为0.998，而基本的RAG需要使用前6个工具才能实现0.968的工具召回率。
图5：工具RAG方案概述。将工具检索构建为一个多标签分类问题。用户查询作为输入提供给微调后的DeBERTa-v3-small模型，该模型输出一个16维向量，指示工具的概率。选择概率高于50%的工具，平均每个查询有3.97个工具，而基本RAG中有6个工具。
在整合了工具RAG后评估了模型的性能。下表显示了结果，报告了简单RAG系统以及微调后的DeBERTa方法的性能。正如大家所见，基于DeBERTa的工具RAG方法实现了几乎完美的召回性能，提高了基线准确性，同时将提示大小减少了约2倍的令牌。
表1：使用DeBERTa与基本RAG和无RAG设置进行TinyAgent性能比较。
即使对于参数为O(1B)的小型模型，在边缘部署模型，例如在消费者的MacBook上，仍然可能具有挑战性，因为加载模型参数可能会消耗可用内存的大部分。这些问题的解决方案是量化，它允许以降低的位精度存储模型。量化不仅减少了存储要求和模型占用空间，还减少了加载模型权重到内存所需的时间和资源，从而降低了整体推理延迟（有关量化的更多信息，请参见此处）。
为了更有效地部署模型，研究人员将模型量化为4位，组大小为32，这是由llama.cpp框架支持的，具有量化感知训练。如表2所示，4位模型的延迟改善了30%，同时模型大小减少了4倍。还注意到轻微的准确性提高，这是由于通过模拟量化进行了额外的微调。
表2：在量化之前和之后的TinyAgent模型的延迟、大小和成功率。延迟是函数调用规划器的端到端延迟，包括提示处理时间和生成时间。
以下是在Macbook Pro M3上部署的最终TinyAgent-1.1B模型的演示，您实际上可以下载并安装在您的Mac上进行测试。它不仅在您的计算机上本地运行所有的模型推理，而且还允许您通过音频提供命令。还在本地使用了来自OpenAI的Whisper-v3模型，使用whisper.cpp框架进行本地处理音频。1.1B模型的准确性超过了GPT-4-Turbo，并且在本地设备上部署时速度明显快。
总结一下，本文介绍了TinyAgent，并展示了确实可以训练一个小型语言模型并用它来驱动处理用户查询的语义系统。特别是，考虑了一个类似Siri的Mac助手作为驱动应用程序。启用它的关键组件是（i）通过LLMCompiler框架教授现成的SLM执行函数调用，（ii）为手头的任务策划高质量的函数调用数据，（iii）在生成的数据上微调现成的模型，以及（iv）通过一种称为ToolRAG的方法根据用户查询仅检索必要的工具来优化提示大小，以及量化模型部署以减少推理资源消耗。经过这些步骤，最终模型在此任务上实现了80.06%和84.95%的成功率，超过了GPT-4-Turbo的79.08%。
