Linkedin领英大模型落地实践系列 - 构建生成式人工智能产品的思考

前言

Linkedin领英有很好的场景以及数据积累，在生成式人工智能的应用方面做了不少落地的实践探索，之前介绍过两篇。

Linkedin领英大模型落地实践系列 - 首个生成式人工智能项目走过的5个坑 & Linkedin的GraphRAG客服问答系统实践

今天介绍第三篇，和几天前的内容有些类似，但从不同的角度进行解读。

正文:

在过去六个月里，我们的LinkedIn团队一直在努力开发一种新的人工智能驱动体验。我们想重新构想我们的会员进行求职和浏览专业内容的方式。

生成性人工智能的爆炸性发展让我们暂停思考，现在有哪些是一年前不可能的。我们尝试了许多想法，但没有真正产生共鸣，最终发现将每个动态和职位发布转变为跳板的力量：

• 获取更快的信息 例如 从帖子中提取要点或了解一家公司的最新动态  

• 连接思路 例如 评估您与职位发布的匹配度  

• 获得建议 例如 改进您的个人资料或为面试做准备  

• 还有更多…  

构建起来容易吗 什么地方做得好，什么地方没有 建立在生成式人工智能之上并不都是一帆风顺，我们在很多地方遇到了障碍 我们想拉开“工程”的幕后，分享哪些方面比较顺利，我们在哪些地方遇到困难，以及接下来会发生什么

概述  

让我们通过一个真实的场景来展示系统是如何工作的。  

想象一下你正在浏览LinkedIn动态，偶然看到一篇关于设计中无障碍性的引人注目的帖子。在帖子旁边，你会看到一些入门问题，以便更深入地探讨这个主题。你很好奇，点击了“在科技公司中无障碍性推动商业价值的一些例子是什么？”  

以下是后台发生的事情：  

1. 选择合适的代理：这是您旅程的起点。我们的系统处理您的问题并决定哪个人工智能代理最适合处理它。在这种情况下，它识别出您对科技公司中的无障碍性的兴趣，并将您的查询转发给一位专注于通用知识寻求问题的人工智能代理。  

2. 收集信息：是时候进行一些实地工作了。人工智能代理调用内部API与必应的组合，搜索具体示例和案例研究，突出设计中的无障碍性如何为科技带来商业价值。我们正在创建一个档案来支撑我们的回答。  

3. 撰写答复：掌握必要的信息后，代理现在可以撰写答复。它过滤和综合数据，形成一个连贯的信息性答案，为您提供关于无障碍倡议如何推动科技公司商业价值的清晰例子。为了避免生成一大段文字并使体验更具互动性，内部API被调用来为答复装饰附件，如文章链接或帖子中提到的人的个人资料。  

您可能会接着问“我如何将我的职业转向这个领域”，我们将重复这个过程，但这次将您引导到一个职业和工作人工智能代理。只需几次点击，您就可以深入了解任何主题，获得可操作的见解或找到您下一个重大机会。

大部分这一切都是由于大型语言模型（LLMs）的出现，我们认为分享关于我们在其基础上构建时所面临的挑战的幕后故事会很有趣。

整体设计

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

你们中的一些人可能从上面的解释中注意到我们的流程遵循被称为检索增强生成（RAG）的模式，这是生成AI系统中常见的设计模式。构建这个流程实际上比我们预期的要简单得多。仅仅几天，我们就建立了基本框架并使其运行起来：

• 路由：决定查询是否在范围内以及将其转发到哪个AI代理。代理的示例包括：职位评估、公司理解、帖子的要点等。  

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

• 生成：以精确为导向的步骤，筛选通过检索得到的嘈杂数据，进行过滤并生成最终响应。

调整“路由”和“检索”感觉更自然，因为它们具有分类特性：我们构建了开发集，并通过提示工程和内部模型进行了拟合。现在，生成就另当别论了。它遵循80/20原则；获得80%很快，但最后的20%却花费了我们大部分的工作。当你产品的期望是99%以上的答案应该是优秀的，即使使用最先进的模型，仍然需要大量的工作和创意来获取每1%的进步。  

对我们有效的方法：

• 固定的三步流程  

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

• 基于嵌入的检索（EBR）由内存数据库支持，作为我们“穷人的微调”，直接将响应示例注入到提示中  

• 每一步的特定评估流程，特别是针对路由/检索

开发速度  

我们希望在多个团队中快速行动，因此决定将任务分成由不同人员开发的独立代理（即，AI代理）：一般知识、工作评估、后续要点等。  

然而，这种方法带来了重大妥协。通过并行化任务，我们在速度上有所提升，但也付出了碎片化的代价。当后续与助手的交互可能由不同的模型、提示或工具管理时，保持统一的用户体验变得具有挑战性。  

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

• 一个小型“横向”工程舱，处理常见组件并专注于整体体验。这包括：

• 产品托管服务  

• 评估/测试工具  

• 所有垂直领域使用的全球提示模板 例如 代理的全球身份 会话历史 越狱防御等  

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

• 一个服务器驱动的UI框架 可以在不更改客户端代码或发布的情况下发布新的UI变化  

• 几个具有自主权的“垂直”工程舱的示例：

• 个性化帖子总结  

• 职位匹配评估  

• 面试技巧  

我们成功的因素是

• 分而治之但限制代理的数量  

• 一个集中评估管道与多轮对话  

• 共享提示模板（例如身份定义） 用户体验模板 工具和仪器

我们所面临的挑战  

评估  

评估我们答案的质量比预期的要困难得多。这些挑战大致可以分为三个方面：制定准则、扩展注释和自动评估。

• 制定指导方针是第一个障碍。以职位评估为例：点击“评估我与该职位的契合度”后得到“你非常不符合”并没有什么用处。我们希望它既要客观也要富有同情心。有些成员可能正在考虑转行到当前不太适合的领域，需要帮助来了解自己的差距和下一步该做什么。确保这些细节的一致性对我们的标注者评分的统一性至关重要。  

• 标注的扩展是第二步。最初团队中的每个人都参与其中（产品、工程、设计等），但我们知道需要一种更有原则的方法，确保标注者的一致性和多样性。我们的内部语言学团队建立了工具和流程，让我们能够评估高达500个每日对话，并获得以下指标：总体质量得分、幻觉率、负责人工智能违规情况、一致性、风格等。这成为我们理解趋势、迭代提示并确保我们准备好上线的主要标志。  

• 自动评估是我们追求的终极目标，但仍在不断进展中。没有自动评估，工程师只能凭眼睛判断结果，并在有限的示例上进行测试，且知道指标需要1天以上的延迟。我们正在构建基于模型的评估器，以估算上述指标，并允许更快的实验，在幻觉检测方面取得了一些成功（但这并不容易）。

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

我们正在努力的方向：用于更快迭代的端到端自动评估管道。

调用内部API

LinkedIn 拥有大量关于人员、公司、技能、课程等的独特数据，这些数据对于构建具有独特和差异化价值的产品至关重要。然而，LLM 并未使用这些信息进行训练，因此无法直接用于推理和生成响应。解决此问题的一种标准模式是设置一个检索增强生成（RAG）管道，通过该管道调用内部 API，并将其响应注入后续的 LLM 提示中，以提供额外的上下文来支持响应。

这些独特数据大多通过各种微服务的 RPC API 在内部公开。虽然这对人类以编程方式调用非常方便，但对 LLM 来说并不友好。我们通过将“技能”封装在这些 API 周围来解决这个问题。每项技能都有以下组件：

• 一个便于人类（因此也便于大型语言模型）理解的API功能描述，以及何时使用它  

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

• 适合大型语言模型的输入和输出模式  

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

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

• 在大型语言模型友好的模式与实际RPC模式之间映射的业务逻辑  

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

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

我们编写提示，让LLM决定使用哪种技能来解决特定任务（通过规划进行技能选择），然后还输出调用该技能的参数（函数调用）。由于调用参数必须与输入模式匹配，我们要求LLM以结构化的方式输出这些参数。大多数LLM是基于YAML和JSON进行结构化输出的训练。我们选择YAML，因为它比JSON更简洁，因此消耗的token更少。

我们遇到的挑战之一是，虽然大约90%的时间，LLM的响应中包含正确格式的参数，但约10%的时间LLM会出错，常常输出根据提供的模式无效的数据，或者更糟的是，甚至不符合有效YAML。这些错误对于人类来说虽然很容易发现，但导致解析这些数据的代码崩溃。10%的错误率足够高，不容忽视，因此我们着手解决这个问题。

解决这个问题的标准方法是检测错误，然后重新提示LLM，让其在一些额外指导下纠正错误。虽然这种技术有效，但会增加非小的延迟，并且由于额外的LLM调用，会消耗宝贵的GPU资源。为了绕过这些限制，我们最终编写了一个内部的防御性YAML解析器。

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

我们正在进行的工作：一个统一的技能注册表，以动态发现和调用作为LLM友好技能打包的API/代理，这些技能遍布我们的生成式AI产品。

一致的质量

团队在第一个月内实现了我们目标提供的基本体验的80%，然后花了额外的四个月试图超过95%的完整体验完成度——我们努力改善、微调和提升各个方面。我们低估了检测和减轻幻觉的挑战，以及质量评分提高的速度——最初迅速上升，然后迅速停滞。

对于允许这种错误水平的产品体验，使用生成性人工智能构建是令人耳目一新的简单。然而，它也带来了不可实现的期望，最初的进展带来了虚假的“快到了”的感觉，随着每增加的1%的改进速度显著减缓，这种感觉变得令人沮丧。

构建助手感觉像是偏离了更“有原则”的机器学习，更像是在调整专家系统中的规则。因此，尽管我们的评估变得越来越复杂，但我们的“训练”主要是提示工程，这更像是一门艺术而不是科学。

我们正在努力的方向：微调大型语言模型（LLMs），使我们的流程更加数据驱动。

容量与延迟  

容量和感知的成员延迟始终是我们关注的焦点。一些维度：  

• 质量与延迟：像思维链（CoT）这样的技术在提高质量和减少幻觉方面非常有效。但它们需要成员从未看到的令牌，因此增加了他们感知的延迟。  

• 吞吐量与延迟：在运行大型生成模型时，初次令牌时间（TTFT）和令牌间时间（TBT）通常会随着利用率的上升而增加。在TBT的情况下，有时它可以是线性的。如果你愿意牺牲这两个指标，获得2倍或3倍的每秒令牌数（TPS）并不罕见，但我们最初必须将它们限制得相当严格。  

• 成本：GPU集群并不容易获得且成本高昂。起初，我们甚至不得不制定时间表，以决定何时可以测试产品，否则会消耗过多的令牌，并使开发人员无法工作。  

• 端到端流式处理：完整的答案可能需要几分钟才能完成，因此我们使所有请求流式传输以减少感知延迟。更重要的是，我们实际上在我们的管道中进行端到端流式处理。例如，LLM响应决定调用哪些API是逐步解析的，我们一有参数准备好就立即发起API调用，而无需等待完整的LLM响应。最终合成的响应也通过我们的实时消息基础设施实现流式传输，并对信任/负责任的人工智能分类等内容进行增量处理。  

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

这些之间有时会产生有趣的相互作用。例如，在我们最初的产品中，我们只是将TTFT与成员延迟直接关联。随着我们解决幻觉问题，并且“思维链”在我们的提示中变得突出，我们忽视了TBT会对我们造成更大的伤害，因为任何“推理”令牌都会多倍成员延迟（例如，对于一个200令牌的推理步骤，即使是10毫秒的TBT增加也意味着额外的2秒延迟）。这导致我们的一次公共上线突然频繁发出警报，提示某些任务超时，我们很快就不得不增加容量以缓解问题。

我们正在进行的工作是:

• 将简单任务转移到内部精调模型  

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

• 减少每一步的浪费token  

  
  

这不错！特别是后续建议可以引导你进入一个维基百科风格的好奇心兔子洞。随着我们继续提升质量、开发新功能和优化速度管道，我们将很快向更多用户推出。