“从头开始训练模型，几乎没有意义”

我们之前分享过我们在运营大型语言模型应用程序时磨练出的战术方面的见解。战术是细粒度的：它们是为实现特定目标而采取的具体行动。我们还分享了我们对运营的看法：为支持战术工作并实现目标而建立的更高层次的过程。

但这些目标从何而来？这就属于战略的范畴。战略解答了战术和运营中“如何”背后的“什么”和“为什么”。

我们将分享我们的见解，比如“在产品市场契合之前避免使用 GPU”和“专注于构建系统而非模型”，以指导团队如何高效地分配稀缺资源。我们还提出了一个通往卓越产品的迭代路线图。这些宝贵的经验教训汇集起来，回答了以下这些问题：

1. 自建还是购买：何时应该自行训练模型，何时应该使用现成的 API？答案总是“视情况而定”。我们分享了决定因素是什么。

2. 迭代至卓越：如何创造长期竞争优势，而不仅仅是依赖最新的模型？我们讨论了基于模型构建健全系统的重要性，并专注于提供令人难忘的、有粘性的体验。

3. 以人为中心的 AI：如何有效地将大模型融入人类工作流程中，以提升生产力和幸福感？我们强调了构建支持和增强人类能力的 AI 工具的重要性，而不是试图完全取代人类。

4. 入门指南：团队开始构建大模型产品的基本步骤是什么？我们概述了一个基本的流程，从提示词工程、评估和数据收集开始。

5. 低成本认知的未来：大模型的成本迅速降低和能力增加将如何塑造 AI 应用的未来？我们审视了历史趋势，并通过一个简单的方法来估计某些应用何时可能在经济上变得可行。

6. 从演示到产品：从一个引人注目的演示到一个可靠、可扩展的产品需要做些什么？我们强调了严格的工程、测试和持续改进的必要性，以缩小原型和生产之间的差距。

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

战略：在不失去先机的情况下利用大模型

成功的产品需要深思熟虑的规划和严格的优先级安排，而不是无休止的原型迭代或盲目追逐最新的模型或潮流。在本文中，我们将放眼四周，深入探讨构建卓越 AI 产品的战略考量。我们还将审视团队在开发过程中可能面临的主要权衡问题，比如决定是自主构建还是外部采购，并为早期大型语言模型应用的策略开发提供一个指导“蓝图”。

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

要实现卓越，你的产品不应该只是在供应商提供的 API 之上构建一层薄弱的包装层，但走向相反的极端可能带来更大的代价。过去一年，我们目睹了大量的风险投资涌入，包括令人瞠目结舌的 60 亿美元 A 轮融资，用于训练和定制模型，而没有清晰的产品愿景或目标市场。在这一部分，我们将解释为什么急于投入模型训练是一个错误，并探讨自托管模型的定位。

从头开始训练模型（几乎）总是没有意义

对于大多数组织来说，从头开始训练大模型是一种不切实际的分心，它分散了构建实际产品的精力和资源。

尽管这么做很令人兴奋，尽管似乎业界都在追随这一趋势，但开发和维护机器学习基础设施需要大量的资源投入，包括收集数据、训练和评估模型以及部署它们。如果你还处在验证产品市场契合度的阶段，这些可能会从核心产品开发中抽走宝贵的资源。即使你拥有计算能力、数据和技术能力，预训练的大模型也可能在几个月内就变得过时。

以BloombergGPT为例，这是一个专门为金融任务训练的大模型。这个模型在 363B 个 token 上进行了预训练，耗费了九名全职员工的辛勤劳动，包括四名 AI 工程师和五名机器学习产品和研究人员。尽管付出了巨大的努力，BloombergGPT 在那些金融任务上的表现在一年内就被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 关注缩短工作流与结果反馈之间的周期，从而促进持续改进而非累积错误。它的理念源于精益创业运动，可以进一步追溯到精益制造和丰田生产系统，这些理念强调的是快速响应变化和持续改进。

MLOps 将 DevOps 的理念和实践应用到机器学习中。它带来了可重复的实验流程，提供了一站式的工具套件，使得模型构建者能够更便捷地将模型推向生产。当然，在这个过程中，YAML 文件扮演了不可或缺的角色。

但从行业来看，LMOps 尚未完全实现 DevOps 的核心功能。它没有有效地缩短模型开发与在生产环境中推理和交互之间的反馈周期。

令人振奋的是，LLMOps 领域已经从关注那些看似琐碎的问题，如提示词管理，转向解决阻碍迭代的难题：在生产环境中进行有效监控并实现持续改进。

我们已经拥有了中立、众包的评估平台，这些平台专门用于聊天和编程模型的互动——它们构成了一个集体迭代改进的外循环。像 LangSmith、Log10、LangFuse、W&B Weave、HoneyHive 等工具不仅可用于收集和整理生产系统中的结果数据，还通过与开发流程紧密结合，利用这些数据来不断改进系统。你可以尝试拥抱它们，或者构建属于自己的工具。

如果可以买，就不要自己构建

大多数成功的业务并不是基于大语言模型的业务，但大多数业务都存在通过大模型进行改进的可能性。

这有时会误导领导者急于将大模型技术应用于系统改造，导致成本上升和产品质量下降，甚至可能将这些技术作为虚假的“AI”特性匆忙推向市场，还带上那些令人眼花缭乱的星星图标。更好的做法是：专注于那些真正与你的产品设计目标相契合并能增强你核心运营的大模型应用。

让我们重新审视一下那些可能消耗团队宝贵时间的错误尝试：

• 尝试为企业开发定制的文本到 SQL 转换功能；

• 构建能够与文档进行互动的聊天机器人；

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

虽然上述的大模型应用属于入门级别，但对于大多数产品公司来说，并不适合自己从头开始构建。这些是许多企业面临的普遍问题，演示和实际存在巨大差距——而这正是软件公司的专长所在。当前的 Y Combinator 孵化器已经在集中解决这些问题，因此在这些问题上投入宝贵的研发资源是一种浪费。

如果说这听起来像是陈词滥调的商业建议，那是因为在当前热潮和泡沫般的兴奋中，人们很容易将带有“大模型”标签的事物误认为是尖端的增值差异化手段，而忽略了哪些应用实际上已经是司空见惯的。

AI 辅助，以人为本

目前，由大模型驱动的应用程序是很脆弱的，它们需要精心设计的保护措施和防御策略，即便如此，依然存在很多不确定性。然而，当这些应用程序的应用范围有了明确限定，可能会变得极为有用。这说明大模型是加速和优化用户工作流的有力工具。

尽管人们可能会被基于大模型的应用程序完全替代工作流或工作职能的想法所吸引，但目前最有效的模式是人机协作——计算机半人马模式（类似国际象棋半人马模式）。当有才能的人类与大模型能力相结合，完成任务的效率和满足感可以得到显著提升。GitHub Copilot，作为大模型的主要应用之一，已经展示了这种协作工作流程的强大潜力：

“总的来说，开发者告诉我们，他们感到更有信心，因为编码变得更容易、错误更少、代码易读性更强、可重用性更高、更简洁、更易于维护，并且系统弹性比没有 GitHub Copilot 和 GitHub Copilot Chat 时更强。”

——Mario Rodriguez，GitHub

对于那些长期从事机器学习工作的人来说，可能会立刻联想到“HITL”，但不要急于下结论：HITL 机器学习是一种人类专家确保机器学习模型能够按照预期的方式运行的范式。尽管两者相关，但我们今天要讨论的是一个更为微妙的概念。大模型驱动的系统不应成为大多数工作流的主要驱动力，而应当被视为一种辅助资源。

将人类置于核心位置，并探索如何让大模型来辅助他们的工作流，这种方法将引导我们做出截然不同的产品和设计决策。最终，这将促使我们打造出与那些急于将所有职责转嫁给大模型的竞争对手不同的产品——更好、更有用、风险更低的产品。

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

前面的章节阐述了一些技术和建议，内容相当丰富，可能需要一些时间来消化。让我们来概括一下最核心的建议：如果一个团队想要构建基于大模型的产品，应该从哪里开始？

在过去的一年里，我们已经看到了足够多的例子，这让我们对大模型应用取得成功的轨迹有了清晰的认识。在本节中，我们将通过一个基础的“入门”指南来梳理这些经验。核心理念是保持简单，只在必要时才引入复杂性。根据经验，每增加一个复杂度级别，通常至少需要比前一个级别多一个数量级的努力。

提示词工程先行

我们从提示词工程开始。在试图从较弱的模型榨取性能之前，先使用我们在战术部分讨论的技术。思维链、n-shot 以及结构化输入和输出通常都是明智的选择。在转向较弱的模型之前，先用大的模型进行原型设计。

只有在提示词工程无法达到所需的性能时才考虑微调。如果有非功能性方面的需求（例如，数据隐私、完全控制权和成本考量），并且这些要求阻碍了使用专有模型，不得不使用自托管方案，那就需要进行微调。只是你要确保数据隐私需求不会阻碍你使用用户数据进行微调！

评估并启用数据飞轮

即使团队是在初始阶段，也需要进行评估。否则，你将无法确定你的提示词工程是否有效，或者微调模型何时能准备就绪替换基础模型。

有效的评估应针对具体的任务，并反映预期的使用场景。我们建议的评估起点是单元测试。这些基础的断言用于检测已知或假设的故障模式，有助于推动早期的设计决策。此外，还可以看看其他特定于任务的评估方法，例如用于分类、摘要等任务的评估。

尽管单元测试和基于模型的评估很有用，但它们不能完全替代人类的评估。让人们使用你的模型或产品，并收集反馈，这至关重要。这不仅可以衡量产品在现实世界中的表现和缺陷，也能收集可用于微调模型的高质量标注数据。这样可以形成一个正向反馈循环（也叫数据飞轮），随着时间的推移，可以产生复合效应：

• 使用人类评估来评估模型性能和/或发现缺陷；

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

• 持续这一过程。

例如，在评审大语言模型生成的摘要时，我们可能会对每个句子进行细致的反馈，识别出事实错误、不相关性或风格问题。然后，我们可以使用事实错误标注来训练幻觉分类器，或使用相关性标注训练奖励模型来评估相关性。 另一个例子是，LinkedIn 在其播客中分享了使用基于模型的评估器来评估幻觉、AI 违规行为、连贯性等问题的成功经验。

通过构建随时间增值的资产，我们将评估工作从单纯的运营成本转变为战略投入，并在这个过程中加速数据飞轮效应。

低成本趋势

1971 年，施乐帕克研究中心的研究人员预测未来是一个由网络个人电脑主导的世界。他们发明了一系列关键技术，如以太网、图形渲染、鼠标以及窗口界面，为他们预测的未来成为现实奠定了基础。

他们还进行了一项基础实践：观察那些非常有实用价值但成本较高的应用（例如，视频显示器），然后分析这些技术的历史价格趋势（如摩尔定律），并预测了这些技术何时会变得经济实惠。

我们同样可以在大型语言模型技术方面进行同样的分析，尽管我们没有像像晶体管成本那样直观的衡量标准。以一个被广泛认可且持续更新的基准测试为例，比如 Massively-Multitask Language Understanding 数据集，以及一种一致性的输入方法（five-shot 提示词）。然后，我们可以比较在不同时间用各种性能水平的语言模型在该基准测试上运行的成本。

在成本固定之下，能力正迅猛提升。在能力水平固定之下，成本正急剧下降。

自 OpenAI 的 davinci 模型作为 API 发布以来的四年里，在该任务上运行具有等效性能的模型的成本已经从 20 美元降到了不到 10 美分——成本减半的时间仅为六个月。同样，截至 2024 年 5 月，通过 API 供应商或自行运行 Meta 的 LLama 3 8B 模型的成本仅为每百万个 token 20 美分，这个模型的性能与 OpenAI 的 text-davinci-003 相当，后者曾以其卓越的表现震惊了世界。值得注意的是，当 LLama 3 8B 在 2023 年 11 月末发布时，其成本大约为每百万个 token 20 美元。成本在短短 18 个月内降低了两个数量级，与摩尔定律预测的时间不谋而合。

现在，我们来探讨一个极具潜力但目前还不具备经济效益的大模型应用（生成视频游戏角色，成本估计为每小时625美元）。自 2023 年 8 月该论文发布以来，成本已经下降了一个数量级，降至每小时 62.5 美元。基于这一趋势，我们可以预期在下一个九个月内，成本会降至每小时 6.25 美元。

当吃豆人（Pac-Man）游戏在 1980 年首发时，现在的 1 美元可以兑换一个信用点，允许玩家享受几分钟到几十分钟的游戏乐趣——如果以每小时六场游戏来估算，相当于每小时 6 美元。按照这种粗略计算，一个引人入胜的大模型增强型游戏体验将在 2025 年的某个时候变得经济可行。

这些趋势虽然还很新，仅有几年的历史，但我们没有理由认为它们在未来几年会有所减缓。尽管在算法和数据集方面，我们可能已经摘取了容易获得的成果，比如超越了“Chinchilla 比率”的每参数约 20 个 token，但数据中心内部更深层次的创新和投入以及硅芯片层面的进展有望弥补这一潜在的不足。

这可能是最关键的战略洞见：那些今天看似完全不可能的演示或研究论文，在未来几年内将逐渐演变为高级的功能，并成为普通商品。我们应当基于这一视角来构建我们的系统和组织架构。

从 0 到 1 已经够多了，是时候从 1 到 N 了

构建大模型演示应用非常有趣，只需要几行代码、一个向量数据库和一条精心设计的提示词，我们就能创造出令人惊叹的“魔法”。在过去的一年里，这种“魔法”被比作是互联网、智能手机，甚至印刷机般的创新。

不幸的是，在现实的软件项目中摸爬滚打的人都知道，演示中的完美表现与大规模稳定运行的产品之间存在着巨大的差异。

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

在过去的一年，不管是工业界还是学术界，我们都看到了大模型应用的起伏：这是大模型应用的“1 到 N”年。我们希望我们所学到的经验——从严格的战术性操作技术，再到内部需要构建哪些能力的战略性视角——能帮助你在接下来的一年乃至更长远的未来，更好地参与这项激动人心的新技术的共同建设。

【声明：本文由 InfoQ 翻译，未经许可禁止转载。】

原文链接：

https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-iii-strategy/