为什么构建AI原生应用需要使用消息队列

Ai小妖

已于 2024-12-03 17:31:46 修改

阅读量1.9k

点赞数 25

文章标签：人工智能

于 2024-12-03 11:22:52 首次发布

本文链接：https://blog.csdn.net/cd4_5792/article/details/144209303

版权

今天广大开发者都在积极投身AI原生应用的建设中，或多或少会发现，传统的同步架构方案在构建AI应用中遇到了一些瓶颈。这也是为什么说需要使用以消息队列为核心的事件驱动架构方案来构建AI原生应用的原因，针对来自消息中文社区的《基于 RocketMQ 事件驱动架构的 AI 应用实践》文章进行解读发现，AI原生应用的定义在趋近明确，基于消息队列的事件驱动架构在解决MAAS（模型服务）同步推理体验差、构建实时RAG数据流困难，提升拟人化的AI交互体验等有着的天独厚的优势。

AI原生应用的进化趋势- 基础模型到复杂的多智能体

AI 应用的变化随着业务的需求发展也在发生变化，从最开始基础模型的扩展到复杂的多智能体协作，体现企业内对AI诉求的升级，下方架构图能够明显的展示出AI应用架构跟传统应用架构的不同。

AI 原生应用全景架构

基于基础模型的扩展应用

MAAS 服务是AI 原生应用最直接的体现，基于基础模型的扩展百花齐放，

典型的如ChatGpt (文本生成）、StableDiffusion（图像生成）、CosyVoice （声音生成）等，这类应用通常会以模型能力为核心，提供相对原子化的服务。

智能知识库应用

知识库应用是以LLM基础模型为核心的高级应用架构，基于RAG（增强检索技术）将数据和模型服务进行连接，极大扩展了LLM模型服务的应用场景

RAG应用架构

阿里云AI助手

智能体应用，智能体应用核心要点是应用以LLM为交互中枢，能够通过工具的调用联通外部世界，复杂

的表现形式如多智能体协作等，是企业AI应用落地最具想象空间的一类应用。

Agent架构

Agent应用场景

AI应用场景的变化带来的架构升级的挑战

从基础模型应用到知识库应用再到智能体应用，应用场景的变化必然需要架构升级应对，传统的顺序调用方案在这类场景下遇到了一些问题和挑战：

顺序调用无法保障推理体验

模型服务的推理耗时远高于传统意义的网络服务调用，比如在文生图这个场景下使用StableDiffusion服务，即使经过算法优化后最快也是秒级，并发量较大的时候，会很容易导致服务器宕机。此外如声音的合成，数字人的合成等耗时可能是分钟级的，此时顺序调用明显就不太合适。选择事件驱动的架构可以快速响应用户，推理服务按需执行，这样既能够保障用户体验，同时也降低系统宕机风险。

顺序调用无法支持实时数据构建的需求

在智能问答系统中，结果的好坏跟数据有很大的关系。问答召回数据的实时性和准确性很大程度影响着智能问答系统的用户体验，从系统架构层面，问答和数据的更新是分开的。靠人工去更新海量数据不现实，通过设置定时任务以及构建知识库数据更新的工作流能够更加有效的解决数据实时更新的问题，事件驱动架构在这个场景下优势非常明显。

双向互动场景无法实现

在问答服务场景下，拟人化的行为能够得到用户好感从而扩展商机，传统的问答式应用架构相对机械死板，而使用消息队列作为信息传输可以有效主动触达用户，通过合理的意图判断，主动向用户问好，是有效的留存手段。

使用基于消息队列的事件驱动架构解决AI应用场景的挑战

同步推理到异步推理

前面提到了关于文生图模型StableDiffusion 在服务客户中遇到的问题，我们利用事件驱动架构，使用函数计算和MNS 构建了StableDiffusion的异步推理架构，用户请求到来时经过函数计算网关到达API代理函数，API代理函数对请求进行打标鉴权，之后将请求发送到MNS队列，同时记录请求的元数据和推理信息到表格存储TableStore, 推理函数根据任务队列进行消费，调度GPU实例启动StableDiffusion进行服务，结束后返回图片结果以及更新请求状态，端侧通过页面上的轮询告知用户。