大模型应用技术架构

话不多说,直接上干货,让我们来看看那些隐藏在应用背后,现在大模型都有哪些常用的架构模式,可以为您的企业应用建设提供参考:
V1、直接调用大模型

这种是最简单的方式,通过prompt给到大模型直接拿到结果。如果只有一个大模型并且用的是别人的公有大模型,那基本上就是大家所说的“套壳”。
V2、Function Calling 调用API

无论什么AI大模型,其本身是有局限性的,例如无法获取实时的一些信息(比如实时获取天气状况、股票等信息)。而解决方案一般通过Actions或Function Calling(函数调用,可以理解为接口回调)等方式,让大模型实时调用搜索、甚至企业自己实现的api,获取各种需要的实时信息,减少幻觉,提升确定性。
这里要注意一点,大模型是会对输入的Prompt进行预处理和理解,确定请求的类型和需求,自己判断是直接回答、调用RAG(下面会讲)进行深入检索,还是需要外部API来获取实时或特定数据。
V3、引入RAG

V3版本,我们引入了RAG(检索增强生成),一般用于检索企业私有知识库中的信息,让私有知识库和AI大模型更好地融合。关于RAG,可以参考之前写的文章《一文解读大模型RAG》。
简单说一下调用流程:
1、应用首先调用RAG组件,利用其检索能力在特定的知识库中寻找与用户Prompt相关的信息。
2、RAG组件通过分析Prompt和知识库内容,返回与之最相关的信息或数据。
3、将RAG返回的信息或数据整合进一个新的Prompt中。这个新Prompt包含了原始用户请求的上下文信息,以及通过RAG检索获得的相关知识。然后应用将这个包含了检索信息的新Prompt发送给大模型。
4 & 5、就是上面v2版本的,大模型根据需要自行判断是否调用外部API,返回结果。
6、大模型输出的回答旨在利用调用外部API和结合了RAG检索信息的Prompt来提供一个更为准确、信息丰富的结果。
优势:这种流程特别适合处理那些需要在生成回答之前获得具体信息或数据的场景,如需要引用特定数据、历史事实验证或复杂问题解答等情况。通过这种方式,可以显著提高回答的准确性和相关性,因为生成的过程直接基于检索到的、与用户请求紧密相关的信息。此外,这种方法还有助于大模型更好地理解和处理复杂的查询,尤其是在需要引用广泛或深入信息时。
-----------
V3的RAG版本,其架构方式有很多,下面这种架构模式也应用的很多。

这个RAG的架构与上面解释的那个版本的区别主要在于引入RAG的位置。大模型分析Prompt后,自己判断调用RAG进行深入检索,还是需要外部API来获取实时或特定数据。一旦获取了来自RAG的检索结果和/或外部API的数据,大模型会整合这些信息、概括或进一步的处理,以生成一个连贯、信息丰富的回答。
V4、将RAG训练到大模型中

V4版本与V3版本的区别,主要在于多了一步将RAG的信息,直接训练到大模型本身,这样大模型中就有了RAG的信息。但是大家要知道,要进行一次Fine-tuning是很费时费钱的,所以一般是某个阶段会Fine-tuning一次。如果以后企业有新知识来了,只能暂时先存入到向量数据库中,后续还是通过V3的方式去获取,然后隔了一段时间,再次Fine-tuning一次,大模型中才会有新的知识,此过程如此往复。
-------------
最后做一个总结,现阶段,应用程序背后用的最多的大模型架构主要就是大模型本身+外部API+RAG的组合方式。这里的大模型也好,RAG外挂知识库也好,API就更不用说了,可能有一个,也可能有多个组成。而现在的Copilot、GPTs等都是对此架构的一个封装。
