捣鼓了一年的LLM应用,我们学到了啥——Part I

之前分享了我们在运营LLM应用时磨练出来的战术(tactics)【指之前的Part I 和Part II两篇文章】。战术是具体的：是为实现目标而采取的具体行动。我们还分享了对运营（Operations）的看法：为了执行战术，达到目标，而制定的更高层次的流程。

但这些目标是从哪里来的呢？这就是战略。如果说战术和运营回答了"如何做"(how)的问题，那么战略(Strategy)就是回答更深层次的“做什么(what)”和“为什么(why)”问题。

我们分享的是自己的主观看法，比如“在 PMF(Product Market Fit) 之前不要买 GPU”和“专注于系统而不是模型”，以帮助团队决定如何合理分配有限资源。还提出了一条迭代出卓越产品的路线图。这一系列经验教训回答了以下问题：

1.自建还是购买：什么时候应该训练自己的模型，什么时候应该利用SaaS模型 API？答案总是“具体情况具体分析”。我们分享什么是"具体情况"。

2.迭代出卓越的产品：如何创造持久的竞争优势，而不仅仅是使用最新模型特性？我们讨论了围绕模型构建健壮系统的重要性，并专注于提供难以忘怀、深入人心的体验。

3.以人为中心的AI：如何有效地将LLMs整合到人类工作流程中，最大程度地提高人类生产力和幸福感？我们强调建立支持和增强人类能力的AI工具的重要性，而不是试图完全取代他们。

4.入门指南：团队开始构建LLM产品的关键步骤是什么？我们提供了一个从提示工程、评估和数据收集开始的基本行动指南。

5.低成本认知智能的未来：大模型成本迅速下降和功能不断增强，这将如何塑造人工智能应用的未来？我们审视历史趋势，并介绍一种简单方法来估计某些应用何时可能变得经济可行。

6.从演示到产品：如何将引人注目的演示转化为可靠、可扩展的产品？我们强调了严格的工程、测试和完善的必要性，以弥合原型和生产之间的差距。

回答这些困难的问题，让我们一步一步地思考...【作者在玩CoT的梗】

1. 战略：利用LLMs构建应用，但是不要被它超越

成功的产品需要周密的规划和艰难的优先级排序，而不是无休止的原型制作或追随最新的模型发布和趋势。我们在此展望未来，思考构建优秀AI产品的战略考量。我们还研究了团队将面临的关键权衡，比如何时自建和何时购买，并为早期大型语言模型（LLM）应用开发策略提出了一个"玩家手册"。

2. 在 PMF 之前别买GPU

出色的AI产品不能仅仅是别人 API 的"套壳"。但是，走向另外一个极端可能代价会更大。过去一年，我们看到了大量风险投资，包括一个令人瞠目结舌的 60 亿美元的 A 轮融资，在缺乏明确的产品愿景或目标市场的情况下用于训练和定制模型。在本节中，我们将解释为什么着急要训练自己的"专属模型"是一个错误，并考虑自部署模型的角色。

2.1 从头开始训练（几乎）没有意义

对于大多数组织来说，如果想构建一个AI产品而去从头开始预训练一个LLM，是一种不切实际的做法。

尽管构建和维护机器学习的基础设施看起来很爽，而且好像每个人都在做，但实际上这需要大量资源。这包括收集数据、训练和评估模型以及部署它们。如果您仍在验证PMF(Product Marketing Fit)，这些努力将分散你的资源，使你无法专注于开发核心产品。即使您拥有算力、数据和技术能力，预训练的LLM也可能在几个月内过时。

看一下 BloombergGPT 的案例，这是一个专门针对金融任务进行训练的模型。该模型在 363B Tokens上进行了预训练，他们投入了九名员工倾尽全力，其中四名来自 AI 工程部门，五名来自 ML 产品和研究部门。尽管付出不少，但在一年内，它就被 gpt-3.5-turbo 和 gpt-4 在金融任务上超越了。

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

当然也有例外情况。一个突出的例子是 Replit 的代码模型，专门针对代码生成和理解进行训练。通过预训练，Replit 能够胜过其他大型模型，比如 CodeLlama7b。但随着其他越来越强大的模型的发布，保持实用性需要持续投资。

2.2 不要微调，除非真的有必要

对于大多数组织来说，微调更多地是受到 FOMO (错失恐惧症 Fear of Missing Out)的驱动，而不是清晰的战略考量。

试图打破“只是另一个套壳应用”的指责，组织往往过早投资到微调当中。实际上，微调是一种"重型装备"，只有在收集了足够多的例子并让您确信其他方法都行不通时才能采用。

一年前，许多团队告诉我们他们对微调感到兴奋。但很少有团队找到了产品市场契合度，大多数人后悔他们的当初的决定。如果你要进行微调，最好确信自己已经准备好了持续不断的，重复的进行微调，因为基础模型在改进——请参见下面的“模型不是产品”和“构建 LLMOps”。

在什么情况下微调实际上是正确的选择？如果应用场景需要的数据，不在用于现有模型训练的开放数据集中，而且您已经构建了一个证明现有模型不足的 MVP(最小可行系统)。但要小心：如果优质的训练数据对模型厂商都不容易获得，那么你从哪里获取它呢？

最终，请记住，LLM 驱动的应用程序不是一个科学展示项目，对它们的投资应该与它们对您企业战略目标和差异化竞争带来的贡献相称。

2.3 从使用API 开始，但不要害怕自部署

利用LLM的 API，初创公司现在更容易利用和整合LLM的能力，而无需从头开始训练自己的模型。像 Anthropic 和 OpenAI 这样的供应商提供了通用API，只需几行代码就可以为您的产品增加智能。通过使用这些服务，您可以减少花费的精力，而是专注于为客户创造价值，这样可以更快地验证想法并朝着产品市场契合度(PMF)迭代。

但是，就像数据库一样，托管服务并不适合每种用例，特别是在规模和需求增加的情况下。事实上，自部署可能是在受监管行业（如医疗保健和金融业）或在不能将机密/私人数据发送到您的网络之外的唯一方法。

此外，自部署可以规避推理提供者施加的限制，如速率限制、模型淘汰和使用限制。此外，自部署使您完全控制模型，更容易围绕其构建差异化、高质量的系统。最后，自部署，尤其是微调，可以在很大程度上降低成本。例如，Buzzfeed 分享了他们如何微调开源LLMs以降低了 80%成本。

3. 迭代至卓越

为了长期保持竞争优势，你需要超越模型来思考，如何使你的产品脱颖而出。执行速度固然重要，但不应该是你唯一的优势。

3.1 模型不是你的产品，系统才是

对于不构建模型的团队来说，模型的不断快速创新是一个福音，模型不断达到SOTA，追求在上下文长度、推理能力和性价比方面的提升，以此构建越来越好的产品。

这一进步既令人兴奋又可以预见。综合起来，这意味着模型很可能是系统中变化最快的组件。

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

•评估框架：可靠地测量不同模型在执行你的任务时表现

•护栏【这里应该指对齐系统】：无论模型如何，都要防止你不希望的输出

•缓存：通过避免完全加载模型来减少延迟和成本

•数据飞轮：推动一切不断改进的动力

这些组件共同构建了比原始模型能力更深厚的产品质量护城河。

但这并不意味着在应用层构建就没有风险。不要试图解决那些OpenAI或其他模型提供商为了提供可行的企业软件而必须解决的问题。

例如，一些团队投资于构建定制工具来验证专有模型的结构化输出；在这里进行最小的投资是重要的，但深入的投资并不是一个好的时间分配。OpenAI 需要确保当您请求函数调用时，您会得到一个有效的函数调用——因为他们所有的客户都希望如此。在这里采用一些“战略性拖延”，构建您绝对需要的内容，并等待供应商提供的明显扩展能力。【这是我们之前一直强调的，先把车造了，等一个好的发动机】

3.2 从小处开始建立信任

试图迎合所有人的产品是平庸的秘诀。为了创造引人入胜的产品，公司需要专注于打造令人难忘、让用户回头的粘性体验。

考虑一个通用的 RAG 系统，旨在回答用户可能提出的任何问题。缺乏专业化意味着系统无法考虑最新信息，解析特定领域的格式，或理解特定任务的细微差别。最终，用户得到的是肤浅、不可靠的体验，无法满足他们的需求。

为了解决这个问题，专注于特定领域和使用场景。优先考虑深度而不是广度。这将创造与用户共鸣的特定领域工具。专业化还可以让您坦率地介绍系统的能力和局限性。

透明的展示什么是系统能做的什么是不能做的，说明你很有自知之明。帮助用户了解你的应用可以为他们哪些地方带来最大价值，从而建立对应用输出的信心和信任。

3.3 构建 LLMOps，但要出于正确的原因：更快的迭代

DevOps 的根本不在于可重用工作流程、 shifting left（左移）或构建Two Pizza Team小团队，更不是关于编写 YAML 文件。

DevOps旨在缩短工作与成果之间的反馈周期，以积累改进而非错误。其根源可追溯至精益创业运动，进而到达精益制造和丰田生产系统，强调单分钟交换模具和持续改进（Kaizen）。

MLOps已经将DevOps的形式适应到了机器学习（ML）中。我们有了可复现的实验，以及一套全集工具，这些工具赋予模型构建者部署模型的能力。老天，我们确实有了很多YAML文件。

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

令人振奋的是，LLMOps 领域已经摆脱了关注像提示词管理这样的小妖怪，转而关注阻碍迭代的困难问题：生产监控和持续改进，通过评估相互联系。

我们已经拥有用于聊天和编码模型的交互式竞技场，进行中立、众包评估——一个集体迭代改进的外循环。像LangSmith、Log10、LangFuse、W&B Weave、HoneyHive等工具不仅承诺收集和整理有关生产系统结果的数据，而且还通过与开发紧密结合来利用它们来改进这些系统。你可以使用这些工具或者自己构建自己的。

3.4 不要构建可以购买的LLM功能

大多数成功的企业不是LLM企业。同时，大多数企业都有机会通过LLM得到改进。

上面的观察结果常常误导领导者急于求成的以增加成本和降低质量的方式，将系统匆忙地改造为搭载大型语言模型（LLMs）的应用，并将它们作为假冒的、虚荣的“AI”特性发布，配上各种唬人的闪亮图标。更好的方法是：专注于与您的产品目标一致且能提升你核心运营的LLM应用。

考虑一些会浪费团队时间的做法

•为您的业务构建定制Text-to-SQL 的能力。【是的，对于要做ChatBI的应用一般都是劝退】

•构建一个与您的文档交谈的聊天机器人。

•将您公司的知识库与客户支持聊天机器人集成。

虽然以上是LLM应用程序的基本应用，但对于几乎任何产品公司来说，建立这些应用程序都没有意义。这些是许多企业普遍存在的一般问题，将一个激动人性的演示转变成可靠应用组件之间还存在很大差距，这是属于软件公司的传统领域。将宝贵的研发资源投入到当前 Y Combinator 正在大规模批量解决的一般问题上是一种浪费。

如果这听起来像是老掉牙的商业建议，那是因为在当前炒作浪潮的兴奋中，很容易将任何“LLM”都误认为是尖端、增值的差异化，忽略了哪些应用是已经过时的。

3.5 应用AI；以人类为中心

目前，基于LLM的应用程序很脆弱。它们需要大量的保护、防御性工程，并且很难预测。但是，当这些应用程序被严格限定范围时，它们可以极其有用。这意味着LLMs是加快用户工作流程的优秀工具。

尽管想象基于LLM的应用程序完全取代工作流程或替代工作职能可能很诱人，但如今最有效的范式是Copilot形式（参见半人马国际象棋）。当有能力的员工与专为他们快速利用而调整的LLM能力配合工作时，任务的生产力和幸福感可以大幅提高。LLMs的旗舰应用之一，GitHub CoPilot，展示了这些工作流程的力量：

“总的来说，开发人员告诉我们，使用 GitHub Copilot 和 GitHub Copilot Chat 进行编码比不使用它们时更容易、更无错误、更易读、更可重用、更简洁、更易维护和更具弹性，因此他们感到更加自信。”– Mario Rodriguez，GitHub

对于那些长期从事机器学习的人来说，你可能会跳到“人机协同(Human-In-The-Loop)”这个想法，但不要那么快：HITL 机器学习是建立在人类专家确保 ML 模型表现如预期的范式上。虽然相关，但我们在这里提出的是更微妙的东西。今天，LLM驱动的系统不应该是大多数业务流程的主要驱动力，它应该只是一种资源。

通过以人为中心，并询问LLM如何支持他们的工作流程，这将导致显著不同的产品和设计决策。最终，这将驱使您构建与试图迅速将所有责任转移到LLMs的竞争对手不同的产品；更好、更有用、更少风险的产品。

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

前面的部分提供了大量的技术和建议。这是很多要消化的。让我们考虑一组最小有用的建议：如果一个团队想要构建一个产品，他们应该从哪里开始？

在过去的一年里，我们已经看到足够的例子，开始对成功的LLM应用程序遵循一致的轨迹变得自信。我们将在本节中介绍这个基本的“入门”指南。核心思想是从简单开始，只在需要时添加复杂性。一个不错的经验法则是，每个复杂性层次通常至少需要比前一个层次多一个数量级的努力。考虑到这一点…

4.1 提示工程优先

从提示工程开始。使用我们在战术部分讨论过的所有的技术。思维链、n -shots和结构化的输入和输出几乎总是一个好主意。在尝试从较弱的模型中挤出性能之前，先用最高性能的模型制作原型。【是的，如果应用场景连GPT4都无法支持实现，那么证明这个应用现在不太可行】

只有在提示工程无法达到所需的性能水平时，你才应考虑微调。只有存在非功能性需求（例如数据隐私、完全控制、成本）阻碍了专有模型的使用时，才需要自部署。但是要确保这些隐私要求不会阻止你使用用户数据对模型进行微调！

4.2 构建评估并启动数据飞轮

即使是刚刚开始的团队也需要评估。否则，您将不知道您的提示工程是否足够，或者您的微调模型何时准备好替换基础模型。

有效的评估是针对您的任务具体化的，并反映了预期的使用情况。我们建议的第一级评估是单元测试。这些简单的断言可以检测已知或假设的故障模式，并有助于推动早期设计决策。还可以查看其他针对分类、摘要等任务的特定评估。

虽然单元测试和基于模型的评估很有用，但它们并不能取代人类评估的必要性。让人们使用您的模型/产品并提供反馈。这既可以用来衡量实际性能和缺陷率，也可以收集高质量的带标注的数据，用于微调未来的模型。这创造了一个积极的反馈循环，或数据飞轮，随着时间的推移而增长：

•人类评估以评估模型性能和/或发现缺陷

•使用带标注的数据来微调模型或更新提示

•重复

例如，当审计LLM生成的缺陷摘要时，我们可能会使用细粒度反馈为每个句子打上标签，识别事实不一致、无关或风格差的问题。然后，我们可以使用这些事实不一致的注释来训练一个幻觉分类器，或者使用相关性注释来训练一个奖励模型以评分相关性。另一个例子是，LinkedIn 分享了他们成功使用基于模型的评估器来估计幻觉、负责任的 AI 违规行为、连贯性等的经验。

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

5. 低成本认知的趋势

1971 年，施乐PARC研究人员预测到了未来：我们现在生活在的网络个人电脑世界。他们通过在使这一未来成为可能的技术发明中发挥关键作用，如以太网、图形渲染、鼠标和窗口等，帮助孕育了这一未来。

但他们也进行了一个简单的练习：他们看了一些非常有用的应用程序（例如视频显示），但尚未经济实惠（即，足够的 RAM 来驱动视频显示需要成千上万美元）。然后，他们查看了该技术的历史价格趋势（类似摩尔定律），并预测了这些技术何时会变得经济实惠。

我们可以对LLM种技术做同样的事情，尽管我们没有像每美元晶体管那样干净的东西可以使用。拿一个流行的、历史悠久的基准，比如大规模多任务语言理解数据集，以及一个一致的输入方法（五次提示）。然后，比较随着时间推移在这个基准上运行语言模型的成本与各种性能水平。

对于固定成本，能力迅速增加。对于固定能力水平，成本迅速降低。由合著者Charles Frye使用 2024 年 5 月 13 日的公共数据创建。

自 OpenAI 的davinci模型作为 API 推出以来的四年里，以每百万Token（大约是这份文件的一百倍）规模运行具有相同性能的模型的成本已从 20 美元降至不到 10 美分，减半时间仅为六个月。同样，截至 2024 年 5 月，通过 API 提供商或自己运行 Meta 的 LLaMA 3 8B 的成本仅为每百万 token 20 美分，并且其性能与 OpenAI 的文本Davinci-003 相似，这是使 ChatGPT 震惊世界的模型。当这个模型在 2023 年 11 月底发布时，每百万Token的成本也约为 20 美元。在短短 18 个月内，这是两个数量级的变化，而摩尔定律预测仅仅是翻倍的时间框架。

现在，让我们考虑一个非常有用的LLMs的应用（为生成式视频游戏角色提供动力，如 Park 等人所述），但目前还不经济（他们的成本在这里估计为每小时 625 美元）。自那篇论文于 2023 年 8 月发表以来，成本已经下降了大约一个数量级，降至每小时 62.50 美元。我们可能期望在另外九个月内降至每小时 6.25 美元。

与此同时，当《吃豆人》于 1980 年发布时，今天的 1 美元可以购买一次游戏，可以玩几分钟或几十分钟——每小时大约 6 场比赛，或每小时 6 美元。这种粗略的数学计算表明，一个引人注目的LLM增强型游戏体验将在2025年的某个时候变得经济。

这些趋势是新的，只有几年的历史。但我们没有理由期望这个过程在接下来的几年里会放缓。即使我们在算法和数据集上可能用尽了低挂的果实，比如超越“Chinchilla比例”的~20个token每个参数，数据中心内部的更深层次的创新和投资以及在硅层上的投资有望弥补不足。

这也许是最重要的战略事实：今天完全不可行的展示或研究论文将在几年后成为高级功能，然后很快变成商品。我们应该以此为考量来构建我们的系统和组织。

6.  0 到 1 演示已经够多，现在是 1 到 N 产品的时候

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

不幸的是，任何在运输现实软件方面工作过的人都知道，在受控环境中运行良好的演示和在规模上可靠运行的产品之间存在着天壤之别。

以自动驾驶汽车为例。第一辆汽车是在 1988 年由神经网络驾驶的。二十五年后，Andrej Karpathy 在 Waymo 中进行了他的第一次演示乘车。十年后，该公司获得了无人驾驶许可。从原型到商业产品，经过了三十五年的严格工程、测试、改进和监管导航。

在不同行业和学术领域，我们敏锐地观察到过去一年的起起伏伏：LLM应用的第 1 年。我们希望我们所学到的经验教训——从严格的团队建设操作技巧到内部建设哪些能力等战略视角——能够帮助您在第 2 年及以后，我们共同发展这一令人兴奋的新技术。

这系列文章来自于《What We Learned from a Year of Building with LLMs 》的博文，作者一共有6个人，Eugene Yan (Amazon), Bryan Bischof (Hex), Charles Frye (Modal), Hamel Husain (Parlance Labs), Jason Liu (Instructor), 和 Shreya Shankar (UC Berkeley)。