MinerU 多语言 OCR 实战：--lang 参数如何用 12 个模型覆盖 37 种语言

MinerU 多语言 OCR 实战--lang 参数如何用 12 个模型覆盖 37 种语言【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU某贸易团队处理一批扫描版合同同一批 PDF 里混着俄文、阿拉伯文和中文用默认 OCR 模型跑出来的俄文页几乎全是乱码。MinerU 的--lang参数就是为此准备的在解析时指定文档语言pipeline 后端会加载对应的 PP-OCRv5 多语言识别模型覆盖法语、西班牙语、葡萄牙语、俄语、韩语等 37 种语言的文字识别。 能力速览2.1.0 起 pipeline 后端内置 PP-OCRv5 多语言识别模型官方口径平均精度涨幅超 30%通过 12 个语言档位语言模型组覆盖 37 种语言含拉丁语系、斯拉夫语系、阿拉伯语系、印度语系支持单文件指定语言、API 批量按文件分配语言兼容en、ru等常用别名仅作用于 pipeline 后端hybrid / vlm 后端忽略该参数语言码归一化逻辑集中在mineru/utils/ocr_language.py便于查证 最小可运行示例安装后首次运行会自动下载模型处理一份俄文合同 PDF 只需一条命令mineru -p contract_ru.pdf -o output/ --backend pipeline --lang east_slavic预期输出output/contract_ru/pipeline/目录下生成contract_ru.md与切分图片Markdown 正文为俄文文本。跑对的标准是正文无方框乱码、专有名词人名、地名拼写正确、表格以 Markdown 表格形式保留。 原理与架构--lang参数在入口处先经过归一化normalize_ocr_model_lang()把en、japan归到ch把ru、be、uk归到east_slavic把ar、fa、ur等归到arabic。归一化后的 key 决定 pipeline 加载哪套识别模型与字典检测模型是共用的换语言只切换识别阶段。关键设计决策一个检测模型 多套识别模型文本检测对不同语言通用因此所有语言共享 det 模型识别模型按语系拆分ch、korean、arabic、east_slavic、cyrillic、devanagari等而不是每种语言一个模型。这是 12 个档位能覆盖 37 种语言的直接原因——同一语系共享一套字典和权重。语言码归一化而非直接透传公开入口只暴露 12 个枚举值见PUBLIC_OCR_LANGUAGES但接受en、ru、hi等别名并在入口统一收敛。好处是用户可以用 ISO 习惯写法内部模型 key 不受影响。仅绑定 pipeline 后端多语言 OCR 依赖检测 识别两阶段只有 pipeline 后端具备该链路hybrid / vlm 后端由视觉模型直接出文本lang参数对其无效文档中已明确标注。 进阶用法从单一场景到复杂场景混合语言文档按文件分流批量目录里语言混杂时逐文件指定语言比整批共用一个模型更准。API 的lang_list长度与文件数一致时按序对应长度不一致时取首值广播到所有文件逻辑见mineru/cli/fast_api.py的normalize_lang_list{ lang_list: [east_slavic, arabic, ch], backend: pipeline, parse_method: auto }适用场景归档型文档库一次提交多国合同。注意lang_list顺序必须与提交的文件顺序严格一致错位会导致整批识别降级。手写与日韩繁混合文档的精度切换默认ch对应 PP-OCRv4 识别模型ch_server切换到 PP-OCRv5 server 档强化手写与特殊字符1.8w 字典mineru -p handwriting_notes.pdf -o output/ --backend pipeline --lang ch_server适用场景扫描的手写笔记、日文与繁中混排的旧文档。注意官方测试结论是 v5 server 对手写有提升、普通印刷文档精度略低于 v4纯印刷体仍建议保留默认ch。大文件按页段切分长文档配合-s/-e页码区间分段解析便于失败重跑与并行mineru -p report_500p.pdf -o output/ --backend pipeline \ --lang cyrillic -s 0 -e 99适用场景数百页扫描件。注意页码从 0 起算-e为闭区间重跑已完成的段时调整区间即可不必整本重新解析。 调优与排障西里尔文字输出乱码或方框症状俄文、乌克兰文正文出现替换字符原因默认ch模型不覆盖西里尔字母强行识别产生乱码解法改用--lang east_slavic俄/白俄/乌或--lang cyrillic覆盖俄语系及周边 30 余种使用西里尔字母的语言报 Language xxx not supported症状命令行或 API 启动即抛ValueError原因传入了不在 12 个公开档位内的语言码如es、pt西班牙语、葡萄牙语实际由ch档位下的拉丁语能力覆盖解法按mineru -h中--lang的枚举选择西、法、德等拉丁语系文档直接使用默认ch首次运行耗时异常长症状第一批文档处理极慢疑似卡死原因首次运行按语言档位自动下载对应 OCR 模型解法模型下载慢时设置环境变量MINERU_MODEL_SOURCEmodelscope切换免代理源见demo/demo.py注释下载完成后同档位文档不再重复下载 效果基准下表第一项来自官方 2.1.0 版本说明其余为示例数据请以官方 Benchmark 为准指标PP-OCRv4PP-OCRv5变化官方口径37 语言平均识别精度基线基线提升超 30%官方 changelog俄语合同识别准确率示例100 份84.5%93.1%8.6%阿拉伯文识别准确率示例50 份81.2%90.4%9.2%单页处理耗时示例V100 / 72 DPI1.9 s2.1 s10.5%解读提升最显著的是非中英文档的识别精度原因是 v4 时代非中文语言基本靠ch模型顺带识别v5 为各语系训练了专属识别模型与字典属于从能读到读准的差距。配置参考--lang完整取值默认ch# 推荐默认ch中文/英文/日文/繁中/拉丁语系覆盖 37 语言中的主体 # 按场景切换 # korean 韩英混合 推荐韩文合同 # ta / te / ka 泰米尔/泰卢固/卡纳达 推荐印度语种文档 # th / el 泰英 / 希腊英混合 推荐对应语种扫描件 # arabic 阿拉伯语系 9 语种 推荐阿语/波斯语/乌尔都语文档 # east_slavic 俄/白俄/乌/英 推荐东斯拉夫语种合同 # cyrillic 西里尔字母 30 语言 推荐哈萨克、蒙古等西里尔文字 # devanagari 天城文 14 语种 推荐印地语/马拉地语文档 # ch_server PP-OCRv5 中英日繁手写 推荐手写与特殊字符场景 mineru -p docs/ -o output/ --backend pipeline --lang ch参数默认值推荐值说明--langch按文档语言选择仅 pipeline 后端生效--backendhybrid-enginepipeline需要多语言 OCR 时必须指定-s/-e0/None大文件分段页码区间从 0 起算MINERU_MODEL_SOURCEhuggingface国内网络下modelscope控制模型下载源相关源码与文档mineru/utils/ocr_language.py语言码定义与归一化、docs/zh/usage/cli_tools.mdCLI 参数说明、docs/zh/reference/changelog.md2.1.0 多语言更新记录。多语言 OCR 在 MinerU 中的定位是 pipeline 后端的一个可选精度开关默认ch已覆盖中英日繁与拉丁语系遇到其他语系时按语系切一档即可无需改代码。建议先用默认配置跑一批真实文档把识别偏差集中在哪个语系定位出来再针对性调整--lang而不是全量切换。本文基于 MinerU 3.4.4 源码整理PP-OCRv5 多语言支持自 2.1.0 引入不同版本的默认后端与模型档位可能不同请以实际版本为准。【免费下载链接】MinerUTransforms complex documents like PDFs and Office docs into LLM-ready markdown/JSON for your Agentic workflows.项目地址: https://gitcode.com/GitHub_Trending/mi/MinerU创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考