过去一年有关大模型应用构建的干货经验之战略篇

一、战术篇

过去一年有关大模型应用构建的干货经验之战术篇

二、运营篇

过去一年有关大模型应用构建的干货经验之运营篇

三、战略篇

成功的产品需要的是深思熟虑的规划和严格的优先级排序，而不是无休止的原型设计，也不是盲目追随最新发布的模型或趋势。在最后一节中，我们深入探讨打造优秀人工智能产品的战略考量，包括团队将面临的关键权衡——比如何时自建、何时购买——并为早期 LLM 应用开发战略提出了具体的“玩法”建议。目标从何而来？这就是战略的范畴。战略回答了战术和行动“如何”背后的“是什么”和“为什么”。我们提出了一些自己的观点，例如“在 PMF 之前不使用 GPU”和“关注系统而不是模型”，以帮助团队找出稀缺资源的最佳分配方向。此外，我们还给出了一个迭代路线图，助力团队开发出优秀的产品。这最后一组经验，正好回答了下面几个问题：

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

PMF 之前不必使用 GPU

要想成为伟大的产品，你的产品就不能仅仅是对别人 API 的简单包装。但反过来，自己硬干代价可能更高。过去一年，我们看到大量风险投资——比如那笔令人瞠目的 60 亿美元 A 轮融资——砸向那些既没产品愿景也没目标市场的模型训练和定制上。这一节，我们来解释为什么立即训练自己的模型是个错误，同时也会考虑自托管的作用。

从头开始训练模型（几乎）毫无意义

对于大多数组织而言，从头开始预训练 LLM 不切实际，而且会分散对产品开发的注意力。尽管这件事听起来很兴奋，而且似乎别人都在这么做，但开发和维护机器学习基础设施需要大量资源——收集数据、训练和评估模型、部署模型。如果你还在验证产品与市场的契合度，这些工作就会挤占开发核心产品的资源。退一步讲，即便你拥有计算、数据和技术能力，预训练的 LLM 也可能几个月后就过时了。

以 BloombergGPT 为例，这是一个专门为金融任务训练的 LLM。该模型在 363B 个 token 上预训练，需要九名全职员工（其中四名来自 AI 工程部，五名来自 ML 产品与研究部）的不懈努力。即便如此，一年之内，它在那些金融任务上就被 gpt-3.5-turbo 和 gpt-4 超越了。

这个故事和其他类似案例表明，对于绝大多数实际应用，从头开始预训练 LLM（哪怕用特定领域的数据）都不是资源的最佳利用方式。更好的选择是：根据自身需求，对现有的最强开源模型进行微调。当然也有例外。Replit 的代码模型就是一个典型——它专门为代码生成和理解而训练，通过预训练超越了 CodeLlama7b 等更大模型。但随着更强大的模型不断发布，要保持其实用性，需要持续投入。

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

对大多数组织而言，微调更多是出于“好感”，而非清晰的战略思考。团队过早投资微调，往往是想击败“只是另一种 wrapper”的说法。实际上，微调是一种重型机械，只有在收集了大量实例、证明其他方法无法满足需求时，才值得部署。一年前，很多团队告诉我们他们很想微调，但很少有人找到了产品与市场的契合点，大多数人后来都后悔了。如果真要微调，你最好有足够的信心——随着基础模型不断改进，你可以反复进行微调（详见下面的“模型不是产品”和“构建 LLMOps”）。那么，什么时候微调才合适？当用例所需的数据无法从现有模型训练所用的开放式网络数据集中获得，而且你已经构建了一个 MVP，证明了现有模型确实不够时。但要注意：如果模型构建者自己都很难拿到好的训练数据，你又从哪获得这些数据呢？最后请记住，LLM 驱动的应用不是科学展示项目；对你的投资应该与其对企业战略目标和差异化竞争的贡献相称。

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

有了 LLM API，初创公司比以往任何时候都更容易采用和集成 LLM，而无需从头训练自己的模型。Anthropic 和 OpenAI 等供应商提供通用 API，几行代码就能把智能融入产品。通过使用这些服务，你可以把精力集中在为客户创造价值上——从而更快验证想法、实现产品与市场的契合。不过，与数据库一样，托管服务并不适合所有情况，尤其是随着规模和需求增长。事实上，自托管可能是使用模型而不将机密/私人数据发送出网络的唯一方法，这在医疗、金融等受监管行业，或者涉及合同义务、保密要求时是必需的。此外，自托管可以规避推理提供商施加的限制，比如费率限制、模型报废和使用限制。自托管还能让你完全控制模型，更容易围绕模型构建差异化、高质量的系统。最后，自托管——特别是微调——可以大规模降低成本。BuzzFeed 就分享了他们如何微调开源 LLM，成功降低了 80% 的成本。

不断迭代，使之伟大

要想长期保持竞争优势，就得跳出模型的框框，考虑如何让自己的产品与众不同。执行速度固然重要，但不应该是唯一的优势。

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

对于没有自己构建模型的团队来说，快速的创新步伐其实是福音——他们可以从一个 SOTA 模型迁移到下一个，追逐情景规模、推理能力和性价比的提升，从而建立越来越好的产品。这种进步既令人兴奋，又是可以预见的。但这也意味着，模型很可能是系统中最不耐用的组件。相反，你的精力应该放在那些能提供持久价值的方面，比如：

• 评估底盘
  ：可靠地衡量不同模型在任务中的表现

• 围栏
  ：无论采用何种模型，都要防止出现不期望的输出

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

• 数据飞轮
  ：为上述所有功能的迭代改进提供动力

与原始模型能力相比，这些组成部分为产品质量提供了更厚实的护城河。但这并不意味着在应用层构建就没有风险。如果 OpenAI 或其他模型提供商想要提供可行的企业软件，就不要把你的剪刀对准他们需要剪掉的牦牛。例如，有些团队投资构建定制工具，以验证专有模型的结构化输出——最小程度的投资固然重要，但过深的投资并不是好时间用法。OpenAI 需要确保当你要求调用函数时，你得到的是有效的函数调用——因为所有客户都期望如此。这里可以采用一些“策略性拖延”：先构建你绝对需要的功能，等待供应商对功能的明显扩展。

从小事做起，建立信任

试图面面俱到的产品注定平庸。要想创造引人注目的产品，公司需要专门打造令人难忘的粘性体验，让用户流连忘返。想想通用的 RAG 系统，目标是对用户可能提出的任何问题都有答案。缺乏专业化意味着系统无法优先处理近期信息，无法解析特定领域的格式，也无法理解特定任务的细微差别。结果，用户只能得到肤浅、不可靠的体验。解决之道是：把重点放在特定领域和使用案例上。深入而非广泛，缩小范围，就能创建与用户产生共鸣的专用工具。专业化还能让你直面系统的能力和局限性。对系统能做什么、不能做什么保持透明，展示自我意识，帮助用户了解系统在哪些方面能带来最大价值，从而建立对输出结果的信任和信心。

以正确的理由构建 LLMOps：更快的迭代速度

从根本上说，DevOps 与可复制的工作流程、左移或授权两个披萨规模的团队无关，更与编写 YAML 文件无关。DevOps 的核心是缩短工作与成果之间的反馈周期，从而不断改进，而不是不断出错。其根源可以追溯到精益创业、精益生产和丰田生产方式，后者强调“一分钟换模和改善”。MLOps 把 DevOps 的形式套用到 ML 上：我们有可重现的实验，有一体式套件让模型构建者交付，还有 YAML 文件。但作为一个行业，MLOps 并没有适应 DevOps 的功能——它没有缩短模型与生产中推论和交互之间的反馈差距。令人欣慰的是，LLMOps 领域已经从关注提示管理之类的小麻烦，转向解决阻碍迭代的难题：生产监控和持续改进，并通过评估进行关联。现在，我们已经有了对聊天和编码模式进行中立、众包评估的互动平台——一个集体迭代改进的外循环。LangSmith、Log10、LangFuse、W&B Wea ve、HoneyHive 等工具不仅收集和整理生产过程中的系统结果数据，还通过与开发的深度整合，利用这些数据来改进系统。

不要开发可以购买的 LLM 功能

大多数成功的企业都不是终身学习企业。与此同时，大多数企业都有机会通过本地化管理加以改进。这两点往往会误导领导者，急匆匆地在系统中加装 LLM，增加成本、降低质量，然后作为虚有其表的“人工智能”功能发布，附上闪光的图标。更好的方法是：专注于真正符合产品目标、能增强核心运营的 LLM 应用。想想那些浪费团队时间的误导性投资：为你的业务构建自定义文本到 SQL 功能；构建与文档对话的聊天机器人；把公司的知识库与客户支持聊天机器人整合在一起。虽然这些都是常见的入门级 LLM 应用，但几乎所有产品公司都不应该自己构建它们——因为它们是很多企业面临的普遍问题，在有前景的演示和可靠的组件之间存在巨大差距，而这恰恰是软件公司的惯常做法。把宝贵的研发资源投入到当前 Y Combinator 批量解决的一般问题上，是一种浪费。如果这听起来像老生常谈的商业建议，那只是因为，在当前的炒作浪潮中，人们很容易把任何“LLM”误认为是前沿的增量差异化，而忽略了哪些应用其实已经过时。

AI 在回路中，人类在中心

目前，由 LLM 驱动的应用程序非常脆弱，需要大量的安全保护和防御工程，而且仍然难以预测。但当范围严格限定时，这些应用可能非常有用。这意味着 LLM 是加速用户工作流程的绝佳工具。虽然想象基于 LLM 的应用完全取代工作流程或替代工作职能很有诱惑力，但如今最有效的范例是人机半人马（就像半人马国际象棋）。当有能力的人类与为快速利用而调整的 LLM 功能配对时，工作效率和完成任务的愉悦感都会大幅提升。GitHub Copilot 就是旗舰案例之一：开发人员反馈说，使用 Copilot 后编码更简单、更少差错、更可读、更可重用、更简洁、更可维护、更有弹性。对于那些在 AI 领域工作久了的人，可能会想到“人在回路中”的概念，但没那么快——HITL 是一种建立在人类专家确保模型行为符合预测基础上的范式。我们这里提出的东西更微妙：LLM 驱动的系统不应成为当今大多数工作流程的主要驱动力，它们应该只是一种资源。以人类为中心，询问 LLM 如何支持他们的工作流程，这会带来截然不同的产品和设计决策。最终，这会促使你打造出与那些试图把所有责任外包给 LLM 的竞争对手不同的产品——更好、更有用、风险更低。

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

前面几节提供了大量技巧和建议，信息量不小。让我们考虑一下最少但最实用的建议：如果一个团队想构建 LLM 产品，该从哪里开始？过去一年中，我们看到足够多的例子，开始确信成功的 LLM 应用都遵循着一致的轨迹。下面就是这本基本的“入门”手册：核心理念是从简单开始，只在需要时增加复杂性。一个合理的经验法则是，每提高一个复杂程度，通常需要比前一个复杂程度多付出至少一个数量级的努力。

首先考虑提示工程

从提示工程开始。使用之前在战术部分讨论过的所有技巧：思维链、n-shot 示例、结构化输入和输出，几乎总是好主意。在尝试从性能较弱的模型中榨出性能之前，先用性能最高的模型做原型。只有在提示工程无法达到所需性能时，才考虑微调。如果有一些非功能性要求（如数据隐私、完全控制和成本）阻碍了专有模型的使用，从而要求你自行托管，那么微调的可能性会更大。但也要确保隐私要求不会阻止你使用用户数据进行微调！

建立评估并启动数据飞轮

即使是刚刚起步的团队也需要评估。否则，你就不知道提示工程是否足够，也不知道微调模型何时可以取代基础模型。有效的评估应该针对你的任务并反映预期用例。我们推荐的第一级评估是单元测试——简单的断言可以检测已知或假设的故障模式，有助于推动早期设计决策。此外，还可以查看其他针对特定任务的评估，如分类、总结等。虽然单元测试和基于模型的评估很有用，但它们不能取代人工评估。让人们使用你的模型/产品并提供反馈，这样做有两个目的：一是测量真实世界的性能和缺陷率，二是收集可用于微调未来模型的高质量注释数据。这就形成了一个正反馈循环——数据飞轮——并随着时间的推移不断累积：
① 使用人工评估来评估模型性能和/或发现缺陷；
② 使用标注数据对模型进行微调或更新提示；
③ 重复。

例如，在审核 LLM 生成的摘要是否存在缺陷时，我们可能会给每个句子贴上细粒度的反馈标签，比如事实不一致、不相关或风格不佳。然后，可以用这些事实不一致注释训练一个幻觉分类器，或者用相关性注释训练一个奖励模型。LinkedIn 在其文章中分享了使用基于模型的评价器来估计幻觉、负责任的人工智能违规行为、一致性等方面的成功经验。通过创建资产，使其价值随时间不断复合，我们将评估从纯粹的运营支出升级为战略投资，同时建立自己的数据飞轮。

低成本认知的高级趋势

1971 年，施乐 PARC 的研究人员预言了我们现在生活的个人电脑网络世界。他们在以太网、图形渲染、鼠标和窗口等技术的发明中起到了关键作用，帮助创造了未来。但他们还做了一项简单的工作：他们研究了那些非常有用（如视频显示）但还不经济（足够的 RAM 驱动视频显示需要数千美元）的应用，然后研究了该技术的历史价格趋势（类似摩尔定律），预测这些技术何时会变得经济实惠。我们也可以对 LLM 技术采取同样的方法，尽管没有像每美元晶体管那样简洁的度量。我们可以采用一个流行、长期使用的基准，比如大规模多任务语言理解数据集，以及一种一致的输入方法（五次提示），然后比较不同性能水平的语言模型在该基准上的运行成本。

在成本固定的情况下，能力会迅速提高；在能力水平固定的情况下，成本会迅速降低。上图由作者之一 Charles Frye 于 2024 年 5 月 13 日使用公共数据创建。自 OpenAI 的 da vinci 模型作为 API 推出以来的四年里，在一百万 token（约 100 份本文档）规模上运行性能相当的模型，成本从 20 美元降至不到 10 美分——仅用六个月就减半了。同样，截至 2024 年 5 月，通过 API 提供商或自行运行 Meta 的 Llama 3 8B，成本仅为每百万 token 20 美分，其性能与 OpenAI 的 text-da vinci-003 相似——后者是曾让 ChatGPT 震惊世界的模型，在 2023 年 11 月底发布时价格约为每百万 token 20 美元。短短 18 个月内，成本提升了两个数量级——而摩尔定律预测在同一时间段内仅翻一番。现在，考虑 LLM 的一个非常有用的应用：为生成视频游戏角色提供动力（如 Park 等人所述），但这种应用还不经济（当时成本估计为每小时 625 美元）。自该论文 2023 年 8 月发表以来，成本已经下降了大约一个数量级，降至每小时 62.50 美元。我们可以预计，再过九个月，成本将降至每小时 6.25 美元。与此同时，1980 年《吃豆人》发行时，今天的 1 美元可以买到一个 credit，玩几分钟或几十分钟——算作每小时 6 个游戏，即每小时 6 美元。根据这个粗略计算，令人信服的 LLM 增强型游戏体验将在 2025 年的某个时候变得经济实惠。这些趋势都是新趋势，只有几年历史，但我们没有理由期待这一进程在未来几年放缓。即使我们可能已经用完了算法和数据集中的低挂果实（例如超过了每个参数约 20 个 token 的“Chinchilla ratio”），数据中心内部和硅层的深入创新和投资仍有望填补空缺。

受够了 0 到 1 的演示，是时候推出 1 到 N 的产品了

我们知道，制作 LLM 演示非常有趣——只需几行代码、一个向量数据库和一个精心制作的提示，就能创造出神奇✨✨。过去一年，这种魔力被比作互联网、智能手机甚至印刷机。不幸的是，任何参与过实际软件交付的人都知道，在受控环境下运行的演示与大规模可靠运行的产品之间存在天壤之别。以自动驾驶汽车为例：1988 年第一辆汽车由神经网络驱动；25 年后，Andrej Karpathy 第一次试驾了 Waymo；又过了十年，该公司才获得无人驾驶许可证。从原型到商业产品，经历了三十五年的严格工程设计、测试、改进和监管导航。在工业界和学术界的不同领域，我们敏锐地观察到了过去一年 LLM 应用的起伏。希望我们学到的经验——从建立团队的严格操作技术等战术，到内部建设哪些能力等战略视角——能在第二年及以后帮助你们，让我们共同发展这项令人兴奋的新技术。