多模态大模型全解析：模态类型、编码方式与融合方案实战

先别急着打开搜索引擎去查“多模态大模型有哪些模态”，因为这个问题真正的价值，不在于背出一张“文本、图像、音频、视频”的清单，而在于理解每种模态背后那一整套数据表示、编码方式、对齐逻辑和落地成本。搞清楚这一点，你才有可能在自己的项目里做出靠谱的多模态应用，而不是被各种Demo带偏方向。

这篇文章适合三类人看：一是正在做AI应用开发、想往多模态方向转的工程师，二是做数据治理和算法选型的产品经理，三是刚入门、想系统建立“多模态认知地图”的研究者。我会从模态的定义开始，逐个拆解主流模态的技术细节，然后讲清楚模型的编码入口、融合方案、训练调优和部署排查，全程按照我在实际项目里踩坑总结的“从业者视角”来写，尽量不说废话。

1. 先从“模态”这个概念说起

很多人把“模态”等同于“文件格式”，比如认为传个.png就是图像模态，传个.wav就是音频模态。这个理解在业务层面可以接受，但从技术视角看太粗糙了。模态的本质是“信息被感知和表达的方式”，它决定了数据在时间上是否连续、在空间上是否有几何结构、在语义上是离散符号还是连续信号。理解这一点，你才能解释为什么有的任务适合用图像模型处理，有的任务必须上视频模型，而不是简单堆数据。

1.1 为什么定义模态比想象中重要

不同模态的信息密度和表达方式差异巨大。文本是离散符号序列，语义高度浓缩，一个词可能承载上百个字节的信息；图像是二维像素矩阵，空间关系直接可见，但同样的内容换一个角度拍出来，语义可能完全不同；音频是随时间连续变化的一维信号，既有语言内容，又有说话人的情绪、节奏和环境噪声；视频则是图像加时间的组合，既要处理空间细节，又要建模运动趋势。

这种差异带来两个直接后果。第一个后果是编码方式不通用，文本用Tokenization，图像用Patch Embedding，音频用梅尔谱特征，你不能把一套编码器塞给所有模态。第二个后果是对齐成本不同，文本和图像对齐相对容易，因为大规模图文数据好找；视频和文本对齐就难很多，因为需要时间维度的标注；3D点云和文本对齐更难，因为数据结构稀疏，标注样本极少。理解了这些，你再看“有哪些模态”这个问题，就会变成“我需要为哪些信息通道分别搭建编码和融合管线”。

1.2 当前主流模型覆盖的模态清单

目前业界讨论的多模态大模型，覆盖范围大致包括以下七类，我用一张表做个总览，方便你建立全局认知。

这七类并不需要你在一个模型里全部支持，实际项目里通常只需要两到三类。但无论选哪几类，你都得先回答三个问题：这个模态的数据长什么样，怎么编码成大模型能处理的序列，以及它和目标模态之间的对应关系是什么。下面我把几个最常见的模态逐个拆开讲，重点放在那些容易被忽略的细节上。

2. 逐个拆解常见模态：从文本到视频

讲模态不能停留在概念层，必须落到数据和算法层面。这一节我会对每个主流模态做一次完整的技术拆解，包括数据形态、编码思路、典型落地点和最常见的坑。

2.1 文本模态：一切大模型的地基

文本是当前大模型最成熟的模态，也是大多数多模态系统的“中枢语言”。原因是文本具备天然的离散性，词与词之间有明确的边界，语义可以通过Tokenization转换成固定词表上的索引序列，非常适合自回归式训练。你可能听过BPE这类子词切分算法，它的思路很直观：先把常用词保留为完整Token，把生僻词拆成更小的子词片段，这样既能控制词表大小，又能覆盖未登录词。

为什么文本能成为多模态的“语言中枢”？因为几乎所有其他模态，最终都可以转成文字描述来和用户交互。图像可以被描述成“一只坐在草地上的黄色小猫”，音频可以被转写成“用户说麻袋里有东西”，视频可以被概括成“一个人从左向右跑过马路”。所以，很多多模态模型的做法是：用其他模态的编码器把非文本信号变成特征向量，再通过一个映射层接入文本模型的Token序列，让文本模型负责推理和生成。这时候，文本不仅是输入，更是一个“交互接口”和“推理引擎”。

做文本模态时要注意一个细节：Token数量直接决定算力成本。一个中文汉字通常对应一个或半个Token，一段500字的描述大概会消耗700个Token，而一张图像经过Patch划分后可能产生196个或更多Token。如果做图文混合输入，文本部分被图像Token“淹没”是常见现象，后面我会在融合部分展开讲。

2.2 图像模态：从“看懂”到“生成”

图像模态的核心难点，是把二维像素矩阵变成一维序列，同时保留空间结构信息。目前主流的做法是用视觉编码器，比如把一张224×224的图像切分成16×16大小的Patch，那么图像会被分成(224/16)^2 = 196个Patch，每个Patch展开成向量后，再加上位置编码和CLS Token，就形成了大约197个Token的序列。这个序列可以像文本Token一样输入Transformer层，让模型学习Patch与Patch之间的依赖关系。

到这里，你可能会问：为什么不直接卷积？卷积确实擅长提取局部特征，感受野逐层扩大，但它在建模全局关系时不如注意力机制灵活。视觉Transformer用自注意力直接建模任意两个Patch之间的关系，理论上不需要堆叠很多层就能看到全局。当然，它的代价是计算量与Patch数量的平方成正比，输入图像越大，算力增长越明显。

图像模态的典型落地场景包括：图文检索、图像描述、视觉问答、文生图。实际操作中，我推荐优先关注“图像输入质量”和“图文对齐质量”，前者决定模型能不能看到细节，后者决定模型能不能听指挥。很多看起来模型“笨”的案例，排查下来其实是图像被缩放得面目全非，或者图像Token被截断，导致模型根本没看见关键区域。

2.3 音频模态：不止是语音，还有音乐和环境音

音频模态经常被误以为只包含“语音识别”，实际上它的范围广得多，包括人声的语义内容、说话人的音色、语气情绪、环境声音、音乐旋律和节奏。这些信息高度耦合在一根时间轴上，区分起来并不容易。

在编码层面，常见做法是把原始波形先分帧加窗，然后计算梅尔频谱。一个典型的参数组合是采样率16kHz、帧长25毫秒、帧移10毫秒，那么每秒音频会得到约100帧，每帧提取80维梅尔特征。这个特征图可以看成“以时间为横轴、频率为纵轴的二维图像”，因此可以复用图像编码器的思路，用二维卷积或Transformer来处理。不同之处在于，音频特征的长度会远大于同尺寸的图像，一分钟音频就有6000帧，直接全部输入Transformer会非常昂贵。

音频模态的另一个难点是“内容-音色分离”。同一句话，不同人说出来的含义相同，但音色特征完全不同。如果模型把音色也当成语义的一部分，就容易在转写或问答时产生偏差。实践中，很多系统会先做ASR得到文本，再把文本作为主输入，音频特征作为辅助输入，这样既利用了声学信息，又不会让音色干扰语义判断。对于音乐生成这类场景，则需要额外的时序生成模型，单纯靠文本对齐不够。

2.4 视频模态：时间维度的挑战

视频可以理解为“图像序列加音频轨道的组合”，但它不是简单地把若干帧图像塞进模型就行。时间维度的引入让问题复杂了至少一个量级，一方面模型需要建模帧与帧之间的运动变化，比如判断“人是在跑步还是走路”，只看单帧容易误判，联系前后帧才能确定；另一方面视频数据量巨大，一分钟视频按1帧每秒采样也有60张图像，信息冗余非常高，直接全量计算成本不可控。

所以，当前视频模态的编码普遍采用“稀疏采样”策略，比如从一段视频中均匀抽取4秒、8秒或16帧，每帧用图像编码器提取视觉特征，再引入时间位置编码，让模型知道这些帧的先后关系。有些方案还会额外叠加光流特征或音频特征，帮助模型更好地建模动态信息。这种方法的核心思想是：牺牲一些细粒度的时间连续性，换取可承受的计算开销。做视频理解项目时，采样间隔的选择非常关键，间隔太密会导致算力浪费，间隔太稀又会漏掉关键动作，需要根据场景反复调优。

视频模态的落地场景包括视频摘要、事件定位、视频问答、内容审核、自动驾驶决策等。我自己的经验是，视频项目最大的坑不是模型结构，而是数据整理。你需要对帧时间戳、镜头切换点、OCR字幕、音轨对齐做统一管理，缺任何一块，训练或评测时都会出现莫名其妙的偏差。

2.5 3D、传感器与结构化数据：被低估的模态

文本、图像、音频、视频是“大众模态”，但实际工业场景里还有三类模态经常出现，却常常被低估。

第一类是3D数据，最典型的是点云。点云是空间中离散的三维坐标点集合，可以附带颜色、强度等信息。它的特点是稀疏且无规则，不存在“相邻像素”的概念，因此不能直接用图像卷积。常见做法是体素化后当作三维网格，或者用PointNet一类的结构直接聚合点特征。落地方向包括自动驾驶障碍物检测、三维室内重建、AR交互等。

第二类是传感器数据，比如IMU、温度、湿度、振动频率、激光雷达距离读数。这类数据是一维或多维时间序列，噪声大、采样率不一致，最麻烦的是不同传感器的时钟可能偏移。做具身智能或多模态IoT项目时，我通常先把各传感器的数据按时间戳插值对齐，再转成固定长度的滑动窗口特征，喂给回归或预测头使用。

第三类是结构化表格数据，常见于数据库问答和商业智能场景。表格中有数值、类别、缺失值，行和列天然形成二维结构。大模型处理表格时，可以把它线性化为“列名：行值”的文本序列，也可以为每个单元格生成嵌入后再聚合。前者简单，但会丢失行列间的局部关系；后者效果好，但实现复杂度高。对大多数业务场景，我建议先线性化文本，效果不够再上结构化编码。

3. 模态的“入口”：每种模态如何被大模型读取和编码

了解了模态是什么之后，你需要掌握一个更关键的问题：这些五花八门的数据，是怎么变成大模型能够“理解”的Token序列的？这一节我从工程实现角度拆解编码链路，并给出常见参数的计算过程，让你能自己估算显存和训练成本。

3.1 不同模态如何变成同一套“语言”

Transformer本身只认识向量序列，不关心你输入的是单词还是像素。因此，每种模态都需要一个“翻译器”，把自己的原始数据翻译成向量序列。这个翻译器就是各种编码器。

文本走的是Tokenizer加Embedding。Token先把字符串切成整数索引，Embedding层把索引映射为向量。以中文为例，一个包含2000个汉字的段落大概产生1500到2500个Token，每个Token的向量维度通常是4096或5120，那么这批文本的数据量就是Token数乘以向量维度再乘以字节数。假如你用的是FP16精度，每个参数占2字节，2000个Token在5120维下会占用约20MB内存，这是非常粗粒度的估算，但足以让你感受到量级。

图像走的是Patch Embedding。一张224×224的RGB图像，切分成16×16的Patch，会变成196个Patch。每个Patch展平后长度为16×16×3 = 768，再通过一个线性映射压到隐藏维度，比如1024。加上CLS Token和位置编码，输入序列长度就是197。如果你输入的是336×336的图像，Patch数量会变成(336/16)^2 = 441，再加上分类Token就是442个Token。直观感受一下：一张中等尺寸图像的Token消耗量，相当于一段几百字的中文文本，而且图像Token的“信息密度”远低于文本Token，这会导致模型天然更关注文本部分，所以很多多模态模型会为图像特征增加额外权重或指令前缀。

音频走的是频谱特征。16kHz采样、25毫秒窗长、10毫秒帧移的音频，每秒产生约100帧，每帧提取80维梅尔特征。这些特征形成形状为100×80的二维矩阵，可以按图像方式切Patch，也可以直接线性化成一维序列。一分钟音频会产生6000帧特征，是图像的几十倍，因此音频输入通常采用时间下采样或截断策略，否则模型根本装不下。

视频走的是“帧采样加图像编码”。如果每秒采样1帧，一段10秒的视频会产生10帧，每帧224×224的图像编码为196个Patch Token，加上文本和音频特征，总Token数可能达到3000以上，这已经是一段长文本的规模。所以视频模型的输入长度和显存压力，永远是工程上的头号问题。

3.2 冻结编码器与端到端训练的选择

在训练多模态大模型时，你经常会听到两个词：“冻结编码器”和“端到端微调”。这指的是其他模态的编码器是否参与梯度更新。

冻结编码器的做法，是使用一个预训练好的图像编码器或音频编码器，把输入转换为固定特征，然后只训练映射层和语言模型。这样做的好处是训练稳定、算力要求低，坏处是编码器本身不一定适配目标任务。例如，通用的图像编码器没有专门训练过“看清小字”，如果你要做文档图片理解，冻结编码器可能根本提取不回完整文字信息，效果自然上不去。

端到端微调则允许反向传播进入编码器，让编码器参数不断适应任务需求。这样做的上限更高，但显存占用巨大，而且容易过拟合。我的建议是分阶段执行：先冻结其他模态编码器，只训练投影层和语言模型，等损失收敛到平台期后，再解冻一部分编码器做全量微调。这段时间我在多个实验里都发现，分阶段训练比一上来就端到端的效果好，而且好调得多。

3.3 对齐策略：对比学习、回归损失、指令微调

多模态模型的核心在于“对齐”，就是让模型明白什么样的图像特征和什么样的文本特征是同一回事。目前有三种主流对齐策略，各有各的适用场景。

对比学习的思路是把成对的图像和文本拿来做匹配。同一个batch里，一张图和对应的描述是正样本，其他描述是负样本，训练目标是让正样本的相似度高于负样本，常用InfoNCE一类损失。这种方式适合做图文检索和零样本分类，但有一个缺点：它只解决“匹配不匹配”的问题，不太擅长生成细腻的描述，因为对比学习并不强迫模型把图像细节完整复述出来。

回归损失更直白：把图像特征和文本特征拿去做L2距离约束，让配对样本的向量距离不断缩小。这种方式适合做特征空间统一的场景，比如让图像和文本映射到同一个向量空间，方便做近邻检索。但它对特征维度和数值范围敏感，容易出现训练不稳定的情况。

指令微调是目前最实用的一种对齐方式。你直接构造“对话指令”，比如给模型看图后问“这张图里发生了什么”，让模型生成自然语言答案。通过大量这样的指令数据，模型不仅学会“看图说话”，还学会了遵循用户的表达方式。我更推荐业务项目优先做指令微调，因为它的效果能直接被产品体验验证，也方便收集真实用户反馈进行迭代。

4. 多模态融合的几种主流玩法

模态编码完成之后，接下来的问题是怎么把不同模态的信息组合起来。融合方式决定了模型在什么层次共享信息、能不能处理模态缺失的场景，也决定了训练难度。我把目前主流的玩法梳理成三条路线。

4.1 拼接式输入：直接但有代价

最简单的融合方式，就是把不同模态的Token序列直接拼接在一起，比如“一段文本Token + 一堆图像Token + 一段音频Token”，然后一起交给Transformer处理。这种方式实现成本低，改动小，很多开源插件都支持。

但它的缺点很明显：不同模态的特征空间天然不对齐。文本Token来自离散的Embedding空间，图像Token来自视觉编码器的输出，两者直接拼接后，模型需要在自注意力中学习它们之间的复杂关系，需要一个很长的训练过程才能让语义对齐。而且由于拼接后序列长度骤增，计算开销成倍上升。在预处理阶段，你通常还需要给每种模态加入类型区分标记，让模型知道哪些Token属于图像，哪些属于文本，否则很容易混淆。

4.2 跨模态注意力桥接：像专业同传一样传话

一种更聪明的做法，是设置一组“查询Token”，让它们通过交叉注意力机制去查询图像特征或音频特征，再把查询结果送入语言模型。这组Token就像一个“同传翻译官”，把视觉特征转换成文本模型能够消化的嵌入表示。

典型的结构是：语言模型生成每一个新Token时，都会通过交叉注意力层“读取”图像或音频特征中与当前文本最相关的部分。这样，语言模型不需要把整张图的所有Token都塞进上下文，只需要读取相关片段，序列效率和参数效率都会提高，不同模态之间的语义鸿沟也有了一个专门的“翻译层”来弥合。

实际项目中，如果条件允许，我会优先考虑这类方案。它在视觉问答、图文对话等场景的表现明显优于简单拼接，而且对输入尺度的容忍度更高。缺点是结构更复杂，引入的“查询Token”数量需要调参，数量太大浪费算力，太小又看不全图像。

4.3 以语言模型为中枢：让所有模态都学会说“人话”

第三种思路在近两年非常流行：把所有非文本模态都“翻译”成语言模型能理解的离散Token或连续向量，然后完全交给一个语言模型做推理和生成。图像不再是“图像”，而是被映射成一组“图像Token”；音频也不再是“音频”，而是被映射成“语音Token”。语言模型变成所有模态共用的“大脑”，其他模态只是不同形式的输入输出接口。

这种方案的优点是统一性极强，你只需要维护一个强大的语言模型，各种模态的接入都可以复用同一套训练和推理框架。缺点是映射不可避免会丢失一些底层细节，尤其是空间几何信息、时间精确性等；同时，把高帧率视频或长音频映射成有限Token，需要非常强的压缩能力。

我做过多模态助手项目后深刻的体会是：不要把某一个融合方案当成银弹。选择拼接式还是注意力桥接，取决于你的数据量、算力资源和业务目标。如果只是想快速验证图文问答效果，拼接式能让你跑通流程；如果是面向严肃业务场景，为了控制幻觉和错误召回，注意力桥接更值得投入。

4.4 从实际项目出发，如何选择融合方案

我把自己做选择时的决策标准分享出来，供你参考。

第一个标准是模态数量。如果你只需要处理“文本+图像”，拼接式足以应付，配合指令微调就能达到不错的效果。如果涉及“文本+图像+音频”或“文本+视频”，建议引入查询Token桥接结构，减少序列长度压力，否则显存会非常吃紧。

第二个标准是数据规模。如果你能拿到的多模态数据只有几千对，不要做强融合模型，老老实实冻结编码器、只训练一个投影层，效果反而更稳定。数据量过万之后，再放开一部分参数端到端微调，收益才大于风险。

第三个标准是业务准确率要求。像“给用户写商品文案”这类容错度较高的任务，拼接式足够；像“医疗影像辅助诊断”“自动检测视频安全隐患”这类错误代价高的任务，必须做更强的对齐和更充分的评估，不能只凭几个Demo就上线。

5. 实操中的关键细节与避坑经验

前面讲的是结构和算法，这一节我专门说数据、训练、评估和部署这些工程环节里真正容易被坑的地方。这些经验大多来自我自己在模拟项目X中的实践，走了不少弯路，希望你能少踩一次。

5.1 训练数据配比：模态失衡会让收敛变慢

多模态训练的一个经典陷阱，是训练数据中各个模态数量严重不均衡。比如你有100万对图文数据，但音频对只有1万对，模型大概率会优先学会图文对齐，音频任务学不好。原因很简单，梯度更新被大头数据主导，小模态的损失贡献被淹没。

我的建议是，在每次训练前先统计各模态的数据量，按比例设置采样器，确保每个batch里各模态出现次数相对均衡。一个我常用的估算方式：假设文本问答数据、图片描述数据、音视频对话数据的比例是3:2:1，那么采样器权重就按倒数的比例调整。这样做的效果非常直观，小模态的损失下降速度会有明显改善，整体收敛时间也更可控。

另一个容易被忽视的问题是数据质量。文本标注错误、图像截断、音频有噪音、视频时间戳偏移，任何一项都可能让模型学到错误映射。我坚持“先清洗再训练”，每次拿到新数据都会做一次抽样人工审查，至少覆盖5%的样本量。听起来费时，但它能避免训练了一周之后才发现数据有系统性问题的惨剧。

5.2 缺模态和噪声数据的处理

实际业务里，用户上传的数据经常缺失一部分模态。比如用户提交了一张图片但没写描述，或者上传了一段视频但没有声音。如果你只在完整数据上训练，模型遇到这些情况会崩溃。

解决办法是训练时主动做“随机模态遮蔽”：随机关闭某一个模态的输入，让模型学会在缺模态时仍然输出合理结果。比如把图像Token全部置零或去掉，此时模型只能依靠文本来回答；把音频Token去掉，模型只能依靠视觉信息来回答。这样既增加了模型的鲁棒性，也模拟了真实世界的噪声环境。

实际操作中，遮蔽比例我一般控制在15%到30%。比例太低，模型学不会“抗缺失”；比例太高，会拖慢对齐训练的节奏，导致模型过度依赖单一模态。此外，我还会在数据里加入轻微噪声，比如图像模糊、音频混入白噪声、文本出现少量错别字，帮助模型降低对数据完美度的依赖。

5.3 评估：不能只看Metrics合并结果

多模态模型的评估比单模态复杂得多，因为不同任务的错误类型完全不一样。图文问答的错误可能是“看错了物体”，也可能是“语言表达不通顺”；视频理解的错误可能是“时间顺序搞反了”，也可能是“识别错了动作”。

如果只看一个合并的准确率，你根本不知道模型弱在哪里。我的习惯是分模态、分任务类型拆分评估指标。比如图文问答，分别统计“物体识别准确率”“颜色属性准确率”“计数准确率”；视频理解，分别统计“事件时间顺序准确性”“主体动作准确性”。只有拆开看，才能发现模型在哪些维度拖了后腿，再针对性地补充训练数据。

另外一个容易漏掉的评估维度是“模型是否过度依赖某种模态捷径”。比如训练数据里几乎所有关于“沙滩”的图片都带有“蓝天”，模型可能学会了看到蓝天就回答沙滩，而没有真正理解沙滩特征。做测评时，要专门构造一些反例，比如乌云密布的沙滩图片，看模型是否还是能正确答出“沙滩”。这种对抗性评估，才是检验模型真实理解能力的关键。

5.4 推理部署：模态越多，显存和延迟压力越大

多模态模型的部署，首先面临的是显存问题。序列长度直接决定自注意力的显存占用，而这个占用随序列长度平方增长。我给你做一个粗略估算：假设一张图像切成196个Patch，加上32个查询Token，再配合512个文本Token，总序列长度约为740。自注意力层中QK矩阵的中间激活大小大约是长度乘以长度，740×740约55万量级，乘以层数和隐藏维度，再乘以FP16的2字节，单条样本的注意力图就已经相当可观。如果你同时输入10张图像，序列长度会飙升到数千，显存压力会急剧增大。

所以，工程上必须做Token裁剪和KV Cache管理。我常用的策略是：在进入语言模型之前，对非文本模态的Token做池化或筛选，比如把196个图像Token压缩成32个查询Token；推理时只缓存必要的历史KV，并定时清理；如果视频输入过长，先做关键帧筛选，而不是把所有帧都送进去。

延迟方面，多模态系统的瓶颈往往在编码器上。图像编码、音频编码和视频抽帧都是独立的前置处理，建议做成并行的预处理管道，不要让编码耗时叠在语言模型耗时后面串行执行。我在部署时会把编码部分单独放在推理服务的前置阶段，并给编码器增加缓存，这样同一个图像编码结果可以被多次请求复用，节省大量计算。

6. 常见问题排查实录

多模态模型一旦表现不好，大家第一反应是“换更大模型”。但根据我的经验，绝大多数效果问题都不是模型容量不够，而是工程细节出了偏差。我把几个高频问题整理成一份排查速查表，并附上我在调试时的定位方法。

除了表格里的现象，还有一个非常隐蔽的坑：“编码器版本不一致”。我曾经在复现实验时，发现同一份数据在不同机器上跑出的结果对不上，排查了半天，发现图像增强库的版本不同导致图像缩放后的像素值有细微差异。这个问题在纯文本模型里不存在，但在多模态模型里特别常见，因为你同时依赖多个应用库处理不同模态数据。我的建议是，在项目初期就把所有依赖库的版本固定下来，把预处理脚本单独打包，让整个团队共享同一个镜像环境，不要在三台机器上各装一遍。

还有一个高频问题：“图文特征对齐收敛了，但生成内容依然与图不符”。这种情况通常是对齐数据里存在负样本错误，比如图片和描述本身不匹配，模型强行拟合了错误对应关系。我遇到后，处理方式不是盲目加大数据量，而是先做一轮清洗，把置信度低的对齐样本人工复审，筛掉错误样本后再训练，效果立竿见影。

最后说一个容易被忽略的细节：多模态模型的输出层通常沿用文本模型的词表，所以它能输出的内容被限制在文本空间里。如果你想让它“画图”或“谱曲”，必须有额外的生成解码器，而不能只靠一个多模态理解模型搞定一切。很多刚接触多模态的人会把“理解”和“生成”混为一谈，做产品设计时一定要提前想清楚技术边界，不然需求评审时很容易给自己挖坑。

我在实际工作中踩过的最深的一次坑，是以为“模态越多功能越全”。当时我们试图在一个模型里同时塞入图像、音频、视频、传感器四种模态，结果训练时间翻了三倍，各模态效果却互相拖累。后来我重新按业务重要度排序，只保留图像和文本两个核心模态，把音频作为可选输入，传感器干脆放弃，项目的整体效果和稳定性反而大幅提升。多模态不是填空题，不是把各种数据堆进去就行，而是要找到真正有价值的信息通道，把每一条通道的对齐质量打磨到位。这个体会，比任何模型结构都重要。