Skip to content
随着大型语言模型（LLM）技术日渐成熟，各行各业加快了 LLM 应用落地的步伐。为了改进 LLM 的实际应用效果，业界做出了诸多努力。
近期，领英（LinkedIn）团队分享了他们在构建生成式 AI 产品的过程中总结的宝贵经验。领英表示基于生成式人工智能构建产品并非一帆风顺，他们在很多地方都遇到了困难。
以下是领英博客原文。
过去六个月，我们 LinkedIn 团队一直在努力开发一种新的人工智能体验，试图重新构想我们的会员如何进行求职和浏览专业内容。
生成式人工智能的爆发式增长让我们停下来思考，一年前不可能实现的事情现在有了哪些可能。我们尝试了很多想法，但都没有成功，最终发现产品需要如下关键点：
更快地获取信息，例如从帖子中获取要点或了解公司最新动态。
将信息点连接起来，例如评估您是否适合某个职位。
获取建议，例如改善您的个人资料或准备面试。
……
我们通过一个现实场景来展示新开发的系统是如何工作的。想象一下，您正在滚动浏览 LinkedIn 信息流，偶然发现了一篇关于设计中的可访问性的有趣帖子。除了这篇文章之外，您还会刷到一些入门问题，以便更深入地研究该主题，您很好奇，例如点击「科技公司中可访问性推动商业价值的例子有哪些？」
系统后台会发生如下操作：
选择合适的智能体：系统会接受您的问题并决定哪个 AI 智能体最适合处理它。在这种情况下，它会识别您对科技公司内部可访问性的兴趣，并将您的查询路由到专门执行通用知识搜索的 AI 智能体。
收集信息：AI 智能体调用内部 API 和 Bing 的组合，搜索具体示例和案例研究，突出设计的可访问性如何为技术领域的商业价值做出贡献。
制定回复：有了必要的信息，智能体现在可以撰写回复。它将数据过滤并合成为连贯、信息丰富的答案，为您提供清晰的示例，说明可访问性计划如何为科技公司带来商业价值。为了使体验更具交互性，系统会调用内部 API 来使用文章链接或帖子中提到的人员简介等附件。
你可能会提问「我如何将我的职业生涯转向这个领域」，那么系统会重复上述过程，但现在会将你转给职业和工作（career and job）AI 智能体。只需点击几下，您就可以深入研究任何主题，获得可行的见解或找到下一个工作机会。
大部分新功能是借助 LLM 技术才成为可能。
总体设计
系统 pipeline 遵循检索增强生成（RAG），这是生成式人工智能系统的常见设计模式。令人惊讶的是，建设 pipeline 并没有我们预期的那么令人头疼。在短短几天内，我们就建立并运行了基本框架：
路由：决定查询是否在范围内，以及将其转发给哪个 AI 智能体。
检索：面向 recall 的步骤，AI 智能体决定调用哪些服务以及如何调用（例如 LinkedIn 人物搜索、Bing API 等）。
生成：面向精度的步骤，筛选检索到的噪声数据，对其进行过滤并生成最终响应。
图 1：处理用户查询的简化 pipeline。KSA 代表「知识共享智能体」，是数十种可以处理用户查询的智能体之一。
关键设计包括：
固定三步 pipeline；
用于路由 / 检索的小型模型，用于生成的较大模型；
基于嵌入的检索 (EBR)，由内存数据库提供支持，将响应示例直接注入到提示（prompt）中；
每步特定的评估 pipeline，特别是对于路由 / 检索。
开发速度
我们决定将开发任务拆分为由不同人员开发独立智能体：常识、工作评估、职位要点等。
通过并行化开发任务，我们提高了开发速度，但这是以「碎片」为代价的。当与通过不同的模型、提示或工具进行管理的助手（assistant）进行后续交互时，保持统一的用户体验变得具有挑战性。
为了解决这个问题，我们采用了一个简单的组织结构：
一个小型「水平（horizontal）」工程 pod，处理通用组件并专注于整体体验，其中包括：
托管产品的服务
评估 / 测试工具
所有垂直领域使用的全局提示模板（例如智能体的全局身份（identity）、对话历史、越狱防御等）
为 iOS/Android/Web 客户端共享 UX 组件
服务器驱动的 UI 框架，用于发布新的 UI 更改，而无需更改或发布客户端代码。
关键设计包括：
分而治之，但限制智能体数量；
具有多轮对话的集中式评估 pipeline；
共享提示模板（例如「身份（identity）」定义）、UX 模板、工具和检测
评估
事实证明，评估响应的质量比预期的更加困难。这些挑战可大致分为三个领域：制定指南（guideline）、扩展注释和自动评估。
制定 guideline 是第一个障碍。以工作评估为例：点击「评估我是否适合这份工作」并得到「你非常适合」并没有多大用处。我们希望响应既真实又富有同理心。一些用户可能正在考虑转行到他们目前不太适合的领域，并需要帮助了解差距和后续步骤。确保这些细节一致对注释器非常关键。
扩展注释是第二步。我们需要一致和多样化的注释器。我们内部的语言学家团队构建了工具和流程，以评估多达 500 个日常对话并获取相关指标：整体质量得分、幻觉率、AI 违规、连贯性、风格等。
自动评估工作目前仍在进行中。如果没有自动评估，工程师只能目测结果并在一组有限的示例上进行测试，并且要延迟 1 天以上才能了解指标。我们正在构建基于模型的评估器来评估上述指标，并努力在幻觉检测方面取得一些成功，端到端自动评估 pipeline 将实现更快的迭代。
图 2：评估步骤。
调用内部 API
LinkedIn 拥有大量有关人员、公司、技能、课程等的独特数据，这些数据对于构建提供差异化价值的产品至关重要。然而，LLM 尚未接受过这些信息的训练，因此无法使用它们进行推理和生成响应。解决此问题的标准模式是设置检索增强生成 (RAG) pipeline，通过该 pipeline 调用内部 API，并将其响应注入到后续的 LLM 提示中，以提供额外的上下文来支持响应。
许多此类数据通过各种微服务中的 RPC API 在内部公开。虽然这对于人类以编程方式调用非常方便，但对 LLM 来说并不友好。我们通过围绕这些 API 包装「技能」来解决这个问题。每个技能都有以下组件：
关于 API 的功能以及何时使用的人类友好描述
调用 RPC API 的配置（端点、输入模式、输出模式等）
LLM 友好的输入和输出模式
原始类型（字符串 / 布尔 / 数字）值
JSON 模式的输入和输出模式描述
LLM 友好模式和实际 RPC 模式之间映射的业务逻辑
这些技能旨在让 LLM 能够执行与产品相关的各种操作，例如查看个人资料、搜索文章 / 人员 / 职位 / 公司，甚至查询内部分析系统。同样的技术也用于调用非 LinkedIn API，例如 Bing 搜索。
图 3：使用技能调用内部 API。
我们编写提示，要求 LLM 决定使用什么技能来解决特定的工作（通过规划选择技能），然后输出参数来调用技能（函数调用）。由于调用的参数必须与输入模式匹配，因此我们要求 LLM 以结构化方式输出它们。大多数 LLM 都接受过用于结构化输出的 YAML 和 JSON 训练。我们选择 YAML 是因为它不太冗长，因此比 JSON 消耗更少的 token。
我们遇到的挑战之一是，虽然大约 90% 的情况下，LLM 响应包含正确格式的参数，但大约 10% 的情况下，LLM 会出错，并且经常输出格式无效的数据，或者更糟糕的是甚至不是有效的 YAML。
这些错误对人类来说是微不足道的，但却会导致解析它们的代码崩溃。10% 是一个足够高的数字，我们不能轻易忽视，因此我们着手解决这个问题。
解决此问题的标准方法是检测它，然后重新提示 LLM 要求其纠正错误并提供一些额外的指导。虽然这种方法有效，但它增加了相当大的延迟，并且由于额外的 LLM 调用而消耗了宝贵的 GPU 容量。为了规避这些限制，我们最终编写了一个内部防御性 YAML 解析器。
通过对各种有效负载的分析，我们确定了 LLM 所犯的常见错误，并编写了代码以在解析之前适当地检测和修补（patch）这些错误。我们还修改了提示，针对其中一些常见错误注入提示，以提高修补的准确率。我们最终能够将这些错误的发生率减少到约 0.01%。
我们目前正在构建一个统一的技能注册表，用于在我们的生成式人工智能产品中，动态发现和调用打包为 LLM 友好技能的 API / 智能体。
容量和延迟
容量和延迟始终是首要考虑因素，这里提及一些考量维度：
质量与延迟：思想链 (CoT) 等技术对于提高质量和减少幻觉非常有效，但需要从未见过的 token，因此增加了延迟。
吞吐量与延迟：运行大型生成模型时，通常会出现 TimeToFirstToken (TTFT) 和 TimeBetweenTokens (TBT) 随着利用率的增加而增加的情况。
成本：GPU 集群不易获得且成本高昂。一开始我们甚至必须设定测试产品的时间表，因为会消耗太多 token。
端到端流式处理（streaming）：完整的答案可能需要几分钟才能完成，因此我们流式处理所有请求，以减少感知延迟。更重要的是，我们实际上在 pipeline 中端到端地进行流式处理。例如，决定调用哪些 API 的 LLM 响应是逐步解析的，一旦参数准备好，就会触发 API 调用，而无需等待完整的 LLM 响应。最终的综合响应也会使用实时消息传递基础设施一路传输到客户端，并根据「负责任的 AI」等进行增量处理。
异步非阻塞 pipeline：由于 LLM 调用可能需要很长时间才能处理，因此我们通过构建完全异步非阻塞 pipeline 来优化服务吞吐量，该 pipeline 不会因 I/O 线程阻塞而浪费资源。
感兴趣的读者可以阅读博客原文，了解更多研究内容。
原文链接：https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product
作者丨 Eugene Yan et al.
译者丨明知山
策划丨褚杏娟
常有人错误地将这样一句话归因于一些领导者，尽管它可能完全是虚构的：“外行谈论战略和战术，内行关注运营。”从战术的角度看，我们面对的是一系列独特的问题，从运营角度，我们看到的是需要解决的组织功能失调模式。在战略视角看到的是机会，在运营视角看到的是需要应对的挑战。
在本系列文章的第一部分，我们介绍了 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 评估标准，即：
定义特定领域的测试（通过提示词自动引导）。它们可以是带有代码的断言，或者是采用“LLM 即评委”的形式。
强调将测试与人类判断对齐的重要性，使用户能够验证测试是否确实捕捉到了既定的标准。
随着系统（如提示词内容等）的变化不断迭代和优化测试标准。
EvalGen 为开发人员提供了评估构建过程的框架性理解，而不是将他们限制在特定工具的使用上。我们发现，一旦 AI 工程师获得了这种宏观视角，他们往往会选择采用更简洁的工具，或者根据自己的需求自行开发解决方案。
LLM 的组成部分远不止提示词编写和评估，其复杂性无法在此一一列举。关键在于 AI 工程师在采用工具之前要深入理解其背后的流程和原理。
持续地实验
机器学习产品与实验密切相关。不仅涉及 A/B 测试、随机对照试验，还包括频繁尝试修改系统的最小组件并进行离线评估。人们热衷于评估的真正原因并非仅仅为了可靠性和信心——而是为了让实验成为可能。你的评估越精确，就能越迅速地进行实验，进而更快地发现系统的最佳配置。
尝试采用不同的方法解决同一个问题是一种很常见的做法，因为现在的实验成本很低。收集数据和训练模型的高昂成本已经得到有效控制——提示词工程的成本仅略高于人力投入。确保你的团队成员都掌握了提示词工程的基础知识。这不仅能激发他们进行实验的热情，还能促进组织内部不同观点的交流与碰撞。
此外，实验不仅仅是为了探索，而是要学会利用它们。如果你手头有一个新的任务，可以考虑让团队的其他成员从不同的视角来处理它。尝试寻找更高效的方法，探索如思维链或 few-shot 提示词等技术，以提高工作质量。不要让工具限制了你的实验；如果是这样，那就重新构建它们，或者购买新的工具。
最后，在产品或项目规划阶段，务必留出足够的时间来构建评估机制并进行多项实验。在考虑工程产品的规格时，为评估过程设定明确的标准。在制定路线图时，不要低估了实验所需的时间。要预见到在生产交付之前，可能需要进行多轮的开发和评估迭代。
让每个人都能使用新的 AI 技术
随着生成式 AI 采用率的增加，我们希望整个团队——不仅仅是专家——都能理解并自信地使用这项新技术。没有比亲自实践更好的方式去培养对大型语言模型工作原理的直观理解了，比如它们的响应延迟、故障模式和用户体验。LLM 相对容易使用：你无需编码技能就可以为流程管道提升性能，每个人都可以通过提示词工程和评估做出实质性的贡献。
教育是关键环节，可以从提示词工程的基础开始，如利用 n-shot 和思维链等技术，引导模型生成期望的输出。拥有这方面知识的人还可以教授更技术性的内容，例如大型语言模型本质上是自回归的。换句话说，虽然输入可以并行处理，但输出是顺序的。因此，生成延迟更多地取决于输出的长度而非输入的长度——这是在设计用户体验和设定性能预期时需要考虑的一个关键因素。
我们还可以提供更多实践和探索的机会，比如举办一次黑客马拉松。虽然让整个团队投入数日时间在探索性项目上看起来成本较高，但最终的成果可能会超出你的预期。我们见证了一个团队通过黑客马拉松，在短短一年内就实现了他们原本计划三年完成的路线图。另一个团队则通过黑客马拉松，引领了一场用户体验的范式转变，这种转变现在因为大型语言模型的加入而成为可能。
不要掉入“AI 工程就是一切”的陷阱
随着新职位名称的出现，人们往往容易过分夸大这些角色的能力。这通常会导致在实际工作职责变得逐渐明确时，人们不得不去做一些痛苦的调整。新入行的人和负责招聘的经理可能会夸大声明或抱有不切实际的期望。在过去的十年里，这类显著的例子包括：
数据科学家：“在统计学方面比任何软件工程师都强，在软件工程方面比任何统计学家都强的人”
机器学习工程师（MLE）：以软件工程为中心的机器学习视角
最初，许多人认为数据科学家单枪匹马就能驾驭数据驱动的项目。然而，现实情况已经清晰地表明，为了有效地开发和部署数据产品，数据科学家必须与软件工程师和数据工程师紧密合作。
这种误解在 AI 工程师这一新兴角色上再次出现，一些团队误以为 AI 工程师就是他们需要的一切。实际上，构建机器学习或 AI 产品需要一个由多种专业角色 组成的团队。我们与十多家公司就 AI 产品进行了深入咨询，发现他们普遍都陷入了认为“AI 工程就是一切”的陷阱。这种认知导致产品往往难以越过演示阶段，因为公司忽视了构建产品所涉及的关键方面。
例如，评估和度量对于将产品从单一的领域检查阶段扩展到广泛应用阶段来说至关重要。有效的评估能力与机器学习工程师通常所具备的优势相辅相成——一个完全由 AI 工程师组成的团队可能缺乏这些技能。Hamel Husain 在他最近的研究中强调了这些技能的重要性，包括监测数据漂移和制定针对特定领域的评估标准。
以下是在构建 AI 产品的过程中你需要的不同类型角色，以及他们在项目各个阶段大致的参与时机：
首先，专注于构建产品。这个阶段可能涉及 AI 工程师，但并非必须。AI 工程师在快速原型设计和迭代产品方面具有显著的价值（用户体验、数据处理管道等）。
随后，通过系统化地收集和分析数据，为产品打下坚实的基础。根据数据的性质和体量，你可能需要平台工程师或数据工程师。你还需要建立查询和分析数据的系统，以便快速定位问题。
最后，你将致力于优化 AI 系统。这并不一定涉及训练模型，包括设计评估指标、构建评估系统、执行实验、优化 RAG 检索、调试随机性问题等。机器学习工程师非常擅长这些工作（尽管 AI 工程师也可以通过学习掌握这些技能）。但如果你没有完成前面的基础步骤，招聘机器学习工程师可能并不明智。
除此之外，你始终需要一个领域专家。在小型企业，这通常是创始团队的成员；而在大型企业，产品经理也可以担任这一角色。角色的介入时机至关重要。在不恰当的时间（例如，过早让机器学习工程师介入）招聘人员或介入顺序不对，不仅浪费时间和金钱，还会导致频繁的人员更替。此外，在前面两个阶段定期与机器学习工程师沟通（但不全职让他们介入）将有助于公司为未来的成功打下坚实的基础。
原文链接：
https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-ii/
声明：本文由 InfoQ 翻译，未经许可禁止转载。
内容推荐
在这个智能时代，AI 技术如潮水般涌入千行百业，深度重塑生产与生活方式。大模型技术引领创新，精准提升行业效率，从教育个性化教学到零售精准营销，从通信稳定高效到金融智能风控，AI 无处不在。它不仅是技术革新的先锋，更是社会经济发展的强大驱动力。在 AI 的赋能下，我们正迈向一个更加智能、便捷、高效的新未来，体验前所未有的生活变革与行业飞跃。
今日荐文
两天内，Meta 和 Mistral 两款主流大模型打擂台！已经不仅卷性能了，谁更便宜就用谁？
Llama 3.1 源模型泄露背后：失手的 GitHub，破碎的 Meta，好在最小参数都能打脸GPT-4o！
Claude Sonnet 3.5 口碑爆棚！10 倍速开发，“2 个月内用 Rust 从零构建完一款产品”
没投简历却被陌生HR随机辱骂，HR道歉称压力大；OPPO 回应“大量裁撤华为系员工”；传百度新任公关一号位或为蒋昕捷｜AI 周报
开源独角兽 GitLab 走上“卖身”路！前工程师拆台：赚钱的业务不好好运营，开发了一堆没用的功能