开源版GPT-4o来了！互腾讯引领风潮，开源VITA多模态大模型，开启自然人机交互新纪元[文末领福利]-CSDN博客

本文链接：https://blog.csdn.net/CDB3399/article/details/142820054

福利领取：包含：Java、云原生、GO语音、嵌入式、Linux、物联网、AI人工智能、python、C/C++/C#、软件测试、网络安全、Web前端、网页、大数据、Android大模型多线程、JVM、Spring、MySQL、Redis、Dubbo、中间件…等最全厂牌最新视频教程+源码+软件包+面试必考题和答案详解。

拉到文末领福利

首个开源支持自然人机交互（非唤醒词交互+可打断交互，类 GPT-4o）的全能（支持视频、图片、文本和语音）多模态大语言模型。

论文链接：

https://arxiv.org/pdf/2408.05211

demo链接：

https://vita-home.github.io/

代码链接：

https://github.com/VITA-MLLM/VITA

总览

▲ 传统的音频交互需要预定义的唤醒词，例如每次提问时都需要说“Hi! Siri∼”，或者需要按下按钮来控制输入的音频问题（限制1）。此外，当模型生成输出时，不能支持新的查询，因为以前的系统只能依次响应输入的查询（限制2）。相比之下，VITA 在多模态交互方面做出了两项重要贡献：1. 非唤醒交互：VITA 能够自动过滤背景噪音，如非查询的人声，因此不再需要唤醒词或按钮来激活模型。2. 音频打断交互：如果用户在生成过程中提出另一个问题，生成过程将被暂停，模型会立即响应最新的查询。与以往的方法不同，VITA 支持音频、文本和视觉模态的端到端处理，不再将这些模态分开处理。

GPT-4o 的卓越多模态能力和用户交互体验在实际应用中非常重要，但没有开源模型在这两个领域同时表现出色。本文介绍了 VITA，这是首个能够同时处理和分析视频、图像、文本和音频模态的开源多模态大语言模型（MLLM），并且具备先进的多模态交互体验。我们在以下三个关键特性，与现有的开源 MLLM 有所区分：

1. 全方位多模态理解能力：VITA 展示了强大的多语言、视觉和音频理解基础能力，并在多种单模态和多模态基准测试中表现优异。

2. 非唤醒交互：VITA 可以在不需要唤醒词或按钮的情况下被激活，并对环境中的用户音频问题做出响应。

3. 音频打断交互：VITA 能够实时跟踪和筛选外部查询，允许用户随时以新问题打断模型的生成，VITA 将根据新的查询做出相应的响应。

VITA 模型的详细介绍

VITA 的整体训练流程如上图所示，由三个阶段组成：LLM 指令微调、多模态对齐和多模态指令微调。

2.1 LLM 指令微调

我们选择 Mixtral 8x7B 作为基础语言模型，它是具有稀疏专家混合（SMoE）架构的代表性 LLM，性能在开源 LLM 中名列前茅，是我们工作的理想起点。然而，我们观察到官方的 Mixtral 模型在理解中文方面表现有限。

为此，我们扩展了基础模型的中文词汇量，将词汇量从 32,000 增加到 51,747。这一扩展不仅增强了双语（中英文）理解能力，还减少了相同文本下的词元数量，从而提高了推理效率。在扩展词汇后，我们使用 500 万条合成的双语语料库进行纯文本指令微调。

2.2 多模态对齐

在这一阶段，我们旨在弥合文本与其他模态之间的表示差距，为多模态理解奠定基础。

2.2.1 视觉模态

视觉编码器：我们使用 InternViT-300M-448px 作为视觉编码器，该编码器接收 448×448 的图像作为输入，通过一个简单的两层 MLP 视觉连接器生成 256 个词元。

对于高分辨率图像输入，我们实现了动态补丁策略来捕捉局部细节。视频被视为图像的特殊情况进行处理。如果视频长度小于 4 秒，我们均匀采样 4 帧；如果视频长度在 4 到 16 秒之间，我们每秒采样一帧；对于超过 16 秒的视频，我们均匀采样 16 帧。为了防止引入过多的视觉词元，我们不对视频的单个帧执行动态补丁。

视觉对齐：在视觉对齐阶段，我们仅训练视觉连接器。表 1 总结了使用的训练数据（不包括纯文本 SFT 部分）。此外，在此阶段我们不使用音频问题。

1. 对于一般图像描述任务，我们引入了来自 ShareGPT4V 的 GPT-4V 生成部分，以确保数据质量。我们还引入了 Allava-Caption 和 ShareGTP4o-Image，并补充了一些由现有 MLLM 生成的中文图像描述。

2. 对于一般图像问答（QA）任务，我们初步收集了三个数据集：LLaVA-Mixture-sample、Lvis-Instruct 和 ScienceQA。我们使用现有的 MLLM 生成了额外的 21.8K 中文 QA 数据。此外，我们从 LLaVA-150K 数据集中移除了标题子集，并将其余部分翻译为中文。

3. 对于 OCR 和图表任务，我们引入了 Anyword-3M、ICDAR2019-LSVT、ICDAR2017-RCTW、Open-Chart（包括 ChartQA、DVQA、InfoVQA、Pew 和 OpenCQA），以及一些由现有 MLLM 从其他开源数据中生成的合成数据。

4. 对于一般视频描述任务，我们使用 ShareGemini 数据集。

5. 对于一般视频 QA 任务，我们使用现有的 MLLM 重新标注了 Video-ChatGPT 和 VideoChat2 的开源数据。

▲ 不同的文本数据直接拼接到 6K 词元。图像首先被划分为局部补丁，然后将不同的图像-文本对进行拼接。视频数据则直接逐帧采样作为输入，无需进行拼接。通过这种方式，我们能够统一不同训练批次中的数据长度，从而提高训练效率。

数据拼接：对于纯文本数据和图像数据，我们的目标是将上下文长度拼接到 6K 词元，如上图所示。视频数据则不进行拼接。拼接不同的数据带来了两个好处：

一是支持更长的上下文长度，使得从单一到多图像-问题交互成为可能，从而实现更灵活的输入形式和延长的上下文；

二是提高了计算效率，因为视频帧通常包含大量视觉词元。通过拼接图像-问题对，我们在训练批次中保持了词元数量的平衡，从而提高了计算效率。此外，我们发现使用拼接数据训练的模型在性能上与未拼接数据的模型表现相当。

2.3 音频模态

音频编码器：输入音频首先通过 Mel 频率滤波器块处理，该块将音频信号分解为 Mel 频率尺度上的各个频带，模拟人类对声音的非线性感知。

随后，我们使用 4 层 CNN 下采样层和 24 层的变换器，共计 341M 参数，处理输入特征。我们采用简单的两层 MLP 作为音频-文本模态连接器。最终，每 2 秒的音频输入被编码为 25 个词元。

音频对齐：在对齐任务中，我们选择了自动语音识别（ASR）。我们的数据集包括 Wenetspeech，该数据集涵盖了超过 10,000 小时的多领域语音识别数据，主要集中在中文任务上。同样，Gigaspeech 也包含 10,000 小时的高质量音频数据，大部分数据用于英语语音识别任务。

另一个任务是音频字幕生成，依赖于 Wavcaps 的 AudioSet SL 子集，该数据集包含 400K 个音频片段及其对应的音频字幕。在对齐过程中，音频编码器和连接器都进行了训练。

多模态指令微调

在这一阶段，我们对模型进行指令微调，以增强其遵循指令的能力（文本 & 音频指令）。

3.1 训练数据

数据构建：指令微调阶段的数据来源与对齐阶段相同（见表 1），并进行了如下改进：

1. 音频问题替换：我们使用 TTS 技术（如 GPT-SoVITS6）将大约一半的问题随机替换为其音频版本，以提升模型对音频查询的理解能力和指令跟随能力。音频问题和文本问题的数量见表 1。

2. 系统提示设置：设置不同的系统提示，以避免不同类型数据之间的冲突（见下表）。例如，有些问题可以基于视觉信息或模型自身知识进行回答，这可能会导致冲突。此外，由于图像数据的补丁类似于视频数据的多个帧，可能会使模型感到困惑。系统提示明确区分不同的数据类型，使其更易于理解。

噪声音频构建：在人机交互过程中，并非所有的音频输入都需要响应，这些被称为噪声音频。一个具有良好交互能力的系统应能主动识别音频类型，并有选择性地执行后续输出。为此，我们需要构建各种噪声音频样本以供模型识别。

具体而言，我们从现有的多模态和单模态 QA 数据中随机抽取 474K 个句子。这些负样本文本集中在不需要用户响应的非查询相关内容上，其长度分布与正向问题的长度分布一致。

然后，我们使用 TTS 工具将这些句子转换为音频。噪声音频样本的构建使模型能够识别不需要响应的音频输入，这有助于实现非唤醒交互。具体的训练策略将在以下部分详细说明。

3.1.1 训练过程

根据上述构建的 QA 对，模型需要区分三种类型的查询：

查询音频：问题由音频发起。
噪声音频：输入为音频，但不包含问题。
查询文本：问题由文本发起。

基于这些查询类型，我们设计了三种状态标记 <1>、<2> 和 <3>。在训练阶段，我们在答案的开头插入对应的状态标记，使模型能够灵活处理不同的交互行为。具体如下：

状态标记 <1> 表示问题输入为查询音频。在这种情况下，模型的输出需要以文本或通过 TTS 工具转换的语音形式呈现给用户。
状态标记 <2> 表示问题输入为噪声音频。模型应输出 EOS 标记作为终止符。然而，我们发现训练过程中突然终止输出可能会显著降低性能。因此，我们将噪声音频对应的文本发送给 LLM，并使用其输出文本作为训练目标。在推理过程中，<2> 作为另一种特殊的 EOS 标记。
状态标记 <3> 表示问题为纯文本，用于区分训练集中的前两种查询。

在训练过程中，视觉和音频编码器保持冻结状态，而连接器与 Mixtral 8×7B 一起进行训练。

模型部署：双工策略

在这一部分，我们主要讨论如何实现两种交互功能：非唤醒交互和音频中断交互。

4.1 非唤醒交互

非唤醒交互意味着模型可以在不需要唤醒词或按钮的情况下被激活，并对环境中的用户音频问题做出回应。部署过程必须满足以下要求：

实时跟踪环境声音：这涉及确定音频内容是否属于人类语言。
过滤噪声音频：模型应仅对有效的用户查询音频作出响应。

对于第一个要求，现有的语音活动检测（VAD）可以提供帮助。VITA 使用 SileroVAD [45]，该系统经过大规模语料库训练，涵盖超过 6,000 种语言，并且能够在各种背景噪声下表现良好。

对于第二个要求，我们利用第 3.3.2 节中描述的状态标记 <2>。这使模型能够自动区分输入音频是否为有效查询。如果输入为非查询类型，模型将直接终止推理，从而仅对查询类型的输入作出响应。

4.2 音频中断交互

音频中断交互允许用户随时用新问题打断模型的生成过程。为实现这一点，部署环境必须满足以下要求：

实时跟踪和过滤外部查询：在生成响应的同时，系统必须实时跟踪和过滤外部查询。
回答新问题：当出现新问题时，系统必须停止当前生成，整合历史上下文，并对当前查询作出回应。

为实现这一目标，我们提出了双工部署框架。如上图所示，两个 VITA 模型同时部署。在典型条件下，生成模型负责回答用户查询。同时，监控模型在生成过程中检测环境声音。它忽略非查询用户声音（即噪声音频），但在检测到查询音频时会停止生成模型的进度。监控模型随后整合历史上下文，并对最新的用户查询做出回应。这时，生成模型和监控模型的身份会发生转变。

评估

5.1 语言表现

为了验证我们训练过程对语言模型的有效性，我们将训练后的模型 “Mixtral 8x7B Ours” 与官方版本 “Mixtral 8x7B Instruct” 进行对比，评估使用了四个数据集：C-EVAL、AGIEVAL、MMLU 和 GSM8K。这些数据集涵盖了包括普通多项选择题、多学科问答，以及数学和逻辑推理任务的各种场景，涉及中文和英文上下文。

结果如上表所示，我们的训练显著提升了模型在中文评估集（C-EVAL 和 AGIEVAL）上的能力，同时保持了在英文相关基准（MMLU）上的原有性能，并在数学推理任务（GSM8K）中显示出显著的改进。

5.2 音频表现

为了验证我们模型所学的语音表示的鲁棒性，我们在 Wenetspeech 和 Librispeech 数据集上进行了测试。Wenetspeech 具有两个评估拆分：test_net 和 test_meeting。前者的数据源与训练数据更为接近，较容易；后者则具有更大的挑战性。

作为我们模型的留出数据集，Librispeech 评估了模型在未见数据集上的泛化能力。它有四个评估拆分：“dev” 开头的是验证集，“test” 开头的是测试集。“Clean” 指较不具挑战性的集合，而 “other” 指较具挑战性的集合。我们可以看到，VITA 在 ASR 基准上取得了可观的结果。

5.3 多模态表现

为了评估 VITA 的多模态能力，我们在四个代表性基准上进行评估，包括 MME、OCRBench、HallusionBench 和 Video-MME。

如上图所示，在图像理解方面，VITA 超越了图像专用的开源模型 LLaVA-Next，接近于闭源模型 Gemini 1.5 Pro。在视频理解方面，VITA 超过了视频专用的开源模型 Video-CCAM。

尽管 VITA 与视频专用的 LLaVA-Next-Video 之间存在差距，但鉴于 VITA 支持更广泛的模态并优先考虑交互，这种差距是可以接受的。然而，值得注意的是，当前开源模型与专有模型在视频理解能力方面仍存在较大差距。

结论与未来工作

在本文中，我们介绍了 VITA，一个强大的开源多模态大语言模型，它将视频、图像、文本和音频理解整合到一个统一的框架中，并提供了先进的交互体验。除了强大的多模态基础能力，VITA 还在开源社区中开创了新的多模态交互方式，包括非唤醒交互和音频中断交互。然而，当前版本仍面临以下限制：

基础能力的提升：虽然 VITA 在单模态和多模态任务中相较于领先的开源模型表现出色，但与专有模型相比仍存在显著差距。
噪声音频构建的优化：使用现有数据的非查询响应作为噪声音频样本是一种简单而有效的方法。然而，VITA 有时会将噪声音频误分类为查询音频，这突显了需要更细致的构建方法。
与 LLM 联合构建端到端 TTS：我们目前使用额外的 TTS 工具将 LLM 生成的文本转换为语音，这一过程比较耗时。如果能够将 TTS 与 LLM 结合，实现端到端的语音输出，可能会大大提升实时交互性能。

未来的工作将集中在解决这些限制，并探索以下方向：