一图快速理解大模型应用架构

最新推荐文章于 2024-10-14 11:35:11 发布

鹏哥聊AI

最新推荐文章于 2024-10-14 11:35:11 发布

阅读量1.2k

点赞数 29

文章标签：架构

本文链接：https://blog.csdn.net/2401_86636311/article/details/142717582

版权

前言-PREFACE

传统应用架构有句真理，任何抛开需求空谈谈架构的行为都是在耍流氓。大模型虽然有其特殊的技术特点，但其终极目标仍然是以最合理的方式实现业务需求，千万不要为了只是追求技术新颖或体现技术水平而设计架构。

本文以当前大模型主要应用领域的常用架构设计为参考，用一图对当前应用架构的主要方式进行概述，让读者对当前大模型应用架构的全貌有个基本的认识和理解，但是如果涉及到具体项目实施中，需要结合业务诉求和技术特点进行调整和改良。

大模型应用架构概述-Overview of AI Application Architecture

随着云服务和动态资源分配能力的发展，使用微服务架构基本上是大模型应用架构的通用选择，下图对大模型的应用架构进行了概述：

以下内容将结合笔者经验，对上述架构描述的主要内容以及注意事项进行简要介绍，读者如果想了解很多细节或者有问题交流，欢迎关注本公众号私信或者评论区留言。

1. 客户端

大模型的客户端可以是Web页面、移动端或者通过API接口的访问，通常来说，Web和移动端的技术主要使用以下技术栈：

Web端：React + Redux + Axios + Material UI
移动端（iOS）：Swift + SwiftUI + Alamofire
移动端（Android）： Kotlin + Jetpack Compose + Retrofit

以上各技术栈的内容不是本文重点，不再赘述。

特别需要关注的内容：

通信机制：因为大模型响应时间长且文字类的应答处于持续回传的状态，客户端和服务端之间通信需要进行特殊考虑，一般建议使用Http SSE的方式，该方式是在服务端和客户端建立一个长连接，客户端向服务器发起一个HTTP GET请求，服务器保持连接不关闭。服务器通过这个长连接，可以随时向客户端推送数据。
注重用户体验：近期Open AI发布的Canvas，有兴趣的读者可以了解一下。另外建立缓存应对重复提交、异常情况友好提示（如网络问题等）等，都是需要考虑的内容。

2. 服务端

首先说明一下，图中将应用架构中主要的服务进行了描述，但是为了聚焦本文主旨，微服务应用架构中常见的配置中心、注册中心等服务以及传统数据库等内容没有描述，不妨碍对本文的理解，但是搭建系统时需要注意。

上图中对大模型架构涉及的主要功能模块进行了统一呈现，对不同的交易链路进行不同方式的组合，便形成了不同的应用架构：

1）交易1+交易2=传统微服务架构

这个很好理解，如果有读者没有微服务架构基础可以查看相关资料，本文不再赘述。

2）交易1+交易3+交易4+交易5=简单的大模型应用架构或RAG

如果数据存储节点（模块③）只是多轮对话的缓存，那么就构成了最简单的大模型应用架构，主要应用在只是使用预训练大模型能力，解答用户问题的简单应用场景。

如果希望使用企业专属领域的资料，借助大模型的能力回答问题，那么就需要使用向量数据库（可参考文章：向量数据库全方位解析与选型指南

）搭建专属领域知识库，这时在数据存储节点就包含了存储在向量数据库的企业专属领域知识库内容，则该架构便成为（Retrieval-Augmented Generation，RAG）的典型架构。

3）交易1+交易3+交易4+交易6+交易7=大模型应用高级架构

随着大模型在企业应用的范围和领域逐步扩大，为了提升垂直领域的模型性能，必然会步入对模型进行微调（fine-tuning）的阶段，进而产生多个领域的专属模型（模块⑤），在线上部署运行时，就需要有负责路由的功能模块（模块④），针对用户问题，有效理解用户用途进而调用相应的大模型。该功能初级阶段由于路由规则相对简单，可以使用程序编码实现，但随着业务越来越复杂，模型数量越来越多，最终会走向使用大模型理解用户意图进行路由的方向。

4）交易1+交易3+交易4+交易6+交易7+交易8+交易9=智能体（Agent）

智能体的能力包括规划（Plan）、存储（Memory）和工具（Tools）。其中，规划就是流程编排能力（模块④），工具是一个特有功能的函数或者服务（模块④和模块⑥），存储包括缓存和长期的存储能力（模块③）。基于大模型能力，通过规划灵活编排工具、存储等动作，就形成了智能体（agent），同时智能体可以嵌套、组合等方式形成能力更强的复合智能体。

特别需要关注的是，传统统计类模型（也可以称为判别式模型）因其更具解释性，可以通过agent方式与生成式大模型结合，形成兼具解释性和灵活性的智能体，这也是将来发展方向。

结语-EPILOGUE

从上面的描述可以看到，通过将不同交易进行组合形成相应的应用系统的能力，成为大家经常听到的RAG和Agent，针对此过程，读者是否有搭积木的感觉？其实应用架构就是这样，充分了解每项产品、组件等相关技术特性，面向业务目标，合理的设计和充分的验证，最终形成一套完整的解决方案，这就是系统架构设计的价值所在。当然，大模型技术处于快速发展阶段，应用架构也会相应地更新迭代，请关注本公众号（ModaTechSub），让我们持续交流，共同进步！