Junk data getting predicted from the custom model

Hello Yugesh Bandaru,

Greetings! Thanks for raising this question in Q&A forum.

This usually happens when the Azure Document Intelligence in Foundry Tools model is returning a low-confidence extraction or the model has learned inconsistent patterns from the training set. In your case, because the same PDF gives the correct result after reupload and the wrong value is not present in the document, it may also point to a service-side prediction inconsistency that needs log review.

1. First, confirm whether you are using a custom extraction model and not only a classification model, because field values are extracted by the extraction model. The question on Junk data getting predicted from the custom model mentions classification, but the behavior described is field prediction.
2. Check the confidence score and the bounding region/content returned for that field in the API response. If the confidence is low or the source span does not match the expected text, treat that value as unreliable in your app and ignore it.
3. Re-test the same file using the same model ID and same API version each time. This helps rule out differences between studio testing and application calls.
4. Review your training set for that field and add a few more representative invoice samples, especially files where that field appears in slightly different positions or formats. This usually reduces random false matches.
5. If this continues, the next action should be with Microsoft support, because this looks intermittent and is not easily reproducible. Please collect the request ID/correlation ID, model ID, API version, and one affected sample file so the support team can check backend logs and confirm whether there is a service issue or model problem.

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.

I think Azure Document Intelligence can return different field values when the OCR read or the page layout shifts between uploads. The fix is to check the confidence and the textSpan for that field and add a few clean, correctly‑labeled invoice samples before retraining in the studio.

Hello @Yugesh Bandaru

Thank you for the update.

Since the incorrect value does not exist anywhere in the PDF and the issue occurs intermittently, this may indicate either a document ingestion issue or an inconsistency in the prediction process rather than a training data issue alone. Retraining with additional documents is a good step, but if the problem persists, I recommend reviewing the following:

• Verify that the affected PDFs are not corrupted, encrypted, or password protected.
• Confirm whether the documents are text-based PDFs or scanned/image-based documents, as extraction accuracy can vary between the two.
• Review the confidence score, content span, and bounding regions returned for the affected field when the incorrect value is predicted.
• Ensure the training dataset covers all variations of the document layout and that field labeling is consistent across samples.
• If the documents are retrieved from Azure Storage, verify that the same file is being analyzed each time and that there are no ingestion or access inconsistencies.

To help investigate further, could you please share the following from an affected request?

• Request ID / Correlation ID
• Model ID
• API version
• Analysis timestamp
• Sample document that produced the incorrect result (if it can be shared)
• Confidence score and field details from the API response

This information will help determine whether the behavior is related to model prediction confidence, document ingestion, or a potential service-side issue requiring further investigation.

Thank you!