wsl-docs

LinkedIn 团队构建生成式 AI 产品的经验教训

发布日期：2024-07-28来源：https://baoyu.io/blog/ai/linkedin-team-building-generative-ai-lessons11分钟阅读

摘要

1) 一句话总结 本文总结了 LinkedIn 构建生成式 AI 产品的实践经验，涵盖多智能体架构设计、团队协作重组、数据检索优化、结构化数据输出及质量评估等核心环节。

2) 关键要点

  • 多智能体架构：系统分为路由、检索和生成三步。路由和检索阶段可使用小模型，生成阶段使用大模型以保证内容质量。
  • 团队架构调整：将团队从“按智能体独立划分”重组为“公共底层框架组 + 多个垂直智能体组”，以共享提示词模板、集中处理安全防护并统一用户体验。
  • 自然语言检索转换：通过 LLM 将用户资料、咨询问题和可用 API 结合，把自然语言请求分解为具体的 API 查询参数，并针对 LLM 优化了传统 API 的冗余返回数据。
  • 结构化数据输出优化：使用 YAML 替代 JSON 以提高容错率，通过日志优化自定义 YAML 解析器，并利用 LLM 修复无法解析的错误，最终将结构化数据的错误率从 10% 降至 0.01%。
  • 性能与体验优化：采用思维链（CoT）提升质量并减少幻觉，使用流式（Streaming）输出提升用户体验，通过异步非阻塞管道优化服务吞吐量。
  • 分层质量评估机制：采用三级人工评估流程：工程师快速粗略评估 → 标注员提供细致反馈（约需 1 天） → 团队成员进行全面评估（需超 3 天）。

3) 风险与不足（原文明确提及）

  • 团队协作风险：各小组独立开发智能体容易导致提示词、对话历史、越狱防护等模块重复建设，且造成用户体验不一致。
  • 数据检索适配不足：传统 API 是为传统 App 设计的，返回数据冗余过多，不适合 LLM 直接使用，必须进行针对性优化。
  • 性能与延迟权衡：使用思维链（CoT）时，由于中间步骤不能展示给用户，必须等待其完成，从而增加了系统延迟；同时在复杂流程中实现流式输出存在技术挑战。
  • 评估机制的局限性：生成结果的质量评估难以制定标准（如需兼顾真实准确与同理心），数据标注难以规模化，且高度依赖人工，难以实现自动化。

正文

LinkedIn 的这个分享很有价值，他们分享了在构建生成式 AI 产品时的一些宝贵经验教训

他们做的产品时基于 LinkedIn 上的信息流和职位，借助 AI 帮助用户评估是不是和职位匹配、了解某个公司的最新动态、面试和修改个人简历方面的建议，以及其他一些功能。

Image 1

从技术架构上来说，是一个多智能体的技术架构，主要分成三步：

  • 路由：确定查询是否在范围内，并决定将其转发给哪个 AI 智能体。智能体的例子有：职位评估、公司理解、帖子总结等。
  • 检索：AI 智能体决定调用哪些服务以及如何调用（例如 LinkedIn 用户搜索，Bing 搜索 等）。
  • 生成：LLM 根据获取到的信息、原始问题和上下文去生成答案。

Image 2

这其中路由、检索可以使用小模型，但生成内容需要使用大模型，这样才能有比较好的生成效果。

在整个项目的开发过程中，挑战是多方面的，有来自团队协作的，有来自大语言模型本身的

  1. 团队协作的挑战

首先在团队协作方面，最开始他们是按照智能体划分小组，各自负责，这样优点是开发速度快，但缺点是各自的提示词、对话历史、越狱防护等这些需要重复建设，用户体验不一致。

所以他们后来将组织架构进行了调整：

  • 一个小组负责公共和底层框架，并且保证提供一致的体验，这样可以共享提示词模板、集中解决安全防护、统一用户体验等
  • 多个小组负责垂直方向的智能体，基于公共组提供的框架优化提示词、连接后端 API 等
  1. 数据检索的挑战

Image 3

LinkedIn 有大量的用户资料、公司信息、还有一些其他的信息，这些数据更新很快，并且没有被大语言模型训练过，所以当用户请求时，需要能检索到用户想要的数据，而基于生成式 AI 产品的交互，不再是传统的关键字 + 选项的检索，而是完全自然语言的检索，这就需要先调用一次 LLM 帮助将自然语言转化为 API 调用。另外传统的 API 是给传统的 App 使用的，返回的数据冗余很多，并不适合 LLM 使用，所以需要针对 API 做一些针对 LLM 的优化。

举例来说，用户可能会询问：“请给我推荐西雅图的待遇好的公司”，那么针对这样的查询，首先需要去根据用户的身份找出来用户自己的职业（比如 Java 后端开发工程师），然后将用户资料 + 咨询的问题 + 可用的检索 API，一起交给 LLM，LLM 将请求分解成适合 API 查询的参数：

  • 职位搜索 API
    • 职位：Java 后端开发工程师
    • 地点：西雅图
    • 排序：工资由高到低

然后去调用 API，API 返回结果后，将返回结果、用户原始问题、历史对话一起交给 LLM，最终生成答案。

  1. 怎么稳定的让 LLM 返回结构化的数据？

真正做过 LLM 开发的都知道，虽然理论上 LLM 可以生成结构化的数据，但是真正生成的时候经常出错。LinkedIn 的做法是： 1). 使用 YAML 格式而不是 JSON，相对来说容错率更高 2). 用日志记录常见的 YAML 错误，优化自己的 YAML 解析器，可以解析 LLM 返回的不规范的 YAML 3). 如果还是无法解析则将错误信息交给 LLM 修复，并且不断优化提示词，提升 LLM 修复的成功率

最终结构化数据的错误率从 10% 下降到 0.01%

  1. 如何减少幻觉、降低延迟和提升吞吐量
  • 使用 CoT（思维链）可以有效提升质量和减少幻觉，但由于一些中间步骤不能显示给用户，要等前面的中间步骤输出完成才能给用户显示结果，这也会增加延迟
  • 使用流式（streaming）输出可以提升用户体验，让用户尽早看到输出，但这在复杂的流程上有很多挑战
  • 由于 LLM 调用可能需要很长时间处理，使用异步非阻塞管道可以优化服务吞吐量，从而避免因 I/O 阻塞线程而浪费资源。
  1. 如何评估生成结果的质量

只有对生成的结果有科学的评估，才能不断优化生成结果，但如何评估生成质量是很困难的，主要表现在：

  • 难以制定标准。以职位评估为例：点击“评估我与该职位的匹配度”然后得到“你很不适合”并没有多大价值。好的结果既要真实准确又富有同情心。
  • 对数据标注很难规模化，主要得依赖团队成员和外部标注员
  • 难以自动化，还是需要人工去标注，并且需要收集一定的数据后才能评估

Image 4

最终 LinkedIn 的做法： 1). 工程师们先快速粗略评估，得到个大致的指标。 2). 标注员提供更细致的反馈，但需要大约 1 天的时间。 3). 最终由团队成员进行全面评估，但可能需要超过 3 天的时间。

具体内容建议阅读原文。

关联主题

关系图谱

反向链接