多模态大模型:算法、应用与微调

你可能已经会调文字模型，但一碰上「图 + 文一起丢进去」就有点懵：图片到底被怎么处理成模型能吃的东西？OCR、看图答题、找图里的表格，哪些是现成能力、哪些得自己微调？这篇不堆公式，按「先看算法拆成哪几块 — 再对着任务挑能力 — 最后决定要不要微调」的顺序走一遍，每步给出可对照的动作。

文字模型你大概已经能跑通了，一换成「图加文一起丢进去」就容易卡住：这张图到底被模型怎么读进去的？我拿张发票让它抽字段算不算超纲？今天这篇不堆公式，按「先拆算法看三块拼图怎么协作、再对着任务挑现成能力、最后决定要不要动微调」这个顺序走一遍，每一步都给出能直接上手的动作和判断标准。

先把预期放正：多模态不是魔法，很多需求用提示词加少量样本就能过验收，真正需要微调的场景比想象中少。反过来，如果你连图片在模型眼里被折算成多少 token 都没算过，后面谈微调、谈省钱都是空转。下面按顺序拆。

先拆开看：多模态模型由哪三块拼起来

不管哪家多模态模型，基本都能拆成三块：视觉编码器、投影层、语言模型。视觉编码器把一张图压成一串向量，但语言模型读不懂这串向量，中间得靠投影层翻译成「语言模型习惯的表示」，最后语言模型负责把答案吐成文字。这三块任何一块没接好，整条链路就跑不通，所以排查问题时要先定位是哪一块出毛病，而不是笼统说「模型不行」。

视觉编码器

把图片切成小块、各抽一串特征向量，分辨率越高、切得越细向量通常越多

投影层

把视觉向量翻译成语言模型能读的表示，也是微调时最常被单独调的一层

语言模型

接收「翻译后的图」加你的文字提示，负责推理并输出最终答案

融合方式

指图信息在什么阶段进入语言侧，进的早晚决定了它更偏对齐还是更偏看图说话

这三块的拼接方式，直接决定模型擅长什么。融合发生在较早阶段，更吃图文对齐质量，适合需要「图文一起推理」的活；融合偏后期，更像先描述图再回答，适合看图说话类任务。所以挑模型前先问自己一句：我要的是描述、定位坐标，还是跨图文的推理？答案不同，该看的模型也不同。

对着任务挑能力：哪些活不用微调就能干

落地前先把需求归成三类：识别类、理解类、生成类。识别类是 OCR、票据字段这类，答案对错好判；理解类像图表问答、截图排错，得看它推理链路是否靠谱；生成类是看图写文案，主观性强、验收标准最松。三类验收方式完全不同，混在一起讨论就永远吵不出结论。

• 识别类优先试零样本加提示词，不行再用少量样本做适配，别一上来就微调
• 理解类先确认图片分辨率与 token 折算口径，细节糊了先换更大图或换模型
• 生成类别急着上模型，先把你自己的风格样例整理成对照集
• 每类都留一组坏案例（模糊图、倾斜图），验收时专门跑一遍

成本这块别只盯文字单价。一张高分辨率图被切成很多小块后，折算出的 token 数往往远超你的直觉，一张图抵得上一大段文字是常态。建议按你实际业务里的图片尺寸，到 /official-api 看各家口径，再用 /tools/token-price-calculator 把图文混合的调用量算一遍，得到的是当时的数字，别用手感估。

什么时候该微调，微调哪一层

微调不是第一选项，是兜底选项。判断顺序是这样的：提示词改不好、检索也补不上，还是稳定翻车，才轮到微调。很多团队说「模型看不懂我们行业的图」，拆开一看其实是输入格式、图片预处理或者术语先验没喂对，把提示词和示例修一遍就过了，根本用不着动权重。

1. 第一步 定位失败类型把翻车案例分类：是没看清图、看不懂领域术语，还是输出格式不对。只有「看懂了但仍答错」才像缺微调。
2. 第二步 先穷尽非微调手段改提示词、补 few-shot 示例、加图片预处理（裁边、去噪、放大）、上检索补充领域资料。逐条试完再判断。
3. 第三步 选微调层级只动投影层：数据少、成本低，适合对齐新的图文风格；加 LoRA 适配器：能兼顾视觉侧、改动中等；全量微调留给有稳定数据管线和大算力的团队。
4. 第四步 核实服务商口径自己干还是外包，先到 /stacks/fine-tuning 看当时的服务商分类和适用场景，再按你的数据量决定。

数据准备上有个容易踩的坑：图文对要成对清洗，别只洗文字。图糊了、标注口径不一致的样本，比单纯样本少更伤效果——模型会学到互相矛盾的映射。开工前先抽一批样本人工标一遍，确认口径统一，再规模化生产。

先怀疑输入格式，再怀疑提示词，最后才怀疑模型权重。