过去一年有关大模型应用构建的干货经验：运营篇

过去一年，大模型应用以前所未有之势从出现到繁荣。LLM应用从原型展示向生产落地演进。近日，Oreilly刊发了由 Eugene Yan, Bryan Bischof等人撰写的大模型总结性文章《What We Learned from a Year of Building with LLMs？》，由于作者们背景各不相同，有独立咨询顾问（Hamel Husain，Jason Liu），有研究人员（Shreya Shankar），还有科技公司AI团队领袖（Eugene Yan，Bryan Bischof），以及AI领域布道师（Charles Frye），这使得文章内容更为全面深入。他们从战术、运营和战略三个部分展开解读了自己过去一年有关LLM应用开发与运营的全方位经验。

一、战术篇

过去一年有关大模型应用构建的干货经验之战术篇

二、运营篇

在运营 LLM 应用时，会遇到一些传统软件系统中常见的问题，但这些问题通常都会以新颖的方式出现，以保持新颖性。LLM 应用也提出了全新的问题。文章将这些问题和答案分为四个部分：数据、模型、产品和人员。

• 对于数据，如何以及多久审查一次 LLM 输入和输出？如何衡量和减少测试-产品偏差？
• 对于模型，如何将语言模型集成到堆栈的其他部分？如何考虑模型的版本化以及模型和版本之间的迁移？
• 对于产品，设计应该何时参与应用程序开发过程，为什么是 "尽早"？如何设计具有丰富人际反馈的用户体验？如何对众多相互冲突的需求进行优先排序？如何校准产品风险？
• 对于人员，要成功构建LLM应用，应该招聘什么样的人？如何培养正确的实验文化？如何利用新兴的LLM应用软件来构建自己的LLM应用软件？流程和工具哪个更重要？

数据

正如食材的质量决定了菜肴的味道一样，输入数据的质量也制约着机器学习系统的性能。此外，输出数据是了解产品是否有效的唯一途径。所有作者都密切关注数据，每周都要花几个小时查看输入和输出，以便更好地了解数据分布：其模式、边角情况以及模型的局限性。检查开发-生产数据偏差

传统机器学习Pipeline中常见的错误源是开发-生产数据偏差（train-serve skew）。当训练中使用的数据与模型在生产中遇到的数据不同时，就会出现这种情况。虽然可以在不进行训练或微调的情况下使用 LLM，因此没有训练集，但开发-生产数据偏差也会产生类似的问题。从根本上说，在开发过程中测试系统的数据应该反映系统在生产中将面临的情况。否则，可能会发现生产准确性会受到影响。

LLM 开发-生产数据偏差可分为两类：结构性偏差和内容偏差。结构性偏差包括格式差异等问题，例如具有列表类型值的 JSON 字典与 JSON 列表之间的差异、不一致的大小写以及错别字或句子片段等错误。这些错误可能会导致无法预测的模型性能，因为不同的 LLM 是根据特定的数据格式进行训练的，而提示可能会对细微变化高度敏感。基于内容或 "语义 "的偏差指的是数据含义或上下文的差异。

与传统的 ML 一样，定期测量 LLM 输入/输出对之间的偏差也很有用。输入和输出的长度或特定格式要求（如 JSON 或 XML）等简单指标是跟踪变化的直接方法。对于更 "高级 "的漂移（drift）检测，可以考虑对输入/输出对的嵌入进行聚类，以检测语义漂移，例如用户讨论的话题发生了变化，这可能表明他们正在探索模型以前未曾接触过的领域。

在测试变化（如提示工程）时，确保保留数据集是最新的，并能反映最新的用户交互类型。例如，如果错别字在生产输入中很常见，那么它们也应该出现在保留数据中。除了数值偏差测量，对输出进行定性评估也很有益处。定期检查模型的输出结果--俗称 "振动检查(vibe checks)"--可确保结果符合预期，并始终与用户需求相关。最后，将非确定性纳入偏差检查也很有用，通过对测试数据集中的每个输入多次运行Pipeline并分析所有输出，就更有可能捕捉到偶尔出现的异常情况。

每天审查LLM的输入和输出样本

LLM 是动态的，不断进化的。尽管 LLM 具备令人印象深刻的零误差能力，而且通常能提供令人满意的输出结果，但其失败类型却可能非常难以预测。对于定制任务而言，定期查看数据样本对于直观了解 LLM 的性能至关重要。来自生产的输入输出对是 LLM 应用的 "真实事物、真实地点"，它们是不可替代的。最近的研究强调，开发人员对什么是 "好"、什么是 "坏 "输出的看法会随着他们与更多数据的交互而改变（即标准漂移）。虽然开发人员可以预先制定一些标准来评估 LLM 输出，但这些预定义的标准往往是不完整的。例如，在开发过程中，我们可能会更新提示，以增加好回答的概率，降低坏回答的概率。这种评估、重新评估和标准更新的迭代过程是必要的，因为如果不直接观察输出结果，就很难预测 LLM 的行为或人类的偏好。为了有效管理，应该记录 LLM 的输入和输出。通过每天检查这些日志样本，可以快速识别并适应新的模式或失败类型。当发现一个新问题时，可以立即编写一个断言或评估。同样，失败类型定义的任何更新都应反映在评估标准中。这些 "振动检查 "是不良输出的信号，利用代码和断言日常执行这些检查。最后，必须将这种形式制度化，例如在值班轮换中增加对输入和输出的审查或注释。

使用模型

有了 LLM API，我们可以依靠少数几个供应商提供的智能。虽然这是件好事，但这些依赖性也涉及性能、延迟、吞吐量和成本方面的权衡。此外，随着更新、更好的模型的出现（去年几乎每月都有），应该做好准备，在淘汰旧模型并迁移到更新模型时更新的产品。在本节中，将分享在使用我们无法完全控制的技术时的经验教训，在这些技术中，模型无法自托管和管理。

生成结构化输出，便于下游集成对于大多数实际用例而言，LLM 的输出将由下游应用通过某种机器可读格式来使用。例如，房地产 CRM Rechat 需要结构化的响应，以便前端渲染小部件。同样，用于生成产品战略创意的工具 Boba 也需要结构化的输出，其中包括标题、摘要、可信度评分和时间范围等字段。最后，LinkedIn 分享了如何限制 LLM 生成 YAML，然后用 YAML 决定使用哪种技能，并提供调用技能的参数。这种应用模式是波斯特尔定律（Postel’s law）的极端版本：接受的内容（任意自然语言）要自由，发送的内容（键入的机器可读对象）要保守。因此，我们希望它非常耐用。目前，"指导者 "和 "大纲 "是从 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 端点花费更多时间。不要以为插入相同的提示符就能得到相似或更好的结果。此外，拥有可靠的自动验证有助于衡量迁移前后的任务性能，并减少手动验证所需的工作量。

版本化和固定模型

在任何机器学习Pipeline中，"改变任何东西都会改变一切"。这一点在我们依赖大型语言模型（LLM）等组件时尤为重要，因为这些组件不是我们自己训练的，而且可能在我们不知情的情况下发生变化。幸运的是，许多模型提供商提供了 "固定 "特定模型版本的选项（例如，gpt-4-turbo-1106）。这样我们就能使用特定版本的模型权重，确保它们保持不变。在生产中固定模型版本有助于避免模型行为发生意想不到的变化，这可能会导致客户抱怨在交换模型时可能出现的问题，例如过于冗长的输出或其他不可预见的失败情况。此外，还可以考虑维护一个影子Pipeline，以反映生产设置，但使用最新的模型版本。这样就能安全地使用新版本进行实验和测试。一旦您验证了这些较新模型输出的稳定性和质量，您就可以放心地更新生产环境中的模型版本。

选择能完成工作的最小版本的模型

在开发新的应用时，使用最大、最强大的模型很有诱惑力。但是，一旦我们确定任务在技术上是可行的，就值得尝试一下较小的模型是否也能达到类似的效果。较小模型的好处是延迟更短，成本更低。虽然它的性能可能较弱，但COT、N-shot和上下文学习等技术可以帮助较小的模型发挥更大的作用。除了 LLM API 之外，微调我们的特定任务也有助于提高性能。综合来看，使用较小模型精心设计的工作流程往往可以达到甚至超过单一大型模型的输出质量，同时速度更快、成本更低。例如，这篇文章分享了 Haiku + 10-shot prompt 如何优于 0-shot Opus 和 GPT-4 故事（https://twitter.com/mattshumer_/status/1770823530394833242）。从长远来看，我们希望看到更多使用较小模型进行流程设计的例子，以实现输出质量、延迟和成本之间的最佳平衡。再以简单的分类任务为例。像 DistilBERT（6700 万参数）这样的轻量级模型是一个令人惊讶的强大基线。400M 参数的 DistilBART 是另一个不错的选择--在开源数据上进行微调后，它可以识别幻觉，ROC-AUC 为 0.84，超过了大多数 LLM，而延迟和成本却不到 5%。重点是，不要忽视较小的模型。虽然我们很容易在每一个问题上都抛出一个庞大的模型，但通过一些创造性的尝试，我们往往可以找到更有效的解决方案。产品虽然新技术提供了新的可能性，但打造优秀产品的原则是永恒的。因此，即使我们是第一次解决新问题，我们也不必重新设计产品。将我们的 LLM 应用开发建立在坚实的产品基础之上，可以让我们为我们所服务的人群提供真正的价值。尽早并经常参与设计有了设计师的参与，就能促使你深入理解和思考如何构建产品并将其呈现给用户。我们有时会将设计师刻板地认为他们只会把东西做得漂亮。但除了用户界面之外，他们还会重新思考如何改善用户体验，即使这意味着要打破现有的规则和模式。设计师尤其擅长将用户需求重构为各种形式。其中一些形式比其他形式更容易解决，因此，它们可能为人工智能解决方案提供更多或更少的机会。与许多其他产品一样，打造人工智能产品的核心应该是要完成的工作，而不是为其提供动力的技术。重点是问自己"用户要求这款产品为他们做什么工作？这项工作是聊天机器人擅长的吗？自动完成怎么样？也许会有所不同！"考虑现有的设计模式以及它们与待完成任务的关系。这些都是设计师为团队能力增添的宝贵财富。为 "Human-in-the-Loop"设计用户体验

获得高质量注释的方法之一是将 "Human-in-the-Loop"（HITL）集成到用户体验（UX）中。通过允许用户轻松提供反馈和更正，我们可以改进即时输出，并收集宝贵的数据来改进我们的模型。

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

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

虽然这三种方法都涉及到 LLM，但它们提供的用户体验却截然不同。第一种方法让用户承担前期成本，而 LLM 则充当后处理检查。第二种方法不需要用户做出任何努力，但不提供任何透明度或控制。第三种方法取得了适当的平衡。通过让 LLM 提前提出分类建议，我们减轻了用户的认知负担，他们无需学习我们的分类法来对产品进行分类！同时，通过允许用户审查和编辑建议，他们对产品如何分类拥有最终决定权，从而将控制权牢牢掌握在自己手中。另外，第三种方法还为模型改进创造了一个自然的反馈回路。好的建议会被接受（正面标签），不好的建议会被更新（负面标签后是正面标签）。

这种建议、用户验证和数据收集的模式在多个应用中都很常见：

• 编码助手：用户可以接受建议（强正反馈）、接受并调整建议（正反馈）或忽略建议（负反馈）。
• Midjourney：用户可以选择放大并下载图片（强正反馈）、更改图片（正反馈）或生成一组新图片（否定）
• 聊天机器人：用户可以对回复竖起大拇指（强正反馈）或摁下大拇指（负反馈），或者在回复非常糟糕的情况下选择重新生成回复（强负反馈）

反馈可以是显性的，也可以是隐性的。显性反馈是用户应我们产品的要求而提供的信息；隐性反馈是我们从用户交互中了解到的信息，无需用户刻意提供反馈。编码助手和 Midjourney 就是隐式反馈的例子，而竖起大拇指和放下大拇指则是显式反馈。如果我们能像编码助手和 Midjourney 一样设计好用户体验，我们就能收集到大量的隐式反馈，从而改进我们的产品和模型。客观地确定需求层次的优先级当我们考虑将我们的演示投入生产时，我们必须考虑以下需求：

• 可靠性：99.9% 的正常运行时间，坚持结构化输出
• 无害性：不生成攻击性、NSFW 或其他有害内容
• 事实一致性：忠实于所提供的上下文，不胡编乱造
• 有用性：与用户的需求和要求相关
• 可扩展性：延迟 SLA、支持的吞吐量
• 成本：因为我们没有无限的预算
• 更多安全、隐私、公平、GDPR、DMA 等。

如果试图一次解决所有这些需求，将永远无法交付任何东西。因此，需要分清轻重缓急。这意味着要明确哪些要求是必须满足的（如可靠性、无害性），否则产品将无法运行或无法生存。这就是要确定最小产品。我们必须接受第一个版本并不完美的事实，并不断推出和迭代。

根据使用案例校准风险容忍度在决定应用程序的语言模型和审查级别时，要考虑使用案例和受众。对于面向客户提供医疗或金融建议的聊天机器人，我们需要对安全性和准确性有很高的要求。错误或糟糕的输出可能会造成真正的伤害并削弱信任。但对于不那么重要的应用，如推荐系统，或面向内部的应用，如内容分类或摘要，过于严格的要求只会减慢进度，而不会增加多少价值。这与 a16z 最近的一份报告（A16Z:2024年企业落地生成式AI技术的16个变化）不谋而合，该报告显示，与外部应用相比，许多公司的内部应用进展更快。通过尝试使用人工智能提高内部生产力，企业可以开始获取价值，同时学习如何在更可控的环境中管理风险。然后，随着信心的增强，他们可以扩展到面向客户的使用案例。团队与角色
任何工作职能都不容易定义，但为这个新空间的工作撰写职位描述却比其他工作更具挑战性。我们将放弃绘制交叉职称的维恩图，也不对职位描述提出建议。不过，我们将承认一个新角色--AI工程师--的存在，并讨论它的位置。重要的是，我们将讨论团队的其他成员以及如何分配职责。注重过程而非工具面对 LLM 等新模式时，软件工程师往往倾向于使用工具。结果，我们忽略了工具本应解决的问题和流程。这样一来，许多工程师就会认为复杂性是偶然的，从而对团队的长期生产力造成负面影响。例如，这篇文章（https://hamel.dev/blog/posts/prompt/）讨论了某些工具如何为LLM自动创建提示。文章认为，工程师在使用这些工具时，如果没有首先了解解决问题的方法或流程，最终就会承担不必要的技术债务。除了意外的复杂性之外，工具往往不够规范。例如，现在有一种不断发展的LLM评估工具，提供 "LLM Evaluation in a Box"，带有毒性、简洁性、语气等通用评估工具。我们看到许多团队在采用这些工具时，并没有认真思考其领域的具体失败情况。而 EvalGen 则不同，它侧重于向用户传授创建特定领域评估的过程，让用户深入参与从指定标准、标注数据到检查评估的每一个步骤。该软件引导用户完成如下工作流程：

EvalGen 可指导用户采用最佳实践方法来编写LLM评估报告，即

1.定义特定领域的测试（从提示中自动引导）。这些测试既可以定义为带有代码的断言，也可以定义为 LLM-as-a-Judge。

2.使测试与人类判断对齐的重要性，这样用户就能检查测试是否捕获了指定的标准。

3.随着系统（提示等）的变化而迭代测试。

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

不断实验

ML 产品与实验密切相关。不仅是 A/B、随机对照试验，还包括经常尝试修改系统中尽可能小的组件并进行离线评估。每个人都如此热衷于评估的原因其实并不在于可信度和信心，而是为了实现实验！评估做得越好，你就能越快地迭代实验，从而越快地收敛到系统的最佳版本。

尝试不同的方法来解决同一个问题是很常见的，因为现在的实验成本很低。收集数据和训练模型的高成本已经降到了最低--提示工程所花费的不过是人的时间。对团队进行定位，让每个人都能学到即时工程的基础知识。这将鼓励每个人进行实验，并从整个组织中产生不同的想法。

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

最后，在产品/项目规划期间，预留时间用于建立评估和运行多个实验。想想工程产品的产品规格，但在其中加入明确的实验标准。在绘制路线图时，不要低估实验所需的时间--预计在获得生产绿灯之前，需要进行多次迭代开发和验证。

让每个人都有能力使用新的人工智能技术随着生成式人工智能的应用越来越广泛，我们希望整个团队，而不仅仅是专家，都能了解并有能力使用这项新技术。没有比使用 LLM 更好的方法来培养对 LLM 工作原理（如延迟、故障模式、用户体验）的直觉了。LLM 相对来说比较容易使用：您不需要知道如何编写代码就能提高管道的性能，而且每个人都可以通过及时工程和评估开始贡献自己的力量。其中很重要的一部分就是教育。教育可以从简单的提示工程基础知识开始，N-shot 提示和 CoT 等技术有助于调节模型以实现理想的输出。具备相关知识的人还可以从技术层面进行教育，例如 LLM 在本质上是如何自回归的。换句话说，输入token是并行处理的，而输出token则是顺序生成的。因此，延迟与其说是输入长度的函数，不如说是输出长度的函数，这也是设计用户体验和设定性能预期时需要考虑的关键因素。
还可以更进一步，提供动手实验和探索的机会。比如黑客马拉松？虽然让整个团队花几天时间进行投机性项目的工作似乎很昂贵，但结果可能会让你大吃一惊。据我们所知，有一个团队通过黑客马拉松加快了进度，几乎在一年内完成了他们的三年路线图。另一个团队则通过黑客马拉松实现了用户体验的范式转换，而这一切都要归功于 LLMs，它们现在已被列为今年及以后的优先事项。不要陷入 "AI engineering is all I need"的陷阱随着新职位出现，人们最初往往会夸大这些职位的相关能力。当这些工作的实际范围变得清晰时，这往往会导致痛苦的修正。该领域的新人和招聘经理可能会夸大其词或抱有过高的期望。过去十年中的著名例子包括：

• 数据科学家："在统计方面比任何软件工程师都强，在软件工程方面比任何统计学家都强"。

• 机器学习工程师（MLE）：以软件工程为中心的机器学习观点

最初，许多人认为数据科学家本身就足以完成数据驱动型项目。然而，数据科学家显然必须与软件和数据工程师合作，才能有效地开发和部署数据产品。随着AI工程师这一新角色的出现，这种误解再次显现，一些团队认为AI工程师就是你所需要的全部。实际上，构建机器学习或AI产品需要大量的专业角色。我们曾为十多家公司提供AI产品方面的咨询，并持续观察到他们陷入了 "只需要AI工程师 "的误区。结果，由于公司忽视了构建产品所涉及的关键环节，产品在演示之后往往难以推广。例如，评估和测量对于扩大产品规模，使其超越振动检查至关重要。有效评估的技能与机器学习工程师的一些传统优势相吻合，而仅由人工智能工程师组成的团队很可能缺乏这些技能。合著者哈梅尔-侯赛因（Hamel Husain）在他最近围绕检测数据漂移和设计特定领域评估的工作中说明了这些技能的重要性。以下是在构建人工智能产品的整个过程中，您需要的角色类型以及何时需要这些角色的粗略进展：首先，专注于打造产品。这可能包括一名AI工程师，但不一定非得如此。AI工程师在产品原型设计和快速迭代（用户体验、Pipeline等）方面很有价值。接下来，通过检测系统和收集数据来创建正确的基础。根据数据的类型和规模，您可能需要平台和/或数据工程师。您还必须拥有查询和分析这些数据的系统，以调试问题。接下来，您最终需要优化人工智能系统。这不一定需要训练模型。基本步骤包括设计指标、构建评估系统、运行实验、优化 RAG 检索、调试随机系统等。MLE 在这方面非常擅长（虽然AI工程师也能学会）。除非已经完成了前提步骤，否则雇用一名 MLE 通常是没有意义的。除此之外，还需要一名领域专家。在小公司，这最好是创始团队的成员；在大公司，产品经理可以扮演这一角色。了解角色的发展和时机至关重要。在错误的时间聘用人员（如过早聘用一名 MLE）或以错误的顺序组建团队都会浪费时间和金钱，并导致人员流失。此外，在第 1-2 阶段定期检查 MLE（但不是全职聘用）将有助于公司建立正确的基础。