领英AI实践经验精选指南

自Lilian Weng提出Agent框架图至今已满一年。这一年间，各大企业与初创团队纷纷尝试将Agent落地于真实业务场景，过程中积累的教训与经验弥足珍贵。近期LinkedIn团队发布的几篇实践回顾，信息密度极高，值得深入拆解。

01 整体架构透视

先看一个实际场景，理解系统如何运作。

假设你在浏览LinkedIn动态时，看到一篇关于“设计可访问性”的帖子。帖子旁附有几个入门级问题，引导你深入探索。你点击其中一个：“在科技公司中，可访问性如何驱动业务价值？”

系统在幕后执行三个步骤：

1. 路由至最合适的Agent：系统分析问题，识别“科技公司”与“可访问性”关键词，将其分派给专精此领域的Agent。
2. 信息检索：Agent调用内部API及Bing搜索，搜集说明可访问性提升商业价值的实际案例。
3. 答案生成：素材归集完成后，Agent整合信息，输出兼具案例与数据支撑的回复。为提升可读性，系统自动调用内部API，附上相关文章链接或人物简介，增强交互性。

你可能继续追问：“如何转行进入这个领域？”系统会无缝切换至另一个负责职业路径规划的Agent。整个过程只需几次点击，即可深入探讨一个主题，获得可落地的洞察。

这一切得益于大型语言模型（LLM）的快速演进。但模型本身仅是起点，落地过程中的真实挑战与应对策略，才是真正的价值所在。

02 相对顺畅的部分

系统设计

Figure1 用户查询处理简化流程。KSA代表“知识共享”Agent，是数十个可处理用户查询的Agent之一

不难看出，这套系统采用检索增强生成（RAG）模式，这在生成式AI应用中已是标配。有趣的是，搭建核心流程比预期快得多。团队仅用数天即完成框架搭建：

• 路由：判断查询是否在服务范围内，并指定应由哪个Agent处理。例如，有的Agent擅长岗位评估，有的聚焦公司分析，有的专门提取帖子要点。
• 检索：侧重“召回”。Agent需决策调用哪些服务（如人员搜索、Bing API等），以及如何调用。
• 生成：侧重“精度”。从检索到的庞杂数据中筛选、整合，最终形成高质量回复。

路由与检索环节带有明显的分类属性，调整起来相对顺手。团队为其专门构建了开发集，借助提示工程与内部模型优化。但生成阶段则完全不同。遵循典型的二八原则：前80%的工作可快速完成，后20%却需大量精力投入。当产品要求回答质量达到99%以上“优秀”时，即便使用最先进的模型，每提升1%都需绞尽脑汁。

团队在实践中总结出有效方法：

• 固定三步流程，不轻易变动
• 路由与检索使用小型模型，生成则交由更大模型
• 通过内存数据库支持的基于嵌入的检索（EBR），作为低成本微调手段，直接将响应示例嵌入提示中
• 针对每个步骤设立专项评估流程，尤其路由与检索阶段

开发速度

为在多团队协作中快速推进，初期将任务分配给不同人员，开发独立的Agent（如常规知识、岗位评估、摘要提取等）。

但这带来了明显副作用。任务并行虽提升速度，却导致系统碎片化。当用户与助手的多轮对话由不同模型、提示或工具管理时，维持统一用户体验变得极为困难。

解决方案采用简单的组织结构：

• 一个小型“横向”工程组，负责公共组件与整体体验。包括：托管产品的服务、评估/测试工具、所有垂直部门共用的全局提示模板（如Agent的身份、对话历史、越狱防御等），以及共享的UX组件和服务器驱动的UI框架。
• 多个拥有自主权的“垂直”工程组，例如负责个性化帖子摘要、岗位适配评估、面试技巧的团队。

成功经验可总结为：分而治之，同时严格控制Agent数量；对多轮对话进行集中评估；共享提示模板、UX设计模板、工具和仪表盘。

03 真正的挑战所在

评估

评估AI回答质量远比想象复杂。挑战主要来自三个方面：制定标准、扩展标注、自动评估。

• 制定标准是第一步。以岗位评估为例，单纯告知用户“你不适合”毫无价值。回答需基于事实，同时体现同理心。对想转行但能力不足的用户，要帮其看清能力差距与下一步行动。保证这些细节的一致性，是评估得分统一的关键。
• 扩展数据标注是第二步。初期所有成员（产品、工程、设计）都参与评估，但很快发现需要更系统的方法。标注者既要保持一致性，也要具备多样性。团队的语言学专家开发了工具与流程，每日可评估多达500个对话，收集包括总体质量评分、幻觉发生率、负责任AI合规性、逻辑连贯性、风格等多个维度的数据。这些数据成为洞察趋势、优化提示词、确认产品上线准备度的关键依据。
• 自动评估是理想目标，但实现难度极高。在无自动化工具时，工程师只能靠肉眼和有限样本测试，学习评估标准通常需要一天以上。团队正开发基于模型的评估工具以加速实验，在幻觉检测方面取得一定进展，但过程并不轻松。

Figure2 评估流程。工程师执行快速粗略评估以获取方向性指标。标注员提供细化反馈，但周转时间约需一天。成员是最终评判者，提供规模化优势，但某些指标单次更改可能需要三天以上。

团队当前重点：开发端到端自动评估流程，加快迭代速度。

调用内部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是因为更简洁，消耗的Token更少。

一个棘手挑战是，虽然LLM大部分时间格式正确，但约10%的情况会出现错误。最常见的是输出数据不符合架构，甚至不是有效YAML。这些错误对人类来说极易识别，但解析代码就会出错。由于错误率太高，必须认真解决。

常规方法是检测到错误后重新提示LLM，要求其在额外指导下纠正。虽然有效，但会增加延迟和GPU资源消耗。为规避这些限制，团队最终开发了内部防御性YAML解析器。通过分析大量数据负载，确定LLM常见错误类型，编写代码在解析前进行检测和修复。同时，在提示词中嵌入关于这些常见错误的提示，提高修复准确性。最终，将错误率降低至约0.01%。

团队当前重点：开发统一技能注册表，用于动态发现和调用API/Agent，并将其打包为LLM友好型技能，供整个生成式AI产品使用。

质量稳定性

团队在第一个月内完成了基本体验的80%，但接下来的四个月都在完善、调整，试图达到95%的完整目标。他们仍低估了检测和减少幻觉的难度，也低估了质量分数的提升曲线——开始时直线上升，随后很快趋于平稳。

对于能容忍一定错误的产品体验，用生成式AI构建应用会让人感觉爽快。但它也带来了难以实现的期望：初期的快速进展会让人产生“很快就能成功”的错觉，而后续每提升1%都异常缓慢，这种挫败感确实显著。

构建此类助手，感觉更像是在调整专家系统的规则，而不是进行更有原则的机器学习。因此，虽然评估变得越来越复杂，但“训练”主要依赖提示工程，这与其说是科学，不如说是艺术。

团队当前重点：微调大型语言模型（LLM），让流程更依赖数据驱动。

容量与延迟

容量和用户感知到的延迟，始终是团队关注的重点。几个关键点包括：

• 质量与延迟：如思维链（CoT）等技术，在提高质量和减少幻觉方面效果显著，但需要消耗用户看不见的Token，因此增加了感知延迟。
• 吞吐量与延迟：运行大型生成模型时，随着使用率增加，首次生成Token的时间（TTFT）和Token之间的时间（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 总结

说了这么多，不如让产品自己来证明吧。

来源：互联网