过去一年，大模型应用以前所未有之势从出现到繁荣。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应用开发与运营的全方位经验。

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

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

要想成为伟大的产品，你的产品就不能仅仅是对别人的API的简单包装。但反其道而行之，代价可能会更高。在过去的一年里，有大量的风险投资，包括令人瞠目的 60 亿美元 A 轮融资，都花在了没有明确产品愿景或目标市场的培训和定制模型上。在本节中，我们将解释为什么立即培训自己的模型是一个错误，并考虑自托管的作用。

对于大多数组织而言，从头开始预训练LLM是不切实际的，会分散对产品开发的注意力。

虽然这很令人兴奋，而且似乎其他人都在这么做，但开发和维护机器学习基础架构需要大量资源。这包括收集数据、训练和评估模型以及部署模型。如果你还在验证产品与市场的契合度，这些工作就会占用开发核心产品的资源。即使您拥有计算、数据和技术能力，预训练的 LLM 也可能在几个月后就会过时。

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

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

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

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

这种进步既令人兴奋，又是可以预见的。综上所述，这意味着模型很可能是系统中最不耐用的组件。

相反，应将精力集中在能够提供持久价值的方面，例如：

• 评估底盘：可靠地衡量不同模型在任务中的表现
• 围栏：无论采用何种模型，都要防止出现不期望的输出
• 缓存：通过完全避免模型来减少延迟和成本

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

与原始模型能力相比，这些组成部分为产品质量提供了更厚实的护城河。

但这并不意味着在应用层构建就没有风险。如果 OpenAI 或其他模型提供商想要提供可行的企业软件，就不要把你的剪子对准他们需要剪掉的牦牛。

例如，一些团队投资构建定制工具，以验证专有模型的结构化输出；在此方面进行最小程度的投资固然重要，但过深的投资并不能很好地利用时间。OpenAI 需要确保当你要求调用函数时，你得到的是有效的函数调用--因为他们的所有客户都希望如此。在此采用一些 "策略性拖延"，构建你绝对需要的功能，等待供应商对功能的明显扩展。

从小事做起，建立信任

从根本上说，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 应用。

考虑一些浪费团队时间的误导性投资：

• 为您的业务构建自定义文本到 SQL 功能
• 构建与文档对话的聊天机器人

• 将公司的知识库与客户支持聊天机器人整合在一起

虽然以上是常见入门级的 LLM 应用，但几乎所有产品公司都不应该自己构建这些应用程序。这些都是许多企业面临的普遍问题，在有前景的演示和可靠的组件之间存在巨大差距，而这正是软件公司的惯常做法。将宝贵的研发资源投入到当前 Y Combinator 批量解决的一般问题上是一种浪费。

如果这听起来像是老生常谈的商业建议，那是因为在当前的炒作浪潮中，人们很容易把任何 "LLM "都误认为是前沿的增量差异化，而忽略了哪些已经过时的应用。

"总的来说，开发人员告诉我们，他们感到更有信心了，因为使用 GitHub Copilot 和 GitHub Copilot Chat 比不使用时编码更容易、更无差错、更可读、更可重用、更简洁、更可维护、更有弹性"。 

马里奥-罗德里格斯（Mario Rodriguez），GitHub

前面的章节提供了大量的技巧和建议。这需要吸收很多东西。让我们考虑一下最起码有用的建议：如果一个团队想要构建一个 LLM 产品，他们应该从哪里开始？

在过去的一年中，我们已经看到了足够多的例子，开始确信成功的 LLM 应用都遵循着一致的轨迹。在本节中，我们将介绍这本基本的 "入门 "手册。核心理念是从简单开始，只在需要时增加复杂性。一个合理的经验法则是，每提高一个复杂程度，通常都需要比前一个复杂程度多付出至少一个数量级的努力。考虑到这一点...

从提示工程开始。使用我们之前在战术部分讨论过的所有技巧。思维链、n-shot 示例以及结构化输入和输出几乎总是一个好主意。在尝试从性能较弱的模型中榨出性能之前，先用性能最高的模型做原型。

只有在提示工程设计无法达到所需的性能水平时，才应考虑微调。如果有一些非功能性要求（如数据隐私、完全控制和成本）阻碍了专有模型的使用，从而要求您自行托管，那么这种情况就会更多。只要确保同样的隐私要求不会阻止你使用用户数据进行微调即可！

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

例如，在审核 LLM 生成的摘要是否存在缺陷时，我们可能会给每个句子贴上细粒度的反馈标签，以确定事实不一致、不相关或风格不佳。然后，我们可以使用这些事实不一致注释来训练一个幻觉分类器，或者使用相关性注释来训练一个奖励模型，以便对相关性进行评分。作为另一个例子，LinkedIn 在其撰写的文章中分享了其使用基于模型的评价器来估计幻觉、负责任的人工智能违规行为、一致性等方面的成功经验。

通过创建资产，使其价值随着时间的推移不断复合，我们将建立评估从纯粹的运营支出升级为战略投资，并在此过程中建立我们的数据飞轮。