MinerU 多语言 OCR 配置指南：12 个语言模型与 --lang 参数调优

MinerU 多语言 OCR 配置指南：12 个语言模型与 --lang 参数调优

【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU

本文聚焦 MinerU pipeline 后端的多语言 OCR，讲清--lang的 12 个语言模型取值、别名映射和调优参数，帮你为外文文档选对识别模型。

功能全景：多语言 OCR 能力边界

MinerU 2.1.0 起，pipeline 后端默认识别模型更新为 PP-OCRv5 多语种模型，官方 changelog 标注其支持法语、西班牙语、葡萄牙语、俄语、韩语等 37 种语言，平均精度涨幅超 30%。在此之上，--lang又暴露了 12 个专用语言模型，覆盖东欧斯拉夫语系、阿拉伯语系、西里尔文和印度语系等默认模型覆盖不到或覆盖较弱的文字体系。需要注意：--lang仅对 pipeline 后端生效，hybrid 与 vlm 后端会忽略该值。

快速跑通：一条命令解析外文文档

mineru -p <input.pdf> -o output/ -b pipeline -l ch

首次运行会自动下载对应语言模型，网络无法访问 HuggingFace 时先执行export MINERU_MODEL_SOURCE=modelscope切换模型源。运行完成后，output/目录下会生成以文件命名的目录，包含 Markdown 结果与抽取出的图片，OCR 识别出的文本已合入 Markdown 正文。

分模块说明：按文档文字体系选模型

12 个语言模型覆盖哪些文字

每个--lang取值对应一个专用识别模型，语言说明以--help输出为准。下表按文字体系归类，便于按文档实际用字快速定位：

别名短码：en、ru、ar 等可直接传

validate_public_ocr_lang等校验逻辑会把兼容别名规范到实际模型 key，例如en、japan、chinese_cht、latin归一为ch，ru、be、uk归一为east_slavic，hi、mr、ne归一为devanagari。这样脚本里可以按 ISO 语言码传参而不必记忆模型 key：

mineru -p <doc_ru.pdf> -o output/ -b pipeline -l ru

• ru等价于east_slavic，走俄语等东斯拉夫语系专用模型
• 约 32 个西里尔文字别名（bg、kk、ky等）统一映射到cyrillic
• 不在白名单的语言值会直接抛错并列出合法取值

ch 与 ch_server：默认模型与手写场景

两者都面向中英日繁混合文档，区别在底层模型代次。1.3.12 版本起ch_server指向 PP-OCRv5_rec_server，强化手写场景和特殊字符；默认ch仍保留 PP-OCRv4_rec_server_doc，在一般文档类别上精度略优于 v5 server，手写场景则相反。

扫描件与纯文本文档：配合 -m 使用

-m决定每页走文本抽取还是 OCR：auto自动判定，txt强制抽取，ocr强制识别。对扫描件，auto 判定若偏保守会走文本抽取导致输出几乎为空，此时应显式指定ocr：

mineru -p <scan.pdf> -o output/ -b pipeline -m ocr -l arabic

• -m ocr与--lang必须配合，否则指定语言模型不会参与识别
• -s/-e指定起止页码（从 0 开始），长文档可分段试跑

配置与调优：参数、取值与依据

• MINERU_PROCESSING_WINDOW_SIZE→ 默认 64，大页数外文文档内存吃紧时降至 16~32 → 该窗口直接决定单进程同时持有的页面数与内存占用
• MINERU_PDF_RENDER_THREADS→ 默认 4，高核 CPU 可提到 8 → 控制 PDF 渲染 worker 并发，只影响渲染阶段速度
• MINERU_MODEL_SOURCE→ 默认 huggingface，无法访问时设为modelscope→ 决定首次运行下载 12 个语言模型走哪条链路
• -s/-e→ 0 到目标页码 → 先用 10 页以内区间验证--lang选择，再放大到全文
• MINERU_FORMULA_ENABLE/MINERU_TABLE_ENABLE→ 不含公式、表格的纯外文文档设为false→ 跳过对应模型推理，缩短单文档耗时

多语言相关的版本事实，供核对升级收益（数据均来自仓库 changelog，无第三方基准）：

典型场景：按文字体系配置

场景一：俄语文档扫描件

• 问题：西里尔文字扫描 PDF，默认 ch 模型字典不覆盖，识别结果整段乱码
• 做法：-b pipeline -m ocr -l east_slavic，纯西里尔小语种（保加利亚语、哈萨克语等）改用-l cyrillic
• 效果：走对应文字体系专用模型，30+ 种西里尔文字语言在同一模型下识别

场景二：中英混排的手写会议纪要

• 问题：默认 ch（v4 代模型）对手写覆盖有限
• 做法：--lang ch_server，其余参数不变
• 效果：PP-OCRv5_rec_server 强化手写与特殊字符，1.8w 字典对中英日繁混排保持覆盖

场景三：多语言混排的目录批处理

• 问题：同一目录下混有英文、西班牙语、阿拉伯语文档，统一跑ch会出现个别语种精度差
• 做法：按语言分组，每组单独执行mineru并指定对应--lang；默认模型已覆盖的 37 种语言（法语、西班牙语等）可留在 ch 组
• 效果：每组各用最优模型，且分组后单任务内存占用更可控

常见坑：现象、原因与解法

• 传了--lang但结果没有变化 → 该参数仅用于 pipeline 后端，hybrid / vlm 后端直接忽略 → 切换-b pipeline或调整预期
• 传en、latin以为是纯拉丁语专用模型 → 别名只做兼容映射，en/latin实际归一到ch→ 以 12 个合法取值为准，不确定时查mineru --help
• 扫描件输出几乎为空 → auto 判定走了文本抽取而非 OCR → 强制-m ocr并配合--lang
• 手写文档错字偏多 → 默认ch仍是 PP-OCRv4_rec_server_doc → 改传--lang ch_server使用 v5 模型
• 阿拉伯文、西里尔小语种精度不理想 → 默认模型字典未覆盖对应文字体系 → 改用-l arabic或-l cyrillic专用模型

结语

按文字体系选对--lang，再配合-m ocr和窗口参数，即可覆盖绝大多数多语言 OCR 场景。本文基于 MinerU 3.4.4 编写，取值以实际版本--help为准。

【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU