使用大语言模型 (LLMs) 构建产品一年后的经验总结 (第二部分)[译]
阅读本系列的第一部分，请点击这里，并关注即将发布的第三部分。 想直接听取作者对此主题的见解，请报名参加将于 6 月 20 日举行的线上活动，并在 6 月 12 日的生成式 AI 成功故事直播中了解更多信息。
有一句可能是伪造的名言，被许多领导人引用：“业余者谈战略和战术，专业者谈运营。”从战术角度看，问题是一堆独特的难题；从运营角度看，这些问题体现了需要修复的组织功能失调。从战略角度看，机会是一种挑战，值得迎接。
在这篇文章的第一部分中，我们介绍了使用大语言模型的战术细节。在下一部分中，我们将扩大视野，涵盖长期的战略考量。在本部分中，我们讨论了构建大语言模型应用程序的运营方面，这些方面位于战略和战术之间，并将理论付诸实践。
运营大语言模型应用程序提出了一些在运营传统软件系统时熟悉的问题，但通常有新的变化来保持新鲜感。大语言模型应用程序还提出了全新的问题。我们将这些问题及其答案分为四部分：数据、模型、产品和团队。
对于数据，我们回答：如何以及多频繁地审查大语言模型的输入和输出？如何测量和减少测试与生产之间的偏差？
对于模型，我们回答：如何将语言模型整合到其他系统中？应如何考虑模型的版本控制及在模型和版本之间迁移？
对于产品部分，我们讨论了：在应用开发过程中，设计应何时介入，为什么要尽早介入？如何通过丰富的人类反馈来设计用户体验？面对众多相互冲突的需求，如何确定优先级？又如何评估和控制产品风险？
对于团队部分，我们解答了：要打造成功的大语言模型 (LLM) 应用程序，应该聘请什么样的人才，何时聘请？如何营造一种鼓励实验的企业文化？如何利用现有的大语言模型应用来开发自己的应用？在过程和工具之间，哪个更为重要？
作为一个 AI 语言模型，我没有个人观点，因此无法评判你提供的介绍是否“优秀”。但我可以说，这个介绍很好地为后续内容铺平了道路。
操作：开发和管理 LLM 应用程序及其团队
数据
就像食材的质量决定了菜肴的味道一样，输入数据的质量也决定了机器学习系统的表现。而且，输出数据是唯一能判断产品是否正常运行的依据。所有作者都非常重视数据，每周都会花数小时研究输入和输出数据，以更好地理解数据分布：其模式、极端情况以及模型的局限性。
检查开发与生产的偏差
在传统的机器学习流程中，常见的错误来源之一是 训练 - 服务偏差。这是指训练时使用的数据与模型在生产中遇到的数据不同。尽管我们可以直接使用大语言模型（LLM）而无需训练或微调，但开发与生产数据之间的偏差问题仍然存在。基本上，我们在开发过程中测试的数据应与生产环境中的数据相似，否则生产中的准确性可能会受到影响。
大语言模型的开发与生产偏差主要有两类：结构性偏差和内容性偏差。结构性偏差包括格式差异问题，例如 JSON 字典中的列表类型值与 JSON 列表之间的差异、不一致的大小写，以及拼写错误或句子片段等错误。这些错误会导致模型性能不可预测，因为不同的大语言模型在特定数据格式上进行训练，且对微小的变化非常敏感。内容性或“语义”偏差指的是数据的意义或上下文的差异。
与传统机器学习一样，定期测量大语言模型输入/输出对之间的偏差是有用的。像输入和输出长度或特定格式要求（如 JSON 或 XML）这样的简单指标，是跟踪变化的有效方法。对于更“高级”的漂移检测，可以考虑对输入/输出对的嵌入进行聚类，以检测语义漂移，例如用户讨论话题的变化，这可能表明他们正在探索模型之前未接触过的领域。
在测试更改（如提示工程）时，确保保留的数据集是最新的并反映用户互动的最新类型。例如，如果生产输入中常见拼写错误，那么这些错误也应该出现在保留数据中。除了数值偏差测量外，对输出进行定性评估也是有益的。定期审查模型输出——一种俗称“氛围检查”的做法——可以确保结果符合预期，并保持对用户需求的相关性。最后，在偏差检查中引入非确定性也是有益的——通过对测试数据集中的每个输入多次运行管道并分析所有输出，我们可以增加捕捉偶尔发生的异常的可能性。
每天查看大语言模型（LLM）的输入和输出样本
大语言模型（LLM）是动态且不断发展的。尽管它们具有令人惊叹的零样本能力，且输出结果常常令人满意，但它们的故障模式往往难以预测。对于自定义任务，定期查看数据样本是理解 LLM 表现的关键。
生产环境中的输入输出对是 LLM 应用的“真实事物，真实地点”（genchi genbutsu），无可替代。 最近的研究 表明，开发人员在与更多数据交互时，对“好”与“坏”输出的看法会发生变化（即_标准漂移_）。虽然开发人员可以预先制定一些标准来评估 LLM 输出，但这些预定标准往往是不完整的。例如，在开发过程中，我们可能会调整提示词，以增加良好响应的概率并减少不良响应的概率。这种评估、重新评估和更新标准的迭代过程是必要的，因为在不直接观察输出的情况下，很难预测 LLM 的行为或人类的偏好。
为了有效管理这一过程，我们应记录 LLM 的输入和输出。通过每天检查这些日志样本，我们可以迅速识别并适应新的模式或故障模式。一旦发现新问题，可以立即编写断言或评估。同时，任何故障模式定义的更新都应体现在评估标准中。这些“氛围检查”是坏输出的信号，代码和断言将其具体化。最后，这种方法应被普及，例如通过将输入和输出的审查或注释添加到值班任务中。
与模型合作
通过使用 LLM API，我们可以依赖少数提供商的智能。这虽然是一个优势，但这些依赖也涉及性能、延迟、吞吐量和成本的权衡。此外，随着新模型的不断涌现（去年几乎每个月都有新模型发布），我们应准备好更新产品，淘汰旧模型并迁移到新模型。在本节中，我们分享了使用无法完全控制的技术（这些模型无法自行托管和管理）的经验教训。
生成结构化输出以简化下游集成
在大多数实际应用中，大语言模型 (LLM) 的输出需要通过机器可读的格式供下游应用程序使用。例如，Rechat 是一个房地产客户关系管理系统，需要结构化的响应来在前端呈现小部件。同样，Boba 是一个生成产品战略创意的工具，需要结构化的输出，包括标题、摘要、可信度评分和时间范围等字段。最后，LinkedIn 分享了如何约束 LLM 生成 YAML，用来决定使用哪种技能，并提供调用技能的参数。
这种应用模式是 Postel 定律的极端版本：在接受内容时要宽松（如任意自然语言），而在发送内容时要保守（如类型化的机器可读对象）。因此，我们认为这种模式非常可靠。
目前，Instructor 和 Outlines 已成为从大语言模型中引导结构化输出的实际标准。如果你使用的是 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 端点花费更多时间。不要以为使用相同的提示词会产生相似或更好的效果。此外，拥有可靠的自动化评估工具可以帮助我们在迁移前后衡量任务性能，并减少手动验证的工作量。
版本控制和固定模型
在任何机器学习管道中，“改变任何部分都会改变整体”[20]。这尤其适用于我们依赖的那些我们自己不训练的大语言模型 (Large Language Models, LLMs)，这些模型可能会在我们不知情的情况下发生变化。
幸运的是，许多模型提供者都提供了固定特定模型版本（例如，gpt-4-turbo-1106）的选项。这让我们可以使用特定版本的模型权重，确保其不变。在生产环境中固定模型版本可以避免因模型行为的意外变化而导致的客户投诉，例如模型更换时出现的输出过于冗长或其他不可预见的故障。
此外，我们可以考虑维护一个与生产环境相同但使用最新模型版本的影子管道 (shadow pipeline)。这样可以在安全的情况下对新版本进行实验和测试。一旦确认这些新模型的输出在稳定性和质量上都令人满意，我们就可以自信地在生产环境中更新模型版本。
选择最小的能完成任务的模型
在开发新应用时，我们往往会倾向于使用最大、最强大的模型。但一旦我们确定任务在技术上是可行的，就值得尝试较小的模型是否能实现相似的结果。
使用较小模型的好处是延迟和成本更低。尽管较小模型可能性能较弱，但链式思维、n-shot 提示和上下文学习等技术可以帮助其发挥超常水平。除了 LLM API，针对具体任务进行微调也有助于提高性能。
总体来看，一个精心设计的小模型工作流程通常可以匹敌甚至超过单个大模型的输出质量，同时速度更快、成本更低。例如，这篇 帖子 分享了 Haiku + 10-shot 提示如何超越零样本 Opus 和 GPT-4 的实例数据。从长远来看，我们预计会看到更多使用小模型的流工程案例，因为它们在输出质量、延迟和成本之间实现了最佳平衡。
另一个例子是简单的分类任务。像 DistilBERT（67M 参数）这样的轻量模型是一个令人惊讶的强大基线模型。拥有 400M 参数的 DistilBART 是另一个很好的选择——当在开源数据上进行微调时，它可以以 0.84 的 ROC-AUC 识别幻觉，在延迟和成本不到 5% 的情况下超过大多数大语言模型。
重点是，不要忽视较小的模型。虽然使用大型模型解决每个问题很容易，但通过一些创造力和实验，我们通常可以找到更有效的解决方案。
产品
虽然新技术提供了新的可能性，但打造优秀产品的原则是永恒的。因此，即使我们第一次解决新问题，我们也不必在产品设计上重新发明轮子。通过将我们的 LLM 应用开发建立在坚实的产品基础上，可以获得很多好处，使我们能够为用户提供真正的价值。
尽早且频繁地参与设计
设计师的加入会促使你深入思考产品如何构建和呈现给用户。我们有时会把设计师刻板印象为那些把东西弄得漂亮的人。但实际上，除了用户界面之外，他们还会重新思考如何改进用户体验，即使这意味着打破现有的规则和范式。
设计师尤其擅长将用户需求重新框架成各种形式。其中有些形式更容易解决，因此可能为 AI 解决方案提供更多或更少的机会。和许多其他产品一样，构建 AI 产品应该以完成任务为中心，而不是以驱动技术为中心。
重点是问自己：“用户希望这个产品为他们做什么？这个任务是聊天机器人擅长的吗？自动完成功能怎么样？也许需要不同的解决方案！”考虑现有的设计模式 以及它们与要完成的任务的关系。这些是设计师为你的团队能力带来的宝贵资产。
为 Human-in-the-Loop 设计用户体验
一种提高标注质量的方法是将 Human-in-the-Loop（HITL）集成到用户体验（UX）中。通过让用户轻松提供反馈和修改，我们不仅可以改进即时输出，还能收集到改进模型所需的宝贵数据。
设想一个电子商务平台，用户在上面上传并分类自己的产品。我们可以设计几种不同的用户体验：
- 用户手动选择产品类别；后台的大语言模型（LLM）定期检查新产品，并纠正分类错误。
- 用户无需选择任何类别；后台的 LLM 定期自动分类（可能会有错误）。
- LLM 实时建议产品类别，用户可以验证并根据需要进行更新。
尽管这三种方法都使用了 LLM，但它们提供的用户体验截然不同。第一种方法将初始负担放在用户身上，而 LLM 作为后续检查工具。第二种方法对用户来说毫无负担，但缺乏透明度和控制权。第三种方法则在两者之间找到了平衡。通过让 LLM 提前建议类别，我们减轻了用户的认知负担，他们无需学习复杂的分类体系来分类产品。同时，用户可以审查和修改这些建议，最终决定权掌握在自己手中。额外的好处是，第三种方法还创造了一个 改进模型的自然反馈循环：好的建议会被接受（正标签），错误的建议会被修改（负标签再变成正标签）。
这种建议、用户验证和数据收集的模式在多个应用中很常见：
- 编程助手：用户可以接受建议（强正面），接受并调整建议（正面），或忽略建议（负面）
- Midjourney：用户可以选择放大并下载图像（强正面），调整图像（正面），或生成新图像（负面）
- 聊天机器人：用户可以对回复点赞（正面）或点踩（负面），如果回复很差还可以选择重新生成（强负面）
反馈可以分为显性反馈和隐性反馈。显性反馈是指用户在我们产品请求下主动提供的信息；隐性反馈则是我们从用户交互中无意间收集到的信息。比如，编码助手和 Midjourney 提供的是隐性反馈，而点赞和点踩属于显性反馈。如果我们能像编码助手和 Midjourney 那样设计出优良的用户体验（UX），就能收集大量隐性反馈，进而改进我们的产品和模型。
严格优先考虑需求
在将演示投入实际使用时，我们需要考虑以下几个方面：
- 可靠性：确保 99.9% 的正常运行时间，遵循结构化输出
- 无害性：不生成有攻击性、成人内容或其他有害内容
- 事实一致性：忠于提供的上下文，不编造内容
- 有用性：与用户的需求和请求相关
- 可扩展性：满足延迟服务水平协议（SLA）和支持的吞吐量
- 成本：由于预算有限
- 其他：包括安全性、隐私、公平性、GDPR、DMA 等
如果我们试图一次性满足所有这些要求，就永远无法发布产品。因此，我们必须严格优先考虑。这意味着明确哪些是不可妥协的（如可靠性、无害性），否则我们的产品将无法运行或不具备可行性。关键是找到一个最低可接受的产品版本。我们必须接受初版不会完美，只需发布并不断改进。
根据使用场景调整风险承受能力
在选择语言模型和决定应用程序的审查级别时，要考虑具体的使用场景和受众。对于提供医疗或财务建议的客户聊天机器人，我们需要非常高的安全性和准确性标准，因为错误或不良输出可能会带来实际危害并损害用户信任。而对于诸如推荐系统或内容分类、摘要等内部应用，过于严格的要求只会拖慢进度，并不会带来太多额外价值。
这与最近的一份 a16z 报告 相符。报告显示，许多公司在内部应用大语言模型时，进展速度要快于外部应用。通过在内部试验 AI，提高生产力，企业可以在更可控的环境中实现价值，同时学习如何管理风险。随着经验和信心的增长，他们可以逐步扩展到面向客户的使用场景。
团队与角色
定义任何职位都不容易，但在这个新领域编写职位描述尤其具有挑战性。我们不打算使用交叉职位的维恩图或职位描述建议，而是认可一个新角色——AI 工程师，并讨论其职责和地位。同时，我们也会讨论团队中的其他角色及其职责分配。
注重过程，而非工具
当面对大语言模型等新范式时，软件工程师往往偏爱工具。这导致我们忽视了工具本应解决的问题和流程。结果，许多工程师无意中增加了复杂性，影响了团队的长期生产力。
例如，这篇文章讨论了某些工具如何自动生成大语言模型的提示。文章认为（在我看来是正确的），工程师在没有先理解问题解决方法或流程的情况下使用这些工具，最终会增加不必要的技术债务。
除了意外的复杂性外，工具通常缺乏详细说明。例如，LLM 评估工具市场在不断增长，这些工具提供“盒装 LLM 评估”，使用通用评估器来评估毒性、简洁性、语气等方面。我们见过许多团队在没有仔细考虑其领域特定失败模式的情况下采用这些工具。而 EvalGen 则不同。它专注于教用户创建特定领域的评估过程，用户在每一步都要深度参与，从指定标准、标记数据到检查评估。该软件引导用户完成如下工作流程：
EvalGen 引导用户通过最佳实践来制作 LLM 评估，即：
- 定义特定领域的测试（从提示中自动生成）。这些测试可以通过代码断言或使用 LLM-as-a-Judge（以 LLM 作为评判标准）来定义。
- 确保测试与人类判断一致，以便用户检查测试是否符合预期标准。
- 随着系统（如提示）的变化不断改进测试。
EvalGen 为开发者提供了一种评估构建过程的思维模式，而不局限于特定工具。我们发现，当 AI 工程师了解了这一背景知识后，他们往往会选择更精简的工具或自己开发工具。
除了提示编写和评估之外，大语言模型的其他组件很多，无法一一详述。然而，AI 工程师在采用工具之前必须理解这些过程。
始终进行实验
机器学习产品离不开实验。不仅是 A/B 测试和随机对照试验，还包括频繁地尝试修改系统中的小组件并进行离线评估。大家对评估如此重视，实际上是为了推动实验进展！评估越完善，你在实验上的迭代速度就越快，从而更快找到系统的最佳版本。
由于现在实验成本很低，尝试不同的方法来解决同一个问题已非常普遍。数据收集和模型训练的高成本已经大幅降低——提示工程几乎只需要花费人力时间。让团队成员掌握提示工程的基础知识，这不仅鼓励每个人进行实验，还能激发来自整个组织的多样化创意。
此外，不仅要进行探索性实验，还要通过实验来优化已有成果！有了一个新任务的初步版本后，考虑让团队中的其他人以不同方式处理它，尝试更快捷的方法。研究链式思维或少样本等提示技术，以提高质量。不要让工具限制了你的实验；如果有这种情况，重新设计或购买更好的工具。
最后，在进行产品或项目规划时，预留时间用于构建评估和进行多次实验。除了常规的工程产品规范，还要增加明确的评估标准。在制定路线图时，不要低估实验所需的时间——在最终投产之前，预计要进行多次开发和评估迭代。
让每个人都能使用新的 AI 技术
随着生成式 AI 的普及，我们希望整个团队——不仅仅是专家——都能理解并有能力使用这种新技术。要真正理解大语言模型 (LLM) 的工作原理 (例如，延迟、故障模式、用户体验)，最好的方法就是亲身使用它们。大语言模型相对容易接触：即使不懂编程，也能提升工作流程的性能，每个人都可以通过提示设计和评估来做出贡献。
这其中很大一部分是教育。可以从提示设计的基础知识入手，比如 n-shot 提示和链式思维 (CoT) 等技术，这些方法有助于将模型调整到所需的输出。拥有相关知识的人也可以讲解更技术的方面，例如大语言模型的自回归特性。换句话说，虽然输入 token 是并行处理的，但输出 token 是顺序生成的。因此，延迟主要取决于输出长度而非输入长度——这是设计用户体验和设定性能预期时的一个关键考虑因素。
我们还可以更进一步，提供动手实验和探索的机会。比如举办一次编程马拉松？虽然让整个团队花几天时间在一些设想的项目上进行编程马拉松似乎成本较高，但结果可能会让你感到惊讶。据我们所知，有一个团队通过一次编程马拉松，加速并几乎在一年内完成了他们三年的计划。另一个团队通过编程马拉松，开发出了颠覆性的用户体验，现在由于大语言模型的存在，这些体验已经成为年度及以后的优先事项。
别误以为“只需要 AI 工程师”
随着各种新职位的出现，人们往往会高估这些角色的能力。这通常会导致在明确这些工作的实际范围时出现纠正的过程。新入行的人和招聘经理可能会夸大这些职位的作用或对其抱有过高的期望。过去十年中的一些明显例子包括：
- 数据科学家：“比任何软件工程师都更擅长统计，比任何统计学家都更擅长软件工程”
- 机器学习工程师 (MLE)：一种以软件工程为核心的机器学习角色
最初，许多人以为只靠数据科学家就能完成所有数据驱动的项目。然而，事实证明，数据科学家需要与软件和数据工程师合作，才能有效地开发和部署数据产品。
这种误解在新的 AI 工程师职位中再次出现，一些团队认为只需要 AI 工程师就可以了。实际上，构建机器学习或 AI 产品需要多种专业角色。我们已经为十几家公司提供了 AI 产品咨询，常常发现他们误以为“只需要 AI 工程师”。结果，产品往往难以规模化，因为公司忽视了构建产品所需的重要环节。
例如，评估和测量对于将产品从初步阶段扩展至关重要。这些技能与机器学习工程师的一些传统优势相吻合——一个仅由 AI 工程师组成的团队可能缺乏这些技能。合著者 Hamel Husain 在他最近关于检测数据漂移和设计特定领域评估的工作中，展示了这些技能的重要性。
以下是构建 AI 产品过程中，各个阶段需要的角色类型及其需求的一个大致进展：
- 首先，专注于构建产品。这可能需要 AI 工程师，但不一定是必须的。AI 工程师在快速创建产品原型和迭代方面非常有用（例如用户体验和基础设施）。
- 接下来，您需要建立系统并收集数据来打好基础。根据数据的类型和规模，可能需要平台工程师和/或数据工程师。您还需要有查询和分析数据的系统来解决问题。
- 然后，您最终会希望优化您的 AI 系统。这不一定需要训练模型。基础步骤包括设计指标、构建评估系统、进行实验、优化 RAG 检索、调试随机系统等。机器学习工程师（MLE）在这方面非常擅长（尽管 AI 工程师也可以掌握这些技能）。通常，在完成前面的步骤之前，雇佣 MLE 是没有意义的。
除此之外，您始终需要一个领域专家。在小公司中，创始团队通常会担任这一角色；在大公司中，产品经理可以扮演这一角色。了解角色的进展和时机非常关键。在错误的时间雇佣人员（例如，过早雇佣 MLE）或按错误的顺序进行构建，会浪费时间和金钱，并导致人员流动。此外，在阶段 1-2 期间定期与 MLE 核对（但不全职雇佣他们）将有助于公司建立正确的基础。
关于作者
Eugene Yan 设计并运营大规模的机器学习系统，目前是亚马逊的高级应用科学家，负责构建服务大规模用户群体的推荐系统 (RecSys)和应用大语言模型 (LLMs) 提升客户体验。他曾在 Lazada（被阿里巴巴收购）领导机器学习团队，并在一家健康科技 Series A 公司担任领导职务。他在eugeneyan.com和ApplyingML.com上撰写和分享关于机器学习、推荐系统、大语言模型和工程的文章和演讲。
Bryan Bischof 是 Hex 的 AI 负责人，带领工程团队开发 Magic——一款数据科学和分析助手。Bryan 曾在数据分析、机器学习工程、数据平台工程和 AI 工程团队中担任领导角色。他在 Blue Bottle Coffee 创建了数据团队，领导了 Stitch Fix 的多个项目，并在 Weights and Biases 构建了数据团队。他曾与 O'Reilly 合著《Building Production Recommendation Systems》一书，并在罗格斯大学教授研究生数据科学和分析课程，拥有纯数学的博士学位。
Charles Frye 专注于教授 AI 应用开发。他在发表了关于精神药物学和神经生物学的研究后，在加利福尼亚大学伯克利分校获得了神经网络优化的博士学位。他通过在 Weights and Biases、Full Stack Deep Learning和 Modal 的教育和咨询工作，教授了数千人 AI 应用开发的完整流程，从线性代数基础到 GPU 技术以及如何构建有竞争力的商业模式。
Hamel Husain 是一位拥有超过 25 年经验的机器学习工程师。他曾在 Airbnb 和 GitHub 等创新公司工作，并参与了 OpenAI 早期用于代码理解的大语言模型（LLM）研究。他还领导并开发了许多流行的开源机器学习工具。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 的问题，使这些经验更具连贯性和紧凑性——这篇文章能从 40 页缩减到 30 页，多亏了他！我们感谢 Hamel 和 Jason，他们为客户提供咨询并身处前线，分享了广泛适用于客户的经验教训，并对工具有深刻了解。最后，感谢 Shreya，她提醒我们评估和严谨生产实践的重要性，并为本文带来了她的研究成果和原创见解。
最后，感谢所有团队，你们在自己的文章中慷慨分享了挑战和经验，并在本系列中被引用。同时，感谢 AI 社区，感谢你们对这个群体的积极参与和互动。