一个常被许多领导者引用、但很可能是被杜撰出来的名言是：“外行谈战略和战术，内行谈运营。”战术视角看到的是一个个独特的难题，而运营视角看到的是组织中需要需要改变的不协调的模式。战略视角看到的是机会，运营视角则看的是挑战。

在这一系列文章的第一部分中，我们介绍了与LLMs配合的战术要点。在接下来的部分中，我们将放大视角，涵盖长期考虑因素。在这一部分，我们将讨论构建LLM应用的运营方面。运营，就像是连接理想与现实的桥梁，把高大上的理念落到实处。

运营LLM应用会带来一些常见的问题，这些问题与运营传统软件系统类似，但往往有一些新颖的变化。LLM应用也会引发全新的问题。我们将这些问题及我们的答案分为四个部分：数据、模型、产品和人。

对于数据，我们回答：你应该如何以及以多高的频率审查LLM的输入和输出？如何评估和减少测试-生产偏差？

对于模型，我们回答：您如何将语言模型与技术堆栈的其余部分整合？您应该如何考虑模型的版本控制以及在模型和版本之间进行迁移？

对于产品方面，我们探讨的问题是：设计师应该在应用开发过程的哪个阶段介入，为什么说是“越早越好”？如何设计出能够收集丰富真人反馈的用户体验？面对众多的矛盾需求，应该如何进行优先排序？如何调整产品的风险系数？

最后，对于人才方面，我们探讨的问题是：为了成功构建大型语言模型（LLM）应用，你应该聘请哪些人才，以及何时聘请他们？如何培养正确的文化，即一种实验文化？你应该如何利用新兴的LLM来构建你自己的LLM应用程序？哪个更重要：流程还是工具？

作为一个AI语言模型，我没有个人观点，所以无法告诉你你所提供的介绍是“绝妙还是一般”。然而，我可以告诉你，这个介绍恰当地为后续的内容奠定了基础。

【作者在玩AI回复梗......】

运营：创建和管理LLM应用以及应用开发团队

1.数据

"高端的食材往往只需要简单的烹饪"，输入数据的质量决定了机器学习系统的性能。此外，输出数据是判断产品是否正常工作的唯一途径。所有本文作者都紧密关注数据，每周都在研究输入和输出上花费好几个小时，以便更好地理解数据分布：它的主要模式、边缘案例，以及它的限制模型。

1.1 检查开发和生产之间的差异

在传统的机器学习流程中，常见的错误来源是训练-推理偏差。这种情况发生在训练中使用的数据与模型在生产环境中遇到的数据不同。尽管我们可以不经过训练或微调就使用大型语言模型（LLMs），因此不存在训练集，但开发-生产数据偏差的类似问题仍然存在。本质上，我们在开发过程中测试系统的数据应该反映出系统在生产中将会面临的情况。如果做不到这一点，我们可能会发现生产系统的准确率受到影响。

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

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

在测试更改时，比如提示工程，请确保保留数据集是当前的，并且反映了最新的用户交互类型。例如，如果在生产输入中错别字很常见，那么在保留数据中也应该存在错别字。除了数值偏差测量之外，对输出进行定性评估也是有益的。定期审查模型的输出——俗称“氛围检查（Vibe Checks）”——确保结果符合预期，并保持与用户需求的关联性。最后，将非确定性因素纳入偏差检查也很有用——通过为测试数据集中的每个输入多次运行管道并分析所有输出，我们增加了捕捉可能偶尔发生的异常的可能性。

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

LLMs 是动态的，不断发展的。尽管它们具有令人印象深刻的零提示能力，也能常常给你欣喜的输出，但它们的失败模式可能非常难以预测。对于定制任务，为了对于提高对LLMs性能的直观理解，定期审查数据样本至关重要。

来自生产的输入-输出对是大型语言模型（LLM）应用程序的“真实事物、真实地点”（Genchi Genbutsu），它们无法被替代。最近的研究强调，随着开发者与更多数据互动，他们对“好”和“坏”输出的看法会发生变化（即标准漂移）。虽然开发者可以提前制定一些评估LLM输出的标准，但这些预定义标准通常是不足的。例如，在开发过程中，我们可能会更新提示，以提高良好响应的概率并降低不良响应的概率。这种评估、重新评估和标准更新的迭代过程是必要的，因为如果不直接观察输出，很难预测LLM的行为或人类的偏好。

为了有效管理这一点，我们应该记录LLM个输入和输出。通过每天检查这些日志的样本，我们可以快速识别和适应新的模式或失效模式。当我们发现新问题时，我们可以立即围绕它编写一个断言或测试。同样，对失效模式定义的任何更新都应反映在评估标准中。这些“氛围检查”是坏输出的信号；代码和断言将它们操作化。

最后，这种态度必须被所有人遵守，例如通过将输入和输出的审查或注释添加到您的值班轮换(on-call rotation)中。

2. 与模型合作

如果使用大型语言模型（LLM）API，我们能依赖好几个提供商的服务。虽然这是一大优势，但这些依赖关系也涉及到性能、延迟、吞吐量和成本之间的权衡。另外，随着新模型的推出（在过去一年中几乎每个月都有新模型），我们应该准备好更新我们的产品，因为我们需要抛弃旧模型并迁移到新模型。在本节中，我们将分享我们在使用我们无法完全控制的技术方面的经验教训，在这种情况下，我们对模型无法自部署或者管理控制。

2.1 生成结构化输出以便于下游集成

在大多数真实世界的用例中，大型语言模型（LLM）的输出将通过某种机器可读的格式被下游应用程序所使用。例如，Rechat，一个房地产CRM系统，需要结构化的响应以便前端渲染Widget。同样，Boba，一个生成产品策略想法的工具，需要带有标题、摘要、可行性评分和时间范围等字段的结构化输出。最后，LinkedIn分享了如何限制LLM生成YAML，然后使用该YAML来决定使用哪个技能，并提供调用该技能的参数。

这种应用模式是 Postel 法则的极端版本：在接受内容时要宽容（任意自然语言），在发送内容时要保守（类型化、机器可读对象）。因此，我们期望它非常经久耐用。

目前，Instructor 和 Outlines 是从 LLMs 中获取结构化输出的事实标准。如果您正在使用 LLM API（例如，Anthropic、OpenAI），请使用 Instructor；如果您正在使用自托管模型（例如，Hugging Face），请使用 Outlines。

2.2 跨模型迁移提示词是一件让人头疼的事情

有时候，我们精心设计的提示在一个模型上表现出色，但在另一个模型上却不起作用。当我们在不同的模型提供商之间切换，或者在同一个模型的不同版本之间升级时，就会出现这种情况。

例如，Voiceflow 发现从 gpt-3.5-turbo-0301 迁移到 gpt-3.5-turbo-1106 导致其意图分类任务下降了 10%。（幸运的是，他们有评估！）同样，GoDaddy 观察到一个正向趋势，升级到版本 1106 缩小了 gpt-3.5-turbo 和 gpt-4 之间的性能差距。（或者，如果你是一个看到杯子半满的人，你可能会对 gpt-4 的领先优势在新升级中被减少感到失望）

因此，如果我们需要在模型之间迁移提示，预计这将比简单地交换 API 端点需要更多时间。不要假设插入相同的提示会导致类似或更好的结果。此外，具有可靠的自动评估有助于在迁移之前和之后测量任务性能，并减少手动验证所需的工作量。

2.3 模型的版本管理

在任何机器学习流程中，“改变任何东西都会改变一切”。这一点尤其重要，因为我们依赖于像大型语言模型（LLMs）这样的组件，这些组件我们自己没有训练，而且可能在我们不知情的情况下发生变化。

幸运的是，许多模型提供商提供了“固定”特定模型版本（例如，gpt-4-turbo-1106）的选项。这使我们能够使用模型权重的特定版本，确保它们保持不变。在生产中固定模型版本可以帮助避免模型行为的意外变化，这可能导致客户投诉出现问题，例如当模型被替换时可能出现的过于啰嗦的输出或其他意想不到的失效模式。

此外，考虑维护一个影子管道，镜像您的生产设置，但使用最新的模型版本。这样可以进行安全的实验和测试，尝试新版本。一旦您验证了这些更新模型的输出的稳定性和质量，您可以自信地更新生产环境中的模型版本。

2.4 选择胜任工作的最小模型

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

较小模型的好处是延迟和成本更低。虽然可能较弱，但像思维链、n-shot 提示和ICL (In-Context-Learning)等技术可以帮助较小模型发挥超出其重量的作用。除了LLM个 API 之外，微调我们的特定任务也可以帮助提高性能。

综合起来，使用较小的模型精心设计的工作流程通常可以达到甚至超越单个大型模型的输出质量，同时速度更快、成本更低。例如，这篇文章(https://twitter.com/mattshumer_/status/1770823530394833242)分享了 Haiku + 10-shot 提示优于零提示 Opus 和 GPT-4 的案例。从长远来看，我们期望看到更多使用较小模型的流程工程示例，作为输出质量、延迟和成本的最佳平衡。

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

关键是，不要忽视较小的模型。虽然很容易将庞大的模型用于每个问题，但通过一些创造力和实验，我们通常可以找到更有效的解决方案。

3. 产品

虽然新技术提供了新的可能性，但构建伟大产品的原则是永恒的。因此，即使我们是在首次解决新问题，也不必在产品设计上重新发明轮子。将我们的LLM应用程序开发建立在坚实的产品基础上，可以让我们为服务的人带来真正的价值，这是非常有益的。

3.1 让设计师尽早并经常介入

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

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

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

3.2 为"人在回路(HITL)"设计您的用户体验

将质量标注集成到用户体验（UX）中的一种方法是将人在环中（HITL）融入其中。通过让用户轻松提供反馈和更正，我们可以改善即时输出并收集宝贵的数据来改进我们的模型。

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

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

虽然这三种方法都涉及到了大型语言模型（LLM），但它们提供了非常不同的用户体验（UX）。第一种方法将初始负担放在用户身上，LLM充当后期处理的检查。第二种方法不需要用户付出任何努力，但不提供透明度或控制权。第三种方法找到了正确的平衡。通过让LLM提前建议分类，我们减少了用户的认知负担，他们不必学习我们的分类法来对他们的产品进行分类！同时，通过允许用户审查和编辑建议，他们在如何分类他们的产品上有最终决定权，从而将控制权牢牢掌握在自己手中。作为额外的好处，第三种方法为模型改进创造了自然的反馈循环。好的建议被接受（正面标签），而不好的建议被更新（负面后跟正面标签）。

这种建议、用户验证和数据收集的模式通常在几个应用程序中看到：

• 编码助手：用户可以接受建议（强烈正面），接受并调整建议（正面），或忽略建议（负面）
• Midjourney：用户可以选择升级并下载图像（强烈正面），变换图像（正面），或生成新的一组图像（负面）
• 聊天机器人：用户可以对回复进行点赞（积极）或点踩（消极），或选择重新生成回复，如果回复真的很糟糕（强烈消极）

反馈可以是明确的或隐含的。明确反馈是用户对我们产品请求的信息；隐含反馈是我们从用户互动中学到的信息，而无需用户刻意提供反馈。编码助手和 Midjourney 是隐含反馈的例子，而点赞和点踩是明确反馈。如果我们像编码助手和 Midjourney 一样设计好用户体验，我们就可以收集大量隐含反馈来改进我们的产品和模型。

3.3 无情地进行优先级排序

当我们考虑将我们的演示放入生产中时，我们将不得不考虑以下要求：

• 可靠性：99.9% 的正常运行时间，遵守结构化输出
• 无害：不生成冒犯性、NSFW 或其他有害内容
• 事实一致性：忠实于所提供的背景，不虚构
• 实用性：与用户的需求和请求相关
• 可伸缩性：延迟 SLA，支持的吞吐量
• 成本：因为我们没有无限的预算
• 更多：安全、隐私、公平、GDPR、DMA 等。

如果我们试图一次解决所有这些要求，我们永远无法交付任何东西。因此，我们需要非常无情的进行优先排序。这意味着明确非谈判性的内容（例如，可靠性，无害性），没有这些内容，我们的产品无法运行或不可行。这一切都是关于确定"最小可爱产品(minimum lovable product)"。我们必须接受第一个版本不会完美，并且只需启动和迭代。

3.4 根据使用情况校准您的风险承受能力

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

这与最近的 a16z 报告一致，显示许多公司在内部LLM应用方面比外部应用更快。通过尝试在内部生产力方面使用人工智能，组织可以开始捕捉价值，同时学习如何在更受控制的环境中管理风险。然后，当他们获得信心时，他们可以扩展到面向客户的用例。

4. 团队与角色

没有哪项工作职责是容易定义的，但在这一新兴领域撰写职位描述比其他领域更具挑战性。我们将不使用韦恩图来展示交叉的职位名称，或不提供具体的职位描述建议。然而，我们将接受一个新角色——AI工程师——的存在，并讨论其定位。重要的是，我们还将讨论团队的其他成员以及如何分配责任。

4.1 专注于过程，而不是工具

当面对新的范式时，例如LLMs，软件工程师倾向于偏爱工具。因此，我们忽视了工具本应解决的问题和流程。这样做，许多工程师会假设意外复杂性，这对团队的长期生产力产生负面影响。

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

除了偶然的复杂性外，工具通常规定不足。例如，有一个不断增长的LLM评估工具行业，提供“LLM评估盒” ，其中包含毒性、简洁性、语气等通用评估器。我们看到许多团队采用这些工具，而没有对其领域的具体故障模式进行批判性思考。与此形成对比的是 EvalGen。它专注于教导用户创建特定领域评估的过程，通过深度参与用户的每一个步骤，从指定标准，到标记数据，再到检查评估。该软件引导用户完成一个看起来像这样的工作流程：

Shankar, S., 等人（2024 年）。谁来验证验证者？将LLM辅助评估LLM输出与人类偏好对齐。取自 https://arxiv.org/abs/2404.12272

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

• 定义特定领域测试（从提示中自动引导）。这些被定义为具有代码或LLM-as-a-Judge 的断言。

• 将测试与人类判断相一致的重要性，使用户能够检查测试是否符合指定的标准。

• 随着系统（提示等）的变化对您的测试进行迭代。

EvalGen 为开发人员提供了一个评估构建过程的心智模型，而不将他们锚定在特定工具上。我们发现，在为 AI 工程师提供了这种背景后，他们经常决定选择更精简的工具或自行构建。

这里有太多LLMs的组成部分超出了及时写作和评估的范围，无法在这里详细列出。然而，重要的是 AI 工程师在采用工具之前要努力理解这些过程。

4.2 始终进行实验

ML 产品与实验紧密相连。不仅仅是 A/B 测试、随机对照试验，还包括频繁尝试修改系统中最小的组件并进行离线评估。大家如此热衷于评估的原因实际上并不是出于可信度和信心，而是为了促进实验！你的评估越好，你就能更快地在实验上迭代，从而更快地收敛于系统的最佳版本。

尝试不同方法来解决同一个问题是很常见的，因为现在实验成本很低。收集数据和训练模型的高成本被最小化了——提示工程师几乎不比人力成本高。让团队的每个人都掌握快速工程的基础知识。这样可以鼓励每个人进行实验，从而产生来自整个组织的多样化想法。

此外，不要只是进行实验探索，还要利用它们！有一个新任务的工作版本吗？考虑让团队中的其他人以不同方式处理。尝试以更快的方式进行另一种尝试。探索快速技术，如思维链或few-shot，使其质量更高。不要让工具限制你的实验；如果是这样，重新构建它，或购买一些东西使其更好。

最后，在产品/项目规划阶段，要为建立评估和运行多个实验留出时间。将工程产品的产品规格视为指导，但在此基础上加入明确的评估标准。在制定路线图时，不要低估实验所需的时间——预计在获得生产批准之前，需要进行多次开发和评估的迭代。

4.3 赋予每个人使用新人工智能技术的能力

随着生成式人工智能的普及，我们希望整个团队——不仅仅是专家们——都能理解并感到有能力使用这项新技术。要培养对LLMs工作方式（例如延迟、故障模式、用户体验）的直觉，没有比使用它们更好的方式了。LLMs相对容易获取：您不需要懂编程就能提高管道性能，每个人都可以通过提示工程和评估开始贡献。

这其中的一个重要部分是教育。它可以从简单的提示工程基础开始，其中像 n-shot 提示和 CoT 这样的技术有助于将模型调整到期望的输出。具有知识的人还可以就更技术方面进行教育，比如LLMs是自回归的性质。换句话说，虽然输入标记是并行处理的，但输出标记是按顺序生成的。因此，延迟更多地取决于输出长度而不是输入长度——这是在设计 UX 和设置性能期望时的一个关键考虑因素。

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

4.4 不要陷入“AI 工程师就是我需要的一切”的陷阱

随着新的职称的创造，最初往往会夸大与这些角色相关联的能力。这通常会导致在这些工作的实际范围变得清晰时进行痛苦的纠正。新手和招聘经理可能会夸大其词或抱有夸张的期望。过去十年中的显著例子包括：

• 数据科学家：“一个比任何软件工程师更擅长统计学，比任何统计学家更擅长软件工程的人”

• 机器学习工程师（MLE）：机器学习的软件工程视角

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

这种误解再次出现在 AI 工程师的新角色中，一些团队认为 AI 工程师就是你所需要的全部。实际上，构建机器学习或人工智能产品需要各种专业角色。我们咨询了十多家公司的人工智能产品，并一直观察到它们陷入了“只需要 AI 工程师”的陷阱。结果，产品往往难以超越演示阶段，因为公司忽视了构建产品所涉及的关键方面。

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

这是在构建人工智能产品过程中，您需要的各种角色以及需要它们的时间的大致进展：

• 首先，专注于打造产品。这可能包括一个 AI 工程师，但不一定。AI 工程师对于在产品（用户体验，管道等）上快速原型设计和迭代非常有价值。

• 接下来，通过仪器化系统并收集数据来建立正确的基础。根据数据的类型和规模，您可能需要平台和/或数据工程师。您还必须有用于查询和分析这些数据以调试问题的系统。

• 接下来，您最终会想要优化您的AI系统。这并不一定涉及训练模型。基础工作包括设计指标、构建评估系统、运行实验、优化 RAG 检索、调试随机系统等步骤。MLEs 在这方面非常擅长（尽管 AI 工程师也可以掌握）。除非您已经完成了先决步骤，否则雇佣 MLE 通常是没有意义的。

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

文章来自于微信公众号“Meshinfo ”，作者 “Meshinfo ”