我们开发了一年LLMs产品后学到了什么（第二部分）

许多领导者都曾说过这样一句话，可能有些杜撰：“业余人士谈论战略和战术，专业人士谈论运营。”战术视角看到的是一大堆 独特的 问题，而运营视角看到的是需要修复的组织功能障碍模式。战略视角看到的是机遇，而运营视角看到的是值得迎接的挑战。

在本文的第一部分中，我们介绍了 LLM 工作中的战术要点。在下一部分中，我们将放宽范围以涵盖长期战略考虑。在本部分中，我们将讨论构建 LLM 应用程序的_运营_ 方面，这些应用程序介于战略和战术之间，并为道路提供实际帮助。

运营 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 端点更长。不要以为插入相同的提示会产生类似或更好的结果。此外，拥有可靠的自动化评估有助于在迁移前后衡量任务性能，并减少手动验证所需的工作量。

版本控制和固定模型

在任何机器学习流程中，“改变任何事情都会改变一切”。这一点尤其重要，因为我们依赖大型语言模型 (LLM) 等组件，这些组件我们不会自行训练，而且可能会在我们不知情的情况下发生变化。

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

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

选择能够完成工作的最小型号

在开发新应用程序时，人们很容易使用最大、最强大的模型。但是，一旦我们确定该任务在技术上可行，就值得尝试较小的模型是否能取得类似的结果。

较小模型的好处是延迟和成本更低。虽然它可能较弱，但诸如思路链、n 次提示和上下文学习等技术可以帮助较小模型发挥其最大作用。除了 LLM API 之外，微调我们的特定任务也可以帮助提高性能。

综合起来，使用较小模型精心设计的工作流程通常可以匹敌甚至超越单个大型模型的输出质量，同时速度更快、成本更低。例如，这篇文章分享了 Haiku + 10-shot prompt 如何胜过零样本 Opus 和 GPT-4 的轶事数据。从长远来看，我们希望看到更多使用较小模型进行流程工程的例子，作为输出质量、延迟和成本的最佳平衡。

再举一个例子，以简单的分类任务为例。像 DistilBERT（67M 个参数）这样的轻量级模型是一个令人惊讶的强大基线。400M 参数的 DistilBART 是另一个不错的选择 - 当在开源数据上进行微调时，它可以识别幻觉，ROC-AUC 为 0.84，以不到 5% 的延迟和成本超越大多数 LLM。

重点是，不要忽视较小的模型。虽然很容易将大型模型用于解决每个问题，但只要发挥创造力并进行实验，我们通常就能找到更有效的解决方案。

产品

虽然新技术提供了新的可能性，但打造优质产品的原则是永恒的。因此，即使我们第一次解决新问题，我们也不必在产品设计上重新发明轮子。将我们的 LLM 应用程序开发建立在坚实的产品基础之上，将带来很多好处，使我们能够为我们所服务的人提供真正的价值。

尽早并经常参与设计

拥有一名设计师会促使你理解并深入思考如何构建产品并将其呈现给用户。我们有时会将设计师定型为那些将事物变得漂亮的人。但除了用户界面之外，他们还会重新思考如何改善用户体验，即使这意味着打破现有的规则和范式。

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

专注于问自己：“用户希望这个产品为他们做什么工作？聊天机器人擅长这项工作吗？自动完成怎么样？也许可以做些不同的事情！”考虑现有的设计模式以及它们与待完成工作的关系。这些是设计师为您的团队能力增添的宝贵资产。

为人机交互设计你的用户体验

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

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

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

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

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

编码助手：用户可以接受建议（强烈积极）、接受并调整建议（积极）或忽略建议（消极）
旅途中：用户可以选择放大并下载图像（强正片）、改变图像（正片）或生成一组新图像（负片）
聊天机器人：用户可以对回复表示赞同（积极）或反对（消极），或者如果回复非常糟糕（强烈反对），可以选择重新生成回复

反馈可以是显式的，也可以是隐式的。显式反馈是用户响应我们产品的请求而提供的信息；隐式反馈是我们从用户交互中了解到的信息，不需要用户刻意提供反馈。编码助手和 Midjourney 是隐式反馈的例子，而竖起大拇指和竖起大拇指则是显式反馈。如果我们设计好我们的用户体验，就像编码助手和 Midjourney 一样，我们可以收集大量隐式反馈来改进我们的产品和模型。

严格按照需求层次划分优先顺序

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

可靠性：99.9% 正常运行时间，遵守结构化输出
无害性：不会生成冒犯性、不适合工作场所或其他有害内容
事实一致性：忠实于提供的背景，不编造事实
实用性：与用户的需求和要求相关
可扩展性：延迟 SLA、支持的吞吐量
成本：因为我们的预算有限
还有：安全、隐私、公平、GDPR、DMA 等。

如果我们试图一次性解决所有这些要求，我们将永远无法交付任何东西。因此，我们需要确定优先次序。毫不留情。这意味着要明确哪些是不可协商的（例如，可靠性、无害性），没有这些，我们的产品就无法运行或不可行。这一切都是为了确定最低限度的可爱产品。我们必须接受第一个版本不会是完美的，然后发布和迭代。

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

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

这与a16z最近的一份报告一致，该报告显示，许多公司在内部 LLM 应用程序方面的发展速度比外部应用程序更快。通过尝试使用 AI 来提高内部生产力，组织可以开始获取价值，同时学习如何在更受控制的环境中管理风险。然后，随着他们获得信心，他们可以扩展到面向客户的用例。

团队与角色

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

关注流程，而不是工具

当面对新范式（例如 LLM）时，软件工程师倾向于使用工具。结果，我们忽略了工具本应解决的问题和流程。这样一来，许多工程师就认为存在偶然的复杂性，这会对团队的长期生产力产生负面影响。

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

除了偶然的复杂性之外，工具通常还不够完善。例如，LLM 评估工具行业正在不断发展，它们提供“LLM 评估盒”，其中包含针对毒性、简洁性、语气等的通用评估器。我们已经看到许多团队采用这些工具，而没有认真考虑其领域的具体故障模式。与 EvalGen 形成鲜明对比。它专注于通过让用户深入参与从指定标准到标记数据再到检查评估的每个步骤来教用户创建特定领域评估的过程。该软件引导用户完成如下工作流程：

Shankar, S. 等人 (2024)。谁来验证验证器？将 LLM 辅助评估与人类偏好相结合。取自 https://arxiv.org/abs/2404.12272

EvalGen 指导用户制定 LLM 评估的最佳实践，即：

定义特定领域的测试（从提示中自动引导）。这些测试被定义为带有代码的断言或使用 LLM-as-a-Judge 的断言。
将测试与人类判断相结合非常重要，这样用户可以检查测试是否符合指定的标准。
随着系统（提示等）的变化，对测试进行迭代。

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

除了即时写作和评估之外，LLM还有太多组成部分，无法在此详尽列出。然而，人工智能工程师在采用工具之前，务必了解流程。

不断尝试

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

由于现在实验成本低廉，因此尝试不同的方法来解决同一问题很常见。收集数据和训练模型的高成本被最小化——快速工程的成本几乎只比人力成本高一点。让您的团队定位，让每个人都了解快速工程的基础知识。这鼓励每个人进行实验，并导致整个组织产生不同的想法。

此外，不要只进行实验以探索，也要利用它们来开发！有新任务的工作版本吗？考虑让团队中的其他人以不同的方式处理它。尝试另一种更快的方法。研究诸如思维链或少量样本之类的提示技术，以提高质量。不要让你的工具阻碍你进行实验；如果是这样，请重建它，或购买一些东西来使其变得更好。

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

让每个人都能使用新的 AI 技术

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

这其中很大一部分是教育。它可以从简单的即时工程基础知识开始，其中 n-shot prompting 和 CoT 等技术有助于将模型调整为所需的输出。具有相关知识的人还可以教育更多技术方面，例如 LLM 本质上是自回归的。换句话说，虽然输入 token 是并行处理的，但输出 token 是顺序生成的。因此，延迟更多地取决于输出长度而不是输入长度——这是设计 UX 和设定性能预期时的一个关键考虑因素。

我们还可以更进一步，提供动手实验和探索的机会。也许是黑客马拉松？虽然让整个团队花几天时间对投机项目进行黑客攻击似乎很昂贵，但结果可能会让您感到惊讶。我们知道一个团队通过黑客马拉松加速并几乎在一年内完成了他们的三年路线图。另一个团队的黑客马拉松导致了范式转变的用户体验，这现在得益于 LLM，现在是今年及以后的优先事项。

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

随着新职位的出现，人们最初倾向于夸大这些职位的能力。随着这些职位的实际范围逐渐清晰，这通常会导致痛苦的纠正。该领域的新手以及招聘经理可能会做出夸大的说法或抱有过高的期望。过去十年中值得注意的例子包括：

数据科学家：“比任何软件工程师都更擅长统计，比任何统计学家都更擅长软件工程的人”
机器学习工程师（MLE）：以软件工程为中心的机器学习观点

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

这种误解在 AI 工程师这一新角色出现后再次显现，一些团队认为 AI 工程师就是一切。实际上，构建机器学习或 AI 产品需要一系列专业角色。我们为十多家 AI 产品公司提供咨询，并不断观察到他们陷入了“AI 工程就是一切”的陷阱。因此，由于公司忽视了构建产品所涉及的关键方面，产品往往难以扩展到演示之外。

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

以下是在构建 AI 产品的过程中您需要的角色类型以及何时需要它们的基本情况：

首先，专注于打造产品。这可能包括一名人工智能工程师，但这不是必须的。人工智能工程师对于产品原型设计和快速迭代（用户体验、管道等）很有价值。
接下来，通过检测系统和收集数据来创建正确的基础。根据数据的类型和规模，您可能需要平台和/或数据工程师。您还必须拥有用于查询和分析这些数据以调试问题的系统。
接下来，您最终将需要优化您的 AI 系统。这不一定涉及训练模型。基本步骤包括设计指标、构建评估系统、运行实验、优化 RAG 检索、调试随机系统等。MLE 在这方面非常擅长（尽管 AI 工程师也可以学习它们）。除非您已完成先决条件步骤，否则聘请 MLE 通常没有意义。

除此之外，您始终都需要一名领域专家。在小公司，理想情况下，创始团队是该领域的专家，而在大公司，产品经理可以扮演这一角色。了解角色的进展和时间至关重要。在错误的时间雇佣员工（例如，过早雇佣 MLE）或以错误的顺序进行构建会浪费时间和金钱，并导致员工流失。此外，在第 1-2 阶段定期与 MLE 进行沟通（但不要全职雇佣他们）将有助于公司建立正确的基础。

关于作者

Eugene Yan设计、构建和运营机器学习系统，为大规模客户提供服务。他目前是亚马逊的高级应用科学家，负责构建 RecSys 为大规模用户提供服务，并应用 LLM 更好地为客户服务。此前，他曾领导 Lazada（被阿里巴巴收购）的机器学习和 Healthtech A 轮融资。他在 eugeneyan.com和ApplyingML.com上撰写和演讲有关 ML、RecSys、LLM 和工程的文章。

Bryan Bischof是 Hex 的 AI 主管，他领导工程师团队开发 Magic — 数据科学和分析副驾驶。Bryan 曾在数据堆栈的各个领域工作，领导分析、机器学习工程、数据平台工程和 AI 工程团队。他创办了 Blue Bottle Coffee 的数据团队，领导了 Stitch Fix 的多个项目，并组建了 Weights and Biases 的数据团队。Bryan 之前曾与 O'Reilly 合著《构建生产推荐系统》一书，并在罗格斯大学研究生院教授数据科学和分析学。他的博士学位是纯数学。

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

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

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

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

联系我们

我们很乐意听听您对这篇文章的想法。您可以通过contact@applied-llms.org联系我们。我们中的许多人都愿意接受各种形式的咨询和建议。如果合适，我们会在联系后将您转介给合适的专家。

致谢

本系列始于群聊中的对话，布莱恩打趣说他受到启发写了《人工智能工程的一年》。然后，群聊中发生了✨神奇✨，我们都受到启发，纷纷参与进来，分享我们迄今为止学到的东西。

作者要感谢 Eugene 领导了大部分文档集成和整体结构以及大部分课程。此外，还要感谢他承担了主要的编辑职责和文档指导。作者要感谢 Bryan 激发了我们撰写这篇文章，将文章重组为战术、运营和战略部分及其简介，并促使我们更深入地思考如何接触和帮助社区。作者要感谢 Charles 对成本和 LLMOps 的深入研究，以及编织课程以使其更加连贯和紧凑——感谢他让这篇文章只有 30 页而不是 40 页！作者感谢 Hamel 和 Jason 从为客户提供建议和身处第一线的见解、从客户那里获得的广泛可推广的学习以及对工具的深入了解。最后，感谢 Shreya 提醒我们评估和严格的生产实践的重要性，并将她的研究和原创成果带到这篇文章中。

最后，作者要感谢所有团队慷慨地在我们在本系列中引用的文章中分享你们面临的挑战和经验教训，也要感谢人工智能社区对这个小组的积极参与和投入。

原文地址：What We Learned from a Year of Building with LLMs (Part II) – O’Reilly

内容由MiX Copilot基于大语言模型生成，有可能存在错误的风险。