在过去的六个月里， LinkedIn 的团队一直在努力开发新的人工智能体验。我们想要重新构思 LinkedIn 会员如何进行求职和浏览专业内容。
生成式 AI 的爆发式增长让我们停下来思考，与一年前相比，现在的可能性有多大。我们尝试了很多想法，但都没有真正被采纳，最终我们发现了将每一条信息和招聘信息转化为跳板的力量：
更快地获取信息，例如从帖子中获取要点或了解公司的最新动态。
连接点，例如评估您是否适合某个职位发布。
接受建议，例如改善你的个人资料或准备面试。
以及更多…
整体构建容易吗?什么比较容易，什么比较有难度?基于生成式 AI 的构建并非一帆风顺，我们在很多地方都碰壁了。我们想要拉开 “ 工程 ” 的帷幕，分享那些容易的事情、我们遇到的困难以及接下来会发生的事情。
概述
让我们通过一个现实场景来展示系统的工作原理。
想象一下，你正在浏览 LinkedIn feed ，偶然发现了一篇关于设计中的可访问性的有趣帖子。除了这篇文章之外，你还会遇到一些入门问题，以便更深入地研究该主题。你很好奇并点击 “ 在科技公司中可访问性推动商业价值的一些例子是什么? ”
这是后台发生的事情：
选择合适的 Agent ：这是旅程的开始。我们的系统会接受你的问题并决定哪个人工智能 Agent 最适合处理它。在这种情况下，它会识别你对科技公司内部可访问性的兴趣，并将你的查询路由到专门从事一般知识搜索问题的人工智能 Agent 。
收集信息：是时候做一些准备工作了。人工智能 Agent 将调用内部应用程序接口( API )和必应( Bing )，搜索具体案例和案例研究，以突出无障碍设计如何为科技领域的商业价值做出贡献。我们正在创建一份档案，为我们的回应提供依据。
撰写回复：有了必要的信息，Agent 就可以撰写回复了。它将数据过滤并综合成一个连贯、翔实的答案，为你提供清晰的实例，说明无障碍计划如何为科技公司带来商业价值。为了避免产生文字墙，并使体验更具互动性，我们会调用内部应用程序接口，用文章链接或帖子中提到的人物简介等附件来装饰回复。
你可能会问 “ 我如何将我的职业生涯转向这个领域? ” ，我们会重复这个过程，但现在将你转给职业和工作人工智能 Agent 。只需点击几下，你就可以深入研究任何主题，获得可行的见解或找到下一个重大机会。
什么比较容易
整体设计
图 1 ：处理用户查询的简化流水线。KSA 代表 “ 知识共享Agent ” ，是数十种可以处理用户查询的Agent之一
你们中的一些人可能从上面的解释中注意到，我们的流水线遵循所谓的检索增强生成( RAG )，这是生成式人工智能系统的常见设计模式。令人惊讶的是，建设流水线并没有我们预期的那么令人头疼。在短短几天内，我们就建立并运行了基本框架：
路由：决定查询是否在范围内，以及将其转发给哪个人工智能 Agent 。Agent 的例子有：工作评估、公司了、职位要点等。
检索：面向召回的步骤，人工智能 Agent 决定调用哪些服务以及如何调用( 例如 LinkedIn 人物搜索、 Bing API 等 )。
生成：面向精度的步骤，筛选检索到的噪声数据，对其进行过滤并生成最终响应。
鉴于 " 路由 " 和 " 检索 " 的分类性质，调整它们感觉更自然：我们建立了开发集，并将其与提示词的工程设计和内部模型相匹配。现在， " 生成 " 则是另一回事。它遵循的是 80/20 法则;完成 80% 的工作很快，但最后 20% 的工作耗费了我们大部分的精力。如果对产品的期望是 99%+ 的答案都是好的，那么即使使用最先进的模型，也需要大量的工作和创造力才能获得每 1% 。
什么是有用的：
固定 3 步流水线
小型模型用于路由 / 检索，较大模型用于生成
基于嵌入的检索( EBR )由内存数据库提供支持，作为我们的 “ 穷人的微调 ” ，将响应示例直接注入到我们的提示词中
每个步骤都有特定评估流水线，特别是路由 / 检索流水线
开发速度
我们希望在多个团队之间快速推进，因此决定将任务拆分为由不同人员开发的独立 Agent ：常识、工作评估、岗位收获等。
然而，这种方法带来了很大的折衷。通过并行化任务，我们提高了速度，但也付出了碎片化的代价。当与助手的后续交互可能由不同的模型、提示词或工具管理时，保持统一的用户体验就变得非常具有挑战性。
为了解决这个问题，我们采用了一个简单的组织结构：
一个小型的 " 横向 " 工程小组负责处理通用组件，并注重整体体验。其中包括：
托管产品的服务
评估 / 测试工具
所有垂直领域使用的全局提示词模板( 例如：Agent 的全局身份、对话历史记录、越狱防御等 )
为我们的 iOS/Android/Web 客户端提供共享 UX 组件
一个服务器驱动的 UI 框架，用于发布新的 UI 变更，而无需更改或发布客户端代码。
几个 " 垂类 " 工程小组，其拥有对相关 Agent 的自主权，例如，：
个性化的帖子总结
工作适合度评估
面试技巧
什么是有用的：
分而治之，但限制 Agent 数量
具有多轮对话的集中式评估流水线
共享提示词模板( 例如 “ 身份 ” 定义 )、 UX 模板、工具和检测
什么比较困难
评估
事实证明，评估我们答案的质量比预期的更加困难。这些挑战可大致分为三个领域：制定指南、缩放注释和自动评估。
制定指导原则是第一个障碍。以工作评估为例：点击 " 评估我是否适合这份工作 " ，得到的结果是 " 你非常不适合 " ，这并没有什么用处。我们希望它既能反映事实，又能让人感同身受。有些会员可能正在考虑转行，进入他们目前并不十分适合的领域，他们需要帮助来了解存在哪些差距以及下一步该怎么做。确保这些细节的一致性是我们标注者评分统一的关键。
扩大标注规模是第二步。起初，团队中的每个人都参与其中( 产品、工程、设计等 )，但我们知道，我们需要一种更有原则的方法，需要一致且多样化的标注者。我们的内部语言学家团队建立了工具和流程，通过这些工具和流程，我们可以对每天多达 500 个对话进行评估，并获得以下方面的指标：总体质量得分、幻觉率、负责任人工智能违规、连贯性、风格等。这成为我们了解趋势、迭代提示词和确保准备上线的主要路标。
自动评估是圣杯，但仍在进行中。如果没有它，工程师只能目测结果并在有限的一组示例上进行测试，并且要延迟 1 天以上才能了解指标。我们正在构建基于模型的评估器来估计上述指标并允许更快的实验，并在幻觉检测方面取得了一些成功( 但这并不容易! )。
图 2 ：我们执行的评估步骤。工程师执行快速、粗略的评估以获得方向指标。注释者提供更精细的反馈，但周转时间约为 1 天。成员是最终的评委，并为我们提供衡量标准，但某些指标可能需要 3 天以上的时间才能进行一次变更
正在研究的内容：端到端自动评估流水线以实现更快的迭代。
调用内部 API
LinkedIn 拥有大量有关人员、公司、技能、课程等的独特数据，这些数据对于构建提供独特和差异化价值的产品至关重要。然而， LLMs 尚未接受过这些数据的训练，因此无法按原样使用它们进行推理和生成响应。解决此问题的标准模式是设置检索增强生成 ( RAG ) 流水线，通过该流水线调用内部 API ，并将其响应注入到后续的 LLM 提示中，以提供额外的上下文来接地回复。
这些独特的数据有很多是通过跨各种微服务的 RPC API 在内部公开的。虽然这非常方便人类以编程方式调用，但对 LLM 并不友好。为此，我们将这些 API 包装成 " 技能 " 。每个技能都包含以下组件：
对 API 功能以及何时使用它的人性化( 以及 LLM )友好描述。
调用 RPC API 的配置( 端点、输入模式、输出模式等 )
LLM 友好的输入和输出模式
原始类型( 字符串 / 布尔 / 数字 )值
JSON 模式样式输入和输出模式描述
在 LLM 友好模式和实际 RPC 模式之间映射的业务逻辑。
此类技能使 LLM 能够执行与我们产品相关的各种操作，例如查看个人资料、搜索文章 / 人员 / 职位 / 公司，甚至查询内部分析系统。同样的技术也用于调用非 LinkedIn API ，例如 Bing 搜索和新闻。
我们编写提示，要求 LLM 决定使用什么技能来解决特定工作( 通过规划选择技能 )，然后输出调用技能的参数( 函数调用 )。由于调用的参数必须与输入模式相匹配，因此我们要求 LLM 以结构化的方式输出这些参数。大多数 LLM 都是通过 YAML 和 JSON 进行结构化输出的。我们之所以选择 YAML ，是因为它不太啰嗦，因此比 JSON 消耗的标记更少。
我们遇到的挑战之一是，虽然约 90% 的时间 LLM 响应都包含正确格式的参数，但约 10% 的时间 LLM 会出错，经常输出与所提供的模式不符的数据，更有甚者甚至不是有效的 YAML 。这些错误虽然对人类来说微不足道，但却会导致解析这些错误的代码崩溃。 ~10% 这个数字对我们来说已经很高了，我们不能轻易忽略，因此我们开始着手解决这个问题。
解决这一问题的标准方法是检测出问题，然后重新提示 LLM ，要求它通过一些额外的指导来纠正错误。这种方法虽然有效，但却增加了非同小可的延迟，而且由于额外的 LLM 调用，还消耗了宝贵的 GPU 容量。为了规避这些限制，我们最终编写了一个内部防御型 YAML 解析器。
通过对各种有效载荷的分析，我们确定了 LLM 常犯的错误，并编写了代码，以便在解析前检测并适当修补这些错误。我们还修改了我们的提示，在其中一些常见错误周围注入提示，以提高修补的准确性。我们最终将这些错误的发生率降低到了约 0.01% 。
正在实现的内容：一个统一的技能注册表，用于动态发现和调用 API/ Agent，并将其打包为 LLM 友好型技能，供我们的生成式人工智能产品使用。
品质稳定
团队在第一个月内实现了我们目标提供的基本体验的 80% ，然后又花了四个月的时间，试图超过我们完整体验的 95% 的完成度 - 我们努力完善、调整和改进各个方面。我们低估了检测和减轻幻觉的挑战，以及质量分数提高的速度——最初猛增，然后迅速趋于稳定。
对于能够容忍如此程度错误的产品体验，使用生成式 AI 进行构建非常简单。但它也产生了无法实现的期望，最初的步伐产生了一种 “ 几乎就在那里 ” 的错误感觉，随着随后每 1% 的增长，改善速度都会显着放缓，这种感觉变得令人沮丧。
建立助手的过程与更多 " 原则性 " 的机器学习有所不同，更类似于调整专家系统中的规则。因此，当我们的评估变得越来越复杂时，我们的 " 训练 " 主要是提示词工程，这与其说是一门科学，不如说是一门艺术。
正在实现的内容：微调大型语言模型 ( LLMs ) ，使我们的流水线更加由数据驱动。
容量和延迟
容量和感知到的会员延迟始终是最重要的问题。一些维度：
质量与延迟：思想链 ( CoT ) 等技术对于提高质量和减少幻觉非常有效。但他们需要会员从未见过的 token ，因此增加了他们感知到的延迟。
吞吐量与延迟：在运行大型生成模型时， TimeToFirstToken ( TTFT )和 TimeBetweenTokens ( TBT )通常会随着使用率的增加而增加。就 TBT 而言，有时可能是线性增长。如果愿意牺牲这两项指标，每秒 token 数( TPS )提高 2 倍 /3 倍的情况并不罕见，但我们最初不得不对它们进行严格限制。
成本：GPU 集群不易获得且成本高昂。一开始我们甚至必须设定何时可以测试产品的时间表，因为它会消耗太多 token 并阻止开发人员工作。
端到端流式传输：一个完整的答案可能需要数分钟才能完成，因此我们将所有请求流式传输，以减少感知延迟。更重要的是，我们的流水线实际上是端到端的。例如，决定调用哪些应用程序接口的 LLM 响应会被逐步解析，一旦参数准备就绪，我们就会立即调用应用程序接口，而无需等待完整的 LLM 响应。最终合成的响应也会使用我们的实时消息传输基础架构，通过增量处理( 如信任 / 负责任的人工智能分类 )一路流式传输到客户端。
异步非阻塞流水线：由于 LLM 调用可能需要很长时间才能处理完毕，因此我们通过构建一个完全异步的非阻塞流水线来优化服务吞吐量，这样就不会因为线程阻塞在 I/O 上而浪费资源。
它们之间有时会产生有趣的相互作用。举例来说，我们最初只对 TTFT 进行了约束，因为它直接映射了我们最初产品的成员延迟。当我们处理幻觉问题，并且 " 思维链 " 在我们的提示中变得突出时，我们忽略了 TBT 对我们的影响更大，因为任何 " 推理 "token 都会增加成员延迟( 例如，对于 200 个 token 的推理步骤，即使 10 毫秒的 TBT 增加也意味着额外 2 秒的延迟 )。这导致我们的一个公共资源监控突然发出警报：一些任务出现超时，我们不得不迅速增加容量来缓解这一问题。
正在实现的内容：
将更简单的任务转移到内部经过微调的模型
为 LLM 部署提供更可预测的部署基础架构
减少每一步浪费的 token
总结
已经讲了很多，为什么不让产品来说话呢?
还不错!尤其是后续建议，可能会引导你陷入维基百科式的好奇心兔子洞。
随着我们不断提高质量、开发新功能并优化流水线速度，我们将很快向更多用户推出。
我们将在不久的将来分享更多技术细节，敬请期待!
