Posted in

领英 AI 落地复盘:多 Agent 配合、端到端输出_AI阅读总结 — 包阅AI

包阅导读总结

1. 关键词:领英、生成式 AI、多 Agent、端到端输出、挑战与成就

2. 总结:本文主要讲述了领英在过去六个月开发基于自身业务的生成式 AI 应用的情况,包括应用场景、设计过程、遇到的困难与挑战,如质量评估、调用内部 API 等,还介绍了一些成果及正在进行的工作。

3. 主要内容:

– 领英 AI 应用成果

– 重新设计求职流程,用户可通过 AI 直接获取职位信息和职场建议

– 应用实现过程

– 选择合适的 Agent 处理用户问题

– 进行信息搜集

– 生成回复

– 轻松实现的部分

– 总体设计采用检索增强生成模式,包含路由、检索、生成三个步骤

– 开发速度通过任务分配给不同人员的独立 AI Agent 提升,但带来系统碎片化问题

– 遇到的困难与挑战

– 评价回答质量困难,涉及制定评估标准、扩展数据标注和实现自动化评估

– 调用内部 API 需创建技能包装,并解决格式错误问题

– 质量稳定性方面,低估了检测幻觉和提高质量分数的难度

– 容量与延迟方面,关注质量与延迟、吞吐量与延迟、成本等,实现端到端流式处理和异步非阻塞管道

– 展示与总结

– 期待后续推出更多优化成果和分享技术细节

思维导图:

文章地址:https://mp.weixin.qq.com/s/0AP0kckR_299QHaYq9zFdw

文章来源:mp.weixin.qq.com

作者:萧夫

发布时间:2024/8/3 17:40

语言:中文

总字数:5083字

预计阅读时间:21分钟

评分:91分

标签:多Agent系统,生成式AI,端到端流式处理,LinkedIn,职业规划


以下为原文内容

本内容来源于用户推荐转载,旨在分享知识与观点,如有侵权请联系删除 联系邮箱 media@ilingban.com

在过去的六个月,LinkedIn 开发了基于自身业务的生成式AI应用。领英团队希望能重新设计求职流程,改变专业内容的浏览方式。

现在,用户可以不用再刷新招聘软件上更新的招聘信息。求职者可以通过 AI 直接获取信息,得到基于大数据的职位评估和职场建议。这一改进加快了人们的信息获取速度,还增强了职位适配的判断力和个人职业规划的指导。

构建基于生成式 AI 的应用不是一件简单的事儿。领英团队表示,自己在多个方面遇到了阻碍。本文是团队分享的「幕后工程」故事,文中将展现产品打造的挑战与成就,以及未来的发展方向。

要点总结:

  1. 多 Agent 的设计过程分而治之,拆解出公共的部分和垂直领域部分分别开发,能够保持一致性的同时大大提效

  2. 巧妙地设计测评过程,动员团队所有角色共同参与到测评中保证上线质量

  3. 将内部 API 翻译成 LLM 友好可利用的 API,需要进一步丰富描述

  4. 端到端的流式输出,获得关键信息后可快速进入下一步,明显降低时延

01

AI 在领英的应用

以一个实际场景为例,来看我们系统的实际运行过程:

想象你在滚动你的 LinkedIn 动态,偶然间发现了一个关于设计可访问性的有意思的帖子。在帖子旁边,你会看到一些入门问题,让你更深入地了解这个话题。你出于好奇点击了「在科技公司中,可访问性如何推动业务价值的例子是什么?」

以下是背后发生的事情:

  1. 选择合适的 Agent:系统会分析你的问题,并确定最合适的 Agent 进行处理。此例中,系统依据你对科技公司中设计可访问性的兴趣,将你的问题定向到专门处理此类查询的 Agent。

  2. 信息搜集:此时 Agent 需要搜集信息,通过调用内部 API 和 Bing,寻找展示设计可访问性如何提升科技公司商业价值的相关案例。

  3. 生成回复:凭借搜集的资料,Agent 编制回答,具体展示如何通过增强可访问性来提升科技公司的商业价值。为了避免生成大段文字且增加互动性,系统还会通过调用内部 API 添加如相关文章链接或提及人物的简介等内容.

您可能会追问:”我如何将我的职业生涯转向这个领域?”,系统会继续提供支持,此时会转由专门的职业和就业 Agent 处理。这一过程仅需几次点击,你便可以深入探讨任何主题,获取实际可行的见解或发现下一个重大机会。

我们的许多进展都得益于大型语言模型(”LLM”)的快速发展。分享在此基础上构建应用时遇到的挑战和经验,对我们来说是非常有价值的。


02

轻松实现的部分

总体设计

Figure1. 处理用户查询的简化流程。KSA 代表 “知识共享”Agent,

是可以处理用户查询的数十个 Agent 之一

您可能已经注意到,我们的系统采用了一种被称为检索增强生成(”RAG”)的设计模式,这是生成式 AI 系统中的常规配置。意外的是,建立这样的流程比我们预期的要简单。在短短几天内,我们就构建了基础框架:

  • 路由(Routing):确定查询是否在处理范围内,并决定将其分配给哪个 AI Agent。例如,这些 Agent 可能负责工作评估、公司分析或提取帖子的要点。

  • 检索(Retrieval):以召回为导向的步骤,AI Agent 决定调用哪些服务以及如何调用(例如 LinkedIn 人员搜索、Bing API 等)。

  • 生成(Generation):这是一个以精度为目标的步骤,它会筛选并处理检索到的庞杂数据,生成最终的响应。

鉴于 “路由 “和 “检索 “的分类性质,对它们进行调整感觉更自然:我们创建了专用的开发集,并通过提示工程和内部模型进行了优化。然而,生成阶段的工作则更为复杂。这部分工作遵循 二八原则:快速完成前 80% 的工作,而最后 20% 则需要投入大量精力。当产品的期望是 99%+ 的回答都应该很好时,即便使用最先进的模型也仍需大量工作和创造力来实现每一个 1% 的提升。

我们的有效做法包括:

  • 设立了固定的三步流程

  • 使用小型模型处理路由和检索任务,而生成任务则采用更大的模型

  • 通过内存数据库支持的基于嵌入的检索(EBR),作为我们的低成本微调手段,直接将响应示例整合进提示中

  • 针对各个步骤特殊设定评估流程,尤其是在路由和检索阶段

开发速度

为了在多个团队间快速进展,我们选择将任务分配给不同人员开发的各种独立 AI Agent,如常规知识、职位评估和摘要提取等。

然而,这种方法带来了显著的缺陷。通过任务并行处理,我们在速度上获得了提升,但代价是系统碎片化。当后续与助手的互动可能由不同的模型、提示或工具管理时,维护统一的用户体验变得具有挑战性。

为了解决这一问题,我们采用了简单的组织结构:

我们的成功经验:


03

遇到的困难与挑战

评价我们回答的质量证明比我们预期的要困难得多。这些挑战主要涉及三个方面:制定评估标准、扩展数据标注和实现自动化评估。

  • 制定评估标准是首个难题。以职位评估为例:单纯告诉用户「你不适合这个职位」并没有太大帮助。我们的回答需要基于事实,同时也要体现出同理心。例如,对于那些希望转行但当前能力尚有不足的用户,我们需要帮助他们明确能力差距及后续步骤。保证这些细节的一致性是确保评估得分统一的关键。

  • 扩展数据标注是第二步。起初,团队中的每个人都参与评估(包括产品、工程和设计团队),但我们很快意识到需要一个更系统的方法,这要求注释者既要保持一致性也要具备多样性。我们的语言学团队开发了工具和流程,可以每天评估多达 500 个对话,收集包括总体质量评分、幻觉发生率、负责任 AI 的遵守情况、逻辑连贯性和风格等多个维度的数据。这成为我们洞察趋势、优化提示词以及确保产品上线前准备充分的重要依据。

  • 自动评估虽然是理想状态,但实现起来充满挑战。在没有自动化工具的情况下,工程师只能依靠肉眼判断和有限的样本进行测试,而且通常需要超过一天的时间来学习评估标准。我们正在开发基于模型的评估工具来快速进行实验,并在检测幻觉方面取得了一定的成果,但这个过程并不容易。

Figure2. 我们执行的评估步骤。工程师执行快速、粗略的评估,以获得方向性指标。注释员提供更细化的反馈,但周转时间约为 1 天。成员是最终的评判者,为我们提供规模,但某些指标的单次更改可能需要 3 天以上的时间

我们正在进行的工作:开发一个端到端的自动评估流程,以加快迭代速度。

调用内部API

LinkedIn 拥有大量关于个人、公司、技能和课程等的独特数据,这些数据对于打造具有独特价值和差异化的产品至关重要。然而,由于 LLM 未接受这些信息的训练,它无法直接利用这些数据进行推理和回答生成。我们采用的标准做法是建立一个检索增强生成(RAG)流程,通过这一流程调用内部 API,并将其响应嵌入到后续的 LLM 提示中,为生成的回答提供必要的背景信息。

这些独特的数据通过不同微服务的 RPC API 在内部公开,尽管这对程序化调用非常便利,但并不完全适合 LLM。为了解决这个问题,我们为这些 API 创建了「技能」包装。每项技能都包括以下几个部分:

  • 人类(因此也是 LLM)友好的 API 功能描述及使用时机。

  • 调用 RPC API 的配置(端点、输入架构、输出架构等)。

  • LLM 友好的输入和输出架构

    • 原始类型(字符串/布尔/数字)值

    • JSON 模式风格的输入和输出模式描述

  • 将 LLM 友好的架构与实际 RPC 架构进行映射的业务逻辑

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

Figure3. 使用技能调用内部 API

我们设计了提示词,要求 LLM 决定使用什么技能来解决特定工作(通过规划选择技能),然后输出调用技能的参数(函数调用)。由于调用的参数必须与输入模式相匹配,因此我们要求 LLM 以结构化的方式输出这些参数。大多数 LLM 都是通过 YAML 和 JSON 进行结构化输出的。我们之所以选择 YAML,是因为它不太啰嗦,因此比 JSON 消耗更少的标记。

我们遇到的一个挑战是,尽管大多数时候 LLM 的响应格式正确,但大约 10% 的时间会出现错误,通常输出的数据不符合所提供的架构,甚至不是有效的 YAML。这些错误虽然对人类容易识别,但却使得解析代码出现问题。由于这类错误的比例足够高,我们无法忽视,因此我们着手解决这一问题。

解决这一问题的常规方法是检测错误后重新提示 LLM,要求其在额外的指导下纠正错误。虽然这种方法有效,但它增加了相当的延迟,并且因为额外的 LLM 调用而消耗了宝贵的 GPU 资源。为了规避这些限制,我们最终开发了一个内部防御性的 YAML 解析器。

通过分析各种数据负载,我们确定了 LLM 常见的错误,并编写了代码在解析前适当地检测和修复这些错误。我们还修改了我们的提示,在其中嵌入关于这些常见错误的提示,以提高修复的准确性。我们最终能够将这些错误的发生率降低到约 0.01%。

我们正在开发的内容:一个统一的技能注册表,用于动态发现和调用 API/Agent,并将其打包为 LLM 友好型技能,供我们的生成式人工智能产品使用。

质量稳定性

我们的团队在第一个月内就完成了基本体验的 80%,我们一直在努力完善、调整和改进各个方面,随后又花了四个月的时间试图达到 95% 的完整体验目标。但还是低估了检测和减少幻觉的挑战,也低估了质量分数的提高速度–最初是直线上升,然后迅速趋于平稳。

对于能够容忍这种程度错误的产品体验来说,使用生成式人工智能进行构建令人耳目一新。但它也带来了难以实现的期望,最初的速度让人产生一种 “就快成功了 “的错觉,而随后每提高 1%,改进速度就会明显放缓,这让人感到气馁。

构建这样的助手,感觉像是从更有原则的机器学习中脱离出来,更像是在专家系统中调整规则。因此,虽然我们的评估变得越来越复杂,但我们的「训练」主要是依赖 prompt engineering,这与其说是一门科学,不如说是一门艺术。

我们正在进行的工作:微调大型语言模型(LLM),使我们的流程更加依赖数据驱动。

容量与延迟

容量和感知到的用户延迟始终是我们关注的重点。一些重要方面包括:

  • 质量与延迟:如思维链(CoT)等技术在提高质量和减少幻觉方面非常有效,但它们需要消耗用户看不见的 Token,因此增加了感知延迟。

  • 吞吐量与延迟:运行大型生成模型时,随着使用率的增加,首次生成 Token 的时间(Time To First Token,TTFT)和 Token 之间的时间(Time Between Tokens,TBT)通常会增加。就 TBT 而言,有时可能是线性增长。如果愿意牺牲这两个指标,获得 2 倍或 3 倍的每秒 Token 数(TPS)并不罕见,但我们最初必须严格控制这些指标。

  • 成本:GPU 集群不易获得且成本高昂。一开始我们甚至设定了测试产品的时间表,因为它会消耗过多 Token,阻止开发人员工作。

  • 端到端流式处理:完整回答可能需要几分钟时间,因此我们让所有请求都进行流式处理以减少感知延迟。更重要的是,我们实际上在整个流程中实现了端到端的流式处理。例如,LLM 响应决定调用哪些 API 会被逐步解析,我们在参数准备好后立即触发 API 调用,而不等待完整的 LLM 响应。最终合成的回应也通过我们的实时消息基础设施流式传输到客户端,通过增量处理(如信任/负责任的人工智能分类)一路流式传输到客户端。

  • 异步非阻塞管道:由于 LLM 调用可能需要较长时间处理,我们通过构建一个完全异步的非阻塞管道优化了服务吞吐量,不会因 I/O 阻塞而浪费资源。

这些方面有时会相互作用。例如,我们最初只限制了 TTFT,因为这直接关系到我们最初产品的用户延迟。当我们解决幻觉问题并在提示中引入思维链时,我们忽略了 TBT 会给我们带来更大的影响,任何「推理」Token 都会增加用户延迟(例如,对于 200 个 Token 的推理步骤,即使 TBT 增加 10 毫秒也意味着额外 2 秒的延迟)。这导致我们的一个公开发布突然发出警报,指出一些任务达到超时,我们迅速增加了容量以缓解这一问题。

我们正在进行的工作:

  • 将更简单的任务转移到内部微调模型

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

  • 减少每一步浪费的 Token

04

展示与总结

我们已经说了很多,不如让产品自己来表达如何?

这还不错!特别是后续的建议,可能会让你像探索维基百科一样好奇地深入了解。

随着我们继续提升质量,开发新功能,并优化速度流程,我们很快就会向更多用户推出。

达到这一步是一个团队出色的集体努力的结果,仍然在不断学习的过程中,我们将很快与大家分享更多技术细节。敬请期待!


转载原创文章请添加微信:founderparker