Ml Multimodal

多模态建模决策 — 单模态够不够，融合怎么融

R — 原文 (Reading)

（转述）Radford 等提出 CLIP：放弃固定类别标签，改用自然语言作监督——对 4 亿网络图文对做对比学习，把配对图文的表征拉近、错对的推远；由此学得的联合嵌入空间支持零样本迁移：新分类任务无需训练，把类别名写成句子编码后与图像表征比相似度即可分类。

— Alec Radford 等, "Learning Transferable Visual Models From Natural Language Supervision" (ICML 2021)

（转述）多模态文献的长期共识：融合时机是核心设计轴——早期融合在输入/特征层拼接（信息全但噪声互扰），晚期融合在各模态独立预测后合并（稳健且天然抗单模态缺失，代价是丢失跨模态交互），注意力中间融合让一个模态的表示动态查询另一模态（表达力强，成为当前主流）；没有普适最优，选择取决于模态间互补度与数据规模。

— 多模态融合方法族的综述共识（Baltrušaitis 等综述以来的通行的三分法）

I — 方法论骨架 (Interpretation)

第一问永远是"单模态够吗"。加模态的理由必须来自信息增量：任务里存在只有另一模态才携带的信息（视频鉴伪要看音频、商品搜索要图配文）。如果文本已经够用（多数纯文档任务），上多模态只会带来标注成本、对齐工程与过拟合风险——多一个模态不是免费的升级，是翻倍的失败面。

融合三型按互补结构选：

• 早期（特征级）: 各模态编码后在特征层拼接进统一模型——适合两模态细粒度交织的任务（VQA 里问题决定看图的哪里），但对单侧噪声敏感；
• 晚期（决策级）: 各模态独立建模、输出层投票/加权——适合模态质量参差或常缺一侧的场景（医疗影像+化验单，缺哪路都能出预测），代价是无法学到"图像细节呼应文字描述"这类交互；
• 中间（注意力级）: 一个模态的 token 对另一模态做 cross-attention——表达力最强、当前主流，但需要更多数据与调参功夫。

CLIP 的核心直觉值得单独掌握：它证明了"对齐"本身就是一种强大的预训练——不用人工标注类别，只要海量图文对 + 对比损失，就能学出一个图像与语言共享的语义空间；零样本迁移是这个空间的免费赠品（分类变成"图和哪个类名最像"）。这改变了范式：多模态能力可以来自"对齐现成单模态骨干"，不必从零联合训练。

现实的两块硬骨头：①模态缺失是常态而非异常——真实管线里图片会加载失败、某模态历史数据就是稀疏；设计时要问"缺一侧还能不能跑"，晚期融合天然抗缺失，早/中融合需要缺失感知的训练策略；②模态不平衡——一个模态信号强/数据多时会主导训练，另一个沦为装饰品（模型名义上是双模态实际只用了单模态），诊断手段是单模态消融对照。

评测的特殊性：多模态任务的分数提升要拆开审——是真融合收益还是某个模态单独就够（消融检验）；跨模态检索类指标与下游任务表现不总是一致；且基准污染同样存在（测试图文对可能进了预训练语料）。

A1 — 文献中的经典应用 (Past Application)

（本批主题超出西瓜书覆盖范围，A1 改引学界公认的经典案例与公开记录）

案例 1: CLIP 的零样本 ImageNet 实验

• 问题: 传统视觉模型的迁移路线是"ImageNet 预训→下游微调"，每换任务就要标注与重训；能否不训练直接识别新类别？
• 方法论的使用: 用 4 亿网络图文对做对比预训练后，把 ImageNet 的 1000 个类名填进"一张{类别}的照片"模板，编码为文本向量，图像按余弦相似度归类——全程不做一次梯度更新。
• 结论: 零样本准确率追平了有监督训练的 ResNet-50（转述）；且在需要鲁棒性的分布偏移基准上大幅超过 ImageNet 模型——因为它的训练分布是开放的互联网而非固定基准。
• 结果: 零样本分类从不可能变成基线操作；"提示词工程"进入视觉领域（措辞影响零样本分数，回扣 ml-prompting-methodology 的敏感性主题），开放词表检测/分割等后续方向全部以此为地基。

案例 2: 视觉-语言导航之前的融合教训——VQA 基线的"语言捷径"危机

• 问题: VQA（看图答问题）早期模型分数上涨迅猛，但怀疑者发现许多问题不看图也能答个八九不离十（"这是什么运动？"大概率答网球）。
• 方法论的使用: 构造仅语言盲基线（LSTM 只读问题不读图）与之对比；进一步构造平衡数据集使答案分布不依赖问题先验。
• 结论: 相当一部分表观多模态收益实为语言先验——模型没学会"看图"，学会了"猜高频答案"；平衡集上早期模型分数大幅回落（转述）。
• 结果: 迫使整个社区把"单模态消融基线"写进多模态论文的标准协议——这正是本 skill E 段"消融检验真融合"纪律的直接出处。

案例 3: 音频-视觉语音识别中的模态互补经典

• 问题: 嘈杂环境下纯语音识别崩溃，人却靠唇形补足听觉。
• 方法论的使用: 音频流与视频(唇部)流分别编码后融合；系统实验比较不同融合层级在干净/噪声条件下的表现差异。
• 结论: 干净音频时单模态已近最优、融合收益小；噪声越大跨模态互补价值越高，且中期融合在交互密集场景占优、晚期融合抗单侧失效（转述的通行实验格局）。
• 结果: 确立"融合策略的价值随模态互补度变化"的设计观——本 skill I 段三型选型的原型论据。

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

1. 用户的项目同时有图文/音视等多源数据，纠结"要不要都喂进去"、"会不会反而更差"——单模态够吗的判定。
2. 用户在设计模型架构时问："特征拼接就行还是要 cross-attention？"——融合策略选型。
3. 用户想搞懂 CLIP 类模型为什么能零样本分类，或想用 CLIP 做免训练的图文检索/打标/异常检测。
4. 用户的线上系统经常遇到某一模态拿不到（图片超时/传感器坏/字段缺失），模型要么报错要么乱猜——缺失鲁棒性设计。
5. 用户的多模态模型指标很好但上线体验差，或想知道涨点是不是真来自融合——评测与消融审查。

语言信号 (用户的话里出现这些就应激活)

• "多模态/multimodal/multi-modal"/"图文/vision-language/VL"
• "融合/fusion/early fusion/late fusion/cross-attention 怎么选"
• "CLIP/对比学习/zero-shot/零样本分类/检索"/"图文匹配"
• "模态缺失/missing modality/缺一张图怎么办/某模态数据少"
• "模态坍塌/modality collapse/模型没用另一个模态/单模态就够了
• "VQA/captioning/图文检索/跨模态"

与相邻 skill 的区分

• 与 ml-transformer-era 的区别: 那管单模态骨架选型（CNN/RNN/Transformer 三轴）；本 skill 在其之上处理"多个模态怎么接"的问题。典型串联：先用那边定各模态各自的 encoder，再到本 skill 定接法。
• 与 ml-pretraining-paradigm 的区别: 那是档位决策（自训/微调/PEFT/提示），本 skill 是模态维度的架构决策；"用现成 CLIP 零样本还是微调它"是两边交界处——档位问题走那边，对齐与融合设计走这边。
• 与 ml-llm-evaluation 的区别: 那管 LLM 能力度量与污染探针；本 skill 特化多模态评测的两个独有坑——单模态消融基线与跨模态基准泄漏，评估协议层面互补。
• 与 ml-imbalanced-learning 无关（那是类别不平衡）：模态不平衡是"输入通道间的贡献失衡"，别被字面混淆。

E — 可执行步骤 (Execution)

当 skill 被激活后, agent 应按以下步骤执行:

1. 单模态充分性判定

   • 明确回答：目标信息是否分布在多个模态？主模态单独做到什么水平？另一模态携带什么独有信息？
   • 完成标准: 写明"模态 B 提供 A 无法提供的 X 信息"的具体论证；论证不出 → 劝退，留在单模态方案。
   • 判停条件: 用户只是"觉得多模态高级"而无信息增量论证 → 明示成本（标注×对齐×失败面翻倍）后再确认。

2. 单模态基线先行

   • 分别训主模态与次模态的独立模型（哪怕粗糙版），记录各自指标。
   • 完成标准: 两个基线数字落盘——它们既是下限参照也是后面消融的对照组。
   • 判停条件: 次模态单模态已接近目标精度 → 直接用单模态，结束；次模态信号极弱且获取昂贵 → 同上劝退。

3. 融合策略选型

   • 按"交互密度 × 缺失风险 × 数据量"三轴定：细粒度交织且数据足 → 注意力中间融合；模态常缺/质量参差 → 晚期决策级；折衷或起步 → 早期特征级（最便宜的第一版）。
   • 完成标准: 选型卡写明三轴取值与对应理由。
   • 判停条件: 三轴评估后仍无法确定 → 从早期融合起步（最便宜可回退），把升级列入迭代计划，不空耗选型时间。

4. 对齐路线判定

   • 判断是否可借现成对齐空间：图文任务优先试 CLIP 类零样本（成本几乎为零）；零样本不够再考虑在其上轻量适配（衔接 ml-pretraining-paradigm 的 PEFT 档）；确需从零联合训练则预算另议。
   • 完成标准: 有"零样本成绩 vs 目标"的差距数字，作为是否继续投入的依据。
   • 判停条件: 零样本已达业务目标 → 直接采用现成对齐空间，跳过步骤 5-6 的自训流程，仅保留监控。

5. 缺失与不平衡预案

   • 设计缺失路径（缺模态时的降级推理方式）；训练中加入单模态消融检查防止一路主导。
   • 完成标准: 缺失场景有明确行为定义（拒绝/降级/插补）；消融显示双模态均实质参与（否则回到步骤 3 重选融合）。
   • 判停条件: 消融证明去掉次模态掉点 < 噪声水平 → 名义多模态实为单模态，砍掉次模态简化系统。

6. 多模态专项验收

   • 除端到端指标外必交：单模态消融对比、（若用公开 benchmark）污染自查（衔接 ml-llm-evaluation 探针）、跨模态检索指标与任务指标的分歧说明。
   • 完成标准: 验收报告能回答"涨点确实来自跨模态协同"。
   • 判停条件: 消融显示涨点全部来自单模态 → 回退单模态方案并归档多模态尝试的负结果，避免重复踩坑。

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

• 单模态已满足需求: 加模态增加标注成本、对齐工程、推理延迟与故障面，无信息增量时全是负资产。
• 要研究多模态大模型的内部机制（视觉 token 如何被 LLM 处理、幻觉的机理分析）: 本 skill 是应用层建模决策，机制研究超出射程。
• 数据只有一种形态、只是格式不同（都是表格/都是文本）: 格式转换不是多模态问题。

文献反复警告的失败模式

• 模态坍塌（一路主导）: 强模态（通常图像或大数据量一侧）吃掉全部梯度，弱模态沦为摆设；名义双模态实际单模态还白白付了成本——诊断靠单模态消融，预防靠平衡采样/梯度调制。
• 语言捷径陷阱: 多模态基准上模型可能靠单侧先验拿到大半分数（VQA 的著名教训）；不跑盲基线的多模态报告不可信。
• 标注成本指数增长: 对齐好的多模态标注远贵于单模态（每条样本要多人多源核对一致）；项目排期常在此翻车，须在步骤 1 就摊开算。
• 天真拼接的维度暴力: 把高维模态直接 concat 进小模型，参数与过拟合风险暴涨而交互没学到；拼接≠融合。
• 评测集泄漏: 热门图文基准大量出现在预训练网页语料中，榜单分虚高；自有分布抽测不可省。

作者盲点 / 时代局限（本批为外推补全）

• 必须声明: 本 skill 主题超出西瓜书覆盖范围——书中无任何多模态内容（2016 年语境）；本 skill 是对该时代局限的外推补全，素材为 2021-2023 交叉学科文献共识转述，方法论仍在快速演化（原生多模态大模型、任意模态到任意模态的新架构持续涌现，融合三型的边界在被改写），执行时应核对最新进展。
• "何时融合最优"没有定论: 文献中早/晚/中融合的胜负随任务与数据规模反复横跳，本 skill 给的是决策框架与默认起点，不是终局答案。
• 对齐质量的度量不成熟: "两个模态在表征空间对齐得好"缺乏公认量化标准；CLIP 分数等代理指标与下游表现的关系仍在争论中。
• 西瓜书的 NFL 思想在此同样成立: 不存在对所有模态组合都最优的融合架构，脱离具体任务谈"主流架构"没有意义。

容易混淆的邻近方法论

• 多模态 ≠ 多视图: 多视图学习指同一对象的多份同质观测（多个相机视角/多个量表），模态间异质性低；融合技巧可互通，但缺失模式与对齐难度完全不同。
• 跨模态检索 ≠ 多模态分类: 前者是对齐空间的排序问题（召回指标），后者是决策问题（分类指标）；用 CLIP 时先想清楚自己要哪种。
• 模态缺失 ≠ 数据缺失: 表格数据的缺失值插补逻辑（ml-feature-engineering 语境）不能照搬到模态缺失——后者缺的是整条信息通道，正确处置是架构级降级而非数值填充。
• 注意力可视化 ≠ 融合证据: cross-attention 图好看不代表融合有效，判据仍是消融对照（回扣 ml-explainability-xai 对显著性图的警告）。

相关 skills

• depends-on: ml-methodology-router（总入口）
• contrasts-with: ml-transformer-era（单模态骨架选型 vs 多模态接法决策）
• composes-with: ml-pretraining-paradigm（CLIP 零样本→PEFT→全训的档位衔接）, ml-llm-evaluation（benchmark 污染探针复用）, ml-explainability-xai（消融与归因工具用于验证融合真实性）

审计信息

• 来源性质: 扩充批E·交叉学科——主题超出西瓜书(2016)覆盖范围，R 段为公认文献的转述表述（均已标注"（转述）"）
• 验证通过: 待流水线三重验证复核
• 测试通过率: 待阶段 4 测试 (详见 test-prompts.json)
• skill_version: 0.0.1
• 蒸馏时间: 2026-08-24