AI智能体产品案例深度思虑和分享

在过去的六个月里，在领英我们的团队一贯致力于开拓一种新的 AI 驱动的产品体验。
我们想重新构想会员们进行求职和浏览专业内容的办法。

天生式人工智能的爆发让我们停下脚步，思考现在能够实现而一年前还无法实现的事情。
我们考试测验了许多想法，但都不怎么灵。
终极以信息流和招聘缘由切入找到了开释AI强大力量的方法，它可以帮助用户：

总结关键点，例如从帖子中总结要点或理解各个公司的最新动态。
关联不同信息，例如评估自己与某个职位的匹配度。
获取建议，例如改进个人资料或准备口试。
等等……

那么，这活随意马虎么？哪些进展顺利，哪些不好搞？在天生式人工智能的根本上构建运用实在很麻烦的。
我们碰着了一堆难题。

我们希望揭开这活的的神秘面纱，分享详细哪些部分好搞，哪些部分不好搞，以及接下来还须要搞定什么。

一、概览

让我们通过一个真实场景来展示这个别系是如何事情的。

想象一下，你正在浏览领英的动态，有时创造了一篇关于产品设计中确保残障人士可访问性（注:便是那种系统里可以把字体放大好多倍的功能）的有趣帖子。
在帖子阁下，你看到了几个入门问题，以便你更深入地理解这个主题。
你感到好奇，点击了“有哪些例子解释确保残障人士可访问性可以推动科技公司的商业代价？”

这时候，在幕后发生了以下事情：

选择得当的智能体：这是统统的原点。
我们的系统吸收你的问题，并决定哪个AI智能体最适宜处理它。
在上面这个例子中，它识别出你对科技公司中如何确保残障人士可访问性感兴趣，就会将你的问题导引到卖力一样平常知识性问题的AI智能体。
网络信息：然后就得做些根本事情。
AI智能体会调用内部API和Bing，搜索详细的例子和研究案例，这些例子和研究案例突出了设计中的确保这种可访问性与科技公司商业代价的关联。
这些便是产生终极回答的原始素材库。
编写回答：有了回答所须要的原始信息，智能体就开始编写回答了。
它将数据过滤并综合成一个连贯、信息丰富的答案，为你供应明确回答。
为了避免天生太多的笔墨并使体验更具互动性，会调用内部API来对回答进行润色，比如加入文章链接或帖子中提到的人物的资料。

作为用户你可能会接着问“我如何将自己的职业转向这个领域？”，然后我们会重复上面这三个步骤，但这次会将你路由到职业和事情的AI智能体。
只需点击几下，你就可以深入理解任何主题，得到可操作的见地或找到你下一个大好机会。

这统统在很大程度上得益于大措辞模型（LLMs）的涌现，我们认为进一步分享我们在构建这些功能时面临的寻衅和幕后故事会很有趣。

1. 整体设计

图1：简化的用户查询过程。

KSA代表“知识共享智能体”，是数十个能够处理用户查询的智能体之一

大家可能已经把稳到，我们的流程遵照了检索增强天生（RAG），这是天生式AI系统中常见的设计模式。
构建这个流程比我们预期的要随意马虎得多。
在短短几天内，我们就搭建好了基本框架并使其运行起来：

路由(Routing)：判断问题是否在处理范围内，是的话将其转发给哪个AI智能体。
智能体的例子包括：岗位评估、理解公司、帖子要点提取等各种智能体。
检索(Retrival)：这是一个逐步确定详细信息的步骤（召回率导向的步骤），AI智能体决定调用哪些做事以及如何调用（例如，LinkedIn People Search、Bing API等）。
天生(Generation)：这是一个精准度导向的步骤，它筛选检索到的各种数据，过滤它，并产生终极相应内容。

鉴于“路由”和“检索”的分类性子，微调它们相对顺畅：我们构建了开拓测试集，并利用提示词工程和内部模型进行优化。
然而，“天生”则是一个完备不同的故事。
它遵照80/20法则；很快可以达到80%的准确度，但剩下的20%却耗费了我们大部分人的所有事情韶光。
当你的产品期望99%以上的答案都非常出色时，纵然利用最前辈的模型，每一个1%的进步也仍旧须要大量的事情和创造力。

对我们而言好使的招数是：

固定的三步流程用小模型干路由/检索，用大模型干天生基于内存数据库的EBR（Embedding-Based Retrieval (EBR) ），直接将相应示例注入到我们的提示词中（穷汉版微调）。
（注：EBR是个技能名词，感兴趣的自己再查吧。
）在路由和检索过程中针对每个步骤做特定评估

2. 开拓速率

我们希望多个团队并行快速推进，因此决定将任务拆分为由不同职员开拓的独立智能体（即AI智能体）：岗位评估、理解公司、帖子要点提取等智能体分别由不同团队卖力。

这种方法带来了显著的不良影响（compromise）。
通过并行处理任务，我们在速率上取得了上风，但这却以碎片化为代价。
当与智能体的交互可能由不同的模型、提示词或工具管理时，保持统一的用户体验变得极其具有寻衅性。

为理解决这个问题，我们采取了一个大略的组织构造：

1）一个小型“横向”工程小组，卖力处理公共组件并专注于整体体验。
这包括：

各种支撑此产品的根本做事评估/测试工具所有垂直领域利用的全局提示词模板（例如，智能体的全局身份标识、对话历史、越狱攻击的防护等）iOS/Android/Web客户真个共享UX组件（注：一样平常便是指按钮、下拉列表这些）一个做事器端驱动的UI框架，用于发布新的UI变动，而无需变动或发布客户端代码。
（注：由于UI在做事端，那就须要有个在做事端天生UI的框架，很麻烦的一个东西）

2）多个“纵向”工程小组，各自对其智能体拥有自主权，例如：

3）那些东西对我们有用：

分而治之，但限定智能体的数量建立一个中央化的，通过多轮对话支撑的评估过程共享提示词模板（如“身份”定义）、UX模板、工具及指令

3. 评价输出好坏

评估我们回答的质量比预期的要困难得多。
这些寻衅大致来自三个方面：制订指南、扩展标注和自动评估。

制订指南：以岗位评估为例：点击“评估我是否适宜这份事情”却得到“你非常不适宜”的结果实在没啥用。
我们希望它既具有事实性又充满同理心。
有些用户可能正在考虑转行到他们目前并不十分适宜的领域，并须要帮助理解差距和下一步辇儿为。
不能确保这些细节的同等性就没法让保持标注者保持评分的同等性。
扩展标注：最初，团队中的每个人都参与了谈论（产品、工程、设计等），但我们知道我们须要一个更加有原则的方法，拥有同等且多样化的标注者。
我们内部的措辞学家团队建立了工具和流程，使我们能够每天评估多达500次对话，并得到以下方面的指标：整体质量分数、幻觉率、负任务的人工智能违规情形、连贯性、风格等。
这成为我们理解趋势、迭代提示词并确保我们准备好上线的紧张参考点。
自动评估是终极目标，但仍在进行中：没有它，工程师只能依赖主不雅观判断和对有限示例的测试，并且须要1天以上的韶光才能得到反馈。
我们正在构建基于模型的评估器来估算上述指标，并许可更快的实验，我们在幻觉检测方面取得了一些成功（但这并不随意马虎！
）。

图2：我们实行的评估步骤。

工程师进行快速、粗略的评估以得到方向性度量和判断。
标注者供应更详细的反馈，但大约须要1天的韶光。
测试成员是终极的评判者，并为我们供应规模性的反馈，但单个变动的某些度量可能须要3天以上的韶光。

还在去世磕的事：端到端自动评估流程，以实现更快的迭代。

4. 调用内部API

领英拥有大量关于人、公司、技能、课程等的独特数据，这些数据对付构建具有独特和差异化代价的产品至关主要。
然而，大措辞模型（LLMs）并未经由这些信息的演习，因此无法直接用于推理和天生相应。
为理解决这个问题，一个标准的做法是设置检索增强天生（RAG）流程，通过该流程调用内部API，并将它们的相应注入到后续的大措辞模型提示词中，以供应额外的高下文来支持天生相应。

这些独特的数据中有很多是通过各种微做事中的远程过程调用（RPC）API在内部公开的。
这些API虽然这对付人类通过编程办法调用非常方便，但对付大措辞模型来说并不友好。
我们通过把这些API“包装”成技能来办理这个问题。
每个技能(Skill)都包含以下组件：

人类（和大措辞模型）友好的描述：解释API的功能以及何时利用它。
RPC API调用配置：包括端点、输入、输出schema等。

大措辞模型友好的输入和输出schema：

基本类型（如字符串/布尔值/数字）JSON风格的输入和输出schema

业务逻辑：用于在大措辞模型友好的schema与实际RPC schema之间进行映射。

（注：schema是个编程术语，也容许以翻译成模式，拿excel表作类比，表头是schema）

这样的技能使大措辞模型能够实行与我们的产品干系的各种任务，如查看个人资料、搜索文章/职员/职位/公司，乃至查询内部分析系统。
同样的技能也用于调用非LinkedIn API，如Bing搜索和新闻。

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

我们编写了提示词，哀求大措辞模型（LLM）决定利用哪种技能来办理特界说务（通过方案来完成技能选择），然后输出调用该技能所需的参数（函数调用）。
由于调用参数必须与输入schema匹配，我们哀求LLM以构造化的办法输出它们。
大多数LLM都经由YAML和JSON的构造化输出演习。
我们选择YAML是由于它更简洁，因此花费的tokens比JSON少。

我们碰着的一个寻衅是，虽然大约90%的韶光里，LLM的相应包含了精确格式的参数，但有大约10%的韶光，LLM会出错（注：常常说的幻觉），并且常常输出不符合哀求的数据，或者更糟糕的是，乃至不是有效的YAML。
虽然这些缺点对人类来说微不足道，但会导致解析它们的代码出错。
由于10%的比例足够高，我们不能忽略这些微不足道的缺点，因此我们动手办理这个问题。

办理这个问题的标准方法是检测到缺点，然后重新发提示词给大措辞模型，哀求它在这些额外指示下纠正缺点。
虽然这种方法有效，但它增加了不小的延迟，并且由于额外的LLM调用而花费了宝贵的GPU算力。
为了绕过这些限定，我们终极编写了一个内部防御性YAML解析器。

通过对各种调用参数（payload）的剖析，我们确定了LLM常犯的缺点，并编写了代码来在解析之前检测和适当修补这些缺点。
我们还修正了提示词，以便在这些常见缺点周围注入提示词，以提高我们修补的准确性。
终极，我们将这些缺点的发生率降落到了约0.01%。
（注：这实在是用规则补足模型的不敷，降落本钱）

还在去世磕的事是：构建一个统一的技能注册机制，以便在我们的天生式AI产品中动态创造和调用封装为LLM友好技能的API/智能体。
（注：可以想象是个技能商店，智能音箱那种能够动态添加景象、音乐技能的机制）

5. 保持统一的质量

团队在首月内实现了我们目标体验的80%，随后又额外花费了四个月韶光，致力于将我们的全面体验完成度提升至95%以上——我们勤奋地事情，对各个方面进行风雅化调度、优化和改进。
然而，我们低估了检测和减轻幻觉征象的寻衅，以及质量评分提升的难度（注：原文是速率该当是笔误）——起初迅速攀升，随后便迅速达到瓶颈期。

对付那些容忍一定缺点率的产品而言，采取天生式AI进行构建无疑是一种令人线人一新的直接手法。
但这也带来了不切实际的期望，初期的快速进展营造了一种“即将达成”的错觉，而随着后续每1%提升的改进速率显著放缓，这种快速改进的错觉变得令人沮丧。

构建该助手觉得像是偏离了“原则性”的机器学习，而更像是在专家系统中调度规则。
因此，只管我们的评估变得越来越繁芜，但我们的“演习”却紧张是提示词工程，这更像是一门艺术而非科学。

还在去世磕的事：对大措辞模型（LLMs）进行微调，以使我们的流程更加数据驱动。
（注：实在是肯定会出问题，以是修的要快）

6. 容量与延迟

容量和成员感知到的延迟始终是我们最关心的问题。
以下是一些维度：

质量 vs 延迟：像“思维链”（Chain of Thought, CoT）这样的技能非常有效地提高了质量并减少了幻觉征象。
但它们须要成员从未预想过的tokens，因此增加了成员感知到的延迟。
吞吐量 vs 延迟：在运行大模型时，常日情形是“首个Token相应韶光”（TimeToFirstToken, TTFT）和“Token间相应韶光”（TimeBetweenTokens, TBT）会随着利用率的增加而增加。
在TBT的情形下，有时延迟乃至会呈现线性增长。
如果你乐意捐躯这两个方面的度量，得到每秒Tokens数（TokensPerSecond, TPS）的两倍或三倍增加是很随意马虎的，但我们最初必须将它们限定得很紧。
（注：否则用户会以为慢）本钱：GPU集群并不随意马虎得到且本钱高昂。
在初期，我们乃至不得不为产品测试设定时间表，由于测试会花费太多tokens并阻挡开拓职员事情。
端到端流式传输：一个完全的答案可能须要几分钟才能完成，因此我们让所有要求进行流式传输以减少感知到的延迟。
更主要的是，我们实际上在流程内部实现了端到真个流式传输。
例如，大措辞模型（LLM）的相应会逐步解析出应调用的API，并在参数准备好后立即发起API调用，而无需等待完全的LLM相应。
终极合成的相应也会通过我们的实时通报根本举动步伐进行流式传输，并对信赖/负任务的AI分类等内容进行增量处理，直至到达客户端。
（注：便是通过流式提升可感知的相应速率，非流式会导致你等半天溘然所有结果出来了）异步非壅塞管道：由于LLM调用可能须要很永劫光来处理，我们通过构建一个完备异步非壅塞的管道来优化做事吞吐量，该管道不会因I/O壅塞的线程而摧残浪费蹂躏资源。

这些成分之间有时会产生有趣的相互浸染。
举个例子，我们最初只限定了首个Token相应韶光（TimeToFirstToken, TTFT），由于这对付我们初期产品延迟有直接影响。
然而，随着我们办理幻觉问题，并且思维链（Chain of Thought, CoT）在我们的提示词中变得突出，如果我们忽略了Token间相应韶光（TimeBetweenTokens, TBT）会对我们造成更大的侵害，由于任何“推理”token都会增加产品的延迟（例如，对付一个200个tokens的推理步骤，纵然是10毫秒的TBT增加也意味着额外的2秒延迟）。
这会导致我们公共平台上的某些任务溘然发出超时警告，我们不得不迅速增加算力以缓解这一问题。

还在去世磕的事：

将更大略的任务转移到内部进行，并利用微调后的自己的模型进行处理。
（注：潜在意思是专门化的模型要和通用大模型进行搭配）为大措辞模型（LLM）支配构建更可预测的根本举动步伐。
（注：不理解，我猜是LLM吞吐量伸缩须要更可控）减少每个步骤中摧残浪费蹂躏的tokens。

二、收成

我们说的够多了，为什么不让产品自己说话呢？

这还不错！
特殊是后续的建议中让产品可以像维基百科那样带你进入一个充满好奇心的“知识黑洞”的功能。

随着我们不断提高质量、开拓新功能并优化流程以加快速率，我们很快就会向更多用户推出上述功能。

能够走到这一步，离不开一群精良人士的巨大努力，我们将连续学习并很快分享更多技能细节。
敬请期待！

注：这里的产品、工程实践实在和琢磨事之前分享的各种内容基本全部吻合，拜会

原文链接：https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product

原作者是：Juan Pablo BottaroandCo-authored byKarthik Ramgopal

专栏作家

琢磨事，微信"大众年夜众号：琢磨事，大家都是产品经理专栏作家。
声智科技副总裁。
著有《终极复制：人工智能将如何推动社会巨变》、《完美软件开拓：方法与逻辑》、《互联网+时期的7个引爆点》等书。

本文原创发布于大家都是产品经理。
未经容许，禁止转载。

题图来自 Unsplash，基于 CC0 协议

该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。