在过去六个月里，我们 LinkedIn 的团队一直在努力开发一种新的 AI 驱动的系统体验。我们希望重新设想我们的用户如何进行工作岗位搜索和浏览专业内容。

生成式 AI 的爆发让我们停下来思考，现在有哪些场景是一年前不可能实现的。我们尝试了许多想法，但都没有真正奏效，最终我们发现了可以将每个动态和职位发布变成一个开始：

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

• Connect the dots，例如评估您对职位发布的适合度。
• 接收建议，例如改进您的个人资料或准备面试。

• 以及更多[1]

概述

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

1. 选择合适的代理：这是您旅程的开始。我们的系统会根据您的问题决定哪个 AI 代理最适合处理它。在这种情况下，它识别出您对技术公司内可访问性感兴趣，并将您的查询路由到专门处理一般知识寻求问题的 AI 代理。

2. 收集信息：AI 代理调用内部 API 和 Bing 的组合，搜索特定的例子和案例研究，展示设计可访问性如何为技术公司贡献商业价值。我们正在创建一个资料集来支撑我们的回应。

3. 撰写回应：有了必要的信息，AI 代理现在可以写回应了。它过滤和综合数据，提供一个连贯、信息丰富的答案，向您展示可访问性举措如何为技术公司推动商业价值。为了避免生成一大段文字并使体验更加互动，内部 API 被调用来用文章链接或帖子中提到的人的资料装饰回应。

这大部分得益于大型语言模型（LLMs）的出现，我们认为分享我们在它们之上构建时面临的幕后故事会很有趣。

容易的部分

1. 整体设计

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

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

• 生成：以精确为导向的步骤，筛选检索到的噪声数据，过滤并生成最终回应。

调整“路由”和“检索”感觉更自然，因为它们的分类性质：我们构建了开发集，并使用提示词工程和内部模型对其进行了适配。现在，生成则是另一回事。它遵循 80/20 规则；达到 80% 的速度很快，但最后的 20% 占用了我们大部分的工作。当你的产品期望 99% 以上的答案都应该是优秀的，即使使用最先进的模型，仍然需要大量的工作和创造力来获得每一个 1% 的提升。

• 固定三步流水线

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

• 基于嵌入的检索（EBR），由内存数据库驱动，作为我们的‘低成本微调’，直接将响应示例嵌入我们的提示词中

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

2. 开发速度

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

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

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

• 一个小型的“横向”工程小组，负责处理通用组件并专注于整体体验。这包括：

• 产品托管服务

• 评估/测试工具

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

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

• 用于无需客户端代码更改或发布即可发布新 UI 更改的服务器驱动 UI 框架

• 多个“垂直”工程小组，拥有其代理的自主权，例如：
• 个性化帖子摘要
• 工作适应性评估
• 面试技巧

对我们有效的方法：

• 分而治之，但限制代理数量
• 具有多轮对话的集中评估流程

• 共享提示模板（如“身份”定义）、UX 模板、工具和监控

我们遇到的困难

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

• 制定准则是第一个障碍。以工作评估为例：点击“评估我适合这份工作”并得到“你完全不适合”并不十分有用。我们希望它是事实性的，但也具有同理心。一些成员可能正在考虑转向他们目前不太适合的领域，需要帮助理解差距和下一步。确保这些细节的一致性对于我们的注释者（评估）分数的统一性至关重要。

• 扩展数据标注是第二步。最初团队中的每个人都参与进来（产品、工程、设计等），但我们知道我们需要一个更有原则的方法，具有一致和多样化的注释者（评分）。我们的内部语言学家团队建立了工具和流程，通过这些工具和流程，我们每天能评估多达 500 次对话，并获得关于：整体质量分数、幻觉率、负责任 AI 违规、连贯性、风格等的指标。这成为我们理解趋势、迭代提示并确保我们准备好上线的主要标志。

• 自动评估是圣杯，但仍在进行中。没有它，工程师只能通过肉眼检查结果并在有限的一组示例上进行测试，而且需要1天以上的延迟才能知道指标。我们正在开发基于模型的评估工具来测算上述指标，并允许更快的实验，我们在幻觉检测方面取得了一些成功（但这并不容易！）。

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

2. 调用内部API

领英拥有大量关于个人、企业、技能、课程等方面的独特数据，这些数据对于构建提供独特和差异化价值的产品至关重要。然而，大语言模型（LLMs）并未接受过这些信息的训练，因此无法直接利用它们进行推理和生成响应。为了解决这个问题，一种标准的做法是建立一个检索增强生成（RAG）管道，通过该管道调用内部 API，并将它们的响应注入到后续的 LLM 提示中，以提供额外的上下文来支撑响应。

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

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

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

3. 一致的质量

4. 容量与延迟

容量和感知成员延迟始终是我们关注的重点。一些方面：

• 质量与响应时间：像思维链（CoT）这样的技术在提升答案质量和减少幻觉方面非常有效。然而，这些技术需要使用成员无法直接看到的令牌，从而增加了他们感受到的响应延迟。

• 吞吐量与响应延迟：运行大型生成模型时，通常情况下，首次令牌时间（TTFT）和令牌间时间（TBT）随着系统利用率的提高而增加。在令牌间时间（TBT）方面，增加可能是线性的。如果你愿意牺牲这两个指标，通常可以实现每秒令牌数（TPS）的两倍或三倍增长，但我们最初必须对它们进行严格限制。

• 成本：GPU集群不仅难以获取，而且成本高昂。起初，我们不得不制定时间表来规定何时可以进行产品测试，因为测试会消耗大量令牌，从而影响开发者的正常工作。

• 端到端流：一个完整的答案可能需要几分钟才能完成，因此我们采用流式传输所有请求的方式来减少用户感知的延迟。更重要的是，我们在整个处理管道内部实现了端到端的流式传输。例如，对于决定调用哪些 API 的 LLM 响应，我们是逐步解析的，一旦参数准备就绪，我们就会立即发起 API 调用，而不等待完整的 LLM 响应。最终合成的响应也通过我们的实时消息传递基础设施[2]流式传输到客户端，并进行如信任/负责任AI分类等增量处理。
• 异步非阻塞处理管道：由于 LLM 调用可能需要较长时间处理，我们构建了一个完全异步非阻塞的处理管道来优化服务吞吐量，避免了因 I/O 阻塞线程而导致的资源浪费。

这些因素有时会相互作用，产生有趣的影响。例如，我们最初只对首次令牌时间（TTFT）进行了限制，因为这直接关系到我们初始产品的用户响应延迟。当我们解决幻觉问题并且思维链在我们的提示中变得重要时，我们忽略了令牌间时间（TBT）会对我们造成更大的影响，因为任何‘推理’令牌都会成倍增加用户感知的延迟。这导致我们的一个公开发布突然触发警报，有些任务达到了超时，我们迅速增加系统容量以缓解这一问题。

我们正在进行的工作:

• 将更简单的任务迁移到内部经过微调的模型上

• 为LLM部署提供更加可预测的基础设施

• 减少每个处理步骤中的令牌浪费

收获

我们已经说得够多了，让我们的产品自己来展示吧。