技术媒体O'Reilly有一组名为《What We Learned from a Year of Building with LLMs》（我们从一年的大型语言模型建设中学到了什么）的系列文章，一个专业技术团队为所有利用 LLM 打造产品的人分享了一些建议和经验教训，包括战术、运营和战略三部分。

在本篇之前的第一部分是战术：为实现特定目标而采取的具体行动；第二部分是运营：为支持战术工作以实现目标而实施的更高级别的流程。这是第三部分，为使用 LLM 构建的从业者和从事周末项目的黑客分享使用大型语言模型进行构建的战略。

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

我们提供自己的观点，例如“PMF 之前不使用 GPU”和“关注系统而不是模型”，以帮助团队确定将稀缺资源分配到何处。我们还建议了迭代以打造出优质产品的路线图。这最后一组课程回答了以下问题：

1. 构建与购买：何时应训练自己的模型，何时应利用现有 API？答案一如既往是“视情况而定”。我们分享了这取决于什么。
2. 不断迭代，成就卓越：除了使用最新模型之外，如何才能创造持久的竞争优势？我们讨论了围绕模型构建强大系统以及专注于提供令人难忘、令人难忘的体验的重要性。
3. 以人为本的人工智能：如何有效地将 LLM 融入人类工作流程，以最大限度地提高生产力和幸福感？我们强调构建支持和增强人类能力的人工智能工具的重要性，而不是试图完全取代它们。
4. 入门：团队着手构建 LLM 产品时需要执行哪些基本步骤？我们概述了一个基本剧本，从快速工程、评估和数据收集开始。
5. 低成本认知的未来：LLMs (LLM) 成本的快速下降和能力的不断提升将如何塑造人工智能应用的未来？我们研究历史趋势，并通过一种简单的方法来估计某些应用何时可能具有经济可行性。
6. 从演示到产品：如何才能将引人入胜的演示转变为可靠、可扩展的产品？我们强调需要严格的工程、测试和改进，以弥合原型和生产之间的差距。

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

策略：利用LLMs进行建设，避免被别人超越

成功的产品需要周密的规划和严格的优先级排序，而不是无休止地设计原型或追随最新的模型发布或趋势。在最后一节中，我们将从各个角度来思考构建优秀 AI 产品的战略考虑因素。我们还将研究团队将面临的关键权衡，例如何时构建和何时购买，并为早期 LLM 应用程序开发策略提供“剧本”。

PMF 之前没有 GPU

要想成为优秀产品，您的产品需要的不仅仅是对他人 API 的薄包装。但相反方向的错误可能会付出更大的代价。过去一年，大量风险投资，包括令人瞠目结舌的 60 亿美元 A 轮融资，都花在了训练和定制模型上，而没有明确的产品愿景或目标市场。在本节中，我们将解释为什么立即开始训练自己的模型是一个错误，并考虑自托管的作用。

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

对于大多数组织来说，从头开始预先训练 LLM 是不切实际的，会分散他们对产品构建的注意力。

尽管这很令人兴奋，而且似乎每个人都在做这件事，但开发和维护机器学习基础设施需要大量资源。这包括收集数据、训练和评估模型以及部署它们。如果你仍在验证产品与市场的契合度，这些努力将分散你开发核心产品的资源。即使你拥有计算、数据和技术能力，预训练的 LLM 也可能会在几个月内过时。

以BloombergGPT为例，这是一门专门为金融任务训练的LLMs课程。该模型在 3630 亿个 token 上进行了预训练，需要 9 名全职员工（其中 4 名来自 AI 工程部门，5 名来自 ML 产品和研究部门）的艰苦努力。尽管付出了这些努力，但在一年之内，它在这些金融任务上就被GPT-3.5-turbo 和 GPT-4 超越。

受 OpenAI GPT 底层技术的启发，彭博社开发了 BloombergGPT。

这个故事和其他类似的故事表明，对于大多数实际应用来说，从头开始预训练 LLM（即使是使用特定领域的数据）并不是资源的最佳利用方式。相反，团队最好根据自己的特定需求微调最强大的开源模型。

当然也有例外。一个典型的例子是 Replit 的代码模型，它专门为代码生成和理解而训练。通过预训练，Replit 能够胜过其他大型模型，例如 CodeLlama7b。但随着其他功能越来越强大的模型的发布，维持实用性需要持续的投资。

除非你证明有必要，否则不要进行微调

对于大多数组织而言，微调更多是由 FOMO 而不是清晰的战略思维驱动的。

组织过早地投资微调，试图打破“只是另一个包装”的指控。事实上，微调是重型机器，只有在你收集了大量例子，让你相信其他方法不够用之后，才能部署。

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

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

最后，请记住，LLM 支持的应用程序不是科学展览项目；对它们的投资应与它们对您的业务战略目标及其竞争差异化的贡献相称。

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

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

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

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

不断迭代，直至取得巨大成功

为了长期保持竞争优势，您需要超越模式，思考如何让您的产品与众不同。虽然执行速度很重要，但它不应该是您唯一的优势。

模型不是产品，而是围绕它的系统

对于没有构建模型的团队来说，快速的创新步伐是一种福音，因为他们从一个 SOTA 模型迁移到另一个 SOTA 模型，追求上下文规模、推理能力和性价比的提升，以构建越来越好的产品。

这一进展令人兴奋，也是可以预见的。总而言之，这意味着模型可能是系统中最不耐用的组件。

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

• 评估框架：可靠地衡量跨模型任务的性能
• 护栏：无论模型如何，都要防止出现不良输出
• 缓存：通过完全避免使用模型来减少延迟和成本
• 数据飞轮：为上述一切的迭代改进提供动力

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

但这并不意味着在应用层构建是没有风险的。如果 OpenAI 或其他模型提供商想要提供可行的企业软件，他们也需要剃掉同样的牦牛。

例如，一些团队投资构建自定义工具来验证专有模型的结构化输出；在这里，最小限度的投资很重要，但深度投资并不是一种很好的时间利用方式。OpenAI 需要确保当您请求函数调用时，您会得到一个有效的函数调用——因为他们的所有客户都希望这样。在这里​​采用一些“战略性拖延”，构建您绝对需要的东西，然后等待提供商对功能的明显扩展。

从小事做起建立信任

打造一款试图满足所有人需求的产品只会让产品变得平庸。要打造出引人注目的产品，公司需要专注于打造令人难忘、令人难忘的体验，让用户不断回头。

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

为了解决这个问题，请专注于特定领域和用例。通过深入而不是广泛来缩小范围。这将创建与用户产生共鸣的特定领域的工具。专业化还可以让您坦率地了解系统的功能和局限性。对您的系统能做什么和不能做什么保持透明可以展示自我意识，帮助用户了解它可以在哪些方面增加最大的价值，从而建立对输出的信任和信心。

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

从根本上来说，DevOps 并不涉及可重复的工作流程、左移或授权两个披萨团队——而且它绝对不是关于编写 YAML 文件。

DevOps 旨在缩短工作与结果之间的反馈周期，以便改进而不是错误。它的根源可以追溯到精益创业运动、精益制造和丰田生产系统，其重点是单分钟模具交换和改善。

MLOps 已将 DevOps 的形式应用于 ML。我们有可重复的实验，并且拥有让模型构建者能够交付的一体化套件。天哪，我们有 YAML 文件。

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

令人欣慰的是，LLMOps 领域已经不再考虑诸如快速管理之类的小心思问题，而是转向解决阻碍迭代的难题：通过评估将生产监控和持续改进联系起来。

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

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

大多数成功的企业都不是LLMs企业。同时，大多数企业都有机会通过LLMs得到提升。

这两种观察结果往往会误导领导者匆忙改造系统，增加成本，降低质量，并将其作为虚假的虚荣“AI”功能发布，并附上现在令人恐惧的闪光图标。有更好的方法：专注于真正符合您的产品目标并增强您的核心运营的 LLM 应用程序。

考虑一下一些浪费你的团队时间的错误做法：

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

虽然以上只是 LLM 应用程序的入门级应用，但对于几乎任何一家产品公司来说，它们都没有任何意义去自行构建。对于许多企业来说，这些都是普遍存在的问题，因为有前途的演示和可靠的组件之间存在很大差距——这是软件公司的惯常领域。将宝贵的研发资源投入到当前 Y Combinator 批次正在大量解决的一般问题上是一种浪费。

如果这听起来像是陈腐的商业建议，那是因为在当前炒作浪潮的泡沫兴奋中，人们很容易将任何“LLMs”误认为是前沿的增值差异化，而忽略了哪些应用已经是过时的。

人工智能在循环中；人类处于中心

目前，基于 LLM 的应用程序很脆弱。它们需要大量的安全防护和防御工程，并且仍然难以预测。此外，当范围严格限制时，这些应用程序可能会非常有用。这意味着 LLM 是加速用户工作流程的绝佳工具。

尽管人们可能很容易想象基于 LLM 的应用程序会完全取代工作流程或替代工作职能，但如今最有效的范例是人机半人马（高级国际象棋，人类棋手使用计算机程序来探索候选走法）。当有能力的人与经过调整以快速利用的 LLM 功能相结合时，执行任务的生产力和幸福感可以大大提高。LLM 的旗舰应用程序之一 GitHub Copilot 展示了这些工作流程的强大功能：

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

对于那些长期从事机器学习的人来说，你可能会想到“人机协同”的概念，但不要这么快：HITL 机器学习是一种建立在人类专家基础上的范式，以确保机器学习模型的行为符合预期。虽然相关，但我们在这里提出的建议更微妙。LLM 驱动的系统不应成为当今大多数工作流程的主要驱动因素；它们应该只是一种资源。

通过以人为本并询问 LLM 如何支持他们的工作流程，这会导致截然不同的产品和设计决策。最终，它将促使您打造与试图将所有责任迅速转移给 LLM 的竞争对手不同的产品——更好、更有用、风险更低的产品。

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

前面几节已经提供了大量的技术和建议。需要学习的内容很多。让我们考虑一下最有用的建议：如果一个团队想要构建 LLM 产品，他们应该从哪里开始？

在过去的一年里，我们已经看到了足够多的例子，开始有信心成功的 LLM 申请遵循一致的轨迹。我们将在本节中介绍这个基本的“入门”手册。核心思想是从简单开始，只在需要时增加复杂性。一个不错的经验法则是，每个复杂程度通常需要比之前至少多一个数量级的努力。考虑到这一点……

快速工程是重中之重

从快速工程开始。使用我们之前在策略部分讨论过的所有技术。思路链、n 次样本和结构化输入和输出几乎总是一个好主意。在尝试从较弱的模型中榨取性能之前，先使用性能最强的模型进行原型设计。

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

建立评估并启动数据飞轮

即使是刚起步的团队也需要评估。否则，您将不知道您的快速工程是否足够，或者您的微调模型何时可以替换基础模型。

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

虽然单元测试和基于模型的评估很有用，但它们并不能取代人工评估。让人们使用您的模型/产品并提供反馈。这可以达到双重目的，既可以衡量实际性能和缺陷率，又可以收集可用于微调未来模型的高质量注释数据。这会创建一个正反馈循环或数据飞轮，随着时间的推移，它会不断累积：

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

例如，在审核 LLM 生成的摘要是否存在缺陷时，我们可能会为每个句子添加细粒度的反馈，以识别事实不一致、不相关或风格不佳。然后，我们可以使用这些事实不一致注释来训练幻觉分类器，或使用相关性注释来训练奖励模型以对相关性进行评分。再举一个例子，LinkedIn 在其文章中分享了其使用基于模型的评估器来评估幻觉、负责任的 AI 违规、连贯性等方面的成功经验。

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

低成本认知的高层趋势

1971 年，施乐帕克研究中心的研究人员预测了未来：我们现在生活的联网个人计算机世界。他们在以太网和图形渲染到鼠标和窗口等技术发明中发挥了关键作用，推动了这一未来的诞生。

但他们也做了一个简单的练习：他们研究了非常有用（例如视频显示器）但尚不经济的应用程序（即，驱动视频显示器所需的 RAM 需要数千美元）。然后他们研究了该技术的历史价格趋势（摩尔定律），并预测了这些技术何时会变得经济实惠。

我们可以对 LLM 技术做同样的事情，即使我们没有像每美元晶体管数这样清晰的东西可供使用。采用一个流行的、长期存在的基准，如大规模多任务语言理解数据集，以及一致的输入方法（五次提示）。然后，比较在一段时间内在此基准上运行具有各种性能水平的语言模型的成本。

对于固定成本，能力正在迅速提升。对于固定能力水平，成本正在迅速下降。由合著者 Charles Frye 于 2024 年 5 月 13 日使用公开数据创建。

自 OpenAI 的 Davinci 模型作为 API 推出以来的四年里，在 100 万个代币（约 100 份本文档）规模上运行具有同等性能的模型的成本已从 20 美元降至不到 10 美分，减半时间仅为六个月。同样，截至 2024 年 5 月，通过 API 提供商或自行运行 Meta 的 LLama 3 8B 的成本仅为每百万个代币 20 美分，其性能与 OpenAI 的 text-davinci-003 模型相似，该模型使 ChatGPT 震惊了世界。该模型在 2023 年 11 月下旬发布时，每百万个代币的成本也约为 20 美元。这在短短 18 个月内就实现了两个数量级的提升，而摩尔定律预测的翻倍时间范围也恰好相同。

现在，让我们考虑一个非常有用的 LLM 应用（为生成视频游戏角色提供动力，就像 Park 等人那样），但目前还不经济。（他们的成本估计为每小时 625 美元。）自 2023 年 8 月发表该论文以来，成本已下降了大约一个数量级，降至每小时 62.50 美元。我们预计，在未来九个月内，成本将降至每小时 6.25 美元。

与此同时，当Pac-Man于 1980 年发布时，今天的 1 美元可以购买一个积分，可以玩几分钟或几十分钟——每小时玩六场游戏，或者每小时 6 美元。这项餐巾纸上的数学计算表明，引人注目的 LLM 增强游戏体验将在 2025 年的某个时候变得经济实惠。

这些趋势是新的，只有几年的历史。但是，几乎没有理由认为这一进程会在未来几年放缓。即使我们可能用尽算法和数据集中唾手可得的成果，比如超过每个参数约 20 个令牌的“Chinchilla 比率”，数据中心和硅层内部的更深层次的创新和投资有望弥补不足。

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

0 到 1 的演示已经足够，是时候进行 1 到 N 的产品了

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

不幸的是，任何参与过现实世界软件交付的人都知道，在受控环境下运行的演示和在规模上可靠运行的产品之间存在着天壤之别。

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

在行业和学术界的不同领域，我们敏锐地观察了过去一年的起起落落：这是 N 申请LLMs的第一年。我们希望我们学到的经验教训——从组建团队的严格操作技术等策略到内部构建哪些能力等战略观点——能够帮助您在第二年及以后继续前进，因为我们都在共同开发这项令人兴奋的新技术。