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

　　生成式 AI 的爆发式增长让我们停下来思考，与一年前相比，现在的可能性有多大。我们尝试了很多想法，但都没有真正被采纳，最终我们发现了将每一条信息和招聘信息转化为跳板的力量：

       整体构建容易吗?什么比较容易，什么比较有难度?基于生成式 AI 的构建并非一帆风顺，我们在很多地方都碰壁了。我们想要拉开 “ 工程 ” 的帷幕，分享那些容易的事情、我们遇到的困难以及接下来会发生的事情。

概述

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

　　想象一下，你正在浏览 LinkedIn feed ，偶然发现了一篇关于设计中的可访问性的有趣帖子。除了这篇文章之外，你还会遇到一些入门问题，以便更深入地研究该主题。你很好奇并点击 “ 在科技公司中可访问性推动商业价值的一些例子是什么? ”

　　这是后台发生的事情：

　　你可能会问 “ 我如何将我的职业生涯转向这个领域? ” ，我们会重复这个过程，但现在将你转给职业和工作人工智能 Agent 。只需点击几下，你就可以深入研究任何主题，获得可行的见解或找到下一个重大机会。

什么比较容易

整体设计

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

　　你们中的一些人可能从上面的解释中注意到，我们的流水线遵循所谓的检索增强生成( RAG )，这是生成式人工智能系统的常见设计模式。令人惊讶的是，建设流水线并没有我们预期的那么令人头疼。在短短几天内，我们就建立并运行了基本框架：

　　鉴于 " 路由 " 和 " 检索 " 的分类性质，调整它们感觉更自然：我们建立了开发集，并将其与提示词的工程设计和内部模型相匹配。现在， " 生成 " 则是另一回事。它遵循的是 80/20 法则;完成 80% 的工作很快，但最后 20% 的工作耗费了我们大部分的精力。如果对产品的期望是 99%+ 的答案都是好的，那么即使使用最先进的模型，也需要大量的工作和创造力才能获得每 1% 。

什么是有用的：

开发速度

　　我们希望在多个团队之间快速推进，因此决定将任务拆分为由不同人员开发的独立 Agent ：常识、工作评估、岗位收获等。

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

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

什么是有用的：

什么比较困难

评估

　　事实证明，评估我们答案的质量比预期的更加困难。这些挑战可大致分为三个领域：制定指南、缩放注释和自动评估。

图 2 ：我们执行的评估步骤。工程师执行快速、粗略的评估以获得方向指标。注释者提供更精细的反馈，但周转时间约为 1 天。成员是最终的评委，并为我们提供衡量标准，但某些指标可能需要 3 天以上的时间才能进行一次变更

　　正在研究的内容：端到端自动评估流水线以实现更快的迭代。

调用内部 API

　　LinkedIn 拥有大量有关人员、公司、技能、课程等的独特数据，这些数据对于构建提供独特和差异化价值的产品至关重要。然而， LLMs 尚未接受过这些数据的训练，因此无法按原样使用它们进行推理和生成响应。解决此问题的标准模式是设置检索增强生成 (  RAG  ) 流水线，通过该流水线调用内部 API ，并将其响应注入到后续的 LLM 提示中，以提供额外的上下文来接地回复。

　　这些独特的数据有很多是通过跨各种微服务的 RPC API 在内部公开的。虽然这非常方便人类以编程方式调用，但对 LLM 并不友好。为此，我们将这些 API 包装成 " 技能 " 。每个技能都包含以下组件：

　　此类技能使 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  ) ，使我们的流水线更加由数据驱动。

容量和延迟

　　容量和感知到的会员延迟始终是最重要的问题。一些维度：

　　它们之间有时会产生有趣的相互作用。举例来说，我们最初只对 TTFT 进行了约束，因为它直接映射了我们最初产品的成员延迟。当我们处理幻觉问题，并且 " 思维链 " 在我们的提示中变得突出时，我们忽略了 TBT 对我们的影响更大，因为任何 " 推理 "token 都会增加成员延迟( 例如，对于 200 个 token 的推理步骤，即使 10 毫秒的 TBT 增加也意味着额外 2 秒的延迟 )。这导致我们的一个公共资源监控突然发出警报：一些任务出现超时，我们不得不迅速增加容量来缓解这一问题。

　　正在实现的内容：

总结

　　已经讲了很多，为什么不让产品来说话呢?

　　还不错!尤其是后续建议，可能会引导你陷入维基百科式的好奇心兔子洞。

　　随着我们不断提高质量、开发新功能并优化流水线速度，我们将很快向更多用户推出。

　　我们将在不久的将来分享更多技术细节，敬请期待!