原作者是：JuanPabloBottaroandCo-authoredbyKarthikRamgopal
在过去的六个月里，在领英我们的团队一直致力于开发一种新的AI驱动的产品体验。我们想重新构想会员们进行求职和浏览专业内容的方式。
生成式人工智能的爆发让我们停下脚步，思考现在能够实现而一年前还无法实现的事情。我们尝试了许多想法，但都不怎么灵。最终以信息流和招聘启事切入找到了释放AI强大力量的方法，它可以帮助用户：
●总结关键点，例如从帖子中总结要点或了解各个公司的最新动态。
●关联不同信息，例如评估自己与某个职位的匹配度。
●获取建议，例如改进个人资料或准备面试。
●等等……
概览让我们通过一个真实场景来展示这个系统是如何工作的。
想象一下，你正在浏览领英的动态，偶然发现了一篇关于产品设计中确保残障人士可访问性（注:就是那种系统里可以把字体放大好多倍的功能）的有趣帖子。在帖子旁边，你看到了几个入门问题，以便你更深入地了解这个主题。你感到好奇，点击了“有哪些例子说明确保残障人士可访问性可以推动科技公司的商业价值？”这时候，在幕后发生了以下事情：
1.选择合适的智能体：这是一切的原点。我们的系统接收你的问题，并决定哪个AI智能体最适合处理它。在上面这个例子中，它识别出你对科技公司中如何确保残障人士可访问性感兴趣，就会将你的问题导引到负责一般知识性问题的AI智能体。
2.收集信息：然后就得做些基础工作。AI智能体会调用内部API和Bing，搜索具体的例子和研究案例，这些例子和研究案例突出了设计中的确保这种可访问性与科技公司商业价值的关联。这些就是产生最终回答的原始素材库。
作为用户你可能会接着问“我如何将自己的职业转向这个领域？”，然后我们会重复上面这三个步骤，但这次会将你路由到职业和工作的AI智能体。只需点击几下，你就可以深入了解任何主题，获得可操作的见解或找到你下一个大好机会。
轻松实现的部分
整体设计
图1：简化的用户查询过程。KSA代表“知识共享智能体”，是数十个能够处理用户查询的智能体之一
大家可能已经注意到，我们的流程遵循了检索增强生成（RAG），这是生成式AI系统中常见的设计模式。构建这个流程比我们预期的要容易得多。在短短几天内，我们就搭建好了基本框架并使其运行起来：
1.路由(Routing)：判断问题是否在处理范围内，是的话将其转发给哪个AI智能体。智能体的例子包括：岗位评估、理解公司、帖子要点提取等各种智能体。
2.检索(Retrival)：这是一个逐步确定详细信息的步骤（召回率导向的步骤），AI智能体决定调用哪些服务以及如何调用（例如，LinkedInPeopleSearch、BingAPI等）。
3.生成(Generation)：这是一个精准度导向的步骤，它筛选检索到的各种数据，过滤它，并产生最终响应内容。
对我们而言好使的招数是：
●固定的三步流程
●用小模型干路由/检索，用大模型干生成
●基于内存数据库的EBR（Embedding-BasedRetrieval(EBR)），直接将响应示例注入到我们的提示词中（穷人版微调）。（注：EBR是个技术名词，感兴趣的自己再查吧。）
●在路由和检索过程中针对每个步骤做特定评估
开发速度
我们希望多个团队并行快速推进，因此决定将任务拆分为由不同人员开发的独立智能体（即AI智能体）：岗位评估、理解公司、帖子要点提取等智能体分别由不同团队负责。
这种方法带来了显著的不良影响（compromise）。通过并行处理任务，我们在速度上取得了优势，但这却以碎片化为代价。当与智能体的交互可能由不同的模型、提示词或工具管理时，保持统一的用户体验变得极其具有挑战性。
为了解决这个问题，我们采用了一个简单的组织结构：
●一个小型“横向”工程小组，负责处理公共组件并专注于整体体验。这包括：
○各种支撑此产品的基础服务
○评估/测试工具
○所有垂直领域使用的全局提示词模板（例如，智能体的全局身份标识、对话历史、越狱攻击的防护等）
○iOS/Android/Web客户端的共享UX组件（注：一般就是指按钮、下拉列表这些）
○一个服务器端驱动的UI框架，用于发布新的UI更改，而无需更改或发布客户端代码。（注：因为UI在服务端，那就需要有个在服务端生成UI的框架，很麻烦的一个东西）
●多个“纵向”工程小组，各自对其智能体拥有自主权，例如：
○个性化帖子摘要
○岗位匹配度评估
○面试技巧
那些东西对我们有用：
●分而治之，但限制智能体的数量
●建立一个中心化的，通过多轮对话支撑的评估过程
●共享提示词模板（如“身份”定义）、UX模板、工具及指令
不好搞的部分
评价输出好坏
评估我们回答的质量比预期的要困难得多。这些挑战大致来自三个方面：制定指南、扩展标注和自动评估。
制定指南：以岗位评估为例：点击“评估我是否适合这份工作”却得到“你非常不适合”的结果其实没啥用。我们希望它既具有事实性又充满同理心。有些用户可能正在考虑转行到他们目前并不十分适合的领域，并需要帮助了解差距和下一步行动。不能确保这些细节的一致性就没法让保持标注者保持评分的一致性。
扩展标注：最初，团队中的每个人都参与了讨论（产品、工程、设计等），但我们知道我们需要一个更加有原则的方法，拥有一致且多样化的标注者。我们内部的语言学家团队建立了工具和流程，使我们能够每天评估多达500次对话，并获得以下方面的指标：整体质量分数、幻觉率、负责任的人工智能违规情况、连贯性、风格等。这成为我们了解趋势、迭代提示词并确保我们准备好上线的主要参考点。
还在死磕的事：端到端自动评估流程，以实现更快的迭代。
调用内部API
领英拥有大量关于人、公司、技能、课程等的独特数据，这些数据对于构建具有独特和差异化价值的产品至关重要。然而，大语言模型（LLMs）并未经过这些信息的训练，因此无法直接用于推理和生成响应。为了解决这个问题，一个标准的做法是设置检索增强生成（RAG）流程，通过该流程调用内部API，并将它们的响应注入到后续的大语言模型提示词中，以提供额外的上下文来支持生成响应。
这些独特的数据中有很多是通过各种微服务中的远程过程调用（RPC）API在内部公开的。这些API虽然这对于人类通过编程方式调用非常方便，但对于大语言模型来说并不友好。我们通过把这些API“包装”成技能来解决这个问题。每个技能(Skill)都包含以下组件：
1.人类（和大语言模型）友好的描述：说明API的功能以及何时使用它。
2.RPCAPI调用配置：包括端点、输入、输出schema等。
3.大语言模型友好的输入和输出schema：
a.基本类型（如字符串/布尔值/数字）
b.JSON风格的输入和输出schema
4.业务逻辑：用于在大语言模型友好的schema与实际RPCschema之间进行映射。
（注：schema是个编程术语，也许可以翻译成模式，拿excel表作类比，表头是schema）
图3：使用技能调用内部API
我们编写了提示词，要求大语言模型（LLM）决定使用哪种技能来解决特定任务（通过规划来完成技能选择），然后输出调用该技能所需的参数（函数调用）。由于调用参数必须与输入schema匹配，我们要求LLM以结构化的方式输出它们。大多数LLM都经过YAML和JSON的结构化输出训练。我们选择YAML是因为它更简洁，因此消耗的tokens比JSON少。
解决这个问题的标准方法是检测到错误，然后重新发提示词给大语言模型，要求它在这些额外指示下纠正错误。虽然这种方法有效，但它增加了不小的延迟，并且由于额外的LLM调用而消耗了宝贵的GPU算力。为了绕过这些限制，我们最终编写了一个内部防御性YAML解析器。
通过对各种调用参数（payload）的分析，我们确定了LLM常犯的错误，并编写了代码来在解析之前检测和适当修补这些错误。我们还修改了提示词，以便在这些常见错误周围注入提示词，以提高我们修补的准确性。最终，我们将这些错误的发生率降低到了约0.01%。（注：这其实是用规则补足模型的不足，降低成本）
还在死磕的事是：构建一个统一的技能注册机制，以便在我们的生成式AI产品中动态发现和调用封装为LLM友好技能的API/智能体。（注：可以想象是个技能商店，智能音箱那种能够动态添加天气、音乐技能的机制）
保持统一的质量
对于那些容忍一定错误率的产品而言，采用生成式AI进行构建无疑是一种令人耳目一新的直接方法。但这也带来了不切实际的期望，初期的快速进展营造了一种“即将达成”的错觉，而随着后续每1%提升的改进速度显著放缓，这种快速改进的错觉变得令人沮丧。
构建该助手感觉像是偏离了“原则性”的机器学习，而更像是在专家系统中调整规则。因此，尽管我们的评估变得越来越复杂，但我们的“训练”却主要是提示词工程，这更像是一门艺术而非科学。
还在死磕的事：对大语言模型（LLMs）进行微调，以使我们的流程更加数据驱动。（注：其实是肯定会出问题，所以修的要快）
容量与延迟
容量和成员感知到的延迟始终是我们最关心的问题。以下是一些维度：
质量vs延迟：像“思维链”（ChainofThought,CoT）这样的技术非常有效地提高了质量并减少了幻觉现象。但它们需要成员从未预想过的tokens，因此增加了成员感知到的延迟。
端到端流式传输：一个完整的答案可能需要几分钟才能完成，因此我们让所有请求进行流式传输以减少感知到的延迟。更重要的是，我们实际上在流程内部实现了端到端的流式传输。例如，大语言模型（LLM）的响应会逐步解析出应调用的API，并在参数准备好后立即发起API调用，而无需等待完整的LLM响应。最终合成的响应也会通过我们的实时消息传递基础设施进行流式传输，并对信任/负责任的AI分类等内容进行增量处理，直至到达客户端。（注：就是通过流式提升可感知的响应速度，非流式会导致你等半天突然所有结果出来了）
还在死磕的事：
1.将更简单的任务转移到内部进行，并使用微调后的自己的模型进行处理。（注：潜在意思是专门化的模型要和通用大模型进行搭配）
2.为大语言模型（LLM）部署构建更可预测的基础设施。（注：不理解，我猜是LLM吞吐量伸缩需要更可控）
3.减少每个步骤中浪费的tokens。
收获
我们说的够多了，为什么不让产品自己说话呢？
这还不错！特别是后续的建议中让产品可以像维基百科那样带你进入一个充满好奇心的“知识黑洞”的功能。
随着我们不断提高质量、开发新功能并优化流程以加快速度，我们很快就会向更多用户推出上述功能。
这个时点的AI太混沌了，宣称有赚钱方法的大概率是骗子，宣称全无机会的又错的太厉害。研究AI就得解剖麻雀，研究案例，回到现场。反之越高大上、越论文就越危险。问题是案例不好找，所以就有了琢磨事AI碰撞局。研究清楚多个案例，弄明白底层套路，回到自己问题差不多是最靠谱的方式了。对活动感兴趣的同学请联系cathywangyue。老李话一三，公众号：琢磨事