2026年6月24日15 个节点#tech#ai
OCR,重新成为研究课题
2026 年,文档 OCR 为何不再是一桩已解决的标配,小而专的模型、不切页的长程解析,以及一道再也分不出高下的基准天花板。
完整简报
多年来,OCR 一直被当作一桩了结的 API 调用。2026 年年中,三个版本在一天之内相继落地,把它重新拉回活跃研究:问题不再是“我们能否读出文字”,而是哪一种模型形态,小型专家、通用 VLM,还是长上下文解析器,契合某条特定的文档管线。
三种技术押注#
目标相同,架构分岔
Mistral OCR 4、PaddleOCR 的 PP-OCRv6,以及百度的 Unlimited-OCR,瞄准的是同一个结果,却拉动了不同的杠杆:一个托管的多语言模型、一个参数量不足 3500 万的端侧家族,以及一个 KV 缓存恒定的长程解析器。这一分岔,正是故事所在。
Mistral OCR 4#
托管、多语言、懂结构
Mistral OCR 4 以宽广的语言覆盖与文档结构化输出立足,作为一个托管 API,把 OCR 定位为一项有价的服务,而非一个你自己运行的模型。它比拼的是便利,以及表格/版式的保真,而非生字符精度。
open_in_newmistral.ai/news/ocr-4PP-OCRv6#
3500 万参数以下,覆盖 50 种语言
PaddleOCR 的 PP-OCRv6 推出一个分级家族,小到足以在端侧运行,却仍覆盖 50 种语言。它是托管 VLM 的反命题:把检测与识别做成一个可嵌入的微小组件,而非一次远程调用。
open_in_newhuggingface.co/blog/PaddlePaddle/pp-ocrv6Unlimited-OCR#
一次成形、不切页的解析
百度的 Unlimited-OCR 让 KV 缓存保持恒定,以一趟通行解析长文档,而非把页面切片。它把 OCR 重构为一个长程解码问题,上下文长度与显存,塑造着单次前向能读下多少。
open_in_newgithub.com/baidu/Unlimited-OCR专家模型 对 通用 VLM#
权衡真正发威之处
纯文档模型以广度换取成本与时延;前沿 VLM 什么都能读,却按 token 计费,且在表格上飘移。这一选择极少关乎峰值精度,它关乎每千页的成本,以及输出如何接入下游解析。
每页成本#
真正的选择之轴
通用 VLM 按整张渲染页面的 token 计费;专家模型只收一笔极小的固定费用。在文档规模上,这一差距是数倍量级,这正是为什么一个纸面上更逊色的专家,往往拿下生产线上的那个名额。
管线中的落位#
在 RAG/文档栈里,谁该放在哪
OCR 坐落在分块、嵌入与检索的上游。在这里选错模型,误差会向下游处处扩散,因此落位的抉择,事先抽取,还是把 VLM 放进回路,比单一基准上的一个点更要紧。
事先抽取 对 回路之内#
两种集成范式
要么 OCR 在前端跑一次,把干净文本喂进索引;要么让 VLM 在智能体回路之内,按需读取页面。事先抽取更便宜、可缓存;回路之内更灵活,却要在每次查询时付出 VLM 的成本。
基准的天花板#
OmniDocBench 正在饱和
当多个模型在同一套件上挤在 90 分以上,排行榜便不再是信号。有意思的差异转移到别处:多语言覆盖、表格与公式上的结构保真,以及每页几美元,而这些,单一的饱和分数一个都捕捉不到。
来源与相关
想把这张图变成真正的系统
读完简报之后,下一个问题通常是「那我们该怎么把它做出来」。Weple 是一家外包开发工作室,擅长把这样的结构拆成小块交付。咨询时把本页链接一并发给我们即可。
咨询开发