领英登录出现意外错误，领英出现错误再试一次

2024-08-07 15:46:00 | 来源: 互联网整理

从LinkedIn 选择

作者：胡安·巴勃罗·博塔罗、卡蒂克·兰戈帕尔

机器之心编译

机器之心编辑部

随着大规模语言模型（LLM）技术的日益成熟，LLM跨行业应用的实施步伐正在加快。业界为提高LLM的实际效果做出了很多努力。

近日，LinkedIn团队分享了他们在构建生成式AI产品方面的宝贵经验。 LinkedIn表示，构建基于生成式AI的产品并非一帆风顺，在很多领域都面临着挑战。

以下为LinkedIn博客原文。

在过去的六个月里，我们的LinkedIn 团队一直在努力开发新的人工智能体验，重新构想会员申请工作和查看专业内容的方式。

生成式人工智能的爆炸性增长让我们停下来思考一年前不可能的事情现在变得可能。在尝试了很多想法都没有成功后，我终于意识到这个产品需要以下几个关键点：

更快地获取信息、从帖子中获取关键要点、获取最新的公司新闻等等。

连接信息点，包括评估职位的适合性。

获取有关改善个人资料、准备面试等方面的建议。

.

使用真实场景来演示新开发的系统如何工作。想象一下，您正在浏览LinkedIn feed，并看到一篇关于设计中的可访问性的有趣帖子。除了本文之外，如果您感兴趣，我们还提供了一些介绍性问题来深入探讨该主题，例如“在技术公司中可访问性驱动商业价值的一些示例是什么？”

以下操作均在系统后台进行：

选择正确的智能体：系统收到问题并确定最佳的人工智能智能体来处理该问题。在这种情况下，我们识别技术公司内部的可访问性问题，并将查询路由到专门从事一般知识搜索的人工智能代理。

收集信息：AI 代理调用内部API 和Bing 的组合来搜索具体示例和案例研究，突出设计中的可访问性如何为技术中的商业价值做出贡献。

创建响应：准备好必要的信息后，代理可以创建响应。过滤和综合数据以生成一致、信息丰富的答案，并提供清晰的示例，说明无障碍工作如何为科技公司带来商业价值。为了使体验更具互动性，我们会使用附件进行内部API 调用，例如帖子中提到的文章或个人资料的链接。

当您问“我如何将我的职业生涯转向这个领域？”时，系统会重复上述过程，但这次您将被引导至职业和工作人工智能代理。只需点击几下，您就可以深入研究任何主题，获得可行的见解，并找到下一个工作机会。

大多数新功能都是在LLM技术的帮助下实现的。

总体设计

系统管道遵循搜索增强生成（RAG），这是生成式人工智能系统的常见设计模式。令人惊讶的是，建设管道并没有我想象的那么令人头疼。我在短短几天内就建立并运行了一个基本框架。

路由：确定查询是否在范围内以及将查询路由到哪个AI 代理。

Get：面向调用的步骤。 AI代理决定调用哪些服务以及如何调用它们（例如LinkedIn人物搜索、Bing API等）。

生成：精确密集型步骤，筛选和过滤获取的噪声数据以生成最终响应。

图1：用于处理用户查询的简化管道。 KSA 代表“知识共享代理”，是可以处理您的查询的数十个代理之一。

主要设计包括：

固定3 步管道。

用于路由/检索的小型模型，用于生成的大型模型。

具有内存数据库的嵌入式检索(EBR) 将示例响应直接插入提示中。

每个步骤的特定评估管道，尤其是路由/检索。

开发速度

我们决定将开发任务划分为不同人开发的独立代理，例如常识、工作评估、工作积分。

并行化开发任务可以提高开发速度，但代价是“碎片化”。当与通过不同模型、提示或工具管理的助手进行后续交互时，保持统一的用户体验变得困难。

为了解决这个问题，我们采用了简单的组织结构。

小型“水平”工程荚，处理常见组件并专注于整体体验，包括：

托管产品服务

评估/测试工具

跨行业使用的全局提示模板（全局座席ID、对话历史记录、越狱保护等）

共享iOS/Android/Web 客户端的UX 组件

服务器驱动的UI 框架，用于公开新的UI 更改，而无需更改或公开客户端代码。

主要设计包括：

分而治之，但限制代理数量。

具有多轮交互的集中式评估管道。

共享提示模板（例如“身份”定义）、UX 模板、工具和检测

评价

评估答复的质量比预期的要困难。这些挑战可大致分为三个领域：指南制定、注释扩展和自动评估。

制定指导方针是第一个障碍。例如，考虑工作评估。单击“评估您是否适合这份工作”并得到“您非常适合”的结果并没有多大意义。我们希望我们的回答真实且具有相关性。一些用户可能正在考虑将职业转移到他们目前不太适合的领域，并需要帮助了解差距和后续步骤。对于注释者来说，确保这些细节的一致性非常重要。

扩展注释是第二步。我们需要一致且多样化的注释者。我们的内部语言学家团队构建了工具和流程来评估多达500 个日常对话，并获取相关指标，例如总体质量得分、幻觉率、人工智能违规、连贯性、风格等。

自动化评估工作仍在进行中。如果没有自动化评估，工程师只能目视检查结果并在有限的示例上进行测试，从而导致理解指标的时间延迟一天或更长时间。我们正在构建一个基于模型的评估器来评估上述指标，并努力在幻觉检测方面取得一些成功。端到端自动化评估管道可实现更快的迭代。

图2：评估程序。

调用内部API

LinkedIn 拥有大量有关人员、公司、技能、课程等的专有数据，这些数据对于构建提供差异化价值的产品至关重要。然而，由于法学硕士没有接受过有关此信息的培训，因此它无法使用此信息进行推理并生成响应。解决此问题的标准模式是设置一个检索扩展生成(RAG) 管道，该管道调用内部API 并将响应注入到后续的LLM 提示中，从而提供额外的上下文来支持响应。

其中大部分数据是通过各种微服务的RPC API 在内部公开的。这对于人类以编程方式调用非常有用，但不适合LLM。我们通过围绕这些API 包装“技能”来解决这个问题。每个技能都有以下组成部分：

以人性化的方式解释API 的用途以及何时使用它。

配置RPC API调用（端点、输入模式、输出模式等）

适合LLM的I/O模式

基本类型的值（字符串/布尔值/数字）

JSON Schema 输入和输出架构描述

LLM友好模式与真实RPC模式映射的业务逻辑

这些技能旨在使法学硕士能够执行各种与产品相关的操作，例如查看个人资料、搜索文章/人员/工作/公司，甚至查询内部分析系统。同样的技术也用于调用非LinkedIn API，例如Bing 搜索。

图3：使用技能调用内部API。

创建一个提示，要求LLM 决定使用哪种技能来解决特定工作（通过规划选择技能），并输出参数以调用该技能（函数调用）。调用的参数必须与输入模式匹配，因此我们要求LLM以结构化的方式输出参数。大多数法学硕士都接受过用于结构化输出的YAML 和JSON 培训。我们选择YAML 是因为它比JSON 更简洁并且消耗更少的令牌。

我们面临的挑战之一是，大约90% 的情况下，LLM 响应包含正确格式的参数，但大约10% 的情况下，LLM 会出错并返回无效的格式。它们经常输出丢失的数据，或更糟的是，输出数据。有效的YAML。

尽管这些错误对人类来说微不足道，但它们可能会导致解析它们的代码崩溃。 10% 是一个不容忽视的高数字，因此我们决定对此采取一些措施。

解决此问题的标准方法是检测问题并重新请求LLM 更正错误并提供额外指导。尽管这种方法有效，但额外的LLM 调用会显着增加延迟并消耗宝贵的GPU 容量。为了克服这些限制，我最终编写了一个内部防御性YAML 解析器。

通过对各种有效负载的分析，我们确定了LLM 遇到的常见错误，并编写了代码以在解析这些错误之前正确检测和修补这些错误。我们还修改了提示，以包含一些常见错误的提示，以提高修补的准确性。最终，我们能够将这些错误的发生率降低到大约0.01%。

我们目前正在构建一个统一的技能注册表，以动态发现和调用在生成人工智能产品中打包为支持LLM 的技能的API/代理。

容量和延迟

容量和延迟始终是首要考虑因素。以下是一些注意事项。

质量和延迟：思想链(CoT) 等技术对于提高质量和减少幻觉非常有用，但它们需要看不见的令牌，这会增加延迟。

吞吐量和延迟：运行大规模生成模型时，通常会看到TimeToFirstToken (TTFT) 和TimeBetweenTokens (TBT) 随着利用率的增加而增加。

成本：GPU集群不容易获得并且价格昂贵。我们甚至必须首先制定一个时间表来测试产品，因为消耗了太多代币。

端到端流式传输：完整的答案可能需要几分钟才能完成，因此我们流式传输所有请求以减少感知延迟。此外，它实际上在管道内执行端到端的流传输。例如，逐步解析确定调用哪个API的LLM响应，当参数准备好时，无需等待完整的LLM响应就触发API调用。最终的综合响应也会使用实时消息传递基础设施发送给客户，并基于“负责任的人工智能”等进行逐步处理。

异步非阻塞管道：由于LLM 调用可能需要很长时间才能处理，因此我们通过构建完全异步非阻塞管道来优化服务吞吐量，该管道不会因阻塞I/O 线程而浪费资源。

有兴趣的读者可以阅读博客原文，了解更多研究内容。

原文链接：https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product

版权声明：本文转载于网络，版权归作者所有。如有侵权，请联系本站编辑删除。