反对LLM最大化主义：模块化NLP设计

反对LLM最大化主义

许多人正在用大语言模型构建真正新颖的东西，比如以前不可能实现的交互式虚构体验。但如果你处理的是企业长期以来一直试图解决的相同类型的自然语言处理问题，那么使用它们的最佳方式是什么？

企业使用语言技术已多年，成效参差不齐。以某种智能方式处理文本或语音数据的需求非常基本。例如，在大多数热门网站中，文本通常是产品的重要组成部分（如网站发布新闻或评论）、使用模式（如用户之间互写文本）或输入（如新闻聚合器）。语言交易总体上占了经济活动的很大比例。我们都在工作生活中花费大量时间写作、阅读、说话和倾听。因此，“用语言做事情”长期以来一直是各类程序渴望的功能特性，这很合理。2014年我开始开发spaCy，以下是我解释该库动机的摘录：

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

如今，很难再声称计算机不理解文本而不加上大大的星号或限定条件。即使你对“理解”的构成有特定的哲学观点，但毫无疑问，LLM能够构建和操作足以满足广泛实际用途的意义表征。它们仍然会犯各种错误，但感觉它们只是未能将输入词语连接起来形成预期含义的情况相对少见。它们生成的文本也非常流畅。有时它会自信地给出错误答案或与你的问题无关，但几乎总是由真实、连贯的句子组成。这绝对是新现象。

然而，LLM并不是企业长期以来一直处理的绝大多数NLP用例的直接解决方案。它们非常有用，但如果你想交付可随时间改进的可靠软件，就不能只写一个提示就完事。一旦你过了原型阶段，想要交付尽可能好的系统，对于非生成式任务——即存在模型需要找到的特定正确答案的任务——监督学习通常会比上下文学习给你带来更好的效率、准确性和可靠性。在模型周围应用规则和逻辑来进行数据转换或处理可完全枚举的情况也极其重要。

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

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

LLM足够新，变化足够快，对于如何最佳使用它们几乎没有共识。最终事情会稳定下来（或者AGI终究会把我们都干掉），我们将留下一些伤疤和关于什么有效、什么无效的积累智慧。在此期间，我想提出一些常识。

LLM最大化主义

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

这种方法有两个大问题。一是“绕过系统限制”通常根本不可能。大多数系统需要比当今LLM快得多的速度，而且根据当前效率和硬件改进的趋势，未来几年内仍将如此。用户在聊天应用中对延迟相当容忍，但在几乎任何其他类型的用户界面中，你不能为单个预测等待数秒。这太慢了。在我们在线声誉管理的例子中，你想要连接到某种数据消防水管，如Reddit或Twitter。你不能直接将其传入LLM——成本太高了。

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

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

什么是好的程序？它不仅在于它解决单一需求集的效率和准确性，还在于它能够被理解、更改和改进的可靠性。用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实用主义：

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

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

附录1：付诸实践

有很多工具和库可用于标注你自己的数据和训练你自己的NLP模型。HF Transformers和spaCy是两个最流行的库。Transformers让你轻松使用来自近期研究的各种模型，并且更接近底层ML库（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 Microsoft Cognitive Services.")
for ent in doc.ents:
    print(ent.text, ent.label_, ent.sent)

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

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

附录2：监督学习与上下文学习的准确率

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

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

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

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

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