作者： Eugene Yan, Bryan Bischof, Charles Frye, Hamel Husain, Jason Liu & Shreya Shankar
原作发布日期：May 31, 2024
翻译：ian
最后修订日期：2024年10月5日
有一句伪名人名言如此说道：“业余人士谈论战略和战术。专业人士谈论运作。” —— 江湖传闻此言出自多名领袖。战术视角看到的是一系列 独特的 难题，而运作[1]视角则看到的是需修复的组织功能障碍的模式。战略视角看到的是机遇，运作视角看到的是值得迎接的挑战。
在本文的第一篇章，我们介绍了使用 LLMs（大型语言模型）的战术细节[2]。在下一部分，我们将放大视野，涵盖长期的战略考虑。而在这一部分，我们将讨论构建LLM应用的运作层面，这些层面介于战略和战术之间，将理论与实践相结合。
运作LLM应用会引发一些与传统软件系统相似的问题，但通常带有新颖的转折，让事情变得有趣。LLM应用带来了全新的问题。我们将这些问题及其答案分为四个部分：数据、模型、产品和人员。
对于数据，我们来解答：你应该如何以及多久审查一次LLM的输入和输出？你如何衡量和减少测试与生产之间的偏差？
对于模型，我们来解答：你如何将语言模型整合到整个技术栈中？你应该如何考虑模型的版本控制以及在模型和版本之间迁移？
对于产品，我们来解答：设计应该在应用开发过程中何时介入，为什么是“尽可能早”？你如何设计包含丰富人机交互反馈的用户体验？你如何处理众多相互冲突的需求的来优先度？你如何校准产品风险？
最后，对于人员，我们来解答：你应该雇佣谁来构建一个成功的LLM应用，以及何时雇佣他们？你如何培养一种实验性的文化？你应如何利用新兴的LLM应用来构建你自己的LLM应用？过程和工具哪个更为关键？
作为一个AI语言模型：我没有个人主张，因此无法告诉你你提供的这篇介绍是“绝妙还是一般”。但我可以说，此文恰当地为后续内容搭好了台阶。[3]
运作篇：日常事务与组织关注之焦点
数据
正如食材的质量决定菜肴的口味一样，输入数据的质量也制约着机器学习系统的性能。此外，输出数据是判断产品是否正常运作的唯一途径。所有创作者都紧密关注数据，每周花费数小时审视输入和输出数据，以更好地理解数据分布：其模式、临界情况、以及模型的局限性。
检查“开发-生产”之间的偏差
在传统的机器学习Pipeline中，一个常见的错误来源是训练-服务偏差。这种情况发生在训练数据与模型在产品阶段遇到的数据不同的时候。虽然我们可以直接使用LLMs而不进行训练或微调，不需要训练数据集，但类似的“开发-生产”数据偏差引发的问题仍然存在。本质上，我们在开发过程中测试系统所用的数据应该反映系统在产品阶段将面临的数据；否则，我们可能会发现在生产环境中的准确性受到了影响。
LLM的开发-生产偏差可以分为两种类型：结构性的和内容性的。结构性偏差包括了诸如格式差异问题等，例如：一个带有列表类型值的 JSON 字典和一个 JSON 列表之间的差异、大小写不一致、以及拼写错误或句子片段等错误。这些错误可能导致模型性能不可预测，因为不同的LLMs是针对特定的数据格式进行训练的，而提示对微小的变化非常敏感。内容性或“语义”偏差指的是数据表达的含义不同、或所处的上下文语境不同。
与传统的机器学习一样，阶段性评测 LLM 输入/输出对之间的偏差是有用的。简单的指标，如输入和输出的长度、或特定的格式要求（例如 JSON 或 XML），都是跟踪变化的直接手段。对于更“高级”的偏移检测，则可以考虑对输入/输出对的Embedding进行聚类，以检测语义偏移，例如用户讨论主题的变化，可能表明他们在探索模型之前未触碰过的领域。
在测试变化时，例如在提示工程中，要确保保留的数据集是最新的，并反映最新的用户交互类型。例如，如果产品使用过程经常发生拼写错误，那这些错误也应该出现在保留的数据中。除了定量的偏差测量之外，对输出进行定性评估也是有帮助的。应定期审查模型的输出 —— 俗称“情境检查” —— 以确保结果符合预期，且保持了对用户需求的匹配。最后，将非确定性纳入偏差检查也是有用的 —— 可对测试数据集中的每一条输入通过多次运行Pipeline来分析所有输出，从而提升捕捉到那些偶尔才出现的异常的几率。
每天查看 LLM 输入和输出的样本
LLMs正在持续进化，是动态的。尽管它们具有令人印象深刻的零样本(zero-shot)[4]能力，并且其输出往往令人愉悦，但它们出错也极难预测。对于定制任务，定期审查数据样本对于培养对LLMs性能的直观理解至关重要。
来自生产环境的“输入-输出对”是 LLM 应用的"现地现物"（genchi genbutsu[5]），它们是不可替代的。最近的研究强调，随着开发者与更多数据的交互，他们对“好”和“坏”输出的认知会发生变化（即标准漂移）。虽然开发者可以预先制定一些评估 LLM 输出的标准，但这些预定义的标准往往是不完备的。例如，在开发过程中，我们可能会更新提示以增加好的响应的概率并减少坏的响应的概率。这种评估、重新评估和更新标准的迭代过程是必要的，因为不直接观察输出，就很难预测 LLM 的行为或人类的偏好。
为了有效管理这一点，我们应该记录 LLM 的输入和输出。通过每天检查这些日志的样本，可以快速识别并适应新的模式或出错的规律。当发现新问题时，可以立即围绕它编写断言或评估。同样，任何对出错模式的定义的更新都应反映到评估标准中。这些“氛围检查”是产生不良输出的指示信号；可用代码和断言来处理这些信号。最后，这种管理方式须推广开来，例如，将输入和输出的复盘或备注工作添加到每个人的流程中。
与模型协作
通过LLM API，我们可以依赖少数供应商提供的智能能力。虽然这是一个福音，但这些依赖也涉及到性能、延迟、吞吐量和成本的权衡。此外，随着更新、更好的模型不断推出（过去一年几乎每个月都有），我们应该准备好更新我们的产品，淘汰旧模型并迁移到新模型。在这一部分，我们将分享我们在无法完全控制的技术基础上展开工作的经验，也即，当我们无法私有部署和掌控这些模型的时候，如何展开工作。
生成结构化输出以简化下游集成
对于大多数现实世界的用例，LLM的输出将通过某种机器可读的格式被下游应用程序使用。例如，Rechat，一个房地产CRM，需要结构化的响应以便前端渲染部件。同样，Boba，一个用于生成产品战略思路的工具，需要带有标题、摘要、合理性评分和时间范围等字段的结构化输出。还有，LinkedIn分享了关于约束LLM生成YAML的内容，这些YAML用于决定使用的哪项技能，及调用技能的参数。
这种应用模式是Postel定律[6]的一个极端版本：在接受（任意自然语言）时要宽松，在发送（类型化的机器可读对象）时要保守。因此，我们预计这个策略面对变化能够长期保持有效和可靠。[7]
目前，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端点花费更多时间。不要假设插入相同的提示会导致相似或更好的结果。此外，拥有可靠的自动化评估有助于在迁移前后测量任务性能，并减少手动验证所需的努力。
做好版本控制并锁定模型
在任何机器学习的管道(Pipeline)中，“改变任何东西都会改变一切”。这一点在我们不训练自己的模型，而是依赖（供应商提供的）大语言模型时尤为相关，那些模型可能在我们不知情的情况下发生变化。
幸运的是，许多模型提供商提供了“锁定”指定模型版本（例如，gpt-4-turbo-1106）的选项。这使我们能够使用特定版本的模型权重，确保它们保持不变。在生产中锁定模型版本可以帮助避免模型行为产生意外的变化，这可能导致客户投诉，例如在更换模型后出现的过于冗长的输出或其他未预见的错误。
此外，可以考虑维护一个和生产设置一致但使用最新模型版本的影子管道（shadow pipeline），可以安全地使用新版本进行实验和测试。一旦你验证了这些较新模型的输出稳定性和质量，你就可以自信地在生产环境中更新模型版本。
选择能完成任务的最小模型
在开发新应用时，使用最大、最强大的模型是很诱人的。但一旦我们确定任务在技术上是可行的，就值得实验一下是否可以用较小的模型达到类似的结果。
较小的模型的好处是延迟和成本更低。虽然它可能较弱，但像思维链、n轮提示和上下文学习这样的技术可以帮助较小的模型发挥超出其能力的性能。除了LLM API之外，对我们的特定任务进行微调也可以帮助提高性能。
综合来看，使用较小的模型精心设计的流程往往可以匹配甚至超过单个大模型的输出质量，同时速度更快、成本更低。例如，这篇帖子分享了Haiku + 10-shot提示如何超过zero-shot提示的Opus和GPT-4的轶事。长期来看，我们预计会看到更多使用较小模型的流程工程(flow-engineering)的例子，作为输出质量、延迟和成本的最佳平衡。
再举一个例子，考虑简单的分类任务。像DistilBERT（6700万个参数）这样的轻量级模型是一个出人意料的强大基线。4亿参数的DistilBART是另一个很好的选择 —— 当在开源数据集上进行微调时，它可以以0.84 ROC-AUC识别幻觉，[8]超过了大多数LLM，而延迟和成本不到5%。
关键点就是，不要忽视较小的模型。虽然很容易对每个问题都使用一个巨大的模型，但通过一些创新和实验，我们通常可以找到一个更高效的解决方案。
产品
虽然新技术带来了新的可能性，但打造优秀产品的基本原则是永远不会过时的。因此，即使我们第一次遇到新问题，我们也不必在产品设计上重新发明轮子。将我们的LLM应用开发建立在坚实的产品基础之上，可以让我们为所服务的人们提供真正的价值。
尽早并经常地引入设计
拥有一个设计师会推动你深入理解和思考如何构建和向用户展示你的产品。我们有时将设计师刻板地视为那些把东西变得漂亮的人。但除了用户界面之外，他们还会重新思考如何改进用户体验，即使这意味着打破现有的规则和范式。
设计师尤其擅长将用户需求重新包装成不同的形态。其中一些形式比其他形式更容易（通过AI）得到解决，因此，它们可能为AI解决方案提供或多或少的机会。与其他许多产品一样，构建AI产品应该围绕着要完成的任务，而不是驱动它们的技术。
应多问问自己：“用户要求这个产品为他们做什么？这个任务是聊天机器人擅长的吗？如果自动完成会怎么样？也许还有其他什么！”考虑现有的设计模式以及它们与要完成的任务之间的关系。这些都是设计师能为你的团队能力增加的无价资产。
为“Human-in-the-Loop”[9]设计你的用户体验
有一种获得高质量的标注的方法是将 HITL 集成到用户体验（UX）中。通过允许用户轻松地提供反馈和更正，我们可以改进即时输出并收集有价值的数据来改进我们的模型。
想象一个用户上传和分类他们产品的电子商务平台。我们可以设计几种不同的用户体验：
- 用户手动选择正确的产品类别；LLM定期检查新产品并在后台纠正分类错误。
- 用户不选择任何类别；LLM定期在后台对产品进行分类（可能存在错误）。
- LLM实时建议产品类别，用户可以验证并根据需要更新。
虽然所有三种方法都涉及LLM，但它们提供了非常不同的用户体验。第一种方法将初始负担放在用户身上，LLM作为后处理检查。第二种方法不需要用户付出任何努力，但不提供透明度或控制。第三种方法找到了正确的平衡。通过让LLM提前建议类别，我们减少了用户的认知负荷，他们不需要学习我们的分类法来分类他们的产品！同时，通过允许用户审查和编辑建议，他们在产品的分类上有最终决定权，将控制权牢牢掌握在他们手中。第三种方法创建了一个自然的模型改进反馈循环作为模型反馈的奖励机制：好的建议被接受（正面标签），坏的建议被更新（负面之后尾随正面标签）。
这种建议、用户验证和数据收集的模式在几种应用中很常见：
- 编码助手：用户可以接受建议（强正面），接受并调整建议（正面），或忽略建议（负面）
- Midjourney：用户可以选择放大并下载图像（强正面），改变图像（正面），或生成一组新的图像（负面）
- 聊天机器人：用户可以对回复点赞（正面）或踩（负面），或者如果回复真的很糟糕，可以选择重新生成回复（强负面）
反馈可以是显性的也可以是隐性的。显性反馈是用户在产品请求后提供的信息；隐性反馈是我们从用户交互中学习到的信息，而不需要用户故意提供反馈。编码助手和Midjourney是隐性反馈的例子，而点赞和踩是显性反馈。如果我们设计好我们的用户体验，比如编码助手和Midjourney，我们可以收集大量的隐性反馈来改进我们的产品和模型。
无情地优先考虑你的需求层次
当我们考虑将我们的演示投入运行时，我们必须考虑以下要求：
- 可靠性：99.9%的正常运行时间，遵守结构化输出
- 无害性：不生成攻击性、NSFW[10]或其他有害内容
- 事实一致性：忠实于提供的上下文，不编造事实
- 有用性：与用户的需求和请求相关
- 可扩展性：延迟服务级别协议，支持的吞吐量
- 成本：因为我们没有无限的预算
- 更多：安全性、隐私、公平性、GDPR、DMA等
如果我们试图同时解决所有这些要求，我们将永远无法发布任何东西。因此，我们需要无情地进行优先选择。这意味着要清楚什么是不可商量的（例如，可靠性、无害性），没有这些我们的产品就无法运行或不可行。关键在于找到最小可行产品（MVP）。我们必须接受第一版不会完美，只需不断发布并迭代去改善它。
根据用例校准你的风险承受能力
在决定语言模型和应用程序的审查级别时，要考虑用例和受众。对于提供医疗或财务建议的面向客户的聊天机器人，我们需要非常高的安全性和准确性标准。错误或不良输出可能会造成实际伤害并侵蚀信任。但对于不太关键的应用程序，如推荐系统，或面向内部的应用程序，如内容分类或摘要，过度的严格要求只会减缓进度而不会增加太多价值。
这与最近的a16z报告一致，该报告显示许多公司在内部LLM应用程序上比外部应用程序发展得更快。通过实验使用AI提高内部生产力，组织可以在更受控的环境中学习如何管理风险的同时开始获取价值。然后，随着他们获得信心，他们可以扩展到面向客户的用例。
团队与角色
没有哪个职位的功能是容易定义的，但相比其他的职位，在这个新的领域描述职位则更具挑战性。我们将避免使用交叠的职位标题的文氏图，或职位描述的建议。然而，我们将提出一个新的角色 —— AI工程师 —— 的存在，并讨论它的定位。重要的是，我们将讨论其余的团队以及如何进行职能分配。
关注流程，而非工具
面对新范式，比如大语言模型（LLMs），软件工程师往往倾向于依赖工具。这样一来，我们忽略了工具原本要解决的问题和过程。许多工程师因此承担了不必要的复杂性，这对团队的长期生产力产生了负面影响。
例如，这篇博文探讨了某些工具如何自动为大型语言模型生成提示。它认为（在我看来是正确的），那些不先理解问题解决方法或流程就使用这些工具的工程师，最终会担负不必要的技术债。
除了偶然的复杂性，工具往往还不能满足一些特定领域。例如，现在有一个不断壮大的行业，提供“一站式LLM评估工具”，这些工具提供通用的评估器，用于检测有害性、简洁性、语气等。我们见过许多团队在不深入思考其在一些特定领域的失效状况的情况下就采用了这些工具。相比之下，EvalGen则专注于教导用户如何创建特定领域的评估，通过深入参与每个步骤，从制定标准、标注数据到检查评估，全程引导用户。软件引导用户完成的工作流程如下：
EvalGen引导用户通过一套“最佳实践”来制定LLM评估，即：
- 域测试的定义（从提示词自动引导）。这些测试可以定义为代码断言或使用LLM作为判断。
- 测试与人类判断的一致性至关重要，这样用户可以确认测试是否符合指定的标准。
- 随着系统（提示等）的变化迭代测试。
EvalGen为开发者提供了一个评估构建过程的思路模型，而不将他们锚定在特定的工具上。我们发现，在提供了这个套路之后，AI工程师通常会选择更精简的工具或构建自己的工具。
大语言模型（LLMs）的组成部分远不止提示词编写和评估那么简单，这里无法一一列举。然而，重要的是，AI工程师在采用这些工具之前，应努力理解其背后的流程。
永远保持尝试
机器学习产品与实验密不可分。不仅仅是A/B测试、随机对照试验这类，还包括频繁尝试修改系统中最小的组件并进行离线评估。大家如此热衷于评估，其实并不是为了信任度和信心 —— 而是为了推动实验！评估做得越好，实验迭代就越快，从而能更快地找到系统的最佳版本。
现在尝试不同方法解决同一个问题很常见，因为实验成本很低。收集数据和训练模型的成本大大降低——提示工程的成本几乎只相当于人力时间。让团队中的每个人都掌握提示工程的基础知识，这样能鼓励大家进行实验，从而在整个组织中产生多样化的想法。
另外，不要只为了探索而实验 —— 也要利用它们来发挥优势！有了新任务的工作版本？考虑让团队中的其他人以不同的方式处理它，尝试另一种更快的方法，研究像思维链或few-shot这样的提示技巧，以提高质量。不要让你的工具限制了你的实验；如果有，那就重构它，或者买个更好的。
最后，在产品阶段或项目规划阶段，要预留时间进行评估构建和多次实验。可以将其视为工程产品的规格说明，但要在此基础上增加明确的评估标准。在制定路线图时，不要低估实验所需的时间 —— 在获得生产许可之前，需要进行多次开发和评估的迭代，应将此纳入预期。
鼓励每个人使用新的AI技术
随着生成式AI的普及，我们需要整个团队 —— 不仅仅是专家 —— 都能理解和感受到使用这项新技术的力量。没有什么比亲自使用更能培养对大型语言模型（如延迟、故障模式、用户体验）工作原理的直观感受了。大型语言模型相对容易上手：你不需要懂得编程就能优化一个流程的性能，每个人都可以通过提示工程和评估来开始贡献。
教育培训在这其中占据了很大一部分。可以从简单的提示工程基础开始，比如使用n-shot提示和思维链（CoT）等技巧来引导模型输出期望的结果。具备更多知识的人还可以传授一些更技术性的内容，比如大语言模型（LLM）本质上是自回归的。换句话说，虽然输入的词元是并行处理的，但输出的词元是按顺序生成的。因此，延迟更多取决于输出长度而非输入长度 —— 这在设计用户体验和设定性能预期时是一个关键考虑因素。
我们还可以更进一步，提供动手实验和探索的机会。比如举办一个黑客松？虽然让整个团队花几天时间在模拟项目上可能看起来成本高昂，但结果可能会让你大吃一惊。我们知道有一个团队通过黑客松，在一年内加速并几乎完成了他们原本三年的路线图。还有个团队的黑客松，因LLMs则带来了用户体验上的全新颠覆，这种全新的用户体验范式被列为了今年及以后的重点。
别掉进“AI工程就是一切”的陷阱
随着新职位的涌现，起初人们往往会夸大这些角色的能力。这通常会导致一个痛苦的修正过程，因为这些工作的实际范围变得清晰。无论是新入行者还是招聘经理，都可能做出夸大的声明或抱有不切实际的期望。过去十年中，有几个著名的案例，请参考：
- Data scientist: “someone who is better at statistics than any software engineer and better at software engineering than any statistician”
- Machine learning engineer (MLE): a software engineering-centric view of machine learning
起初，许多人以为数据科学家单独就能搞定数据驱动项目。然而，后来大家明白过来，数据科学家得跟软件工程师和数据工程师联手，才能高效地开发和部署数据产品。
这种误解在新兴的AI工程师角色中再次出现，有些团队认为AI工程师就是一切。实际上，构建机器学习或AI产品需要广泛的专业角色。我们与十几家公司就AI产品进行了咨询，并持续观察到他们陷入了“AI工程就是一切”的陷阱。因此，实际产品往往难以超越演示阶段，因为公司在构建产品时忽略了关键方面。
例如，评估和衡量对于将产品扩展到超越直觉检查的阶段至关重要。有效评估所需的技能与机器学习工程师传统上所具备的一些优势相吻合 —— 一个完全由 AI 工程师组成的团队可能会缺乏这些技能。合著者Hamel Husain在他最近关于检测数据漂移(data drift)和设计特定领域评估的工作中，阐明了这些技能的重要性。
以下是在构建AI产品的过程中，您需要的各种角色的大致安排，以及您何时需要这些角色：
- 首先，专注于产品构建。这可能包括一名AI工程师，但并非必须。AI工程师在快速原型设计和迭代产品（用户体验、基础架构等）方面非常有价值
- 接着, 通过仪器化(instrumenting)[11]你的系统并收集数据来建立正确的基石。根据数据的类型和规模，你可能需要平台工程师和/或数据工程师。你还必须拥有查询和分析这些数据的系统，以便调试问题。
- 然后，你最终会希望优化你的AI系统。这不一定涉及训练模型。基础步骤包括设计指标、构建评估系统、运行实验、优化RAG检索、调试随机系统等。机器学习工程师（MLEs）在这方面非常擅长（尽管AI工程师也能掌握这些技能）。通常，如果你尚未完成必要的前期工作，雇佣一名 MLE 是没有意义的。
除此之外，你始终需要一位领域专家。在小公司，理想情况下这应该是创始团队——而在大公司，产品经理可以扮演这个角色。了解角色发展和时机至关重要。在不恰当的时机招聘人员（例如，过早招聘了机器学习工程师 ）或按错误的顺序构建，都是浪费时间和金钱，还会导致人员流动。此外，在第1至2阶段，定期与机器学习工程师沟通（但不必全职聘用他们）将有助于公司打下正确的基础。
关于作者
Eugene Yan 设计、构建和运营为大规模客户服务的机器学习系统。他目前是亚马逊的高级应用科学家，在亚马逊他构建了服务于全球数百万客户的推荐系统RecSys 2022主题演讲，并应用LLM来更好地服务客户AI Eng Summit 2023主题演讲。此前，他在Lazada（被阿里巴巴收购）和一家医疗科技 A 轮公司领导机器学习工作。他在eugeneyan.com和ApplyingML.com上撰写和讨论有关ML、RecSys、LLM和工程的内容。
Bryan Bischof 是 Hex 的 AI 负责人，他领导着一支工程师团队构建 Magic —— 一个数据科学和分析的Copilot应用。Bryan在数据相关技术栈的各个领域都有工作经验，领导过分析、机器学习工程、数据平台工程和AI工程团队。他在 Blue Bottle Coffee 创建了数据团队，在 Stitch Fix 领导了几个项目，并在 Weights and Biases 构建了数据团队。Bryan 此前与 O’Reilly 合著了《构建产品推荐系统》一书，并在罗格斯大学研究生院教授数据科学和分析。他的博士学位是纯数学。
Charles Frye 教人们构建AI应用。在发表了精神药理学和神经生物学的研究成果后，他在加州大学伯克利分校获得了博士学位，研究方向为神经网络优化。他已经教授了数千人 AI 应用开发的全栈知识，从线性代数基础到GPU的深奥知识，以及构建可防御的业务，并在Weights and Biases、Full Stack Deep Learning 和 Modal 从事教育和咨询工作。
Hamel Husain 是一位拥有超过25年经验的机器学习工程师。他曾在 Airbnb 和 GitHub 等创新公司工作，其中包括一些早期的LLM研究被 OpenAI 采用，用于代码理解。他还领导并贡献了许多流行的开源机器学习工具。Hamel 目前是一名独立顾问，帮助公司将大型语言模型（LLMs）投入运营，以加速他们的AI产品开发进程。
Jason Liu 是一位杰出的机器学习顾问，以领导团队成功交付AI产品而闻名。Jason 的技术专长涵盖个性化算法、搜索优化、合成数据生成和 MLOps 系统。他的经验包括在 Stitch Fix 等公司工作，在那里他创建了一个推荐框架和可观测性工具，每天处理3.5亿次请求。他还在Meta、纽约大学以及 Limitless AI 和 Trunk Tools 等初创公司担任过其他职务。
Shreya Shankar 是加州大学伯克利分校的机器学习工程师和计算机科学博士生。她是两家初创公司的第一位机器学习工程师，从零开始构建每日服务于数千用户的AI驱动产品。作为研究员，她的工作专注于通过以人为中心的方法解决生产环境中机器学习系统的数据挑战。她的研究成果已在VLDB、SIGMOD、CIDR和CSCW等顶级数据管理和人机交互会议上发表。
联系我们
我们非常希望收到您对这篇文章的想法。您可以通过 contact@applied-llms.org 与我们联系。我们中的许多人都愿意提供各种形式的咨询和建议。如果合适的话，我们会在您与我们联系后将您转介给相应的专家。
致谢
这个系列文章始于一次群聊中的对话，Bryan 开玩笑说他受到启发要写"一年的 AI 工程"。然后，✨魔法✨在群聊中发生了，我们都受到启发，决定一起贡献并分享我们迄今为止所学到的东西。
作者们感谢 Eugene 领导了文档整合和整体结构的大部分工作，以及大部分课程内容。此外，还要感谢他承担主要编辑责任和文档方向。作者们感谢 Bryan 提供了促成这篇文章的灵感，将文章重组为战术、运营和战略部分及其介绍，并推动我们思考如何更好地接触和帮助社区。作者们感谢 Charles 对成本和 LLMOps 的深入探讨，以及将课程编织得更加连贯和紧凑 —— 你应该感谢他让这篇文章只有30页而不是40页！作者们感谢 Hamel 和 Jason 从客户咨询和前线工作中获得的洞见，从客户那里学到的广泛可推广的知识，以及对工具的深入了解。最后，感谢 Shreya 提醒我们评估和严格生产实践的重要性，并将她的研究和原创成果带入这篇文章。
最后，作者们感谢所有在文章中慷慨分享挑战和经验教训的团队，我们在整个系列中都引用了这些内容，同时也感谢 AI 社区对本团队的积极参与和互动。
译注
“Operation/Operating”在中文语境中，有多种翻译，包括：操作，运营等。考虑到“运营”在中文语境中，一般特指经营一个系统或平台软件，而“操作”则更侧重于执行具体任务。而本文的内容涵盖了从数据准备到人员团队的与LLMs相关的全生命周期，因此，本文根据上下文语境，将之翻译为“运作”。 ↩︎
“tactical nuts and bolts of working with LLMs” 指的是使用大型语言模型（LLMs）时需要掌握的具体操作和细节。“nubs and bolts”原为机械装置的螺母与螺帽等基本零件，引申为问题的关键点和细节，是一个英语常用短语。 ↩︎
此处，作者模拟一个大语言模型的口吻来评价这篇文章，揭示了这篇文章是为下一篇文章作出了铺垫。 ↩︎
"Zero-shot"是一种机器学习中的技术，意思是让计算机在没有见过某个特定例子的情况下，也能理解和处理这个例子。 ↩︎
“Genchi genbutsu” 的日语写法是「現地現物（ゲンチ ゲンブツ）」，意思是：当你遇到问题时，不要只坐在办公室里猜测或听别人说，而是要亲自去问题的发生地点，亲眼看看实际情况，这样才能真正了解问题，找到最好的解决办法，通常用于强调在解决问题或做出决策时，亲自到现场去观察实际情况的重要性。 ↩︎
Postel定律，也称为鲁棒性原则（Robustness Principle），是由互联网早期先驱Jon Postel提出的一个软件设计指南。该定律的核心思想是：“在你发送的内容上要保守，在你接收的内容上要开放。” 具体来说，这意味着软件在发送数据时应严格遵循协议规范，而在接收数据时则应尽可能宽容，即使数据不完全符合规范也应尝试处理。Postel定律的主要目的是提高系统的鲁棒性和兼容性，使得不同系统之间的通信更加稳定和可靠。然而，这一原则也有其争议，特别是在安全性和协议僵化（Protocol Ossification）方面。一些人认为，过于宽容的接收可能会导致安全漏洞，因为系统可能会无意中处理恶意数据。Postel定律是一个在软件设计中平衡兼容性和安全性的重要原则，但在实际应用中需要谨慎权衡其利弊。 ↩︎
此处为意译。原文是：As such, we expect it to be extremely durable。 ↩︎
ROC-AUC（Receiver Operating Characteristic - Area Under Curve）是一种用于评估分类模型性能的指标。具体来说：
ROC曲线：ROC曲线是根据不同的分类阈值绘制的，横轴表示假阳性率（False Positive Rate, FPR），纵轴表示真阳性率（True Positive Rate, TPR）。ROC曲线能够直观地展示模型在不同阈值下的分类性能。
AUC值：AUC（Area Under Curve）是ROC曲线下的面积，范围在0到1之间。AUC值越大，表示模型的分类性能越好。AUC值为1表示模型完美分类，而0.5表示模型性能等同于随机猜测。 ↩︎
“Human-in-the-Loop”是指一种在系统或流程中，人类参与其中并发挥重要作用的模式。更细致的解释是，这种模式强调在自动化或智能化的过程中，人类的干预、判断和决策对于优化系统性能、提高结果准确性和确保符合伦理道德等方面具有关键意义。人类并非完全被排除在流程之外，而是与技术相互协作，共同实现目标。 可以翻译为“人在环”或“回路中的人”。译者认为保留英语原味妥妥，并可以将“HITL”作为一个术语使用。 ↩︎
Not safe for work 的缩写，字面意思是不适合在上班的时候看。对于一些涉及色情，暴力等内容，发帖子的人就会在标题中加一个NSFW的标签，以提醒读者注意。 ↩︎
"Instrumenting"是指在软件系统中插入代码，以便收集有关系统运行状况和性能的数据。通过仪器化，开发人员可以监视系统的运行情况，识别潜在的性能瓶颈，优化系统性能，提高系统的稳定性和可靠性。仪器化是软件开发和运维中的重要实践，有助于开发人员更好地了解系统的运行情况，及时发现和解决问题，提高系统的性能和可维护性。 ↩︎
Comments