目前，已经有研究提出了多模态 Agent AI（Multimodal Agent AI，MAA）的概念，类似这样的一个 MAA 系统，能够基于对多模态感知输入的理解，在一个给定的环境中生成有效的行为。例如，下面是一个交互增强的 Agent 系统，如图所示： 上面这个多模态的 Agent AI 系统展示了基于 2D/3D 在跨现实（ross-reality）中实现生成，和进行编辑交互。我们对图中上面的会议室场景，说明如下： 首先，在物理世界交互中，通过人类输入的指令，使用 DALLE-2 模型，通过文生图得到一个会议室场景图片。 然后，通过 Knowledge Agent 问答系统，得到一个与会议相关的各种元素，如投影仪、桌子、椅子、白板等等。 接着，通过虚拟现实（Virtual Reality） Agent 能够看到一个虚拟的会议室场景。 最后，通过模拟器或一些 AR/MR 设备实现从物理世界与虚拟世界的交互，可以操作 AR/MR 设备完成特定任务，如远程会议的“现场”开会任务。 另外两个例子（2D 到 3D 的交互；物理世界公交车场景到游戏场景的生成与交互）也是一样的，都实现了从物理世界到虚拟世界的映射与交互。 新的 Agent 范式
按月份浏览文章: 二月 2024
开源 AI Agent：HuggingGPT 基本原理浅析
HuggingGPT 是浙江大学、微软亚洲研究院合作开发的开源项目，以 ChatGPT 和 Hugging Face 为基础构建的一个 AI Agent 框架，融合了 LLM 和 AI 领域模型的能力，用来解决不同领域和不同模态的 AI 任务。 HuggingGPT 是一个以 LLM（比如 ChatGPT）为控制器，以专家模型（HuggingFace）为执行任务的 AI Agent 系统，主要通过连接到各个领域内的专家模型以尝试自动地解决各种复杂的 AI 任务。HuggingGPT 以自然语言为接口，通过 ChatGPT 进行任务规划、模型选择，并通过使用专家模型处理对应领域的问题，生成最终结果，从而能够很好地解决 AI 任务。 HuggingGPT 对应的相关代码和工具，都托管在 Github 上，对应的项目名是 JARVIS：https://github.com/microsoft/JARVIS。 HuggingGPT 设计概览 HuggingGPT 的总体处理流程，如下图所示： 通过上图可以看到，HuggingGPT 的处理过程可以分为如下 4 个阶段： 任务规划（Task Planning） 使用一个 LLM（ChatGPT）分析用户的请求，了解用户的意图。通过用户输入到 LLM（ChatGPT）的 Prompt，根据对话结果将用户任务分解为可
自注意力（Self-Attention）的计算过程
在深度学习中，很多 LLM 的训练都使用 Transformer 架构，而在 Transformer 架构中计算的过程涉及到的最关键的就是注意力，它是整个过程中重要的基础。注意力抽象出了 3 个重要的概念，在计算过程中对应着 3 个矩阵，如下所示： Query：在自主提示下，自主提示的内容，对应着矩阵 Q Keys：在非自主提示下，进入视觉系统的线索，对应着矩阵 K Values：使用 Query 从 Keys 中匹配得到的线索，基于这些线索得到的进入视觉系统中焦点内容，对应着矩阵 V 我们要训练的模型，输入的句子有 n 个 token，而通过选择并使用某个 Embedding 模型获取到每个 token 的 Word Embedding，每个 Word Embedding 是一个 d 维向量。本文我们详细说明自注意力（Self-Attention）的计算过程，在进行解释说明之前，先定义一些标识符号以方便后面阐述使用： X：输入训练数据的 Embedding 是一个 n x d 矩阵 Q：查询矩阵，矩阵形状 n x dq K：键矩阵，矩阵形状 n x dk，其中 dk=dq V：值矩阵，矩阵形状 n x dv 计算自注意力（Self-Attention）的基本流程，如下图所示： 计算过程及其示例
理解注意力机制
在深度学习中，Transformer 架构被广泛使用，而它所基于的注意力机制是最核心的部分，这里通过参考网上各种介绍注意力机制的资料，经过简化并重新组织内容，来说明注意力机制到底是一种什么样的机制。 注意力（Attention）框架 19 世纪 90 年代，美国心理学家威廉·詹姆斯（William James）提出了视觉注意力的工作原理类似于聚光灯，他认为：我们在日常中会聚焦一些事物，在这个焦点上可以清楚地看到一些物体；而在这个焦点周围的区域（称为边缘）仍然可见其他一些物体但不是很清楚。基于这个注意力的原理，后来提出了双组件（two‐component）的框架，其中两个非常重要的概念就是：非自主性提示和自主性提示，通过这两种方式都能够引导我们注意力关注焦点的改变。 非自主性提示 我们在所处环境中，时刻都能不由自主地目及一些事物，还有另外一些事物，这时进入视觉系统的物体如果有特别突出的特征，我们就会将注意力的焦点放在其上面，如下图所示： 上面指定了 5 个物品：一份报纸、一篇论文、一杯咖啡、一个笔记本、一本书，其中装有红色咖啡的杯子的特征最突出
什么是 AI 智能体（AI Agent）
目前 LLM 技术发展非常迅速，虽然 LLM 看似已经具备了丰富的知识与足够的智慧，但是在一些场景下我们可能需要更加精确的答案，而不是得到一些幻觉类答案，或者答案不够实时，或者人类诉求太过复杂以至于 LLM 无法理解，等等，这些问题也是目前阻止很多 AI 应用落地的主要原因。 基于 AI Agent（AI 智能体）自身所具备的能力，同时借助于 LLM 所释放的潜力，或许在不久的将来能够不断优化改进，达到满足人类更方便、更智能地使用 AI 完成各种任务的需求，实现普惠 AI 的目标。 下面，首先了解一下 LLM 和 AI Agent 有什么不同： 人类与 LLM 之间的交互，是基于给定的 Prompt 提示词来实现的，而对于 Prompt 的设计不同 LLM 给出的对话回答质量也是不同的，所以需要人类通过一些特定的方法或经过多次尝试，才有可能逐步提高对话的精确度和满意度。可见，目前基于 LLM 的应用作为工具，能够在一定程度上提高人类日常生活、工作等的效率，同时反过来也对人类使用 LLM 提出了一定的要求，而且这一部分工作更多的是需要人类主动请求，而 LLM 被动执行动作来完成一次一次地
LangChain 框架介绍及入门指南
LangChain 是一个用来开发大型语言模型（LLM）应用的框架，为了简化构建基于 LLM 的应用，它能够为开发 LLM 应用带来如下能力： 根据给定的 Prompt 方便构建上下文，并连接到 LLM， 得到更加符合查询的回答结果 在构建整个基于 LLM 的应用提供各种工具，如各种模块（Modules）、LCEL、LangGraph 等 提供工具支持，使用户自己的 LLM 应用从原型版本到上线到生产环境过程中，一站式的调试、测试、评估等迭代功能 当前，已经发布了最新的 v0.10.0 稳定版本，可以参考这里 LangChain v0.1.0。本文我们通过介绍 LangChain 框架的方方面面（算是对官方文档的一个入门的内容浓缩）使我们对它有一个更全面的认识，以帮助我们使用 LangChain 构建基于 LLM 的应用，具体包括如下几个方面的内容： LangChain 是什么 LangChain Modules 概览 LangChain 模块：Model I/O LangChain 模块：Retrieval LangChain 模块：Agents LangChain 模块：Chains LangChain 模块：Memory LangChain 模块：Callbacks LCEL（LangChain Expression Language） LangServe 介绍 LangSmith 介绍 La
基于 LLM 的应用架构 RAG
RAG（Retrieval Augmented Generation），是指“检索增强生成”，它主要通过检索已有文档（如，企业内部，或者某一领域，或者某个垂直行业等等的内容）的方式，进而将得到的结果作为输入 LLM 的 Prompt 更相关的上下文 Context 来给出更好的回答。 我们都知道，对于一些通用的 LLM，它们所能回答的内容是基于训练该 LLM 时使用的数据集，而且由于模型超大所以使用的训练数据的时效性也是会差一些。而对于某个特定的领域内的内容， LLM 它可能没有或者“知道”得不够精细，甚至对一些最新变化的内容它也不一定包含，所以，需要通过一些方法将 LLM 所不包含的内容“增强”进去，这样就有了类似 RAG 之类的方法，能够解决我们所面临的一些问题。 具体来说，使用 RAG 能够获得的好处，可以概括成如下 4 点（来自 databricks，详见文末参考链接）： Providing up-to-date and accurate responses Reducing inaccurate responses, or hallucinations Providing domain-specific, relevant responses Being efficient and cost-effective 使用 RAG 构建基于 LLM 的应用，
大模型（LLMs）盘点跟踪
发布时间 LLM 模型参数量 组织名称 论文/模型特点 2024-05 Chameleon Meta [论文]混合模态基座模型，只支持图像文本，不支持语音。 2024-05 GPT-4o OpenAI [介绍]OpenAI 的首个整合文本、视觉和音频多模态输入与输出的模型。 2024-04 Arctic 4800亿 Snowflake [介绍]迄今为止最大 MOE 模型，以 128 位专家和 4800亿参数开源，击败 Llama 3、Mixtral。 2024-04 Command R+ 1040亿 Cohere [介绍]首个击败 GPT-4 的开源 LLM。 2024-04 LIama 3 4000亿 Meta [介绍]开源了 3B 和 70B 两款，400B 将会是首个开源的 GPT-4 级别 LLM。 2024-04 GPT-4 Turbo OpenAI [论文]超越 Claude 3 Opus，比 GPT-4 系列性能有所提升。 2024-03 DBRX 1320亿 Databricks [论文]开源，采用细粒度 MOE 架构，推理速度比 LLaMA 2-70B 快两倍，整体性能超越 GPT-3.5。 2024-03 Grok-1 3140亿 xAI [介绍]目前参数量最大的开源模型，基于 MOE 架构。 2024-03 Inflection-2.5 Inflection AI [介绍]性能媲美 GPT-4，仅用四成训练计算量。最大亮点：结合了高 IQ 和高 EQ。
理解 PyTorch 分布式 Autograd 设计
Autograd 是一个反向自动微分系统（或梯度计算引擎），基于记录所有的操作来构建一个有向无环图——Autograd 计算图，其中叶子节点是输入 Tensor，根节点 root 是输出 Tensor，通过跟踪图中从根节点 root 到叶子节点的路径上的操作，能够自动地计算出梯度。 在 PyTorch 中，模型训练的每一轮迭代，都会创建对应的 Autograd 计算图：在前向传播阶段动态地创建 Autograd 计算图，在反向传播阶段根据 Autograd 计算图来进行梯度的计算。 构建分布式 Autograd 计算图 对于分布式模型训练环境下，需要在各个节点（主机）之间进行大量的 RPC 调用，统一协调各个过程来完成模型的训练。PyTorch 实现的分布式 Autograd，在前向传播过程中构建 Autograd 计算图，并且基于 Autograd 计算图在反向传播过程中计算梯度。在前向传播过程中，PyTorch 持续跟踪各个 RPC 调用的情况，必须确保在反向传播过程中计算是正确的，所以 PyTorch 在实现过程中使用了 send、recv 这一对函数来进行跟踪，当执行 RPC 调用时将 send 和 recv 绑定到 Autograd 计算图上。 send 函数被绑定到 RPC
理解 PyTorch DDP 分布式数据并行模式
PyTorch 使用 DDP（Distributed Data Parallel） 实现了真正的分布式数据并行，在下面的两个场景下都可以使用 DDP 实现模型的分布式训练： 单机、多 GPU（单进程多线程的伪分布式） 多机、多 GPU（多机多进程的真正分布式） 上面第一种方式，就是类似使用简单的 DP 数据并行模式，但是 DP 使用的单进程、多线程的范式来实现的；而 DDP 完全使用了多进程的方式，包括单机多进程、多机多进程，如果是多机的情形则对应着物理上的分布式多进程模式。为了获得更好的性能，最好是使用 DDP 模式来训练模型，即使是在单机、多 GPU 的情况下，也建议使用 DDP 模式来实现基于数据并行的模型训练，使用单机 DDP 模式训练模型的性能要比 DP 模式好很多。 DDP 基于集合通信（Collective Communications）来实现分布式训练过程中的梯度同步。在反向传播过程中，DDP 使用 AllReduce 来实现分布式梯度计算和同步。 下面，我们从与 DDP 相关的几个方面来理解 DDP 的设计与实现，包括： 集合通信（Collective Communication） 通信后端（Communication Backend） DDP 内部实现概览
PyTorch 使用 DP 模式实现数据并行
PyTorch 使用 torch.nn.DataParallel 来实现基于数据并行的单机、多 GPU 并行训练。使用 DP 方式在多 GPU 上训练模型，需要保证模型能够在每个 GPU 上放得下，训练过程中会把整个模型都复制到每个 GPU 内，通过数据并行的方式提高训练模型的速度。 虽然 DataParallel 使用起来非常容易，但是通常不能够获得最佳的性能。DataParallel 在每一轮的前向传播过程中，会复制一遍模型，同时这种基于单进程、多线程的并行方式也会存在 GIL（Global Interpreter Lock） 竞争问题。 DP 数据并行训练流程 下面我们分析一下 DP 数据并行模式在多 GPU 的情况下训练模型的基本流程，如下图所示： 基于 DP 模式，模型训练的基本过程分为三个阶段，描述如下： 前向传播计算过程 1.Scatter mini-batch inputs to GPUs 我们通过指定 batch_size 大小，对输入的训练数据集进行了分割，在训练神经网络模型的前向传播过程中，会将每一个小批数据（Mini-Batch）分发到每一个 GPU 上。具体过程是：将 4 个小批数据 i1 ~ i4 复制到 GPU-1 上，再将 4 个小批数据分别发送到 GPU-1 ~ GPU-4
PyTorch 流水线并行模式设计分析
流水线并行（Pipeline Parallelism）最早是 Google 在 Gpipe 论文中提出的，这种并行训练模式能够充分利用多 GPU 的资源高效地训练评估大模型。目前 PyTorch 最新版本是 2.2，流水线并行的功能是基于 torchgpipe 论文中的设计来实现的，该功能当前还处于试验阶段。 问题背景 大模型无法直接放到单个 GPU 中进行训练，通过模型并行（Model Parallelism）的方法可以把模型进行分片，每一个分片放置到一个 GPU 上，这样能够很好实现模型并行且利用多 GPU 的资源。虽然使用这种较为初级的方式能够实现大模型的训练，但在训练的过程中并不能充分利用 GPU 资源，因为对顺序（Sequential）模型来说它每次只能激活一个 GPU 来进行训练，其它的 GPU 此时是闲置的，所以在底层设备上其实仍然是顺序执行。 例如，对一个有 4 层的顺序（Sequential）神经网络模型，经过模型分片后，训练过程中每一层（或 Subnetwork）放在一个 GPU 上，先进行前向传播计算得到 Loss，然后反向传播计算梯度，如下图所示： 使用这种方式利用 GPU 训练，我们可以看到在训练过程中 GPU 完全没有被充