大模型应用开发之业务架构和技术架构(从AI Embedded 到 Copilot,再到Agent)

前言

本文我们重点讲的就是伴随着大模型的广泛应用,这些概念是在什么体系和场景下衍生的;换句话说,基于LLM,目前大家在做的应用,他主流的业务架构和技术架构都是什么样子的,我们在了解之后,可以根据依据我们现实的业务需求,来选择自己的技术路线。

技术往往一半是基础设施,一半是应用设施

就像我们的软件开发,一半是做中间件,框架等基础层的,另一半是在基础层之上,来开发应用的。

大模型目前也是,目前技术分为两个方面:

  1. 建设和训练基础大模型
  2. 建造大模型应用,或者基于基础大模型的应用开发

同时,基础大模型的建设和训练,又需要更为复杂、丰富和专业的知识,这部分长期看来,不会需要太多的人;我们绝大多数人,都会在大模型的应用层这一层,而像我在01篇写到的:

我们在不断被迫接受着过量的信息和超出认知的技术革新,否则就会处于被革新的尴尬境地。

我们大部分人或者所有人都需要接触和掌握的。

典型的业务架构

image.png

目前在实际落地场景中,广泛在用的或者是不断迭代演进的,基本都是围绕这三种类型来的:

AI Embedded模式

这个场景,很好理解,就是在我们的传统应用中,其中某个环节加入了LLM的能力来帮我们提效做一些事情。

AI Copilot模式

这种模式,是在我们的系统应用中,广泛的应用LLM的能力,再通过我们的应用进行串联,这也是目前使用最多的模式。 我们目前能看到各种各样的Copilot,Microsoft Copilot,GitHub Copilot等等。

在这些场景中,大家并不会依赖算法的结果进行最终决策,大都是作为一种信息的收集来源和参考。对比传统的搜索引擎,更多的是效率上的提升,形态其实没有发生本质变化。

AI Agent模式

这个我们可以看到,明显与前两种模式不同,前两种模式的任务主要还是以人来实现为主,LLM作为辅助。

而Agent模式,人只需要提出要求和指令,AI可以自动帮助拆解任务,完成任务的执行。

单Agent和Multi-Agent

我们之前说,在大模型领域,大模型替代了传统agent 中的规则引擎以及知识库,Agent提供了并寻求推理、观察、批评和验证的对话通道。

而Multi-Agent(多智能体系统) 是指由多个自主个体组成的群体系统,其目标是通过个体间的相互信息通信和交互作用。

在基于大模型的应用领域中,当复杂任务被分解成更简单的子任务时,LLM已经被证明了拥有解决复杂任务的能力。Multi-Agent 的通信与协作可以通过“对话”这一直观的方式实现这种子任务的分拆和集成。

为了使基于大模型的Agent适合于Multi-Agent的对话,每个Agent都可以进行对话,它们可以接收、响应和响应消息。当配置正确时 ,Agent可以自动与其他代理进行多次对话,或者在某些对话轮次中请求人工输入,从而通过人工反馈形成RLHF。可对话的Agent设计利用了LLM通过聊天获取反馈并取得进展的强大能力,还允许以模块化的方式组合LLM的功能。

基于大模型的常见单Agent 系统包括:

AutoGPT:AutoGPT是一个AI代理的开源实现,它试图自动实现一个给定的目标。它遵循单Agent范式,使用了许多有用的工具来增强AI模型,并且不支持Multi-Agent协作。

ChatGPT+ (code interpreter or plugin) :ChatGPT是一种会话AI Agent,现在可以与code interpreter或插件一起使用。code interpreter使ChatGPT能够执行代码,而插件通过管理工具增强了ChatGPT。

LangChain Agent:LangChain是开发基于LLM应用的通用框架。LangChain有各种类型的代理,ReAct Agent是其中一个著名的示例。LangChain所有代理都遵循单Agent范式,并不是天生为交流和协作模式而设计的。

Transformers Agent:Transformers Agent 是一个建立在Transformer存储库上的实验性自然语言API。它包括一组经过策划的工具和一个用来解释自然语言和使用这些工具的Agent。与 AutoGPT类似,它遵循单Agent范式,不支持Agent间的协作。

基于大模型的常见Multi-Agent 系统包括:

BabyAGI:BabyAGI 是一个用Python脚本实现的人工智能任务管理系统的示例。在这个已实现的系统中,使用了多个基于LLM的代理。例如,有一个Agent用于基于上一个任务的目标和结果创建新任务,有一个Agent用于确定任务列表的优先级,还有一个用于完成任务/子任务的Agent。BabyAGI作为一个Multi-Agent系统,采用静态Agent对话模式,一个预定义的Agent通信顺序。

CAMEL:CAMEL 是一个agent 通信框架。它演示了如何使用角色扮演来让聊天Agent相互通信以完成任务。它还记录了Agent的对话, 以进行行为分析和能力理解,并采用初始提 示技术来实现代理之间的自主合作。但是,CAMEL本身不支持工具的使用,比如代码执行。虽然它被提议作为多代理会话的基础设施,但它只支持静态会话模式。

Multi-Agent Debate:Multi-Agent Debate试图构建具有多代理对话的LLM应用程序,是鼓励LLM中发散思维的有效方式,并改善了LLM的事实性和推理。在这两种工作中 ,多个LLM推理实例被构建为多个Agent来解决与Agent争论的问题。每个Agent都是一个LLM推理实例,而不涉及任何工具或人员,并且Agent间的对话需要遵循预定义的顺序。

MetaGPT:MetaGPT 是一种基于Multi-Agent对话框架的LLM自动软件开发应用程序。他们为各种gpt分配不同的角色来协作开发软件,针对特定场景制定专门的解决方案。

基于Multi-Agent的LLM 应用开发框架:Autogen

在单Agent和Multi-Agent的应用开发中,大家看到了我们之前提到的,LangChain与Autogen,就是为了Agent开发而出现的应用开发框架。

技术架构

纯prompt

基本的对话式,你问一句,我答一句。。。

image.png

Agent + Function Calling

  • Agent:AI 主动提要求
  • Function Calling:AI 要求执行某个函数
  • 场景举例:你问过年去哪玩,ta 先反问你有多少预算

image.png

RAG(Retrieval-Augmented Generation)

  • Embeddings:把文字转换为更易于相似度计算的编码。这种编码叫向量
  • 向量数据库:把向量存起来,方便查找
  • 向量搜索:根据输入向量,找到最相似的向量
  • 场景举例:考试时,看到一道题,到书上找相关内容,再结合题目组成答案。然后,就都忘了

image.png

Fine-tuning

大模型的微调

image.png

如何选择技术路线

面对一个需求,如何选择技术方案?下面是个不严谨但常用思路。

image.png

题外话:值得尝试 Fine-tuning 的情况

刚接触LLM的小伙伴在听到Fine-tuning的时候都觉得蛮高级的,在我实际工作中应用了一段时间大模型之后,我自己的感受时,在很多基础应用场景中,我们用好提示工程,就足够了。

值得尝试 Fine-tuning 的情况

  1. 提高大模型的稳定性
  2. 用户量大,降低推理成本的意义很大
  3. 提高大模型的生成速度

总结

本文章,我们从大模型目前应用的典型业务架构和技术架构进行分析,让大家初步能够了解我们都是在如何使用LLM的,从而大家在自己的实际落地场景中,也可以对照分析,如何建设自己的业务架构和技术架构,以及选择什么样的技术路线。

如何学习大模型 AI ?

由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。

但是具体到个人,只能说是:

“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

😝有需要的小伙伴,可以点击下方链接免费领取或者V扫描下方二维码免费领取🆓

在这里插入图片描述

在这里插入图片描述

第一阶段(10天):初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么?
  • 大模型是怎样获得「智能」的?
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例:向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范

第二阶段(30天):高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示(Embeddings)
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署

第三阶段(30天):模型训练

恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。

到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2:手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建

第四阶段(20天):商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身:基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例:如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案

学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。

如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

😝有需要的小伙伴,可以Vx扫描下方二维码免费领取==🆓

在这里插入图片描述

  • 8
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: LPC1114是一款由NXP公司提供的ARM Cortex-M0微控制器,而IAR Embedded Workbench是IAR Systems提供的一个常用的集成开发环境。现在要将使用IAR开发的LPC1114工程移植到Keil开发环境中。 首先,打开Keil开发环境,创建一个新的工程。选择适当的器件,确保选择的器件与LPC1114兼容。接下来,将源码文件和头文件添加到Keil工程中。这些文件通常包括main.c(主文件)以及其他的.c和.h文件。 接下来,根据Keil中的需要,对IAR工程中的代码进行一些修改。例如,IAR中的某些特定函数或指令可能需要替换为适合Keil的函数或指令。这可以通过查看相关的文档或用户手册来获得适当的替换方法。 在移植过程中,还需要关注LPC1114的器件配置。在IAR中,在项目选项中有一个设备配置选项,其中可以设置芯片的时钟、外设等参数。同样,Keil也有类似的选项,需要确保将这些配置选项设置为与LPC1114相适应。 移植完成后,通过编译和调试验证移植的工程是否可正常运行。在进行验证时,可能会出现一些问题,例如编译错误、链接错误或功能异常。这些问题一般可以通过检查和调试代码来解决。 总体来说,将LPC1114 IAR Embedded Workbench移植到Keil开发环境中需要进行一些代码修改和器件配置的调整。根据Keil的具体要求进行适当的修改,并通过编译和调试验证移植成功。 ### 回答2: LPC1114是一款基于Cortex-M0内核的单片机,IAR Embedded Workbench和Keil MDK是两种常用的嵌入式开发工具。将LPC1114移植到Keil MDK的过程涉及以下几个步骤: 1. 创建新的Keil项目:在Keil MDK中,创建一个新的项目,选择LPC1114芯片作为目标设备。 2. 复制源代码和配置文件:将IAR Embedded Workbench项目的源代码和相关配置文件复制到新的Keil项目中。确保复制包括了主程序、功能函数、引用的头文件以及外设配置等。 3. 修改编译选项:根据Keil MDK的编译器和链接器要求,修改编译选项。例如,修改编译选项以兼容不同的编译器指令集、优化级别和调试选项。 4. 配置引脚和外设:通过Keil的软件开发包(CMSIS)、启动文件和外设库,对LPC1114的引脚和外设进行配置。根据需要,对时钟配置、中断管理、GPIO、UART、SPI等外设进行初始化和设置。 5. 解决平台相关问题:在移植过程中,可能会遇到一些平台相关的问题。例如,中断向量表的地址、系统时钟的设置、外设寄存器的地址定义等。根据LPC1114和Keil MDK的文档,对这些问题进行适当的调整和修改。 6. 编译、下载和调试:对移植完成的代码进行编译,生成hex或bin文件,然后将它下载到LPC1114的Flash存储器中。通过Keil MDK的调试工具,如Keil ULINK系列调试器,连接目标设备,进行调试和测试。 需要注意的是,IAR Embedded Workbench和Keil MDK是两种不同的开发工具,它们在编译器、链接器和调试器等方面有一些差异。因此,在移植过程中需要仔细查看LPC1114和Keil MDK的文档,了解它们之间的差异和相关配置。同时,也需要适当调整代码,以确保移植后的代码在Keil MDK环境下正常运行。 ### 回答3: lpc1114 iar embedded workbench是一款在IAR Embedded Workbench开发环境下使用的软件开发工具,而keil则是另一款常用的软件开发工具。将lpc1114 iar embedded workbench移植到keil的过程如下: 首先,需要准备好keil软件开发环境,包括安装keil的集成开发环境(IDE)和相应的编译器等必要组件。 接下来,需要将原先在lpc1114 iar embedded workbench下的源代码、工程配置文件等相关文件迁移到keil环境下。可以通过直接复制粘贴文件来实现这一步骤。 然后,需要在keil中新建一个工程,并将移植过来的源代码和配置文件添加到该工程中。确保所有依赖文件都正确地包含在工程中。 接着,根据lpc1114 iar embedded workbench环境中的设置,修改keil的相关配置。这包括正确配置编译选项、链接选项和调试配置等。需要根据项目需求进行适当的修改。 完成以上步骤后,进行编译和构建,以确保移植后的项目能够成功构建。在构建过程中,可能会遇到一些编译错误或者链接错误。需要根据错误提示进行逐个解决并修复。 最后,进行调试和测试。可使用keil提供的调试工具进行硬件调试和代码调试,确保移植后的项目能够正常运行和调试。 总的来说,将lpc1114 iar embedded workbench移植到keil的过程主要是将源代码和配置文件等迁移到keil环境下,并进行相关配置和错误修复。具体的移植过程可能会因项目的复杂程度和个人经验而有所不同。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值