软文安利来体验，真的很失望

[EvanLee0418]

🔎 Search before asking

• I have searched the PaddleOCR Docs and found no similar bug report.
• I have searched the PaddleOCR Issues and found no similar bug report.
• I have searched the PaddleOCR Discussions and found no similar bug report.

🐛 Bug (问题描述)

首先，环境很难装，尤其是PP框架，浪费很多时间。

其次，整体性能数据属实吗？还是为了展示指标而对测评集使劲过拟合？
其中整个表格处理模块，一个模块用了7个模型调参逻辑串联！！！实测下来和其他开源的单模型效果差不多，而且过拟合严重，真实场景上效果极差。
一点经验：7个模型处理这么一个小任务，不遵守第一性原则，其系统性误差和风险指数增长，必然导致过拟合，这是必然规律！！

最后真的很失望，浪费了很多时间，实验了一个失败的方案，希望重视用户体验，不要自嗨！！

🏃‍♂️ Environment (运行环境)

linux

🌰 Minimal Reproducible Example (最小可复现问题的Demo)

xx

[eritpchy]

+1 而且现在PaddleOCR3.0.0 还强制依赖的PaddleX, 懒得开新贴了, PaddleX这玩意有多肥依赖有多少不用我说你们心里自己也知道
本来PaddleOCR就是一个很小的工具类, 各个平台可以无差别安装 这回升级了就麻烦了, 升到了这个版本我甚至都不想用Paddle*本体了, 以后就用onnxruntime跑所有得了

我是Python 3.12 + Windows + numpy 2.2.5, 本来paddlepaddle好不容易都吃上了numpy2了, 这回paddle x又要求numpy1.26.4 又要求pandas 1.5.3 真是吐了, 前者降级后者包太老没有windows还要自己编译, 编译半天又编译不过, 对了macOS那边都在玩python3.13了, 为了一个新版PaddleOCR 3.0.0 大家都得降级3.11? 呕了,

而且我测试下来 V5的det模型误检测率非常高, 比V4高太多了, 又是浪费时间适配的一天, 什么时候出个doc的det啊!!!

[Bobholamovic]

@eritpchy 你好，感谢指出 PaddleOCR 存在的问题！对于依赖的问题，我想做如下解释：

而且现在PaddleOCR3.0.0 还强制依赖的PaddleX, 懒得开新贴了, PaddleX这玩意有多肥依赖有多少不用我说你们心里自己也知道
本来PaddleOCR就是一个很小的工具类

这次升级新增了比较多功能，比如chatocr和表格识别v2，这些功能会需要一些额外的依赖。目前，我们通过对PaddleX的可选依赖进行分组隔离，已经尽可能把PaddleOCR的依赖数量降到最少，也就是说，几乎不存在因为底层使用PaddleX才需要引入的额外依赖，要实现这些功能，不使用PaddleX直接开发，基本上也需要这些依赖。实际上这次升级对训练和推理依赖进行了分离，去掉此前训练才需要用到的依赖、再加上新的依赖后，虽然依赖数量变多（如上文所说，这可能是不可避免的），但依赖的总体积基本保持不变。从安装总体积大小的角度来看，如果之前的PaddleOCR是“一个很小的工具类”，那么现在应该也是，而且功能更多了～此外，当前的机制允许我们对依赖数量和体积进行进一步优化：如果用户呼声较高，后续我们也可能会考虑为PaddleOCR引入可选依赖，对于只希望使用OCR这一基础功能的用户，只安装OCR功能需要用到的依赖，而不用安装PP-StructureV3、ChatOCR等产线需要的依赖。

[Sunting78]

+1 而且现在PaddleOCR3.0.0 还强制依赖的PaddleX, 懒得开新贴了, PaddleX这玩意有多肥依赖有多少不用我说你们心里自己也知道 本来PaddleOCR就是一个很小的工具类, 各个平台可以无差别安装 这回升级了就麻烦了, 升到了这个版本我甚至都不想用Paddle*本体了, 以后就用onnxruntime跑所有得了

我是Python 3.12 + Windows + numpy 2.2.5, 本来paddlepaddle好不容易都吃上了numpy2了, 这回paddle x又要求numpy1.26.4 又要求pandas 1.5.3 真是吐了, 前者降级后者包太老没有windows还要自己编译, 编译半天又编译不过, 对了macOS那边都在玩python3.13了, 为了一个新版PaddleOCR 3.0.0 大家都得降级3.11? 呕了,

而且我测试下来 V5的det模型误检测率非常高, 比V4高太多了, 又是浪费时间适配的一天, 什么时候出个doc的det啊!!!

您好，请问您的文本检测的场景是什么呢？可以提供下具体的case吗？我们来看下是否可以通过参数调整

[cuicheng01]

@EvanLee0418 您好，感谢关注！
首先，关于paddle框架安装，如果确实存在安装困难，欢迎反馈我们，我们及时优化，也欢迎给Paddle框架提ISSUE，当然也可以看下是网络或者其他原因～
其次，关于表格识别任务，目前是业界的难题，一个模型在一组参数下很难识别所有的表格，不同的表格适用的参数并不相同，我们尽可能在满足大家不同场景需求的同时，增加一些模型和参数，允许大家去调试参数并适配自己的任务。当然您的建议也很好，我们后续可能会考虑使用多模态的方案解决，尽量一个模型解决多种表格识别问题，以及暴露少的参数。关于指标，您说的具体是哪个模型的指标呢？
最后，如果有bad case可以提出来，我们看下是不是需要更换参数，由于不是端到端的大模型方案，所以并不是所有默认参数就可以解决所有场景的～

[eritpchy]

@eritpchy 你好，感谢指出 PaddleOCR 存在的问题！对于依赖的问题，我想做如下解释：

而且现在PaddleOCR3.0.0 还强制依赖的PaddleX, 懒得开新贴了, PaddleX这玩意有多肥依赖有多少不用我说你们心里自己也知道
本来PaddleOCR就是一个很小的工具类

这次升级新增了比较多功能，比如chatocr和表格识别v2，这些功能会需要一些额外的依赖。目前，我们通过对PaddleX的可选依赖进行分组隔离，已经尽可能把PaddleOCR的依赖数量降到最少，也就是说，几乎不存在因为底层使用PaddleX才需要引入的额外依赖，要实现这些功能，不使用PaddleX直接开发，基本上也需要这些依赖。实际上这次升级对训练和推理依赖进行了分离，去掉此前训练才需要用到的依赖、再加上新的依赖后，虽然依赖数量变多（如上文所说，这可能是不可避免的），但依赖的总体积基本保持不变。从安装总体积大小的角度来看，如果之前的PaddleOCR是“一个很小的工具类”，那么现在应该也是，而且功能更多了～此外，当前的机制允许我们对依赖数量和体积进行进一步优化：如果用户呼声较高，后续我们也可能会考虑为PaddleOCR引入可选依赖，对于只希望使用OCR这一基础功能的用户，只安装OCR功能需要用到的依赖，而不用安装PP-StructureV3、ChatOCR等产线需要的依赖。

paddleocr 2.10.0 依赖 42个
paddleocr 3.0.0 依赖91个!!!
新增依赖49个!!!

ppocr2-test-3.11.requirements.txt

ppocr3-test-3.11.requirements.txt

当然这些还好, 不好的是PaddleX 强制要求numpy1.26.4 又要求pandas 1.5.3, 而paddlepaddle 很早就兼容numpy2了(paddlex反向拖后腿)
而pandas 1.5.3最高只有3.11的binary, 碰到编译必然失败无疑(python3.13 python3.12 windows都会失败)
如果可能我更希望他保持2.10.0原样

[Bobholamovic]

依赖数量的问题，就如之前的解释，这次新增了大量功能（从2个模型串联系统增加到8个），也需要更多依赖，但这些多是小依赖，对总体积的影响不大，我们也在讨论是否引入可选依赖功能～

对于numpy和pandas版本的问题，目前由于我们使用的部分API的后向兼容性限制，锁定了版本，抱歉造成了不便！PaddleX/PaddleOCR都属于paddlepaddle的下游应用，虽然其中由paddlepaddle提供最核心的能力，但除了模型推理以外的逻辑也有很多，这些逻辑有时也比较复杂，可能需要调用第三方库，可能存在一些对库版本的要求。我相信pin或者cap版本不会是长期方案，我们接下来也会排查代码逻辑，放松依赖版本限制。当前，如果不希望在安装依赖时编译源码的话（部分库只提供了source distribution），可以参考我在这个PR里的回复：

#15307

[liu-jiaxuan]

其中整个表格处理模块，一个模块用了7个模型调参逻辑串联！！！实测下来和其他开源的单模型效果差不多，而且过拟合严重，真实场景上效果极差。
一点经验：7个模型处理这么一个小任务，不遵守第一性原则，其系统性误差和风险指数增长，必然导致过拟合，这是必然规律！

关于这一点做回复哈：

1. 7个模型在实际推理时每次最多只使用3个模型，其中一个是分类模型，实际用于处理的只有两个模型
2. 不理解你提到的“过拟合严重”和“必然规律”从何而来，如果在你的case上默认配置表现不好是正常的，可以参考文档调整参数适配你的场景，开启端到端预测模式时相当于只使用一个模型处理（也即你提到的单模型），表格识别v2产线的功能很多，看你怎么使用了

[aigcliu]

🔎 Search before asking

• I have searched the PaddleOCR Docs and found no similar bug report.[x] I have searched the PaddleOCR Issues and found no similar bug report.[x] I have searched the PaddleOCR Discussions and found no similar bug report.

首先，环境很难装，尤其是PP框架，浪费很多时间。

@EvanLee0418 您好，这里提到PP框架难安装，请问是哪个环节有问题呢？

[eritpchy]

+1 而且现在PaddleOCR3.0.0 还强制依赖的PaddleX, 懒得开新贴了, PaddleX这玩意有多肥依赖有多少不用我说你们心里自己也知道 本来PaddleOCR就是一个很小的工具类, 各个平台可以无差别安装 这回升级了就麻烦了, 升到了这个版本我甚至都不想用Paddle*本体了, 以后就用onnxruntime跑所有得了
我是Python 3.12 + Windows + numpy 2.2.5, 本来paddlepaddle好不容易都吃上了numpy2了, 这回paddle x又要求numpy1.26.4 又要求pandas 1.5.3 真是吐了, 前者降级后者包太老没有windows还要自己编译, 编译半天又编译不过, 对了macOS那边都在玩python3.13了, 为了一个新版PaddleOCR 3.0.0 大家都得降级3.11? 呕了,
而且我测试下来 V5的det模型误检测率非常高, 比V4高太多了, 又是浪费时间适配的一天, 什么时候出个doc的det啊!!!

您好，请问您的文本检测的场景是什么呢？可以提供下具体的case吗？我们来看下是否可以通过参数调整

相关的案例我已经开了新的issue, 详见: #15374

[timminator]

I also have to chime in on the pandas version limitation. This is actually a big issue. This project is listed as compatible with Python 3.12 which it is clearly not!
This has to be fixed or the listed support for Python 3.12 has to be removed which would be a regression in comparison to 2.10.
This is also causing errors while installing for users that are unaware of this see the comment under your quick start guide here.

[Bobholamovic]

大家好，我们近期有了一些修复进展：

• numpy和pandas版本的问题将会在下一个patch版本（PaddleOCR 3.0.2）中解决，到时候Python 3.12安装应该不会再遇到问题。
• 关于依赖数量多的问题，我们正在尝试一种依赖切分的方案，对最基础的OCR功能和其他附加功能做依赖上的隔离，目前在 Split dependencies #15693 实现了。依赖切分会导致PaddleOCR的安装方式有些改变，也想听听大家对这个方案的看法～

Hello everyone, we've made some recent progress on a few fixes:

• The version issues with numpy and pandas will be resolved in the next patch release (PaddleOCR 3.0.2). By then, installing with Python 3.12 should no longer encounter problems.

• Regarding the notably large number of dependencies, we've also been experimenting with a dependency splitting solution. The idea is to isolate the dependencies for the core OCR functionality from those for additional features. This is currently being implemented in Split dependencies #15693. This change will alter how PaddleOCR is installed, so we’d love to hear your thoughts on this approach.