腾讯微信开源WeVisDoc：端到端文档解析新范式，公式表格结构完整输出

文档解析是知识库建设的地基工程，但这个地基长期存在隐蔽的结构性缺陷。当一份包含数学公式、合并单元格表格的PDF被丢进解析器时，传统多流水线方案会依次调用版面检测、OCR识别、公式识别、表格解析等多个模型，每个环节都会带入误差，最终输出的公式变成乱码、表格结构支离破碎。这种误差累积不仅影响内容可用性，更会直接导致检索召回率塌方。腾讯微信视觉团队最新开源的WeVisDoc试图从根本上改变这一困局——用一个视觉语言模型从页面图像直接生成结构化内容，中间不拆流水线，彻底消除多环节误差传递。

流水线困局与端到端转型

传统文档解析方案的痛点不在某个单点，而在于流水线架构本身。以解析一页学术论文为例，系统需要先做版面检测将页面切成文本块、表格块、公式块，再调用OCR引擎识别文字，然后让表格解析和公式识别模型各跑一遍，最后拼装成Markdown输出。这个流程里，每一级的误差都会顺着链条往下传：版面切错导致后续识别区域偏差、多个模型对同一区域理解不一致、歪斜扫描件引发连锁反应。更棘手的是，这条流水线的每一段都需要单独部署、单独调参、单独维护，排查问题时往往需要人工逐页核对。对于需要处理数十万页文档的企业知识库团队而言，任何一环的系统性偏差都会被放大成灾难性后果。

WeVisDoc的核心创新不仅在于架构选择，更在于其「From Coverage to Capability」的两阶段数据工程策略。阶段一聚焦覆盖面扩展，团队汇集异构数据源构建约四千万条训练数据，并采用结构保持的降质合成技术——给干净的数字页面人为添加噪点、模糊、歪斜等退化效果，但保证结构标注不丢失，确保模型在合成样本上也能获得正确监督信号。阶段二才是真正的能力分水岭：团队先通过独立探针集诊断模型残余错误，将其归类到固定的视觉-结构簇中（如手写笔记、彩色教材、公式密集页），定位完弱点后定向构造数据并重新分配训练预算。阶段一只更新整个模型，阶段二则冻结视觉编码器、单独精调语言模型部分——前者练「看懂页面」的能力，后者修「写对结构」的表达，避免把已学好的视觉能力搅乱。

两阶段数据工程方法论

WeVisDoc在OmniDocBench v1.6上取得95.38分，PureDocBench三档均值75.54分，在所比较的端到端解析器中全部排名第一。真正拉开差距的是退化场景：Clean档79.81分、Digital档77.74分、Real档（真实翻拍）69.08分全部第一，其中真实降质场景比第二名高出约2分，是所有维度中差距最大之处。从阶段一到阶段二，模型在Clean档仅提升0.49分，却在Real档提升4.03分，充分证明把训练资源压在薄弱环节而非继续在标准集刷分的策略价值。对于实际部署，2B版本适合页面清晰、追求吞吐的场景；4B版本在翻拍、退化件多的场景下表现更好，两者综合分差仅0.32，差距主要体现在退化场景。模型可基于vLLM快速起服务，单张12GB级别消费卡即可运行4B版本，也支持llama.cpp和MLX在苹果芯片上本地运行。

落地路径与价值展望

对于知识库与RAG系统建设者，WeVisDoc的价值在源头环节：先把脏PDF、翻拍件解析成干净的结构化Markdown（正文Markdown、公式LaTeX、表格HTML），后续的切分与检索质量会随之提升。建议将PDF渲染为页面图并固定DPI这一步写入流水线，避免小字丢失。对于私有化部署场景，4B档位意味着单卡即可起服务，可先拿领域内一批页面跑一遍评估退化件表现。老文档数字化是另一个被低估的落地场景：企业压着的扫描件、翻拍件格式杂乱、人工录入成本高，用WeVisDoc批量转成结构化Markdown后再做检索或归档，能显著缩短从纸质到可用数据的转化周期。需注意的是，模型专注于页面到结构化文本的转换，不负责内容理解与真假判断；高风险场景（合同、票据、医疗文书）仍需人工复核；手写体、历史扫描件、严重破损文档等场景评测覆盖不足，不宜默认其能稳定处理。

WeVisDoc的开源为文档解析领域提供了一条端到端的新路径，其两阶段数据工程方法论尤其值得借鉴：先量化失败、再定向投入，而非盲目堆数据量。Apache-2.0许可为商业使用扫清障碍，2B与4B双版本覆盖不同资源条件，腾讯在开源生态上的持续投入正在为行业提供更多可落地的选择。