Poor extraction

[sonomirco]

🔎 Search before asking | 提交之前请先搜索

• I have searched the MinerU Readme and found no similar bug report.
• I have searched the MinerU Issues and found no similar bug report.
• I have searched the MinerU Discussions and found no similar bug report.

🤖 Consult the online AI assistant for assistance | 在线 AI 助手咨询

• I have consulted the online AI assistant but was unable to obtain a solution to the issue.

Description of the bug | 错误描述

Hi there,
Before today, I was having a very rough extraction.

And today, it just returned an image

I have my pipeline relying on your reach extraction, and now it's gone!
I have the same behaviour using the API, of course.

How to reproduce the bug | 如何复现

You can try with this image

This was a good extraction

MinerU_page_0001__20260623025033.json

This is what I have now
MinerU_page_0001__20260623025708.json

Operating System Mode | 操作系统类型

Windows

Operating System Version| 操作系统版本

Windows 11

Python version | Python 版本

3.13

Software version | 软件版本 (mineru --version)

>=2.5

Backend name | 解析后端

pipeline

Device mode | 设备模式

cpu

[myhloli]

The online API currently does not support changing the effort setting and uses medium by default. This is an intentional decision to help reduce long queue times caused by the growing number of parsing requests.

medium effort still delivers excellent parsing quality in most scenarios, but it may not perform as well for engineering drawings like the ones you provided.

If you are using a local deployment in hybrid mode, you can switch effort to high to improve parsing accuracy. This should restore the parsing quality you previously experienced, but it will also take longer to process.

[sonomirco]

Hi @myhloli
My pipeline is based on API calls. Does this mean that, through the API, the service won't be limited, so I need to move to a local hybrid as the only option?

So the initial parsing effort via API calls was based on high initially?

Is the same problem with the web API service using Docker?

[myhloli]

Starting from version 3.3, we introduced two effort levels and changed the default effort to medium. This significantly improves inference speed while not affecting parsing quality in the vast majority of cases.

The SaaS API was recently updated to version 3.4 and therefore inherits this behavior. However, it does not expose the effort parameter, in order to prevent large-scale queueing caused by the high volume of online parsing requests.

For self-hosted deployments, you are free to switch between different effort levels and continue using the higher-accuracy parsing mode. This usage is completely unrestricted.

[sonomirco]

@myhloli
Can I ask you what the best setup is for self-hosting the deployment in Azure?
A Virtual Machine? I also saw that it is using Qwen; is the model provided to achieve the performance initially provided by the API service?
Why has the effort for extraction been dropped significantly in layout and OCR for the type of documents I am using?

[myhloli]

Hi @sonomirco,

For self-hosted deployment, we recommend using a GPU environment with at least 8 GB of VRAM and 32 GB of system memory. An Azure VM with a suitable NVIDIA GPU should work for this use case.

Yes, self-hosting can fully reproduce the previous parsing quality. You can also test this online here first: https://www.modelscope.cn/studios/OpenDataLab/MinerU

Please use the default hybrid engine, and try switching effort between medium and high to compare the parsing results on different examples.

The lower-effort mode has weaker generalization ability compared with high effort. Engineering drawings like your examples are not the most common document layout type, so they are more likely to show quality degradation under medium effort, especially in layout analysis and OCR-related extraction.

[sonomirco]

@myhloli
Check out the difference between running locally and using the link you provided.
Both effort high and hybrid-engine

page_0001.zip
page_0001_local.zip

In the local one, the OCR from the images does not exist.
I think I need to reconsider the pipeline now; the API service was amazing, but I can't have the same quality locally, and for what I need to do, a VM is an overwhelming step.

Is there no chance you can provide fewer pages, but with high effort, for the API service?

[myhloli]

With the same request parameters, the output of the local deployment and the online version should be consistent. You can try redeploying and testing the output again.

There are currently no plans to add the effort parameter to the online API.