在过去六个月里，我们 LinkedIn 的团队一直在努力开发一种新的 AI 驱动的系统体验。我们希望重新设想我们的用户如何进行工作岗位搜索和浏览专业内容。
生成式 AI 的爆发让我们停下来思考，现在有哪些场景是一年前不可能实现的。我们尝试了许多想法，但都没有真正奏效，最终我们发现了可以将每个动态和职位发布变成一个开始：
构建生成式AI产品容易吗？哪些进展顺利，哪些不顺利？在生成式AI之上构建并非一帆风顺，我们在很多地方遇到了障碍。我们希望揭开“工程”幕后的秘密，分享哪些容易，我们在哪里挣扎，以及接下来会发生什么。
想象一下，您正在浏览 LinkedIn 动态，偶然发现了一篇关于设计可访问性的有趣帖子。在帖子旁边，您会看到几个引导问题，以便更深入地探讨这个主题。您好奇地点击了，“技术公司中可访问性推动商业价值的例子有哪些？” 选择合适的代理： 这是您旅程的开始。我们的系统会根据您的问题决定哪个 AI 代理最适合处理它。在这种情况下，它识别出您对技术公司内可访问性感兴趣，并将您的查询路由到专门处理一般知识寻求问题的 AI 代理。
收集信息： AI 代理调用内部 API 和 Bing 的组合，搜索特定的例子和案例研究，展示设计可访问性如何为技术公司贡献商业价值。我们正在创建一个资料集来支撑我们的回应。撰写回应： 有了必要的信息，AI 代理现在可以写回应了。它过滤和综合数据，提供一个连贯、信息丰富的答案，向您展示可访问性举措如何为技术公司推动商业价值。为了避免生成一大段文字并使体验更加互动，内部 API 被调用来用文章链接或帖子中提到的人的资料装饰回应。
您可能会跟进“我如何转向这个领域？”，我们会重复这个过程，但现在将您路由到职业和职位AI代理。只需几次点击，您就可以深入任何主题，获取可操作的见解或找到下一个大的机会。 这大部分得益于大型语言模型（LLMs）的出现，我们认为分享我们在它们之上构建时面临的幕后故事会很有趣。
1. 整体设计 图1：处理用户查询的简化管道。KSA代表“知识共享代理”，是能够处理用户查询的数十个代理之一 您可能从上面的解释中注意到，我们的管道遵循所谓的检索增强生成（RAG），这是生成式 AI 系统的常见设计模式。构建管道比我们预期的要少得多。仅仅几天，我们就有了基本框架： 调整“路由”和“检索”感觉更自然，因为它们的分类性质：我们构建了开发集，并使用提示词工程和内部模型对其进行了适配。现在，生成则是另一回事。它遵循 80/20 规则；达到 80% 的速度很快，但最后的 20% 占用了我们大部分的工作。当你的产品期望 99% 以上的答案都应该是优秀的，即使使用最先进的模型，仍然需要大量的工作和创造力来获得每一个 1% 的提升。
2. 开发速度 我们希望在多个团队中快速行动，因此决定将任务拆分为由不同人员开发的独立代理（即AI 代理）：一般知识、工作评估、帖子要点等。
然而，这种方法引入了重大妥协。通过并行化任务，我们在速度上获得了优势，但代价是碎片化。当与助手的后续互动可能由不同的模型、提示或工具管理时，保持统一的用户体验变得具有挑战性。
为了解决这个问题，我们采用了简单的组织结构：
对我们有效的方法：
评估我们答案的质量比预期的要困难。挑战可以大致分为三个领域：制定准则、扩展注释和自动评估。
图2：我们执行的评估步骤。工程师进行快速粗略的评估以获取方向性指标。注释者提供更细致的反馈，但反馈周期大约需要1天。成员是最终的评判者，为我们提供了规模，但某些指标可能需要3天以上才能进行单次更改。
我们正在努力： 端到端的自动评估流程，以加快迭代速度。2. 调用内部API 领英拥有大量关于个人、企业、技能、课程等方面的独特数据，这些数据对于构建提供独特和差异化价值的产品至关重要。然而，大语言模型（LLMs）并未接受过这些信息的训练，因此无法直接利用它们进行推理和生成响应。为了解决这个问题，一种标准的做法是建立一个检索增强生成（RAG）管道，通过该管道调用内部 API，并将它们的响应注入到后续的 LLM 提示中，以提供额外的上下文来支撑响应。
这些独特数据中的大部分通过 RPC API 在各个微服务内部暴露。虽然这对人类来说非常方便以编程方式调用，但对 LLM 来说并不友好。我们通过在这些 API 上封装“技能”来解决这个问题。每个技能包含以下组成部分： 一个人（因此也是LLM）友好的描述，说明API的功能以及何时使用它。 调用 RPC API 的配置（端点、输入模式、输出模式等）。 将 LLM 友好的模式与实际 RPC 模式之间映射的业务逻辑。 这样的技能使LLM能够执行与我们的产品相关的各种操作，如查看个人资料、搜索文章/人物/工作/公司，甚至查询内部分析系统。同样的技术也用于调用非领英 API，如 Bing 搜索和新闻。
图3：使用技能调用内部 API
我们编写提示，要求 LLM 决定使用哪种技能来解决特定任务（通过规划进行技能选择），并输出调用该技能所需的参数（函数调用）。由于调用的参数必须匹配输入模式，我们要求 LLM 以结构化方式输出它们。大多数 LLM 在结构化输出方面接受过 YAML 和 JSON 的训练。我们选择了 YAML，因为它更简洁，因此比 JSON 消耗更少的令牌。 我们面临的一个挑战是，大约 90% 的情况下，LLM 的响应包含正确格式的参数，但大约 10% 的情况下，LLM 会出错，并且经常输出不符合所提供模式的数据，或者更糟糕的是，甚至不是有效的 YAML。这些错误虽然对人类来说容易发现，但会导致解析它们的代码出错。10%的比例对我们来说太高，不能轻易忽视，因此我们着手解决这个问题。 解决这个问题的一种标准方法是检测错误，然后重新提示 LLM，要求它根据一些额外的指导纠正其错误。虽然这种方法有效，但它增加了相当大的延迟，并且由于额外的 LLM 调用而消耗了宝贵的 GPU 资源。为了规避这些限制，我们最终开发了一个内部的防御性 YAML 解析器。 通过对各种负载的分析，我们确定了 LLM 常见的错误，并编写了代码来检测和适当修补这些错误，然后再进行解析。我们还修改了我们的提示，注入一些关于这些常见错误的提示，以提高我们修补的准确性。最终，我们能够将这些错误的 occurrence 降低到约 0.01%。 我们正在努力的事项： 一个统一的技能注册表，用于动态发现和调用作为对 LLM 友好的技能打包的 API/代理，横跨我们的生成式AI产品。3. 一致的质量 团队在第一个月内实现了我们目标基本体验的 80%，然后又花了四个月的时间试图超越我们完整体验的 95% 完成度——因为我们努力地改进、调整和完善各个方面。我们低估了检测和缓解幻觉的挑战，以及质量分数提高的速度——最初迅速上升，然后迅速趋于平稳。 对于容忍这种错误水平的产品体验，使用生成式 AI 构建是令人耳目一新的简单直接。但它也创造了无法达到的期望，最初的步伐创造了一种“几乎到达”的错觉，随着每次后续 1% 的改进速度显著放缓，这变得令人沮丧。 构建助手感觉像是从更“原则性”的 ML 转向了更像调整专家系统中的规则。因此，尽管我们的评估变得越来越复杂，但我们的“训练”主要是提示工程，这更像是一门艺术而非科学。 我们正在努力的事项： 微调大语言模型（LLMs），使我们的管道更加数据驱动。4. 容量与延迟 容量和感知成员延迟始终是我们关注的重点。一些方面：
质量与响应时间： 像思维链（CoT）这样的技术在提升答案质量和减少幻觉方面非常有效。然而，这些技术需要使用成员无法直接看到的令牌，从而增加了他们感受到的响应延迟。
吞吐量与响应延迟： 运行大型生成模型时，通常情况下，首次令牌时间（TTFT）和令牌间时间（TBT）随着系统利用率的提高而增加。在令牌间时间（TBT）方面，增加可能是线性的。如果你愿意牺牲这两个指标，通常可以实现每秒令牌数（TPS）的两倍或三倍增长，但我们最初必须对它们进行严格限制。
成本： GPU集群不仅难以获取，而且成本高昂。起初，我们不得不制定时间表来规定何时可以进行产品测试，因为测试会消耗大量令牌，从而影响开发者的正常工作。
端到端流： 一个完整的答案可能需要几分钟才能完成，因此我们采用流式传输所有请求的方式来减少用户感知的延迟。更重要的是，我们在整个处理管道内部实现了端到端的流式传输。例如，对于决定调用哪些 API 的 LLM 响应，我们是逐步解析的，一旦参数准备就绪，我们就会立即发起 API 调用，而不等待完整的 LLM 响应。最终合成的响应也通过我们的实时消息传递基础设施[2]流式传输到客户端，并进行如信任/负责任AI分类等增量处理。异步非阻塞处理管道： 由于 LLM 调用可能需要较长时间处理，我们构建了一个完全异步非阻塞的处理管道来优化服务吞吐量，避免了因 I/O 阻塞线程而导致的资源浪费。这些因素有时会相互作用，产生有趣的影响。例如，我们最初只对首次令牌时间（TTFT）进行了限制，因为这直接关系到我们初始产品的用户响应延迟。当我们解决幻觉问题并且思维链在我们的提示中变得重要时，我们忽略了令牌间时间（TBT）会对我们造成更大的影响，因为任何‘推理’令牌都会成倍增加用户感知的延迟。这导致我们的一个公开发布突然触发警报，有些任务达到了超时，我们迅速增加系统容量以缓解这一问题。
我们正在进行的工作:
将更简单的任务迁移到内部经过微调的模型上
为LLM部署提供更加可预测的基础设施
减少每个处理步骤中的令牌浪费
我们已经说得够多了，让我们的产品自己来展示吧。
这很不错！特别是那些后续建议，能让你像探索维基百科的深渊一样充满好奇。 随着我们持续提升产品质量，开发新功能，并优化处理管道速度，我们很快将向更多用户推出。 到达这一阶段是团队付出了巨大努力的结果，我们将继续学习，并很快分享更多技术细节。敬请期待！
