Linkedin领英AI实践经验分享

Takeaway from SioFU：

1. 多Agent的设计过程分而治之，拆解出公共的部分和垂直领域部分分别开发，能够保持一致性的同时大大提效
2. 巧妙地设计测评过程，动员团队所有角色共同参与到测评中保证上线质量
3. 将内部API翻译成LLM友好可利用的API，需要进一步丰富描述
4. 端到端的流式输出，获得关键信息后可快速进入下一步，明显降低时延

在过去的六个月里，LinkedIn 团队一直在努力开发一种全新的人工智能体验。我们希望重新设计会员的求职和浏览专业内容的方式。

随着生成式 AI 技术的突飞猛进，我们开始探索以往难以触及的可能性。尽管初期尝试多次未能达到预期，但我们最终发掘了将每个动态更新和招聘信息转变为信息获取、职位评估和职场建议的有效平台的巨大潜力。这一转变不仅加快了信息获取速度，还增强了职位适配的判断力和个人职业规划的指导。

构建过程的挑战与收获：构建基于生成式 AI 的应用并非易事，我们在多个方面遇到了阻碍。通过分享“幕后工程”的故事，我们希望展现我们的挑战与成就，以及未来的发展方向。

01

Overview

以一个实际场景为例，来看我们系统的实际运行过程：

想象你在滚动你的 LinkedIn 动态，偶然间发现了一个关于设计可访问性的有意思的帖子。在帖子旁边，你会看到一些入门问题，让你更深入地了解这个话题。你出于好奇点击了“在科技公司中，可访问性如何推动业务价值的例子是什么？”

以下是背后发生的事情：

1. 选择合适的 Agent：系统会分析你的问题，并确定最合适的 Agent 进行处理。此例中，系统依据你对科技公司中设计可访问性的兴趣，将你的问题定向到专门处理此类查询的 Agent。

2. 信息搜集：此时 Agent 需要搜集信息，通过调用内部 API 和 Bing，寻找展示设计可访问性如何提升科技公司商业价值的相关案例。

3. 生成回复：凭借搜集的资料，Agent 编制回答，具体展示如何通过增强可访问性来提升科技公司的商业价值。为了避免生成大段文字且增加互动性，系统还会通过调用内部 API 添加如相关文章链接或提及人物的简介等内容.
   
   

您可能会追问："我如何将我的职业生涯转向这个领域？"，系统会继续提供支持，此时会转由专门的职业和就业 Agent 处理。这一过程仅需几次点击，你便可以深入探讨任何主题，获取实际可行的见解或发现下一个重大机会。

我们的许多进展都得益于大型语言模型（"LLM"）的快速发展。分享在此基础上构建应用时遇到的挑战和经验，对我们来说是非常有价值的。

02What came easy

总体设计

Figure1. 处理用户查询的简化流程。KSA 代表 "知识共享"Agent，是可以处理用户查询的数十个Agent之一

您可能已经注意到，我们的系统采用了一种被称为检索增强生成（"RAG"）的设计模式，这是生成式 AI 系统中的常规配置。意外的是，建立这样的流程比我们预期的要简单。在短短几天内，我们就构建了基础框架：

• 路由（Routing）：确定查询是否在处理范围内，并决定将其分配给哪个 AI Agent。例如，这些Agent可能负责工作评估、公司分析或提取帖子的要点。

• 检索（Retrieval）：以召回为导向的步骤，AI Agent决定调用哪些服务以及如何调用（例如 LinkedIn 人员搜索、Bing API 等）。

• 生成（Generation）：这是一个以精度为目标的步骤，它会筛选并处理检索到的庞杂数据，生成最终的响应。
  
  

鉴于 "路由 "和 "检索 "的分类性质，对它们进行调整感觉更自然：我们创建了专用的开发集，并通过提示工程和内部模型进行了优化。然而，生成阶段的工作则更为复杂。这部分工作遵循 二八原则：快速完成前 80%的工作，而最后 20% 则需要投入大量精力。当产品的期望是 99%+ 的回答都应该很好时，即便使用最先进的模型也仍需大量工作和创造力来实现每一个 1% 的提升。

我们的有效做法包括：

• 设立了固定的三步流程

• 使用小型模型处理路由和检索任务，而生成任务则采用更大的模型

• 通过内存数据库支持的基于嵌入的检索（EBR），作为我们的低成本微调手段，直接将响应示例整合进提示中

• 针对各个步骤特殊设定评估流程，尤其是在路由和检索阶段
  
  

开发速度

为了在多个团队间快速进展，我们选择将任务分配给不同人员开发的各种独立 AI Agent，如常规知识、职位评估和摘要提取等。

然而，这种方法带来了显著的缺陷。通过任务并行处理，我们在速度上获得了提升，但代价是系统碎片化。当后续与助手的互动可能由不同的模型、提示或工具管理时，维护统一的用户体验变得具有挑战性。

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

• 一个小型的“横向”工程小组，负责处理公共组件并专注于整体体验。包括：

• 托管产品的服务

• 评估/测试工具

• 被所有垂直部门使用的全局提示模板（例如，Agent的全球身份、对话历史、越狱防御等）

• 为我们的 iOS/Android/Web 客户共享的 UX 组件

• 一个服务器驱动的 UI 框架，用于发布新的 UI 更改而无需客户端代码更改或发布。

• 几个具有Agent自主权的“垂直”工程小组，例如：

• 个性化帖子摘要

• 职位适配评估

• 面试技巧
  
  

我们的成功经验：

• 采用分而治之的策略，同时限制Agent数量

• 多轮对话的集中评估流程

• 共享Prompt模板（如"system prompt"）、UX设计模板、工具和仪表

03Where we struggled

Evaluation

评价我们回答的质量证明比我们预期的要困难得多。这些挑战主要涉及三个方面：制定评估标准、扩展数据标注和实现自动化评估。

• 制定评估标准 是首个难题。以职位评估为例：单纯告诉用户“你不适合这个职位”并没有太大帮助。我们的回答需要基于事实，同时也要体现出同理心。例如，对于那些希望转行但当前能力尚有不足的用户，我们需要帮助他们明确能力差距及后续步骤。保证这些细节的一致性是确保评估得分统一的关键。

• 扩展数据标注 是第二步。起初，团队中的每个人都参与评估（包括产品、工程和设计团队），但我们很快意识到需要一个更系统的方法，这要求注释者既要保持一致性也要具备多样性。我们的语言学团队开发了工具和流程，可以每天评估多达 500 个对话，收集包括总体质量评分、幻觉发生率、负责任 AI 的遵守情况、逻辑连贯性和风格等多个维度的数据。这成为我们洞察趋势、优化提示词以及确保产品上线前准备充分的重要依据。

• 自动评估 虽然是理想状态，但实现起来充满挑战。在没有自动化工具的情况下，工程师只能依靠肉眼判断和有限的样本进行测试，而且通常需要超过一天的时间来学习评估标准。我们正在开发基于模型的评估工具来快速进行实验，并在检测幻觉方面取得了一定的成果，但这个过程并不容易。

Figure2. 我们执行的评估步骤。工程师执行快速、粗略的评估，以获得方向性指标。注释员提供更细化的反馈，但周转时间约为 1 天。成员是最终的评判者，为我们提供规模，但某些指标的单次更改可能需要 3 天以上的时间

我们正在进行的工作：开发一个端到端的自动评估流程，以加快迭代速度。

调用内部API

LinkedIn 拥有大量关于个人、公司、技能和课程等的独特数据，这些数据对于打造具有独特价值和差异化的产品至关重要。然而，由于 LLM 未接受这些信息的训练，它无法直接利用这些数据进行推理和回答生成。我们采用的标准做法是建立一个检索增强生成（RAG）流程，通过这一流程调用内部 API，并将其响应嵌入到后续的 LLM 提示中，为生成的回答提供必要的背景信息。

这些独特的数据通过不同微服务的 RPC API 在内部公开，尽管这对程序化调用非常便利，但并不完全适合 LLM。为了解决这个问题，我们为这些 API 创建了“技能”包装。每项技能都包括以下几个部分：

• 人类（因此也是 LLM）友好的 API 功能描述及使用时机。

• 调用 RPC API 的配置（端点、输入架构、输出架构等）。

• LLM 友好的输入和输出架构

• 原始类型（字符串/布尔/数字）值

• JSON 模式风格的输入和输出模式描述

• 将 LLM 友好的架构与实际 RPC 架构进行映射的业务逻辑
  
  

这样的技能使 LLM 能够执行与我们的产品相关的各种操作，如查看个人资料、搜索文章/人员/职位/公司，甚至查询内部分析系统。这种技术也用于调用非 LinkedIn 的 API，如 Bing 搜索和新闻。

Figure3. 使用技能调用内部 API

我们设计了提示词，要求 LLM 决定使用什么技能来解决特定工作（通过规划选择技能），然后输出调用技能的参数（函数调用）。由于调用的参数必须与输入模式相匹配，因此我们要求 LLM 以结构化的方式输出这些参数。大多数 LLM 都是通过 YAML 和 JSON 进行结构化输出的。我们之所以选择 YAML，是因为它不太啰嗦，因此比 JSON 消耗更少的标记。

我们遇到的一个挑战是，尽管大多数时候 LLM 的响应格式正确，但大约 10% 的时间会出现错误，通常输出的数据不符合所提供的架构，甚至不是有效的 YAML。这些错误虽然对人类容易识别，但却使得解析代码出现问题。由于这类错误的比例足够高，我们无法忽视，因此我们着手解决这一问题。

解决这一问题的常规方法是检测错误后重新提示 LLM，要求其在额外的指导下纠正错误。虽然这种方法有效，但它增加了相当的延迟，并且因为额外的 LLM 调用而消耗了宝贵的 GPU 资源。为了规避这些限制，我们最终开发了一个内部防御性的 YAML 解析器。

通过分析各种数据负载，我们确定了 LLM 常见的错误，并编写了代码在解析前适当地检测和修复这些错误。我们还修改了我们的提示，在其中嵌入关于这些常见错误的提示，以提高修复的准确性。我们最终能够将这些错误的发生率降低到约 0.01%。

我们正在开发的内容：一个统一的技能注册表，用于动态发现和调用 API/Agent，并将其打包为 LLM 友好型技能，供我们的生成式人工智能产品使用。

质量稳定性

我们的团队在第一个月内就完成了基本体验的 80%，我们一直在努力完善、调整和改进各个方面，随后又花了四个月的时间试图达到95%的完整体验目标。但还是低估了检测和减少幻觉的挑战，也低估了质量分数的提高速度--最初是直线上升，然后迅速趋于平稳。

对于能够容忍这种程度错误的产品体验来说，使用生成式人工智能进行构建令人耳目一新。但它也带来了难以实现的期望，最初的速度让人产生一种 "就快成功了 "的错觉，而随后每提高 1%，改进速度就会明显放缓，这让人感到气馁。

构建这样的助手，感觉像是从更有原则的机器学习中脱离出来，更像是在专家系统中调整规则。因此，虽然我们的评估变得越来越复杂，但我们的“训练”主要是依赖prompt engineering，这与其说是一门科学，不如说是一门艺术。

我们正在进行的工作：微调大型语言模型（LLM），使我们的流程更加依赖数据驱动。

容量与延迟

容量和感知到的用户延迟始终是我们关注的重点。一些重要方面包括：

• 质量与延迟：如思维链（CoT）等技术在提高质量和减少幻觉方面非常有效，但它们需要消耗用户看不见的Token，因此增加了感知延迟。

• 吞吐量与延迟：运行大型生成模型时，随着使用率的增加，首次生成Token的时间（Time To First Token，TTFT）和Token之间的时间（Time Between Tokens，TBT）通常会增加。就TBT而言，有时可能是线性增长。如果愿意牺牲这两个指标，获得2倍或3倍的每秒Token数（TPS）并不罕见，但我们最初必须严格控制这些指标。

• 成本：GPU 集群不易获得且成本高昂。一开始我们甚至设定了测试产品的时间表，因为它会消耗过多Token，阻止开发人员工作。

• 端到端流式处理：完整回答可能需要几分钟时间，因此我们让所有请求都进行流式处理以减少感知延迟。更重要的是，我们实际上在整个流程中实现了端到端的流式处理。例如，LLM 响应决定调用哪些 API 会被逐步解析，我们在参数准备好后立即触发 API 调用，而不等待完整的 LLM 响应。最终合成的回应也通过我们的实时消息基础设施流式传输到客户端，通过增量处理（如信任/负责任的人工智能分类）一路流式传输到客户端。

• 异步非阻塞管道：由于 LLM 调用可能需要较长时间处理，我们通过构建一个完全异步的非阻塞管道优化了服务吞吐量，不会因 I/O 阻塞而浪费资源。

这些方面有时会相互作用。例如，我们最初只限制了 TTFT，因为这直接关系到我们最初产品的用户延迟。当我们解决幻觉问题并在提示中引入思维链时，我们忽略了 TBT 会给我们带来更大的影响，任何“推理”Token都会增加用户延迟（例如，对于200个Token的推理步骤，即使 TBT 增加 10 毫秒也意味着额外 2 秒的延迟）。这导致我们的一个公开发布突然发出警报，指出一些任务达到超时，我们迅速增加了容量以缓解这一问题。

我们正在进行的工作：

• 将更简单的任务转移到内部微调模型

• 为 LLM 部署提供更可预测的基础设施

• 减少每一步浪费的Token

04总结

我们已经说了很多，不如让产品自己来表达如何？