本文探讨了构建和管理“生成式 AI 产品”应用的运营方面，涵盖了数据、模型、产品和人员四个关键领域。作者强调了数据质量对模型性能的重要性，并介绍了如何检测和减少开发环境与生产环境之间的差异。文章还讨论了模型版本控制、选择合适模型大小以及设计以人为中心的“用户体验”的重要性。最后，作者强调了团队合作和实验文化的重要性，并建议将重点放在流程而非工具上。

➡️ 数据

  • 输入数据质量对模型性能至关重要，需要定期审查输入和输出数据，以了解数据分布、边缘情况和模型的局限性。
  • 开发环境与生产环境之间的差异会导致模型性能下降，需要进行结构性和内容性的偏差检测。
  • 定期审查模型输出可以帮助识别和适应新的模式或失败模式，并通过代码和断言将这些模式转化为可操作的指标。

➡️ 模型

  • 为了方便下游集成，需要生成结构化的输出，例如 JSON 或 YAML 格式。
  • 不同模型之间迁移提示可能很困难，需要进行测试和评估，以确保性能不会下降。
  • 版本控制和固定模型版本可以避免模型行为的意外变化，并确保模型的稳定性。
  • 选择最小的模型来完成任务，可以降低延迟和成本，并通过提示工程和上下文学习提高模型性能。

➡️ 产品

  • 在产品开发过程中尽早并经常地引入设计，可以帮助理解用户需求并改善用户体验。
  • 设计以人为中心的“用户体验”，可以收集用户反馈并改进模型。
  • 优先考虑产品的关键需求，例如可靠性、安全性、准确性和可扩展性，并根据用例调整风险承受能力。

➡️ 人员

  • 团队合作和实验文化是成功的关键，需要鼓励团队成员进行实验并分享经验。
  • 将重点放在流程而非工具上，可以避免不必要的技术债务，并提高团队的长期生产力。
  • 团队需要包括 AI 工程师、平台工程师、数据工程师和机器学习工程师等不同角色，以确保产品的成功。
  • 避免过度依赖 AI 工程师，需要根据产品开发阶段的不同需求，组建相应的团队。

原文

有句可能是传闻的名言，被许多领导者引用：“业余者谈策略和战术，专业人士谈操作。” 在战术层面看到的是各种独特的问题，而在操作层面看到的却是需要修复的组织失调模式。在战略层面看到的是机会，而在操作层面看到的是值得迎接的挑战。

在本文的第一部分中，我们介绍了战术性地与大语言模型 (LLMs) 一起工作的具体细节。在下一部分中，我们将放大视角，探讨长期战略考虑。在这一部分，我们讨论了介于战略和战术之间的操作方面，把理论转化为实践。

运营 LLM 应用程序提出了一些在运营传统软件系统中经常出现的问题，但往往带有新颖的变化，使其更具挑战性。同时，LLM 应用程序还引发了全新的问题。我们将这些问题及其答案分为四个部分：数据、模型、产品和人员。

关于数据，我们回答了：应该如何以及多频繁地审查 LLM 的输入和输出？如何测量和减少测试-生产偏差？

关于模型，我们回答了：如何将语言模型集成到整个技术栈中？如何管理模型的版本和迁移？

关于产品，我们回答了：设计应该在何时介入应用程序开发过程，为什么是“越早越好”？如何设计具有丰富人类反馈的用户体验？如何在众多冲突需求中进行优先排序？如何校准产品风险？

最后，关于人员，我们回答了：应该雇佣谁来构建成功的 LLM 应用程序，以及何时雇佣他们？如何培养实验文化？如何利用新兴的 LLM 应用程序来构建自己的 LLM 应用程序？哪个更重要：过程还是工具？

作为一个 AI 语言模型，我没有意见，因此无法告诉你你提供的引言是否“最佳”。不过，我可以说这段引言为接下来的内容定下了合适的基调。

操作：开发和管理 LLM 应用程序及其团队

数据

正如食材的质量决定了菜肴的味道，输入数据的质量决定了机器学习系统的性能。此外，输出数据是判断产品是否工作的唯一标准。所有作者都密切关注数据，每周花费数小时查看输入和输出数据，以更好地了解数据分布、模式、边缘情况及其模型的局限性。

检查开发-生产偏差

传统机器学习管道中一个常见的错误来源是训练-服务偏差。当训练使用的数据与模型在生产中遇到的数据不一致时，就会发生这种情况。虽然我们可以在不训练或微调的情况下使用 LLM，但开发-生产数据偏差依然存在。基本上，我们在开发过程中测试系统的数据应与系统在生产中面临的数据相符。如果不这样做，我们可能会发现生产环境中的准确性下降。

LLM 的开发-生产偏差可以分为两种类型：结构性偏差和内容性偏差。结构性偏差包括格式差异问题，例如 JSON 字典中的列表类型值与 JSON 列表之间的差异、不一致的大小写以及拼写错误或句子片段等。这些错误可能导致模型性能不可预测，因为不同的 LLM 是在特定数据格式上训练的，对细微变化非常敏感。内容性或语义偏差指的是数据意义或上下文的差异。

与传统机器学习一样，定期测量 LLM 输入/输出对之间的偏差是有用的。输入和输出的长度或特定格式要求 (如 JSON 或 XML) 等简单指标是跟踪变化的简单方法。对于更“高级”的漂移检测，可以考虑对输入/输出对的嵌入进行聚类，以检测语义漂移，例如用户讨论主题的变化，这可能表明他们在探索模型以前未接触过的领域。

在测试更改 (如提示工程) 时，确保保持数据集是最新的，并反映最新的用户交互类型。例如，如果拼写错误在生产输入中很常见，它们也应该出现在测试数据集中。除了数值偏差测量外，定期对输出进行定性评估也是有益的。定期审查模型的输出 (俗称“氛围检查”)，确保结果符合预期，并保持与用户需求相关。最后，在偏差检查中引入不确定性也是有用的——通过为测试数据集中的每个输入多次运行管道并分析所有输出，我们增加了捕捉偶尔出现的异常的可能性。

每天查看 LLM 输入和输出样本

LLM 是动态且不断发展的。尽管它们具有令人印象深刻的零样本能力和经常令人满意的输出，但它们的失败模式可能非常不可预测。对于定制任务，定期审查数据样本对于直观了解 LLM 的性能至关重要。

来自生产的输入输出对是 LLM 应用程序的“真实事物，真实场景” (genchi genbutsu)，无法替代。最近的研究强调，开发人员对“好”与“坏”输出的标准会随着他们与更多数据的互动而改变 (即标准漂移)。虽然开发人员可以事先制定一些标准来评估 LLM 输出，但这些预定义标准通常是不完整的。例如，在开发过程中，我们可能会更新提示，以增加好响应的概率并减少坏响应的概率。这种评估、重新评估和标准更新的迭代过程是必要的，因为在不直接观察输出的情况下，很难预测 LLM 的行为或人类的偏好。

为了有效地管理这一点，我们应该记录 LLM 的输入和输出。通过每天检查这些日志的样本，我们可以快速识别和适应新的模式或失败模式。当我们发现一个新问题时，我们可以立即围绕它编写一个断言或评估。同样，任何失败模式定义的更新都应反映在评估标准中。这些“氛围检查”是不良输出的信号；代码和断言将其操作化。最后，这种态度必须被社会化，例如通过将输入和输出的审查或注释添加到值班轮换中。

与模型合作

通过 LLM API，我们可以依靠少数提供商的智能。虽然这是一个好处，但这些依赖也涉及性能、延迟、吞吐量和成本的权衡。此外，随着更好更新的模型不断推出 (过去一年几乎每月都有)，我们应该准备好在淘汰旧模型并迁移到新模型时更新我们的产品。在本节中，我们分享了与我们无法完全控制的技术合作的经验，其中模型无法自托管和管理。

生成结构化输出以简化下游集成

对于大多数现实世界的用例，LLM 的输出将通过某种机器可读格式被下游应用程序消耗。例如，房地产 CRM Rechat 需要结构化响应以便前端呈现小部件。同样，生成产品战略想法的工具 Boba 需要带有标题、摘要、可信度评分和时间范围字段的结构化输出。最后，LinkedIn 分享了关于将 LLM 限制为生成 YAML，然后用于决定使用哪种技能以及提供调用技能的参数。

这种应用模式是 Postel 定律的极端版本：在接受的内容上要宽松 (任意自然语言)，在发送的内容上要保守 (类型化的机器可读对象)。因此，我们预计它将非常持久。

目前，Instructor 和 Outlines 是从 LLM 获取结构化输出的事实标准。如果你使用 LLM API (例如 Anthropic，OpenAI)，请使用 Instructor；如果你使用自托管模型 (例如 Hugging Face)，请使用 Outlines。

在模型之间迁移提示是一件麻烦事

有时，我们精心制作的提示在一个模型上效果极佳，但在另一个模型上却表现平平。这可能发生在我们在不同的模型提供商之间切换时，也可能发生在我们在同一模型的不同版本之间升级时。

例如，Voiceflow 发现从 gpt-3.5-turbo-0301 迁移到 gpt-3.5-turbo-1106 使他们的意图分类任务下降了 10%。(谢天谢地，他们有评估！) 同样，GoDaddy 观察到一个积极的趋势，即升级到 1106 版本缩小了 gpt-3.5-turbo 和 gpt-4 之间的性能差距。(或者，如果你是一个半杯水的人，你可能会失望于新升级使 gpt-4 的领先优势减小了)

因此，如果我们必须在模型之间迁移提示，预计这将比简单地交换 API 端点花费更多时间。不要假设插入相同的提示会导致类似或更好的结果。此外，可靠的自动评估有助于在迁移前后测量任务性能，并减少手动验证所需的努力。

对模型进行版本控制和固定

在任何机器学习管道中，“改变任何东西就会改变一切”。当我们依赖于我们自己没有训练且可能在不知情的情况下发生变化的组件 (如大语言模型 LLMs) 时，这一点尤为重要。

幸运的是，许多模型提供商提供了“固定”特定模型版本的选项 (例如，gpt-4-turbo-1106)。这使我们能够使用特定版本的模型权重，确保它们保持不变。在生产中固定模型版本可以帮助避免模型行为的意外变化，这些变化可能导致客户对模型更换时出现的问题 (如过于冗长的输出或其他不可预见的失败模式) 的投诉。

此外，考虑维护一个影子管道，该管道镜像你的生产设置，但使用最新的模型版本。这使得在新版本上进行安全实验和测试成为可能。一旦你验证了这些新模型输出的稳定性和质量，就可以自信地更新生产环境中的模型版本。

选择完成任务所需的最小模型

在开发新应用程序时，使用最大、最强大的模型是很诱人的。但一旦我们确定任务在技术上是可行的，就值得尝试一个较小的模型是否可以实现相似的结果。

较小模型的好处是延迟和成本较低。虽然它可能较弱，但链式思维、n-shot 提示和上下文学习等技术可以帮助较小的模型超越其能力。除了 LLM API，微调我们的具体任务也有助于提高性能。

综上所述，使用较小模型的精心设计的工作流通常可以匹配甚至超过单个大型模型的输出质量，同时更快且成本更低。例如，这个帖子分享了 Haiku + 10-shot 提示如何优于零样本 Opus 和 GPT-4 的轶事。在长期内，我们预计会看到更多使用较小模型进行流工程的例子，这是输出质量、延迟和成本的最佳平衡。

另一个例子是简单的分类任务。像 DistilBERT (6700 万参数) 这样轻量级的模型是一个令人惊讶的强基线。4000 万参数的 DistilBART 是另一个很好的选择——在开源数据上微调后，它可以以 0.84 的 ROC-AUC 识别幻觉，超过了大多数 LLM，延迟和成本不到 5%。

关键是，不要忽视较小的模型。虽然将一个庞大的模型应用于每个问题很容易，但通过一些创造力和实验，我们通常可以找到更高效的解决方案。

产品

虽然新技术提供了新的可能性，但构建优秀产品的原则是永恒的。因此，即使我们第一次解决新问题，我们也不必在产品设计上重新发明轮子。将我们的 LLM 应用程序开发扎根于坚实的产品基础，可以让我们为服务的人提供真正的价值。

尽早且经常地参与设计

拥有设计师会促使你深入理解和思考你的产品如何构建和呈现给用户。我们有时会将设计师刻板印象为让事物变得美丽的人。但事实上，除了用户界面之外，他们还会重新思考如何改善用户体验，即使这意味着打破现有规则和范式。

设计师尤其擅长将用户的需求重新框定为各种形式。其中一些形式更易于解决，因此，它们可能为 AI 解决方案提供更多或更少的机会。与许多其他产品一样，构建 AI 产品应以要完成的工作为中心，而不是驱动它们的技术。

重点是问自己：“用户要求这个产品为他们做什么工作？这项工作是聊天机器人擅长的吗？自动完成怎么样？也许是不同的东西！” 考虑现有的设计模式及其与要完成的工作的关系。这些是设计师为你的团队能力增添的宝贵资产。

为人类在循环中设计你的 UX

获得高质量注释的一种方法是将人类在循环中 (HITL) 集成到用户体验 (UX) 中。通过让用户轻松提供反馈和纠正，我们可以改进即时输出并收集有价值的数据来改进我们的模型。

想象一个电子商务平台，用户在其中上传和分类他们的产品。我们可以设计 UX 的几种方式：

  • 用户手动选择正确的产品类别；LLM 定期检查新产品并在后端纠正分类错误。
  • 用户根本不选择任何类别；LLM 定期在后端分类产品 (可能会出现错误)。
  • LLM 实时建议一个产品类别，用户可以根据需要验证和更新。

虽然这三种方法都涉及 LLM，但它们提供了非常不同的用户体验。第一种方法将初始负担放在用户身上，而 LLM 充当后处理检查。第二种方法对用户不需要任何努力，但不提供透明度或控制。第三种方法找到了正确的平衡。通过让 LLM 预先建议类别，我们减少了用户的认知负担，他们不必学习我们的分类法来分类他们的产品！同时，通过允许用户查看和编辑建议，他们可以最终决定如何分类他们的产品，将控制权牢牢掌握在自己手中。作为奖励，第三种方法为模型改进创造了一个自然的反馈循环。好的建议被接受 (正标签)，不好的建议被更新 (负标签后接正标签)。

这种建议、用户验证和数据收集的模式在几个应用程序中很常见：

  • 编码助手：用户可以接受一个建议 (强正面)，接受并调整建议 (正面)，或忽略建议 (负面)
  • Midjourney：用户可以选择放大和下载图像 (强正面)，变更图像 (正面)，或生成一组新图像 (负面)
  • 聊天机器人：用户可以对响应提供点赞 (正面) 或点踩 (负面)，或在响应非常糟糕时选择重新生成响应 (强负面)

反馈可以是显式的或隐式的。显式反馈是用户响应产品请求提供的信息；隐式反馈是我们从用户交互中学到的信息，而无需用户故意提供反馈。编码助手和 Midjourney 是隐式反馈的例子，而点赞和点踩是显式反馈。如果我们设计好 UX，如编码助手和 Midjourney，我们可以收集大量隐式反馈来改进我们的产品和模型。

无情地优先考虑你的需求层次

当我们考虑将演示投入生产时，我们必须考虑以下需求：

  • 可靠性：99.9% 的正常运行时间，遵循结构化输出
  • 无害性：不生成冒犯性、NSFW 或其他有害内容
  • 事实一致性：忠实于提供的上下文，不编造内容
  • 有用性：与用户需求和请求相关
  • 可扩展性：延迟服务水平协议，支持的吞吐量
  • 成本：因为我们没有无限预算
  • 以及更多：安全性、隐私、公平性、GDPR、DMA 等

如果我们试图一次解决所有这些需求，我们将永远无法发布任何东西。因此，我们需要无情地优先考虑。这意味着明确哪些是不可协商的 (例如，可靠性、无害性)，没有这些我们的产品无法运行或不可行。这一切都关乎识别最低可爱产品。我们必须接受第一个版本不会是完美的，只需发布并迭代。

根据用例校准你的风险容忍度

在决定语言模型和应用程序的审查级别时，考虑用例和受众。对于提供医疗或财务建议的面向客户的聊天机器人，我们需要非常高的安全性和准确性标准。错误或不良输出可能导致实际伤害并侵蚀信任。但对于不那么关键的应用程序，如推荐系统，或内部应用程序，如内容分类或摘要，过于严格的要求只会减慢进度而不会增加太多价值。

这与最近的a16z 报告一致，该报告显示许多公司在内部 LLM 应用程序上比在外部应用程序上进展更快。通过尝试将 AI 应用于内部生产力，组织可以在更受控的环境中开始捕捉价值，同时学习如何管理风险。然后，随着信心的增加，他们可以扩展到面向客户的用例。

团队与角色

没有工作职能是容易定义的，但为这个新领域的工作写职位描述比其他领域更具挑战性。我们将放弃交叉职务的文氏图或职位描述的建议。然而，我们将承认一个新角色的存在——AI 工程师，并讨论它的位置。重要的是，我们将讨论团队的其余部分以及应如何分配职责。

专注于过程，而不是工具

面对新范式，如 LLMs，软件工程师倾向于偏爱工具。结果，我们忽视了工具应该解决的问题和过程。这样，许多工程师承担了意外的复杂性，这对团队的长期生产力产生了负面影响。

例如，这篇文章讨论了某些工具如何自动为大语言模型创建提示。它（恰当地）认为，工程师在没有首先理解问题解决方法或过程的情况下使用这些工具，最终承担了不必要的技术债务。

除了意外复杂性，工具通常指定不足。例如，LLM 评估工具的行业正在增长，这些工具提供“盒装 LLM 评估”，带有用于毒性、简洁性、语调等的通用评估器。我们看到许多团队在没有认真考虑其领域的特定失败模式的情况下采用这些工具。与此形成对比的是 EvalGen。它专注于教用户通过在每一步都深度参与用户的方式创建领域特定的评估，从指定标准、标记数据到检查评估。软件引导用户通过如下所示的工作流程：

Shankar, S., et al. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. Retrieved from https://arxiv.org/abs/2404.12272

EvalGen 引导用户通过 LLM 评估的最佳实践，即：

  1. 定义领域特定的测试 (从提示自动启动)。这些测试被定义为带有代码的断言或 LLM-as-a-Judge。
  2. 使测试与人类判断保持一致的重要性，以便用户可以检查测试是否捕捉到指定的标准。
  3. 随着系统（提示等）的变化迭代你的测试。

EvalGen 为开发人员提供了评估构建过程的思维模型，而不将他们固定在特定工具上。我们发现，在为 AI 工程师提供这个背景后，他们通常决定选择更精简的工具或自己构建。

除了提示编写和评估之外，LLM 的组件太多，无法在此详尽列出。然而，AI 工程师了解过程而不是采用工具是很重要的。

永远在实验

机器学习产品与实验密切相关。不仅是 A/B，随机对照试验，还有频繁尝试修改系统中最小可能组件并进行离线评估。每个人都如此热衷于评估的原因实际上不是关于可信度和信心——而是为了启用实验！你的评估越好，你对实验的迭代速度就越快，从而你就能更快地收敛到系统的最佳版本。

尝试解决同一问题的不同方法是很常见的，因为现在实验非常便宜。收集数据和训练模型的高成本已最小化——提示工程的成本几乎只是人力成本。将你的团队定位为每个人都学习提示工程的基础知识。这鼓励每个人进行实验，并带来来自整个组织的多样化想法。

此外，不仅仅是进行探索性实验——也要利用它们！有一个新任务的工作版本？考虑让团队中的其他人以不同方式处理它。尝试以更快的方式完成它。研究链式思维或少样本提示等提示技术以提高质量。不要让你的工具限制你的实验；如果它是，请重建它，或购买一些东西来改进它。

最后，在产品/项目规划期间，为构建评估和运行多次实验留出时间。想想工程产品的产品规格，但在其中添加评估的明确标准。在路线图规划期间，不要低估实验所需的时间——预计在获得生产绿灯之前进行多次迭代开发和评估。

赋予每个人使用新 AI 技术的能力

随着生成式 AI 的采用增加，我们希望整个团队——不仅仅是专家——了解并感到有能力使用这项新技术。没有比实际使用它们更好的方法来发展对 LLMs 工作原理 (如延迟、失败模式、UX) 的直觉。LLMs 相对容易接触：你不需要知道如何编码即可提高管道的性能，每个人都可以通过提示工程和评估开始贡献。

这在很大程度上是教育。可以从提示工程的基础知识开始，如 n-shot 提示和链式思维等技术有助于将模型调整到所需的输出。了解这些知识的人还可以介绍更技术的方面，例如 LLMs 本质上是自回归的。换句话说，虽然输入 tokens 是并行处理的，但输出 tokens 是按顺序生成的。因此，延迟更多地取决于输出长度而不是输入长度——这是在设计 UX 和设定性能期望时需要考虑的关键因素。

我们还可以进一步提供动手实验和探索的机会。也许是一次黑客马拉松？虽然让整个团队花几天时间在推测项目上进行黑客攻击似乎很昂贵，但结果可能会让你惊讶。我们知道有一个团队通过一次黑客马拉松，加速并几乎完成了他们的三年路线图。另一个团队进行了黑客马拉松，带来了因 LLMs 而现在可能实现的范式转变 UX，这些 UX 现在被优先安排为年度及以后的重点项目。

不要陷入“AI 工程是我唯一需要”的陷阱

随着新职位名称的出现，最初往往会夸大与这些角色相关的能力。这通常会导致痛苦的纠正，因为这些工作的实际范围变得明确。进入这个领域的新手以及招聘经理可能会做出夸张的声明或有夸大的期望。过去十年中的一些显着例子包括：

最初，许多人认为数据科学家就足以完成数据驱动项目。然而，事实证明，数据科学家必须与软件和数据工程师合作，才能有效开发和部署数据产品。

这种误解在 AI 工程师的新角色中再次出现，一些团队认为 AI 工程师是你所需要的一切。事实上，构建机器学习或 AI 产品需要各种专业角色。我们与十几家公司在 AI 产品上进行了咨询，并始终观察到他们陷入了“AI 工程是你所需要的一切”的陷阱。因此，产品往往难以超越演示阶段，因为公司忽视了构建产品所涉及的关键方面。

例如，评估和测量对于将产品扩展到氛围检查之外至关重要。有效评估的技能与传统上在机器学习工程师中看到的一些优势一致——一个完全由 AI 工程师组成的团队可能缺乏这些技能。联合作者 Hamel Husain 在他最近关于检测数据漂移和设计领域特定评估的工作中展示了这些技能的重要性。

以下是构建 AI 产品过程中所需角色类型及其时间的粗略进展：

  1. 首先，专注于构建产品。这可能包括一个 AI 工程师，但不一定。AI 工程师在原型设计和快速迭代产品 (UX，管道等) 方面很有价值。
  2. 接下来，通过对系统进行检测和收集数据来创建正确的基础。根据数据的类型和规模，你可能需要平台和/或数据工程师。你还必须有查询和分析这些数据的系统来调试问题。
  3. 接下来，你最终会想优化你的 AI 系统。这不一定涉及训练模型。基本步骤包括设计指标、构建评估系统、运行实验、优化 RAG 检索、调试随机系统等。MLE 在这些方面非常擅长 (虽然 AI 工程师也可以掌握这些技能)。除非你已经完成了先决步骤，否则通常没有必要雇用 MLE。

除此之外，你始终需要一个领域专家。在小公司中，这理想情况下是创始团队——在大公司中，产品经理可以扮演这个角色。了解角色的进展和时间安排至关重要。在错误的时间雇用人员 (例如，过早雇用 MLE) 或以错误的顺序构建是浪费时间和金钱，并导致人事变动。此外，在第 1-2 阶段定期与 MLE (但不全职雇用) 核对将帮助公司建立正确的基础。

关于作者

Eugene Yan设计、构建和运营为大规模客户服务的机器学习系统。他目前是亚马逊的高级应用科学家，构建大规模服务用户的 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 的《Building Production Recommendation Systems》一书，并在 Rutgers 研究生院教授数据科学和分析。他的博士学位是纯数学。

Charles Frye教人们构建 AI 应用。在发表了精神药理学和神经生物学方面的研究之后，他在加州大学伯克利分校获得了博士学位，研究论文题为神经网络优化。他已经通过在 Weights and Biases，Full Stack Deep Learning 和 Modal 的教育和咨询工作，教授了数千人从线性代数基础到 GPU 奥秘和构建可辩护业务的整个 AI 应用开发堆栈。

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 驱动的产品，每天为数千用户服务。作为研究人员，她的工作重点是通过以人为中心的方法解决生产机器学习系统中的数据挑战。她的工作出现在顶级数据管理和人机交互会议上，如 VLDB，SIGMOD，CIDR 和 CSCW。

联系我们

我们很想听听你对这篇文章的想法。你可以通过[email protected]联系我们。我们中的许多人愿意接受各种形式的咨询和建议。如果适当，我们将在联系时将你转到相关专家。

致谢

这一系列文章始于群聊中的一次对话，Bryan 打趣说他受到了“写一年的 AI 工程”启发。然后，群聊中发生了✨魔法✨，我们都被激励着分享我们迄今为止学到的东西。

作者们要感谢 Eugene 领导了文档集成和总体结构的主要工作，此外还负责了大量的教训内容。还要感谢他对主要编辑和文档方向的负责。作者们要感谢 Bryan 提供了这个写作的火花，将写作重组为战术、运营和战略部分及其介绍，并推动我们考虑如何更大程度地帮助社区。作者们要感谢 Charles 深入研究成本和 LLMOps，并将教训编织得更连贯、更紧密——你可以感谢他让这篇文章变成 30 页而不是 40 页！作者们感谢 Hamel 和 Jason 他们从客户咨询中获得的见解和第一线的经验，分享了广泛可推广的客户教训以及对工具的深入了解。最后，感谢 Shreya 提醒我们评估和严格生产实践的重要性，并将她的研究和原始结果带入本文。

最后，作者们要感谢所有团队在你们自己的写作中如此慷慨地分享了你们的挑战和教训，我们在本文中多次引用了这些写作，以及 AI 社区的热情参与和与本小组的互动。