模块化设计：对抗LLM滥用主义的务实NLP策略

反对LLM滥用主义

许多人正利用大型语言模型（LLM）构建真正的新事物，例如以前无法实现的狂野互动小说体验。但是，如果你正在处理企业长期以来试图解决的同类自然语言处理（NLP）问题，那么使用它们的最佳方式是什么？

企业使用语言技术已有多年，但成功与失败并存。以某种智能方式处理文本或语音数据的需求是相当基础的。例如，在大多数热门网站中，文本通常是产品的重要组成部分（如网站发布新闻或评论）、使用模式的重要组成部分（如用户之间互发文本）或输入的重要组成部分（如新闻聚合器）。总的来说，语言交易构成了经济活动的很大一部分。我们大部分的工作时间都花在写作、阅读、说话和倾听上。因此，长期以来，各种程序都希望能“用语言做点什么”，这是很合理的。2014年，我开始着手开发spaCy，以下是我解释该库动机的一段摘录：

计算机不理解文本。这很不幸，因为网络几乎完全由文本组成。我们想根据用户喜欢的其他文本来推荐文本。我们想缩短文本以在移动屏幕上显示。我们想聚合、链接、过滤、分类、生成和校正文本。spaCy 提供了一系列实用函数库，帮助程序员构建此类产品。

如今，要声称计算机不理解文本，很难不加上巨大的星号或附加条件。即使你对“理解”的构成持有特定的哲学观点，但毫无疑问，LLM能够构建和操纵足以满足广泛实际用途的意义表示。它们仍然会犯各种错误，但让你觉得它们根本没有将输入的词语连接起来形成预期含义的情况相对少见了。它们生成的文本也非常流畅。有时它可能 confidently wrong 或与你的问题无关，但它几乎总是由真实、连贯的句子组成。这绝对是新的。

然而，对于企业一直在研究的大多数NLP用例来说，LLM并不是直接的解决方案。它们非常有用，但如果你想交付可靠且能随时间改进的软件，就不能只写个提示词就完事了。一旦你完成了原型设计，想要交付你所能构建的最佳系统时，对于非生成式任务——即那些你希望模型找到特定正确答案的任务——监督学习通常比上下文学习提供更好的效率、准确性和可靠性。围绕你的模型应用规则和逻辑来执行数据转换或处理那些可以完全枚举的情况也极其重要。

例如，假设你想构建一个在线声誉管理系统。你想从Twitter、Reddit或其他来源摄取帖子流，识别提及你公司或产品的部分，并理解它们之间的共同主题。也许你还想以类似的方式监控关键竞争对手的提及情况。你可能希望以多种方式查看数据。例如，你可以提取一些粗略的指标，比如在仪表盘中跟踪的总体“积极性”情感分数，同时还可以对帖子进行更细致的聚类，以便定期进行更详细的审查。

我不想低估LLM对此类用例的巨大影响。你可以给LLM一组评论，让它总结文本或识别关键主题。并且这些具体需求可以在运行时改变：你不必针对一个非常特定的总结或预设的问题。这种生成式输出可能完全改变游戏规则，最终交付数据科学项目常常过度承诺但交付不足的“洞察”。除了这些生成式组件，你还可以使用LLM来帮助处理系统的其他部分。但你应该这样做吗？

LLM足够新，变化足够快，以至于对于如何最好地使用它们几乎没有共识。最终事情会稳定下来（或者也许AGI最终会搞定我们所有人），我们会有一些伤疤和积累的智慧，知道什么有效，什么无效。与此同时，我想提出一些常识性的建议。

关于如何使用LLM，有一种愿景我称之为LLM滥用主义。如果你有一个任务，你试图让LLM尽可能直接地完成它。需要某种格式的数据？在提示词中要求它。避免将任务分解成几个步骤，因为这会阻止LLM端到端地处理你的问题。它还会引入额外的调用，并可能在中间处理步骤中引入错误。当然，LLM确实有局限性，例如其知识的时效性，或者你能传递的上下文大小。所以你确实需要绕开这些问题，使用向量数据库或其他技巧。但从根本上说，LLM滥用主义的立场是，你希望信任LLM来解决问题。你正在为这些技术的持续改进做准备，期望当前的痛点随时间推移而减少。

这种方法有两个大问题。第一个是，“绕开系统的局限性”常常是完全不可能的。大多数系统需要比当今LLM快得多的速度，而且根据目前的效率和硬件改进趋势，在未来几年内仍将如此。用户对聊天应用程序的延迟相当容忍，但在几乎任何其他类型的用户界面中，你都不能为了一个预测而等待好几秒。这太慢了。在我们在线声誉管理的例子中，你需要连接到某种数据流，比如Reddit或Twitter。你不能直接把数据流喂给LLM——这太昂贵了。

第二个问题是，LLM滥用主义方法从根本上说不是模块化的。假设你已经做了一个明显的小妥协，你使用一个单独的分类器来预过滤可能提及你公司的文本。你已经开发了一个与你使用的LLM模型配合良好的提示词，并且得到了相当不错的输出摘要。现在你收到一个新请求。用户希望能够查看一些原始数据。为了满足这个需求，你的团队决定开发一个单独的视图，你在其中显示提及列表以及一句上下文。

你应该怎么做？你可以精心设计一个单独的LLM提示词，让它以你被要求的第二种格式提取数据。然而，不能保证新的提示词能识别出与第一个提示词完全相同的提及集合——不可避免地会有一些差异。这真的很不好。你希望能够将摘要与生成它们的评论组链接起来。如果句子视图不同，你就做不到这一点。与其使用单独的提示词，你可以尝试将信息添加到第一个提示词中。但现在你输出了完整的句子，这大大增加了你生成的令牌数量，既慢又贵。而且你很难用这种新的、更复杂的输出格式获得之前相同的准确性。

什么造就了一个好程序？它不仅仅在于它解决单一需求集的效率和准确性，还在于它能够被理解、修改和改进的可靠性。用LLM滥用主义方法编写的程序在这些标准下并不好。

我们可以将问题分解成小块，并将LLM视为系统中另一个模块，而不是抛弃我们学到的关于软件设计的一切，让LLM一次性完成所有事情。当我们的需求发生变化或扩展时，我们不必回去改变整个系统。我们可以添加新模块，或者重新组合我们已经满意的模块。

将任务分解成单独的模块也有助于你看到哪些部分真正需要LLM，哪些部分可以用其他方法更简单、更可靠地完成。识别英文句子边界并非完全微不足道（你不能只用正则表达式），但这绝对不需要LLM来做。你可以直接调用spaCy或其他库。它会快得多，而且你不必担心LLM会在一些奇怪的输入上出错，返回完全意料之外的输出。

检测公司提及的任务可能也不需要LLM来做。在最初的原型设计中使用LLM当然是有意义的——这是LLM另一个不应被低估的巨大优势。快速原型设计极其重要。你可以高效地探索设计空间，舍弃不值得进一步开发的想法。但你也需要能够超越原型设计。一旦你发现了一个值得改进的想法，你需要一种方法来实际改进它。

在你改进任何统计组件之前，你需要能够评估它。对整个流程进行评估很重要，如果没有别的，你可以用它来判断对某个组件的更改是让事情变好还是变坏（这称为“外在评估”）。但你也应该孤立地评估你的组件（“内在评估”）。对于像提及检测器这样的组件，这意味着用正确的标签注释一些文本，将它们放在一边，并在每次更改后针对它们测试你的组件。对于生成式组件，你不能针对单一的一组注释进行评估，但内在评估仍然是可能的，例如使用李克特量表或A/B测试。

内在评估就像单元测试，而外在评估就像集成测试。你两者都需要。很常见的情况是，开始构建一个评估集，然后发现你对组件行为方式的期望比你意识到的要模糊得多。你需要一个清晰的组件规范来改进它，并改进整个系统。否则，你最终会陷入局部最优：对一个组件的更改本身似乎合理，但你会看到整体结果变差，因为先前的行为在补偿其他地方的问题。这样的系统很难改进。

一个好的经验法则是，你的评估指标的每个有效数字需要十个数据点。所以，如果你想区分91%的准确率和90%的准确率，你至少需要注释1000个数据点。你不会希望在你的实验中，准确率数字显示提高了1%，但实际上你是从94/103变成了96/103。你最终会形成迷信，而基础不过是运气。那不是改进的途径。你需要系统化。

一旦你注释了评估数据，通常最好继续为非生成式组件注释一些训练数据。监督学习对于文本分类、实体识别和关系抽取等任务非常强大。如果你对组件应该做什么有清晰的想法，并可以相应地注释数据，使用为单个GPU设计的transformer架构，利用预训练表示，通常可以期望仅用几百个标注样本就获得比LLM更好的准确性。这实际上与LLM的模型架构相同，但尺寸更方便，并且配置为只执行一个任务。

以下是我认为当今应该在NLP项目中使用LLM的方式——我称之为 LLM实用主义。

• 将你的应用程序需要用语言做的事情分解成一系列预测性和生成性步骤。
• 保持步骤简单，不要要求你可以轻松确定性地完成的转换或格式化。
• 组合一个原型流程，对所有预测性或生成性步骤使用LLM提示词或现成的解决方案。
• 在尽可能真实的上下文中试用该流程。
• 设计某种外在评估。这里的成功是什么样的？净节省的劳动力？参与度？转化率？如果你不能直接衡量系统的效用，你可以使用其他类型的指标，但你应该尽量使其尽可能有意义。如果假阴性比假阳性更重要，请在你的外在评估指标中考虑到这一点。
• 尝试备选的流程设计。尝试创建那些正确答案独立于你的用例的任务。倾向于文本分类而不是实体识别，倾向于实体识别而不是关系抽取（注释更快，准确性更好）。
• 选择一个预测性（而非生成性）组件，花两到五个小时为其标注注释数据。
• 使用你的评估数据测量由LLM驱动的组件的准确性。
• 使用由LLM驱动的组件帮助你创建训练数据，来训练你自己的模型。一种方法是简单地保存由LLM驱动的组件的预测，并相信它们足够好。如果由LLM驱动的组件的准确性似乎足以满足你的需求，这是一个值得尝试的好方法。如果你需要比LLM提供的更好的准确性，你需要更正确的示例数据。一个好方法是将LLM的预测加载到注释工具中并修复它们。
• 在你的新训练数据上训练一个监督模型，并在你之前使用的相同评估数据上评估它。
• 为了决定是否应该注释更多训练数据，运行额外的实验，保留部分训练数据。例如，比较当你使用现有数据的100%、80%和50%时，准确率如何变化。这应该有助于你确定如果你有120%或150%的数据，准确率可能会是什么样子。但是，请注意，如果你的训练集很小，你的准确率可能会有很大的方差。尝试几个不同的随机种子，弄清楚仅凭偶然因素你的准确率会变化多少，以帮助你正确看待结果。
• 对任何其他预测组件重复此过程。

在所有这些步骤结束时，你将拥有一个适合生产的流程。它的运行速度将比一连串的LLM调用快得多，准确率也高得多，而且你会知道，无论传入什么文本，你的预测组件都将始终给你有效的输出。你将拥有不同步骤的评估，并且能够将错误归因于不同的组件。如果你需要改变系统的行为，你将能够在流程的不同点添加新的规则或转换，而不必回头重新设计你的提示词或重写你的响应解析逻辑。

其中一些步骤仍然比它们应该的难度要大一些，特别是如果你以前没有接触过机器学习的话。这正是我对LLM寄予厚望的地方。LLM确实非常强大，它们可以让很多事情变得容易得多。它们可以帮助我们构建更好的系统，而这正是我们应该使用它们的方式。我称之为“LLM滥用主义”的方法实际上是没有雄心的。它使用LLM来轻松得到一个更差的系统——成本更高、运行时间更长、可靠性更差、可维护性更差。相反，我们应该利用LLM来帮助我们构建更好的系统。这意味着在开发过程中更多地依赖LLM，以打破知识壁垒、创建数据并改进我们的工作流程。但目标应该是在运行时尽可能少地调用LLM。让LLM训练它们自己更便宜、更可靠的替代品。

附录1：付诸实践

有很多工具和库可以用来标记自己的数据和训练自己的NLP模型。HF Transformers和spaCy（我们的库）是这方面最流行的两个库。Transformers让你可以轻松使用最近研究中的各种模型，它更接近于底层的机器学习库（PyTorch）。spaCy拥有更好的用于处理注释的数据结构，支持混合统计和基于规则操作的流程，以及用于配置、扩展和项目工作流的更多框架性功能。我们最近发布了spacy-llm，一个扩展，允许你将由LLM驱动的组件添加到你的spaCy流程中。你可以将LLM与其他组件混合，并利用spaCy的Doc、Span、Token等类来使用注释。

例如，假设你想创建一个检测某些实体的流程，然后你想获取这些实体出现的句子。以下是在Python中构建和使用该流程的样子：

import spacy
nlp = spacy.blank("en")
nlp.add_pipe("sentencizer")
nlp.add_pipe(
    "llm",
    config={
        "task": {
            "@llm_tasks": "spacy.NER.v1",
            "labels": "SAAS_PLATFORM,PROGRAMMING_LANGUAGE,OPEN_SOURCE_LIBRARY"
        },
        "model": {
            "@llm_models": "spacy.Davinci.v2",
        },
    },
)

doc = nlp("There's no PyTorch bindings for Go. We just use 某机构 Cognitive Services.")
for ent in doc.ents:
    print(ent.text, ent.label_, ent.sent)

spaCy中的sentencizer组件使用规则来检测句子边界，而这里的llm组件被配置为执行命名实体识别，并带有给定的标签。为其他一些常见的NLP任务提供了任务处理器，但你也可以定义自己的函数来执行任意任务——你只需要给你的函数添加一个装饰器并遵守正确的签名即可。

句子和实体注释（在此示例中通过doc.sents和doc.ents访问）都可以作为Span对象的序列访问，Span就像是Doc对象的一个带标签的切片。你可以遍历span中的令牌，获取其起始和结束字符偏移量，并且（取决于你流程中的组件）访问嵌入或计算相似度。组件可以分配多个重叠的Span注释层，你可以设计和分配扩展属性以方便地访问其他属性。

显然，我对spaCy的这些部分相当自豪，但它们与LLM有什么关系呢？你可以用这样的命令提示LLM：“这篇评论中有多少段落对表演提出了负面意见？他们经常提到哪些演员？”。对于一次性的个人任务来说，这绝对神奇。但是，如果你正在构建一个系统，并且想要为每篇评论计算和显示这些信息，那么将其作为单独的预测任务（标记名称、将其链接到知识库以及段落级别的演员情感）来处理就非常好，并且数据结构允许你灵活地访问信息。spaCy中新的LLM支持现在允许你为这些预测任务插入由LLM驱动的组件，这对于原型设计尤其有用。这个功能仍然相当新且实验性，但探索起来已经非常有趣了。

你需要的另一个工具是某种数据注释解决方案。你可以在电子表格或文本编辑器中加载数据，但如果你要重复这样做，值得使用更好的工具。我们开发了一个商业注释工具Prodigy，它强调可定制性和模型辅助的工作流程。Prodigy不是免费的，但它是一次性购买每个许可证，并且非常适合本地工作流程。

Prodigy的一个关键设计思想是模型辅助：调用模型来获取初始注释，然后让你审查和修复它们。这与LLM配合得特别好，我们在过去六个月中一直在构建对此的支持。Prodigy v1.12将集成对LLM注释辅助的支持，并支持选择后端，包括你可以自行托管的开源解决方案。Prodigy还支持生成式输出的A/B评估，这特别适用于LLM。此功能在v1.12中也得到了扩展。例如，你可以设计许多不同的提示词，并通过回答一系列A/B评估问题来让它们进行比拼，你需要在不知道哪个输出是由哪个提示词产生的情况下，选出两个输出中更好的一个。这使你能够基于可以记录和稍后审查的决策，系统地进行提示词工程。

附录2：监督学习和上下文学习的准确性

大型语言模型（LLM）可用于任意预测任务，方法是通过构建描述任务的提示词，给出要预测的标签，并可选地在提示词中包含相对少量的示例。这种方法不涉及对模型针对新任务进行任何直接更新。然而，LLM似乎从其语言模型目标中学习了一种延续模式的通用能力，包括抽象模式。其机制仍在研究中，但可以参考Anthropic关于归纳头的研究（Olsson et al., 2022）。

在监督学习（在语言模型的上下文中通常称为微调）中，模型被提供一组带标签的示例对，并调整权重以最小化某个目标函数。在现代NLP中，监督学习和语言模型预训练紧密相连。关于语言的知识在不同任务间是通用的，因此理想情况下，需要用这些知识来初始化模型。语言模型预训练已被证明是满足这一要求的一个非常强大的通用答案。在我看来，最好的阅读材料是那些发展相对较新时的文章，例如Sebastian Ruder在2018年的博文《NLP的ImageNet时刻终于到来》。

某机构在各种配置下评估了GPT-3的上下文学习能力与监督学习的对比（Brown et al., 2020）。第3.7节关于SuperGLUE基准测试的结果与通用NLP预测任务（如实体识别或文本分类）最直接相关。在他们的实验中，某机构为GPT-3提供了每个任务32个示例的提示词，发现它们能够达到与BERT基线相似的准确率。这些结果是上下文学习作为一种有竞争力的方法的首次重磅亮相，它们确实令人印象深刻。然而，它们在发表时远低于最先进的准确率，而当前SuperGLUE排行榜上的最先进结果都涉及监督学习，而不仅仅是上下文学习。SuperGLUE基准测试套件的一些子任务具有非常小的训练集，在这些任务上，上下文学习具有竞争力。我不知道当前有任何NLP基准测试提供了超过几百个训练样本，而领先的系统完全依赖上下文学习。

上下文学习的重点从来都不是让模型以绝对最高的准确率执行某个特定任务。相反，它是一个令人印象深刻的折衷方案：它的样本效率极高（你不需要很多任务示例），而且你不需要支付前期训练的计算成本。简而言之，上下文学习的优势在于较低的开销。但是，你的项目存活时间越长，就越不应该将此视为主要优势。开销会被分摊掉。

最后，重要的是要认识到SuperGLUE和其他标准NLP基准测试是专门设计来相当具有挑战性的。容易的任务不能成为好的基准。这与NLP应用完全相反，在NLP应用中，我们希望任务尽可能简单。大多数实际任务不需要强大的推理能力或广泛的背景世界知识，而这些正是LLM与较小模型区别开来的地方。相反，实际任务通常要求模型学习一组相当特定的策略，然后一致地应用它们。监督学习非常适合这个要求。

关于作者

Matthew Honnibal是某中心的首席技术官兼创始人。他是人工智能技术的领先专家。他于2009年完成博士学位，并又花了5年时间发表关于最先进NLP系统的研究。他于2014年离开学术界，撰写了spaCy并创立了某机构。FINISHED