如果你一路写到了 pipeline、融合、阅读顺序，再回头看端到端多模态模型，视角其实会发生明显变化。
一开始接触多模态时，很容易被它吸引：
- 一次输入整页
- 不需要 OCR
- 不需要 layout
- 不需要规则
- 看起来一切都能交给模型解决
但当你真正搭过一个可运行、可维护的 PDF 解析系统之后，你会发现，问题从来不在于：
多模态模型"行不行"
而在于：
业务是否愿意为它的特性负责。
多模态模型，确实已经很强了
先把话说清楚：
端到端多模态模型并不是噱头，它的能力是真实存在的。
在很多 pipeline 非常吃力的场景里，它反而是优势明显的：
- 复杂版面、异形排版
- 规则难以覆盖的视觉关系
- 扫描件与非扫描件混杂
- 非标准表格、弱结构文档
当你把它当成一个"读图理解器"时，它往往能直接给出一个人类可理解的答案，而不需要你先拆布局、切区域、算顺序。
从能力上看，多模态模型已经远远超过传统 OCR + 规则那一套。
问题不在能力，而在"端到端"承担了什么责任
真正的分歧，出现在"端到端"这四个字上。端到端意味着：
- 输入：整页图像或整份文档
- 输出：一段生成文本，或结构化字符串
- 中间过程：不可见、不可控
在很多任务上，这是优势；但在 PDF 解析里，它会自然引出一系列工程问题：
- 输出结构是否稳定
- 结果是否可复现
- 错了之后怎么修
- 失败时如何退
这些问题，本身并不是"模型不够好"，而是端到端范式对系统提出的要求更高。
Pipeline 体系
PDF
布局 / 区域
文本 / 表格 / 图像
融合 / 顺序
结构化结果
端到端多模态
整页图像
多模态模型
生成文本 / 结构
图：端到端 vs Pipeline---信息流动方式不同
溯源与截图问答，是多模态目前最难补的一块
在不少真实业务中，有一个绕不开的需求：
"这个结果，是从原文哪来的？"
在 pipeline 体系里，这几乎是天然存在的：
- 每个文本块有 bbox
- 每个表格单元格有坐标
- 可以高亮、截图、回指原文
而在端到端多模态模型里：
- 输出是生成文本
- token 概率存在
- 但空间对应关系往往是丢失的
如果业务需要：
- 精确溯源
- 审计
- 图文问答中的截图引用
那当前阶段，多模态模型往往并不是一个合适的"唯一核心"。
结构不可控，比"偶尔不准"更致命
另一个经常被低估的问题，是结构不可控。
多模态模型的输出，看起来是确定性的文本，但这种确定性只存在于"这一轮生成"。
在实际工程中，你很容易遇到：
- 表格字段缺失
- 列数不一致
- JSON 被截断
- Markdown 格式漂移
- 同一输入多次跑，结构略有变化
这些问题的共同特点是：
- 不算模型失败
- 但工程上几乎没法兜
如果你的下游系统强依赖结构稳定性，这会成为一个非常现实的风险。
长文档与资源成本，是端到端模型的硬约束
PDF 解析绕不开长文档。而在多模态模型中，长文档意味着：
- 更大的图像输入
- token 消耗迅速增长
- 截断风险
- 推理成本不可控
你可以切页、切图、滑窗，但一旦开始切，实际上就已经偏离了"端到端"。这并不是实现问题，而是物理限制。
换一个角度：多模态不是接不住，而是"要价更高"
如果换一个更工程化的视角来看，多模态模型的问题其实可以重新表述为：
它不是接不住 PDF 解析，而是对业务前提要求更高。
只要你的业务能够同时接受以下条件：
- 是离线或批处理场景
- 能接受解析速度较慢
- 可以限制 PDF 页数或尺寸
- 不要求严格的 bbox、溯源、高亮
- 不做精确的图文定位问答
- 能容忍一定失败概率
（token 超限、死循环、幻觉、格式错误） - 并且可以选择能力足够强的多模态模型
那么在这些前提下：
直接 All in 多模态，不但合理，反而可能是工程复杂度更低的选择。
是
否
是否 All in 多模态？
业务条件是否满足
可以直接 All in 多模态
仍需 Pipeline / 融合
离线 / 批处理
页数 / 尺寸可控
无需溯源 / bbox
可容忍失败概率
模型能力足够强
需要稳定交付
需要回退 / 溯源
系统强依赖结构
图：什么时候可以 All in 多模态？
Pipeline 与多模态，本质上是在为不同风险负责
从这个角度再回头看 pipeline 和融合，会发现它们并不是竞争关系。它们承担的，其实是不同类型的风险：
- Pipeline 负责的是：
- 稳定性
- 可控性
- 可回退
- 局部失败不影响整体
- 多模态 All in 负责的是：
- 语义理解上限
- 复杂结构整体把握
- 少规则、少工程
前者是在为系统失败负责 ，后者是在为模型理解能力下注。
这不是新技术淘汰旧技术，而是两种风险模型的选择。
承担系统失败风险
承担理解失败风险
Pipeline 体系
稳定性
可控性
可回退
局部失败可兜底
端到端多模态
整体语义理解
复杂版面泛化
低工程复杂度
系统层风险
模型层风险
图：Pipeline vs 多模态---承担的风险不同
什么时候，多模态反而是更好的选择
如果你的系统目标是：
- 给人看，而不是给系统用
- 理解大意，而不是精确还原
- 能看懂，比每一步都对更重要
那么 pipeline 那一整套：
- 区域
- bbox
- 阅读顺序
- 融合
- 降级
反而可能是过度工程化。
在这种场景下，多模态模型"偶尔犯错"的成本，往往低于 pipeline 长期维护的复杂度。
小结：这是业务选择，而不是技术输赢
所以，与其问：
"端到端多模态能不能接住 PDF 解析？"
不如换一个更诚实的问题：
"我的业务，愿意为哪种风险负责？"
- 如果你更怕：
- 不可解释
- 不可控
- 不可回退
→ pipeline 更合适
- 如果你更怕：
- 看不懂
- 表达能力不够
- 复杂版面解析不出来
→ All in 多模态完全合理
这不是技术路线之争，而是业务约束下的工程取舍。也正因为如此，真正成熟的系统，往往不是"只选一边"，而是清楚地知道，什么时候该 All in，什么时候不该。