多模态系统出问题时，先查预处理链路，模型本身未必是主因

文本模型上线时，工程团队主要担心的是 prompt 写得好不好、上下文够不够长。图像和音频一旦进入推理链路，问题的主要来源就变了。预处理、模态对齐和失败降级这三段代码，往往比模型本身更容易引发线上事故。

原因不复杂：文本输入是“已经是 token”的状态，而图像和音频是“待转换的字节流”。从字节流到模型可消费的表示之间，横着解码、缩放、重采样、分片、裁剪、编码、对齐七个环节。任何一个环节的假设被打破，模型得到的就不是“稍差一点的输入”，而是“语义完全错位的输入”。前者只是质量下降，后者会造成系统性错误。

更麻烦的是，多模态的错误不会像文本那样立刻暴露。一段错位的音频配上正确的文字，模型依然会一本正经地输出答案，置信度还不低。这类问题只能靠工程侧的输入校验和降级设计提前拦截。

输入侧：转换链路是风险集中区。

图像进入模型前通常要经历解码、EXIF 旋转校正、缩放、归一化、分块。风险点主要在缩放策略：固定短边缩放会让超宽截图的有效文字高度低于可识别阈值；直接拉伸则引入几何形变，模型对表格和版式的判断会明显退化。音频侧同理，采样率不统一、双声道未合并、静音段未裁剪，都会让转写与声学特征漂移。输入侧必须做硬性约束：最大像素数、最大时长、允许的格式白名单、单请求模态数量上限。这些限制要作为明确的拒绝条件，不能依赖事后补救。

推理侧：对齐是隐性成本。

多模态对齐分两层。一层是时间或空间对齐，比如音频分片与转写文本的时间戳必须一致，图像分块与坐标映射必须可逆。另一层是语义对齐，图文是否描述同一对象、音画是否同一场景。前者可以靠工程保证，后者只能靠置信度阈值和交叉校验。实践中常见的错误是把分片结果按顺序拼接就当作对齐完成，一旦有分片失败，后续所有时间戳整体偏移，输出看起来完整，实际全错。

输出与评测侧：聚合逻辑要可审计。

多模态输出往往是多个子结果聚合而成，聚合层必须记录每个子结果的来源、置信度和降级标记。评测不能只看最终答案对不对，还要看“在输入被裁剪或降采样后，答案是否仍然稳定”。建议建立一组长尾输入的回归集：超长截图、低照度照片、带背景音乐的语音、方言夹杂、含大量空白页的文档。每次预处理策略变更都要跑一遍。