我们在《我们从一年与大语言模型 (LLMs) 的构建中学到了什么 (第一部分)：战术篇》中分享了操作 LLM 应用程序时精炼的战术见解。战术是具体的行动，用于实现特定目标。在《我们从一年与大语言模型 (LLMs) 的构建中学到了什么 (第二部分)：运营篇》中，我们还探讨了支持战术工作的高级过程。
那么，这些目标从何而来？这就是战略的领域。战略回答了战术和运营背后的“是什么”和“为什么”问题。
我们提出了一些主张，如“在找到产品市场契合 (PMF) 之前不要使用 GPU”和“专注于系统而非模型”，以帮助团队更好地分配有限资源。我们还建议了一条迭代至优秀产品的路线图。最后一部分内容将回答以下问题：
- 构建 vs. 购买：何时应该训练自己的模型，何时应该利用现有 API？答案是“视情况而定”。我们会分享这些情况的具体影响因素。
- 迭代至优秀：如何打造持久的竞争优势，而不仅仅是使用最新的模型？我们将讨论构建强大系统和提供令人难忘体验的重要性。
- 以人为本的 AI：如何将 LLMs 有效地融入人类工作流，最大化生产力和幸福感？我们强调了构建支持和增强人类能力的 AI 工具的重要性，而不是完全取代人类。
- 入门指南：团队在开始构建 LLM 产品时的关键步骤是什么？我们会概述一个从提示工程、评估到数据收集的基本操作手册。
- 低成本认知的未来：快速降低的成本和不断增加的 LLM 能力将如何塑造 AI 应用的未来？我们将探讨历史趋势，并展示如何估算某些应用的经济可行性。
- 从演示到产品：从一个引人注目的演示到一个可靠的、可扩展的产品需要什么？我们强调了从原型到生产的严格工程、测试和改进的必要性。
要回答这些难题，让我们一步一步来思考……
战略：在构建 LLM 产品时不被超越
成功的产品需要深思熟虑的规划和艰难的优先级排序，而不是无休止的原型制作或追随最新的模型发布。在最后一部分中，我们将展望未来，思考构建优秀 AI 产品的战略考量。我们还将探讨团队将面临的关键决策，例如何时构建和何时购买，并建议一个早期 LLM 应用开发的“操作手册”。
在找到产品市场契合 (PMF) 之前不要使用 GPU
要打造优秀的产品，你的产品需要不仅仅是依赖他人 API 的简单包装。但过于依赖自己训练模型的错误也可能更加昂贵。过去一年中，我们看到大量风险投资，包括令人震惊的 60 亿美元 A 轮融资，都用在了训练和定制模型上，却没有明确的产品愿景或目标市场。在本节中，我们将解释为什么立即跳到训练自己的模型是个错误，并探讨自托管的角色。
从头训练几乎永远没有意义
对于大多数组织来说，从头预训练一个大语言模型 (LLM) 是一个不可行的分散注意力的行为。
尽管这很诱人，而且看起来似乎每个人都在这么做，但开发和维护机器学习基础设施需要大量资源。这包括收集数据、训练和评估模型以及部署它们。如果你还在验证产品市场契合 (PMF)，这些努力将分散你开发核心产品的资源。即使你拥有计算能力、数据和技术能力，预训练的 LLM 可能会在几个月内过时。
例如，BloombergGPT 是一个专门为金融任务训练的 LLM。该模型在 3630 亿个 Token 上进行了预训练，花费了 9 名全职员工（4 名来自 AI 工程团队，5 名来自 ML 产品和研究团队）的大量努力。尽管如此，它在一年内在这些金融任务上被 gpt-3.5-turbo 和 gpt-4 超越。
这个故事和其他类似的故事表明，对于大多数实际应用来说，从头预训练一个 LLM，即使是在特定领域的数据上，也不是最佳资源利用方式。相反，团队应该针对其特定需求微调最强大的开源模型。
当然，有一些例外。例如，Replit 的代码模型专门为代码生成和理解而训练。通过预训练，Replit 能够超越其他大型模型如 CodeLlama7b。但随着其他越来越强大的模型发布，保持其实用性需要持续投资。
证明有必要之前不要微调
对于大多数组织来说，微调更多是由 FOMO（错失恐惧症）驱动的，而不是清晰的战略思维。
组织过早投资于微调，试图摆脱“只是另一个包装”的指责。实际上，微调是重型操作，只有在你收集了足够的例子并确信其他方法不足时才应进行。
一年前，许多团队告诉我们他们对微调感到兴奋。很少有找到产品市场契合的，大多数都后悔自己的决定。如果你要进行微调，你最好非常有信心你已经准备好随着基础模型的改进不断重复这一过程——参见下面的“模型不是产品”和“构建 LLMOps”。
什么时候微调实际上是正确的选择？如果使用案例需要的数据在主要的开放网络规模数据集中不可用，并且你已经构建了一个 MVP，证明现有模型不足。但要小心：如果优质的训练数据对模型构建者来说不是唾手可得的，你从哪里获得这些数据？
最终，记住 LLM 驱动的应用不是科学展览项目；对它们的投资应该与它们对你企业战略目标和竞争差异化的贡献相称。
从推理 API 开始，但不要害怕自托管
通过 LLM API，初创公司比以往任何时候都更容易采用和集成语言建模功能，而无需从头训练自己的模型。像 Anthropic 和 OpenAI 这样的提供商提供的通用 API 可以通过几行代码为你的产品增添智能。使用这些服务，你可以减少花费的精力，而专注于为你的客户创造价值——这让你能够更快地验证想法并迭代到产品市场契合。
但是，与数据库一样，托管服务并不适合所有用例，尤其是随着规模和需求的增加。事实上，自托管可能是唯一的方式，尤其是在受监管的行业如医疗保健和金融中，或因合同义务或保密要求需要避免将机密/私密数据发送出你的网络。
此外，自托管可以规避推理提供商施加的限制，如速率限制、模型废弃和使用限制。此外，自托管让你完全控制模型，使得构建一个差异化的、高质量的系统变得更容易。最后，特别是针对大规模的微调，自托管可以降低成本。例如，BuzzFeed 分享了他们如何微调开源 LLM 以将成本降低 80%。
迭代到优秀
要在长期内保持竞争优势，你需要考虑超越模型的因素，考虑是什么让你的产品脱颖而出。虽然执行速度很重要，但它不应该是你唯一的优势。
模型不是产品；它周围的系统才是
对于不构建模型的团队来说，快速的创新步伐是一个福音，因为他们从一个最新的模型迁移到下一个，追求上下文大小、推理能力和性价比的提升，以构建更好的产品。
这进展既令人兴奋又可预测。综合起来，这意味着模型可能是系统中最不耐用的组件。
相反，把你的努力集中在将提供持久价值的方面，例如：
- 评估框架：可靠地衡量模型在你的任务上的表现
- 护栏：防止产生不希望的输出
- 缓存：通过避免使用模型来减少延迟和成本
- 数据飞轮：推动上述所有方面的迭代改进
这些组件比原始模型能力创建了更坚固的产品质量护城河。
但这并不意味着在应用层构建没有风险。不要在那些如果 OpenAI 或其他模型提供商想要提供可行的企业软件必须解决的问题上投入过多。
例如，一些团队投资于构建自定义工具来验证专有模型的结构化输出；在这方面的最低投资是重要的，但深度投资并不是一个好的时间利用。OpenAI 需要确保当你请求一个函数调用时，你会得到一个有效的函数调用——因为他们所有的客户都希望如此。在这里采取一些“战略拖延”，构建你绝对需要的东西，并等待提供商明显扩展的功能。
通过从小处开始建立信任
试图构建一个满足所有人需求的产品是导致平庸的配方。要创建引人入胜的产品，公司需要专注于构建令人难忘的、粘性的体验，让用户不断回归。
考虑一个旨在回答用户可能问的任何问题的通用 RAG 系统。缺乏专业化意味着系统无法优先处理最新信息、解析特定领域的格式或理解特定任务的细微差别。结果，用户得到的是一个浅薄、不可靠的体验，无法满足他们的需求。
为了解决这个问题，请专注于特定领域和用例。通过深入而不是广泛来缩小范围。这将创建与用户产生共鸣的特定领域工具。专业化还使你能够坦率地说出你的系统的能力和局限性。透明地说明你的系统能做什么和不能做什么展示了自我意识，帮助用户了解它在哪里能增加最大的价值，从而建立对输出的信任和信心。
构建 LLMOps，但为了正确的理由：更快的迭代
DevOps 本质上不是关于可重复的工作流程或左移或赋权于两比萨团队——绝对不是关于编写 YAML 文件。
DevOps 是关于缩短工作与其结果之间的反馈周期，以便改进积累而不是错误。它的根源可以追溯到精益创业运动，通过单分钟换模和持续改进强调的丰田生产系统。
MLOps 将 DevOps 的形式适应于 ML。我们有可重复的实验和全方位的套件，使模型构建者能够交付产品。主啊，我们有 YAML 文件。
但作为一个行业，MLOps 没有适应 DevOps 的功能。它没有缩短模型与其在生产中的推理和交互之间的反馈差距。
令人振奋的是，LLMOps 领域已经从思考微小心灵的烦恼，如提示管理，转向阻碍迭代的难题：生产监控和持续改进，通过评估连接。
目前，我们已经有了用于中立、众包的聊天和编码模型评估的互动竞技场——一个集体、迭代改进的外环。LangSmith、Log10、LangFuse、W&B Weave、HoneyHive 等工具不仅承诺收集和整理生产中的系统结果数据，还通过与开发深度集成来利用它们改进这些系统。拥抱这些工具或构建你自己的工具。
不要构建你可以买到的 LLM 功能
大多数成功的企业不是 LLM 企业。同时，大多数企业都有机会通过 LLM 进行改进。
这一对观察结果经常误导领导者仓促改造系统，使之具有 LLM，以增加成本并降低质量，并将其作为虚假的“AI”功能发布，附带着现在令人畏惧的闪光图标。还有一种更好的方式：专注于真正与产品目标一致并增强核心运营的 LLM 应用。
考虑一些误导团队浪费时间的项目：
- 为你的企业构建自定义的文本到 SQL 功能
- 构建一个与你的文档对话的聊天机器人
- 将你的公司知识库与客户支持聊天机器人集成
虽然上述是 LLM 应用的入门程序，但对于几乎任何产品公司来说，自己构建这些都没有意义。这些是许多企业的普遍问题，承诺的演示与可靠的组件之间存在很大差距——这是软件公司的惯常领域。将宝贵的研发资源投资于当前 Y Combinator 批量中大量攻克的普遍问题是浪费。
如果这听起来像陈词滥调的商业建议，那是因为在当前的炒作浪潮中，很容易将任何“LLM”误认为是尖端的增值差异化，而忽略哪些应用已经是老套。
AI 在循环中；以人为中心
目前，LLM 驱动的应用程序是脆弱的。它们需要大量的保护和防御性工程，并且仍然难以预测。此外，当范围明确时，这些应用程序可以非常有用。这意味着 LLM 是加速用户工作流的极佳工具。
虽然想象基于 LLM 的应用完全取代一个工作流或承担一个工作职能可能很诱人，但今天最有效的模式是人机混合（参考高级象棋）。当有能力的人与调优为其快速使用的 LLM 功能配对时，完成任务的生产力和幸福感可以大大提高。LLM 的一个旗舰应用，GitHub Copilot，展示了这些工作流的力量：
“总的来说，开发人员告诉我们，GitHub Copilot 和 GitHub Copilot Chat 使编程变得更容易，更无错误，更具可读性，更具可重用性，更简洁，更具可维护性和更具弹性，他们感觉更有信心。” — Mario Rodriguez，GitHub
对于长期从事 ML 工作的人来说，你可能会跳到“人类在循环中”的概念，但不要那么快：HITL 机器学习是一个建立在人类专家确保 ML 模型表现如预期的模式上。虽然相关，但这里我们提出了一些更微妙的东西。LLM 驱动的系统今天不应该是大多数工作流的主要驱动力；它们应该只是一个资源。
通过以人为中心，询问 LLM 如何支持他们的工作流，这将导致显著不同的产品和设计决策。最终，它会驱使你构建不同于竞争对手的产品，他们试图快速外包所有责任给 LLM——更好，更有用，风险更小的产品。
从提示、评估和数据收集开始
前几节提供了大量的技术和建议。这是一大堆信息。让我们考虑一下最小的有用建议集：如果一个团队想要构建一个 LLM 产品，他们应该从哪里开始？
在过去的一年里，我们看到了足够多的例子，开始相信成功的 LLM 应用程序遵循一致的轨迹。在本节中，我们将走过这个基本的“入门”操作手册。核心思想是从简单开始，仅在需要时增加复杂性。一个不错的经验法则是，每一个复杂程度的水平通常需要比前一个高一个数量级的努力。考虑到这一点……
提示工程是首要任务
从提示工程开始。使用我们在战术部分讨论的所有技术。连贯思维、n-shot 示例、结构化输入和输出几乎总是一个好主意。在尝试从较弱的模型中挤出性能之前，先用最有能力的模型进行原型设计。
只有在提示工程无法达到所需的性能水平时才应考虑微调。如果存在非功能性要求（例如，数据隐私、完全控制和成本）阻止使用专有模型，并因此需要自托管，这将更常发生。只需确保这些相同的隐私要求不会阻止你使用用户数据进行微调！
构建评估并启动数据飞轮
即使是刚开始的团队也需要评估。否则，你不会知道你的提示工程是否足够，或者你的微调模型何时准备好替换基础模型。
有效的评估是针对你的任务具体的，并反映预期的用例。我们推荐的第一级评估是单元测试。这些简单的断言检测已知或假设的故障模式，并帮助驱动早期设计决策。另见其他任务特定的评估用于分类、摘要等。
虽然单元测试和基于模型的评估是有用的，但它们不能替代人类评估。让人们使用你的模型/产品并提供反馈。这既可以测量实际性能和缺陷率，又可以收集高质量的注释数据，用于微调未来的模型。这会产生一个正反馈循环，或数据飞轮，随着时间的推移而复合：
- 使用人类评估来评估模型性能和/或发现缺陷
- 使用注释数据来微调模型或更新提示
- 重复
例如，在审计 LLM 生成的摘要时，我们可能会标记每个句子，提供精细的反馈，指出事实不一致、无关紧要或风格差。然后，我们可以使用这些事实不一致注释来训练一个幻觉分类器，或者使用相关性注释来训练一个奖励模型以得分相关性。另一个例子是，LinkedIn 分享了他们使用基于模型的评估器来估计幻觉、负责 AI 违规、连贯性等的成功。
通过创建随着时间推移而增加价值的资产，我们将构建评估从纯粹的运营成本升级为战略投资，并在此过程中构建我们的数据飞轮。
低成本认知的高级趋势
1971年，Xerox PARC 的研究人员预测了未来：我们现在生活的联网个人计算机的世界。他们通过在发明使之成为可能的技术方面发挥关键作用，从以太网和图形渲染到鼠标和窗口，帮助催生了这个未来。
但他们也进行了一个简单的练习：他们观察了非常有用（例如，视频显示器）但尚未经济实惠（即，足够的 RAM 驱动视频显示器需要数千美元）的应用。然后，他们观察了该技术的历史价格趋势（如摩尔定律）并预测这些技术何时会变得经济实惠。
我们可以对 LLM 技术做同样的事情，尽管我们没有像每美元晶体管那样清晰的东西。拿一个流行的、长期存在的基准，如大规模多任务语言理解数据集，并采用一致的输入方法（五次提示）。然后，比较不同性能水平的语言模型在这个基准上的运行成本随时间的变化。
图 1: 在固定成本下，能力在迅速增加。在固定能力水平下，成本在迅速下降。由合著者 Charles Frye 使用公共数据于 2024 年 5 月 13 日创建。
在 OpenAI 的 davinci 模型作为 API 发布后的四年里，在这个任务上运行一个具有相同性能的模型的成本在百万 Token（大约一百份本文件）的规模上从 20 美元下降到不到 10 美分——减半时间仅为六个月。同样，截至 2024 年 5 月，通过 API 提供商或自己运行 Meta 的 LLama 3 8B 的成本仅为每百万 Token 20 美分，其性能类似于 OpenAI 的 text-davinci-003，该模型使 ChatGPT 震惊世界。该模型在 2023 年 11 月底发布时每百万 Token 的成本也约为 20 美元。这是仅 18 个月内的两个数量级——摩尔定律预测的时间范围内的两倍。
现在，让我们考虑一个非常有用的 LLM 应用（例如，为生成视频游戏角色提供支持，如 Park et al.），但尚未经济实惠。（他们的成本估计为每小时 625 美元）。自该论文于 2023 年 8 月发布以来，成本大约下降了一个数量级，至每小时 62.50 美元。我们可能会期望它在另外九个月内降至每小时 6.25 美元。
同时，当《吃豆人》在 1980 年发布时，今天的一美元可以买到一个信用点，可以玩几分钟或几十分钟——称之为每小时六场游戏，或每小时 6 美元。这种粗略的数学计算表明，LLM 增强的游戏体验将在 2025 年某个时候变得经济实惠。
这些趋势是新的，只有几年历史。但在未来几年中，几乎没有理由期望这一过程放缓。即使我们可能用尽算法和数据集中的低垂果实，如超过“Chinchilla 比率”的 ~20 Token 每参数，数据中心内部和硅层的更深层次创新和投资承诺弥补不足。
这也许是最重要的战略事实：今天完全不可行的地板演示或研究论文将在几年后成为高级功能，然后很快成为商品。我们应该考虑到这一点来构建我们的系统和组织。
从 0 到 1 的演示足够了，是时候进行从 1 到 N 的产品了
我们理解，构建 LLM 演示非常有趣。只需几行代码、一个向量数据库和一个精心设计的提示，我们就可以创造 ✨魔法✨。在过去的一年里，这种魔法被比作互联网、智能手机，甚至印刷机。
不幸的是，任何从事实际软件发布的人都知道，在受控环境中工作的演示与在大规模运行的产品之间有很大的区别。
以自动驾驶汽车为例。第一辆车在 1988 年由神经网络驱动。二十五年后，Andrej Karpathy 进行了他的第一次 Waymo 演示骑行。十年后，该公司获得了其无司机许可证。这是三十五年的严格工程、测试、改进和监管导航，从原型到商业产品。
在不同行业和学术界的不同部分，我们已经密切观察了过去一年的起伏：LLM 应用的第 1 年。我们希望我们所学的经验——从严格的操作技术到战略视角，如哪些能力应该内部构建——能帮助你在第 2 年及以后，因为我们都在共同构建这个令人兴奋的新技术。
关于作者
Eugene Yan 设计、构建和运营为大规模客户服务的机器学习系统。他目前是 Amazon 的高级应用科学家，构建服务全球数百万用户的推荐系统 (RecSys) 并应用 LLMs 来更好地服务客户。此前，他领导 Lazada（被阿里巴巴收购）和一家健康科技 A 轮公司的机器学习工作。他在 eugeneyan.com 和 ApplyingML.com 上写作和演讲关于 ML、RecSys、LLMs 和工程的内容。
Bryan Bischof 是 Hex 的 AI 负责人，领导工程团队构建 Magic——数据科学和分析副驾。Bryan 在数据堆栈的各个方面工作，领导分析、机器学习工程、数据平台工程和 AI 工程团队。他启动了 Blue Bottle Coffee 的数据团队，领导了 Stitch Fix 的多个项目，并构建了 Weights and Biases 的数据团队。Bryan 曾共同撰写 O’Reilly 的《构建生产推荐系统》一书，并在罗格斯大学研究生院教授数据科学和分析。他的博士学位是纯数学。
Charles Frye 教授人们构建 AI 应用。在发布了心理药理学和神经生物学方面的研究后，他在加州大学伯克利分校获得了神经网络优化的博士学位。他通过 Weights and Biases、Full Stack Deep Learning 和 Modal 的教育和咨询工作，教过成千上万的 AI 应用开发全栈，从线性代数基础到 GPU 奥秘以及构建防御性业务。
Hamel Husain 是一名拥有超过 25 年经验的机器学习工程师。他曾与 Airbnb 和 GitHub 等创新公司合作，包括 OpenAI 用于代码理解的早期 LLM 研究。他还领导和参与了许多流行的开源机器学习工具。Hamel 目前是一名独立顾问，帮助公司运营化大语言模型 (LLMs) 以加速其 AI 产品之旅。
Jason Liu 是一位知名的机器学习顾问，以领导团队成功交付 AI 产品而闻名。Jason 的技术专长包括个性化算法、搜索优化、合成数据生成和 MLOps 系统。
他的经验包括在 Stitch Fix 创建处理每天 3.5 亿次请求的推荐框架和可观察性工具。其他角色包括 Meta、NYU 和初创公司如 Limitless AI 和 Trunk Tools。
Shreya Shankar 是加州大学伯克利分校计算机科学专业的机器学习工程师和博士生。她是两家初创公司的第一位机器学习工程师，从头构建服务数千用户的 AI 产品。作为研究人员，她的工作重点是通过以人为中心的方法解决生产 ML 系统中的数据挑战。她的工作出现在 VLDB、SIGMOD、CIDR 和 CSCW 等顶级数据管理和人机交互场所。
联系我们
我们很想听到你对这篇文章的想法。你可以通过 [email protected] 与我们联系。我们中的许多人都开放各种形式的咨询和建议。如果适当，我们会在联系时将你路由到正确的专家。
致谢
本系列文章始于一个群聊中的对话，Bryan 笑说他受到了写《一年 AI 工程》的启发。然后，✨魔法✨ 在群聊中发生了（见下图），我们都受到了启发，分享我们迄今为止的学习。
作者们感谢 Eugene 领导了文档整合和整体结构的大部分工作，以及大量的课程。此外，还感谢主要编辑责任和文档方向。作者们感谢 Bryan 引发了这篇文章的火花，将写作重新结构化为战术、操作和战略部分及其介绍，并推动我们思考如何更大地帮助社区。作者们感谢 Charles 对成本和 LLMOps 的深入探讨，并将课程编织得更连贯、更紧凑——这篇文章减少到 30 页而不是 40 页，你得感谢他！作者们感谢 Hamel 和 Jason 分享客户咨询的见解，以及从客户中获得的广泛普遍学习和工具的深刻知识。最后，感谢 Shreya 提醒我们评估和严格生产实践的重要性，并将她的研究和原创成果带入本文。
最后，作者们感谢所有团队在你们自己的写作中如此慷慨地分享你们的挑战和课程，我们在整个系列中引用了这些内容，以及 AI 社区的热情参与和参与。
