dots.ocr

你有没有遇到过这种情况：打开一份扫描版的老论文，里面密密麻麻的文字，想复制却复制不了；或者是一张外语海报，想提取文字却只能一个个字敲？传统的 OCR 工具碰到藏文、梵文这类"小语种"，要么直接报错，要么识别出来满屏乱码。而刚刚火爆 GitHub 的一个新项目，用一个模型就搞定了这件事——它叫 dots.ocr（现已更名为 dots.mocr），来自小红书团队，在 GitHub 上已经斩获近 9000 颗星。

图1：dots.ocr 项目 Logo，视觉风格简洁专业

项目地址：https://github.com/rednote-hilab/dots.ocr

背景故事：为什么需要"通用"文档解析？

在 dots.ocr 出现之前，文档解析领域长期存在两条技术路线。专用 OCR 引擎（如 Tesseract）精度高，但只支持主流语言，对藏文、梵文等罕见文字束手无策。通用多模态大模型（如 GPT-4V）理解能力强，但在细粒度版面还原方面表现一般——它们能"读懂"文档，却难以精确输出每个段落标题、表格、公式各自的坐标和内容。

dots.ocr 的出现，恰好弥合了这两条路线之间的鸿沟。该项目由小红书 REDNOTE AI Lab 主导开发，2025 年 7 月发布 v1.0 版本，2026 年 3 月升级至 v1.5（品牌重塑为 dots.mocr），核心目标是让一个 3B 参数的视觉语言模型（VLM）完成"通用文档解析"这一任务——无论文档是中文 PDF、藏文古籍、俄语论文还是日语合同，都能一次性输出结构化的解析结果。

技术架构：一个模型，多种能力

dots.ocr 本质上是一个基于 Qwen 架构的 3B 参数视觉语言模型，团队选择了"在相对轻量的模型规模下追求最优性能"的路线。

架构设计上有几个值得关注的细节：

视觉编码与 LLM 的连接：模型采用 Qwen-VL 系列作为基础架构，通过专门的视觉编码器将文档图像转换为 token 序列，再由 LLM 生成结构化输出。相比纯端到端的方法，这种设计在保持多语言理解能力的同时，对版面元素的检测（Layout Detection）和识别（OCR）具有更强的可控性。

输出格式的统一设计：用户可以为不同任务指定不同的 Prompt Mode（提示模式），模型统一输出 JSON 格式的结构化结果，包含每个版面元素的坐标（BBOX）、类别（标题/表格/公式/图片等）和提取的文字内容。这种设计让下游应用（知识库构建、RAG 管道等）可以非常方便地消费解析结果。

vLLM 原生集成（重要里程碑）：2026 年初，dots.mocr 正式合并进入 vLLM 主线版本（v0.11.0+），这意味着用户可以直接用标准的 vLLM OpenAI 兼容 API 部署模型，无需额外适配层。这是一个重大进步——既降低了部署门槛，又引入了 vLLM 的 PagedAttention 内存优化、Tensor Parallelism 多卡推理等能力。

核心功能：能做什么？

根据 GitHub 仓库和论文披露的信息，dots.ocr 的核心能力可以分为以下几类：

多语言文档版面解析：这是最核心的能力。模型可以识别文档中的标题、正文段落、表格（输出 HTML 格式）、数学公式（输出 LaTeX 格式）、图片图注、脚注、页眉页脚等十余种版面元素，并按人类阅读顺序排序输出。在 OmniDocBench 等权威基准测试中，dots.mocr 取得了 1059 分的 TextEdit 得分和 1210 分的 Read Order 得分，超越了多数 3B 参数级别的专业 OCR 模型，也大幅优于 Gemini 2.5 Pro 等通用大模型。

结构化图形解析：dots.mocr-svg 变体专门针对图表、流程图、化学结构式进行优化，能够直接将图形元素解析为 SVG 代码。这意味着用户不只是能"识别"一张图表，而是能获得可编辑的矢量图形表示——在 UI 设计自动化、图表数据提取等场景中有极高的实用价值。

网页截图解析：给定一张网页截图，dots.ocr 可以提取其中的文本内容，并保持与原网页一致的阅读顺序和版面结构，这对于爬虫替代、网页存档分析等场景非常有用。

场景文字检测（Scene Spotting）：除了印刷文档，模型也能处理自然场景中的文字（如街景截图、海报照片等），输出文字区域和内容。

多语言覆盖：项目名称中"Multilingual"并非虚言——从 README 的示例来看，已验证支持藏文、藏语、中文繁体、俄语、梵文、印地语等数十种语言文字。

图2：dots.ocr 网页截图解析效果，输出结构化文本内容

上手体验：CLI、Web UI 还是 API？

dots.ocr 提供了三种使用方式，覆盖了从个人用户到企业部署的各种场景。

Gradio Web UI（推荐尝鲜）：项目提供了开箱即用的 Gradio 界面，用户只需要一行命令 python3 demo/demo_gradio.py 即可启动本地可视化界面，上传 PDF 或图片后直接查看解析结果。这种方式对非技术用户非常友好，适合快速验证模型效果。

命令行解析：通过 python3 dots_mocr/parser.py <文件路径> 可以直接解析单张图片或 PDF，支持 --prompt 参数指定不同的解析模式（纯文本 / 版面检测 / 全量解析），输出 JSON 和 Markdown 两个文件。

vLLM API（生产级部署）：对于需要在业务系统中集成的场景，推荐使用 vLLM 部署方式。启动 vLLM 服务后，通过 OpenAI 兼容的 REST API 调用模型，支持批量推理、并发请求等生产环境必备的功能。官方还提供了 docker-compose.yml，一键启动带 GPU 支持的容器化服务。

模型权重获取：权重托管在 Hugging Face 和 ModelScope 上，通过官方工具脚本 tools/download_model.py 可以一键下载（约 7GB），需要注意存储路径不要包含句点符号（如不要用 dots.mocr 作为目录名），这是当前版本的已知限制。

局限与挑战：不能做什么？

作为一个小团队主导的开源项目，dots.ocr 也有其局限性，官方 README 中坦诚列出了以下几点：

复杂表格和公式仍是痛点：由于模型参数量限制在 3B，在处理高度复杂的嵌套表格（如跨行跨列的财务报表）和多行嵌套的数学公式时，识别准确率仍有提升空间。官方也明确表示，对于这类任务，dots.mocr-svg 变体是当前的最佳方案，但仍未达到足够稳健的生产级水准。

结构化图形的 SVG 解析能力有限：虽然 dots.mocr-svg 在多个基准测试中取得了领先成绩，但作者坦言在某些图形类型（如 Design2Code、Genexam 等）上，3B 模型的能力边界仍然可见。

解析失败率：相比上一版本，当前的失败率已大幅降低，但极端情况的边界案例（如严重扭曲的扫描件、极小字号文档）仍可能出现解析失败。

CPU 推理性能：纯 CPU 推理速度较慢，官方建议使用 GPU 以获得可接受的推理速度。对于没有 GPU 资源的用户，HuggingFace 官方 Spaces 提供了在线体验（但需排队等待）。

行业意义与增长态势

dots.ocr 的出现，在文档解析领域掀起了不小的波澜。数据显示，GitHub 仓库在不到一年的时间内积累了接近 9000 颗星、800 次 fork、146 个 open issues，显示出极高的社区活跃度。

从技术趋势看，dots.ocr 代表了一个重要方向：专用轻量模型在特定任务上超越通用大模型。同样面对一份复杂 PDF，Gemini 3 Pro（超大杯）虽然参数规模数十倍于 dots.ocr，但具体到"文档版面还原"这个细分任务，dots.mocr 的平均得分反而更高（1124 vs 1210，在某些子项上领先明显）。这说明在 OCR 这类"看得见、摸得着"的任务上，经过专项优化的中等规模模型具有极高的性价比。

此外，vLLM 的官方集成是一个标志性事件——它意味着文档解析能力正式进入了 LLM 生产工具链的标准选项，未来在 RAG 管道、知识库构建、AI 阅读助手等方向的应用前景非常广阔。

对于开源社区而言，dots.ocr 的另一个价值在于降低了多语言文档处理的门槛。传统上，构建一个支持藏文、梵文等罕见语言的多语言 OCR 系统需要大量的领域数据和调优工作，而现在只需一个开源模型加几行代码即可实现——这对学术研究、小语种保护、非英语国家的数字化项目都有积极的推动作用。