过去一年，大模型应用以前所未有之势从出现到繁荣。LLM应用从原型展示向生产落地演进。近日，Oreilly刊发了由 Eugene Yan, Bryan Bischof等人撰写的大模型总结性文章《What We Learned from a Year of Building with LLMs？》，由于作者们背景各不相同，有独立咨询顾问（Hamel Husain，Jason Liu），有研究人员（Shreya Shankar），还有科技公司AI团队领袖（Eugene Yan，Bryan Bischof），以及AI领域布道师（Charles Frye），这使得文章内容更为全面深入。他们从战术、运营和战略三个部分展开解读了自己过去一年有关LLM应用开发与运营的全方位经验。
过去一年有关大模型应用构建的干货经验之战术篇
过去一年有关大模型应用构建的干货经验之运营篇
成功的产品需的是深思熟虑的规划和严格的优先级排序，而不是无休止的原型设计或追随最新发布的模型或趋势。在最后一节中，我们将深入探讨打造优秀人工智能产品的战略考量。我们还将探讨团队将面临的关键权衡，例如何时构建、何时购买，并为早期 LLM 应用开发战略提出 "玩法 "建议。目标从何而来？这就是战略的范畴。战略回答了战术和行动 "如何 "背后的 "是什么 "和 "为什么 "的问题。我们提出了自己的观点，例如 "在 PMF 之前不使用 GPU "和 "关注系统而不是模型"，以帮助团队找出稀缺资源的分配方向。此外，我们还提出了一个迭代路线图，帮助团队开发出优秀的产品。这最后一组经验教训回答了以下问题：1.自建与购买：什么时候应该训练自己的模型，什么时候应该利用现有的API？答案始终是 "视情况而定"。我们将与您分享这取决于什么。2.迭代出精品：除了使用最新模型外，如何才能创造持久的竞争优势？我们讨论了围绕模型建立强大系统的重要性，并重点关注提供令人难忘的粘性体验。3.以人为本的人工智能：如何有效地将 LLM 集成到人类工作流程中，从而最大限度地提高生产力和幸福感？我们强调构建支持和增强人类能力的人工智能工具的重要性，而不是试图完全取代人类能力。4.入门：对于着手开发 LLM 产品的团队来说，有哪些基本步骤？我们概述了从及时工程设计、评估和数据收集开始的基本流程。
5.低成本认知的未来：快速降低的成本和不断增强的能力将如何塑造人工智能应用的未来？我们研究了历史趋势，并通过一种简单的方法来估计某些应用何时在经济上可行。6.从演示到产品：从引人注目的演示到可靠、可扩展的产品需要哪些条件？我们强调需要进行严格的工程设计、测试和改进，以弥合原型与生产之间的差距。要想成为伟大的产品，你的产品就不能仅仅是对别人的API的简单包装。但反其道而行之，代价可能会更高。在过去的一年里，有大量的风险投资，包括令人瞠目的 60 亿美元 A 轮融资，都花在了没有明确产品愿景或目标市场的培训和定制模型上。在本节中，我们将解释为什么立即培训自己的模型是一个错误，并考虑自托管的作用。
对于大多数组织而言，从头开始预训练LLM是不切实际的，会分散对产品开发的注意力。
虽然这很令人兴奋，而且似乎其他人都在这么做，但开发和维护机器学习基础架构需要大量资源。这包括收集数据、训练和评估模型以及部署模型。如果你还在验证产品与市场的契合度，这些工作就会占用开发核心产品的资源。即使您拥有计算、数据和技术能力，预训练的 LLM 也可能在几个月后就会过时。
以 BloombergGPT 为例，这是一个专门为金融任务而训练的 LLM。该模型在 363B 个token上进行了预训练，需要九名全职员工（其中四名来自AI工程部，五名来自 ML 产品与研究部）的不懈努力。尽管如此，该模型在一年内还是在这些金融任务上被 gpt-3.5-turbo 和 gpt-4 所超越。
这个故事和其他类似故事表明，对于大多数实际应用来说，从头开始预训练 LLM（即使是特定领域的数据）并不是资源的最佳利用方式。相反，团队最好根据自己的特定需求，对现有的最强开源模型进行微调。
当然也有例外。Replit 的代码模型就是一个典型的例子，它是专门为代码生成和理解而训练的。通过预训练，Replit 能够超越 CodeLlama7b 等其他大型模型。但是，随着其他功能越来越强大的模型的发布，要保持其实用性就需要持续的投资。
对大多数组织而言，微调更多是出于 "好感"，而非清晰的战略思考。组织过早地投资微调，试图击败 "只是另一种wrapper "的说法。实际上，微调是一种重型机械，只有在收集了大量实例，证明其他方法无法满足需要时，才会部署微调。一年前，许多团队告诉我们，他们很想进行微调。但很少有人找到了产品与市场的契合点，大多数人对自己的决定后悔不已。如果要进行微调，你最好有足够的信心，随着基础模型的不断改进，你可以反复进行微调--请参阅下面的 "模型不是产品 "和 "构建 LLMOps"。什么时候微调才是正确的选择？如果用例所需的数据无法从用于训练现有模型的大部分开放式网络规模数据集中获得，而且您已经构建了一个 MVP，证明了现有模型的不足。但要注意：如果模型构建者无法随时获得优秀的训练数据，你又从哪里获得这些数据呢？最后，请记住，LLM 驱动的应用不是一个科学展示项目；对它们的投资应该与其对企业战略目标和差异化竞争的贡献相称。有了LLM API，初创公司比以往任何时候都更容易采用和集成LLM，而无需从头开始训练自己的模型。Anthropic 和 OpenAI 等供应商提供通用 API，只需几行代码就能将智能融入您的产品。通过使用这些服务，您可以减少花费的精力，转而专注于为客户创造价值--这让您可以验证想法，并更快地实现产品与市场的契合。但是，与数据库一样，托管服务并不适合每种使用情况，尤其是随着规模和需求的增加。事实上，自托管可能是使用模型而不将机密/私人数据发送出网络的唯一方法，这在医疗保健和金融等受监管行业或合同义务或保密要求中是必需的。此外，自托管还可以规避推理提供商施加的限制，如费率限制、模型报废和使用限制。此外，自托管还能让您完全控制模型，从而更容易围绕模型构建差异化、高质量的系统。最后，自托管，尤其是微调，可以大规模降低成本。例如，BuzzFeed 分享了他们如何对开源 LLM 进行微调，以降低 80% 的成本。要想长期保持竞争优势，就必须跳出模式的束缚，考虑如何让自己的产品与众不同。执行速度固然重要，但不应该是唯一的优势。对于没有构建模型的团队来说，快速的创新步伐是他们的福音，因为他们可以从一个 SOTA 模型迁移到下一个模型，追逐情境规模、推理能力和性价比的提升，以建立越来越好的产品。
这种进步既令人兴奋，又是可以预见的。综上所述，这意味着模型很可能是系统中最不耐用的组件。
相反，应将精力集中在能够提供持久价值的方面，例如：
与原始模型能力相比，这些组成部分为产品质量提供了更厚实的护城河。
但这并不意味着在应用层构建就没有风险。如果 OpenAI 或其他模型提供商想要提供可行的企业软件，就不要把你的剪子对准他们需要剪掉的牦牛。
例如，一些团队投资构建定制工具，以验证专有模型的结构化输出；在此方面进行最小程度的投资固然重要，但过深的投资并不能很好地利用时间。OpenAI 需要确保当你要求调用函数时，你得到的是有效的函数调用--因为他们的所有客户都希望如此。在此采用一些 "策略性拖延"，构建你绝对需要的功能，等待供应商对功能的明显扩展。
从小事做起，建立信任
试图面面俱到的产品注定平庸。要想创造出引人注目的产品，公司需要专门打造令人难忘的粘性体验，让用户流连忘返。考虑一下通用的 RAG 系统，它的目标是回答用户可能提出的任何问题。缺乏专业化意味着该系统无法对近期信息进行优先排序，无法解析特定领域的格式，也无法理解特定任务的细微差别。因此，用户只能获得肤浅、不可靠的体验，无法满足他们的需求。为解决这一问题，应将重点放在特定领域和使用案例上。通过深入而非广泛的方式缩小范围。这将创建能与用户产生共鸣的特定领域工具。专业化还能让你直面系统的能力和局限性。对系统能做什么和不能做什么保持透明，可以展示自我意识，帮助用户了解系统在哪些方面能带来最大价值，从而建立对输出结果的信任和信心。从根本上说，DevOps 与可复制的工作流程、左移或授权两个披萨规模的团队无关，也绝对与编写 YAML 文件无关。
DevOps 是要缩短工作与成果之间的反馈周期，从而不断改进，而不是不断出错。其根源可以追溯到精益创业运动、精益生产和丰田生产方式，后者强调 "一分钟换模和改善(Single Minute Exchange of Die and Kaizen)"。
MLOps 将 DevOps 的形式应用于 ML。我们有可重现的实验，我们有一体式套件，让模型构建者能够进行交付。我们还有 YAML 文件。
但作为一个行业，MLOps 并没有适应 DevOps 的功能。它没有缩短模型与生产中的推论和交互之间的反馈差距。
令人欣慰的是，LLMOps 领域已经从思考诸如及时管理之类的小麻烦，转向了解决阻碍迭代的难题：生产监控和持续改进，并通过评估进行关联。
现在，我们已经有了对聊天和编码模式进行中立、众包评估的互动平台--一个集体迭代改进的外循环。LangSmith、Log10、LangFuse、W&B Weave、HoneyHive 等工具不仅可以收集和整理生产过程中的系统结果数据，还可以通过与开发的深度整合，利用这些数据来改进这些系统。
大多数成功的企业都不是终身学习企业。与此同时，大多数企业都有机会通过本地化管理加以改进。
这两点往往会误导领导者匆忙地在系统中加装 LLM，从而增加成本、降低质量，并将其作为虚有其表的 "人工智能 "功能发布，同时附上令人生厌的闪光图标。有一种更好的方法：专注于真正符合产品目标并能增强核心运营的 LLM 应用。
考虑一些浪费团队时间的误导性投资：
虽然以上是常见入门级的 LLM 应用，但几乎所有产品公司都不应该自己构建这些应用程序。这些都是许多企业面临的普遍问题，在有前景的演示和可靠的组件之间存在巨大差距，而这正是软件公司的惯常做法。将宝贵的研发资源投入到当前 Y Combinator 批量解决的一般问题上是一种浪费。
如果这听起来像是老生常谈的商业建议，那是因为在当前的炒作浪潮中，人们很容易把任何 "LLM "都误认为是前沿的增量差异化，而忽略了哪些已经过时的应用。
目前，由 LLM 驱动的应用程序非常脆弱。它们需要大量的安全保护和防御工程，而且仍然难以预测。此外，当范围严格限定时，这些应用可能非常有用。这意味着 LLM 是加速用户工作流程的绝佳工具。
虽然想象基于 LLM 的应用完全取代工作流程或替代工作职能可能很有诱惑力，但如今最有效的范例是人机半人马（例如半人马国际象棋）。当有能力的人类与为快速利用而调整的 LLM 功能配对时，工作效率和完成任务的快乐程度都会大大提高。LLM 的旗舰应用之一 GitHub Copilot 就展示了这些工作流程的威力："总的来说，开发人员告诉我们，他们感到更有信心了，因为使用 GitHub Copilot 和 GitHub Copilot Chat 比不使用时编码更容易、更无差错、更可读、更可重用、更简洁、更可维护、更有弹性"。
马里奥-罗德里格斯（Mario Rodriguez），GitHub
对于那些在AI领域工作了很长时间的人来说，你可能会想到 "人在回路中（human-in-the-loop） "的概念，但没那么快：HITL 机器学习是一种建立在人类专家确保人工智能模型的行为符合预测的基础上的范式。虽然相关，但我们在这里提出的是更微妙的东西。LLM 驱动的系统不应成为当今大多数工作流程的主要驱动力；它们应该只是一种资源。以人类为中心，询问 LLM 如何支持他们的工作流程，这将带来截然不同的产品和设计决策。最终，这将促使您打造出与那些试图迅速将所有责任外包给 LLM 的竞争对手不同的产品--更好、更有用、风险更低的产品。前面的章节提供了大量的技巧和建议。这需要吸收很多东西。让我们考虑一下最起码有用的建议：如果一个团队想要构建一个 LLM 产品，他们应该从哪里开始？
在过去的一年中，我们已经看到了足够多的例子，开始确信成功的 LLM 应用都遵循着一致的轨迹。在本节中，我们将介绍这本基本的 "入门 "手册。核心理念是从简单开始，只在需要时增加复杂性。一个合理的经验法则是，每提高一个复杂程度，通常都需要比前一个复杂程度多付出至少一个数量级的努力。考虑到这一点...
从提示工程开始。使用我们之前在战术部分讨论过的所有技巧。思维链、n-shot 示例以及结构化输入和输出几乎总是一个好主意。在尝试从性能较弱的模型中榨出性能之前，先用性能最高的模型做原型。
只有在提示工程设计无法达到所需的性能水平时，才应考虑微调。如果有一些非功能性要求（如数据隐私、完全控制和成本）阻碍了专有模型的使用，从而要求您自行托管，那么这种情况就会更多。只要确保同样的隐私要求不会阻止你使用用户数据进行微调即可！
即使是刚刚起步的团队也需要评估。否则，你就不知道你的提示工程是否足够，也不知道你的微调模型何时可以取代基础模型。有效的评估针对您的任务并反映预期用例。我们推荐的第一级评估是单元测试。这些简单的断言可以检测已知或假设的故障模式，有助于推动早期设计决策。此外，还可查看其他针对特定任务的评估，如分类、总结等。虽然单元测试和基于模型的评估很有用，但它们不能取代人工评估的需要。让人们使用您的模型/产品并提供反馈。这样做有两个目的，一是测量真实世界的性能和缺陷率，二是收集可用于微调未来模型的高质量注释数据。这就形成了一个正反馈循环，或称数据飞轮，并随着时间的推移不断累积：例如，在审核 LLM 生成的摘要是否存在缺陷时，我们可能会给每个句子贴上细粒度的反馈标签，以确定事实不一致、不相关或风格不佳。然后，我们可以使用这些事实不一致注释来训练一个幻觉分类器，或者使用相关性注释来训练一个奖励模型，以便对相关性进行评分。作为另一个例子，LinkedIn 在其撰写的文章中分享了其使用基于模型的评价器来估计幻觉、负责任的人工智能违规行为、一致性等方面的成功经验。
通过创建资产，使其价值随着时间的推移不断复合，我们将建立评估从纯粹的运营支出升级为战略投资，并在此过程中建立我们的数据飞轮。
1971 年，施乐公司 PARC 的研究人员预言了未来：我们现在生活的个人电脑网络世界。他们在以太网、图形渲染、鼠标和窗口等技术的发明过程中发挥了关键作用，帮助创造了未来。但他们也做了一项简单的工作：他们研究了那些非常有用（如视频显示）但还不经济（即足够的 RAM 驱动一个视频显示需要数千美元）的应用。然后，他们研究了该技术的历史价格趋势（类似摩尔定律），并预测这些技术何时会变得经济实惠。我们可以对 LLM 技术采取同样的方法，尽管我们没有像每美元晶体管那样简洁的方法。我们可以采用一个流行的、长期使用的基准，比如大规模多任务语言理解数据集，以及一种一致的输入方法（五次提示）。然后，比较不同性能水平的语言模型在该基准上的运行成本。在成本固定的情况下，能力会迅速提高。在能力水平固定的情况下，成本会迅速降低。由作者之一查尔斯-弗莱（Charles Frye）于 2024 年 5 月 13 日使用公共数据创建。自 OpenAI 的 davinci 模型作为 API 推出以来的四年里，在一百万token（约 100 份本文档）的规模上运行一个性能相当的模型的成本从 20 美元降至不到 10 美分--仅用了六个月的时间就减半了。同样，截至 2024 年 5 月，通过 API 提供商或自行运行 Meta 的 LLama 3 8B 的成本仅为每百万token 20 美分，其性能与 OpenAI 的 text-davinci-003 相似，后者是让 ChatGPT 震惊世界的模型。该模型在 2023 年 11 月底发布时的价格也约为每百万代币 20 美元。这在短短 18 个月内就提升了两个数量级--摩尔定律预测在同一时间段内仅会翻一番。现在，让我们来考虑一下 LLMs 的一个非常有用的应用（为生成视频游戏角色提供动力，如 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 申请的第一年。我们希望我们学到的经验--从建立团队的严格操作技术等战术到内部建设哪些能力等战略视角--能在第二年及以后帮助你们，让我们共同发展这项令人兴奋的新技术。
粤ICP备14082021号
免费POC，
零成本试错
