这文章侯老师扔群里的，我看了发现实在很有价值。同时也发现这类文章直接扔给模型翻译还是让人看不明白，也好多错误，就手动翻了下。里面有些编程术语，看不懂可以看我补的注释，关注AI智能体的同学，这文章还是建议努力读完。4月底发的，差不多就是AI的在顶级公司落地的最新状态了。下面上全文。翻的比较随性，大家尽量看原文。

------------------------------------------------------------------------

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

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

● 总结关键点，例如从帖子中总结要点或了解各个公司的最新动态。

● 关联不同信息，例如评估自己与某个职位的匹配度。

● 获取建议，例如改进个人资料或准备面试。

● 等等……

那么，这活容易么？哪些进展顺利，哪些不好搞？在生成式人工智能的基础上构建应用其实很麻烦的。我们遇到了一堆难题。我们希望揭开这活的的神秘面纱，分享具体哪些部分好搞，哪些部分不好搞，以及接下来还需要搞定什么。

概览

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

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

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

1.  选择合适的智能体：这是一切的原点。我们的系统接收你的问题，并决定哪个AI智能体最适合处理它。在上面这个例子中，它识别出你对科技公司中如何确保残障人士可访问性感兴趣，就会将你的问题导引到负责一般知识性问题的AI智能体。

2.  收集信息：然后就得做些基础工作。AI智能体会调用内部API和Bing，搜索具体的例子和研究案例，这些例子和研究案例突出了设计中的确保这种可访问性与科技公司商业价值的关联。这些就是产生最终回答的原始素材库。

3.  编写回答：有了回答所需要的原始信息，智能体就开始编写回答了。它将数据过滤并综合成一个连贯、信息丰富的答案，为你提供明确回答。为了避免生成太多的文字并使体验更具互动性，会调用内部API来对回答进行修饰，比如加入文章链接或帖子中提到的人物的资料。

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

这一切在很大程度上得益于大语言模型（LLMs）的出现，我们认为进一步分享我们在构建这些功能时面临的挑战和幕后故事会很有趣。

轻松实现的部分

整体设计

图1：简化的用户查询过程。KSA代表“知识共享智能体”，是数十个能够处理用户查询的智能体之一

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

1.  路由(Routing)：判断问题是否在处理范围内，是的话将其转发给哪个AI智能体。智能体的例子包括：岗位评估、理解公司、帖子要点提取等各种智能体。

2.  检索(Retrival)：这是一个逐步确定详细信息的步骤（召回率导向的步骤），AI智能体决定调用哪些服务以及如何调用（例如，LinkedIn People Search、Bing API等）。

3.  生成(Generation)：这是一个精准度导向的步骤，它筛选检索到的各种数据，过滤它，并产生最终响应内容。

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

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

● 固定的三步流程

● 用小模型干路由/检索，用大模型干生成

● 基于内存数据库的EBR（Embedding-Based Retrieval (EBR) ），直接将响应示例注入到我们的提示词中（穷人版微调）。（注：EBR是个技术名词，感兴趣的自己再查吧。）

● 在路由和检索过程中针对每个步骤做特定评估

开发速度

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

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

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

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

○ 各种支撑此产品的基础服务

○ 评估/测试工具

○ 所有垂直领域使用的全局提示词模板（例如，智能体的全局身份标识、对话历史、越狱攻击的防护等）

○ iOS/Android/Web客户端的共享UX组件（注：一般就是指按钮、下拉列表这些）

○ 一个服务器端驱动的UI框架，用于发布新的UI更改，而无需更改或发布客户端代码。（注：因为UI在服务端，那就需要有个在服务端生成UI的框架，很麻烦的一个东西）

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

○ 个性化帖子摘要

○ 岗位匹配度评估

○ 面试技巧

那些东西对我们有用：

● 分而治之，但限制智能体的数量

● 建立一个中心化的，通过多轮对话支撑的评估过程

● 共享提示词模板（如“身份”定义）、UX模板、工具及指令

不好搞的部分

评价输出好坏

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

制定指南：以岗位评估为例：点击“评估我是否适合这份工作”却得到“你非常不适合”的结果其实没啥用。我们希望它既具有事实性又充满同理心。有些用户可能正在考虑转行到他们目前并不十分适合的领域，并需要帮助了解差距和下一步行动。不能确保这些细节的一致性就没法让保持标注者保持评分的一致性。

扩展标注：最初，团队中的每个人都参与了讨论（产品、工程、设计等），但我们知道我们需要一个更加有原则的方法，拥有一致且多样化的标注者。我们内部的语言学家团队建立了工具和流程，使我们能够每天评估多达500次对话，并获得以下方面的指标：整体质量分数、幻觉率、负责任的人工智能违规情况、连贯性、风格等。这成为我们了解趋势、迭代提示词并确保我们准备好上线的主要参考点。

自动评估是终极目标，但仍在进行中：没有它，工程师只能依靠主观判断和对有限示例的测试，并且需要1天以上的时间才能获得反馈。我们正在构建基于模型的评估器来估算上述指标，并允许更快的实验，我们在幻觉检测方面取得了一些成功（但这并不容易！）。

图2：我们执行的评估步骤。工程师进行快速、粗略的评估以获得方向性度量和判断。标注者提供更详细的反馈，但大约需要1天的时间。测试成员是最终的评判者，并为我们提供规模性的反馈，但单个更改的某些度量可能需要3天以上的时间。

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

调用内部API

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

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

1.  人类（和大语言模型）友好的描述：说明API的功能以及何时使用它。

2.  RPC API调用配置：包括端点、输入、输出schema等。

3.  大语言模型友好的输入和输出schema：

a.  基本类型（如字符串/布尔值/数字）

b.  JSON风格的输入和输出schema

4.  业务逻辑：用于在大语言模型友好的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/智能体。（注：可以想象是个技能商店，智能音箱那种能够动态添加天气、音乐技能的机制）

保持统一的质量

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

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

构建该助手感觉像是偏离了“原则性”的机器学习，而更像是在专家系统中调整规则。因此，尽管我们的评估变得越来越复杂，但我们的“训练”却主要是提示词工程，这更像是一门艺术而非科学。

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

容量与延迟

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

质量 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秒延迟）。这会导致我们公共平台上的某些任务突然发出超时警告，我们不得不迅速增加算力以缓解这一问题。

还在死磕的事：

1.  将更简单的任务转移到内部进行，并使用微调后的自己的模型进行处理。（注：潜在意思是专门化的模型要和通用大模型进行搭配）

2.  为大语言模型（LLM）部署构建更可预测的基础设施。（注：不理解，我猜是LLM吞吐量伸缩需要更可控）

3.  减少每个步骤中浪费的tokens。

收获

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

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

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

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