人机协同蒸馏实用指南：从小样本到高效部署

人机协同蒸馏实用指南

随着自然语言处理领域的进步，出现了越来越多高效利用计算资源的方法，能够构建运行成本更低、更易控制的AI系统。

行业中的软件

在AI热潮中需要牢记：AI开发本质上仍是软件开发，许多基本原则仍然适用。我们希望解决方案具备：

• 模块化：能够以不同方式组合理解的基础组件
• 透明性：能够调试或预防问题
• 可解释性：能够建立正确的心智模型

如果AI系统是解决整个问题的黑盒，我们很难了解应用在不同场景下的表现和改进方式。这变成了纯粹的经验性问题：只能不断尝试。

整个开发工作流和生命周期还需要满足：

• 数据隐私：内部数据不离开服务器，满足法律和监管要求
• 可靠性：稳定的请求时间和低故障率
• 经济性：符合预算要求

这使得依赖第三方API变得不切实际。虽然运行开源模型不一定比使用API更便宜，但如果将对大生成模型的依赖从运行时转移到开发阶段，情况就会改变。通过生成更小的任务专用模型，可以实现成本效益更高的解决方案，同时提供完整的数据隐私和更低的操作复杂度。

应用NLP策略

以一个经典的NLP应用问题为例：假设为电子产品制造商或零售商工作，需要分析用户生成的产品评论。计划可能包括：

1. 在评论中查找产品提及
2. 将提及与包含元信息的目录关联
3. 提取不同属性（如电池、相机、性能、设计）的客户情感（称为"面向方面的情感分析"）
4. 以结构化格式将结果添加到数据库，以便查询和大规模计算情感分析

大型生成模型在这方面表现优异，但解决这个特定问题所需的知识只是模型能力的很小一部分。那么，能否只提取这些部分，为我们的特定任务创建更小的专用组件呢？

上下文学习（使用自然语言提示访问信息，无需微调模型权重）和迁移学习（使用从不同任务学到的知识改进泛化能力）是两种不同的工具，用于不同的目的。研究表明，使用BERT-base等嵌入的迁移学习相比少样本上下文学习方法仍然具有竞争力。

使用LLM进行预测任务

本质上，面向方面的情感分析是预测任务而非生成任务。我们试图创建结构化输出供其他程序使用，而不是生成供人类使用的非结构化文本或图像。

上下文学习引入了使用预训练模型执行预测任务的新工作流：通常使用提示模板和相应的解析器，将原始文本输出转换为任务特定的结构化数据。

对于蒸馏，我们可以将这些输出用作任务特定模型的训练数据。理想情况下，需要包含人机协同步骤以纠正LLM的错误。如果不纠正错误，就无法期望超越LLM的表现。

缩小原型与生产之间的差距

构建令人印象深刻的演示和原型从未如此容易，但许多团队也经历了"原型高原"：当需要将解决方案投入生产时，原型无法转化为可用的系统。

根本原因之一在于工作流的差异。如果原型假设的输入输出与生产系统根本不同（如样本文本到文本 vs 用户生成文本到结构化数据），就无法保证在实际中以相同方式工作。理想情况下，需要标准化输入输出并使用相同数据结构的工作流。

设计评估可能不是原型过程中最令人兴奋的部分，但至关重要。没有良好的评估，就无法知道系统是否在改进以及更改是否带来了更好的结果。评估应由运行时数据的具体示例组成，这些示例的正确答案是已知的。

在评估系统时，准确度分数不是唯一需要跟踪的指标：更重要的是系统的效用：是否解决了应该解决的问题，是否适合应用的更大背景。

从原型到生产的结构化数据

缩小原型与生产之间的差距最终归结为正确的开发工具。spacy-llm就是一个例子，这是spaCy的扩展库，提供使用开源和专有LLM进行各种结构化预测任务的组件，包括命名实体识别、文本分类或关系提取。

使用带有LLM组件的spaCy进行原型工作流，现在可以在几分钟内构建工作原型，并通过结构化Doc对象访问预测结果。这为原型和生产期间的输入输出提供了标准化接口。

人机协同蒸馏

使用LLM组件引导流水线可以快速获得工作系统，并为特定任务（如文本分类或命名实体识别）生成标注数据。如果能够通过数据聚合丢弃明显问题或手动纠正来改进标签，就可以在比LLM输出更正确的数据上训练，从而获得不仅更小更快而且更准确的模型。

目标是通过流式输入和纠正LLM的预测来创建黄金标准数据，仅提取我们感兴趣的信息，直到任务特定模型的准确度达到或超过零样本或少样本LLM基线。

在引入人工环节时，需要考虑其自然限制：人类擅长处理上下文和歧义，但在记忆事物和一致执行重复步骤方面远不如机器。如果呈现过多信息，我们也可能不知所措并失去注意力，导致因疏忽而犯错。

这意味着请求人类反馈和纠正的最佳方式可能与为机器学习模型构建任务的方式大不相同。理想情况下，我们希望构建界面来减少认知负荷，只关注从人类那里获得最少必要信息来纠正LLM预选的标注。

案例研究和结果

自发布用于spaCy和Prodigy的LLM驱动蒸馏工作流以来，我们已经在各种用例中进行了尝试，并开始记录不同领域的行业项目，取得了非常有希望的结果。

PyData NYC：分析Reddit烹饪帖子

在去年由Ryan和我在PyData NYC主持的研讨会中，我们设定了一个雄心勃勃的目标：能否用任务特定组件击败LLM？我们选择从r/cooking Reddit帖子中提取DISH、INGREDIENT和EQUIPMENT。通过使用LLM预标注文本范围并与参与者一起纠正预测，我们能够以任务特定组件击败74%的少样本基线，产生小模型工件和20倍的推理时间加速。

指标	生成式LLM	蒸馏组件
准确度(F分数)	0.74	0.74
速度(词/秒)	< 100	~ 2,000
模型大小	~ 5 TB	400 MB
参数	1.8t	130m
训练示例	0	800
评估示例	200	200
数据开发时间	~ 2h	~ 8h

由于研讨会的时间限制，我们在达到基线准确度后停止了，但更多标注可能会带来更好的结果。处理数据还揭示了许多边缘情况，并引发了关于标签方案的有趣讨论。

某全球机构：实时商品交易洞察

某全球机构是全球能源和商品数据和洞察的领先提供商之一，涵盖金属、农产品和化学品等原材料。为了提供更好的市场透明度并实时生成结构化数据，他们的团队构建并部署了小至6 MB的高效spaCy流水线，完全在内部高安全环境中运行，满足严格的推理SLA。在开发过程中使用LLM和Prodigy进行半自动标注，他们还实现了数据收集和标注工作流10倍的速度提升。

将其视为重构过程

虽然可以将蒸馏视为纯粹的技术挑战，但将其视为重构过程更有意义。就像编写和重构软件一样，试图将较大的问题分解为模块化和可组合的构建块。目标是从可用技术中选择最佳技术，并在操作复杂度、易用性和结果质量之间平衡权衡。

重构也是重新评估依赖关系的机会：引入这个大型库是否合理？同样，能否用更小更快的版本替换更大、更慢、更昂贵的模型？是否有可以从运行时移动到开发的依赖关系？

简化问题

在应用工作中，允许简化问题！这不是大学或学术界，那里会提供固定输入和输出的数据集。与其他类型的工程一样，这不是为最困难的问题想出最聪明解决方案的竞赛。我们试图完成任务。如果能用简单得多的问题替换困难问题，那就是胜利。

降低系统的操作复杂度也意味着出错的可能性更小。如果出现问题，诊断和修复也会容易得多。本质上，许多NLP系统由相对简单的分类组成。可以将它们全部塞进单个提示中，或者分解为可以独立处理的较小部分。

开发复杂度

分解业务逻辑

重构代码时，通常试图将逻辑重新分组到具有明确职责和明确定义行为的函数中。不需要理解整个程序就知道某个函数应该如何行为——它本身应该有意义。创建NLP流水线时，也将计算划分为多个函数。简而言之，可以分解为如下公式：

结果 = 业务逻辑(分类(文本))

回到手机评论的例子，如何分工？这是任何其他重构讨论中出现的相同类型问题，只是风险更高。通过在这里做出的选择，可以真正改变模型的性能以及它对未来数据的泛化能力。

模型真的没有机会可靠地预测"最新型号"或"触摸屏"等标签。最多只能尝试学习给定时间什么是最新的，或者记住"nebula"总是"触摸屏"。这对应用程序非常不利：模型正在学习不能泛化的东西，而评估数据可能无法显示问题。

重构的一个技巧：尝试从模型的角度查看文本。想象这是被告知要完成的任务，输入就是所有可用的信息。需要知道什么才能得到答案？如果模型只需要知道词语的一般含义和句子结构，然后应用相当简单的标注策略，那就很好。如果模型需要将语言知识与大量外部知识结合起来，那就很糟。如果答案取决于随时间变化的事实，那就非常糟。

结论

在许多实际应用中，AI模型只是更大系统中的一个函数。因此，与任何函数一样，可以移动工作。可以有一个端到端完成整个任务的函数，或者可以拆分一些部分并协调函数 together。

这个重构过程非常重要，因为它改变了模型学习的内容和泛化的方式。使用正确的工具，可以更快地重构，确保不只是坚持最初的想法。控制更多堆栈也有帮助，因为从上游组件的工作方式继承的约束更少。

迭代处理数据也非常重要，因为关于数据外观和分类方式的假设可能不正确。标注是做到这一点的好方法——它不仅仅是成本，本身也是好处。通常标注过程几乎比标注本身更有价值。

通过高效的工作流和正确的自动化，通常只需要几个小时的工作就能创建足够的数据来实现高精度，并在相同任务上超越通用LLM。随着通用LLM的改进，这个工作流只会变得更强大。 resulting任务特定模型操作复杂度更低，体积小，速度快，通常可以完全在内部运行，不需要昂贵的硬件。

最后，凭借可用的工具和技术，绝对不需要在软件开发最佳实践或数据隐私方面妥协。推广"一个模型统治一切"方法的人可能正在讲述那个故事，但我们其他人没有义务相信他们。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）或者 我的个人博客 https://blog.qife122.com/
公众号二维码