我们从一年的大语言模型构建中学到的经验下：战略篇

最近看到一篇关于LLM的文章，觉得有用，翻译分享给大家，将分为两期呈现。原文地址：https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-iii-strategy/

在之前的文章中，我们分享了在运营大语言模型应用过程中积累的战术经验。战术是具体的：它们是为实现特定目标而采取的具体行动。我们还分享了我们对运营的看法：支持战术工作以实现目标的更高层级流程。

但这些目标从何而来？这就是战略的范畴。战略回答了战术和运营“如何做”背后的“做什么”和“为什么做”的问题。

我们提供了一些个人观点，例如“在找到产品市场契合点之前不要使用GPU”和“专注于系统而不是模型”，以帮助团队确定如何分配稀缺资源。我们还建议了一个迭代开发优秀产品的路线图。最后一组经验回答了以下问题：

构建与购买： 何时应该训练自己的模型，何时应该利用现有的API？答案一如既往地是“视情况而定”。我们分享了具体取决于哪些因素。
迭代出优秀产品： 如何创建持久的竞争优势，而不仅仅是使用最新的模型？我们讨论了围绕模型构建强大系统的必要性，以及专注于提供令人难忘、具有粘性的体验的重要性。
以人为本的人工智能： 如何有效地将大语言模型集成到人类工作流程中，以最大限度地提高生产力和幸福感？我们强调构建支持和增强人类能力的人工智能工具的重要性，而不是试图完全取代人类。
入门指南： 团队在开始构建大语言模型产品时需要采取哪些基本步骤？我们概述了一个基本的行动方案，从提示工程、评估和数据收集开始。
低成本认知的未来： 大语言模型成本的快速下降和能力的不断提高将如何塑造人工智能应用的未来？我们考察了历史趋势，并通过一个简单的方法来估计某些应用何时可能在经济上可行。
从演示到产品： 从一个引人注目的演示到一个可靠、可扩展的产品需要什么？我们强调需要进行严格的工程、测试和改进，以弥合原型和产品之间的差距。

为了回答这些难题，让我们一步一步地思考……

战略：在不被淘汰的情况下构建大语言模型应用

成功的产品需要深思熟虑的规划和艰难的优先级排序，而不是无休止地制作原型或追逐最新的模型发布或趋势。在本节中，我们将展望未来，思考构建优秀人工智能产品的战略考量因素。我们还将考察团队将面临的关键权衡，例如何时构建和何时购买，并为早期大语言模型应用开发战略提供“行动方案”。

在找到产品市场契合点之前不要使用GPU

要想做到出色，你的产品需要的不仅仅是对他人API的简单封装。但在相反方向上的错误可能会带来更大的损失。过去一年，我们也看到大量风险投资（包括一笔令人瞠目的60亿美元A轮融资）被用于训练和定制模型，而没有明确的产品愿景或目标市场。在本节中，我们将解释为什么立即开始训练自己的模型是一个错误，并探讨自托管的作用。

从头开始训练（几乎）永远不可取

对于大多数组织来说，从头开始预训练一个大语言模型会分散他们构建产品的精力，得不偿失。

尽管这很令人兴奋，而且看起来其他所有人都在这样做，但开发和维护机器学习基础设施需要大量的资源。这包括收集数据、训练和评估模型以及部署模型。如果你仍在验证产品市场契合度，这些工作会将资源从开发核心产品上转移开。即使你拥有计算能力、数据和技术能力，预训练的大语言模型也可能在几个月内过时。

以专门针对金融任务训练的BloombergGPT为例。该模型在3630亿个词符上进行了预训练，需要9名全职员工（4名来自人工智能工程部门，5名来自机器学习产品和研究部门）付出巨大的努力。尽管付出了这些努力，但它在一年内就被gpt-3.5-turbo和gpt-4在这些金融任务上的表现超越了。

这个故事和其他类似的故事表明，对于大多数实际应用来说，从头开始预训练一个大语言模型，即使是在特定领域的数据上，也不是最佳的资源利用方式。相反，团队最好针对他们的特定需求对最强大的开源模型进行微调。

当然也有例外。一个很好的例子是Replit的代码模型，该模型专门针对代码生成和理解进行了训练。通过预训练，Replit能够超越其他大型模型（如CodeLlama7b）的性能。但随着其他功能越来越强大的模型的发布，保持实用性需要持续的投入。

在证明有必要之前不要进行微调

对于大多数组织来说，推动微调的更多是“害怕错过”（FOMO），而不是清晰的战略思考。

组织过早地投资于微调，试图摆脱“只是另一个包装器”的指控。实际上，微调是一个沉重的负担，只有在你收集了大量例子，让你确信其他方法都不可行之后，才能部署它。

一年前，许多团队告诉我们，他们对微调感到兴奋。很少有人找到了产品市场契合点，而且大多数人都对自己的决定感到后悔。如果你要进行微调，你最好真的确信你已经做好了准备，随着基础模型的改进，你可以一次又一次地进行微调——参见下面的“模型不是产品”和“构建LLMOps”。

什么时候微调才是正确的选择？如果用例需要的数据在用于训练现有模型的大多数开放网络规模数据集中不可用——并且如果你已经构建了一个MVP，证明现有模型不足以满足需求。但要小心：如果模型构建者无法轻易获得良好的训练数据，那么你是从哪里获得的呢？

最后，请记住，大语言模型驱动的应用并不是科学展览项目；对它们的投资应该与其对企业战略目标和差异化竞争的贡献相称。

从推理API开始，但不要害怕自托管

借助大语言模型API，初创公司可以比以往更容易地采用和集成语言建模功能，而无需从头开始训练自己的模型。Anthropic和OpenAI等提供商提供通用的API，只需几行代码就可以为你的产品注入智能。通过使用这些服务，你可以减少花费的精力，转而专注于为客户创造价值——这使你能够更快地验证想法并迭代出符合产品市场需求的产品。

但是，与数据库一样，托管服务并不适合所有用例，尤其是在规模和需求增加的情况下。事实上，自托管可能是使用模型而不将机密/私有数据发送到网络之外的唯一方法，这在医疗保健和金融等受监管行业中是必需的，或者是由合同义务或保密要求规定的。

此外，自托管可以绕过推理提供商施加的限制，例如速率限制、模型弃用和使用限制。此外，自托管让你可以完全控制模型，从而更容易围绕模型构建差异化、高质量的系统。最后，自托管，尤其是微调的自托管，可以在规模较大的情况下降低成本。例如，BuzzFeed分享了他们如何微调开源大语言模型以将成本降低80%。

迭代出优秀产品

为了在长期内保持竞争优势，你需要超越模型，思考是什么让你的产品与众不同。虽然执行速度很重要，但这不应该是你唯一的优势。

模型不是产品；围绕它的系统才是

对于那些不构建模型的团队来说，快速创新的步伐是一个福音，因为他们可以从一个最先进的模型迁移到下一个，追逐上下文大小、推理能力和性价比的提升，以构建越来越好的产品。

这种进步既令人兴奋，也在意料之中。总而言之，这意味着模型可能是系统中最不耐用的组件。

相反，你应该将精力集中在能够提供持久价值的事物上，例如：

评估框架： 跨模型可靠地衡量你在任务上的表现
护栏： 防止出现不希望的输出，无论使用什么模型
缓存： 通过完全避免模型来减少延迟和成本
数据飞轮： 为上述所有内容的迭代改进提供动力

与原始模型功能相比，这些组件创造了更深的产品质量护城河。

但这并不意味着在应用层构建是没有风险的。如果OpenAI或其他模型提供商想要提供可行的企业软件，他们也需要解决同样的问题，所以不要把你的精力浪费在这些问题上。

例如，一些团队投资于构建自定义工具来验证来自专有模型的结构化输出；在这方面进行少量投资很重要，但深入投资并不是明智之举。OpenAI需要确保当你请求函数调用时，你得到的是一个有效的函数调用——因为他们的所有客户都希望如此。在这方面要采取一些“战略性拖延”策略，构建你绝对需要的东西，并等待提供商对功能的明显扩展。

####从小处着手建立信任

构建一个试图满足所有人所有需求的产品只会导致平庸。为了创造引人注目的产品，公司需要专注于构建令人难忘、具有粘性的体验，让用户不断回来。

想象一下一个通用的检索增强生成（RAG）系统，它的目标是回答用户可能提出的任何问题。缺乏专业化意味着系统无法优先考虑最新信息、解析特定领域的格式或理解特定任务的细微差别。因此，用户只能获得一种肤浅、不可靠的体验，无法满足他们的需求。

为了解决这个问题，请专注于特定的领域和用例。通过深入挖掘而不是广泛涉猎来缩小范围。这将创造出与用户产生共鸣的特定领域工具。专业化还可以让你坦诚地说明系统的功能和局限性。透明地说明系统能做什么和不能做什么，表明了自我认知，帮助用户了解它在哪里可以增加最大的价值，从而建立对输出的信任和信心。

构建LLMOps，但要出于正确的理由：更快的迭代

DevOps从根本上来说，并不是关于可重复的工作流程、左移或赋能小型团队——也绝对不是关于编写YAML文件。

DevOps的目的是缩短工作与其结果之间的反馈周期，以便积累改进而不是错误。它的根源可以追溯到精益创业运动，再到精益制造和丰田生产系统，后者强调单分钟换模和持续改进（Kaizen）。

MLOps使DevOps的形式适应了机器学习。我们拥有可重复的实验，我们拥有能够赋能模型构建者进行交付的一体化套件。而且，天哪，我们确实有YAML文件。

但作为一个行业，MLOps并没有适应DevOps的功能。它没有缩短模型与其在生产中的推理和交互之间的反馈差距。

令人鼓舞的是，LLMOps领域已经从思考诸如提示管理之类的小问题转向了阻碍迭代的难题：生产监控和持续改进，并通过评估将两者联系起来。

我们已经拥有了用于对聊天和编码模型进行中立、众包评估的交互式平台——一个集体、迭代改进的外部循环。LangSmith、Log10、LangFuse、W&B Weave、HoneyHive等工具不仅承诺收集和整理有关生产中系统结果的数据，还承诺通过与开发深度集成来利用这些数据改进系统。拥抱这些工具或构建你自己的工具。

不要构建可以购买的大语言模型功能

大多数成功的企业都不是大语言模型企业。与此同时，大多数企业都有机会通过大语言模型得到改进。

这两点观察结果常常误导领导者仓促地用大语言模型改造系统，导致成本增加、质量下降，并将它们作为ersatz发布，自诩为“人工智能”功能，并配上现在令人厌恶的闪光图标。有一种更好的方法：专注于真正符合你的产品目标并增强你的核心运营的大语言模型应用。

考虑以下一些会浪费你团队时间的误导性项目：

为你的企业构建自定义文本到SQL的功能
构建一个聊天机器人来与你的文档进行对话
将你公司的知识库与你的客户支持聊天机器人集成

虽然以上是大语言模型应用的入门级应用，但对于几乎所有产品公司来说，自己构建这些应用都没有意义。对于许多企业来说，这些都是普遍存在的问题，从有希望的演示到可靠的组件之间存在着巨大的差距——这是软件公司的惯常领域。将宝贵的研发资源投入到当前Y Combinator批次正在集体解决的普遍问题上是一种浪费。

如果这听起来像是老生常谈的商业建议，那是因为在当前炒作浪潮的狂热兴奋中，人们很容易将任何“大语言模型”都误认为是尖端的增值差异化因素，而忽略了哪些应用已经过时。

人在回路中的人工智能；以人为中心

目前，大语言模型驱动的应用还很脆弱。它们需要大量的安全防护和防御性工程，而且仍然难以预测。此外，当范围严格限定时，这些应用可能非常有用。这意味着大语言模型是加速用户工作流程的出色工具。

虽然你可能会很想想象基于大语言模型的应用完全取代一个工作流程或代替一个工作岗位，但今天最有效的范式是人机协作（参见人马棋）。当有能力的人类与针对其快速利用而调整的大语言模型功能配对时，执行任务的生产力和幸福感可以得到极大的提高。大语言模型的旗舰应用之一GitHub Copilot展示了这些工作流程的强大功能：

“总的来说，开发人员告诉我们，与不使用GitHub Copilot和GitHub Copilot Chat相比，他们对使用GitHub Copilot和GitHub Copilot Chat进行编码更有信心，因为编码更容易、错误更少、可读性更强、可重用性更高、更简洁、更易维护、更有弹性。” —Mario Rodriguez，GitHub

对于那些长期从事机器学习工作的人来说，你可能会想到“人在回路中”，但不要操之过急：人在回路中的机器学习是一种范式，它建立在人类专家确保机器学习模型按预期行为的基础上。虽然相关，但我们在这里提出的是更微妙的东西。大语言模型驱动的系统不应该成为当今大多数工作流程的主要驱动力；它们应该仅仅是一种资源。

通过以人为中心，并询问大语言模型如何支持他们的工作流程，这将导致截然不同的产品和设计决策。最终，它将促使你构建出与那些试图快速将所有责任都推卸给大语言模型的竞争对手不同的产品——更好、更有用、风险更低的产品。

从提示、评估和数据收集开始

前面的章节提供了一大堆技术和建议。需要吸收的东西太多了。让我们考虑一下最小的有用建议集：如果一个团队想要构建一个大语言模型产品，他们应该从哪里开始？

在过去的一年中，我们已经看到了足够多的例子，可以开始确信成功的大语言模型应用遵循着一致的发展轨迹。在本节中，我们将介绍这个基本的“入门”行动方案。核心思想是从简单开始，只在必要时才增加复杂性。一个不错的经验法则是，每一级的复杂性通常都需要比前一级至少多一个数量级的努力。考虑到这一点……

提示工程优先

从提示工程开始。使用我们在战术部分讨论过的所有技术。思维链、少样本示例以及结构化输入和输出几乎总是一个好主意。在尝试从较弱的模型中榨取性能之前，先使用功能最强大的模型进行原型设计。

只有在提示工程无法达到预期的性能水平时，才应该考虑微调。如果存在非功能性需求（例如，数据隐私、完全控制和成本）阻碍了专有模型的使用，从而需要你进行自托管，那么这种情况就会更频繁地出现。只要确保这些相同的隐私要求不会阻止你使用用户数据进行微调！

构建评估并启动数据飞轮

即使是刚刚起步的团队也需要评估。否则，你将不知道你的提示工程是否足够，或者你的微调模型何时可以取代基础模型。

有效的评估是针对你的任务的，并反映了预期的用例。我们推荐的第一级评估是单元测试。这些简单的断言可以检测已知或假设的故障模式，并帮助推动早期的设计决策。另请参阅其他针对特定任务的评估，例如分类、摘要等。

虽然单元测试和基于模型的评估很有用，但它们并不能取代人工评估的必要性。让人们使用你的模型/产品并提供反馈。这具有双重目的：测量现实世界的性能和缺陷率，同时收集高质量的注释数据，这些数据可用于微调未来的模型。这将创建一个随着时间的推移而复合的正反馈循环，或数据飞轮：

使用人工评估来评估模型性能和/或发现缺陷
使用注释数据来微调模型或更新提示
重复

例如，在审核大语言模型生成的摘要以发现缺陷时，我们可以用细粒度的反馈来标记每个句子，识别事实不一致、不相关或文风不佳。然后，我们可以使用这些事实不一致的注释来训练一个幻觉分类器，或者使用相关性注释来训练一个奖励模型来对相关性进行评分。另一个例子是，LinkedIn在其文章中分享了使用基于模型的评估器来估计其文章中的幻觉、负责任的人工智能违规、连贯性等的成功经验。

通过创建随着时间的推移而复合其价值的资产，我们将构建评估从纯粹的运营支出升级为战略投资，并在此过程中构建我们的数据飞轮。

低成本认知的大趋势

1971年，施乐帕克研究中心的研究人员预测了未来：我们现在生活在联网个人电脑的世界里。他们通过在发明使之成为可能的各种技术（从以太网和图形渲染到鼠标和窗口）方面发挥关键作用，帮助孕育了未来。

但他们也进行了一个简单的练习：他们着眼于非常有用（例如，视频显示器）但尚不经济（例如，驱动视频显示器所需的内存要花费数千美元）的应用。然后，他们研究了该技术的历史价格趋势（类似于摩尔定律），并预测了这些技术何时会变得经济。

我们可以对大语言模型技术做同样的事情，即使我们没有像晶体管每美元成本那样清晰的东西可以使用。以一个流行的、长期存在的基准（例如，大规模多任务语言理解数据集）和一个一致的输入方法（五样本提示）为例。然后，比较随着时间的推移，在该基准测试上运行具有不同性能水平的语言模型的成本。

对于固定的成本，功能正在迅速增加。对于固定的功能水平，成本正在迅速下降。由共同作者Charles Frye于2024年5月13日使用公开数据创建。

自OpenAI的davinci模型作为API推出以来的四年里，以一百万个词符（大约是本文档的一百份副本）的规模运行在该任务上具有同等性能的模型的成本已从20美元降至不到10美分——每六个月减半一次。同样，截至2024年5月，通过API提供商或自行运行Meta的LLama 3 8B的成本仅为每百万个词符20美分，其性能与OpenAI的text-davinci-003类似，后者是使ChatGPT震惊世界的模型。该模型在2023年11月底发布时，每百万个词符的成本也约为20美元。这在短短18个月内就下降了两个数量级——而摩尔定律预测在同一时间段内只会翻一番。

现在，让我们考虑一下大语言模型的一个非常有用（为生成式电子游戏角色提供动力，例如Park等人）但尚不经济的应用。（他们的成本估计为每小时625美元这里）。自2023年8月该论文发表以来，成本已大幅下降了一个数量级，至每小时62.50美元。我们预计在未来9个月内，它将降至每小时6.25美元。

与此同时，当_吃豆人_在1980年发布时，按今天的货币计算，1美元可以让你玩几分钟或十几分钟——我们称之为每小时6局，即每小时6美元。这种粗略的计算表明，令人信服的大语言模型增强型游戏体验将在2025年的某个时候变得经济。

这些趋势是新出现的，只有几年的历史。但没有理由认为这一进程会在未来几年放缓。即使我们可能已经用尽了算法和数据集方面的唾手可得的成果，例如将“Chinchilla比率”（每个参数约20个词符）扩展到更大的规模，数据中心内部和硅层面的更深层次的创新和投资也有望弥补不足。

这也许是最重要的战略性事实：今天完全不可行的底层演示或研究论文将在几年内成为一项高级功能，然后很快就会成为一种商品。我们应该牢记这一点来构建我们的系统和组织。

从0到1的演示已经足够多了，是时候推出1到N的产品了

我们知道，构建大语言模型演示非常有趣。只需几行代码、一个向量数据库和一个精心设计的提示，我们就能创造出✨魔力✨。在过去的一年里，这种魔力被比作互联网、智能手机，甚至是印刷机。

不幸的是，正如任何从事过现实世界软件交付工作的人都知道的那样，在受控环境中工作的演示与能够大规模可靠运行的产品之间存在着天壤之别。

以自动驾驶汽车为例。第一辆由神经网络驾驶的汽车出现在1988年。25年后，Andrej Karpathy第一次乘坐Waymo的演示车。又过了十年，该公司获得了无人驾驶许可证。从原型到商业产品，这需要35年的严格工程、测试、改进和监管导航。

在过去的一年里，我们敏锐地观察到了工业界和学术界的起起伏伏：大语言模型应用的N年中的第1年。我们希望我们吸取的教训——从严格的团队建设运营技术等战术到选择哪些功能在内部构建等战略视角——能够帮助你在第2年及以后取得成功，因为我们都在共同构建这项激动人心的新技术。

关于作者

Eugene Yan 负责设计、构建和运营可为大规模客户服务的机器学习系统。他目前是亚马逊的高级应用科学家，负责构建为全球数百万用户服务的推荐系统，并将大语言模型应用于更好地服务客户。此前，他曾在Lazada（被阿里巴巴收购）领导机器学习团队，并在一家医疗科技A轮公司工作。他在eugeneyan.com和ApplyingML.com上撰写和演讲有关机器学习、推荐系统、大语言模型和工程的内容。

Bryan Bischof 是Hex的人工智能主管，领导着构建Magic（数据科学和分析副驾驶）的工程师团队。Bryan曾在数据堆栈的各个方面工作，领导过分析、机器学习工程、数据平台工程和人工智能工程团队。他创建了Blue Bottle Coffee的数据团队，领导了Stitch Fix的多个项目，并建立了Weights and Biases的数据团队。Bryan此前与O’Reilly合著了《构建生产推荐系统》一书，并在罗格斯大学研究生院教授数据科学和分析。他拥有纯数学博士学位。

Charles Frye 教授人们构建人工智能应用。在发表了精神药理学和神经生物学方面的研究成果后，他获得了加州大学伯克利分校的博士学位，其论文研究的是神经网络优化。他曾在Weights and Biases、Full Stack Deep Learning和Modal从事教育和咨询工作，教授了数千人人工智能应用开发的整个流程，从线性代数基础知识到GPU奥秘以及构建可防御的业务。

Hamel Husain 是一位拥有超过25年经验的机器学习工程师。他曾在Airbnb和GitHub等创新公司工作，其中包括OpenAI使用的早期大语言模型研究,-evaluation%20suite%20where)（用于代码理解）。他还领导并贡献了许多流行的开源机器学习工具。Hamel目前是一名独立顾问，帮助各公司运营大型语言模型（LLM），以加速他们的人工智能产品开发之旅。

Jason Liu 是一位杰出的机器学习顾问，以领导团队成功交付人工智能产品而闻名。Jason的技术专长涵盖个性化算法、搜索优化、合成数据生成和MLOps系统。

他的工作经历包括Stitch Fix等公司，他在那里创建了一个推荐框架和可观察性工具，每天处理3.5亿个请求。其他职位包括Meta、纽约大学以及Limitless AI和Trunk Tools等初创公司。

Shreya Shankar 是一位机器学习工程师，也是加州大学伯克利分校的计算机科学博士生。她是两家初创公司的第一位机器学习工程师，从头开始构建了每天为数千名用户提供服务的人工智能产品。作为一名研究人员，她的工作重点是通过以人为本的方法解决生产机器学习系统中的数据挑战。她的作品曾发表在VLDB、SIGMOD、CIDR和CSCW等顶级数据管理和人机交互场所。

联系我们

我们很乐意听取您对这篇文章的意见。您可以通过[email protected]与我们联系。我们中的许多人都乐于接受各种形式的咨询和建议。如果您有需要，我们将在您与我们联系后，将您引荐给合适的专家。

致谢

这个系列文章起源于群聊中的一次对话，Bryan在对话中开玩笑说，他受到了启发，想写一篇“人工智能工程元年”。然后，群聊中就出现了✨魔力✨（见下图），我们都受到了启发，想要贡献自己的力量，分享我们迄今为止学到的东西。

作者要感谢Eugene领导了大部分文档整合和整体架构工作，以及提供了大量的经验教训。此外，还要感谢他承担了主要的编辑职责和文档指导工作。作者要感谢Bryan的灵感，是他促成了这篇文章的诞生，并将文章重构为战术、运营和战略三个部分及其引言，并促使我们从更大的角度思考如何接触社区并为社区提供帮助。作者要感谢Charles对成本和LLMOps的深入研究，以及他对经验教训的梳理，使它们更加连贯和紧凑——你应该感谢他，因为这篇文章只有30页，而不是40页！作者感谢Hamel和Jason分享了他们为客户提供咨询服务和工作在一线的经验，感谢他们从客户那里获得的广泛的、可概括的经验

分享介绍就到这里，有什么疑问或者问题，可以留言交流哦~

关注我公众号（设计小站）：sjxz00，获取更多AI辅助设计和设计灵感趋势。