51c视觉~OCR~合集1

Surya 是多语言文档 OCR 工具包，可进行准确的文本行检测，目前支持 90 多种语言，以及即将推出表格和图表检测功能。开源地址：https://github.com/VikParuchuri/surya。

whaosoft-143

2850人浏览 · 2025-05-25 00:15:00

whaosoft-143 · 2025-05-25 00:15:00 发布

我自己的原文哦~ https://blog.51cto.com/whaosoft/12800789

一、OCR~合集总结开源ocr

#Surya

Surya 是多语言文档 OCR 工具包，可进行准确的文本行检测，目前支持 90 多种语言，以及即将推出表格和图表检测功能。

开源地址：https://github.com/VikParuchuri/surya

...

#EasyOCR

EasyOCR 是一个用 Python 编写的 OCR 库，用于识别图像中的文字并输出为文本，支持 80 多种语言和常用书写文字。

开源地址：https://github.com/JaidedAI/EasyOCR

...

#MMOCR

MMOCR 是基于 PyTorch 和 mmdetection 的开源工具箱，专注于文本检测，文本识别以及相应的下游任务，如关键信息提取。

开源地址：https://github.com/open-mmlab/mmocr

...

#PaddleOCR

PaddleOCR 是基于飞桨的 OCR 工具库，包含总模型仅 8.6M 的超轻量级中文 OCR，单模型支持中英文数字组合识别、竖排文本识别、长文本识别。同时支持多种文本检测、文本识别的训练算法。

开源地址：https://github.com/PaddlePaddle/PaddleOCR

...

#CnOCR

CnOCR 是 Python 3 下的文字识别 OCR 工具包，能够识别简体中文、繁体中文（部分模型）、英文和数字等常见字符，并支持竖排文字的识别。该工具包内置了 20 多个预训练模型，可满足各种不同的应用需求，用户安装后即可立即投入使用。

开源地址：https://github.com/breezedeus/CnOCR

....

#COCO-Text V2.0

COCO-Text 数据集包含 63686 幅图像，239506 个文本实例。包括手写版和打印版，清晰版和非清晰版，英语版和非英语版。

下载地址：https://bgshih.github.io/cocotext/

....

#SynthText in the Wild dataset

该数据集是一个合成数据集，包含 800 万幅图像，80 万个合成词实例。每个文本实例都使用其文本字符串、字级和字符级边界框进行标注。

下载地址：https://www.robots.ox.ac.uk/~vgg/data/scenetext/

....

#Uber Text dataset

Uber Text 数据集包含从车载传感器采集的街道级图像和由图像分析师团队标注的 Ground Truth。

特点如下：

街道图像及其文本区域多边形和相应文字说明
包含企业名称、街道名称和街道编号文本等 9 个类别
包含超 11 万幅图像
每幅图像平均有 4.84 个文本实例

下载地址：https://s3-us-west-2.amazonaws.com/uber-common-public/ubertext/index.html

....

#Chinese Text Dataset in the Wild(CTW)

CTW 是由清华大学与腾讯联合推出的一个大型中文自然文本数据集，包含 32285 幅图像，1018402 个中文字符，3850 个字符类别和 6 种属性。

下载地址：https://ctwdataset.github.io/

....

#MSRA Text Detection 500 Database(MSRA-TD500)

MSRA-TD500 数据集包含 500 幅自然图像，使用袖珍相机从室内（办公室和商场）和室外（街道）场景进行拍摄。室内图像主要是标志牌、门牌和警示牌，室外图像主要是复杂背景下的引导牌和广告牌。

下载地址：http://www.iapr-tc11.org/mediawiki/index.php/MSRA_Text_Detection_500_Database_%28MSRA-TD500%29

....

#Ollama-OCR

现在可作为 Python 包使用！

对于开发人员和 OCR 爱好者来说是个好消息——Ollama -OCR现已作为 Python 包提供！🎉

此次更新使将Ollama-OCR集成到您现有的应用程序、工作流程或自动化脚本中变得比以往更加容易。只需几行代码，您现在就可以直接在 Python 中利用最先进的 OCR 功能。

🌟 主要特点：

1. 多种视觉模型

选择适合您需求的型号：

LLaVA 7B：轻量且快速，可实时提取文本。

Llama 3.2 Vision：对于复杂的布局和详细的文本具有较高的精度。

或 Ollama 上提供的任何其他视觉模型

2. 灵活的输出格式

Ollama-OCR 支持多种输出格式，以适应不同的用例：

Markdown：保留结构化格式，如标题、列表和项目符号。
纯文本：提取干净、未格式化的文本。
JSON：机器可读的结构化输出，易于集成。
结构化格式：提取并按层次组织表格和内容。
键值对：适用于表格、收据或标记数据提取。

3. 离线和私密

您的数据保留在本地。Ollama-OCR 离线处理图像，确保您的敏感信息保持私密。

🚀 如何使用

安装

要开始使用 Ollama-OCR，只需使用 pip 安装该包：

pip install ollama-ocr

确保 Ollama 服务器已启动并正在运行，并且已安装所需的模型以最大化您的 OCR 体验。

ollama pull llama3.2-vision:11b

简单和高级用法

以下是一个可帮助您入门的简单示例：

from ollama_ocr import OCRProcessor


# Initialize OCR processor
ocr = OCRProcessor(model_name='llama3.2-vision:11b')  # You can use any vision model available on Ollama


# Process an image
result = ocr.process_image(
    image_path="path/to/your/image.png",
    format_type="markdown"  # Options: markdown, text, json, structured, key_value
)
print(result)

# Invoice #1024


## Billed To:


- Really Great Company


## Pay To:


- Avery Davis
123 Anywhere St., Any City
123 456 7890


## Bank Account Information:


- Bank: Really Great Bank
- Account Name: John Smith
- BSB: 000 000
- Account Number: 0000 0000


## Invoice Details:


### Description:
- Content Plan: $200.00
- Copy Writing: $100.00
- Website Design: $250.00
- Website Development: $500.00
- SEO: $200.00


### Subtotal: $1,250.00 (30% discount)
- Total: $875.00


## Payment Terms:


- Payment is required within 14 business days of invoice date.
- Please send remittance to hello@reallygreatsite.com.


# Thank you for your business.

💡 应用场景

发票处理：自动将供应商名称、金额和日期等详细信息提取为会计软件的键值对。
表格提取：将扫描文档中的表格中的结构化数据提取为 JSON 或 CSV 格式。
内容管理系统：集成 OCR 来索引基于图像的文件，以便于搜索和检索。
表单解析：将扫描表单中的字段提取为后端系统的标记数据。
研究论文：从基于图像的学术论文中的图表和表格中提取文本以供进一步分析。

Ollama-OCR 的 5 大集成用例

文档管理系统通过从扫描文档中提取和索引可搜索文本来增强 SharePoint 或 Google Drive 等工具。
会计软件自动从发票和收据中提取数据以填充 QuickBooks 或 Xero 等平台中的字段。
电子商务平台从基于图像的目录中提取产品详细信息，以自动为 Shopify 或 WooCommerce 创建列表。
医疗保健应用将医疗记录和处方数字化，以便集成到电子病历 (EMR) 系统中。
人工智能聊天机器人使聊天机器人能够智能地解释和响应从用户上传的图像中提取的文本。

使用 Ollama-OCR 解锁新的可能性

Ollama-OCR功能多样、易于使用且功能强大，是将 OCR 集成到任何工作流程中的终极解决方案。无论您是管理文档、自动化流程还是构建创新应用程序，此 Python 软件包都可以让您以前所未有的方式提取和利用文本。

完整代码：

https://github.com/imanoop7/Ollama-OCR

....

二、PaddleOCR~合集 3.0

#PaddleOCR 2.9

正式开源文本图像智能分析利器

OCR 方向的工程师，之前一定听说过 PaddleOCR 这个项目。目前项目累计 Star数量已超过 43k+ ，安装包月下载量超过 40w+ 。

滑动查看更多图片

本次 PaddleOCR 最新发版，带来两大重磅升级，包括：

发布文档场景信息抽取v3（PP-ChatOCRv3-doc）开源版，大幅提升了文本图像版面解析能力，充分发挥文心一言语言理解优势，信息抽取整体效果相比于上一个版本提升 6 %，同时新增 7 个实用的 OCR 基础模型。
支持 OCR 领域低代码全流程开发能力，通过极简的 Python API 一键调用 17个 OCR 相关模型，提供基于统一命令和图形界面两种方式，实现模型简洁高效的使用、组合与定制。支持各种主流硬件如英伟达GPU、昆仑芯、昇腾和寒武纪无缝切换。

PaddleOCR 代码库地址，欢迎大家star：

https://github.com/PaddlePaddle/PaddleOCR

PP-ChatOCRv3-doc 在线体验地址：

https://aistudio.baidu.com/community/app/182491/webUI

下面我们就对上述升级依次进行说明。

文档场景信息抽取v3开源版

PP-ChatOCRv3-doc 的系统流程如下图所示：首先输入预测图片，送入通用版面分析系统，经过版面分析后，预测图像中的文字信息和表格结构。将版面分析系统预测出的版面类别、文字、表格结构与 Query 之间进行向量检索，得到与 Query 相关的文本信息，然后送入 Prompt 生成器重新组合成，基于文心大语言模型将海量数据和知识的融合，信息抽取准确率高且应用广泛。其中版面分析系统中集成了图像矫正（可选）、版面区域定位、常规文本检测、印章文本检测、文本识别、表格识别等多个功能，可实现 CPU/GPU 上的高精度实时预测。通过大小模型的融合策略，各部分得以充分展现其优势：小模型以其高精度的图像处理能力脱颖而出，而大模型则展现出卓越的内容理解能力。

在研发 PP-ChatOCRv3-doc 同时，沉淀了 7 个实用的 OCR 基础模型，方便独立使用。具体如下：基于 RT-DETR 的 2 个高精度版面区域检测模型和 1 个基于 PicoDet 的高效率版面区域检测模型、高精度表格结构识别模型 SLANet_Plus 、文本图像矫正模型 UVDoc 、公式识别模型 LatexOCR 、基于 PP-LCNet 的文档图像方向分类模型。

OCR 领域低代码全流程开发

飞桨低代码开发工具 PaddleX，依托于 PaddleOCR 的先进技术，支持了 OCR 领域的低代码全流程开发能力。通过低代码全流程开发，可实现简单且高效的模型使用、组合与定制。这将显著减少模型开发的时间消耗，降低其开发难度，大大加快模型在行业中的应用和推广速度。特色如下：

模型丰富一键调用：将文本图像智能分析、通用 OCR 、通用版面解析、表格识别、公式识别、印章识别涉及的 17 个模型整合为 6 条模型产线，通过极简的 Python API 一键调用，快速体验模型效果。此外，同一套 API ，也支持图像分类、目标检测、图像分割、时序预测等共计 200+ 模型，形成 20+ 单功能模块，方便开发者进行模型组合使用。
提高效率降低门槛：提供基于统一命令和图形界面两种方式，实现模型简洁高效的使用、组合与定制。支持高性能推理、服务化部署和端侧部署等多种部署方式。此外，对于各种主流硬件如英伟达GPU、昆仑芯、昇腾、寒武纪和海光等，进行模型开发时，都可以无缝切换。

下面是 PP-ChatOCRv3-doc 的快速推理程序，5 行代码实现经典模型和大语言模型的交互。

# 安装PaddlePaddle和PaddleX，PP-ChatOCRv3-doc的快速推理程序
from paddlex import create_pipeline
predict = create_pipeline( pipeline="PP-ChatOCRv3-doc",
                            llm_name="ernie-3.5",
                            llm_params = {"api_type":"qianfan","ak":"","sk":""} )  
visual_result, visual_info = pipeline.visual_predict("https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/contract.pdf")
vector = pipeline.build_vector(visual_info=visual_info)
chat_result = pipeline.chat(key_list=["乙方", "手机号"], visual_info=visual_info, vector=vector)

如果您对产线的预训练模型效果满意，可以直接对产线进行高性能推理/服务化部署/端侧部署，如果不满意，您也可以使用产线的二次开发能力，提升效果。完整的产线开发流程文档请参考：

https://paddlepaddle.github.io/PaddleOCR/latest/paddlex/overview.html

此外，我们也在星河社区为开发者提供了基于云端图形化界面零代码的全流程开发工具，下面是 PP-ChatOCRv3-doc 零代码模型产线的开发界面，只需按要求准备好微调模型的数据，就可以快速进行模型迭代和集成部署，详细可以参考教程《零门槛开发产业级AI模型》中相关章节：

https://aistudio.baidu.com/practical/introduce/546656605663301

....

#PaddleOCR 3.0

OCR精度跃升13%，支持多语种、手写体与高精度文档解析

PaddleOCR自发布以来凭借学术前沿算法和产业落地实践，受到了产学研各方的喜爱，并被广泛应用于众多知名开源项目，如Umi-OCR、OmniParser、MinerU、RAGFlow等，已成为广大开发者心中的开源OCR领域的首选工具。

2025年5月20日，飞桨团队发布PaddleOCR 3.0并对外开源，全面适配飞桨框架3.0正式版，进一步提升文字识别精度，支持多文字类型识别和手写体识别，满足大模型应用对复杂文档高精度解析的旺盛需求，结合文心大模型4.5 Turbo显著提升关键信息抽取精度，并新增对昆仑芯、昇腾等国产硬件的支持。

PaddleOCR3.0全景图

1.
全场景文字识别模型PP-OCRv5

单模型支持5种文字类型和复杂手写体识别

整体识别精度相比上一代提升13个百分点

PP-OCRv5是面向大模型时代多模态需求、聚焦多语言多场景识别的轻量级端到端文字识别方案。该方案实现以单一模型高效、精准地支持简体中文、繁体中文、中文拼音、英文、日文五种文字类型，以及手写、竖版、拼音、生僻字等复杂文本场景的识别。

左右滑动查看更多

PP-OCRv5的主要优势有：

单模型支持5种文字类型（简体中文、繁体中文、中文拼音、英文和日文）。PP-OCRv5是业界首个单模型支持5种文字类型的超轻量级(<100M)开源模型，在此之前，通常是单一模型解决一种文字类型的识别。若一个文档中有3种文字类型，则需要调用三个模型去实现文字识别，导致识别效率不高。PP-OCRv5通过统一模型架构实现5种文字类型的无缝识别，无需针对不同文字类型部署独立模型，简化了部署流程，也提升了识别的总体精度和速度。
支持复杂手写体识别。手写体混合印刷体的识别是多个应用场景的刚需，例如：教育行业的试卷作业批改场景、医疗行业的病历数字化场景、法律行业的合同笔录数字化场景等。PP-OCRv5支持中英日手写体识别，对复杂连笔、非规范字迹识别精度有显著提升。
整体识别达到SOTA精度。在业务多场景高难度文字识别评估集上，PP-OCRv5的识别精度达到当前最优，比上一版本PP-OCRv4，识别精度提升13个百分点！

PP-OCRv5 vs PP-OCRv4 模型精度对比

欢迎开发者到飞桨星河社区体验PP-OCRv5的能力：

https://aistudio.baidu.com/community/app/91660/webUI

2.通用文档解析方案PP-StructureV3

支持多场景、多版式PDF高精度解析

在公开评测集中领先众多开源和闭源方案

文档解析是一种从文档图像中提取结构化信息的技术，主要用于将复杂的文档版面转换为结构化数据，这项技术在AI大模型文档处理领域有广泛的应用。通用文档解析方案PP-StructureV3在上一代的基础上，强化了版面区域检测、表格识别、公式识别的能力，增加了图表理解和多栏阅读顺序的恢复能力，并可以将结果转换 Markdown和JSON格式。

左右滑动查看更多

PP-StructureV3的主要优势有：

精度高：支持多场景、多版式PDF高精度解析，在OmniDocBench基准测试中领先众多开源和闭源方案。

注：以上精度信息除PP-StructureV3和MinerU-1.3.11为自测精度外，均来自OmniDocBench

多项专精能力: 除了在OmniDocBench上的精度指标更高之外，PP-StructureV3还有多项专精能力，如：印章识别、图表转表格、嵌套公式/图片的表格识别、竖排文本解析及复杂表格结构分析等——这些能力是很多重要场景AI应用落地的刚需。

欢迎开发者到飞桨星河社区体验PP-StructureV3的能力：

https://aistudio.baidu.com/community/app/518494/webUI

3.智能文档理解方案PP-ChatOCRv4

原生支持文心大模型4.5 Turbo

关键信息抽取精度相比上一代提升15个百分点

PP-ChatOCR系列是飞桨特色智能文档理解类解决方案，融合大模型和小模型的优势能力，达到通用场景下的文档图像关键信息抽取效果，支持身份证、银行卡、企业合同等多种场景的关键信息提取。PP-ChatOCRv4在上一代基础上，结合文心大模型4.5 Turbo强大的理解优势，并支持离线使用多模态文档理解模型PP-DocBee2，实现了更高效的文本图像信息抽取，一站式解决版面分析、生僻字、多页pdf、表格、印章识别等常见的复杂文档信息抽取难点问题。

PP-ChatOCRv4的主要优势有：

关键信息抽取精度相比上一代提升15个百分点，效果业界领先。在内部业务中文场景评估集（覆盖印刷文字、表格、印章、图表等）中的准确率如下表所示：

原生支持文心大模型4.5 Turbo，还兼容PaddleNLP、Ollama等工具部署离线大模型。
集成PP-DocBee2，支持印刷文字、手写体文字、印章信息、表格、图表等常见的复杂文档信息抽取和理解的能力。

左右滑动查看更多

欢迎开发者到飞桨星河社区体验PP-ChatOCRv4的能力：

https://aistudio.baidu.com/community/app/518493/webUI

PaddleOCR 3.0全面适配飞桨框架3.0正式版，并发布三大特色能力，包括：全场景文字识别模型PP-OCRv5，通用文档解析方案PP-StructureV3和原生支持文心大模型4.5 Turbo的智能文档理解方案PP-ChatOCRv4；新增对昆仑芯、昇腾等国产硬件的支持；提供好学易用的工具，赋能开发者轻松应用文字识别和文档解析技术，快速落地AI应用。非常欢迎大家立即体验&使用，并给我们反馈！

开源地址：

https://github.com/PaddlePaddle/PaddleOCR

,,,.

#PaddleOCR 3.2

多语种文字识别精度提升，多平台部署能力升级

今年上半年，PaddleOCR发布了3.0和3.1版本，全方面提升了文本识别和文档解析的精度，并新增了大模型的连接器MCP server。在此基础上，近日我们发布了PaddleOCR 3.2版本，带来了以下重要升级：

1.提升英文文本识别精度，扩展更多语言文本识别能力。本次支持全新的PP-OCRv5英文识别模型，英文文本识别精度相比上一版本提升近11%。此外，新增泰语和希腊语的文本识别能力，进一步扩展多语言文字识别支持。

2.全面升级部署能力。提供完整的PP-OCRv5 C++本地部署方案，兼容多平台，助力用户在工业产线系统、桌面应用等多种场景下高效集成和部署。同时，全面开源高稳定性服务化部署方案，支持用户灵活定制Docker镜像和SDK，从而应对实际场景的多样化部署需求。

3.支持细粒度性能Benchmark。新增产线级推理Benchmark，提供逐层、逐模块的详细性能数据，帮助用户精准分析当前硬件上的模型方案性能瓶颈，进而有针对性地优化部署方案。

提升英文文本识别精度，扩展更多语言文本识别能力

针对用户在实际应用中对于提升英文识别准确率和扩展更多语言适配的需求，本次发版中，重点优化了PP-OCRv5英文文本识别模型，英文识别场景准确率提升近11%；同时，进一步拓展了多语言适配范围，新增泰语和希腊语的文本识别。

英文识别的关键升级

进一步提升字符的识别准确率，同时优化空格识别效果，有效减少因漏识别空格导致的单词“粘连”现象。
增强对手写英文的识别能力，在手写英文文本上的识别准确率有明显提升。

PP-OCRv5 英文数据集模型精度指标对比

注：为更全面评估英文模型能力，本次模型研发过程中重新收集了大量来自真实场景的高难度评估数据。

部分英文场景模型预测的结果可视化如下：

手写英文

印刷英文

英文海报

PP-OCRv5 多语种精度指标

部分泰语和希腊语场景模型预测的结果可视化如下：

PP-OCRv5英语及多语种文字识别命令行使用方式

可以通过在命令行中使用--lang 参数，来进行指定语种的文本识别模型推理：

# 通过 `--lang` 参数指定使用英文的识别模型
paddleocr ocr -i https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_hw_en_02.png \
    --lang en \ # 此处为英语，如需指定泰语，则修改为 th
    --use_doc_orientation_classify False \
    --use_doc_unwarping False \
    --use_textline_orientation False \
    --save_path ./output \
    --device gpu:0

当指定语言为英文时，默认模型从PP-OCRv5_server_rec修改为en_PP-OCRv5_mobile_rec, 上述命令行的其他参数说明请参考命令行使用方式。

https://www.paddleocr.ai/latest/version3.x/pipeline_usage/OCR.html#21

全面升级部署能力

PaddleOCR 3.2在部署上进行了两方面的升级：升级C++本地部署能力以及开源高稳定性服务化部署方案。下面将就这两方面的升级进行说明。

C++本地部署能力升级

在工业产线系统、Windows桌面应用等场景中，常常有使用C++语言调用模型产线推理能力的需求。在PaddleOCR 3.0和3.1中，C++本地部署能力延续了PaddleOCR 2.x的方案。自PaddleOCR 3.2起，C++本地部署SDK迎来了全面升级，底层架构经过重新设计，充分融合了与PaddleOCR 3.x Python推理库一致的设计理念。新版SDK以高度模块化的方式，将各项功能拆分为可独立使用的单功能模块，开发者可根据实际需求自由组合，便于灵活构建完整的产线推理流程。

针对PP-OCRv5，C++ SDK新增了文档图像方向分类和文本图像矫正等模块，功能与Python端完全对齐。同时，前后处理算子也根据最新的Python实现进行了重构，确保了C++与Python推理结果的精度一致性。新版SDK不仅支持命令行（CLI）和API两种调用方式，且两者均提供丰富的可调参数，接口风格与Python CLI/API保持高度一致。配套的详细使用文档进一步提升了开发体验，极大地方便了开发者将SDK集成到各类应用中，助力高效部署和快速开发。

以下分别是使用PaddleOCR 3.2的C++ SDK CLI实现PP-OCRv5和文档图像分类单功能模块推理的例子：

./ppocr paddleocr --input your_input --save_path your_save_path \
    --doc_orientation_classify_model_dir your_doc_orientation_classify_model_dir \
    --doc_unwarping_model_dir your_doc_unwarping_model_dir \
    --textline_orientation_model_dir your_textline_orientation_model_dir \
    --text_detection_model_dir your_text_detection_model_dir \
    --text_recognition_model_dir your_text_recognition_model_dir

./ppocr doc_img_orientation_classification --input your_input --save_path your_save_path
    --doc_orientation_classify_model_dir your_doc_orientation_classify_model_dir \
    --doc_orientation_classify_model_name your_doc_orientation_classify_model_name

请参考PP-OCRv5 C++本地部署文档了解更多细节：

https://www.paddleocr.ai/latest/version3.x/deployment/cpp/cpp_local_deployment.html

高稳定性服务化部署方案开源

PaddleOCR 3.x提供了基础服务化部署和高稳定性服务化部署两种方案。相比基础方案，高稳定性方案具有以下优势：

通过资源隔离和调度队列机制，有效提升服务的稳定性和容错能力。
支持用户通过配置调整优化性能。例如，可通过多卡多实例部署提高服务的并发处理能力，从而最大化利用服务器的计算资源。

在PaddleOCR 3.0和3.1中，高稳定性服务化部署方案以预编译Docker镜像和SDK的形式提供，这种方式灵活性有限——用户难以根据自身需求对镜像或SDK进行二次开发。为了解决这一问题，PaddleOCR 3.2全面开源了完整的高稳定性服务化部署方案（包括推理镜像和SDK）。如下图所示，用户可根据文档说明，使用server_env部分的构建脚本生成不同类型的Docker镜像，使用sdk部分的打包脚本完成SDK封装，然后将两者组合使用，实现高稳定性服务化部署。

需要说明的是，此次开源的方案主要面向有二次开发需求的用户；对于希望直接使用预编译镜像和SDK的用户，我们后续仍将继续提供支持，无需用户自行编译。

请参考PaddleOCR服务化部署文档的“高稳定性服务化部署”部分了解更多细节：

https://www.paddleocr.ai/latest/version3.x/deployment/serving.html#2

支持细粒度性能Benchmark

在PaddleOCR 3.x中，产线通常由多个功能模块组合而成，并可能包含较为复杂的串联逻辑。例如，PP-OCRv5包含文本图像预处理子产线、文本检测模块、文本识别模块、文本行方向分类模块等组件，组件之间也并非简单串联。因此，相较于单个模块的性能分析，产线整体性能的评估更为复杂——无论是模型推理速度，还是模块间的串联效率，都会对产线的端到端推理表现产生影响。为此，PaddleOCR 3.2推出了推理Benchmark功能。该功能不仅支持对整个产线的端到端推理速度进行测量，还能提供逐层级、逐模块的详细性能数据，帮助用户深入分析产线推理过程中各环节的耗时情况。

具体而言，PaddleOCR通过benchmark接口提供的数个API，实现耗时统计和信息汇总。示例如下：

from paddleocr import PaddleOCR, benchmark
pipeline = PaddleOCR()
image = "general_ocr_002.png"
benchmark.start_warmup() # warmup开始
for _ in range(50):
    pipeline.predict(image)
benchmark.stop_warmup() # warmup结束
for _ in range(100): # 开始正式测速
    pipeline.predict(image)
benchmark.print_pipeline_data()  # 打印汇总的benchmark数据
benchmark.save_pipeline_data("./benchmark") # 将benchmark数据保存至benchmark文件夹

运行上述脚本后，得到的输出结果如下（由于完整结果较长，仅展示部分内容）：

可以看出，产线中每个单功能模块，以及模块与产线中的关键方法执行时间均被详细记录。同时，在benchmark目录中存储有CSV格式的测量结果，便于后续编写脚本解析。用户可以基于这些数据精准地分析当前硬件上的模型方案性能瓶颈，进而有针对性地优化部署方案。

此外，在PaddleOCR 3.2的文档中，我们也补充了各类产线常用配置在Intel 6271C、Intel 8350C、M4、V100、T4、A100、A20、H20等主流硬件上的关键指标，包括平均单页推理耗时、CPU利用率、GPU利用率、CPU内存利用率和显存利用率等，便于用户在部署方案选择时参考。

更多细节请参见PaddleOCR产线使用教程：

https://www.paddleocr.ai/latest/version3.x/pipeline_usage/OCR.html

https://www.paddleocr.ai/latest/version3.x/pipeline_usage/PP-StructureV3.html

除了以上几个重要能力的升级之外，我们也根据用户的反馈，积极优化了PaddleOCR中一些细节，支持了部分其他重要能力：如支持Windows用户使用英伟达50系显卡；支持韩语、俄语、西班牙语等40+种语言的文档解析；PP-OCR系列模型支持返回文本行中单个文字的坐标；新增AIStudio、ModelScope模型下载源。此外，相关的文档也进行了优化，进一步提升了PaddleOCR的易用性。

,,,.

#PaddleOCR-VL-1.5

PaddleOCR-VL-1.5发布问鼎双榜，0.9B小钢炮攻克“曲面”文档！

2025年，PaddleOCR发布了多个文字识别和文档解析模型工具，已经被业界广泛用于大模型训练数据和应用数据构建。其中仅0.9B的多模态文档解析模型PaddleOCR-VL凭借优异的产业级效果，至今稳居OmniDocBench官方榜首。与此同时，我们也收集到各行业对于PaddleOCR-VL的大量使用反馈，秉承快速响应、持续进化的理念，我们对用户关心的效果问题做了重要升级，正式推出PaddleOCR-VL-1.5。

PaddleOCR-VL-1.5不仅以94.5%精度大幅刷新了评测集OmniDocBench v1.5，更创新性地支持了异形框定位，在扫描、倾斜、弯折、屏幕拍摄及复杂光照等真实场景中均表现优异。此外，模型还新增了印章识别与文本检测识别能力，关键指标持续领跑。

PaddleOCR-VL-1.5已上线PaddleOCR官网，用户可通过网页或API方式快速使用。同时PaddleOCR-VL-1.5代码和模型已开源至Github和HuggingFace，欢迎下载使用，并可通过飞桨训练推理套件PaddleFormers与FastDeploy实现高效微调与全场景部署。

PaddleOCR官网：

paddleocr.com

Github：

github.com/PaddlePaddle/PaddleOCR

HuggingFace：

huggingface.co/PaddlePaddle/PaddleOCR-VL-1.5

此外，PaddleOCR-VL-1.5已与昆仑芯、沐曦股份、天数、海光、昇腾、此芯科技、Intel、ARM、AMD等核心硬件厂商，以及百度智能云、国家超算互联网平台、硅基流动、九章智算云、魔搭社区、并行科技、Cherry Studio、Dify、Haystack、Novita AI 、PPIO、RAGFlow、Sophnet等平台伙伴持续集成，方便用户在不同硬件环境与平台应用中使用。

< 1 效果速览 >

1. 扫描场景

上下滑动查看更多

2.倾斜场景

上下滑动查看更多

3. 光线变化场景

上下滑动查看更多

4. 屏幕拍照场景

上下滑动查看更多

5. 弯折场景

上下滑动查看更多

< 2 核心指标 >

1. OmniDocBench v1.5指标

总指标94.5%，领跑全球顶尖开源闭源模型。

2. Real5-OmniDocBench指标

Real5-OmniDocBench是我们基于OmniDocBench v1.5自建的多场景文档解析评估集合，涵盖了扫描、弯折、屏幕拍照、光线变化、倾斜5大场景，PaddleOCR-VL-1.5总指标92.05%，全面领先，总指标领先第二名Gemini3 Pro近3个百分点。

< 3 核心升级点 >

1. 关键技术创新：创新性地支持异形框定位，多场景精度SOTA

技术的实用性往往在复杂环境下见真章。面对现实中因拍摄角度、纸张弯折或倾斜而形成的非矩形布局，传统的矩形框输出难以实现精准映射。为此，PaddleOCR-VL-1.5引入了多边形异型框定位技术。针对扫描、倾斜、光线变化、屏幕拍照、弯折五大典型挑战场景，模型能够更加细腻地贴合文本、表格与公式的实际轮廓，提供更高质量的位置输出，能够稳定服务于多样化的实际业务环境。这项能力助力了PaddleOCR-VL在多种真实场景的的精度实现SOTA性能。

上下滑动查看更多

2. 落地关键能力升级：新增文本行定位/识别与印章识别能力

在基础能力的持续打磨下，PaddleOCR-VL-1.5进一步新增了文本行定位与识别及印章识别两项核心能力。文档的结构化解析往往始于对文本行逻辑的精准捕捉，其坐标精度与内容质量是诸多行业下游应用链路中不可或缺的底层支撑。而针对业界普遍面临的印章识别难题，新版本通过专项优化，有效缓解了复杂干扰下的解析瓶颈，旨在为各领域文档处理的规模化落地扫清关键障碍。

文本行定位、识别能力

印章识别能力

3. 特殊场景及多语种识别能力精进

文档解析的广度则体现于对长尾场景的支持。针对特殊符号、古籍、多语种表格及带有下划线、复选框的复杂版面，PaddleOCR-VL-1.5进行了针对性的算法精进，使细微长尾元素的识别更具鲁棒性。同时，模型进一步扩展了语种支持边界，实现了对藏语与孟加拉语的解析。

特殊字符

特殊场景

多语种表格

4. 跨页表格自动合并与跨页段落标题识别支持

长文档的逻辑重构，核心在于消除物理分页带来的信息割裂。PaddleOCR-VL-1.5引入了跨页表格自动合并与跨页段落标题识别能力，旨在重建文档在空间跨度上的语义连贯性。通过精准识别并关联因分页而截断的表格与标题，模型有效解决了长篇幅解析中的断层现象。这种对文档全局结构的深度感知，不仅提升了信息的完整度，也为后续的语义理解与检索提供了更具逻辑一致性的数据支撑。

跨页表格合并

5. 推理速度持续提升

推理速度是企业部署模型时尤为关注的关键指标。依托于飞桨框架与FastDeploy端到端的深度优化，PaddleOCR-VL-1.5推理速度显著提升。在A100上以PDF文件进行测试时，模型每秒可处理1.43个文档页，较上一代PaddleOCR-VL提速17%，也明显优于业界同类文档解析模型。

....

三、CV+OCR~弧形文字识别

主要介绍基于OpenCV+OCR实现弧形文字识别。

背景介绍

测试图如下，目标是正确识别图中的字符。图片来源：

https://www.51halcon.com/forum.php?mod=viewthread&tid=6712

同样，论坛中已经给出了Halcon实现代码，实现效果如下：

这个例子与以前介绍的环形文字识别类似，具体可参考下面链接：

实战 | OpenCV+OCR实现环形文字识别实例(详细步骤 + 代码)

二者的区别就在于一张包含完整的圆，另一张只有部分圆弧，下面给出详细实现步骤。

实现步骤

【1】扩充图像。由于这里的只有部分圆弧，为方便后续检测圆和ROI截取，我们先将原图扩大：

img = cv2.imread("./1.png")
cv2.imshow("src",img)


new_img = np.zeros((img.shape[0]*3,img.shape[1]*3,3),np.uint8)
new_img[new_img.shape[0]//3:new_img.shape[0]//3+img.shape[0],new_img.shape[1]//3:new_img.shape[1]//3+img.shape[1]] = img
cv2.imshow('new_img',new_img)

【2】检测圆。将扩充后的图像转为灰度图，然后滤波，使用霍夫变换检测圆，结果如下：

gray = cv2.cvtColor(new_img,cv2.COLOR_BGR2GRAY)
gray = cv2.medianBlur(gray,3)
circles = cv2.HoughCircles(gray,cv2.HOUGH_GRADIENT,1,100,\
         param1=200,param2=30,minRadius=300,maxRadius=400)

【3】极坐标变换。以检测到的圆心和半径做极坐标变换。

ROI = new_img[y:y+h,x:x+w].copy()
cv2.imshow('ROI',ROI)
cv2.imwrite('ROI.jpg',ROI)
trans_center = (int(center[0]-x), int(center[1]-y))
polarImg = cv2.warpPolar(ROI,(300,600),trans_center,radius,cv2.INTER_LINEAR + cv2.WARP_POLAR_LINEAR)
polarImg = cv2.transpose(polarImg)
polarImg = cv2.flip(polarImg,0)
cv2.imshow('polarImg',polarImg)

【4】使用OCR做字符识别。这里使用EasyOCR或者PaddleOCR均可：

result = reader.readtext(polarImg)
  res = None
  print(result)
if len(result) > 0:
for i in range(0,len(result)):
      print(result[i][1])
if(result[i][2] < 0.2):
continue
      print('---------------1--------------')
for j in range(4):
if j > 0:
          cv2.line(polarImg,(tuple(result[i][0][j-1])),(tuple(result[i][0][j])),(0,255,0),2,cv2.LINE_AA)
      cv2.line(polarImg,(tuple(result[i][0][0])),(tuple(result[i][0][3])),(0,255,0),2,cv2.LINE_AA)  
      strText = result[i][1].replace(' ','')
      cv2.putText(polarImg,strText,(result[i][0][3][0],result[i][0][3][1]+20),0,1.1,(0,0,255),2)

【5】反极坐标变换。通过反极坐标变换，将识别结果映射到原始图像。

polarImg_Inv = cv2.warpPolar(polarImg,(w,h),trans_center,radius,cv2.INTER_LINEAR + \
                            cv2.WARP_POLAR_LINEAR + cv2.WARP_INVERSE_MAP)
    cv2.imshow('polarImg_Inv',polarImg_Inv)

【6】截取ROI，得到最终结果。

ROI = new_img[y:y+h,x:x+w]
for i inrange(0,ROI.shape[0]):
for j inrange(0, ROI.shape[1]):
if mask[i,j] > 0:
                ROI[i,j] = polarImg_Inv[i,j]


#cv2.imshow('ROI',ROI)
    res = new_img[new_img.shape[0]//3:new_img.shape[0]//3+img.shape[0],new_img.shape[1]//3:new_img.shape[1]//3+img.shape[1]]

,,,.

四、MonkeyOCR

华科开源高效文档解析模型，精度超越闭源大模型、速度还更快！

最近华中科技大学主导开源的一款文档解析模型引起了业界关注，相比以往模型提高了在公开数据集上的识别精度、提高了速度，其模型参数量为3B，可在单机单卡（3090）上部署，非常值得关注。

MonkeyOCR 作者来自华科和金山

文章：https://arxiv.org/abs/2506.05218
代码：https://github.com/Yuliang-Liu/MonkeyOCR
体验：http://vlrlabmonkey.xyz:7685/

Github 仓库已经斩获2.5K星标

MonkeyOCR 论文的比较对象是专业从事文档解析的开源工具 MinerU 和开源甚至闭源的商业大模型。

在OmniDocBench数据集与其他SOTA技术的比较结果

从上图可知，MonkeyOCR 整体上精度提升明显，且推理速度更快！

MonkeyOCR 的设计哲学

论文中认为文档解析的两条主流路径各有自己的问题。

基于管线的方法（Pipeline-based）将文档解析任务拆解为多个小任务，能够针对每个任务进行优化，但容易受到错误累积的影响。比如常拆解的任务流程：布局识别、区域分割、文本识别、表格识别、公式识别、结构重组，每个任务使用独立模型，这种设计哲学累积早期阶段的错误，后面任务的的模型再强也无法弥补。

Pipeline-based 方法错误累积示例

另一种端到端大模型的方法，不考虑文档的结构和任务分解，让模型直接从文档推断出结构化结果，计算量上的挑战很大。

MonkeyOCR 则是一种居中的设计，Structure-Recognition-Relation (SRR)三元组方式：文档以目标检测（使用的YOLO）的形式被切分为块（Structure），每一块输入到端到端的大模型中进行识别（Recognition）（分块后会使得LLM推理计算量大大下降），然后结合文档结构和识别到的具体内容来预测多个块内容之间的关系（Relation）。

问题关键：数据集的构建

以上 MonkeyOCR 论文中提出的 Structure-Recognition-Relation (SRR) 三元组方法并不难理解，但要实现有效的模型训练，需要有标注的大量的数据，实际上论文在此处的介绍颇多。

作者构建了一个大规模文档解析数据集 MonkeyDoc，下表展示了其与其他常见数据集的对比：

MonkeyDoc 数据集与其他文档解析数据集比较

下图展示了数据的文档类型（PPT、笔记、杂志、试卷等）、结构分块示例（表格、图像、文本、公式等）。

MonkeyDoc 包含的标注数据样例和合成数据样例

数据集的生成，充分利用了开源数据集、可解析的PDF文档、数据合成方法、专家大模型的自动标注结果。

MonkeyDoc 数据集生成的三大核心阶段

（没有仔细确认）粗略计算，作者构建了上百万有标注的训练数据。

实现与结果

下图展示了 MonkeyOCR 文档解析的过程，实际实现中使用针对文档结构识别的 DocLayout-YOLO做结构检测，在 32 个 A800 显卡训练 53 个小时。

MonkeyOCR 整个过程

实验结果显示，MonkeyOCR 与同样开源的专用模型MinerU、开源的多模态大模型Qwen2.5-VL、闭源的大模型GPT4o相比，整体上取得了更好的结果，尤其在中文内容的识别上的领先似乎更明显。

在 OmniDocBench 数据集上不同任务上的对比结果

在 OmniDocBench 数据集上跨9种PDF页面类型比较结果

实际测试

作者提供了可直接体验的 demo：http://vlrlabmonkey.xyz:7685/ ，大家可以试玩一下。

因为之前做过一点药方识别工作，我顺手在百度下载了一张图片测试，并把结果和 MinerU 进行了比较：

MinerU 客户端测试结果

MonkeyOCR 官网测试结果

从这一张图看，MonkeyOCR 的结构检测这块还是蛮好的，因为识别出药方中间部分是表格，所以最终结果也是以表格展示，不过遗憾的是“茯苓”的茯识别错了。

另外，在试用这个demo网站的时候，多次发现图片文件上传和解析时系统提示error的情况，貌似网站对于分辨率大的图片处理有bug，如果大家测试最好不要图片太大。

总之，对于从事文档解析方向研究和工程的同学来说，MonkeyOCR 都是一个值得尝试的选项。

,,,.

五、OCR-Reasoning

OCR场景推理评测迎来重大革新！系统性推理基准发布

导读：

在多模态大模型（MLLMs）飞速发展的浪潮中，数学推理（如MathVista、MathVerse、MathVision）和学科知识推理（如MMMU）已有成熟的评测标尺。然而，当我们面对购买决策、财报解读、票据分析、路线规划等依赖复杂图文信息的真实OCR场景时，模型所需的深度推理能力却长期缺乏系统性的评估标准！这一关键空白，现在被正式填补！ OCR-Reasoning基准应运而生，为衡量模型在真实OCR场景下的综合推理能力，提供了一把至关重要的标尺。

资源获取

论文名称：OCR-Reasoning Benchmark: Unveiling the True Capabilities of MLLMs in Complex Text-Rich Image Reasoning
📄 论文地址： https://arxiv.org/pdf/2505.17163
💻 代码仓库： https://github.com/SCUT-DLVCLab/OCR-Reasoning
🔗 项目主页： https://ocr-reasoning.github.io/

一、现有OCR基准的瓶颈

当前主流的OCR相关评测基准，如DocVQA、TextVQA、InfographicVQA、OCRBench等，其核心聚焦点在于信息抽取任务（如识别实体、提取键值对）。这类任务往往依赖模型的“快思考”（Fast Thinking）能力即可完成，却难以有效评估模型在以下需要“慢思考”（Slow Thinking）的复杂场景中的表现：

📍 空间关系理解：文字的空间布局、元素间的方位关联如何？
🧮 数值计算与分析：表格数据如何运算？图表趋势怎样解读？
🧠 逻辑推理与批判性思维：如何基于图文信息，通过演绎或归纳得出可靠结论？
📚 多学科知识应用：如何解答手写的物理、化学题目？

二、OCR-Reasoning基准🚀 OCR-Reasoning基准：全方位定义六大核心推理能力

为了系统、深入地评估OCR场景下的模型推理能力，研究者们精心打造了OCR-Reasoning基准，其核心亮点令人瞩目：

📊 高质量数据集： 包含1069道手工精心标注的题目和1022张真实场景图片。标注流程严谨：图片获取后，标注人员设计针对性问题；随后，双路径并行标注推理过程与答案——一路由Gemini-2.0-flash生成，另一路由人工标注；之后由另一组标注人员进行质量评分，择优保留；最终还需进行人工复查与纠错。题目最终由三名标注人员独立归类至六大类别，并以多数共识确定最终类别，确保数据质量与分类可靠性。

🧩 六大推理能力全覆盖：

📍 空间推理： 理解文本与视觉元素间的空间关系，解析图文混排布局。
🧮 数值分析： 计算数值变化，应用于成本效益决策、增长率估算、财报分析、日程规划、数据解读等。
🔢 枚举推理： 计数满足特定条件的图文元素。
📐 数学推理： 运用数学知识解决图文中的数学问题（函数图像、几何、统计等）。关键提升：大多题目由标注人员手抄获取，极大提升OCR场景贴合度！
🧠 逻辑推理： 运用批判性思维，基于图文信息进行推论得出结论。
⚗️ 多学科知识推理： 应用物理、化学等跨学科知识解释图文内容（多为手写题目）。

🔍 强推理导向：核心差异显著！

现有OCR基准答案多直接复制图像原文。
OCR-Reasoning答案极少（仅2.3%） 能直接从原文提取，强制要求模型进行深度推理！

典型案例对比

现有基准： “发票中的总金额是多少？” 👉 答案直接读取文本即可。
OCR-Reasoning： “根据促销海报计算满3件打折后最低单价” 👉 需整合价格、折扣规则、商品信息，进行推理计算！

三、模型现状与关键发现

研究团队对主流开源与闭源模型进行了全面评测，包括：

闭源模型：DouBao-1.5-Vision-Pro, O1, Claude-3.7；
开源模型：Qwen2.5-VL, Llama4-Scout, InternVL3, Kimi-VL-Thinking等；
LLM+OCR方法：OCR识别结果+LLM（O3-mini和DeepSeek-R1）。

实验的结果如下表所示：

评测揭示三大关键现象

👁️ 视觉信息是OCR推理的命脉！

使用相同语言模型(Qwen2.5-32B)：纯文本模型(DeepSeek-R1-Distill-Qwen-32B+OCR)准确率仅26.5%，而多模态模型(Qwen2.5-VL-32B)达到36.2%，差距高达9.7个百分点！图像输入不可或缺！

🤖 现有RL训练的开源模型在OCR推理上仍需优化！

VLAA-Thinker-Qwen2.5VL-7B 和 MM-Eureka-Qwen-7B 等基于Qwen2.5-VL-7B进行RL训练后，数学与逻辑推理提升，但空间推理和数值分析能力却下降。设计适用于OCR推理的RL算法是未来关键方向！

🚧 现有技术天花板显著，挑战巨大！

顶尖闭源模型如豆包-1.5-Vision-Pro在传统OCR理解任务(DocVQA: 96.7%, InfoVQA: 89.3%, ChartQA: 87.4%)表现优异，但在OCR-Reasoning的文本丰富图像推理准确率仍不足50% (仅46.8%)。O1 (44.4%) 和 Gemini-2.0-flash (39.3%) 同样面临挑战。这凸显了同步处理视觉文本、语义内容和复杂逻辑推理的独特难度。

💡 CoT对模型性能的影响

论文同时也测试了CoT对模型性能的影响，结果如下表所示。

对于大部分模型，思维链提示能持续提升其性能。比如，思维链提示分别使Qwen2.5-VL-32B的性能提升3.2%，GPT-4o提升4.2%。然而，在VL-Rethinker-7B模型上，思维链提示通常会导致性能下降。这一现象可能源于VL-Rethinker-7B内置的强制性反思机制。在推理阶段额外添加思维链提示会打破训练与测试条件的一致性，导致性能退化。

💡 CoT对模型的推理路径进行评估

论文对闭源的多模态大模型的推理路径也进行了评估（论文采用了LLM as Judges的方式来对推理路径进行评估），结果如下表所示。

推理路径得分的排名与基于最终答案准确性的排名相似，除了Gemini和Claude-3.7-Sonnet这两个模型。具体而言，Gemini-2.0-Flash和Claude-3.7-Sonnet的高分主要归因于其比较高质量的推理过程。下面通过一个例子来说明这一点。如下图所示，Gemini-2.0-Flash推理过程中出现的微小错误导致了最终答案错误，但整体推理过程仍基本合理。因此，大语言模型（LLM）对其问题推理路径仍然给予了相对较高的评分。

四、便捷使用：集成开源评估工具

为方便社区使用，OCR-Reasoning 评测代码已集成至 VLMevalkit 工具包，支持研究者一键进行评估，极大提升效率。

结语：

OCR-Reasoning 基准的发布，成功填补了OCR场景下复杂深度推理能力评估的长期空白！它不仅为多模态推理模型的研发与优化提供了至关重要的评测依据和方向指引，其揭示的模型现状更清晰地表明：OCR场景下的复杂推理，仍是充满挑战的研究课题。

,,,.

六、贝叶斯分类器在OCR中的应用

从早期的邮政编码识别到如今无处不在的文字提取，光学字符识别（Optical Character Recognition，OCR）有着广泛的应用。OCR分文本检测和文本识别两个步骤，即首先定位文本，然后再进行识别。

在工业图像处理领域，OCR有其自身的一些特点：

(1) 字符以印刷体为主，一致性好。

(2) 需要识别的字符数量较少，比如产品的序列号之类的。

(3) 所能提供的标准字符图像不多，有时甚至只有一幅图像。

(4) 文本位置固定。

(5) 用于字符识别的计算机配置一般。

近年来，以深度学习为代表的算法在OCR应用中取得了惊人的成就，各种环境下的字符识别率极高。但深度学习算法需要大量训练数据以及高性能计算机，因此并不适合大多数工业OCR场景。另外，由于工业OCR中的文本位置固定，因此我们不讨论文本检测算法，感兴趣的读者可以参考[Tian, 2016]，文中提出了一种名为CTPN（Connectionist Text Proposal Network）的文本检测模型，文本定位效果很好。

在只有很少标准字符图像，并且识别的字符不多的情况下，用图像匹配算法即可。除此之外，大部分工业OCR应用可采用贝叶斯分类器、SVM等算法。本文讨论的内容包括应用传统图像处理技术对字符进行分割、提取特征以及用贝叶斯分类器对字符进行分类。

字符分割

用贝叶斯分类器等机器学习算法进行字符识别的第一步就是将文本分割成单个字符。在字符分割前，对于图1和图2这类图像，需要通过投影变换和极坐标变换将文本变换成矩形排列。对于大部分字符分割，采用分割技术已经足够了，但是对于粘连字符需要采用针对性技术。如图3所示，图3(a)是MingLiU-ExtB字体的文本，两个字符呈粘连状态。对于这类的粘连字符，首选的方案就是用开或闭运算对其进行分割，这里采用3×11结构元进行闭运算（前景为白色），结果如图3(b)所示。之所以采用细长结构元，是为了防止在分割时造成字符在水平方向断开。此外，我们还可以将二维图像的像素灰度值投影到一维的水平轴上，即行剖面，然后根据波峰或波谷确定粘连位置。图3(c)为图3(a)行剖面，可以看到，在水平坐标126附近有一波峰，对应的就是粘连位置。

图1.投影变换应用

图2.CD 和极坐标变换的结果

图3.MingLiU-ExtB字体的文本（尺寸252×198像素） (b)用3×11结构元对二值化后的图a进行闭运算的结果；(c)图a的行剖面

但是，上述的形态学方法并不总有效。如图4所示，图4(a)为字符粘连的图像，图4(b)是对二值化后的图4(a)进行开运算的结果，由于图4(a)与图3(a)的前景相反，所以用了相反的形态学算法。从图中可以看到，除了“C”和“8”，“1”和“A”外，其他粘连字符并未分开。对于这类重度粘连的字符，如果是等宽字符，可以在确定了首字符的位置后，根据字符宽度进行分割。对于非等宽字符，如果不同宽度字符出现的位置是确定的，也可以根据字符宽度进行分割。

图4.(a)字符粘连的图像；(b)用5×9结构元对二值化后的图(a)进行开运算的结果

另外，对于诸如“i”、“j”或点阵之类的字符，在分割前需要进行膨胀或腐蚀处理，以使单个字符连接到一起。如图5所示，图5(a)是产品包装上常见的点阵字符串，图5(b)是对图5(a)二值化后再腐蚀的结果。经过这样的处理，单个字符都连接起来了，不会出现一个字符分割成几部分的情况。

图5.(a)点阵字符；(b)对图(a)二值化后腐蚀的结果（结构元9×9）；(c)对图(b)膨胀的结果（结构元3×3）；(d)图(a)叠加图(c)的区域分析结果

对字符分割完毕后，需要通过区域分析，在图像上确定包含字符的外框。一般来说，我们希望外框与字符之间有一两个像素的间隙。我们以图5为例对此进行讨论。由于进行了腐蚀运算，如果直接提取图5(b)中的字符的外框，尺寸会过大。所以首先对图5(b)进行膨胀运算，如图5(c)所示。然后再提取外框，叠加到原图后的效果如图5(d)所示，外框与字符之间有一定的间隙。如果分割中没有进行形态学操作，可以在提取外框前做一次3×3的腐蚀运算（假设字符为黑色），以保证字符与外框之间有一个像素的间隙。

特征提取

字符分割完毕后，接下来就是特征提取。可以将多种图像信息作为样本的特征：灰度值、梯度、二值图像、行剖面、列剖面、高宽比、高度、宽度等，其中高宽比等为单一特征，一般与灰度值等组合使用，以提高对字符的分辨能力。

如图6所示，图6(a)是分割出来的字符。如图直接用图6(a)的像素灰度值序列作为特征，则样本的维数为36×45=1620，维数过高，需要降维。此外，分割出来的字符尺寸不一，造成样本维数不同。因此，提取特征之前需要对字符进行缩放，对于工业应用来说，将字符缩放到8×10比较恰当[Steger, 2019]。如果在应用中只有很少的字符类型，比如只有数字，则可以使用更小一点的尺寸；如果包含较多的字符类型，比如数字、大写字母和小写字母，则可使用更大的尺寸，比如10×12。将图6(a)缩放8×10后，如图6(b)所示，这时样本维数为80。缩放建议采用双线性插值法，可以同时兼顾效率和质量。

图6.提取灰度值特征

(a)深色字符“9”（尺寸36×45）；(b)将图(a)缩放到8×10；(c)对图(a)归一化后再缩放到8×10（去掉直方图两端5%的像素后的灰度值作为归一化最值。归一化后的浮点数图像映射到[0, 255]）；(d)浅色字符“9”；(e)将图(d)缩放到8×10；(f)对图(d)归一化后再缩放到8×10

但是这样直接缩放是有问题的。图6(d)是光照发生变化的字符“9”图像，图像亮度更高，缩放到8×10后的图像如图6(e)所示。图6(b)与图6(e)灰度值差异较大，这样会造成后续的分类很困难。解决这个问题的方法就是在缩放前对灰度值进行归一化处理。归一化可以理解为一种灰度拉伸，是将图像的动态范围[r1，r2]映射到[0,1]，即

公式1

式中，s为输出灰度值，r为输入灰度值。为了降低噪声的影响，我们不建议r1和r2取图像的灰度最小值和最大值，而是取去掉直方图两端一定比例的像素后的灰度最值。灰度值归一化后再缩放到8×10的字符如图6(c)和6(f)所示，这时二者的灰度值基本一致。

由于我们是将分割得到的包含字符外接矩形的图像缩放到一个标准尺寸，那么对于有些字体中的个别字符，比如等线字体中的“I”和“-”，就不能分辨开，因为缩放后的图像是一样的。解决这个问题的方法就是额外增加一个特征，将分割得到的字符外接矩形的高宽比作为一个特征。这样，对于8×10的字符来说，样本维数就是81。

由于梯度对光照变化不敏感，因此梯度也是一种常用的特征。与构造SIFT关键点描述符类似，首先将图像缩放到一个标准尺寸，例如35×35，然后再将图像细分为5×5个子区域，每个子区域尺寸为7×7。最后计算每个像素点的梯度并离散到间隔45°的8个方向，共构成200个梯度特征[Liu, 2004][Steger, 2019]。

字符分类

我们使用正态贝叶斯分类器作为OCR分类器。在对字符分割以及特征提取后就得到了样本集，用分类器进行训练和测试即可。下面通过一个例子来讲述OCR的完整过程。

例.用正态贝叶斯分类器进行OCR及异常检测

如图7示，图7(a)是包含训练字符的原图，数字0~9，共10行，每行20个字符。图7(b)是用自动阈值对图7(a)分割后再腐蚀的结果。图7(c)是区域分析后得到的包含字符的矩形框。提取每个字符的特征并生成样本后，还需要标记每个样本。如果矩形框的排列顺序未知，那么可以用细长结构元对图7(b)进行腐蚀，结果如图7(d)所示，通过区域分析得到包含每行字符的矩形框。对于图7(c)中那些矩形框中心落入图7(d)同一矩形框内的字符做相同的标记。对样本标记后，就可用分类器进行训练了。

图7.字符分割及特征提取

(a)包含训练字符的原图（尺寸871×730像素）；(b)对图(a)二值化后再腐蚀（自动阈值，5×5八边形结构元）；(c)对图(b)区域分析后得到的包含字符的矩形框；(d)用35×1矩形结构元对图(b)腐蚀后再区域分析

训练完毕后即可进行字符分类。如图8所示，图8(a)是包含待识别字符的原图，其中有未训练字符“M”。如果直接分类，结果如图8(b)所示，“M”识别成了“7”。现在我们观察用式1计算的各字符的f（kk）的值，如表1所示。可以发现，“M”的值f（kk）要明显小于其他字符，因此我们用阈值，比如-26，进行异常检测，结果如图8(c)所示，“?”表示异常字符。

图8.用正态贝叶斯分类器进行字符识别

(a)包含待识别字符的原图；(b)不进行异常检测的识别结果；(c)进行异常检测的识别结果

表1.字符f（kk）值

,,,.

七、MonkeyOCR v1.5

MonkeyOCR v1.5技术报告发布：视觉一致性强化学习，解锁复杂模式下的稳健文档解析

大家好，今天想和大家聊一篇关于文档智能解析的新工作。现在的文档解析工具已经很棒，但各种头疼的复杂版式仍需改进，比如多级嵌套的表格、嵌入的图片或公式，甚至是跨页的长表格。这些都是现有OCR系统面前的硬骨头。

最近，来自金山办公和华中科技大学的研究团队联合发布了他们最新的技术报告，详细介绍了他们研发的MonkeyOCR v1.5。它在一个统一的视觉语言框架下，通过一个巧妙的两阶段流程，同时提升了版面理解和内容识别的准确性，在权威基准测试中取得了当前最佳性能。

一起来看看他们是如何做到的。

论文标题: MonkeyOCR v1.5 Technical Report: Unlocking Robust Document Parsing for Complex Patterns
作者团队: Jiarui Zhang, Yuliang Liu, Zijun Wu, Guosheng Pang 等
机构: 金山办公, 华中科技大学
论文地址: https://arxiv.org/pdf/2511.10390v1
相关代码仓库（开源版前代）: https://github.com/Yuliang-Liu/MonkeyOCR
Demo: https://aiwrite.wps.cn/pdf/parse/web/

MonkeyOCR v1.5的独特优势是对复杂表格的解析

两阶段解析流程：全局与局部的精妙平衡

为了兼顾全局的结构理解和局部的精细识别，MonkeyOCR v1.5 设计了一个两阶段的解析流程。这个设计思路很清晰，既要看得准，也要认得对。

第一阶段：版面分析与阅读顺序预测。研究者使用一个大型多模态模型（LMM）来同时预测文档的版面布局和阅读顺序。相比于之前依赖文本模型来推断顺序，v1.5直接利用视觉信息来保证结构和顺序的一致性。模型会输出每个元素（文本、表格、公式等）的边界框、类别和阅读顺序索引。
第二阶段：局部内容识别。在第一阶段确定了各个区域后，第二阶段就对每个区域进行“精加工”。每个被检测到的区域块（patch）会被裁剪出来，并根据其类型（文本、公式、表格）交由同一个VLM进行内容识别。最后，所有识别出的内容会根据第一阶段预测的阅读顺序重新组合，还原出完整的文档结构。

这种“先定位、再识别”的策略，有效地避免了传统端到-端模型在处理高分辨率文档时面临的巨大计算开销，也减少了多阶段流水线方法中常见的错误累积问题。

攻克复杂表格的三大“利器”

表格解析，尤其是复杂表格，一直是文档解析领域的难点。MonkeyOCR v1.5 针对性地提出了三个创新模块，极大地提升了模型处理复杂表格的能力。

视觉一致性强化学习

这是一个非常有趣的想法。为了让模型能更好地识别复杂表格，尤其是在缺少大量精细标注数据的情况下，团队引入了一种基于视觉一致性的强化学习方案。

它的核心思想是：让模型自己判断识别结果的好坏。具体来说，他们先训练了一个“奖励模型”，这个模型能够判断一次表格识别的结果（例如，生成的HTML代码）在被重新渲染成图片后，与原始的表格图片在视觉上是否一致。

然后，利用这个奖励模型作为“导师”，通过强化学习算法（GRPO）来优化主模型。主模型生成的识别结果如果渲染后与原图更“像”，就会得到更高的奖励。这样一来，模型就能在没有人工标注的情况下，从海量无标签数据中自我学习和进化，不断提升表格识别的准确性和鲁棒性。

图像解耦的表格解析

真实文档的表格里经常会嵌入图片，这对于大多数OCR系统来说是个灾难，很容易导致结构错乱或内容丢失。

MonkeyOCR v1.5 的策略非常巧妙，可以概括为“先分离，再识别，后重组”：

检测与替换：首先用一个目标检测模型（YOLOv10）找出表格中所有嵌入的图片，然后用一个大小精确的占位符（placeholder）替换掉它们。
识别：接着，对这个“干净”的、只剩下文本和框线的表格进行识别。模型被训练成能将占位符识别为一个特殊的<img>标签。
重组：最后，在后处理阶段，根据之前保存的映射关系，将<img>标签替换回原始的图片。

通过这种方式，模型可以将棘手的图片处理问题与表格结构识别任务解耦，从而互不干扰，保证了最终结果的完整性和准确性。

从对比中可以看到，其他方法要么丢失了图片，要么错误地识别了表格结构，而MonkeyOCR v1.5则完美地还原了表格和其中的图片。

类型引导的表格合并

长表格因为排版限制，常常被拆分到不同页面或不同栏中。如何将这些碎片“破镜重圆”，也是一大挑战。

研究者总结了三种常见的跨页/跨栏模式，并提出了针对性的合并策略：

模式一：表头完全重复。如果两个表格碎片的表头完全一样，就去掉第二个的表头，然后将内容直接拼接。
模式二：无表头连续。如果表头不同，但内容上是连续的，也直接拼接。
模式三：行分割连续。如果一个单元格被硬生生拆开，模型会先合并被拆分的单元格，再进行拼接。

为了区分这些模式，他们甚至用了一个小型的BERT分类器来判断两个表格碎片的语义连接关系，从而实现智能、准确的合并。

在处理跨页表格时，其他模型要么无法合并，要么错误地处理了空单元格的关系，而MonkeyOCR v1.5则能准确地还原整个表格的结构。

实验结果：性能全面领先

在权威的文档解析基准 OmniDocBench v1.5 上，MonkeyOCR v1.5 的表现非常亮眼。

从上表可以看到，MonkeyOCR v1.5 的综合得分达到了 92.9，超越了之前的SOTA模型 PPOCR-VL (91.9) 和 MinerU 2.5 (90.7)。值得注意的是，它也超过了像 Gemini 2.5-Pro 这样的通用闭源大模型，显示了领域专用模型在垂直任务上的巨大优势。

在更具挑战性的复杂表格识别任务上，它的优势更加明显。

在专门测试复杂表格的 OCRFlux-Complex 数据集上，MonkeyOCR v1.5 的性能达到了 90.9，相比于 MinerU2.5 (81.7) 和 PaddleOCR-VL (81.7)，实现了 超过9个百分点 的巨大提升。这充分证明了其针对性设计的有效性。

上图直观展示了MonkeyOCR v1.5在版面分析上的优势，它能准确识别出所有的图片和表格，而其他方法则容易将表格结构误判为独立的文本和图片。

总的来说，MonkeyOCR v1.5 通过一系列精巧而实用的设计，特别是在处理复杂表格方面，为文档智能领域贡献了一个非常强大的新工具。它不仅在学术基准上取得了领先，也为解决工业界真实、复杂的文档解析需求提供了可靠的方案（目前在文中没有看到开源信息，可在Demo页面体验其能力）。

,,,.

八、POINTS-Reader

不蒸馏也超强？揭秘端到端文档OCR模型 POINTS-Reader

文档解析领域又一新进展——POINTS-Reader 模型。采用两阶段训练方案：第一阶段通过统一格式的合成数据预热，使模型掌握文档元素的结构化解析能力；第二阶段通过迭代式的自我提升，利用真实数据持续优化模型性能。目前，该模型在 OmniDocBench 基准测试上取得了领先优势，并已开源。

目前论文已经被 EMNLP 2025 主会录取，同时模型已经开源

论文: https://huggingface.co/papers/2509.01215

Github: https://github.com/Tencent/POINTS-Reader

HuggingFace: https://huggingface.co/tencent/POINTS-Reader

Demo: https://huggingface.co/spaces/prithivMLmods/POINTS-Reader-OCR

在论文投稿后，我们利用文章中提出的方法持续对模型进行优化，当前在 OmniDocBench 上取得了领先的优势。

01 介绍

在当今的信息社会，PDF文档是互联网信息传播的重要形式。然而，如何有效地将这些文档内容转换为便于使用的格式一直是一个挑战。这些PDF文档常常蕴含丰富的信息，同时格式也多种多样，包括正文、数学公式和表格等。现有的文档提取方法主要可以分为三类：

传统解析方案：工具如PyMuPDF在解析过程中可能无法准确保留复杂结构，例如数学公式的精确特征，这常导致提取出的文本伴有大量的噪声。
pipeline 方案：例如MinerU和Mathpix，这些方法通过集成多个专有模型，可以取得较好的效果。然而，最终的提取效果受限于单个模型的表现，而且优化起来较为繁琐。
端到端方案：端到端方案为文档信息提取提供了一条简洁、高效的路径，它通过直接优化视觉-语言模型来完成任务。然而，这一方案的成败严重依赖于训练数据的质量和规模，而这恰恰是其最大的瓶颈。目前，数据获取方式存在一个两难困境：要么选择成本高昂且难以扩展的人工标注，要么依赖于从现有模型采集数据，但这又面临着继承其原有偏见（bias）的风险。

在端到端方案中，POINTS-Reader提出了一套高度可扩展的数据生成方案，包含两个核心阶段：统一格式预热阶段(Uniform Format Warm-up Stage)和迭代自我改进阶段(Iterative Self-improvement Stage)。这种方法不仅提升了文档提取的效率，还为后续优化提供了坚实的基础。

02 模型效果

话不多说，我们先来看看模型的提取效果:

单栏 + 数学公式

单栏 + 表格

双栏 + 数学公式

双栏 + 表格

03 模型特色

简洁性：POINTS-Reader 是一个非常精简的模型，它保持了与 POINTS1.5 相同的架构，唯一的改动是将 Qwen2.5-7B-Instruct 替换为了 Qwen2.5-3B-Instruct。此外，它的输入和输出都极其简单直接。输入由一个固定的提示（prompt）和一张文档图片组成，输出则是一个单一的字符串（即从文档图片中提取的文本）。模型的输出就是交付给用户的最终结果，无需任何后处理。
性能：POINTS-Reader 目前支持提取中文和英文两种文档，并取得了非常惊艳的效果，在 OmniDocBench 基准测试上，其英文得分为 0.133，中文得分为 0.212。
高吞吐量：在当前主流的推理框架（如 SGLang 和 vLLM）中，优化主要集中在大型语言模型（LLM）上。因此，一个大的 ViT（视觉 Transformer）可能会成为一个显著的吞吐量瓶颈，这也是我们选择一个中等规模 ViT（POINTS1.5 中使用的 6 亿参数的 NaViT）的原因。结合我们对 SGLang 的原生支持，我们目前实现了非常高的吞吐量。未来我们也将增加对 vLLM 的支持。
开源技术方案：在 POINTS-Reader 的论文中，我们提出了一种两阶段的数据增强策略。第一阶段利用自动生成的数据，为模型赋予基础的文档提取能力。在随后的阶段，通过一个持续的自我演进过程来提升模型生成数据的质量。这种第二阶段的自我演进方法具有高度的可扩展性，几乎可以应用于任何模型。

04 方法

当前，多数端到端模型的训练依赖于私有模型（如GPT-4o）的蒸馏数据。该方法主要面临两大挑战：一是继承教师模型的内在偏见（bias），二是自身迭代受限于外部模型的更新。为解决这些问题，我们提出一种完全不依赖蒸馏数据的两阶段训练方案。

第一阶段：统一格式预热阶段 (Uniform Format Warm-up Stage, UWS)

目标是为模型打下坚实的基础，使其能够处理各种文档元素。

统一输出格式：为了简化模型学习，论文为不同类型的文档元素定义了统一的输出格式：

纯文本：使用Markdown格式。
表格：使用HTML格式（能处理合并单元格等复杂结构）。
数学公式：使用LaTeX格式（行内公式用 $...$ ，行间公式用$$...$$）。

生成大规模合成数据：

使用一个大语言模型（LLM，如Qwen2.5-72B），根据特定的提示（Prompt）生成包含纯文本、含公式的文本、含表格的文本以及多栏布局文本的多样化内容。
对生成的公式和表格进行基于规则的过滤（如语法检查）。
将过滤后的内容使用HTML模板渲染成图像，并与原始文本配对，形成“图像-文本”对。

模型微调：使用这些大规模的、格式统一的合成数据对一个通用的视觉-语言模型（如POINTS-1.5）进行微调。这使模型具备了初步的、格式化的文档元素提取能力。

第二阶段：迭代式自我提升阶段 (Iterative Self-improvement Stage, ISS)

目标是将第一阶段在合成数据上训练的模型，自适应地迁移到真实世界文档上，并持续提升模型和数据质量。

模型标注：使用第一阶段训练好的模型去自动标注一个大规模的真实文档数据集（如DocMatix）。
数据过滤：对模型生成的标注结果应用一套精心设计的、基于规则的过滤策略，以自动验证和筛选高质量的数据：

纯文本过滤：计算模型输出与传统OCR（如PaddleOCR）结果的F1分数，仅保留分数高于阈值（如0.9）的样本，以减少遗漏、幻觉和重复。
表格过滤：检查表格结构的有效性，例如确保每行的单元格数量一致，以去除结构错误的表格。
公式过滤：检查LaTeX公式的语法是否正确，以去除语法错误的公式。

模型再训练：使用经过过滤的高质量真实数据，对模型进行重新训练。
迭代循环：将新训练的模型作为起点，重复执行“标注 -> 过滤 -> 再训练”的过程。通过多轮迭代，模型的转换能力不断提升，同时生成的伪标签数据质量也越来越高。

总结来说，该数据生成方案的核心创新在于：

● 无需蒸馏：完全避免了对昂贵或闭源的教师模型的依赖。

● 自动化闭环：通过“合成数据预热 + 真实数据自我提升”的两阶段设计，构建了一个自动化的数据-模型协同进化闭环。

● 规则化过滤：利用简单但有效的规则对模型自生成的数据进行质量控制，使得模型能在没有人工标注的情况下，利用真实世界数据持续进步。最终我们得到了 POINTS-Reader，在多个基准测试上达到了甚至超过了更大模型的性能。

05 实验

更强的性能

可以发现，POINTS-Reader 在 OmniDocBench 和 Fox 上都取得了不错的效果，甚至超越了一些私有模型和更大尺寸的模型

消融实验

为了让实验具有更高的可信度，我们对训练 POINTS-Reader 中的每一步进行了详细的消融，下面我们选取几个重点的实验进行展示:Uniform Format Warm-up 阶段，更好的数据多样性，更好的模型性能

从上表可以发现，当我们使用更丰富的元素和布局，模型的性能呈现出一个持续变好的趋势。Iterative Self-improvement 阶段，过滤的手段至关重要

可以发现，在这个阶段对模型生成的数据从各个维度进行过滤，例如表格、公式，可以显著提升数据的质量，从而提升模型的性能。

Iterative Self-improvement 阶段，随着迭代次数多增加，数据的质量和模型的性能也持续提升

从上图可以看出，随着迭代的进行，数据的质量在持续的提升（F1-score 不断增加），但是增长的数据变缓了。同时，随着数据质量的提升，训练得到的模型的性能也不断提升，可以从 OmniDocBench 上不断增长的性能可以看出来

除此之外，我们可以发现，随着迭代次数多增加，我们过滤得到的数据数量也是不断提高，也进一步说明数据质量的提升。

06 总结

本工作提出了一种全自动化的两阶段数据构建方案。第一阶段，通过统一格式的数据进行预训练，使模型初步掌握文档元素的结构化解析能力。第二阶段，我们引入“标注-过滤-再训练”的迭代循环，驱动模型性能的持续优化。最终，我们成功构建了一个性能卓越的端到端文档解析模型。该方案具有高度的可扩展性，可应用于任何模型高效生产训练数据，并通过自迭代机制实现性能的持续提升。

....

九、OCRBench v2

25年9月最新榜单发布！揭示多模态大模型文档智能真实水平

导读：现有多模态大模型（LMMs）在复杂多样的OCR任务中表现如何？华中科技大学白翔团队联合华南理工大学、阿德莱德大学和字节跳动联合推出新一代OCR评测基准OCRBench v2，并发布最新私有数据榜单（2025年9月）。

Seed1.6-vision、Qwen3-Omni-30B-A3B-Instruct和Gemini-2.5-Pro包揽了中英榜单前三名，但即便是这些最先进的模型，其平均分也仅勉强达到“60分”的及格线，这表明它们仍难以完全满足复杂多样的真实应用需求。

十、HunyuanOCR

OCR新晋顶流！腾讯混元开源1B级全能模型HunyuanOCR，效果惊艳

论文标题: HunyuanOCR Technical Report
作者团队: Hunyuan Vision Team
论文地址: https://arxiv.org/abs/2511.19575
HuggingFace: https://huggingface.co/tencent/HunyuanOCR
GitHub: https://github.com/Tencent-Hunyuan/HunyuanOCR

最近，来自腾讯混元视觉团队的研究者们发布了一份名为《HunyuanOCR技术报告》的重磅技术文档，介绍了一款商业级的开源轻量级视觉语言模型（Vision-Language Model, VLM）—— HunyuanOCR。

朋友们，OCR（光学字符识别）这个领域最近真是越来越卷了。传统的OCR技术，要么是专门处理特定任务的“偏科生”，要么就是依赖一套复杂的“流水线”作业，一个环节出错，后面全盘皆崩。后来，通用的视觉语言模型（VLM）虽然强大，但又大又慢，部署成本高，像“请了个全能保姆，结果发现只用来扫地”。

HunyuanOCR的出现，就像是试图打破这个僵局。它希望用一个轻量级（仅1B参数）的端到端模型，优雅地解决从文字识别、版面分析到信息提取、图像翻译等一系列OCR任务。

从官方给出的性能对比图就能直观感受到，HunyuanOCR在多个维度上都展现出了强大的竞争力。

告别“小模型”与“大而全”的困境

HunyuanOCR的核心思路是“在多功能与高效率之间取得平衡”。它不再满足于单一任务，而是将文字定位（Spotting）、版面解析（Parsing）、信息抽取（IE）、视觉问答（VQA）和文本翻译等多种核心能力集成到一个统一的框架下。

从上面这张多任务能力对比表中可以看到，相比于传统的PaddleOCR、仅支持部分功能的PP-ChatOCR，以及虽然功能全面但表现平平的通用VLM（如Gemini-2.5-Pro），HunyuanOCR在几乎所有任务上都达到了“支持且高性能”（用小太阳图标表示）的水平。

纯粹的端到端架构

HunyuanOCR的架构设计得相当漂亮，可以用“简约而不简单”来形容。它由三个核心部分组成：原生分辨率视觉编码器（Hunyuan-ViT）、自适应MLP连接器和一个轻量级语言模型（Hunyuan-0.5B）。

原生分辨率视觉编码器：这个编码器很聪明，它能处理任意分辨率的输入图像，而且不改变原始长宽比。对于那些又长又窄的文档图片，这种设计能避免图像被强行拉伸或压缩，从而保留了关键的文字细节。
自适应MLP连接器：它像一个高效的“翻译官”，负责将视觉编码器提取的视觉特征转换成语言模型能理解的格式。它能智能地压缩信息，丢掉冗余，同时保留文本密集区域的关键特征。
轻量级语言模型：基于Hunyuan-0.5B模型，它通过一种名为XD-RoPE的技术，原生建立了文本、高度、宽度和时间四个维度的对齐机制，让模型能更好地理解文本在图像中的空间位置。

这种纯粹的端到端（End-to-End）设计，最大的好处是摆脱了对布局分析等预处理模块的依赖。输入一张图片，直接输出最终结果，从根本上解决了传统流水线方法中常见的错误累积问题，也大大简化了部署流程。

数据驱动与强化学习的“双轮驱动”

模型性能的飞跃，离不开高质量数据和先进训练策略的加持。

精心构建的“数据食谱”

团队构建了一个覆盖超过130种语言、包含2亿图文对的庞大数据集。为了提升模型的泛化能力，他们不仅用了真实世界的图片，还开发了一套强大的数据合成与增强工具。

如上图所示，他们可以合成多语言文本（包括从右到左的书写顺序）、带有逼真褶皱和光影变化的文档图像，还能自动从已有的标注数据中生成新的问答和翻译数据，实现了数据的“一鱼多吃”。

四阶段预训练策略

为了让模型循序渐进地掌握各项技能，研究者设计了一个四阶段预训练流程：

第一阶段：视觉-语言对齐。冻结语言模型，只训练视觉编码器和连接器，让模型学会看图说话。
第二阶段：多模态预训练。放开所有参数进行端到端联调，增强对文档、表格等结构化内容的深层理解。
第三阶段：长上下文预训练。将模型的上下文窗口扩展到32K，专门“补习”长文档解析能力。
第四阶段：面向应用的SFT。使用高质量的人工标注真实数据进行微调，让模型更适应实际应用场景。

首次在OCR中引入强化学习

这可以说是HunyuanOCR最亮眼的创新之一。团队首次在业界证明了强化学习（Reinforcement Learning, RL）策略能显著提升OCR任务的性能。

对于文字定位、文档解析这类有明确答案的任务，他们使用可验证奖励的强化学习（RLVR）；对于翻译、问答这类开放性任务，则采用“LLM-as-a-judge”的方式，让一个更强的语言模型来当“裁判”打分。从训练动态图中可以看到，模型的平均奖励值在训练过程中稳步提升，证明模型确实“学进去了”。

“全能选手”的惊艳表现

HunyuanOCR在多个基准测试中都取得了优异的成绩，甚至超越了不少体量远大于它的模型和商业API。

文字定位（Spotting）

在一个包含艺术字、手写体、游戏截图等9大类场景的内部测试集上，HunyuanOCR的综合表现远超传统方法和其他通用VLM。

版面解析（Parsing）

在权威的文档解析基准OmniDocBench、更具挑战的实拍版Wild-OmniDocBench以及自研的多语言数据集DocML上，HunyuanOCR均取得了最佳性能，全面领先于其他专用模型和通用大模型。

信息抽取（IE）与视觉问答（VQA）

在包含30种常见卡证票据的信息抽取任务上，HunyuanOCR的准确率达到了惊人的92%+，显著优于Qwen3-VL-235B和Gemini-2.5-Pro等超大模型。在公开的OCRBench上，其表现也与更大规模的模型相当。

文本图像翻译

在文档翻译数据集DoTA上，这个仅1B参数的模型，翻译效果甚至超过了8B参数的Qwen3-VL。凭借出色的表现，HunyuanOCR还在ICDAR 2025 DIMT挑战赛的小模型赛道中夺得第一名。

总结

总而言之，HunyuanOCR的出现，确实为OCR领域带来了一股清新的风。它证明了通过精巧的架构设计、高质量的数据策略以及创新的强化学习方法，一个轻量级的模型完全有能力应对复杂多样的OCR任务，并且在性能和效率上取得SOTA级别的成果。

,,,.

十一、EasyOCR~条码字符识别

EasyOCR是一个Python 软件包，用于从照片或扫描文档等图像中检测和提取文本。它带有预先训练的模型，旨在快速高效地进行文本识别，并支持 80 多种语言。

在本文中，我们将探讨如何使用 EasyOCR 包从图像中检测和提取文本。让我们开始吧！

EasyOCR 如何工作

EasyOCR 内部的文本识别过程主要包括三个步骤：特征提取、序列标记和解码。

ResNet和VGG（视觉几何组）等 eep 学习模型从图像中提取关键特征，LSTM（长短期记忆）网络处理序列上下文，CTC（联结时间分类）算法将这些标记序列转换为可读文本。

如何使用 EasyOCR 从图像中提取文本

现在我们已经了解了什么是 EasyOCR 以及它的一些用例，接下来，我们将探索一个编码示例，展示如何使用 EasyOCR 从图像中提取文本。

步骤＃1：安装

首先，安装所有必需的库。我们将使用“pip”包安装程序安装 PyTorch 库（核心依赖项）和 EasyOCR 库。打开命令提示符或终端并运行以下命令开始安装。

pip install torch torchvision torchaudio easyocr

步骤2：初始化阅读器

安装依赖项后，我们可以导入 EasyOCR 包并初始化其“阅读器”功能。我们还可以选择要检测和提取的语言。有超过 80 种语言可供选择。在这个例子中，我们选择英语为“en”。

import easyocr
reader = easyocr.Reader(['en'])

在“reader”函数中，我们还可以管理系统规格设置，例如启用或禁用 GPU 或选择自定义目录来存储 EasyOCR 模型。对于 EasyOCR 库，建议使用 GPU 来加快处理速度，但也可以禁用它以在 CPU 上工作。要禁用 GPU 设置（默认情况下设置为“True”）：

reader = easyocr.Reader(['en'],gpu=False)

选择自定义目录来存储模型：

reader = easyocr.Reader(['en'],model_storage_directory='path/to/directory'
)

步骤3：在图像上运行EasyOCR

一旦初始化了阅读器函数，模型就会自动下载（如果选择，则下载到自定义目录）。接下来，我们可以初始化“readtext”函数并将输入图像的路径传递给它。

在此示例中，我们将使用包含产品序列号和零件号的图像作为输入。您也可以使用同一图像或任何其他相关图像。

当我们打印出结果时，它将包括图像内检测到的文本的边界框坐标、检测到的文本和置信度分数。

以下是我们输入图像返回的输出：

[([[28, 22], [353, 22], [353, 72], [28, 72]], 'SERIAL NUMBER', 0.8874381662616708), ([[35, 75], [397, 75], [397, 137], [35, 137]], 'AOC1715821', 0.8521895819573561), ([[39, 255], [315, 255], [315, 299], [39, 299]], 'PART NUMBER', 0.9971079202290591), ([[42, 298], [370, 298], [370, 354], [42, 354]], '9-00864-01', 0.8142346378327698)]

首先显示边界框坐标，然后是提取的文本，最后是置信度分数。但理想情况下，我们不需要所有这些数据；我们只需要提取的文本。EasyOCR 允许轻松自定义输出选项。接下来，我们将重点介绍自定义和可视化输出。

步骤＃4：配置输出格式

EasyOCR 库提供了许多不同的输出自定义选项。我们可以通过在“readtext”函数中将“detail”参数设置为零来避免检索边界框坐标和置信度分数，如下所示。

import easyocr
reader = easyocr.Reader(['en'])
result = reader.readtext('/path/of/image',detail=0) 
print(result)

对于我们的输入图像，这将是打印的结果。如您所见，我们仅过滤掉了检测到的文本。

['SERIAL NUMBER', 'AOC1715821', 'PART NUMBER', '9-00864-01']

我们还可以通过设置“paragraph”为true来将文本分组，如下所示。

result = reader.readtext('/path/of/image',detail=0, paragraph=True) 
print(result)

这将是我们输入图像的打印结果。提取的文本现在被分组在一起。

['SERIAL NUMBER AOC1715821', 'PART NUMBER 9-00864-01']

以下是逐行打印结果的代码片段示例：

import easyocr
reader = easyocr.Reader(['en'])
result = reader.readtext('/path/of/image')
for res in result:
  coord=res[0]
  text=res[1]
  cnotallow=res[2]
  print(text)

这就是我们输入图像的打印结果。提取的文本按照文档中出现的顺序逐行打印出来。

SERIAL NUMBER
AOC1715821
PART NUMBER
9-00864-01

如果不是打印变量“text”，而是打印变量“coord”和“conf”，我们将获得带有边界框坐标和置信度分数的类似输出。

步骤#5：可视化结果

我们还可以可视化 EasyOCR 模块的预测结果，将其叠加在输入图像之上。使用Supervision Python 包可以轻松完成此操作。Supervision 提供了一系列可重复使用的计算机视觉工具，可用于注释各种计算机视觉模型生成的预测结果等任务。

为了使用该库，我们需要安装 Supervision Python 包，如下所示：

pip install supervision

安装模块后，此代码使用 EasyOCR 检测图像中的文本并使用边界框和标签对其进行注释。它会初始化英语版 EasyOCR 阅读器，处理图像以提取文本、边界框坐标和置信度分数，并将数据存储在列表中。

然后使用 Supervision 的注释器在图像上叠加边界框和文本。最后，注释后的图像会显示并保存为“Output.jpg”，从而为 OCR 和视觉注释提供完整的工作流程。

import easyocr
import supervision as sv
import cv2
import numpy as np
from google.colab.patches import cv2_imshow


# Image path
Image_path = '/path/to/image'


# Initialize EasyOCR reader (English language, CPU)
reader = easyocr.Reader(['en'], gpu=False, model_storage_directory='/path/to/directory')


# Perform text detection on the image
result = reader.readtext(Image_path)


# Load image using OpenCV
image = cv2.imread(Image_path)


# Prepare lists for bounding boxes, confidences, class IDs, and labels
xyxy, confidences, class_ids, label = [], [], [], []


# Extract data from OCR result
for detection in result:
    bbox, text, confidence = detection[0], detection[1], detection[2]


    # Convert bounding box format
    x_min = int(min([point[0] for point in bbox]))
    y_min = int(min([point[1] for point in bbox]))
    x_max = int(max([point[0] for point in bbox]))
    y_max = int(max([point[1] for point in bbox]))


    # Append data to lists
    xyxy.append([x_min, y_min, x_max, y_max])
    label.append(text)
    confidences.append(confidence)
    class_ids.append(0)  


# Convert to NumPy arrays
detections = sv.Detections(
    xyxy=np.array(xyxy),
    cnotallow=np.array(confidences),
    class_id=np.array(class_ids)
)


# Annotate image with bounding boxes and labels
box_annotator = sv.BoxAnnotator()
label_annotator = sv.LabelAnnotator()


annotated_image = box_annotator.annotate(scene=image, detectinotallow=detections)
annotated_image = label_annotator.annotate(scene=annotated_image, detectinotallow=detections, labels=label)


# Display and save the annotated image
sv.plot_image(image=annotated_image)
cv2.imwrite("Output.jpg", annotated_image)

输出图像如下所示：

以下是使用不同输入图像获得的另一个示例输出图像：

OCR 挑战和注意事项

使用 EasyOCR 等 OCR 工具检测和提取图像中的文本并不总是那么容易。为了获得最佳结果，必须考虑几个关键因素。图像的质量至关重要，它需要清晰、光线充足且分辨率高。高质量的图像有助于 OCR 模型准确检测和识别字符，而质量差的图像则会导致误解。

可以使用锐化、降噪、对比度调整和图像规范化等图像预处理技术来增强图像质量。EasyOCR 的另一个需要考虑的因素是语言选择。该库支持 80 多种语言。正确指定输入图像中使用的语言至关重要。

您还可以考虑使用批处理和微调来提高效率。批处理允许您一次处理多个图像，在处理大量文档时节省时间和资源。EasyOCR 的微调选项可用于根据您的特定需求自定义引擎的工作方式。调整设置还可以针对您正在处理的内容类型优化模型，从而提高准确性和性能。

....

十二、DeepSeek-OCR 2

刚刚，DeepSeek又探索新架构了，开源OCR 2~

嘿！刚刚，DeepSeek 又更新了！

这次是更新了十月份推出的 DeepSeek-OCR 模型（参见：太强了！DeepSeek 刚刚开源新模型，用视觉方式压缩一切）。

当时 DeepSeek-OCR 的出世，引起了大家对视觉压缩的关注与讨论，而这一次，DeepSeek 对视觉编码下手了。

可以说，刚刚发布的 DeepSeek-OCR 2 通过引入 DeepEncoder V2 架构，实现了视觉编码从「固定扫描」向「语义推理」的范式转变！

当然，和 DeepSeek 几乎每次发布一样，这一次同样也是模型和技术报告齐开源。

项目地址：https://github.com/deepseek-ai/DeepSeek-OCR-2
论文地址：https://github.com/deepseek-ai/DeepSeek-OCR-2/blob/main/DeepSeek_OCR2_paper.pdf
模型地址：https://huggingface.co/deepseek-ai/DeepSeek-OCR-2

这项研究的三位作者分别是魏浩然、孙耀峰、李宇琨。

具体来说，该研究的核心创新在于将原本基于 CLIP 的编码器替换为轻量级语言模型（Qwen2-500M），并引入了具有因果注意力机制的「因果流查询」。

这种设计打破了传统模型必须按从左到右、从上到下的栅格顺序处理图像的限制，赋予了编码器根据图像语义动态重排视觉 Token 的能力。通过这种两级级联的 1D 因果推理结构（编码器重排与译码器解析），模型能够更精准地还原复杂文档（如带表格、公式和多栏布局）的自然阅读逻辑。

这就像是为机器装上了「人类的阅读逻辑」，让 AI 不再只是生搬硬套地扫描图像。对比之下，传统的 AI 就像一个死板的复印机，不管页面内容多复杂，都只能从左上角到右下角按行扫描。

在维持极高数据压缩效率的同时，DeepSeek-OCR 2 在多项基准测试和生产指标上均取得了显著突破。模型仅需 256 到 1120 个视觉 Token 即可覆盖复杂的文档页面，这在同类模型中处于极低水平，显著降低了下游 LLM 的计算开销。

在 OmniDocBench v1.5 评测中，其综合得分达到 91.09%，较前代提升了 3.73%，特别是在阅读顺序识别方面表现出了更强的逻辑性。

此外，在实际生产环境中，该模型显著降低了 OCR 识别结果的重复率，并为未来构建统一的 omni-modal（全模态）编码器提供了可行路径。是的，未来同一个 AI「大脑」或许能用同样的方法去处理声音、视频等所有模态的数据，真正实现多模态的深度统一。

DeepSeek-OCR 2 架构

如图 3 所示，DeepSeek-OCR 2 延续了 DeepSeek-OCR 的整体架构，由编码器（encoder）和解码器（decoder）组成。编码器负责将图像离散化为视觉 token，而解码器则在这些视觉 token 与文本提示（text prompts）的条件约束下生成输出。

两者的关键区别在于编码器部分：DeepSeek 将原有的 DeepEncoder 升级为 DeepEncoder V2。在完整保留前代能力的基础上，DeepEncoder V2 通过一种全新的架构设计，引入了因果推理能力（causal reasoning）。

DeepEncoder V2

DeepEncoder V2 的第一个组成部分是视觉分词器（vision tokenizer）。延续了 DeepEncoder 的设计，DeepSeek 采用了一种由参数规模为 8000 万的 SAM-base 与两层卷积层组成的架构。相比 DeepEncoder，DeepSeek 将最终卷积层的输出维度从 1024 降至 896，以与后续处理流程保持一致。

在 DeepEncoder 中，视觉分词器之后接入的是一个 CLIP ViT，用于进一步压缩和建模视觉语义。DeepEncoder V2 对这一组件进行了重新设计，将其改造为一种类 LLM 的架构，并引入了双流注意力机制（dual-stream attention）。

其中，视觉 token 采用双向注意力，以保留 CLIP 所具备的全局建模能力；而新引入的因果流查询（causal flow queries）则使用因果注意力。这些可学习的查询 token 被作为后缀追加在视觉 token 之后，每个查询都可以关注所有视觉 token 以及其之前的查询 token。通过保持查询 token 与视觉 token 数量一致，该设计在不改变 token 总数的前提下，对视觉特征施加语义上的排序与蒸馏约束。最终，只有因果查询 token 的输出会被送入 LLM 解码器。

从整体上看，该架构实际上构建了一种两阶段级联的因果推理机制：首先，编码器通过可学习查询对视觉 token 进行语义重排；随后，LLM 解码器在这一有序序列之上执行自回归推理。与依赖位置编码施加刚性空间顺序的传统编码器不同，这种因果排序查询能够更自然地贴合连续的视觉语义，并与 LLM 的单向注意力模式高度一致。该设计有望在二维空间结构与一维因果语言建模之间搭建起一座桥梁。

为更直观地展示 DeepEncoder V2 的注意力机制，图 5 对其注意力掩码进行了可视化。该注意力掩码由两个相互区分的区域组成。

左侧区域对原始视觉 token 采用双向注意力机制（类似于 ViT），使任意 token 都可以与其他所有 token 建立可见性，从而实现完整的全局建模；右侧区域则针对因果流 token 使用因果注意力（三角形掩码，与纯解码器 LLM 完全一致），其中每个 token 只能关注其之前的 token。

DeepSeek-MoE Decoder

由于 DeepSeek-OCR 2 的改进重点主要集中在编码器上，并未对解码器部分进行升级。遵循这一设计原则，模型继续沿用 DeepSeek-OCR 的解码器 —— 一个参数规模为 30 亿的 MoE 结构，其中约 5 亿参数在推理时处于激活状态。

训练数据与训练流程

在数据层面，DeepSeek-OCR 2 沿用了与 DeepSeek-OCR 相同的数据源，由 OCR 1.0、OCR 2.0 以及通用视觉数据组成，其中 OCR 数据占混合训练数据的 80%。同时引入了以下两项改进：

针对 OCR 1.0 数据采用了更均衡的采样策略，并按内容类型（正文、公式和表格）以 3:1:1 的比例对页面进行划分；
通过合并语义相似的类别（例如统一「插图说明」和「插图标题」）来优化布局检测的标签。

在训练阶段，DeepSeek-OCR 2 主要分为三个阶段来完成：（1）编码器预训练；（2）查询增强；（3）解码器专门化。

其中第一阶段使视觉分词器（tokenizer）和 LLM 风格的编码器获得特征提取、token 压缩和 token 重排的基础能力。第二阶段进一步加强编码器的 token 重排能力，同时增强了视觉知识的压缩。第三阶段冻结编码器参数，仅优化解码器，从而在相同的 FLOPs 下实现更高的数据吞吐量。

接着来看细节。

首先是训练 DeepEncoder V2。遵循 DeepSeek-OCR 和 Vary 的方法，使用语言建模目标来训练 DeepEncoder V2，将编码器与轻量级解码器耦合，通过预测下一个 token 进行联合优化。采用了 768×768 和 1024×1024 两种分辨率的数据加载器。视觉分词器初始化自 DeepEncoder，LLM 风格的编码器则初始化自 Qwen2-0.5B-base。预训练完成后，仅保留编码器参数用于后续阶段。

本阶段使用 AdamW 优化器，学习率采用余弦退火，从 1e-4 降至 1e-6，在 160 台 A100 GPU（20 个节点 × 8 台 GPU）上以 640 的批大小训练 40k 次迭代（采用长度为 8K 的序列打包，约包含 1 亿个图文对样本）。

其次是查询增强。在 DeepEncoder V2 预训练之后，将其与 DeepSeek-3B-A500M 整合为最终的流水线。冻结视觉分词器（SAM-conv 结构），并联合优化 LLM 编码器和 LLM 解码器以增强查询表示。本阶段通过多裁剪策略将两种分辨率统一到单个数据加载器中。此外采用 4 阶段流水线并行：视觉分词器（PP0）、LLM 风格编码器（PP1）以及 DeepSeek-LLM 层（PP2-3 每阶段 6 层）。

本阶段利用 160 台 GPU（每台 40GB 显存），配置了 40 个数据并行副本（每个副本 4 台 GPU），过程中使用相同的优化器，以 1280 的全局批大小进行训练，学习率在 15k 次迭代中从 5e-5 退火至 1e-6。

最后是 LLM 持续训练。为了快速消耗训练数据，本阶段冻结 DeepEncoder V2 的所有参数，仅更新 DeepSeek-LLM 的参数。本阶段加速了训练（在相同全局批大小下，训练速度提升了一倍多），同时有助于 LLM 更好地理解 DeepEncoder V2 重排后的视觉 token。

承接第二阶段，本阶段进行了另一次学习率退火，从 1e-6 降至 5e-8，共训练 20k 次迭代。

评估结果

团队选用 OmniDocBench v1.5 作为主要评测基准，该基准包含 1355 页文档，覆盖中英文两种语言的 9 大主要类别，包括杂志、学术论文、研究报告等。凭借其多样化的测试样本与严格的评测标准，OmniDocBench 为验证 DeepSeek-OCR 2 的整体性能，尤其是 DeepEncoder V2 的有效性，提供了一个可靠有效的平台。

如表 1 所示，在使用最小视觉 token 上限（

）的情况下，DeepSeek-OCR 2 仍取得了 91.09% 的领先性能。与 DeepSeek-OCR 基线模型相比，在采用相似训练数据来源的前提下，其性能提升了 3.73%，验证了新设计架构的有效性。

此外，除了整体性能提升，阅读顺序（R-order）指标上的编辑距离（Edit Distance，ED）也显著下降，从 0.085 降至 0.057。这表明，新的 DeepEncoder V2 能够根据图像信息更有效地选择并排列初始视觉 token。

进一步如表 2 所示，在相同的视觉 token 预算（1120）条件下，DeepSeek-OCR 2 在文档解析任务中的 ED（0.100）低于 Gemini-3 Pro（0.115）。这进一步证明了新模型在保持高视觉 token 压缩率的同时，仍能确保更优的性能，并展现出极高的潜力。

改进空间

团队在 9 种文档类型上，对 DeepSeek-OCR 与 DeepSeek-OCR 2 进行了细致的性能对比，结果表明：DeepSeek-OCR 2 仍具有较大的提升空间，如表 3 所示。在文本识别的编辑距离（ED）指标上，DeepSeek-OCR 2 在大多数场景中优于 DeepSeek-OCR，但在某些类型上仍存在明显不足，例如报纸类文档，其 ED 超过 0.13。

团队认为主要原因有两点：

视觉 token 上限较低，可能影响了文本极为密集的报纸类文档识别效果，这一问题可在未来通过增加局部裁剪（local crops）的数量来缓解；
报纸类数据不足 —— 当前训练集中仅包含约 25 万条相关样本，这对于训练 DeepEncoder V2 来说仍然不够充分。

当然，在阅读顺序（R-order）这一指标上，DeepSeek-OCR 2 在所有类别中始终优于 DeepSeek-OCR，这进一步验证了所提出的「视觉因果流」编码器设计的有效性。

实际应用

DeepSeek-OCR 主要面向两类生产场景：一是为 DeepSeek-LLM 提供图像 / 文档读取能力的在线 OCR 服务，二是用于批量 PDF 处理的预训练数据流水线。在比较了 DeepSeek-OCR 2 与 DeepSeek-OCR 在真实生产环境中的表现后发现，由于生产环境中无法获得标准答案，因此团队主要采用「重复率」作为核心质量指标。

如表 4 所示，相比前代模型，DeepSeek-OCR 2 在实际可用性方面有了显著提升：在在线用户日志图像中，重复率从 6.25% 降至 4.17%；在 PDF 数据生产场景中，重复率从 3.69% 降至 2.88%。

这些结果进一步验证了 DeepSeek-OCR 2 架构的有效性，尤其体现了其在逻辑性视觉理解方面的优势。

更多详情信息，可阅读原文获取！

,,,,

十三、DeepSeek-OCR

太强了！DeepSeek刚刚开源新模型，用视觉方式压缩一切

我们或许能通过文本到图像的方法实现近 10 倍无损上下文压缩。

没想到吧，DeepSeek 刚刚开源了新模型，还是一款 OCR 模型。可以看到，该模型的参数量为 3B，刚上线不久就已经有 100 多次下载量了。

该项目由 DeepSeek 三位研究员 Haoran Wei、Yaofeng Sun、Yukun Li 共同完成。其中一作 Haoran Wei 曾在阶跃星辰工作过，曾主导开发了旨在实现「第二代 OCR」的 GOT-OCR2.0 系统（arXiv:2409.01704），该项目已在 GitHub 收获了超 7800 star。也因此，由其主导 DeepSeek 的 OCR 项目也在情理之中。

论文标题：DeepSeek-OCR: Contexts Optical Compression
项目地址：https://github.com/deepseek-ai/DeepSeek-OCR
论文地址：https://github.com/deepseek-ai/DeepSeek-OCR/blob/main/DeepSeek_OCR_paper.pdf
Hugging Face：https://huggingface.co/deepseek-ai/DeepSeek-OCR

DeepSeek 表示，DeepSeek-OCR 模型是通过光学二维映射技术压缩长文本上下文可行性的初步探索。

该模型主要由 DeepEncoder 和 DeepSeek3B-MoE-A570M 解码器两大核心组件构成。其中 DeepEncoder 作为核心引擎，既能保持高分辨率输入下的低激活状态，又能实现高压缩比，从而生成数量适中的视觉 token。

实验数据显示，当文本 token 数量在视觉 token 的 10 倍以内（即压缩率 <10×）时，模型的解码（OCR）精度可达 97%；即使在压缩率达到 20× 的情况下，OCR 准确率仍保持在约 60%。

这一结果显示出该方法在长上下文压缩和 LLM 的记忆遗忘机制等研究方向上具有相当潜力。

此外，DeepSeek-OCR 还展现出很高的实用价值。在 OmniDocBench 基准测试中，它仅使用 100 个视觉 token 就超过了 GOT-OCR2.0（每页 256 个 token）的表现；同时，使用不到 800 个视觉 token 就优于 MinerU2.0（平均每页超过 6000 个 token）。在实际生产环境中，单张 A100-40G GPU 每天可生成超过 20 万页（200k+）的 LLM/VLM 训练数据。

DeepSeek-OCR 在端到端模型测试中以最少的视觉 token 数达到了最先进的性能。

DeepSeek-OCR：上下文光学压缩

DeepSeek 探索的方法概括起来就是：利用视觉模态作为文本信息的高效压缩媒介。

什么意思呢？我们知道，一张包含文档文本的图像可以用比等效文本少得多的 Token 来表示丰富的信息，这表明：通过视觉 Token 进行光学压缩可以实现高得多的压缩率。

基于这一洞见，DeepSeek 从以 LLM 为中心的视角重新审视了视觉语言模型 (VLM)，其中，他们的研究重点是：视觉编码器如何提升 LLM 处理文本信息的效率，而非人类已擅长的基本视觉问答 (VQA) 任务。

DeepSeek 表示，OCR 任务作为连接视觉和语言的中间模态，为这种视觉 - 文本压缩范式提供了理想的试验平台，因为它在视觉和文本表示之间建立了自然的压缩 - 解压缩映射，同时提供了可量化的评估指标。

DeepSeek-OCR 便由此而生。这是一个为实现高效视觉 - 文本压缩而设计的 VLM。

如下图所示，DeepSeek-OCR 采用了一个统一的端到端 VLM 架构，由一个编码器和一个解码器组成。

其中，编码器 (即 DeepEncoder) 负责提取图像特征，并将视觉表示进行 Token 化和压缩。解码器则用于根据图像 Token 和提示词 (prompt) 生成所需的结果。

DeepEncoder 的参数量约为 3.8 亿 (380M)，主要由一个 80M 的 SAM-base 和一个 300M 的 CLIP-large 串联而成。解码器采用 3B MoE 架构，激活参数量为 5.7 亿 (570M)。

DeepEncoder

DeepSeek 研究发现，为了探索上下文光学压缩的可行性，我们需要一个具备以下特点的视觉编码器：

1. 能够处理高分辨率；

2. 在高分辨率下激活值低；

3. 视觉 Token 数量少；

4. 支持多分辨率输入；

5. 参数量适中。

然而，现有的开源编码器无法完全满足所有这些条件。因此，DeepSeek 自行设计了一款新颖的视觉编码器，命名为 DeepEncoder。

DeepEncoder 主要由两个组件构成：一个以窗口注意力为主的视觉感知特征提取组件，以及一个采用密集全局注意力的视觉知识特征提取组件。

基于之前相关研究的预训练成果，该团队分别使用 SAM-base (patch 大小为 16) 和 CLIP-large 作为这两个组件的主要架构。

对于 CLIP，他们移除了其第一个 patch 嵌入层，因为它的输入不再是图像，而是来自前一个流程的输出 Token。在两个组件之间，该团队借鉴了 Vary 的设计（参阅论文《Vary: Scaling up the vision vocabulary for large vision-language model》），使用了一个 2 层的卷积模块对视觉 Token 进行 16 倍的下采样。每个卷积层的核大小为 3，步长为 2，填充为 1，通道数从 256 增加到 1024。假设我们输入一张 1024×1024 的图像，DeepEncoder 会将其分割成 1024/16 x 1024/16 = 4096 个 patch Token。

由于编码器的前半部分主要由窗口注意力构成，且参数量仅为 80M，因此其激活值是可接受的。在进入全局注意力之前，这 4096 个 Token 会经过压缩模块，数量变为 4096/16 = 256，从而使得整体的激活内存变得可控。

MoE 解码器

该模型的解码器使用了 DeepSeekMoE ，具体为 DeepSeek-3B-MoE。

在推理过程中，模型会激活 64 个路由专家中的 6 个以及 2 个共享专家，激活参数量约为 5.7 亿 (570M)。3B 的 DeepSeekMoE 非常适合以领域为中心 (这里即为 OCR) 的 VLM 研究，因为它在获得 3B 模型表达能力的同时，也享有了 5 亿 (500M) 参数量小模型的推理效率。

解码器从 DeepEncoder 压缩后的潜在视觉 Token 中重建原始文本表示，过程如下：

其中 Z 是来自 DeepEncoder 的压缩后潜在 (视觉) Token，而

是重建的文本表示。函数 f_dec 代表一个非线性映射，紧凑的语言模型可以通过 OCR 风格的训练来有效地学习它。DeepSeek 推测认为：大语言模型通过专门的预训练优化，将能更自然地集成这类能力。

数据引擎

DeepSeek 也为 DeepSeek-OCR 构建了复杂多样的训练数据，包括：

OCR 1.0 数据，主要包含传统 OCR 任务，如场景图像 OCR 和文档 OCR；
OCR 2.0 数据，主要包括复杂人造图像的解析任务，如常见图表、化学分子式和平面几何解析数据；
通用视觉数据，主要用于为 DeepSeek-OCR 注入一定的通用图像理解能力，并保留通用的视觉接口。

数据方面，DeepSeek 还进行了更多有利于 OCR 任务的设计，详情请参阅原论文。

训练流程

该模型的训练流程非常简单，主要包括两个阶段：

独立训练 DeepEncoder
训练 DeepSeek-OCR

DeepEncoder 的训练遵循 Vary 的方法，利用一个紧凑的语言模型并采用下一个 Token 预测的框架来训练 DeepEncoder。

在此阶段，DeepSeek 使用了前文提到的所有 OCR 1.0 和 2.0 数据，以及从 LAION 数据集中采样的 1 亿条通用数据。所有数据均使用 AdamW 优化器和余弦退火调度器进行训练，共训练 2 个 epoch，批处理大小为 1280，学习率为 5e-5。训练序列长度为 4096。

在 DeepEncoder 准备就绪后，再训练 DeepSeek-OCR。整个训练过程在 HAI-LLM 平台上进行。整个模型采用了流水线并行 (PP)，并被分为 4 个部分，其中 DeepEncoder 占用两部分，解码器占用两部分。

对于 DeepEncoder，DeepSeek 将 SAM 和压缩器视为视觉 Tokenizer，放置在 PP0 上并冻结其参数；同时将 CLIP 部分视为输入嵌入层，放置在 PP1 上，其权重不冻结并参与训练。对于语言模型部分，由于 DeepSeek3B-MoE 有 12 层，他们在 PP2 和 PP3 上各放置 6 层。

他们使用 20 个节点 (每个节点配备 8 个 A100-40G GPU) 进行训练，数据并行 (DP) 度为 40，全局批处理大小为 640。优化器为 AdamW，配合基于步数 (step-based) 的调度器，初始学习率为 3e-5。对于纯文本数据，训练速度为每天 900 亿 Token；对于多模态数据，训练速度为每天 700 亿 Token。

实验结果

视觉 - 文本压缩

研究选用了 Fox 基准数据集来验证 DeepSeek-OCR 在文本密集型文档上的压缩与解压能力。

如表 2 所示，在 10× 压缩比的情况下，模型的解码精度可达约 97%。

当压缩比超过 10× 时，性能开始下降，他们猜测可能有两个原因：

长文档的版面布局更复杂，导致信息分布不均；
在 512×512 或 640×640 分辨率下，长文本会变得模糊。

当压缩比接近 20× 时，作者发现模型的精度仍可达到约 60%。

OCR 实际性能

DeepSeek-OCR 不仅是一个实验性模型，还具备很强的实用能力。结果如表 3 所示。

具体而言：

在仅使用 100 个视觉 token（分辨率 640×640）的情况下，DeepSeek-OCR 的表现超越了使用 256 个 token 的 GOT-OCR2.0 ；
当使用 400 个视觉 token（其中有效 token 为 285，分辨率 1280×1280）时，其性能已可与当前 SOTA 模型相当；
进一步地，在使用不到 800 个视觉 token（即 Gundam 模式）时，DeepSeek-OCR 的性能超过了 MinerU2.0 ，后者需要近 7,000 个视觉 token。

这些结果表明，DeepSeek-OCR 在实际应用中表现出极强的性能与效率，并且由于其更高的 token 压缩率，具有更高的研究潜力与扩展空间。

表 4 结果表明，不同类型文档对视觉 token 的需求差异较大：

对于幻灯片类文档，仅需 64 个视觉 token 即可达到令人满意的识别效果；
对于书籍和报告类文档，100 个视觉 token 即可取得较好表现。

定性研究

图 7、图 8、图 9、图 10 所示，模型能够对图表、几何图形、化学公式，甚至自然图像进行深度解析，只需使用一个统一的提示词（prompt）即可完成。

多语言识别：针对 PDF 文档，DeepSeek-OCR 支持近 100 种语言的识别。

如图 11 所示展示了 DeepSeek-OCR 在阿拉伯语（Arabic）与僧伽罗语（Sinhala）的可视化识别结果。

通用视觉理解：此外，DeepSeek-OCR 还具备一定程度的通用图像理解能力，相关的可视化结果如图 12 所示。

~2>>> DeepSeek的新模型很疯狂：整个AI圈都在研究视觉路线，Karpathy不装了

「我很喜欢新的 DeepSeek-OCR 论文…… 也许更合理的是，LLM 的所有输入都应该是图像。即使碰巧有纯文本输入，你更应该先渲染它，然后再输入。」

一夜之间，大模型的范式仿佛被 DeepSeek 新推出的模型给打破了。

昨天下午，全新模型 DeepSeek-OCR 突然开源。在该模型的处理过程中，1000 个字的文章能被压缩成 100 个视觉 token，十倍的压缩下精度也可以达到 97%，一块英伟达 A100 每天就可以处理 20 万页的数据。

这种方式或许可以解决大模型领域目前头疼的长上下文效率问题，更重要的是，如果「看」文本而不是「读」文本最终被确定为正确的方向，也意味着大模型的范式会发生重要的转变。

GitHub 上，DeepSeek-OCR 项目一晚收获了超过 4000 个 Star。

因为是开源的小模型，DeepSeek-OCR 第一时间经历了整个 AI 社区的检验，很多大佬在看完论文之后纷纷发表了看法，兴奋之情溢于言表。

OpenAI 联合创始成员之一，前特斯拉自动驾驶总监 Andrej Karpathy 表示，它是一个很好的 OCR 模型。

他表示，作为一个本质上是研究计算机视觉，暂时伪装成自然语言专家的人，他更感兴趣的部分是：对于大语言模型来说，像素是否比文本更适合作为输入？文本 token 在输入端是否浪费资源，甚至很糟糕？

也许更合理的是，LLM 的所有输入都应该是图像。即使你碰巧有纯文本输入，也许你更愿意先渲染它，然后再输入：

更多信息压缩（参见论文） => 更短的上下文窗口，更高的效率
明显更为通用的信息流 => 不仅仅是文本，还包括粗体文本、彩色文本、任意图像。
现在可以轻松地使用双向注意力来处理输入，并且默认情况下，而不是自回归注意力 - 功能更加强大。
删除（输入端的）分词器！！我已经吐槽过我有多讨厌分词器了。分词器很丑陋，独立存在，而且不是端到端的。它「导入」了 Unicode 和字节编码的所有丑陋之处，继承了大量历史包袱，以及安全 / 越狱风险（例如连续字节）。它让两个肉眼看起来相同的字符在网络内部看起来像两个完全不同的 token。一个微笑的表情符号看起来像一个奇怪的 token，而不是…… 一个真正的笑脸，包括像素等等，以及它带来的所有迁移学习。分词器必须移除。

OCR 只是众多有用的视觉-文本任务之一。文本-文本任务可以转换为视觉-文本任务，反之则不行。

很多用户信息都是图像，但解码器（智能助手的响应）仍然是文本。如何真实地输出像素…… 或者说，如果你想要输出像素，那就不那么明显了。

纽约大学助理教授谢赛宁也发推对 Karpathy 的评论给予了高度评价，他尤其对其中「作为一个本质上是研究计算机视觉，暂时伪装成自然语言专家的人」这一句深感共鸣。

毕竟正是谢赛宁当年首次将 Transformer 架构与扩散模型相结合，提出了扩散 Transformer（DiT），为文生视频开启了新的道路。

也有研究者对 DeepSeek-OCR 这项研究的潜在意义进行了更引人入胜的解读。

Emanuel 继续写道：传统上，在多模态大语言模型中，视觉 token 几乎像是事后添加的产物，或者说是「外挂」在语言模型框架之上的功能。而如果用可识别的图像像素形式来表示文本，那么一万英文单词在多模态 LLM 中所占的空间，将远远大于用文本 token 表示时的空间。

举例来说，那一万字的英文文本可能原本对应 15,000 个文本 token，但如果转换成视觉 token，可能就会变成 30,000 到 60,000 个视觉 token。由此可见，视觉 token 的效率低得多，因此过去它们只适用于那些无法用文字有效表达的数据（例如图像或视觉场景）。

但这篇论文的提出，颠覆了这一切。

DeepSeek 想出了一种方法，使得视觉 token 的压缩效率比文本 token 高出 10 倍！

换句话说，原本需要 10,000 个单词的文本，现在理论上只需约 1,500 个经过特殊压缩的视觉 token 即可完整表示。

如果你想一想人类大脑的运作方式，这其实也并非完全出人意料。

毕竟，当我们回忆一本读过的书的某一部分时，往往会以视觉的方式来定位：我们能记得那段内容在书的哪一页、哪一侧、页面的大致位置，这说明我们的大脑在使用某种视觉记忆表征机制。

不过，目前还不清楚这种机制在 LLM 的下游认知能力中会如何表现。模型在使用这些压缩后的视觉 token 时，是否还能像使用普通文本 token 那样进行智能推理？或者，这种方式会不会让模型变得不那么善于表达语言，因为它被迫更多地以视觉方式来思考？

无论如何，可以想见：根据实际的性能权衡，这可能成为一个极具潜力的新方向，用于大幅扩展模型的有效上下文长度（context size）。

尤其是如果与 DeepSeek 几周前发布的另一篇关于稀疏注意力（sparse attention）的论文结合使用，前景将更加令人兴奋。详情可参阅xx报道《刚刚，DeepSeek 开源 V3.2-Exp，公开新稀疏注意力机制 DSA》。

他还提到：「据我们所知，谷歌也可能早就发现了类似的技术，这或许能解释为什么 Gemini 模型拥有如此巨大的上下文窗口，并在 OCR 任务上表现得又快又好。当然，如果他们真的做到了，可能也不会公开说明 —— 毕竟这会被视为核心商业机密。而 DeepSeek 的可贵之处在于：他们选择了完全开源，包括模型权重与方法细节。这意味着，任何人都可以试验、验证并进一步探索这一突破。」

即使这些技巧可能让注意力机制的表达变得略微「有损」（lossy），但如果它能让前沿级 LLM 拥有一千万甚至两千万 token 级别的上下文窗口，那无疑是令人振奋的。

设想一下：你可以把一家公司的所有关键内部文档都塞进提示词的前缀（prompt preamble）中，并缓存到 OpenAI 的系统里。之后只需在其上添加具体的问题或提示词，无需搜索工具，就能快速且经济地完成查询。

或者，你可以将整个代码库都放入上下文中并缓存，每次修改时只需追加相当于 Git 有差异的部分内容。

他还表示：「这让我想起著名物理学家 Hans Bethe（汉斯・贝特）的故事 —— 他以记忆力惊人著称，能背下大量随机的物理数据（例如整个元素周期表、各种物质的沸点等），因此在思考与计算时几乎从不需要中断去查阅资料。」

毫无疑问，拥有大量与任务相关的知识并能随时调用，是极其强大的能力。而 DeepSeek 的这一方法，似乎正是一个聪明且可扩展的路径，有望让模型的「工作记忆」容量提升 10 倍甚至更多。

在 Hacker News 等平台上，DeepSeek-OCR 也引发了广泛热议。

Django Web 框架的联合创建者 Simon Willison 甚至成功尝试了让 Claude Code 成功在英伟达 Spark 硬件上运行这个模型。整个过程仅使用了 4 个提示词，时间也只不过 40 分钟。

科技视频播主 NiceKate AI 将成功将其部署到了 Mac 上。

不过，值得注意的是，有不少研究者指出，DeepSeek 新模型虽然在工程上取得了不可否认的巨大成功，但其核心方法思路并非首创。

事实上，早在 2022 年，哥本哈根大学等机构的论文《Language Modelling with Pixels》就已经提出了类似的思想。其中提出了基于像素的语言编码器（Pixel-based Encoder of Language），简称 PIXEL，可望解决语言模型的词汇瓶颈问题。

PIXEL 架构概况，来自论文《Language Modelling with Pixels》，arXiv:2207.06991

具体来说，PIXEL 是一种预训练语言模型，可将文本渲染为图像，从而能够基于文字形态的相似性或像素共激活模式在不同语言之间实现表示的迁移。与传统语言模型预测 token 分布的方式不同，PIXEL 的训练目标是重建被遮盖图像块的像素。

此后也有多篇研究成果对这一研究思路进行了发展和改进，至少包括：

CVPR 2023 论文：CLIPPO: Image-and-Language Understanding from Pixels Only
NeurIPS 2024 论文：Leveraging Visual Tokens for Extended Text Contexts in Multi-Modal Learning
2024 年论文：Improving Language Understanding from Screenshots
NeurIPS 2025 论文：Vision-centric Token Compression in Large Language Model

不管怎样，看起来 DeepSeek-OCR 确实是一个非常好用的模型，也已经有不少先行者开始用起来了：

当然，批评的声音依然是存在的，比如现在 Meta 工作的前 OpenAI 和 DeepMind 研究者 Lucas Beyer 就毫不客气地表示 DeepSeek-OCR 的方法并不存在渐进性，不像人类。

最后，在 DeepSeek-OCR 热烈的讨论人群中，也有一群外国人注意到了其论文中有趣的 Prompt 示例，在研究什么叫「先天下之忧而忧，后天下之乐而乐」。

不论是对 AI 还是对外国人来说，理解准确的意思确实是个挑战。

你是否已经尝试过 DeepSeek-OCR 模型？又怎么看待其背后的「以视觉方式压缩一切」的研究思路？

~3>>> 文本已死，视觉当立！Karpathy狂赞DeepSeek新模型，终结分词器时代

DeepSeek-OCR 用百级视觉 Token 替代文本，实现 97% 准确率、60×压缩，一举登顶 OmniDocBench；Karpathy 直呼“干掉分词器”，像素输入或成 LLM 新主流。

DeepSeek再次让全世界大吃一惊！

他们最新成果DeepSeek-OCR，从根本上改变了游戏规则——

文本并非通用的输入。反而，视觉将取而代之！

此外，在光学文字识别OCR任务上，DeepSeek-OCR模型名副其实，堪称工程学的巅峰之作——

在单卡A100-40G上，可达每秒约2500 Token，跑得飞快。

在保持97% OCR准确率的前提下，可将视觉上下文压缩至原来的1/20，常规使用下压缩比也能轻松小于1/10。

在OmniDocBench基准测试中，使用更少的视觉Token，即可超越GOT-OCR2.0和MinerU2.0的表现。

到底效果多惊艳？

一整页密密麻麻的文本，被压成仅仅100个视觉Token，在 OmniDocBench上实现最多60倍压缩！

DeepSeek-OCR简直把文字变成了像素点，就像把一本100页的书压缩成一张照片，AI依然能读懂它。

参数少、压缩率高、速度快、涵盖100种语言……DeepSeek-OCR全都要。

不仅理论价值大，实用性还很高强，好评如潮：

Github开源项目DeepSeek-OCR，一夜收获4.4k星：

DeepSeek-OCR用事实证明，实体页面（如缩微胶片、书籍）才是训练AI模型的更优数据源——而非低质量的互联网文本。

「骨子里的计算机视觉研究者」、特斯拉前AI总监、OpenAI创始团队成员Karpathy，难掩欣喜，力挺DeepSeek新模型。

Karpathy

技痒难耐，早已受不了分词器

Karpathy相当喜欢DeepSeek-OCR的新论文。

但更有趣的部分在于，对于大语言模型来说，像素输入是否优于文本输入？在输入端，文本Token会不会是一种既浪费又糟糕透顶的方式？

DeepSeek-OCR在动摇「文本作为AI的核心地位」，而视觉或将再次成为主流！

Karpathy自称「骨子里搞计算机视觉」，只是暂时混迹在自然语言处理圈，自然对上述问题尤其感兴趣。

上下滑动查看

或许，大语言模型的所有输入都只应该是图像，这才更有道理。就算你手头是纯文本输入，可能也最好先把它渲染成图像再喂给模型：

更高的信息压缩率 => 更短的上下文窗口，更高的效率。
信息流的通用性显著增强 => 不再局限于文本，还可以处理粗体、彩色文本乃至任意图像。
输入现在可以轻松地、默认地采用双向注意力机制处理，而不再是自回归注意力——这可要强大得多。
干掉（输入端的）分词器tokenizer！！

特别是最后一点，Karpathy忍了很久了，早就多次吐槽分词器太烂了——

分词器丑陋、独立，并非端到端的环节。

它「引入」了Unicode和字节编码的所有糟粕，背负着沉重的历史包袱，还带来了安全/越狱风险（比如连续字节问题）。

它让两个肉眼看起来一模一样的字符，在网络内部却变成了两个风马牛不相及的 Token。

一个微笑的表情符号😄，在LLM模型看来只是个奇怪的token，而不是一个带有像素、承载着丰富信息、能从中进行迁移学习的真实笑脸。

总之，Karpathy认为，分词器「恶行累累」，这次必须赶走分词器。

此外，他展望了视觉成为通用输入的前景：

OCR只是「视觉到文本」众多落地应用中的一种。而「文本到文本」的任务也可以被改造为「视觉到文本」的任务，反之则不行。

所以，或许用户输入的消息是图像，但解码器（即「智能助理」的响应）依然是文本。

至于，到底如何真实地输出像素或者说你是否真想这么做，就远没那么明朗了。

现在，Karpathy表示，他要拼命忍住，不去搞一个只用图像输入的「nanochat」的支线任务。

为什么图像输入对AI更友好？

有网友问：

首先，为什么图像能轻易获得双向注意力，而文本却不能？

另外，虽然图像没有像文本那样的「Token化」过程，但我们把输入图像切割成一个个图像块（patches）时，难道得到的不是类似，甚至可能更不理想的结果吗？

对此，Karpathy表示，原则上可以，只不过为了追求效率，文本（的生成）通常采用简单的自回归方式进行训练。

可以设想存在一个中间训练阶段，利用双向注意力机制，微调条件信息，比如那些我们不需要去预测或生成的代表用户消息的Token。

原则上，你可以对整个上下文窗口进行双向编码，而目的仅仅是为了预测下一个 Token。但这么做的代价就是无法并行化训练。

至于第二个问题，他认为，严格来说与「像素 vs. Token」无关。其核心更在于，像素通常是被编码的（encoded），而 Token则是被解码的（decoded）。

至于，Karpathy的「nanochat支线任务论」，网友并不认可：

DeepSeekOCR证明这不仅关乎压缩——更是语义的蒸馏。

分词器时代意味着识字，像素时代则关乎感知。

Nanochat不该是支线任务，它是「光学认知」的开端。

帖子下面，网友恳求Karpathy：快搞个只用图像输入的「nanochat」吧！

Karpathy的前老板、「好兄弟」马斯克给出了更科幻的猜想：

长期来看，AI模型超过99%的输入和输出将是光子。

马斯克让Grok估计了一下已知宇宙的光子总量：

1=估算可观测宇宙中的光子总数是一项复杂的工作，但我们可以基于几个主要组成部分得出一个大致数字：宇宙微波背景辐射（CMB）产生的光子、星光光子，以及其他一些微弱来源。

宇宙微波背景辐射（CMB）占据主导地位，使得可观测宇宙中的光子总数约为1.5×10⁸⁹个。这个数字是一个粗略估算，具体数值取决于可观测宇宙的精确体积以及其他微小来源的贡献，但整体上与宇宙学计算结果相符。

1.5×10⁸⁹！没有其他东西能达到这种规模。这就是马斯克的逻辑。

毕竟，人类就是通用「光学计算系统」——眼睛来认识世界的：

作者介绍

这次论文一共有三位作者：Haoran Wei、Yaofeng Sun、Yukun Li。

论文地址：https://github.com/deepseek-ai/DeepSeek-OCR/blob/main/DeepSeek_OCR_paper.pdf

论文一作Haoran Wei，此前也是GitHub 7.9k星爆火项目GOT-OCR2.0，即「General OCR Theory: Towards OCR-2.0 via a Unified End-to-end Model」的一作。

项目地址：https://github.com/Ucas-HaoranWei/GOT-OCR2.0

论文地址：https://arxiv.org/abs/2409.01704

Yaofeng Sun是DeepSeek的软件工程师，于2023年加入幻方AI/DeepSeek。

谷歌学术显示，他参与了DeepSeek-r1、DeepSeek-v3、DeepSeek-vl2、DeepSeek-v2、DeepSeek-vl、DeepSeek LLM等模型的研究。

据悉，他本科毕业于北京大学图灵班（Turing Class）计算机科学专业。

他代表北京大学参赛，获得ACM-ICPC 亚洲区域赛金牌（2017–2019），获奖赛区包括：EC 总决赛 2017、青岛 2017、西安 2017、上海 2019、南京 2019。

之前，他获得全国信息学奥林匹克竞赛（NOI）金牌（2015、2016）。

Yukun Li也是高产的AI从业者——

2020年至今，引用数已过9千；参与过DeepSeek-v3、DeepSeek-vl2、DeepSeek-v2、DeepSeek-Coder、DeepSeek-MoE、DeepSeek LLM等项目研究。

我们一起见证他们带来的AI新突破，一起见证开源AI的崛起！

参考资料：

https://x.com/karpathy/status/1980397031542989305

https://x.com/teortaxesTex/status/198023417556435798

https://www.linkedin.com/in/sunyaofeng/

~ 4 ~ DeepSeek-OCR 并非 OCR，而是 Token 压缩

DeepSeek 仅使用 100 个视觉标记即可表示通常需要 1,000 个文本标记的内容，然后以 97% 的准确率将其解码回来。

你肯定听过“一图胜千言”这句话吧？这句古老的谚语，简单概括了视觉信息的丰富性。但如果这并非老生常谈的陈词滥调，那会怎样？如果你真的能在一张图片中存储一千个字的完美且可检索的文本，并让人工智能完美地解读出来，那会怎样？

嗯，这就是 DeepSeek AI 的一篇新论文和模型背后的想法，而且很快就会变成现实。表面上看，它被称为 DeepSeek-OCR，你可能会把它和其他十几种文档阅读工具混为一谈。但是，正如研究人员自己暗示的那样，这实际上与 OCR 无关。

是的，该模型确实是最先进的文档解析器。但光学字符识别只是一个更大、更深刻想法的概念验证：一种革命性的人工智能内存压缩新形式。他们把这个古老的术语转化为一种压缩算法，这种算法可能会从根本上改变我们解决当今人工智能领域一些最大瓶颈的方式：长期上下文和记忆。

AI的共性瓶颈：海量数据处理的困境

人工智能开发中的“圣杯”之一是创建能够处理超长上下文的模型——对话、文档或代码库，其包含数百万甚至数千万个标记。这里的挑战在于，对于当前的大型语言模型 (LLM) 来说，信息处理极其线性。我们采用“每个单词一个标记”的粗略标准。想要给模型提供一份 10,000 字的报告？你需要大约 10,000 个标记，而一次性处理所有这些标记的计算成本是另一篇文章要讨论的，但现在只需知道它的巨大成本即可。

这大致就是上下文窗口问题。随着对话时间的延长，模型有限的“短期记忆”会被填满，它开始忘记一开始说了什么。这听起来也像是我女朋友被问到我的听力水平时会说的话，不过，我们继续吧。

这就是 DeepSeek 的激进想法发挥作用的地方，他们称之为“上下文光学压缩”。简而言之，除了将图像转换为文本标记之外，如果可以将文本标记存储在图像中会怎么样？为什么呢？他们声称：

DeepSeek 仅使用 100 个视觉标记即可表示通常需要 1,000 个文本标记的内容，然后以 97% 的准确率将其解码回来。

这是 10 倍的压缩率，同时保持了近乎完美的保真度。他们甚至发现，在 20 倍压缩率（每 1,000 个单词使用 50 个视觉标记）下，该模型仍能保持 60% 左右的准确率。这不仅仅是一种改进，更是一次范式转变。

换个角度来看：1,000 个文本标记大约相当于 2-3 页文本，想象一下一份完整的商务备忘录或一封长邮件。使用这种压缩方法，您只需 100 个视觉标记即可表示所有信息——这大约相当于一张个人资料照片（200×200 像素）或一个小图标大小的微小缩略图。想象一下，将一份完整的 2-3 页文档压缩成像您的 Facebook 个人资料照片一样紧凑的体积，或者换句话说，将整份备忘录压缩成一张比拇指还小的图像。而 AI 仍然可以以 97% 的准确率将其解码。

工作原理：DeepEncoder 中的“秘密武器”

要理解这项技术的革命性，首先需要快速了解一下 AI 如何识别图像。通常，视觉变换器 (ViT) 模型通过将图像分割成由小块组成的网格来实现“识别”。每个小块随后被转换为一个“视觉标记”。但问题在于，对于高分辨率文档，这种方法要么会产生难以管理的标记数量，要么会丢失关键细节。

DeepSeek 的解决方案是一个具有巧妙的两阶段架构的定制 DeepEncoder。

高保真感知 (SAM)：首先，图像由基于 Meta 的“全分割模型”(SAM) 的组件进行处理。该模型非常擅长在极高分辨率下捕捉精细细节。它就像一次细致的初次处理，能够准确理解图像的布局和结构，而不会遗漏任何细节。

激进压缩（CNN）：在继续之前，第一阶段的输出将通过卷积神经网络（CNN）作为强大的压缩器，将标记数量缩小 16 倍。这是使视觉信息变得极其密集的关键步骤。
全局理解 (CLIP)：最终，这组高度压缩的视觉标记会被输入到基于 OpenAI CLIP 模型的组件中。CLIP 擅长将视觉信息与其底层含义联系起来。在这个阶段，它会提取这些密集且压缩的片段，并找出它们之间的关联，最终形成连贯的文本。

结果是，系统可以获取使用旧方法需要超过 6,000 个视觉标记的文档，并使用不到 800 个标记来表示它 - 同时实现更好的性能。

一种新型的人工智能记忆

这就是我们超越 OCR 并进入真正激动人心的应用领域的地方。想象一下，一个 AI 助手能够记住你几个月来数百万个词条的整个对话历史。将其存储为文本将耗费大量的计算资源。

但有了光学压缩，一种新的记忆模型就变得可行了。正如文字记录员精彩地阐述的那样，你可以设计一个系统，其中：

最近的对话被保存为高分辨率、标准文本标记，以便完美、即时地回忆。

超过一定时间的旧对话会被渲染成图像。一周前的聊天记录可能是一张清晰的图像，一个月前的聊天记录可能是一张分辨率稍低的图像，而一年前的聊天记录则是一张高度压缩的图像。

然后，AI 可以用更少的标记将整个视觉历史记录存储在其上下文窗口中。当你问：“我们三周前讨论了关于泰坦计划的什么？”时，模型无需搜索海量文本文件。相反，它只需“浏览”那次对话的压缩图像，并将信息读给你听。这是一种记忆衰退的形式，反映了人类记忆的运作方式——近期事件清晰可见，而遥远的记忆则较为模糊，但仍然可以获取。

展望未来

值得注意的是，正如研究人员所言，这仍处于早期研究阶段。我们尚不清楚能否将其扩展至使用 50 万个视觉标记来替代 500 万个文本标记。OCR 任务只是个例证——它证明了光学压缩的底层原理是合理的。但这是一个强有力的证明。DeepSeek 所做的正是他们创新精神的体现：他们没有随波逐流，试图构建更大的上下文窗口，而是重新审视了标记本身的根本性质。

这不仅仅是一个OCR模型。它让我们看到了未来的景象：人工智能系统可以拥有相当于1000万到2000万个标记上下文窗口，不是通过蛮力，而是通过优雅高效的光能。这提醒我们，有时，最深刻的突破来自于用全新的视角看待一个老问题。

DeepSeek OCR 论文：

https://www.arxiv.org/abs/2510.18234

~ 5 ~ Deepseek-OCR干翻了所有架构

今日暴论：

DeepSeek 又整出新东西来了，只用到原本十分之一 token，就能存下几乎一样的文字信息，这压缩比，香农看了都要流泪，冯·诺伊曼看了都要沉默。

更是直接把一堆老外给钓成了翘嘴。

昨天，DeepSeek 发布了新模型 DeepSeek-OCR，OCR 这东西咱们都熟悉，就是把图片里的文字给识别出来。

经常用微信的差友应该知道，微信客户端里的图片，被咱们点开后，是可以直接复制文字的。

没错，这就是一种 OCR 技术的应用。

但是 DeepSeek 这次的「技能 OCR」则是刚好相反，它可以把大量文字变成一张图片，作为 AI 的“记忆载体”。

是的，用文字来存储信息，已经不够满足它了。

过去的大模型，不管是什么 ChatGPT、Gemini、Llama、Qwen、还是 DeepSeek 过去的自己，在读取数据的用的都是一种方式：文字，也就是平时常说的 token。

我们写的 Prompt，会被转换成一大堆的 token 给大模型，我们提供的参考资料，会被转换成一大堆的 token 给大模型，就算是能识别图像的多模态的大模型，也是要先把图片转换成了一段文字描述，来交给大模型来做辨认才行。

但文字 token 真的就是大模型理解世界的唯一方式么？

DeepSeek 决定试一试新的路子，毕竟，如果咱们把一张图片和一段文字放在一起，前者明显可以包含下更多的信息。

比如这个描述，就不够全面

既然如此，那我们能不能直接用图片来训练大模型？

于是 DeepSeek 就开始整，结果发现这个用图片训练出来的模型，既中看，又中用。

一方面，它可以用更少的 token，来记住更多的内容。

在测试文档理解能力的任务里，DeepSeek-OCR 只用了 100 个视觉 token，就超过了需要 256 个 token 的 GOT-OCR 2.0。

再放狠点，它用不到 800 个视觉 token，就吊打了平均要 6000+ token 的 MinerU 2.0。

这就意味着、当我们让大模型开始使用图像的这种方式来记住数据了之后，模型就有能力用更少的token资源，来取得更好的表达效果。

另外，DeepSeek-OCR 还支持多种分辨率和压缩模式，来适应不同复杂度的文档：

比如说一张只有图片背景和标题文案的 PPT，可能只需要 64 个视觉token 就足够表示了。

如果这页的文字内容比较多，那就会自动切换到 Large 模式，用上最多 400 个视觉token 来记录。

如果觉得还不够的话，DeepSeek-OCR 还能支持动态调整的 Gundam 模式来记忆图片，主打一个应记就记，分清轻重缓急的记。

而且比起过去只能识别文字的传统模型来说，DeepSeek-OCR 能记住的数据还会更多。

论文里的一张柱状体，DeepSeek-OCR 能够自动把它给识别成 Excel 格式给保存下来。

文章里出现的有机化合物的分子结构图片，也能自动转化为标准的 SMILES（简化分子线性输入规范）格式存储。

不但能记住图片本身，DeepSeek-OCR 还会同时记住这张图片的位置，记住图片附近的文字在写些什么东西。。。

过去很多看不到的二维信息，都会被 DeepSeek-OCR 给再次捕获。

这玩意的价值有多大，可能大家一下都还没意识到。

这两年做大模型，除了显卡不够之外的最大问题，就是没有训练的数据了。

常规的数据集之前都用过了，想要再搞点高质量的数据集，要么偷偷去网上爬，要么花大价钱去买，再要么就是想办法自己合成。

但现在，很多过去没采集到的数据，就可以在二维信息里被采集到了。

就比如说很多论文文件，过去，大模型只能学到里面的文字信息，但是里面的各种图表，插图那都是两眼一摸黑。

但用上了 DeepSeek-OCR 之后，就可以把之前缺的这部分给无痛补上了。

实际上 DeepSeek 也是这么想的，在论文里还特意提了一嘴，说这个新模型在一张 A100 上，一天可以给大模型采集出 20 万页以上的训练数据。

所以说，在有了 DeepSeek-OCR 之后，过去的所有数据都值得用它来再识别一遍。

毫无疑问，这些数据，又会成为下一个大模型的养料。

另一方面，用二维的方式来存储数据后，整个模型运行起来也变得更省资源了。

咱都知道，我们在用大模型的时候，聊天聊的越久、上下文越长，这个模型就越容易出 bug。

这是因为大模型在运行的时候，要处理每一个单词，和其他所有单词的关系。

你把对话的长度增加一倍，整个模型的计算量就增加了四倍，增加了两倍，那整个模型的计算量就变成了原本的九倍。

这也是为啥现在大模型厂商都在给你限制上下文长度的原因之一，你要是在一个对话里聊的太嗨了的话，成本要直接卷上天去了。

而在用上了图像记忆之后，DeepSeek 可以把 token 的数量，压缩到原本的十分之一。。。

同时，还不会让性能有太大的损失。

在论文里可以看到，初出茅庐的 DeepSeek-OCR，就能用原本 1/10 的token 数量，达到原模型 96.5%的准确率。

即使哥们再狠点，给它压缩个20倍，模型的准确率，也还能保持个六成左右。。。

同时，DeepSeek 的研究人员还发现了一件好玩的事情。

他们会感觉大模型通过不同的清晰度来存储图像的方式，其实和我们人类遗忘信息的方式很像。

对我们人类来说，遗忘是一个循序渐进的过程。

刚发生的事情，就有点像是 DeepSeek 用 Gundam 模式存下来的数据，最清晰。

而随着时间的推移，这件事的重要性也会逐渐降低，存储它的格式也会从最大的 Gundam 一路降级，从 Large 一路降到最小的 Tiny，占用的 token 数量也会越来越少。

把这个概念引入到大模型里的话，咱们就可以把最近的聊天记录，用“4K HDR蓝光” 的格式来存储，而那些早年不太重要的聊天记录，则是给压缩成 480P 的文件保存。

通过这种主动遗忘的方式，是否能让大模型的上下文能力变得更强呢？

这个想法很有意思，只不过目前就连 DeepSeek 自己也没能给出一个明确的答案。

不过好在 DeepSeek-OCR 还是和过去一样开源的，相信这个问题，要不了多久就会变成热门，整出不少新东西来。

最后，提到开源，我还注意到另外一件事。。。

这次研究不但是 DeepSeek 自己的成果，也是开源社区集体的胜利

比如训练数据里，用到了华为的 Wukong 数据集，在生成样本文字时，借助了百度的 PaddleOCR，而在图像特征提取部分，核心组件竟然是 Meta 开源的 SAM，在视觉语义理解层面，还整合了 OpenAI 的 CLIP 模型。

正是这些来自全球的开源成果，被 DeepSeek 重新编织成了一个能“用图片思考”的 AI。

所以，R2 什么时候会来呢。

,,,

广州城市开发者社区

欢迎加入我们的广州开发者社区，与优秀的开发者共同成长！

更多推荐

2026冲刺用！AI论文平台千笔 VS 文途AI，专科生写作神器！

广州城市开发者社区

收藏 |小白也能看懂！AI大模型如何赋能企业降本增效，特斯拉蚂蚁集团案例深度解析

广州城市开发者社区

# 第二章：ClaudeCode核心功能（详细版）

广州城市开发者社区

所有评论(0)

查看更多评论

whaosoft-143

@weixin_49587977

已为社区贡献49条内容

51c视觉~OCR~合集1

whaosoft-143

一、OCR~合集 总结开源ocr

#Surya

#EasyOCR

#MMOCR

#PaddleOCR

#CnOCR

#COCO-Text V2.0

#SynthText in the Wild dataset

#Uber Text dataset

#Chinese Text Dataset in the Wild(CTW)

#MSRA Text Detection 500 Database(MSRA-TD500)

#Ollama-OCR

二、PaddleOCR~合集 3.0

#PaddleOCR 2.9

#PaddleOCR 3.0

#PaddleOCR 3.2

#PaddleOCR-VL-1.5

三、CV+OCR~弧形文字识别

四、MonkeyOCR

五、OCR-Reasoning

六、贝叶斯分类器在OCR中的应用

七、MonkeyOCR v1.5

八、POINTS-Reader

九、OCRBench v2

十、HunyuanOCR

十一、EasyOCR~条码字符识别

十二、DeepSeek-OCR 2

十三、DeepSeek-OCR

所有评论(0)

whaosoft-143

一、OCR~合集总结开源ocr