任务分解与小型大语言模型如何使AI更经济实惠

生成式AI应用的广泛使用增加了对准确、经济高效的大语言模型（LLM）的需求。LLM的成本因其规模（通常以参数数量衡量）而有显著差异：切换到下一个较小规模的模型通常可节省70%–90%的成本。然而，仅使用较小、更轻量级的LLM并不总是可行，因为与最先进的“前沿LLM”相比，它们的能力有所减弱。

虽然参数规模的减少通常会降低性能，但有证据表明，专门用于执行问答或文本摘要等任务的小型LLM，在这些相同任务上可以匹配未经修改的大型前沿LLM的性能。这开启了通过将复杂任务分解为更小、可管理的子任务来平衡成本和性能的可能性。这种任务分解使得可以使用经济高效、更小、更专业的任务或领域适应LLM，同时提供控制、增加故障排除能力，并可能减少幻觉。然而，这种方法存在权衡：虽然它可以带来显著的成本节约，但也会增加系统复杂性，可能抵消部分初始收益。本文探讨了LLM任务分解中成本、性能和系统复杂性之间的平衡。

作为一个例子，将考虑使用任务分解生成个性化网站的情况，展示潜在的成本节约和性能收益。然而，也会强调过度工程的潜在陷阱，其中过多的分解可能导致收益递减甚至破坏预期收益。

一、任务分解

理想情况下，任务将被分解为彼此独立的子任务。这允许为每个子任务创建有针对性的提示和上下文，通过将故障隔离到特定子任务而不是需要分析单个大型黑盒过程，使故障排除更容易。

然而，有时无法分解为独立的子任务。在这些情况下，可能需要提示工程或信息检索来确保子任务之间的连贯性。但应避免过度工程，因为它可能不必要地复杂化工作流程。它还可能牺牲LLM通过捕捉原始任务完整上下文中的隐藏关系所能提供的新颖性和上下文丰富性。

但稍后将讨论这些点。首先，提供一个示例，其中个性化网站生成的任务被分解为一个代理工作流程。代理工作流程中的代理可能是功能代理，执行特定任务（例如，数据库查询），或模仿组织中人类角色的基于角色的代理（例如，UX设计师）。在本文中，将专注于基于角色的方法。

一个简单示例：创建个性化网站

在场景中，一家企业希望创建一个网站构建器，为个别访问者生成量身定制的网络体验，无需人工监督。生成式AI的创造性和在不确定性下工作的能力使其适合此任务。然而，控制工作流程至关重要，确保遵守公司政策、最佳实践和设计指南，并管理成本和性能。

此示例基于发布在某中心机器学习博客上的代理工作流程解决方案。对于该解决方案，将整个过程分解为通常分配给人类代理类型的子任务，例如个性化器（UX/UI设计师/产品经理）、艺术家（视觉艺术创作者）和网站构建器（前端开发人员）。

个性化器代理旨在通过考虑访问者档案以及公司的政策、产品设计和设计方法，为网站访问者提供量身定制的体验。这是一个中等大小的文本到文本LLM，具有一定的推理能力。该代理还结合了检索增强生成（RAG）来利用经过审查的“公司研究”。

以下是个性化器的示例提示：

您是一个AI UI/UX设计师， tasked with creating a visually appealing website. Keep in mind the industry pain points [specify relevant pain points — RAG retrieved] to ensure a tailored experience for your customer [provide customer profile — JSON to natural language]. In your response, provide two sections: a website description for front-end developers and visual elements for the artists to follow. You should follow the design guidelines [include relevant design guidelines].

艺术家代理的角色是将视觉元素描述反映在明确定义的图像中，无论是背景图像还是图标。文本到图像提示更直接，以“Create an [extracted from personalizer response].”开头。

最终代理是前端开发人员，其唯一职责是创建前端网站工件。在这里，可以包括设计系统、代码片段或其他相关信息。在简单案例中，使用了此提示：

You are an experienced front-end web developer tasked with creating an accessible, [specify the website’s purpose] website while adhering to the specified guidelines [include relevant guidelines]. Carefully read the ‘Website Description’ [response from personalizer] provided by the UI/UX designer AI and generate the required HTML, CSS, and JavaScript code to build the described website. Ensure that [include specific requirements].

在这里，可以继续使用质量保证（QA）代理的方法或执行最终检查以查看是否存在差异。

二、重大权衡与过度工程的陷阱

任务分解通常引入额外组件（新LLM、协调器），增加复杂性并添加开销。虽然较小的LLM可能提供更快的性能，但增加的复杂性可能导致更高的延迟。因此，应在更广泛的背景下评估任务分解。

将任务复杂性表示为O(n)，其中n是任务大小。使用单个LLM，复杂性随任务大小线性增长。另一方面，在具有k个子任务和k个较小语言模型的并行任务分解中，初始分解具有恒定复杂性——O(1)。每个k语言模型独立处理其分配的子任务，假设均匀分布，复杂性为O(n/k)。

处理后，需要协调和集成来自k语言模型的结果。此步骤的复杂性是O(km)，其中完全 pairwise coordination 给出m = 2，但实际上1 < m ≤ 2。

因此，使用多个语言模型与任务分解的总体复杂性可以表示为： Ok-LLMs = O(1) + k (O(n/k)) + O(km) → O(n) + O(km)

虽然单语言模型方法具有复杂性O(n)，但多语言模型方法由于协调和集成开销引入了额外项O(km)，其中1 < m ≤ 2。

对于小k值和 pairwise connectivity，O(km)开销与O(n)相比可忽略，表明多语言模型方法的潜在好处。然而，随着k和m的增长，O(km)开销变得显著，可能削弱任务分解的收益。最佳方法取决于任务、可用资源以及性能收益与协调开销之间的权衡。改进的技术将减少m，降低使用多个LLM的复杂性。

成本与复杂性的心智模型

决定是否使用任务分解的一个有用心智模型是考虑应用程序的估计总拥有成本（TCO）。随着用户群的增长，基础设施成本变得主导，而像任务分解这样的优化方法可以降低TCO，尽管有前期工程和科学成本。对于较小的应用程序，更简单的方法，例如选择大型模型，可能更合适且成本效益更高。

过度工程与新颖性和简单性

任务分解和创建具有较小LLM的代理工作流程可能以牺牲更大、更强大模型通常显示的新颖性和创造力为代价。通过“手动”将任务分解为子任务并依赖专用模型，整体系统可能无法捕捉到更整体方法中可能出现的偶然联系和新颖见解。此外，制作复杂提示以适应特定子任务的过程可能导致过于复杂和 convoluted prompts，这可能 contribute to reduced accuracy and increased hallucinations。

使用多个较小、微调的LLM进行任务分解为提高复杂AI应用的成本效率提供了一种有前途的方法，与使用单个大型前沿模型相比，可能提供显著的基础设施成本节约。然而，必须注意避免过度工程，因为过多的分解可能增加复杂性和协调开销到收益递减的程度。在成本、性能、简单性和保留AI创造力之间 strike the right balance 将是释放这种有前途方法全部潜力的关键。