Is it GLM-OCR or PP-DocLayoutV3

[TheMrguiller]

Hello,

I’m encountering issues with document information extraction and would like to clarify whether the problem could be related to the OCR stage or to the PP-DocLayoutV3 component.

I am working with complex industrial documents, and I have tested the pipeline across more than 30 systems/models without success. In all cases, the extraction results are either incomplete or inaccurate.

Could you please confirm:

• Whether extraction failures are more likely caused by OCR inaccuracies or by limitations in PP-DocLayoutV3?
• If there are any recommended debugging steps or diagnostics to help isolate whether the issue originates from OCR vs layout detection?
• Whether PP-DocLayoutV3 has known limitations when handling highly complex or dense industrial documents?

Any guidance on how to better troubleshoot or improve performance in such scenarios would be greatly appreciated.

Thank you.

[zRzRzRzRzRzRzR]

Only the layout part uses PP-DocLayoutV3. If you encounter no issues when deploying with vLLM or sglang, but problems arise when using the glm-ocr sdk, it is very likely caused by PP-DocLayoutV3. If both vLLM and sglang fail to start properly or output garbled text, then the issue comes from GLM-OCR

[TheMrguiller]

Thank you so much for your response. Indeed, the issue was more related to PP-DocLayoutV3 than to GLM-OCR. The table extraction capabilities are impressive, leading among the 30 open source services I have used for complex document processing. What other layout extraction systems do you currently support? Is it possible, via your API, to use only GLM-OCR and specify in advance the type of element to extract such as text, formula, or table?