我们从一年的大语言模型构建中学到的经验中

最近看到一篇关于LLM的文章，觉得有用，翻译分享给大家，将分为两期呈现。原文地址：https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-ii/

许多领导者都说过一句可能并不准确的话：“外行谈战略和战术，专业人士谈运营。” 从战术角度来看，会看到一大堆_特殊_问题；而从运营角度来看，则会看到需要修复的组织功能障碍模式。从战略角度来看，会看到一个机会；而从运营角度来看，则会看到一个值得迎接的挑战。

在本篇文章的第一部分中，我们介绍了使用 LLM 的_战术_细节。在下一部分中，我们将放大范围，涵盖长期的_战略_考量。在这一部分中，我们将讨论构建 LLM 应用的_运营_方面，这些方面介于战略和战术之间，将理论付诸实践。

运营 LLM 应用提出了一些我们从运营传统软件系统中熟悉的问题，这些问题通常会带有一种新奇的色彩，以保持趣味性。LLM 应用也提出了一些全新的问题。我们将这些问题和我们的答案分为四个部分：数据、模型、产品和人员。

对于数据，我们回答：你应该如何以及多久审查一次 LLM 的输入和输出？你如何衡量和减少测试与生产环境之间的差异？

对于模型，我们回答：你如何将语言模型集成到其余的技术堆栈中？你应该如何考虑模型版本控制以及在不同模型和版本之间迁移？

对于产品，我们回答：设计应该在应用程序开发过程的什么时候介入，以及为什么是“越早越好”？你如何设计具有丰富的人机交互反馈的用户体验？你如何确定众多相互冲突的需求的优先级？你如何校准产品风险？

最后，对于人员，我们回答：你应该雇佣哪些人来构建成功的 LLM 应用，以及应该在什么时候雇佣他们？你如何才能培养正确的、鼓励实验的文化？你应该如何使用新兴的 LLM 应用来构建自己的 LLM 应用？哪个更重要：流程还是工具？

作为一种 AI 语言模型，我没有意见，所以不能告诉你你提供的引言是“很棒还是一般”。但是，我可以说引言为接下来的内容做好了铺垫。

运营：开发和管理 LLM 应用以及构建它们的团队

数据

正如食材的质量决定了菜肴的味道一样，输入数据的质量也制约着机器学习系统的性能。此外，输出数据是判断产品是否有效的唯一途径。所有作者都密切关注数据，每周都会花几个小时时间查看输入和输出，以便更好地了解数据分布：其模式、边缘情况以及对其建模的局限性。

检查开发环境与生产环境之间的差异

传统机器学习管道中常见的错误来源是_训练-服务偏差_。当训练中使用的数据与模型在生产环境中遇到的数据不同时，就会发生这种情况。虽然我们可以使用 LLM 而不进行训练或微调，因此没有训练集，但开发环境与生产环境之间的数据差异也会出现类似的问题。从本质上讲，我们在开发过程中测试系统所用的数据应该与系统在生产环境中将要面对的数据一致。否则，我们可能会发现生产环境的准确性会受到影响。

LLM 开发环境与生产环境之间的差异可以分为两种类型：结构性差异和基于内容的差异。结构性差异包括格式差异，例如包含列表类型值的 JSON 字典与 JSON 列表之间的差异、大小写不一致以及拼写错误或句子片段等错误。这些错误可能会导致模型性能不可预测，因为不同的 LLM 是根据特定的数据格式进行训练的，而且提示对微小的变化非常敏感。基于内容的差异或“语义”差异是指数据含义或上下文的差异。

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

在测试更改时，例如提示工程，请确保留出数据集是最新的，并且反映了最新类型的用户交互。例如，如果生产环境输入中经常出现拼写错误，那么留出数据中也应该出现拼写错误。除了数值偏差测量之外，对输出进行定性评估也是有益的。定期审查模型的输出（这种做法通常被称为“氛围检查”）可以确保结果符合预期，并始终与用户需求相关。最后，在偏差检查中纳入不确定性也很有用——通过对测试数据集中的每个输入多次运行管道并分析所有输出，我们可以提高捕捉仅偶尔出现的异常的可能性。

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

LLM 是动态的，并且在不断发展。尽管它们具有令人印象深刻的零样本能力，并且经常会输出令人愉快的结果，但它们的故障模式可能 highly unpredictable。对于自定义任务，定期审查数据样本对于直观地了解 LLM 的性能至关重要。

来自生产环境的输入-输出对是 LLM 应用的“真实事物，真实地点”（现场），而且是不可替代的。最近的研究强调，随着开发者与更多数据的交互（即_标准漂移_），他们对什么构成“好”和“坏”输出的看法会发生变化。虽然开发者可以预先提出一些评估 LLM 输出的标准，但这些预定义的标准通常是不完整的。例如，在开发过程中，我们可能会更新提示，以增加良好响应的概率并减少不良响应的概率。这种评估、重新评估和标准更新的迭代过程是必要的，因为如果不直接观察输出，就很难预测 LLM 行为或人类偏好。

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

使用模型

借助 LLM API，我们可以利用来自少数提供商的智能。虽然这是一个福音，但这些依赖关系也涉及性能、延迟、吞吐量和成本方面的权衡。此外，随着更新、更好的模型的出现（在过去的一年中几乎每个月都会出现），我们应该做好更新产品的准备，因为我们要弃用旧模型并迁移到新模型。在本节中，我们将分享我们在使用我们无法完全控制的技术方面的经验教训，在这些技术中，模型无法自托管和管理。

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

对于大多数现实世界的用例，LLM 的输出将通过某种机器可读格式被下游应用程序使用。例如，Rechat（一个房地产 CRM）需要结构化响应，以便前端呈现小部件。类似地，Boba（一种用于生成产品策略想法的工具）需要结构化输出，其中包含标题、摘要、合理性分数和时间范围等字段。最后，LinkedIn 分享了约束 LLM 生成 YAML 的经验，然后使用 YAML 来决定使用哪种技能，以及提供调用该技能的参数。

这种应用程序模式是 Postel 定律的一个极端版本：接受的内容要自由（任意自然语言），发送的内容要保守（类型化、机器可读的对象）。因此，我们预计它将 extremely durable。

目前，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 端点花费更多的时间。不要假设插入相同的提示会导致相似或更好的结果。此外，拥有可靠的自动化评估有助于在迁移前后衡量任务性能，并减少手动验证所需的工作量。

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

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

幸运的是，许多模型提供商都提供了“固定”特定模型版本（例如，gpt-4-turbo-1106）的选项。这使我们能够使用特定版本的模型权重，确保它们保持不变。在生产环境中固定模型版本有助于避免模型行为发生意外变化，因为模型被交换时可能会出现问题，例如输出过于冗长或其他 unforeseen 故障模式，从而导致客户投诉。

此外，可以考虑维护一个影子管道，该管道镜像你的生产环境设置，但使用的是最新的模型版本。这可以让你安全地试验和测试新版本。在你验证了这些较新模型的输出的稳定性和质量后，就可以放心地更新生产环境中的模型版本。

选择能够完成任务的最小模型

在开发新应用程序时，人们很容易想使用最大、最强大的模型。但是，一旦我们确定了任务在技术上是可行的，那么就值得尝试一下，看看一个更小的模型是否能够 achieving comparable results。

较小模型的优点是延迟更低，成本更低。虽然它可能比较弱，但思维链、n-shot 提示和上下文学习等技术可以帮助较小的模型发挥更大的作用。除了 LLM API 之外，针对我们的特定任务进行微调也有助于提高性能。

总而言之，使用较小模型精心设计的流程通常可以匹配甚至超过单个大型模型的输出质量，同时速度更快，成本更低。例如，这篇推文分享了一些轶事数据，说明 Haiku + 10-shot 提示的性能优于零样本 Opus 和 GPT-4。从长远来看，我们预计会看到更多使用较小模型进行流程工程的例子，因为这是输出质量、延迟和成本之间的最佳平衡。

再举一个例子，以简单的分类任务为例。像 DistilBERT（6700 万个参数）这样的轻量级模型是一个 surprisingly strong 基线。4 亿个参数的 DistilBART 是另一个不错的选择——在开源数据上进行微调后，它可以以 0.84 的 ROC-AUC 识别幻觉，在延迟和成本不到 5% 的情况下，其性能超过了大多数 LLM。

关键是，不要忽视较小的模型。虽然将一个大型模型应用于所有问题很容易，但只要 немного творчества 和实验，我们通常可以找到更有效的解决方案。

产品

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

尽早并经常地让设计参与进来

拥有一名设计师会促使你深入了解和思考如何构建你的产品以及如何将其呈现给用户。我们有时会对设计师有刻板印象，认为他们只是把东西做得漂亮。但除了用户界面之外，他们还会重新思考如何改进用户体验，即使这意味着要打破现有的规则和范式。

设计师特别擅长以各种形式重新定义用户的需求。其中一些形式比其他形式更容易解决，因此，它们可能为人工智能解决方案提供更多或更少的机会。与许多其他产品一样，构建人工智能产品的核心应该是要完成的工作，而不是驱动它们的 technology。

专注于问自己：“用户要求这个产品为他们做什么工作？聊天机器人是否适合做这项工作？自动完成怎么样？也许是其他的东西！” 考虑现有的设计模式以及它们与要完成的工作之间的关系。这些都是设计师为你的团队能力带来的宝贵资产。

为人机交互设计用户体验

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

想象一下一个电子商务平台，用户可以在该平台上上传和分类他们的产品。我们可以通过以下几种方式设计用户体验：

用户手动选择正确的产品类别；LLM 定期检查新产品并在后端更正错误分类。
用户根本不需要选择任何类别；LLM 定期在后端对产品进行分类（可能存在错误）。
LLM 实时建议产品类别，用户可以根据需要进行验证和更新。

虽然这三种方法都涉及 LLM，但它们提供的用户体验却截然不同。第一种方法将初始负担放在用户身上，并让 LLM 充当后处理检查。第二种方法不需要用户付出任何努力，但没有提供任何透明度或控制权。第三种方法取得了恰当的平衡。通过让 LLM 预先建议类别，我们减轻了用户的认知负担，而且他们不必为了对产品进行分类而学习我们的分类法！同时，通过允许用户审查和编辑建议，他们对产品的分类方式拥有最终决定权，将控制权牢牢地掌握在自己手中。此外，第三种方法还创建了一个用于模型改进的自然反馈循环。好的建议会被接受（正标签），不好的建议会被更新（负标签，然后是正标签）。

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

编码助手：用户可以接受建议（强肯定）、接受并调整建议（肯定）或忽略建议（否定）
Midjourney：用户可以选择放大和下载图像（强肯定）、修改图像（肯定）或生成一组新图像（否定）
聊天机器人：用户可以对响应表示赞同（肯定）或反对（否定），或者如果响应真的很糟糕，可以选择重新生成响应（强否定）

反馈可以是显式的，也可以是隐式的。显式反馈是用户应我们产品的请求而提供的信息；隐式反馈是我们从用户交互中学习到的信息，而不需要用户刻意提供反馈。编码助手和 Midjourney 是隐式反馈的例子，而点赞和点踩是显式反馈。如果我们像编码助手和 Midjourney 那样设计用户体验，我们就可以收集大量的隐式反馈来改进我们的产品和模型。

无情地确定你的需求层次结构的优先级

当我们考虑将演示版本投入生产时，我们必须考虑以下方面的要求：

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

如果我们试图一次性解决所有这些要求，那么我们将永远无法发布任何东西。因此，我们需要确定优先级。无情地。这意味着要明确什么是不可妥协的（例如，可靠性、无害性），否则我们的产品就无法正常工作或无法生存。关键在于确定最小可行产品。我们必须接受第一个版本并不完美，然后 just launch and iterate。

根据用例校准你的风险承受能力

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

这与最近的一份 a16z 报告的结论一致，该报告显示，与外部 LLM 应用相比，许多公司在内部 LLM 应用方面进展更快。通过试验人工智能来提高内部生产力，企业可以在学习如何在更可控的环境中管理风险的同时，开始获取价值。然后，随着他们获得信心，他们可以扩展到面向客户的用例。

团队和角色

没有任何工作职能是容易定义的，但在这个新领域中，编写工作描述比其他领域更具挑战性。我们将放弃交叉工作职位的维恩图，或对工作描述的建议。然而，我们将承认一个新角色的存在——人工智能工程师——并讨论它的地位。重要的是，我们将讨论团队的其他成员以及如何分配责任。

注重流程，而不是工具

当面对 LLM 等新范式时，软件工程师往往倾向于使用工具。因此，我们忽略了工具应该解决的问题和流程。在这样做的时候，许多工程师承担了不必要的复杂性，这对团队的长期生产力产生了负面影响。

例如，这篇文章讨论了某些工具如何自动为大型语言模型创建提示。它认为（恕我直言，这是正确的），使用这些工具而不首先了解问题解决方法或流程的工程师最终会承担不必要的技术债务。

除了意外的复杂性之外，工具通常定义不明确。例如，LLM 评估工具行业正在不断发展，这些工具提供“开箱即用的 LLM 评估”，其中包含针对毒性、简洁性、语气等的通用评估器。我们已经看到许多团队在采用这些工具时，没有认真考虑其领域特定的故障模式。相比之下，EvalGen 则侧重于教授用户创建特定领域评估的过程，方法是让用户 deeply 参与到从指定标准、标记数据到检查评估的每一步中。该软件引导用户完成如下所示的工作流程：

Shankar, S. 等人 (2024)。谁来验证验证器？使 LLM 辅助的 LLM 输出评估与人类偏好保持一致。检索自 https://arxiv.org/abs/2404.12272

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

定义特定领域的测试（从提示中自动引导）。这些测试被定义为带有代码的断言或使用 LLM 作为判断依据。
将测试与人类判断保持一致的重要性，以便用户可以检查测试是否捕获了指定的标准。
随着系统（提示等）的变化而迭代测试。

EvalGen 为开发者提供了一个评估构建过程的心智模型，而没有将他们限制在特定的工具上。我们发现，在为人工智能工程师提供了这种背景之后，他们通常会选择更精简的工具或构建自己的工具。

除了提示编写和评估之外，LLM 还有很多组件，这里无法一一列举。但是，重要的是，人工智能工程师在采用工具之前要先了解这些流程。

始终保持实验

机器学习产品与实验密切相关。不仅是 A/B 测试、随机对照试验，还包括频繁尝试修改系统中尽可能小的组件并进行离线评估。每个人都对评估如此热衷的原因实际上并不是为了获得可信任性和信心——而是为了实现实验！你的评估做得越好，你就可以越快地迭代实验，从而越快地找到系统的最佳版本。

尝试不同的方法来解决同一个问题是很常见的，因为现在实验的成本很低。收集数据和训练模型的高成本被降到了最低——提示工程的成本只比人工时间略高。定位你的团队，让每个人都学会提示工程的基础知识。这鼓励每个人都去尝试，并能从整个组织中获得不同的想法。

此外，不要只进行探索性的实验，也要利用实验来 exploitation！有了一个新任务的可行版本？可以考虑让团队中的其他人用不同的方法来处理它。尝试用另一种更快的方法来完成它。研究思维链或少样本提示等提示技术，以提高其质量。不要让你的工具阻碍你进行实验；如果阻碍了你，就重建它，或者购买一些东西来改进它。

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

授权每个人使用新的人工智能技术

随着生成式人工智能的普及，我们希望整个团队（而不仅仅是专家）都能理解并敢于使用这项新技术。没有比实际使用 LLM 更好的方法来培养对 LLM 工作原理（例如，延迟、故障模式、用户体验）的直觉了。LLM 相对容易上手：你不需要知道如何编写代码来提高管道的性能，每个人都可以通过提示工程和评估来开始做出贡献。

其中很大一部分是教育。它可以从提示工程的基础知识开始，例如 n-shot 提示和 CoT 等技术如何帮助模型朝着期望的输出方向发展。拥有相关知识的人还可以教授更多技术方面的知识，例如 LLM 如何具有自回归性。换句话说，虽然输入标记是并行处理的，但输出标记是顺序生成的。因此，延迟更多地取决于输出长度，而不是输入长度——这是设计用户体验和设定性能预期时需要考虑的关键因素。

我们还可以更进一步，提供实践和探索的机会。例如，举办一次黑客马拉松？虽然让整个团队花几天时间来研究 speculative 项目似乎成本很高，但结果可能会让你感到惊讶。我们知道有一个团队通过黑客马拉松，在一年内加速并几乎完成了他们三年的路线图。另一个团队在黑客马拉松上提出了现在可以通过 LLM 实现的颠覆性用户体验，这些用户体验现在已被列为今年及以后的优先事项。

不要陷入“我只需要人工智能工程”的陷阱

随着新工作职位的出现，人们最初倾向于夸大与这些角色相关的功能。当这些工作的实际范围变得清晰时，这通常会导致痛苦的纠正。该领域的新人以及招聘经理可能会做出夸大的断言或抱有过高的期望。过去十年的显著例子包括：

数据科学家：“在统计学方面比任何软件工程师都强，在软件工程方面比任何统计学家都强”的人
机器学习工程师 (MLE)：以软件工程为中心的机器学习视角

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

这种误解在人工智能工程师这个新角色上再次出现，一些团队认为人工智能工程师是万能的。实际上，构建机器学习或人工智能产品需要各种专业角色。我们已经咨询了十几家公司的人工智能产品，并且一直观察到，他们都陷入了“我只需要人工智能工程”的陷阱。因此，由于公司忽略了构建产品所涉及的关键方面，产品往往难以扩展到演示阶段之外。

例如，评估和度量对于将产品扩展到 vibe check 之外至关重要。有效评估的技能与机器学习工程师传统上所具备的一些优势相一致——仅由人工智能工程师组成的团队很可能缺乏这些技能。合著者 Hamel Husain 在他最近关于检测数据漂移和设计特定领域的评估的工作中说明了这些技能的重要性。

以下是构建人工智能产品过程中所需的角色类型以及何时需要这些角色的大致进展：

首先，专注于构建产品。这可能包括人工智能工程师，但并非必须如此。人工智能工程师对于产品的原型设计和快速迭代（用户体验、管道等）非常有价值。
接下来，通过检测系统和收集数据来创建正确的基础。根据数据的类型和规模，你可能需要平台工程师和/或数据工程师。你还必须拥有用于查询和分析这些数据以调试问题的系统。
接下来，你最终会想要优化你的人工智能系统。这不一定涉及训练模型。基础工作包括设计指标、构建评估系统、运行实验、优化 RAG 检索、调试随机系统等。机器学习工程师非常擅长这些工作（尽管人工智能工程师也可以胜任）。除非你已经完成了先决条件，否则通常没有必要雇用机器学习工程师。

除此之外，你还需要一位始终参与其中的领域专家。在小公司，这最好是创始团队——而在大公司，产品经理可以扮演这个角色。了解角色的进展和时间安排至关重要。在错误的时间招聘人员（例如，过早地招聘机器学习工程师) 或以错误的顺序进行构建都是在浪费时间和金钱，并且会导致人员流动。此外，在阶段 1-2 定期与机器学习工程师沟通（但不要全职雇用他们）将有助于公司打下良好的基础。

关于作者

Eugene Yan 设计、构建和运营着为大规模客户提供服务的机器学习系统。他目前是亚马逊的高级应用科学家，负责构建为大规模用户提供服务的推荐系统，并应用 LLM 为客户提供更好的服务。此前，他曾在 Lazada（被阿里巴巴收购）和一家医疗科技 A 轮公司领导机器学习工作。他在 eugeneyan.com 和 ApplyingML.com 上撰写并演讲有关机器学习、推荐系统、LLM 和工程的内容。

Bryan Bischof 是 Hex 的人工智能主管，领导着构建 Magic（数据科学和分析副驾驶）的工程师团队。Bryan 在数据堆栈的各个方面都工作过，领导过分析、机器学习工程、数据平台工程和人工智能工程团队。他在 Blue Bottle Coffee 组建了数据团队，在 Stitch Fix 领导了多个项目，并在 Weights and Biases 组建了数据团队。Bryan 此前与 O’Reilly 合著了《构建生产推荐系统》一书，并在罗格斯大学研究生院教授数据科学和分析课程。他拥有纯数学博士学位。

Charles Frye 教授人们构建人工智能应用程序。在精神药理学和神经生物学领域发表研究论文后，他在加州大学伯克利分校获得了博士学位，其论文研究的是神经网络优化。他曾在 Weights and Biases、Full Stack Deep Learning 和 Modal 从事教育和咨询工作，教授了数千人人工智能应用程序开发的整个堆栈，从线性代数基础知识到 GPU 秘诀，再到构建可防御的业务。

Hamel Husain 是一位拥有超过 25 年经验的机器学习工程师。他曾在 Airbnb 和 GitHub 等创新公司工作，其中包括 OpenAI 使用的早期 LLM 研究,-evaluation%20suite%20where)，用于代码理解。他还领导并贡献了许多流行的开源机器学习工具。Hamel 目前是一位独立顾问，帮助各公司实施大型语言模型 (LLM)，以加速他们的人工智能产品之旅。

Jason Liu 是一位杰出的机器学习顾问，以领导团队成功交付人工智能产品而闻名。Jason 的技术专长涵盖个性化算法、搜索优化、合成数据生成和 MLOps 系统。他的工作经历包括 Stitch Fix 等公司，他在 Stitch Fix 创建了一个推荐框架和可观察性工具，每天处理 3.5 亿个请求。其他职位包括 Meta、纽约大学和 Limitless AI 和 Trunk Tools 等初创公司。

Shreya Shankar 是一位机器学习工程师，也是加州大学伯克利分校的计算机科学博士生。她是两家初创公司的第一位机器学习工程师，从头开始构建了服务于数千名用户的基于人工智能的产品。作为一名研究人员，她的工作重点是通过以人为本的方法来解决生产机器学习系统中的数据挑战。她的作品发表在 VLDB、SIGMOD、CIDR 和 CSCW 等顶级数据管理和人机交互场所。

联系我们

我们很乐意听取你对这篇文章的看法。你可以通过 [email protected] 联系我们。我们中的许多人都乐于接受各种形式的咨询和建议。如果你需要，我们会在你联系我们后，将你引荐给相应的专家。

致谢

这个系列文章起源于群聊中的一次对话，Bryan 在对话中开玩笑说，他受到了启发，想写一篇“人工智能工程的一年”。然后，群聊中就发生了 ✨神奇✨ 的事情，我们都受到了启发，想要贡献自己的力量，分享我们迄今为止的收获。

作者要感谢 Eugene 除了贡献了大量的经验教训之外，还领导了大部分文档集成和总体结构方面的工作。此外，还要感谢他承担了主要的编辑责任和文档指导。作者要感谢 Bryan 激发了这篇文字的创作灵感，将文章重构为战术、运营和战略三个部分及其引言，并促使我们思考如何才能接触到社区并帮助社区。作者要感谢 Charles 对成本和 LLMOps 的深入研究，以及他对经验教训的梳理，使之更加连贯和紧凑——你要感谢他将这篇文章的篇幅控制在 30 页而不是 40 页！作者感谢 Hamel 和 Jason 分享他们从客户那里获得的见解和在一线的经验，感谢他们从客户那里获得的广泛的、可概括的经验教训，以及对工具的深入了解。最后，感谢 Shreya 提醒我们评估和严格的生产实践的重要性，以及她为这篇文字带来的研究和原创成果。

最后，作者要感谢所有团队，感谢你们在自己的文章中如此慷慨地分享你们的挑战和经验教训，我们在本系列文章中引用了这些文章，还要感谢人工智能社区对本小组的积极参与和支持。

好了，分享介绍就到这里，有什么疑问或者问题，可以留言交流哦~ 关注我公众号（设计小站）：sjxz00，获取更多AI辅助设计和设计灵感趋势。