企业官网建设流程全解析

做多模态这一行，最让人难受的不是模型不收敛，而是你辛辛苦苦把图像、音频、文本三条数据流接进同一个网络，训练日志上 loss 一路往下掉，评测集指标却只比单用图像分支高了零点几个点。我遇到过不止一次这种情况，回头看基本都是同一个原因：三种模态只是被"放"进了一个模型，从来没有真正被"对齐"过。这篇就围绕多模态数据的融合这件事，把从数据进管道到模型出结果中间那些真正决定成败的环节拆开讲——怎么选融合路线、预处理里哪些参数一改就翻车、共享嵌入空间怎么搭、训练怎么分阶段、以及模型不涨点时该往哪儿查。适合已经跑通过单模态任务、准备把音频和文本接进来的开发者，也适合正在评估要不要上多模态方案的产品侧同学。

1. 单模态模型撞到墙之后：多模态融合到底在解决什么问题

1.1 真实业务里的数据从来不是单一形态

实验室里的数据集是干净的：一个文件夹装图片，一个文件夹装文本，一一对应。真实业务里不是这样。一条短视频同时带着画面、配音、字幕和封面文案；一次客服通话留下的是录音、转写文本和工单；一台设备的巡检记录里有振动声音、红外图像和值班员手写的备注。这些数据天生就是多模态的，只是过去我们习惯先把它压成一种形态再处理——把视频抽帧当图像分类，把录音转成文本再走 NLP。这个"降维"动作本身就在丢信息。

举个特别典型的例子：一段客服录音里客户说"好的我知道了"，纯文本看是确认，加上音频你会听出语气是压着火的，再看工单里的截图，才知道他是因为退款金额不对。文本给出字面语义，音频给出情绪和态度，图像给出事实证据。三者缺一，判断就会偏。这就是多模态融合最朴素的价值：不是为了让模型更花哨，而是因为单一模态的信息量本来就不够支撑决策。

我在做内容理解类项目时的体会是，只要业务里存在"人需要同时看几样东西才能下结论"的场景，多模态就有收益空间。反过来，如果人看一眼就能判断，那硬上多模态基本是给自己找麻烦——多一路数据就多一路预处理、多一路对齐、多一路故障点。

1.2 三条融合路线：早融合、中融合、晚融合的取舍账

这是所有多模态项目绕不开的第一个决策。三条路线不是谁先进谁落后，是三种工程成本与收益的交换。

我的实际选择习惯是这样的：先做晚融合把整条链路跑通，拿到每个单模态的基线分数，再用中融合去冲上限。晚融合的基线分数极其重要，它是你判断中融合到底有没有用的标尺。很多人跳过这一步直接上交叉注意力，最后指标涨了 2 个点，却说不清这 2 个点是融合带来的，还是模型参数量变大带来的。如果晚融合已经能到 0.88，中融合做到 0.91，这 3 个点才是真收益；如果晚融合就有 0.90，中融合 0.91，那这 1 个点大概率是噪声，还要付出几倍的训练和推理成本。

还有一个折中方案值得提：加权晚融合。每个模态出一个置信度，融合时按置信度加权，权重可以让模型自己学（门控网络），也可以人工设定。这个方案在工业场景里性价比很高，尤其是某一路数据质量不稳定的情况下——比如夜间图像很差，那就让模型自动把图像分支的权重压下去。

1.3 一个容易被忽略的前提：模态之间必须有可对齐的锚点

融合的前提是"对齐"。这句话说起来简单，落地时能坑死人。所谓锚点，就是你知道图像里的这一帧、音频里的这 2 秒、文本里的这句话，说的是同一件事。

锚点有三种强度。强对齐：时间戳精确同步，像录屏文件里画面和声音天然对齐。弱对齐：样本级配对，一张商品图和一段商品描述属于同一条记录，但图和描述里的哪句话对应不知道。无对齐：一堆图片和一堆文本，只知道在同一个主题下，具体配对关系未知。

强对齐最好办，直接按时间切窗就行。弱对齐是绝大多数业务的实际状态，也是对比学习类方法的用武之地。无对齐最难，通常要靠聚类或者弱监督，投入产出比往往不高——我的建议是遇到无对齐场景先想清楚能不能人工标注一小批配对数据，几百对高质量样本能顶很多花哨的算法。

注意：锚点对齐这件事必须在数据管道层面解决，不要指望模型自己学出来。模型能学的是"对齐之后怎么融合"，学不了"哪句话配哪一帧"，后者是数据工程问题。

2. 把三种模态喂进网络之前：预处理决定了上限

这一章我想说得重一点：多模态项目里 70% 的效果问题出在预处理。模型架构大家用的都差不多，公开的编码器就那么几个，真正拉开差距的是数据怎么洗、怎么切、怎么对齐。下面按模态拆。

2.1 图像分支：分辨率、归一化与增强策略的一致性

分辨率不是越高越好。ViT 类模型对输入尺寸敏感，224×224 是通用预训练权重的默认值，你硬改成 384 需要重新插值位置编码，效果未必更好，显存却翻倍。我的做法是：先按预训练权重的原生分辨率跑通，确认整条链路没问题，再考虑提分辨率。如果业务里小目标很关键（比如质检里的细微划痕），那宁可用更高分辨率的小模型，也别用低分辨率的大模型——细节在 resize 那一步就没了，后面再大的模型也补不回来。

归一化必须和预训练权重匹配。拿 ImageNet 均值方差预训练的骨干，输入就得按 mean=[0.485,0.456,0.406]、std=[0.229,0.224,0.225] 做标准化；你要是喂 0-1 的原始像素，模型也能训，但收敛会慢很多，而且和预训练权重严重错配。这个坑我见过不止一次，代码里忘了除以 255，loss 曲线看着正常但因为预训练权重失效，最终精度掉了好几个点。

import torch from torchvision import transforms # 与 ImageNet 预训练权重匹配的标准预处理 train_tf = transforms.Compose([ transforms.RandomResizedCrop(224, scale=(0.7, 1.0)), # 别用太小比例，会破坏语义 transforms.RandomHorizontalFlip(p=0.5), transforms.ColorJitter(0.2, 0.2, 0.2, 0.02), # 幅度别太大 transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]), ])

增强策略这里有个多模态特有的坑：增强会破坏跨模态一致性。你把图像水平翻转了，但配对的文本里写着"左边的那个人"，这一对样本就变成了错误对齐的噪声。同理，颜色抖动做得太猛，文本里描述的颜色特征就失效了。我的处理原则是：在对比预训练阶段用轻度增强（翻转、小幅度裁剪），在任务微调阶段干脆关掉几何增强，或者只在确认不影响文本描述的前提下使用。

2.2 音频分支：采样率、帧移与梅尔频谱的参数怎么定

音频预处理有一套相对固定的行业参数，但每一项都有理由。

采样率统一到 16000 Hz 是最常见的做法，语音识别类的预训练模型基本都吃这个采样率。如果原始数据是 44100 Hz，重采样到 16k 会丢掉高频信息，但对语音语义影响不大；如果业务里判别依据是环境音、机器异响这类高频特征，那就得保留到 22050 或更高，别盲目降到 16k。

分帧参数：帧长 25 ms、帧移 10 ms 是语音领域的经典组合，对应 16k 采样率就是 400 个采样点一帧、160 个采样点一跳。帧移小于帧长意味着有重叠，能避免帧边界切断音素。梅尔滤波器组数量常用的有 40、64、80、128 四档，做语音识别 80 够用，做音频分类或者声音事件检测建议 128，因为需要更细的频带分辨。

import torchaudio import torch mel = torchaudio.transforms.MelSpectrogram( sample_rate=16000, n_fft=400, # 25ms @ 16kHz hop_length=160, # 10ms @ 16kHz n_mels=128, f_min=20, f_max=8000, ) to_db = torchaudio.transforms.AmplitudeToDB(top_db=80) def audio_to_feat(waveform): # waveform: [1, T] spec = mel(waveform) # [n_mels, frames] spec = to_db(spec) # 按时间轴做均值方差归一化，比全局归一化更稳 spec = (spec - spec.mean(dim=-1, keepdim=True)) / (spec.std(dim=-1, keepdim=True) + 1e-5) return spec

时长处理很容易被忽略。音频分类类任务通常切 3 到 10 秒的定长片段，太短拿不到足够上下文，太长显存扛不住。切分时的重叠比例建议 30% 到 50%，尤其是事件检测类任务，事件可能正好落在切分边界上，不重叠就会漏。还有个细节：静音段检测。一小时的录音里有大量静音，不剔掉的话算力全浪费在空白上，而且静音片段会让模型学到"没声音=负样本"这种错误关联。

2.3 文本分支：分词器、截断策略与特殊 token

文本这块看起来最成熟，实际上坑不少。首先是分词器必须和预训练模型严格对应，中文场景下用 BERT 的中文词表还是用多语言词表，会直接影响效果。多语言词表对中文的分词粒度往往偏碎，一个字一个 token，序列长度翻倍，截断后信息丢失严重。我一般优先选领域匹配的单语词表。

截断策略要按任务定。分类任务取头部的 [CLS] 通常够，但如果关键信息在长文本末尾（比如合同的风险条款、工单的解决方案），就得用滑动窗口或者取首尾拼接。命名实体类任务绝对不能随便截断，截掉的部分实体就丢了。

from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese") enc = tokenizer( text, max_length=256, truncation=True, padding="max_length", return_tensors="pt", ) # 注意：padding 后的 attention_mask 一定要传给模型

还有一个多模态特有的问题：文本来源的噪声。如果文本是 OCR 出来的，会有错别字、乱序、图标被识别成乱码；如果是语音转写出来的，会有同音错字、缺少标点、语气词堆叠。这两种噪声的分布和干净文本完全不同，直接喂进预训练语言模型效果会打折。我的做法是预处理阶段先过一遍规则清洗（去连续重复字符、修常见同音错字、补句号），再进模型。这一步花的时间不多，但对最终指标的影响经常比换模型还大。

2.4 批处理与对齐：padding、mask 与模态缺失的填法

真正把三路数据拼成一个 batch 的时候，问题来了。文本长度不一要 pad，音频时长不一要 pad，图像数量可能一个样本好几张。这时候 collate 函数写不好，整个训练都是错的。

关键原则：所有 padding 都必须配 mask，并且在模型里真的用上。文本的 attention_mask 要传，音频的 padding 部分在池化时要排除，图像的变长序列要在注意力里 mask 掉。我见过太多代码 pad 了但没 mask，模型把零向量当成真实特征去学，最后精度莫名其妙地上不去。

def collate_fn(batch): images = torch.stack([b["image"] for b in batch]) max_t = max(b["audio"].shape[-1] for b in batch) audio_pad = torch.zeros(len(batch), 128, max_t) audio_mask = torch.zeros(len(batch), max_t, dtype=torch.bool) for i, b in enumerate(batch): t = b["audio"].shape[-1] audio_pad[i, :, :t] = b["audio"] audio_mask[i, :t] = True texts = tokenizer([b["text"] for b in batch], padding=True, truncation=True, max_length=256, return_tensors="pt") return {"image": images, "audio": audio_pad, "audio_mask": audio_mask, "text": texts}

模态缺失的处理也要在这一层考虑。真实数据里总有样本缺某一路——有的视频没声音，有的记录没配图。做法有两种：训练时随机丢掉某个模态（模态 dropout），迫使模型学会在缺模态时也能工作；或者在缺失位置填一个可学习的"空模态"向量，让模型明确知道这里是缺失而不是全零。后者更稳，我一般优先用。

3. 表征与对齐：让三种模态说同一种语言

3.1 编码器选型：别一上来就追最大最贵的

每个模态配一个编码器，这是标准结构，选型的核心约束是推理延迟和显存，不是榜单分数。

图像侧，ResNet 系列稳定、快、显存友好，做基线首选；ViT 系列在数据量足够时上限更高，但小数据集上容易过拟合，而且对输入分辨率敏感。音频侧，如果只是要一个通用音频表征，用公开的音频频谱图预训练模型（AST、PANNs 这类）直接抽特征很省事；如果业务偏语音语义，用语音识别模型的编码器部分做特征提取也常见，但要注意它的输出是帧级序列，需要接一个池化层。文本侧，中文场景下 BERT 系列仍是性价比最高的选择，短文本分类任务上大模型带来的增益并不明显。

我列一个实际项目里的取舍表，供参考：

一个实操建议：先冻结所有编码器，只训融合层。这一步能快速验证数据和融合结构有没有问题，而且训练极快。等融合层训稳了，再解冻顶层做联合微调。这个顺序反过来（一上来全解冻）最常见的后果是预训练权重被小数据集带偏，越训越差。

3.2 投影层与共享嵌入空间：对比学习的温度系数和负样本

要让三种模态"说同一种语言"，核心手段是对比学习：把配对的模态对在嵌入空间里拉近，不配对的推远。这中间最关键的部件是投影层——每个模态的输出维度都不一样，必须通过一个线性层或者两层 MLP 统一到同一个维度（常用 256 或 512）。

投影层用一层线性还是两层 MLP？经验上两层 MLP 加非线性在预训练阶段效果更好，但下游任务微调时，很多人会把投影层换回单层线性，因为预训练学到的非线性映射在任务数据上不一定适配。这个细节在公开的图文对比预训练模型（CLIP 这一类）的实现里就有体现，值得注意。

温度系数是对比学习里最敏感的超参。它控制 softmax 的锐度，取值太小（比如 0.01）会导致梯度爆炸和训练不稳，太大（比如 1.0）会让正负样本区分不开。常用范围是 0.05 到 0.1，0.07 是出现频率最高的默认值。如果你发现训练早期 loss 剧烈震荡，第一个该调的就是它，往上调。

负样本的来源基本靠 batch 内构造——同一个 batch 里其他样本就是负样本。这意味着 batch size 直接决定了负样本数量，太小（比如 8）会严重限制效果。显存不够怎么办？梯度累积能解决显存问题，但解决不了负样本数量问题，因为累积的梯度是分步算的。想在小显存上要大批量负样本，就得用特征队列（把历史 batch 的特征存起来当负样本），代价是实现复杂度上升。

3.3 交叉注意力与融合瓶颈：为什么需要一个"压缩"环节

到了中融合，最朴素的做法是让文本 token 去 attend 图像的 patch 序列和音频的帧序列。问题是序列长度爆炸：图像 196 个 patch、音频 500 帧、文本 50 个 token，两两注意力的计算量随长度平方增长，显存很快就撑不住。

解决办法是加一个融合瓶颈：先把图像和音频的长序列压缩成固定数量（比如 32 个）的查询向量，再让文本和这 32 个向量做交互。这个思路在很多公开的多模态结构里都有体现，本质是用少量可学习的 query 去"抽取"长序列里的关键信息，把交互成本从 O(N×M) 降到 O(N×32)。

import torch.nn as nn class FusionBottleneck(nn.Module): def __init__(self, dim=512, n_query=32, n_head=8): super().__init__() self.query = nn.Parameter(torch.randn(1, n_query, dim) * 0.02) self.cross = nn.MultiheadAttention(dim, n_head, batch_first=True) self.norm = nn.LayerNorm(dim) def forward(self, long_seq, mask=None): # long_seq: [B, L, D] 图像 patch 或音频帧序列 q = self.query.expand(long_seq.size(0), -1, -1) out, _ = self.cross(q, long_seq, long_seq, key_padding_mask=mask) return self.norm(out + q) # [B, n_query, D]

query 数量怎么定？太少（8 个）会丢信息，太多（128 个）失去压缩意义。经验值是 16 到 64 之间，具体看任务的复杂度，我的习惯是从 32 起步。另外残差连接别省，压缩过程本身就是有损的，加残差至少能保住 query 本身的表达能力。

3.4 模态缺失与不平衡：让模型在残缺数据上也能跑

上线之后你会发现，训练集里模态齐全，线上数据永远缺胳膊少腿。用户在弱网环境上传的视频没声音，老系统的历史数据没配图，第三方接口偶尔超时返回空文本。如果模型没在训练时见过缺失情况，遇到就崩。

手段就是模态 dropout：训练时以 10% 到 20% 的概率随机把某一路整个置空（用可学习的空模态向量替代，而不是置零），并且保证至少留一路。这样训出来的模型，在线上缺模态时性能下降是平滑的，而不是断崖式的。这个技巧我强烈建议所有多模态项目都加上，成本几乎为零，收益是线上稳定性。

模态不平衡是另一个隐性问题。三路数据里往往有一路信息量特别大（图像通常是这样），模型就会偷懒只依赖这一路，其他两路学不到东西。诊断方法在后面第 5 章会详细讲怎么验证。

4. 训练与微调的实操节奏：从对比预训练到任务头

4.1 分阶段训练：先对齐、再融合、最后任务微调

想一步到位把多模态模型训好，基本不可能。我的标准节奏是三个阶段。

第一阶段：模态对齐。冻结所有编码器，只训投影层，用对比损失让配对的模态在嵌入空间靠近。这个阶段数据要求低（只需要配对关系，不需要任务标签），收敛快，目标是建立共享空间。验证指标是检索准确率——给定一张图，能不能在候选集里找回配对的文本，这个指标比 loss 直观得多。

第二阶段：融合结构训练。解冻融合模块（交叉注意力、瓶颈层），冻结编码器，用带标签的任务数据训练。这一阶段模型在学习"怎么把三路信息合起来做决策"。

第三阶段：联合微调。解冻编码器的顶层（比如最后 2 到 4 层），用小学习率（比前面阶段小 10 倍左右）做端到端微调。

为什么不能合并？因为三个阶段的学习目标、数据要求、学习率都不一样。混在一起训，最常见的问题是编码器被任务标签带偏，预训练学到的通用表征被破坏，也就是常说的灾难性遗忘。分阶段做，每一阶段的验证都清晰，出问题也容易定位到是哪一段。

4.2 损失函数配比与梯度平衡

多任务训练里，各损失的量级往往差好几个数量级。对比损失可能在 0.1 到 1 之间，分类的交叉熵可能是 0.3 也可能是 5，加的权重不对，其中一项就会主导整个优化方向。

我的做法是：先单独训练每个损失对应的头，记录它们收敛后的数值量级，然后按量级倒数设置初始权重。比如对比损失稳定在 0.5、分类损失稳定在 2.0，那初始权重可以是 1:0.25，让两项对梯度的贡献接近。

loss_align = contrastive_loss(img_emb, txt_emb, temp=0.07) loss_cls = F.cross_entropy(logits, labels) loss = 1.0 * loss_align + 0.25 * loss_cls

如果发现某个损失权重怎么调都不对，试试梯度归一化：分别计算每个损失对共享参数的梯度范数，按范数倒数缩放，强制各项在梯度层面的贡献均衡。这个做法实现不复杂，但对训练稳定性的提升很明显。

4.3 小样本下的冻结策略与参数高效微调

业务数据往往就几千条，甚至几百条。这个量级全量微调多模态模型必然过拟合。做法是只训最必要的部分。

优先级排序：融合层和任务头 > 投影层 > 编码器顶层的注意力输出层 > 编码器全量。数据在几百条这个量级，我只训融合层和任务头，所有编码器全冻。数据到几千条，可以把编码器最后一层的注意力输出投影放开。数据上万条再考虑全量微调。

参数高效微调方法在这类场景很合适：只训练低秩适配器，参数量能压到全量的百分之几，效果接近全量微调，显存占用也小得多。多模态场景下有个额外注意点：适配器最好加在每个模态的编码器上，而不是只加在融合层，因为模态特有的分布差异主要靠编码器吸收。

4.4 显存与吞吐：特征缓存是性价比最高的优化

图像编码器和音频编码器的推理是整条链路里最贵的。如果你的编码器在训练时是冻结的（第一、二阶段都是），那就没必要每个 epoch 重算一遍——直接离线把特征抽出来存到磁盘，训练时只读特征。

这个优化带来的提速经常是几倍甚至十几倍，尤其对音频这种计算密集的模态。代价是存储，一张图 768 维 float32 是 3KB，一百万张图大概 3GB，完全可接受。如果嫌大，可以存 float16 或者降维。

@torch.no_grad() def cache_features(loader, image_encoder, audio_encoder, out_path): feats = [] for batch in loader: img_f = image_encoder(batch["image"].cuda()) aud_f = audio_encoder(batch["audio"].cuda(), batch["audio_mask"].cuda()) feats.append({"img": img_f.cpu().half(), "aud": aud_f.cpu().half(), "label": batch["label"], "text": batch["text"]}) torch.save(feats, out_path)

其他常规优化：混合精度训练（fp16 或 bf16）基本是标配，注意音频频谱经过 log 变换后数值范围较大，用 bf16 比 fp16 更不容易溢出。梯度累积用来凑等效 batch size，但记住它对对比学习的负样本数量没帮助。数据加载的 worker 数量要按 CPU 核数调，音频解码是 CPU 密集型，worker 给少了 GPU 会一直等数据——这个"瓶颈在数据加载"的问题我遇到过好几次，profiler 一看 GPU 利用率只有 40%，加 worker 之后直接拉满。

5. 排错实录：融合模型不涨点的六种典型原因

这一章是全文最实用的部分。下面每一条都是我自己或者身边同行真实踩过的问题，按排查顺序排列。

5.1 模态主导：模型其实只用了其中一路

最常见的症状是：多模态模型的指标和单用图像分支几乎一样，多出来的音频和文本形同虚设。原因通常有三。一是某一路的信息量本来就占绝对优势，模型没有动力去学其他路；二是某一路的特征数值范围明显更大，把其他路的信号淹没了；三是融合层初始化不当，某一路的输入从一开始就被压到接近零。

诊断方法很直接——单模态消融。分别只喂图像、只喂音频、只喂文本、两两组合，测一遍指标，画成表格。如果全模态的指标等于最好的那一路，说明融合没起作用。再看模态 dropout 测试：训练完之后，推理时故意把某一路换成空模态向量，看指标掉多少。掉得少说明模型本来就依赖得少。

修复手段：给占优势的那一路加输入噪声或者随机 mask（类似 DropPath 的思路），逼模型去看其他路；调整各模态特征的归一化方式，让它们的数值范围接近；在融合层前给每个模态加一个可学习的缩放系数，初始化为 1，让模型自己调。

5.2 对齐错位：标签对不上的隐蔽 bug

这个坑最阴险，因为训练能跑、loss 会降，但模型永远学不好。典型场景：数据表 join 的时候键选错了，A 的图配了 B 的音频；或者时间戳的时区没统一，导致音频和视频错开几个小时；或者数据增强时对图像做了随机裁剪，但对应的标注框没跟着变换。

排查要有链路意识，我是按这个顺序走的：先随机抽 20 条样本人工核对，看图、听音频、读文本是不是同一件事；再检查数据表的 join 键和去重逻辑，特别是有没有一对多被展开成多对多；然后检查时间戳的单位和时区，是不是有的用秒有的用毫秒；最后检查增强流程，所有几何变换是否同步应用到了标注。

我印象最深的一次是音频和文本错位，原因是音频切片时用了帧索引而当成了采样点索引，导致每条样本都错开了几秒钟。这种 bug 人工听前几条样本根本发现不了，因为偏差小，听着还挺像，是拿检索准确率一路趴在随机水平才反查出来的。所以验证对齐最可靠的手段是检索指标，不是肉眼看。

5.3 评估陷阱：离线指标好看，线上表现拉胯

多模态模型的离线评估有几个固有偏差。第一是数据分布偏差，离线评测集的模态齐全度远高于线上，线上缺模态的样本占比可能到 30%，离线根本测不出来。第二是标注偏差，标注员在看得到全部模态的情况下打标签，而线上模型面对的是噪声更大的真实输入。第三是负样本构造偏差，离线评测如果只做随机负采样，难度远低于线上的真实检索场景。

改进办法：评测集里主动混入缺失模态的样本，比例和线上对齐；负样本用难负样本（在同一类目内采样）而不是全库随机；再切一个时间上更靠后的数据做一份"未来集"，专门看模型的时效性。

5.4 部署侧：多模态服务的延迟和降级怎么设计

三路编码器串起来，单条请求的延迟很容易到几百毫秒。如果业务是实时交互，这就不可接受。常见优化：把三路编码并行执行而不是串行（异步 IO + 多流），能省掉将近一半时间；特征维度做 PCA 降维，融合阶段的延迟能显著下降而精度损失很小；把文本和音频的编码提前做成异步预计算，用户请求到达时直接读缓存。

降级策略必须提前设计，不能等出事再想。我的方案是三级降级：正常状态下三路全开；当某一路的编码服务超时或者返回异常，自动切到双路融合（用训练时的模态 dropout 能力，模型本来就支持）；当两路都挂，退回到最可靠的单路，同时打点报警。这个设计的前提还是那句话——训练时必须做模态 dropout，否则模型根本没法在缺模态状态下工作。

提示：降级的阈值不要拍脑袋定，用压测数据定。把每一路的 P99 延迟测出来，取一个既能兜住大部分请求又不会误触发降级的值。

6. 落地场景的一点经验

说几个我实际见过、收益比较明确的多模态融合场景，方便判断自己的业务适不适合。

内容理解与检索是最成熟的。图文音三路一起建模之后，用户拿一句话搜视频，能同时匹配字幕、画面和声音，召回率比纯文本检索高出一截。这类场景数据量大、对齐关系清晰（同一条内容天然配对），是做多模态最舒服的起点。

质量检测类场景里，图像和音频的组合经常被低估。一台设备出故障，画面上的异常和声音里的异响往往同时出现，但单一模态都会漏——有的故障看得见听不见，有的听得见看不见。两路融合把漏检率压下去的效果，通常比单独优化任何一路都明显。

无障碍与内容无障碍化也是典型场景：给视频自动生成描述、给图片生成替代文本、给音频做画面摘要，这些任务本身就是多模态的，而且评估标准相对客观。

最后分享一个我自己的体会：做多模态项目，花在数据管道上的时间应该远多于花在模型结构上的时间。我经手的几个项目里，真正让指标从"能用"到"好用"的改动，基本都是数据层面的——把对齐修对、把噪声清掉、把缺失模态补齐、把负样本换成难的。模型结构换来换去，往往就是小数点后一位的波动。如果你的多模态模型不涨点，先别急着换架构，回去把数据管道重看一遍，十有八九问题在那儿。