在过去的六个月里，我们 LinkedIn 团队一直在努力开发一个新的 AI 驱动体验。我们的目标是重新定义会员如何进行求职和浏览专业内容。

生成式 AI 的爆炸性发展让我们重新审视现有可能性。我们尝试了很多想法，但大多数都没有成功，直到我们发现可以将每条信息流和职位发布转变为以下几种跳板：

• 更快获取信息，如获取文章要点或了解公司的最新动态。
• 连接点滴，如评估你是否适合某个职位。
• 接受建议，如改进个人资料或准备面试。
• 以及更多内容...

构建过程是否顺利？哪些方面进展顺利，哪些方面遇到挑战？ 在生成式 AI 上构建并非一帆风顺，我们在很多方面遇到了困难。我们想揭开“工程”的帷幕，分享哪些部分比较顺利，哪些方面遇到了挑战，以及接下来我们将做什么。

概述

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

想象你正在浏览 LinkedIn 的信息流，偶然看到一篇关于设计中可访问性的有趣文章。在文章旁边，你会看到一些入门问题，以便深入探讨该主题。你很好奇并点击了“有哪些例子表明可访问性在科技公司中带来了业务价值？”

以下是后台发生的事情：

1. 选择合适的智能体：这是你旅程的开始。我们的系统接收到你的问题，并决定哪个 AI 智能体最适合处理它。在这种情况下，它识别出你对科技公司中可访问性的兴趣，并将你的查询路由到一个专门处理常识性问题的 AI 智能体。
2. 收集信息：现在是一些体力活的时间了。AI 智能体调用内部 API 和 Bing，搜索具体的例子和案例研究，突出设计中的可访问性如何为科技公司带来了业务价值。我们正在创建一个文档来支持我们的回答。
3. 撰写回答：在获取必要的信息后，智能体现在可以撰写回答。它过滤并综合数据，形成连贯且信息丰富的答案，为你提供清晰的例子，说明可访问性举措如何为科技公司带来业务价值。为了避免生成一大堆文字，并使体验更具互动性，内部 API 被调用以附加例如文章链接或文章中提到的人的个人资料等附件。

你可能会跟进问“如何转行到这个领域？”，我们会重复这个过程，但现在会将你路由到一个专门处理职业和工作的 AI 智能体。只需几次点击，你就可以深入了解任何主题，获取可操作的见解，或找到你的下一个大机会。

这一切大多是由于大语言模型 (LLMs) 的出现才得以实现的，我们认为分享我们在构建这些模型时遇到的挑战的幕后故事会很有趣。

哪些方面很容易

整体设计

有些人可能已经从上面的解释中注意到，我们的流程遵循所谓的“检索增强生成 (RAG)”，这是生成式 AI 系统的一种常见设计模式。构建这个流程比我们预期的要轻松得多。仅用了几天时间，我们就搭建好了基本框架：

• 路由：决定查询是否在范围内，以及将其转发给哪个 AI 智能体。例如，职位评估、公司理解、文章要点等智能体。
• 检索：以召回为导向的步骤，AI 智能体决定调用哪些服务以及如何调用（例如，LinkedIn 人物搜索，Bing API 等）。
• 生成：以精度为导向的步骤，筛选出检索到的噪声数据，过滤并生成最终的回答。

调优“路由”和“检索”感觉更自然，因为它们的分类性质：我们构建了开发集，并通过提示工程和内部模型对其进行了优化。现在，生成是一个不同的故事。它遵循 80/20 原则；前 80% 进展很快，但最后的 20% 花费了我们大部分的工作。当你的产品期望 99% 以上的回答都很优秀时，即使使用最先进的模型，也需要大量的工作和创造力来获得每 1% 的提升。

对我们有用的：

• 固定的三步流程
• 小模型用于路由/检索，大模型用于生成
• 通过内存数据库支持的基于嵌入的检索 (EBR) 作为我们的“穷人的微调”，将响应示例直接注入我们的提示中
• 每步特定的评估流程，特别是针对路由/检索

开发速度

我们希望跨多个团队快速推进，因此决定将任务分解为独立的智能体（即 AI 智能体）由不同的人开发：常识、职位评估、文章要点等。

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

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

• 一个小型的“横向”工程小组，处理公共组件并关注整体体验。这包括：
  • 托管产品的服务
  • 评估/测试工具
  • 所有垂直方向使用的全局提示模板（例如，智能体的全局身份、对话历史、越狱防御等）
  • 我们 iOS/Android/Web 客户端的共享 UX 组件
  • 一个服务器驱动的 UI 框架，用于在无需客户端代码更改或发布的情况下发布新的 UI 更改。
• 几个具有自主权的“纵向”工程小组，负责各自的智能体，例如：
  • 个性化文章摘要
  • 职位适配评估
  • 面试技巧

对我们有用的：

• 分而治之，但限制智能体的数量
• 一个集中化的评估流程，支持多轮对话
• 共享提示模板（例如“身份”定义）、UX 模板、工具和仪器

我们遇到的困难

评估

评估我们答案的质量比预期更困难。这些挑战大致可以分为三个方面：制定指南、扩大注释规模和自动评估。

• 制定指南是第一个难关。以职位评估为例：点击“评估我是否适合这个职位”后得到“你完全不适合”并不是很有用。我们希望它既是事实性的，又是富有同情心的。一些会员可能在考虑转行到他们目前不太适合的领域，需要帮助了解差距和下一步该怎么做。确保这些细节的一致性对于注释评分的一致性至关重要。
• 扩大注释规模是第二步。最初团队中的每个人（产品、工程、设计等）都参与进来，但我们知道需要一种更为原则性的方法，具有一致性和多样性的注释人员。我们的内部语言学团队构建了工具和流程，使我们能够每天评估多达 500 个对话，并获得关于整体质量评分、幻觉率、负责任 AI 违规、一致性、风格等指标。这成为我们了解趋势、迭代提示并确保我们准备上线的主要标志。
• 自动评估是终极目标，但仍在进行中。如果没有它，工程师只能依靠目测结果和在有限的示例集上测试，且需要等待 1 天以上才能知道指标。我们正在构建基于模型的评估器，以估计上述指标并允许更快的实验，并在幻觉检测方面取得了一些成功（但这并不容易）。

我们正在努力的方向：端到端的自动评估流程，以便更快的迭代。

调用内部 API

LinkedIn 拥有大量关于人、公司、技能、课程等独特数据，这些数据对于构建独特且有差异化价值的产品至关重要。然而，大语言模型 (LLMs) 并未接受过这些信息的训练，因此无法直接用于推理和生成响应。一个标准的解决方案是建立一个检索增强生成 (RAG) 流程，通过该流程调用内部 API，并将其响应注入到后续的 LLM 提示中，以提供额外的上下文来支持响应。

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

• 一个人类（因此也是 LLM）友好的描述，说明 API 的功能及其使用时机。
• 调用 RPC API 的配置（端点、输入模式、输出模式等）。
• LLM 友好的输入和输出模式
  • 原始类型（字符串/布尔值/数字）值
  • JSON 模式风格的输入和输出模式描述
• 将 LLM 友好模式与实际 RPC 模式映射的业务逻辑。
  

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

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

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

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

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

我们正在努力的方向：统一技能注册表，用于在我们的生成式 AI 产品中动态发现和调用包装为 LLM 友好技能的 API/智能体。

质量一致性

团队在第一个月内实现了我们目标基本体验的 80%，然后又花了四个月的时间试图超越 95% 的完整体验——我们在努力完善、调整和改进各个方面的过程中。我们低估了检测和减轻幻觉的挑战，以及质量分数提高的速度——最初迅速上升，然后每增加 1% 的提升速度显著放缓。

对于容忍这种错误水平的产品体验来说，使用生成式 AI 构建是非常简单的。但这也创造了无法达到的期望，初期的快速进展制造了“几乎完成”的错觉，当后续改进速度显著放缓时，这变得令人沮丧。

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

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

容量和延迟

容量和用户感知的延迟一直是我们关注的重点。几个方面：

• 质量与延迟：链式思维 (Chain of Thought, CoT) 等技术在提高质量和减少幻觉方面非常有效。但它们需要用户看不到的 Token，因此增加了感知的延迟。
• 吞吐量与延迟：运行大型生成模型时，通常情况下，从第一个 Token 到第一个 Token 的时间 (TTFT) 和 Token 之间的时间 (TBT) 会随着使用率的增加而增加。在 TBT 的情况下，有时它可能是线性的。如果你愿意牺牲这两个指标，你的每秒 Token 数 (TPS) 可以增加 2 倍/3 倍，但我们最初不得不对它们进行严格的限制。
• 成本：GPU 集群并不容易获得且成本高昂。起初，我们甚至不得不为测试产品设定时间表，因为它会消耗太多 Token 并锁定开发人员无法工作。
• 端到端流式处理：完整的回答可能需要几分钟才能完成，因此我们让所有请求流式传输以减少感知延迟。更重要的是，我们实际上在流程中端到端流式传输。例如，决定调用哪些 API 的 LLM 响应会被逐步解析，我们在参数准备好后立即触发 API 调用，而不等待完整的 LLM 响应。最终综合的响应也使用我们的实时消息基础设施流式传输到客户端，进行信任/负责任 AI 分类等增量处理。
• 异步非阻塞流程： 由于 LLM 调用可能需要很长时间来处理，我们通过构建一个完全异步非阻塞的流程来优化我们的服务吞吐量，不会因为 I/O 上的线程阻塞而浪费资源。
  

这些有时在它们之间产生了有趣的相互作用。举例来说，我们最初只限制 TTFT，因为这直接映射到我们初始产品的用户延迟。随着我们解决幻觉问题，链式思维在我们的提示中变得突出，我们忽略了 TBT 会对我们造成更大的伤害，因为任何“推理” Token 都会多倍增加用户延迟（例如，对于一个 200 Token 的推理步骤，即使 TBT 增加 10 毫秒，也意味着额外的 2 秒延迟）。这导致我们的一次公共升级突然发出警报，表示某些任务超时，我们迅速增加了容量以缓解问题。

我们正在努力的方向：

• 将更简单的任务转移到内部微调模型。
• 更可预测的 LLM 部署基础设施。
• 减少每个步骤浪费的 Token。

经验总结

我们说得够多了，不如让产品来说话？

这不错！尤其是后续的建议，能够引导你进入一个类似维基百科风格的好奇心漩涡。

随着我们继续改进质量、开发新功能和优化速度流程，我们很快会向更多用户推出。

达到这一点是一个来自优秀团队的巨大努力，我们将在不断学习的过程中分享更多技术细节。敬请期待！