【背景介绍】本文来自多位一线LLM工作者的亲身体会，发表在O'Reilly，继在What We Learned from a Year of Building with LLMs (Part I)中探讨了与 LLM 工作的战术细节，本次在第二部分，带来了更广视野的LLM产品运营经验分享。鉴于自己近期在学习LLM相关知识，对第二部分也进行了全文翻译，供自己和有兴趣的同学一起继续学习。第二篇中涉及更多的一线实战经验分享，很多特别有意思，扩大了自己的认知。
【原文】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字典与列表类型值的区别、不一致的大小写以及拼写错误或句子片段等错误。这些错误可能导致模型表现不可预测，因为不同的LLM是基于特定数据格式训练的，提示可能对细微的变化非常敏感。内容性或“语义”偏差是指数据的含义或上下文的差异。
和传统的机器学习一样，定期测量LLM输入/输出对之间的偏差是有用的。简单的指标如输入和输出的长度或特定的格式要求（例如JSON或XML）是跟踪变化的直接方法。对于更“高级”的漂移检测，可以考虑对输入/输出对的嵌入进行聚类，以检测语义漂移，例如用户讨论主题的变化，这可能表明他们正在探索模型未曾接触过的领域。
在测试变化时，如提示工程，确保保持的数据集是最新的，并反映最近的用户交互类型。例如，如果生产输入中拼写错误很常见，那么它们也应该存在于保留集中。除了数值偏差测量之外，定性评估输出也是有益的。定期审查模型的输出——一种俗称的“氛围检查”，确保结果符合预期并保持与用户需求的相关性。最后，在偏差检查中加入非确定性也是有用的，通过在测试数据集中为每个输入多次运行管道并分析所有输出，我们增加了捕捉可能偶尔发生的异常的机会。
每天查看LLM输入和输出样本
LLM是动态的，不断发展的。尽管它们具有令人印象深刻的零样本能力，且输出也常常令人满意，但其失效模式可能极难预测。对于自定义任务，定期审查数据样本对于发展对LLM性能的直观理解至关重要。
来自生产的输入-输出对是LLM应用的“真实的事物，真实的地方”，不可替代。最近的研究表明，开发人员对“好”与“坏”输出的认知会随着他们接触更多数据而发生变化（即标准漂移）。尽管开发人员可以提前提出一些评估LLM输出的标准，但这些预定义标准通常是不完整的。例如，在开发过程中，我们可能会更新提示，以增加好响应的概率并减少坏响应的概率。这种评估、重新评估和标准更新的迭代过程是必要的，因为在没有直接观察输出的情况下，很难预测LLM行为或人类偏好。
为了有效地管理这一过程，我们应该记录LLM的输入和输出。通过每天检查这些日志的样本，可以迅速识别并适应新的模式或失效模式。当我们发现新问题时，可以立即编写一个断言或评估来处理它。类似地，任何对失效模式定义的更新都应反映在评估标准中。这些“氛围检查”是坏输出的信号；代码和断言将其操作化。最后，这种态度必须被社会化，例如，通过将输入和输出的审查或注释添加到值班轮值中。
使用模型
使用LLM API，我们可以依赖少数提供商的智能。这虽然是一个好处，但这些依赖也涉及性能、延迟、吞吐量和成本的权衡。此外，随着更新、更好的模型不断涌现（过去一年几乎每月都有），我们应准备好更新我们的产品，废弃旧模型并迁移到新模型。在本节中，我们分享了与我们无法完全控制的技术合作的经验教训，这些模型无法自托管和管理。
生成结构化输出以简化下游集成
对于大多数实际使用场景，LLM的输出将通过某种机器可读格式被下游应用消耗。例如，Rechat，一个房地产CRM，需要结构化响应以便前端渲染小部件。类似地，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之间的性能差距缩小了。
因此，如果我们必须在不同模型间迁移提示，要预料到这将花费比简单替换API更多的时间。不要假设使用相同的提示会产生类似或更好的结果。此外，拥有可靠的自动化评估工具有助于在迁移前后测量任务性能，并减少人工验证的工作量。
版本化和固定模型
在任何机器学习管道中，“改变任何东西都会改变一切”。当我们依赖大语言模型（LLMs）等我们自己不训练且可能在我们不知情的情况下变化的组件时，这一点尤为重要。
幸运的是，许多模型提供商提供了“固定”特定模型版本的选项（例如，gpt-4-turbo-1106）。这使我们能够使用特定版本的模型权重，确保它们保持不变。在生产环境中固定模型版本可以避免模型行为的意外变化，这些变化可能导致客户投诉，例如过于冗长的输出或其他不可预见的失败模式。
此外，可以考虑维护一个影子管道（也就是A/B testing），该管道镜像您的生产设置，但使用最新的模型版本。这允许在新版本上进行安全的实验和测试。一旦验证了这些新模型输出的稳定性和质量，就可以自信地更新生产环境中的模型版本。
选择能完成任务的最小模型
在开发新应用时，使用最大的、最强大的模型可能很有诱惑力。但一旦我们确认任务在技术上是可行的，就值得尝试是否较小的模型可以实现类似的结果。
较小模型的好处是延迟和成本较低。虽然它可能较弱，但像链式思维、多样例提示和上下文学习等技术可以帮助较小模型发挥出更好的表现。除了LLM APIs之外，为特定任务进行微调也可以帮助提高性能。
综合来看，使用较小模型并结合精心设计的工作流程，往往可以匹敌甚至超过单一大模型的输出质量，同时速度更快、成本更低。例如，这篇文章分享了一些例子，展示了Haiku加上10样例提示如何超过零样例的Opus和GPT-4。从长远来看，我们预计会看到更多使用较小模型进行流程工程的例子，这是输出质量、延迟和成本的最佳平衡。
另一个例子是简单的分类任务。像DistilBERT（67M参数）这样的轻量模型是一个出乎意料的强基线。参数为400M的DistilBART是另一个很好的选择——在开源数据上进行微调后，它可以以0.84的ROC-AUC识别幻觉，超过了大多数LLMs，延迟和成本不到5%。
重点是，不要忽视较小的模型。虽然很容易将大型模型用于每个问题，但通过一些创造力和实验，我们常常可以找到更高效的解决方案。
产品
新技术带来了新可能性，但构建伟大产品的原则是永恒的。因此，即使我们是第一次解决新问题，也不必在产品设计上重新发明轮子。将LLM应用开发扎根于坚实的产品基础上，可以为我们服务的人们提供真正的价值。
尽早且频繁地引入设计 有设计师会推动您深入理解和思考产品如何构建和呈现给用户。我们有时会将设计师刻板印象为使事物变得漂亮的人。但不仅仅是用户界面，他们还会重新思考如何改善用户体验，即使这意味着打破现有的规则和范式。
设计师特别擅长将用户的需求重新定义为各种形式。其中一些形式比其他形式更容易解决，因此它们可能提供更多或更少的AI解决方案机会。与许多其他产品一样，构建AI产品应以要完成的任务为中心，而不是推动它们的技术。
重点是问自己：“用户要求这个产品为他们完成什么任务？这个任务是聊天机器人擅长的吗？自动补全呢？也许是其他什么！”考虑现有的设计模式及其与待完成任务的关系。这些是设计师为您的团队能力增加的宝贵资产。
为人机回圈设计UX
获取高质量注释的一种方法是将人类回圈（HITL）集成到用户体验（UX）中。通过让用户轻松提供反馈和纠正，我们可以改善即时输出并收集有价值的数据以改进我们的模型。
想象一个电商平台，用户上传并分类他们的产品。我们可以设计几种不同的UX：
用户手动选择正确的产品类别；LLM定期检查新产品并在后台纠正分类错误。 用户根本不选择任何类别；LLM定期在后台分类产品（可能会有错误）。 LLM实时建议产品类别，用户可以根据需要验证和更新。 虽然所有三种方法都涉及LLM，但它们提供了非常不同的UX。第一种方法将初始负担放在用户身上，并让LLM充当后处理检查。第二种方法对用户没有任何要求，但不提供透明性或控制。第三种方法达到了最佳平衡。通过让LLM提前建议类别，我们减少了用户的认知负担，他们不必学习我们的分类法来分类他们的产品！同时，通过允许用户审查和编辑建议，他们对产品的分类有最终决定权，牢牢掌握控制权。作为额外的好处，第三种方法为模型改进创建了一个自然的反馈循环。好的建议被接受（正面标签），坏的建议被更新（负面然后正面标签）。
这种建议、用户验证和数据收集的模式在几个应用中常见：
- 编码助手：用户可以接受建议（强正面）、接受并调整建议（正面）或忽略建议（负面）；
- Midjourney：用户可以选择放大和下载图像（强正面），改变图像（正面）或生成一组新图像（负面）；
- 聊天机器人：用户可以对响应进行点赞（正面）或点踩（负面），或者选择重新生成一个响应如果它非常糟糕（强负面）
反馈可以是显性的或隐性的。显性反馈是用户在我们产品请求下提供的信息；隐性反馈是我们从用户交互中学习到的信息，而不需要用户刻意提供反馈。编码助手和Midjourney是隐性反馈的例子，而点赞和点踩是显性反馈的例子。如果我们设计得当，就像编码助手和Midjourney一样，我们可以收集大量隐性反馈来改进我们的产品和模型。
无情地优先考虑需求层次
当我们考虑将演示投入生产时，我们需要考虑以下需求：
- 可靠性：99.9%的正常运行时间，遵守结构化输出；
- 无害性：不生成攻击性、NSFW或其他有害内容；
- 事实一致性：忠实于提供的上下文，不编造；
- 有用性：与用户的需求和请求相关；
- 可扩展性：延迟SLA，支持的吞吐量；
- 成本：因为我们没有无限的预算 ；
- 以及更多：安全、隐私、公平、GDPR、DMA等；
如果我们尝试一次解决所有这些需求，我们将永远无法发布任何东西。因此，我们需要无情地优先考虑。这意味着明确什么是不可协商的（例如，可靠性、无害性），如果没有这些，我们的产品无法运行或不具可行性。关键在于确定最小可爱的产品。我们必须接受第一个版本不会完美，只需发布并迭代。
根据用例校准风险容忍度
在决定应用程序的语言模型和审查级别时，请考虑用例和受众。对于提供医疗或财务建议的面向客户的聊天机器人，我们需要非常高的安全性和准确性标准。错误或不良输出可能会造成实际伤害并破坏信任。但对于不太关键的应用程序，例如推荐系统，或内部应用程序如内容分类或摘要，过于严格的要求只会减慢进度，而不会增加太多价值。
这与a16z最近的一份报告一致，报告显示许多公司在内部LLM应用方面比外部应用进展更快。通过在内部生产力上试验AI，组织可以开始捕获价值，同时在更可控的环境中学习如何管理风险。然后，随着他们获得信心，他们可以扩展到面向客户的用例。
团队与角色
没有一个工作职能是容易定义的，但为这个新领域的工作编写职位描述比其他领域更加具有挑战性。我们将放弃用重叠的职称维恩图或职位描述建议来进行解释。然而，我们将提出一个新角色——AI工程师，并讨论其在团队中的地位。更重要的是，我们将讨论团队的其他成员及其责任分配。
关注流程，而不是工具
在面对新范式（如大语言模型）时，软件工程师倾向于偏爱工具。因此，我们往往忽略了工具本应解决的问题和过程。这样做，许多工程师承担了偶然的复杂性，这对团队的长期生产力产生了负面影响。
例如，某篇文章讨论了某些工具可以自动为大语言模型创建提示（prompts）。文章认为（在我看来是正确的），那些在没有先理解问题解决方法或过程的情况下使用这些工具的工程师最终会承担不必要的技术债务。
除了偶然的复杂性，工具往往定义不明确。例如，LLM评估工具行业正在不断增长，提供“LLM Evaluation in a Box”服务，这些工具包括毒性、简洁性、语气等方面的通用评估器。我们看到许多团队在没有批判性地思考其领域特定的失败模式时就采用了这些工具。相比之下，EvalGen则专注于教授用户创建特定领域评估的过程，深度涉及用户从指定标准、标记数据到检查评估的每一步。软件引导用户完成如下工作流程：
- 指定标准：确定对评估结果至关重要的具体标准。
- 标记数据：根据标准标记数据，以便评估模型的表现。
- 检查评估：检查和验证评估结果，确保其准确性和相关性。
通过这种方式，用户能够更好地理解和掌控评估过程，避免了盲目依赖工具所带来的复杂性和技术债务。
EvalGen 指导用户进行最佳实践的 LLM 评估，包括：
- 定义领域特定的测试（从提示自动启动）。这些测试可以通过代码断言或 LLM-as-a-Judge（大语言模型作为裁判）定义。
- 测试与人类判断一致的重要性，以便用户可以检查测试是否符合指定的标准。
- 随着系统（提示等）变化迭代测试。
EvalGen 为开发者提供了评估构建过程的思维模型，而不是将他们固定在特定的工具上。我们发现，在为 AI 工程师提供了这一背景后，他们往往会选择更轻量的工具或自行构建工具。
除了提示编写和评估，LLM 还有太多组件无法在此详述。然而，重要的是 AI 工程师应在采用工具前先了解流程。
永远进行实验
机器学习产品与实验密切相关。这不仅包括 A/B 测试、随机对照试验，还包括频繁修改系统最小组件并进行离线评估。每个人热衷于评估的原因实际上不是为了信任度和信心，而是为了实验！评估越好，实验迭代速度越快，从而更快地优化系统。
如今，实验非常便宜，解决同一问题的方法很多。收集数据和训练模型的高成本被最小化了，提示工程只需花费人力时间。将团队定位于每个人都掌握提示工程基础知识，这会鼓励每个人进行实验，并从整个组织中获得多样化的想法。
此外，不仅要进行探索性实验，还要利用实验来最大化效益！有了新任务的工作版本？考虑让团队中的其他人以不同方式进行尝试。尝试更快的方法，研究像链式思维（chain-of-thought）或少量样本（few-shot）提示等技术，以提高质量。如果工具阻碍了实验，重建它或购买更好的工具。
最后，在产品/项目规划中，预留时间进行评估和多次实验。将工程产品的规格添加明确的评估标准，并在制定路线图时，不要低估实验所需的时间——预期需要多次开发和评估迭代，才能获得生产许可。
赋能每个人使用新AI技术
随着生成式 AI 的普及，我们希望整个团队——不仅仅是专家——都能理解并使用这项新技术。没有比实际使用 LLM 更好的方式来培养对其工作原理（如延迟、失败模式、用户体验）的直觉了。LLM 相对易于访问：不需要编程知识也能改善管道性能，每个人都可以通过提示工程和评估进行贡献。
其中一个重要部分是教育。可以从提示工程的基础知识开始，例如 n-shot 提示和链式思维（CoT）技术，帮助模型朝着预期输出方向发展。掌握知识的人还可以教育更多技术方面的内容，如 LLM 的自回归特性。换句话说，输入标记是并行处理的，但输出标记是顺序生成的。因此，延迟更多取决于输出长度而非输入长度——这在设计用户体验和设定性能预期时是关键考虑因素。
我们还可以进一步提供实践实验和探索的机会。也许是一个黑客马拉松？虽然让整个团队花费几天时间在推测项目上看起来成本很高，但结果可能会让你惊讶。我们知道有一个团队通过黑客马拉松加速并几乎完成了三年的路线图。由于 LLM， 另一个团队通过黑客马拉松实现了可能的范式转变的用户体验。
不要陷入“AI 工程是我唯一需要的”的陷阱
随着新职位的出现，最初往往会夸大这些角色的能力。这通常会导致痛苦的调整，因为工作的实际范围变得明确。进入这个领域的新人以及招聘经理可能会做出夸张的声明或有过高的期望。过去十年的显著例子包括：
- 数据科学家：“比任何软件工程师都更擅长统计，比任何统计学家都更擅长软件工程”
- 机器学习工程师（MLE）：一种以软件工程为中心的机器学习视角
最初，许多人认为仅靠数据科学家就足以完成数据驱动的项目。然而，事实证明，数据科学家必须与软件和数据工程师合作，才能有效开发和部署数据产品。
这种误解再次出现在 AI 工程师的新角色上，有些团队认为 AI 工程师是唯一需要的角色。实际上，构建机器学习或 AI 产品需要多种专业角色。我们咨询了十多家公司关于 AI 产品的开发，发现他们普遍陷入了“AI 工程是唯一需要的”的误区。结果是，产品往往难以超越演示阶段，因为公司忽视了构建产品涉及的关键方面。
例如，评估和测量对于产品超越氛围检查至关重要。有效评估的技能与传统上在机器学习工程师中看到的某些优势一致——一个完全由 AI 工程师组成的团队可能缺乏这些技能。合著者 Hamel Husain 在其最近的工作中阐述了这些技能的重要性，涉及数据漂移检测和设计领域特定的评估。
以下是构建 AI 产品过程中需要的角色类型及其需求时间的大致进展：
- 首先，专注于构建产品。这可能包括 AI 工程师，但不一定必须。AI 工程师对于快速原型和产品迭代（用户体验、管道等）非常有价值。
- 接下来，创建正确的基础设施，记录系统并收集数据。根据数据的类型和规模，可能需要平台和/或数据工程师。还必须有查询和分析这些数据的系统，以便调试问题。
- 然后，最终需要优化 AI 系统。这不一定涉及训练模型。基础步骤包括设计指标、构建评估系统、运行实验、优化 RAG 检索、调试随机系统等。MLE 在这些方面表现出色（虽然 AI 工程师也可以掌握）。除非完成了前提步骤，否则通常不建议过早雇用 MLE。
- 除此之外，始终需要领域专家。在小公司中，这理想情况下是创始团队——在大公司中，产品经理可以扮演这个角色。了解角色的进展和时间安排至关重要。在错误的时间雇用人员（例如，过早雇用 MLE）或以错误的顺序构建是浪费时间和金钱的，并会导致团队流动。此外，在第1-2阶段，定期与 MLE 联系（但不全职雇用）将帮助公司建立正确的基础设施。
679
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
