文档解析的慢，慢在逐 Token
现在的视觉文档解析（PDF 转结构化文本）大多沿用自回归生成：模型一个 Token 一个 Token 地吐结果。一页密集的合同或论文动辄两三千 Token，逐个生成的延迟在单页场景勉强能忍，放到企业级 RAG 知识库——百万页文档批量入库——就是天堑。PaDoc 的思路是利用文档天然的空间结构：页面按布局切块（标题、段落、表格、图注），块与块之间的内容高度独立，可以并行解码。
三项关键数据
- 吞吐提升：67% - 118%（多页批量场景收益最大）
- P95 延迟：下降 39% - 55%（长尾任务不再拖队列）
- 关键路径解码步数：中位数减少 58.4%（决定单页最快出结果时间）
工程上怎么用
PaDoc 不需要换模型：它是在现有视觉文档解析模型上加的解码策略层，切块、调度、合并由框架处理，输出格式不变。对已经在跑 Qwen-VL、GOT-OCR 这类解析管线的团队，迁移成本主要在推理框架侧的批处理改造。论文报告的测试覆盖中英文混合的合同、报表、论文三类版式，表格块的结构还原精度没有因为并行化掉点。
为什么是微信视觉团队在做这件事
微信生态里每天有海量图片和 PDF 在聊天与文档场景流转，文档理解是实打实的生产负载。腾讯微信视觉过去两年持续输出文档解析相关开源工作，PaDoc 这次解决的是「准了但慢」的问题——识别准确率上来之后，吞吐和延迟成了规模化落地的下一个瓶颈。同类方向上，各家大厂的 RAG 平台都在卷入库速度，解码侧优化的优先级肉眼可见地在提高。
RAG 的入库速度决定知识库的保鲜度——文档解析快一倍，知识库的更新周期就短一半。