夜雨聆风LAWYER × AI
两套离线OCR项目实测：PP-OCRv6 Browser与OpenDataLoader怎么选？
副标题：一个负责快速认字，一个负责完整解析PDF，EasyOCR与RapidOCR的坑也要说清楚
测试与资料整理时间：2026年7月30日（UTC+8）。 本文比较的是两个可以独立使用的本地项目，而不是两个单独的OCR模型。测试材料为同源的虚构法律文书，不涉及真实当事人信息。受样本、模型配置、统计口径和本机环境影响，结果仅供部署与选型参考。
最近我在本机搭了两套离线OCR项目。
第一套是PP-OCRv6 Browser Web。把图片或PDF拖进网页，浏览器直接完成识别，结果可以复制，也可以导出Markdown和文字框选图。
第二套是OpenDataLoader PDF本地解析工作台。它会识别文字，并继续处理PDF版面、阅读顺序、标题、段落、列表和表格，最后输出Markdown、JSON、HTML或纯文本。
两套项目都能在本机运行，也都用到了PP-OCRv6，不过定位和处理流程不同。
怎么选，可以先看任务量和输出要求：
如果只是想快速识别图片或几份PDF，PP-OCRv6 Browser更简单；如果要处理整批PDF，并把结果继续交给AI、知识库或其他程序，OpenDataLoader更完整。
01
一、这次比较的是两个完整项目
项目名称、OCR引擎和OCR模型经常被混为一谈。
PP-OCRv6 Browser Web，是我基于PaddleOCR浏览器版工具包制作的本地网页项目。它可以直接选择PP-OCRv6 Small或Medium模型。
OpenDataLoader PDF，则是一套本地PDF解析项目。OCR只是其中一个环节，底层引擎可以更换。本次第一次采用EasyOCR，第二次改为RapidOCR；而RapidOCR实际加载的文字检测和识别模型，正是PP-OCRv6 Small。
本文的比较对象如下：
项目一：PP-OCRv6 Browser Web；
项目二：OpenDataLoader PDF本地解析工作台。
EasyOCR和RapidOCR都属于OpenDataLoader测试过程中采用的OCR方案，没有增加第三、第四个测试项目。
02
二、两个项目的前后端有什么不同
两个项目都有网页界面，但它们的内部结构并不一样。
1. PP-OCRv6 Browser：主要工作都在浏览器完成
这个项目由HTML、CSS和JavaScript组成。启动时虽然需要运行一个Python HTTP服务，但它只负责把网页、模型和运行文件提供给浏览器，不负责接收文件或执行OCR。
实际流程是：
图片或PDF进入浏览器->PDF.js逐页渲染->PP-OCRv6本地模型识别->浏览器生成文字和可视化结果
默认推理后端是WASM，也可以尝试WebGPU。模型和运行库都已放在本机，识别文件不需要发送到云端。
这种结构的优点是简单、直观。只要网页能够正常打开，选择文件后就可以开始识别。
2. OpenDataLoader：网页前端加本地后端
OpenDataLoader项目则是完整的前后端架构。
网页前端负责选择PDF、设置参数、预览原文件和查看结果；FastAPI本地服务负责接收任务、保存结果和提供下载；OpenDataLoaderHybrid服务再调用Docling和OCR引擎完成识别与版面解析。
实际流程是：
PDF进入网页->本机FastAPI服务->OpenDataLoader Hybrid与Docling->OCR引擎识别->版面和结构整理->输出多种格式
它需要同时运行前端、本地接口和Hybrid解析服务，部署明显比PP-OCRv6 Browser复杂。整个流程仍然只使用127.0.0.1或localhost，文件不会上传到云端。
03
三、两个项目的功能差异
比较项目 · PP-OCRv6 Browser Web · OpenDataLoader PDF
比较项目项目定位
PP-OCRv6 Browser Web浏览器本地OCR工具
OpenDataLoader PDF本地PDF解析工作台
比较项目支持输入
PP-OCRv6 Browser WebPNG、JPG、WebP和PDF
OpenDataLoader PDFPDF
比较项目OCR位置
PP-OCRv6 Browser Web浏览器本地执行
OpenDataLoader PDF本机Hybrid后端执行
比较项目OCR方案
PP-OCRv6 Browser Web直接使用PP-OCRv6 Small或Medium
OpenDataLoader PDF可以更换OCR引擎，本次最终采用RapidOCR和PP-OCRv6 Small
比较项目模型体积
PP-OCRv6 Browser WebSmall首次约30MB，Medium首次约132MB
OpenDataLoader PDF除OCR模型外，还包括Python、Java、版面和表格解析组件
比较项目主要输出
PP-OCRv6 Browser Web识别文本、连续或分页Markdown、文字框选图
OpenDataLoader PDFMarkdown、JSON、HTML、纯文本和ZIP结果包
比较项目原文件查看
PP-OCRv6 Browser Web显示图片或PDF首页预览
OpenDataLoader PDF内嵌查看原PDF
比较项目处理能力
PP-OCRv6 Browser Web图片和PDF逐页识别，适合直接复制和人工查看
OpenDataLoader PDF可选页码、密码、表格模式、页眉页脚、原始换行、图片嵌入和敏感信息替换
比较项目部署门槛
PP-OCRv6 Browser Web较低，启动静态HTTP服务即可
OpenDataLoader PDF较高，需要前端、FastAPI、Hybrid服务、Python和Java运行环境
比较项目更适合的任务
PP-OCRv6 Browser Web少量材料、即时识别、问题页面复核
OpenDataLoader PDF批量PDF、结构化整理、知识库和后续AI流程
可以这样理解：
可以把PP-OCRv6 Browser理解为一台随开随用的本地扫描仪；OpenDataLoader则是一条把PDF拆解、整理并送往下一道工序的生产线。
04
四、识别效果：三个数字不能直接排成名次
两份测试都使用了授权委托书和民事起诉状，合计3页，内容来自同一套虚构法律文书。
测试记录如下：
项目或配置 · 严格字符准确率 · 主要表现
项目或配置PP-OCRv6 Browser
严格字符准确率97.52%
主要表现核心法律信息没有明显漏识，差异主要来自阅读顺序、全半角标点、自动编号和页码
项目或配置OpenDataLoader加EasyOCR
严格字符准确率70.98%
主要表现出现漏行、漏段，涉及当事人信息、事实理由、法律依据等内容
项目或配置OpenDataLoader加RapidOCR和PP-OCRv6 Small
严格字符准确率100%
主要表现本次固定样本在归一化统计口径下未发现字符级错漏
单看表格，可能会直接得出“100%比97.52%好”的结论。两组数字的统计口径不同，这样比较并不严谨。
PP-OCRv6 Browser报告使用的原文基准为1131个字符；OpenDataLoader报告的严格口径基准为1144个字符。后者补入了Word打印时可见的自动编号，并统一了全角和半角字符。
浏览器端测试没有保存当次使用Small还是Medium、具体推理后端和页面生成参数。97.52%与100%采用不同测试口径，无法据此判断哪个项目识别更准。
OpenDataLoader项目内部的两轮测试可以直接比较。两轮使用相同PDF、相同强制整页OCR流程和相同统计方法，准确率从EasyOCR方案的70.98%提高到RapidOCR方案的100%。
05
五、EasyOCR踩坑：识别了，后面却被过滤
OpenDataLoader第一次采用EasyOCR1.7.2，语言设置为简体中文和英文，默认置信度阈值为0.5。
最终输出中出现了严重漏段：
授权委托书漏掉部分委托人和受委托人信息；
民事起诉状漏掉部分原被告身份信息；
部分事实与理由、《民法典》依据和房屋结构说明没有进入结果。
进一步查看EasyOCR原始输出后发现，多数缺失文字已经被识别出来，只是置信度低于0.5，后来被Docling过滤掉了。
把阈值临时降到0.2后，大部分遗漏内容能够恢复。问题来自EasyOCR的置信度结果、0.5阈值和后续过滤；EasyOCR已经识别出的部分文字在这一环节被舍弃。
这也是OpenDataLoader项目最需要说清楚的一点：
安装成功只是第一步。只看最后的Markdown，可能会误以为原始OCR没有识别到那些文字。
0.2只是本次排查时使用的参数，并不是所有文档的推荐值。阈值过低也可能把阴影、污点和其他噪声带进结果，而且本次没有对0.2重新计算完整准确率。
06
六、第二次改用RapidOCR，实际模型还是PP-OCRv6
第二次测试把OpenDataLoader的底层OCR方案换成RapidOCR。
RapidOCR负责加载和运行PP-OCRv6模型，两者承担不同角色。
本次RapidOCR负责通过ONNX Runtime加载和运行模型，实际完成文字检测和识别的是：
PP-OCRv6_det_small.onnx；
PP-OCRv6_rec_small.onnx；
另加一个文字方向分类模型。
OpenDataLoader第二次取得100%的测试结果时，同样使用了PP-OCRv6，区别在于运行方式与PP-OCRv6 Browser项目不同。
前者通过RapidOCR在本机后端运行PP-OCRv6 Small，识别后还要继续进行版面和结构整理；后者通过浏览器工具包直接运行PP-OCRv6 Small或Medium，更接近即时OCR工具。
介绍使用RapidOCR等OCR方案的项目时，需要同时说明以下信息：
实际OCR引擎是什么；
加载了哪个检测和识别模型；
置信度阈值是多少；
OCR之后有没有过滤、排序和版面整理。
07
七、速度暂时不能做公平排名
PP-OCRv6 Browser页面会临时显示识别耗时，但本次测试没有保留日志，所以不能补写一个推测数字。
OpenDataLoader加EasyOCR时，1页授权委托书约2.04秒，2页民事起诉状约3.18秒。这是任务创建到结果落盘的估算时间。
OpenDataLoader加RapidOCR时，两次记录分别约4.50秒和1.82秒。前一次包含模型冷启动，后一次是在模型已经加载后的状态。
这些时间来自不同记录方式和不同运行状态，只能说明本机处理短篇法律文书没有明显等待问题，不能据此给两个项目做速度排名。
08
八、律师和法律工作者应该怎样选
1. 这些情况更适合PP-OCRv6 Browser
临时识别一张图片、聊天截图或几页PDF；
想直接复制纯文字；
需要下载文字框选图，人工查看哪里识别错了；
希望部署尽量简单；
不需要JSON、HTML、表格结构或批量任务管理。
它胜在路径短、操作直观。日常处理少量材料时，打开网页、拖入文件、点击识别即可。
2. 这些情况更适合OpenDataLoader
要处理整批PDF卷宗；
需要保留标题、段落、列表和表格结构；
结果准备继续交给大模型、知识库或其他程序；
需要Markdown、JSON、HTML和纯文本等多种格式；
需要页码范围、PDF密码、表格模式、页眉页脚或敏感信息替换等参数。
OpenDataLoader的价值在于完成识别后继续整理结构，让PDF成为后续系统可以使用的资料。
但OpenDataLoader组件更多，也意味着配置和排错成本更高。第一次EasyOCR的经历说明，OCR引擎、模型和阈值必须在正式使用前用自己的法律材料验收。
3. 两个项目也可以同时保留
两套项目可以同时保留，各自承担不同任务。
日常快速识别可以使用PP-OCRv6 Browser，批量PDF和结构化处理则交给OpenDataLoader。
遇到OpenDataLoader输出漏段时，还可以把问题页面单独放进PP-OCRv6 Browser查看文字框选结果，帮助判断问题出在文字识别，还是出在后续过滤和版面整理。
无论使用哪一个项目，姓名、身份证号码、电话号码、金额、日期、案号和授权权限等关键字段，最终都应回到原页核对。
09
写在最后
这次比较之后，两套项目的分工已经明确。
PP-OCRv6 Browser侧重简单、直接和随时可用；OpenDataLoader侧重完整解析、结构化输出和后续流程衔接。
OpenDataLoader第一次使用EasyOCR时踩了阈值过滤的坑，第二次改用RapidOCR后，实际又使用了PP-OCRv6 Small模型。这个过程提醒我们，项目名称只是入口，最终效果取决于整套配置。
PP-OCRv6 Browser负责快速识别文字，OpenDataLoader还会把整份PDF整理成可以继续处理的资料。
10
测试边界说明
本文记录的是2026年7月30日的一次本地小样本测试，不构成对PP-OCRv6 Browser、OpenDataLoader、EasyOCR或RapidOCR长期准确率、速度和稳定性的排名。软件版本、模型配置、页面渲染方式、电脑环境、扫描质量、阈值和统计方法发生变化，均可能导致结果波动。
胡律用AI
法律人的 AI 工具、提示词与工作流
分享合同审查、案例检索、法律写作、文书整理、客户沟通、知识管理等场景中的实用方法，帮律师、法务和法律从业者把 AI 真正用进日常工作。
记录 AI 工具在法律学习、文档处理、资料整理和专业办公中的使用心得，分享法律人 AI 工作和心得。
胡劲科律师
Microsoft Certified Professional（MCP，微软认证专业人士）
Gemini Certified Educator（谷歌AI认证教育者）
腾讯 WorkBuddy 效率智能体 OPC 从业者
律所法律实务 AI 课程讲师
广东省律协婚姻家事专委会副秘书长
AI 不是替代专业判断，而是帮我们更快整理资料、生成初稿、搭建思路。
关注「胡律用AI」，一起把 AI 用进真实工作。
