错误率从10%降至0.01%，领英全面分享LLM应用落地经验

LinkedIn的生成式AI实践：6个月经验复盘

大型语言模型（LLM）技术正快速成熟，各行各业都在加速落地。但说实话，真正把技术变成好用的产品，远没有看上去那么轻松。最近，LinkedIn团队分享了他们在开发生成式AI产品时积累的经验，相当有诚意，值得细读。

先说几个核心发现：过去六个月，LinkedIn团队一直在努力重新构想用户如何在平台上求职、浏览专业内容。生成式AI的爆发让他们意识到，一年前还不敢想的事情，现在已经有了实现的可能。他们尝试了很多想法，有些失败了，但最终总结出产品需要做到三件事——

• 更快地获取信息
  ：比如从帖子中提取要点，或者快速了解公司最新动态。

• 将信息点串联起来
  ：比如帮你评估自己是否适合某个职位。

• 获取切实可行的建议
  ：比如优化个人资料，或者准备面试。

来看一个典型的场景：当你正在浏览LinkedIn信息流，看到一篇关于“设计中可访问性”的有趣帖子。除了文章本身，系统还会推送一些入门问题，引导你深入探讨。比如你点击“科技公司中可访问性推动商业价值的例子有哪些？”——这时，后台就开始运转了。

• 选择合适的智能体
  ：系统接收你的问题，判断哪个AI智能体最合适。它会识别到你关心科技公司的可访问性，然后将查询路由给负责通用知识搜索的智能体。

• 收集信息
  ：该智能体调用内部API和Bing搜索，快速寻找能说明可访问性如何带来商业价值的具体案例。

• 制定回复
  ：有了数据，智能体开始整合、过滤，生成连贯且信息丰富的答案。为了让体验更直接，系统还会自动附上文章链接或文中提到的人物简介。

如果你接着问“我如何才能转行进入这个领域”，系统会重复上述过程，只是这次会被转给专门处理职业与工作相关的AI智能体。几轮点击下来，你可以深入任何主题，获得可行建议，甚至找到下一个工作机会。

这些新功能，说白了，基本都是靠LLM技术撑起来的。

总体设计

整个系统pipeline遵循检索增强生成（RAG）模式——这已经是生成式AI应用里的常见架构了。出乎意料的是，这根pipeline建起来并没有预想中那么令人头疼。基本框架大约几天就搭起来了，主要包含三个步骤：

• 路由
  ：决定查询是否在服务范围内，并转发给合适的AI智能体。

• 检索
  ：这是面向“召回”的步骤，智能体决定调用哪些服务，比如LinkedIn人物搜索或Bing API。

• 生成
  ：这是面向“精度”的步骤，从检索到的噪声数据中筛选有效信息，生成最终回答。

图1：处理用户查询的简化pipeline。KSA代表“知识共享智能体”，是众多智能体之一。

关键设计点包括：

• 采用固定的三步pipeline。
• 路由和检索部分使用小型模型，生成部分使用大模型。
• 基于嵌入的检索（EBR），由内存数据库支持，并将响应示例直接注入到提示中。
• 为每个步骤配置专门的评估pipeline，特别是路由和检索环节。

开发速度

团队决定将开发任务拆分，由不同的人独立开发不同的智能体：常识、工作评估、职位要点等等。这种并行开发模式确实加快了速度，但也带来了一个代价——“碎片化”。当用户与通过不同模型、提示或工具管理的助手进行多轮对话时，保持统一的用户体验变得相当困难。

解决办法是一个简单的组织结构：一个小型的“水平（horizontal）”工程pod，负责通用组件并专注于整体体验。这包括：

• 托管产品的服务
• 评估和测试工具
• 所有垂直领域共用的全局提示模板（比如智能体的全局身份、对话历史、越狱防御等）
• 为iOS、Android和Web客户端共享的UX组件
• 服务器驱动的UI框架，方便快速发布新UI，无需客户端应用更新。

关键设计点：分而治之，但严格限制智能体数量；拥有集中式评估pipeline，支持多轮对话；共享提示模板（如身份定义）、UX模板、工具和检测机制。

评估

事实证明，评价系统响应的质量比想象中要难得多。挑战主要集中在三个方向：制定指南、扩展注释和自动评估。

以工作评估为例：点击“评估我是否适合这份工作”，如果系统只是回复一句“你很适合”，那就没什么价值。团队希望回答既真实又具备同理心。有些用户可能正在考虑转行到一个目前不太匹配的领域，他们需要的是了解差距和下一步该怎么做。要让注释人员在这些细节上保持一致，是件非常考验功夫的事。

需要一批标准统一且背景多样化的注释人员。内部语言学家团队专门搭了工具和流程，每天能评估多达500个会话，并获取关键指标：整体质量得分、幻觉率、AI违规、连贯性、风格等。

没有自动化评估时，工程师只能目测结果，在小范围示例上测试，并且要等超过1天才能看到指标反馈。团队正在构建基于模型的评估器来覆盖上述指标，在幻觉检测方面已经取得了一些进展。完整的端到端自动评估pipeline将大幅加快迭代速度。

图2：评估步骤。

调用内部API

LinkedIn拥有大量关于人、公司、技能、课程等独特数据，这是构建差异化产品的核心优势。但问题是，LLM没有经过这些数据的训练，无法直接利用它们进行推理和生成。标准解法是搭建RAG pipeline：调用内部API，把返回的数据注入到后续的LLM提示中，提供额外上下文支持。

这类数据大多通过各微服务中的RPC API在内部公开。对人类开发者来说，用代码调用这些API很方便，但对LLM而言就不那么友好。团队的做法是在这些API外面包装一层“技能”（skill）。每个技能包括：

• 关于API功能及适用场景的人类友好描述
• 调用RPC API的配置（端点、输入输出模式等）
• LLM友好的输入输出模式，包含原始类型（字符串、布尔、数字）、JSON schema描述，以及LLM模式与RPC模式之间的业务逻辑映射。

这些技能让LLM能够执行各种产品操作——查看个人资料、搜索文章、人员、职位、公司，甚至查询内部分析系统。同样的方式也用于调用外部API，比如Bing搜索。

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

团队在提示中要求LLM自行判断使用什么技能解决特定问题（通过规划选择技能），再输出参数来调用技能（函数调用）。由于调用参数必须符合输入模式，所以要求LLM以结构化方式输出。大多数LLM都接受过YAML和JSON的结构化输出训练，团队最终选择了YAML，因为它比JSON更简洁，消耗的token更少。

一个意外是：虽然约90%的情况下LLM能输出格式正确的参数，但剩下约10%的情况会出错——输出格式无效的数据，甚至根本不是合法的YAML。这些错误对人类来说微不足道，却会导致解析代码直接崩溃。10%的错误率显然不能忽视。

标准解决方案是检测错误后重新提示LLM，帮助其纠正。这种方法虽然有效，但代价是显著增加延迟和GPU消耗。团队最终决定写一个内部防御性YAML解析器。通过分析各种错误payload，他们归纳出LLM的常见错误模式，并编写代码在解析前进行检测和修补。同时，针对部分常见错误修改了提示，提高修补的准确率。最终把这些错误的发生率降到了约0.01%。

值得特别提一句：团队目前正在构建一个统一的技能注册表，用于在生成式AI产品中动态发现和调用这些打包成LLM友好技能的API或智能体。

容量和延迟

容量和延迟始终是绕不开的硬骨头。以下几个维度尤为关键：

• 质量 vs 延迟
  ：思维链（CoT）等技术对提高质量和减少幻觉非常有效，但需要生成大量未见过的新token，延迟随之增加。

• 吞吐量 vs 延迟
  ：运行大型生成模型时，随着GPU利用率上升，首Token延迟（TTFT）和Token间间隔（TBT）都会明显变长。

• 成本
  ：GPU集群既难获取又贵。一开始，团队甚至不得不设定产品的测试时间表，因为token消耗实在太大了。

• 端到端流式处理
  ：完整回答可能需要几分钟才能生成，因此所有请求都采用流式传输，降低用户的感知延迟。更有意思的是，整个pipeline实现的是端到端流式处理——比如决定调用哪些API的LLM响应是逐步解析的，一旦某个参数准备好，就会触发API调用，不必等待完整响应。最终的合成响应也会通过实时消息基础设施一路传输到客户端，并在过程中进行“负责任的AI”等增量处理。

• 异步非阻塞pipeline
  ：LLM调用可能耗时很长，团队通过构建完全异步非阻塞的pipeline来优化服务吞吐量，避免I/O线程阻塞造成的资源浪费。