-
_NEWSDATE: 2024-04-04 | News by: 钛媒体APP | 有0人参与评论 | _FONTSIZE: _FONT_SMALL _FONT_MEDIUM _FONT_LARGE
我认为，多模态大模型有三条路。第一条是用多模态数据端到端预训练的模型，Google 的 Gemini 就是这么做出来的，最近 Berkeley 的 LVM 也是端到端多模态的，我认为这是最有前景的一个方向。当然这条路需要非常多的计算资源。
现在还有一种工程化的方案，是用胶水层去粘接已经训练好的模型，比如目前图片理解做得最好的 GPT-4V，还有学术界开源的 MiniGPT-4/v2，LLaVA 等等。胶水层是我的叫法，专业名词叫做 projection layer，比如右上角这个 MiniGPT 架构图中，标着 “” 的 6 个框就是 projection layer。
输入的图片、语音、视频分别通过不同的 encoder 去做编码，编码结果经过 projection layer 映射到 token，输入给 Transformer 大模型。大模型的输出 token 经过 projection layer，分别映射到图片、语音、视频的解码器，这样就可以生成图片、语音、视频了。
在这个胶水层粘接的方案里，可以看到 encoder、decoder 和大模型上面都标着 “?”，那就是冻结权重的意思。使用多模态数据训练的时候，只修改 projection layer 部分的权重，不修改其他部分的权重，这样训练的成本就能大大降低，只要几百美金就能训练出一个多模态大模型。
第三条路是第二条路推向极致的方案，连 projection layer 都不要了，直接用文本去粘接 encoder、decoder 和文本大模型，不需要做任何训练。例如语音部分就是先做语音识别，把语音转换成文字输入给大模型，然后再把大模型的输出送给语音合成模型生成音频。不要小看这种听起来很土的方案，在语音领域，目前这种方案还是最靠谱的，现有的多模态大模型在识别和合成人类说话语音方面都不太行。
Google Gemini 的语音对话响应延迟只有 0.5 秒，这是一个真人都很难达到的延迟，真人的延迟一般在 1 秒左右。我们现有的语音聊天产品，比如 ChatGPT，语音对话延迟高达 5～10 秒。因此大家才会觉得 Google Gemini 的效果非常惊艳。
那么这个效果是不是很难做出来呢？其实我们现在用开源的方案就可以做出来 2 秒以内的语音对话响应延迟，而且还包含实时视频理解。
我们先不考虑视觉部分，先只看语音部分。在一个语音电话里，收到语音后首先做停顿检测，发现用户说话结束了，就把这一段音频送到 Whisper 去做语音识别。停顿检测比如人声结束后等待 0.5 秒，然后 Whisper 语音识别大概需要 0.5 秒。
然后送到文本模型去做生成，用开源模型生成的速度其实非常快，比如最近比较火的 Mixtral 8x7B MoE 模型，输出第一个 token 只需要 0.2 秒，每秒输出 50 个 token 不是问题，那么第一句话假设有 20 个 token，就需要 0.4 秒。第一句话生成完了，就交给语音合成模型去合成语音，VITS 只需要 0.3 秒。
加上 0.1 秒的网络时延，这样端到端算下来只要 1.8 秒的延迟，已经比市面上的大多数实时语音电话产品好很多了。比如 ChatGPT 语音电话的延迟是 5～10 秒。而且我们的方案中，停顿检测和语音识别部分的延迟还有优化空间。
我们再看 Google Gemini 演示的视频理解场景。
因为我们现在的多模态模型输入的基本都是图片，而不是流式视频，所以首先需要把视频变成图片，截取关键帧。比如每 0.5 秒截取一帧，这里面就有平均 0.3 秒的延迟。图片可以直接送进 MiniGPT-v2 或者 Fuyu-8B 这样的开源多模态模型。但是由于这些模型比较小，实际用起来效果并不是很好，跟 GPT-4V 差距比较大。
因此我们可以采取传统 CV 与多模态大模型相结合的方案，用 Dense Captions 这个技术识别出图片中的所有物体及其位置，并且用 OCR 识别图片中的所有文本。再把 OCR 结果，Dense Captions 的物体识别结果作为原始图片的补充文字，都输入到 MiniGPT-v2 或者 Fuyu-8B 这种多模态大模型里面。对于菜单、说明书一类的图片，OCR 的作用是非常大的，因为单靠多模态大模型经常识别不清楚大块文字。- 新闻来源于其它媒体，内容不代表本站立场！
-
原文链接
原文链接:
目前还没有人发表评论, 大家都在期待您的高见