Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

大佬,关于此工具的一些探讨,望沟通 #414

Closed
czzzjj opened this issue Mar 11, 2024 · 1 comment
Closed

大佬,关于此工具的一些探讨,望沟通 #414

czzzjj opened this issue Mar 11, 2024 · 1 comment

Comments

@czzzjj
Copy link

czzzjj commented Mar 11, 2024

大佬好,刚花了1个小时初步体验了下您开发的工具,基于我目前浅薄的认知与您探讨下
先说下背景,我公司有个业务需要使用到OCR识别的功能,但对精度的要求非常非常高,我寻找过国内国外各种OCR工具,包括本地部署的、API接口的等等,目前使用到最优的是微软Azure的计算机视觉服务API,我基于这个API以及微软的另一个表单识别器API组合调试后形成了一个混合OCR引擎,精度大概能达到95%以上(大部分情况下有100%),并且适用于绝大部分语种(因为微软的API确实囊括了世界上绝大部分语种),但最近我的业务并不满足当前的精度(因为有些时候确实会识别错,比如0变成o ,变成. 表格边界变成1 或者 丢了1之类识别边界非常小的字符),所以我开始寻找新的OCR引擎,无意间发现了这个优质的本地项目,我之前有尝试过本地部署过Paddle模型,但基于初始版本的模型效果非常不好并且业务挺着急上线就不了了之了

基于上述背景,想与您探讨下,您有完整的Paddle调试经验,因为我试用了下您调试好的代码,发现精度似乎不是非常高,如果需要在您的这个工具上提高结果的精度,是否是需要初始一个Paddle模型(或者其他类似的模型),喂自己的素材成长到足够的程度再引入为插件,此外如果需要更高的精度是否需要更好的硬件条件(CPU\GPU等,我们能接受自己搭一个高级的机房来优化这个业务)

另外,想询问下您的意见,您认为是本地优化出一个合适的模型好,还是使用各大厂商的OCR接口更好,虽然我现在走的是第二条路,但还是希望能听听下大佬的想法

@hiroi-sora
Copy link
Owner

你好~

关于 PaddleOCR ,本项目默认自带的是原项目提供的轻量版模型,在家用电脑上有较好的效率。原项目还提供了高精度版模型(体积大、识别速度慢)。你可以在 这里 下载模型,并参考 #316 将模型导入 Umi 。

注意, #316 中只提到了 高精度文本检测库 _server_det 。如果你想要达到最大精度,可以将 高精度文本识别库 _server_rec 也一并导入。

你可以自己训练或微调Paddle的高精度模型。本地训练的一个关键优势是:可以根据自家业务,有针对性地调整模型。比如说,你们业务中经常出现某种地名、人名、专业术语的生僻字,就可以用这些素材来针对性的训练,这是在线服务所无法实现的。

精度与设备(CPU/GPU)没有直接关系。设备性能只影响推理速度。不过,如果打算在生产环境中使用计算量大的高精度库,那么部署到GPU服务器可以提升响应速度。

当然,在开始之前,你们还是应该先做充分的调研。百度、腾讯等都提供了高精度识别的在线接口(比常规接口更贵,效果更好,也支持多种语言)。它们或许采用了更先进的推理方式或模型架构,比我们这些开源项目性能更好。如果这些接口能满足你们业务需求,则直接用在线接口,或许比自己部署的成本更低。

总之,采用在线还是本地,需要经过调研、评测才能决定,不能只凭直觉。

另外,传统OCR技术是有极限的。像你提到的0变成o,大部分OCR模型都难以避免。使用NLP来二次纠正OCR结果,或者使用基于大模型的端到端式OCR,或许是未来的出路。可以了解一下相关的技术。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants