尧图网站建设 
MinerU 多语言 OCR 完整指南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 解析最常见的真实情况。MinerU 2.1.0 的多语言 OCR 识别接入了 PP-OCRv5 文本识别模型覆盖 37 种语言官方给出的平均精度涨幅超过 30%。这篇文章讲三件事语言路由是怎么工作的、代码和 CLI 各怎么调、结果不对时按什么顺序排查。37 种语言是如何被同一条流水线接住的整个识别环节分四步。第一步检测模型ch_PP-OCRv5_det_infer.pth统一负责文本区域定位不同语言共用这一个 det 模型。第二步系统判断当前文本块属于哪个语系。第三步按语系分发到对应的识别模型和字典文件这是多语言精度提升的关键——每个语系用自己的 rec 模型而不是拿一个通用模型硬套。第四步所有语系的输出走同一套后处理保证结构一致。这张图可以放在 pipeline 的语境里看文本 OCR 只是模型层中的一个环节上游是 layout 检测下游是 markdown/JSON 输出。多语言变化只发生在识别模型 字典这一层其余环节不动。语言与模型对照什么语言走哪个模型37 种语言归入五个语系各语系的识别模型与字典文件如下语系代表语言识别模型字典文件东亚中文、英文、日文、韩文、繁体中文ch_PP-OCRv5_rec_server_infer.pthppocrv5_dict.txt拉丁法、西、葡、德、意等latin_PP-OCRv5_rec_infer.pthppocrv5_latin_dict.txt斯拉夫eslav俄语、白俄罗斯语、乌克兰语eslav_PP-OCRv5_rec_infer.pthppocrv5_eslav_dict.txt阿拉伯阿拉伯语arabic_PP-OCRv3_rec_infer.ptharabic_dict.txt印度语系泰米尔、泰卢固、卡纳达、梵文各语言对应 PP-OCRv3 rec 模型各语言对应字典有两个细节值得注意。一是语言码有归一化传en、japan、latin实际都会落到ch模型因为东亚模型的字典本身覆盖了中英日繁和拉丁字母。二是ru、be、uk这类细粒度代码会归到east_slavic这个语系级模型而不是各自建模型。快速上手两行代码跑通一个多语言文档from mineru import MinerU mineru MinerU(langauto) result mineru.process(contract.pdf)等价的命令行写法是一行mineru -p contract.pdf -o output/ --lang latin区别在于auto让系统按语系自动分发适合不确定文档语言构成的场景指定语言码则跳过判断、直接绑定对应语系的模型单语文档上更稳也更快。选型与调参auto 什么时候该用场景建议语言已知且单一如整本俄文手册直接指定语言码精度最高中英日繁混排用ch这几个语言在模型层是同一个语言构成未知、多语系混排用auto交给语系路由大文档和内存紧张时真正有效的参数就三个batch_size批量识别的批大小显存吃紧时减小它比降并发更直接。max_workers控制并发线程数核数少的机器设 2 即可。language_confidence语系判定的置信度阈值。auto 模式下反复选错模型时把阈值调低让判定更宽松比换模型见效快。PP-OCRv4 到 v5 的效果数据指标PP-OCRv4PP-OCRv5变化平均识别准确率85.2%92.7%7.5 个百分点多语言混合识别准确率72.1%89.3%17.2 个百分点处理速度3.2 页/秒3.8 页/秒约 19%内存占用512 MB480 MB-42 MB这组数字里最有信息量的是第二行混合语系场景的增益明显大于单语场景这正是语系路由架构带来的收益。排查顺序三类常见问题的处理路径现象可能原因处理方式语言识别不准跑成了别的语系的模型文档语言构成不典型或置信度阈值偏高明确指定语言码或调低language_confidence再试 auto混合语言文档整体效果差指定了单一语系模型只对该语系优化改用 auto 模式重跑让路由按块分发某个具体语言识别率偏低该语言的字典文件缺字或训练覆盖不足核对 字典目录 中对应字典是否完整升级到最新模型包排查时建议先用单页小样本验证确认语言路由对了再放大到整本能省掉大量无效的全量重跑。写在最后MinerU 2.1.0 的多语言 OCR 把识别这一环做成了按语系分发检测统一、识别分治、后处理收口。选型上记住一条就够了——语言确定就指定语言码不确定就 auto效果不满意先从language_confidence和字典文件查起。下一步可以直接拿一份自己的多语言 PDF跑一遍--lang auto和指定语言码各一次对比输出差异体感会很快建立起来。本文基于 MinerU 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），仅供参考 MinerU 多语言 OCR 完整指南：37 种语言怎么跑、模型怎么选
MinerU 多语言 OCR 完整指南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 解析最常见的真实情况。MinerU 2.1.0 的多语言 OCR 识别接入了 PP-OCRv5 文本识别模型覆盖 37 种语言官方给出的平均精度涨幅超过 30%。这篇文章讲三件事语言路由是怎么工作的、代码和 CLI 各怎么调、结果不对时按什么顺序排查。37 种语言是如何被同一条流水线接住的整个识别环节分四步。第一步检测模型ch_PP-OCRv5_det_infer.pth统一负责文本区域定位不同语言共用这一个 det 模型。第二步系统判断当前文本块属于哪个语系。第三步按语系分发到对应的识别模型和字典文件这是多语言精度提升的关键——每个语系用自己的 rec 模型而不是拿一个通用模型硬套。第四步所有语系的输出走同一套后处理保证结构一致。这张图可以放在 pipeline 的语境里看文本 OCR 只是模型层中的一个环节上游是 layout 检测下游是 markdown/JSON 输出。多语言变化只发生在识别模型 字典这一层其余环节不动。语言与模型对照什么语言走哪个模型37 种语言归入五个语系各语系的识别模型与字典文件如下语系代表语言识别模型字典文件东亚中文、英文、日文、韩文、繁体中文ch_PP-OCRv5_rec_server_infer.pthppocrv5_dict.txt拉丁法、西、葡、德、意等latin_PP-OCRv5_rec_infer.pthppocrv5_latin_dict.txt斯拉夫eslav俄语、白俄罗斯语、乌克兰语eslav_PP-OCRv5_rec_infer.pthppocrv5_eslav_dict.txt阿拉伯阿拉伯语arabic_PP-OCRv3_rec_infer.ptharabic_dict.txt印度语系泰米尔、泰卢固、卡纳达、梵文各语言对应 PP-OCRv3 rec 模型各语言对应字典有两个细节值得注意。一是语言码有归一化传en、japan、latin实际都会落到ch模型因为东亚模型的字典本身覆盖了中英日繁和拉丁字母。二是ru、be、uk这类细粒度代码会归到east_slavic这个语系级模型而不是各自建模型。快速上手两行代码跑通一个多语言文档from mineru import MinerU mineru MinerU(langauto) result mineru.process(contract.pdf)等价的命令行写法是一行mineru -p contract.pdf -o output/ --lang latin区别在于auto让系统按语系自动分发适合不确定文档语言构成的场景指定语言码则跳过判断、直接绑定对应语系的模型单语文档上更稳也更快。选型与调参auto 什么时候该用场景建议语言已知且单一如整本俄文手册直接指定语言码精度最高中英日繁混排用ch这几个语言在模型层是同一个语言构成未知、多语系混排用auto交给语系路由大文档和内存紧张时真正有效的参数就三个batch_size批量识别的批大小显存吃紧时减小它比降并发更直接。max_workers控制并发线程数核数少的机器设 2 即可。language_confidence语系判定的置信度阈值。auto 模式下反复选错模型时把阈值调低让判定更宽松比换模型见效快。PP-OCRv4 到 v5 的效果数据指标PP-OCRv4PP-OCRv5变化平均识别准确率85.2%92.7%7.5 个百分点多语言混合识别准确率72.1%89.3%17.2 个百分点处理速度3.2 页/秒3.8 页/秒约 19%内存占用512 MB480 MB-42 MB这组数字里最有信息量的是第二行混合语系场景的增益明显大于单语场景这正是语系路由架构带来的收益。排查顺序三类常见问题的处理路径现象可能原因处理方式语言识别不准跑成了别的语系的模型文档语言构成不典型或置信度阈值偏高明确指定语言码或调低language_confidence再试 auto混合语言文档整体效果差指定了单一语系模型只对该语系优化改用 auto 模式重跑让路由按块分发某个具体语言识别率偏低该语言的字典文件缺字或训练覆盖不足核对 字典目录 中对应字典是否完整升级到最新模型包排查时建议先用单页小样本验证确认语言路由对了再放大到整本能省掉大量无效的全量重跑。写在最后MinerU 2.1.0 的多语言 OCR 把识别这一环做成了按语系分发检测统一、识别分治、后处理收口。选型上记住一条就够了——语言确定就指定语言码不确定就 auto效果不满意先从language_confidence和字典文件查起。下一步可以直接拿一份自己的多语言 PDF跑一遍--lang auto和指定语言码各一次对比输出差异体感会很快建立起来。本文基于 MinerU 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），仅供参考