不要掉入“AI 工程就是一切”的陷阱

常有人错误地将这样一句话归因于一些领导者，尽管它可能完全是虚构的：“外行谈论战略和战术，内行关注运营。”从战术的角度看，我们面对的是一系列独特的问题，从运营角度，我们看到的是需要解决的组织功能失调模式。在战略视角看到的是机会，在运营视角看到的是需要应对的挑战。

在本系列文章的第一部分，我们介绍了 LLM 的战术性操作。接下来，我们将拓宽视野，深入探讨长期的战略规划。在这一部分，我们将讨论构建 LLM 应用程序的运营层面，这些应用程序是战略与战术的桥梁，将理论与实际应用紧密结合。

在运营 LLM 应用程序过程中，我们遇到了一些似曾相识的问题，这些问题在传统软件系统的运营中也常常出现，不同的是它们也带来了一些新的挑战，使得探索过程充满了趣味。此外，运营 LLM 应用程序还带来了一些全新的问题。我们将这些问题及其答案归纳为四个部分：数据、模型、产品和人。

对于数据，我们将探讨这几个问题：如何以及多久需要重新审视一次 LLM 的输入和输出？如何测量并有效减少测试环境与生产环境之间的偏差？

对于模型，我们将探讨这几个问题：如何将语言模型集成到现有的技术栈中？如何看待模型的版本控制以及如何在不同模型和版本之间进行平滑迁移？

对于产品，我们将探讨这几个问题：设计应该在何时介入应用程序的开发过程，为什么要“尽早介入”？如何设计能够充分吸纳人类反馈的用户体验？在面对相互冲突的需求时如何安排优先级？如何校准产品风险？

最后，对于人，我们将探讨这几个问题：选择哪些人才来构建成功的 LLM 应用程序，以及何时招募他们？如何培养正确的实验性文化？如何利用现有的 LLM 应用程序来辅助开发自己的 LLM 解决方案？哪一个更关键：流程还是工具？

运营：LLM 应用程序的构建和开发团队

数据

正如精选的食材能够成就一道佳肴，高质量的输入数据同样对机器学习系统的表现起着决定性作用。此外，系统的输出是评估其是否正常工作的唯一方式。所有人都紧密关注数据，他们每周都会花几个小时细致地分析输入和输出，以便更好地理解数据分布：模式、边缘情况以及模型的局限性。

检查开发与生产偏差

在传统机器学习流程中存在的一个普遍问题是训练与服务之间的偏差。这种情况通常发生在模型训练时使用的数据与模型在实际应用中遇到的数据不一致时。尽管我们可以无需训练或微调就能够使用 LLM，从而避免了训练集的问题，但开发与生产环境之间的数据偏差问题依然存在。关键在于，在开发阶段测试系统时所用的数据应与系统在生产环境中实际面对的数据相一致。如果不是这样的话，我们可能会发现生产环境中的模型准确性会受影响。

LLM 开发与生产偏差可以分为两种类型：结构性偏差和基于内容的偏差。结构性偏差包括格式不一致，比如 JSON 字典与 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 之间的性能差距。（或者，如果你是一个乐观的人，可能会对 gpt-4 的领先优势在这次升级中有所减少感到失望。）

因此，如果我们不得不在模型之间迁移提示词，预计这将是一个比简单更换 API 端点更耗时的过程。不要想当然地认为使用相同的提示词能够得到相似或更好的结果。此外，拥有一个可靠的自动化评估系统，可以在迁移前后有效地衡量任务性能，并显著减少所需的手动验证工作。

版本控制和固定你的模型

在机器学习管道中，“改变一点，影响全局”是一个普遍现象。这一点在我们依赖自己未参与训练的组件，例如大型语言模型（LLM）时，显得尤为突出，因为这些模型可能会在不被我们察觉的情况下发生变化。

幸运的是，许多模型供应商提供“锁定”特定模型版本（例如，gpt-4-turbo-1106）的选项。这样，我们可以使用特定版本的模型权重，确保它们保持不变。在生产环境中锁定模型版本有助于防止模型行为发生意外变化，从而减少因模型更新可能导致的问题（例如过于冗长的输出或其他不可预见的故障模式）。

此外，可以考虑维护一个影子管道，这个管道镜像了生成环境的设置，但使用的是最新的模型版本。这为实验和测试新版本提供了一个安全的环境。一旦确认这些新模型的输出在稳定性和质量上符合标准，就可以自信地升级生产环境中的模型版本。

选择能够完成任务的最小模型

在开发新应用程序时，使用最强大的模型往往具有极大的吸引力。然而，一旦我们确认了技术可行性，就很有必要尝试一下使用更小的模型是否能够产生同样优质的结果。

小模型的优势是较低的延迟和成本。虽然在性能上可能略显逊色，但通过诸如思维链、n-shot 提示词和上下文学习等先进技术的应用，它们完全有可能超越自身的限制。除了调用 LLM API，针对特定任务进行微调也能够显著提升性能。

综合考虑，一个精心设计的工作流，即使使用较小的模型，通常也能匹敌甚至超越单个大型模型的输出质量，同时还具备更快的处理速度和更低的成本。例如，这个推文分享了 Haiku 结合 10-shot 提示词的表现优于零样本的 Opus 和 GPT-4。从长远来看，我们期望看到更多流程工程的案例，使用较小的模型实现输出质量、响应时间和成本之间的最佳平衡。

作为另一个典型案例，我们来看一下那些看似简单的分类任务。轻量级的 DistilBERT（6700 万参数）模型居然是一个出人意料的强大基线。在开源数据上进行微调后，拥有 4 亿参数的 DistilBART 更是一个不错的选择——它在识别幻觉方面的 ROC-AUC 值达到了 0.84，在延迟和成本方面增加不到 5%，超越了大多数大型语言模型。

重点是，我们不要轻视那些模较小的模型。尽管人们往往倾向于对各种问题都应用庞大的模型，但通过一些创新思维和实验探索，我们常常能够发现更为高效的解决方案。

产品

虽然新技术为我们带来了新的可能性，但构建卓越产品的核心原则始终不变。因此，即使是在第一次面临新挑战时，我们也无需在产品设计方面重新发明轮子。将我们的 LLM 应用程序开发建立在坚实的产品理念之上，这将使我们能够为用户带来真正的价值。。

及早并频繁地进行设计

设计师的参与有助于推动你深入思考如何构建和向用户展示产品。我们有时会将设计师简单定义为美化事物的人。然而，除了用户界面之外，他们还会全面思考如何改进用户体验，甚至是打破现有的规则和范式。

设计师擅长将用户需求转化为各种各样的形式。这些形式有些更容易实现，而有些则为 AI 技术提供了更多或更少的施展空间。与许多其他产品一样，构建 AI 产品应该以要完成的任务为中心，而不是驱动这些任务的技术。

问问自己：“用户期望这个产品为他们完成哪些任务？这些任务是聊天机器人擅长的吗？能够使用自动完成功能？也许可以尝试一些不同的方案！”审视现有的设计模式，思考它们与要完成的任务之间的联系。这些是设计师为团队能力带来的宝贵贡献。

以 HITL 为导向设计用户体验

一种提升注释质量的方式是将 Human-in-the-Loop（HITL）融入到用户体验（UX）设计中。通过让用户轻松地提供反馈和更正，我们不仅能即时优化输出，还能收集有洞察力的数据来改进我们的模型。

设想一个电子商务平台，用户需要上传并分类他们的商品。我们可以从多个角度来设计用户体验：

• 用户手动选择产品类别；LLM 定期检查新产品并在后端更正分类错误。

• 用户不选择产品类别；LLM 定期在后端对产品进行分类（可能存在错误）。

• LLM 提供实时产品类别建议，用户可以根据自己的判断进行验证和更新。

虽然这三种方法都利用了 LLM，但它们提供了非常不同的 UX。第一种方法将初始责任放在用户身上，并将 LLM 作为后续的辅助。第二种方法减少了用户的负担，但不提供透明度或控制权。第三种方法找到了二者之间的平衡点。LLM 提前建议类别，减少了用户的认知负担，他们无需深入了解复杂的分类体系。同时，用户可以审查和修改这些建议，他们对如何分类产品有最终的决定权，将控制权牢牢掌握在手中。作为一个额外的好处，第三种方法为模型改进创建了一个自然反馈循环。好的建议会被接受（正反馈标签），不好的建议会被更新（负反馈标签转成正反馈标签）。

这种建议、用户验证和数据收集的模式在多个应用领域中都得到了广泛应用：

• 编码助手：用户可以接受建议（强烈正反馈）、接受并调整建议（正反馈）或忽略建议（负反馈）。

• Midjourney：用户可以选择放大并下载图像（强烈正反馈）、修改图像（正反馈）或生成一组新图像（负反馈）。

• 聊天机器人：用户可以对响应点赞（正反馈）或不点赞（负反馈），如果响应真的很差，选择重新生成响应（强烈负反馈）。

反馈可以是显式或隐式的。显式反馈是用户对产品提出的意见或评价，隐式反馈是我们需要从用户交互中捕捉的信息，无需用户有意提供。编码助手和 Midjourney 是隐式反馈的例子，而点赞和不点赞是显式反馈。如果我们能够像编码助手和 Midjourney 那样设计 UX，就可以收集到大量的隐式反馈来改进我们的产品和模型。

调整需求层次的优先级

在准备将演示转化为实际应用时，我们需要仔细考虑以下几个关键要素：

• 可靠性：确保 99.9% 的正常运行时间，同时遵循结构化输出标准；

• 无害性：避免生成攻击性、NSFW 或其他有害的内容；

• 事实一致性：忠实于提供的上下文，不虚构信息；

• 实用性：与用户的需求和请求相关；

• 可扩展性：延迟 SLA，支持高吞吐量；

• 成本效益：需要考虑预算限制；

• 其他：安全性、隐私保护、公平性、GDPR 合规性、DMA 合规性等。

如果我们试图同时解决所有这些要求，我们将永远无法完成产品交付。因此，我们必须进行优先级排序，并且要果断。这意味着我们要清楚哪些是没有商量余地的（例如，可靠性、无害性），没有这些我们的产品就是不可行的。关键在于识别出最基本的产品功能。我们必须接受第一个版本不会完美的事实，并通过不断迭代来改进。

根据用例校准风险承受能力

在选择语言模型及其审查标准时，我们需要根据应用场景和目标受众来做出判断。对于那些提供医疗或财务咨询的聊天机器人，我们必须设定极高的安全和准确性标准。因为任何错误或不当的输出都可能造成严重的后果，并且会严重损害用户对我们的信任。然而，对于不那么关键的应用，比如推荐系统，或者那些仅供内部使用的应用程序，如内容分类或摘要，过分严格的要求可能会拖慢开发进度，却不会为提升价值带来太大帮助。

这与最近发布的 a16z 报告中的观点相吻合，许多公司在内部 LLM 应用方面比外部应用进展得更快。通过在内部生产力工具中引入 AI，组织可以在更加受控的环境中实现价值，同时学习如何有效地管理风险。然后，随着他们信心的增强，可以逐步扩展到面向客户的应用场景。

团队与角色

定义工作职能不是件容易的事，而在这个新兴领域编写工作描述比其他领域更具挑战性。我们决定不再使用交叉工作职能的文氏图或工作描述的建议。相反，我们将引入一个新的职位——AI 工程师——并探讨其在组织中的位置。同时，我们也将讨论团队其他成员的角色以及如何合理分配责任，这至关重要。

专注于流程，而不是工具

面对新兴的范式，例如大型语言模型，软件工程师们往往更倾向于采用各种工具。这种偏好有时会导致我们忽视了这些工具本应解决的问题和优化的流程。结果，许多工程师不得不应对由此产生的偶然的复杂性，对团队的长期生产力构成了负面影响。

例如，这篇文章讨论了某些工具如何为大型语言模型自动生成提示词。文章认为（在我看来是正确的），那些在没有先理解问题解决方法或流程的情况下使用这些工具的工程师最终会累积不必要的技术债务。

除了偶然的复杂性，许多工具还常常存在规格不足的问题。以不断壮大的 LLM 评估工具行业为例，它们提供所谓的“即插即用”的 LLM 评估服务，涵盖毒性、简洁性、语调等通用评估指标。我们发现许多团队在没有深入分析其领域特有的失败模式的情况下，就盲目采纳了这些工具。与此形成鲜明对比的是 EvalGen，它通过深度参与用户的每一个环节——从定义标准到标注数据，再到评估检查——引导用户构建适合特定领域的评估体系。

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

EvalGen 引导用户通过遵循最佳实践来制定 LLM 评估标准，即：

1. 定义特定领域的测试（通过提示词自动引导）。它们可以是带有代码的断言，或者是采用“LLM 即评委”的形式。

2. 强调将测试与人类判断对齐的重要性，使用户能够验证测试是否确实捕捉到了既定的标准。

3. 随着系统（如提示词内容等）的变化不断迭代和优化测试标准。

EvalGen 为开发人员提供了评估构建过程的框架性理解，而不是将他们限制在特定工具的使用上。我们发现，一旦 AI 工程师获得了这种宏观视角，他们往往会选择采用更简洁的工具，或者根据自己的需求自行开发解决方案。

LLM 的组成部分远不止提示词编写和评估，其复杂性无法在此一一列举。关键在于 AI 工程师在采用工具之前要深入理解其背后的流程和原理。

持续地实验

机器学习产品与实验密切相关。不仅涉及 A/B 测试、随机对照试验，还包括频繁尝试修改系统的最小组件并进行离线评估。人们热衷于评估的真正原因并非仅仅为了可靠性和信心——而是为了让实验成为可能。你的评估越精确，就能越迅速地进行实验，进而更快地发现系统的最佳配置。

尝试采用不同的方法解决同一个问题是一种很常见的做法，因为现在的实验成本很低。收集数据和训练模型的高昂成本已经得到有效控制——提示词工程的成本仅略高于人力投入。确保你的团队成员都掌握了提示词工程的基础知识。这不仅能激发他们进行实验的热情，还能促进组织内部不同观点的交流与碰撞。

此外，实验不仅仅是为了探索，而是要学会利用它们。如果你手头有一个新的任务，可以考虑让团队的其他成员从不同的视角来处理它。尝试寻找更高效的方法，探索如思维链或 few-shot 提示词等技术，以提高工作质量。不要让工具限制了你的实验；如果是这样，那就重新构建它们，或者购买新的工具。

最后，在产品或项目规划阶段，务必留出足够的时间来构建评估机制并进行多项实验。在考虑工程产品的规格时，为评估过程设定明确的标准。在制定路线图时，不要低估了实验所需的时间。要预见到在生产交付之前，可能需要进行多轮的开发和评估迭代。

让每个人都能使用新的 AI 技术

随着生成式 AI 采用率的增加，我们希望整个团队——不仅仅是专家——都能理解并自信地使用这项新技术。没有比亲自实践更好的方式去培养对大型语言模型工作原理的直观理解了，比如它们的响应延迟、故障模式和用户体验。LLM 相对容易使用：你无需编码技能就可以为流程管道提升性能，每个人都可以通过提示词工程和评估做出实质性的贡献。

教育是关键环节，可以从提示词工程的基础开始，如利用 n-shot 和思维链等技术，引导模型生成期望的输出。拥有这方面知识的人还可以教授更技术性的内容，例如大型语言模型本质上是自回归的。换句话说，虽然输入可以并行处理，但输出是顺序的。因此，生成延迟更多地取决于输出的长度而非输入的长度——这是在设计用户体验和设定性能预期时需要考虑的一个关键因素。

我们还可以提供更多实践和探索的机会，比如举办一次黑客马拉松。虽然让整个团队投入数日时间在探索性项目上看起来成本较高，但最终的成果可能会超出你的预期。我们见证了一个团队通过黑客马拉松，在短短一年内就实现了他们原本计划三年完成的路线图。另一个团队则通过黑客马拉松，引领了一场用户体验的范式转变，这种转变现在因为大型语言模型的加入而成为可能。

不要掉入“AI 工程就是一切”的陷阱

随着新职位名称的出现，人们往往容易过分夸大这些角色的能力。这通常会导致在实际工作职责变得逐渐明确时，人们不得不去做一些痛苦的调整。新入行的人和负责招聘的经理可能会夸大声明或抱有不切实际的期望。在过去的十年里，这类显著的例子包括：

• 数据科学家：“在统计学方面比任何软件工程师都强，在软件工程方面比任何统计学家都强的人”

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

最初，许多人认为数据科学家单枪匹马就能驾驭数据驱动的项目。然而，现实情况已经清晰地表明，为了有效地开发和部署数据产品，数据科学家必须与软件工程师和数据工程师紧密合作。

这种误解在 AI 工程师这一新兴角色上再次出现，一些团队误以为 AI 工程师就是他们需要的一切。实际上，构建机器学习或 AI 产品需要一个由多种专业角色 组成的团队。我们与十多家公司就 AI 产品进行了深入咨询，发现他们普遍都陷入了认为“AI 工程就是一切”的陷阱。这种认知导致产品往往难以越过演示阶段，因为公司忽视了构建产品所涉及的关键方面。

例如，评估和度量对于将产品从单一的领域检查阶段扩展到广泛应用阶段来说至关重要。有效的评估能力与机器学习工程师通常所具备的优势相辅相成——一个完全由 AI 工程师组成的团队可能缺乏这些技能。Hamel Husain 在他最近的研究中强调了这些技能的重要性，包括监测数据漂移和制定针对特定领域的评估标准。

以下是在构建 AI 产品的过程中你需要的不同类型角色，以及他们在项目各个阶段大致的参与时机：

1. 首先，专注于构建产品。这个阶段可能涉及 AI 工程师，但并非必须。AI 工程师在快速原型设计和迭代产品方面具有显著的价值（用户体验、数据处理管道等）。

2. 随后，通过系统化地收集和分析数据，为产品打下坚实的基础。根据数据的性质和体量，你可能需要平台工程师或数据工程师。你还需要建立查询和分析数据的系统，以便快速定位问题。

3. 最后，你将致力于优化 AI 系统。这并不一定涉及训练模型，包括设计评估指标、构建评估系统、执行实验、优化 RAG 检索、调试随机性问题等。机器学习工程师非常擅长这些工作（尽管 AI 工程师也可以通过学习掌握这些技能）。但如果你没有完成前面的基础步骤，招聘机器学习工程师可能并不明智。

除此之外，你始终需要一个领域专家。在小型企业，这通常是创始团队的成员；而在大型企业，产品经理也可以担任这一角色。角色的介入时机至关重要。在不恰当的时间（例如，过早让机器学习工程师介入）招聘人员或介入顺序不对，不仅浪费时间和金钱，还会导致频繁的人员更替。此外，在前面两个阶段定期与机器学习工程师沟通（但不全职让他们介入）将有助于公司为未来的成功打下坚实的基础。

原文链接：

https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-ii/

声明：本文由 InfoQ 翻译，未经许可禁止转载。