Persian document OCR quality: evaluate knowledge ingestion before replacing the model

A correct citation can still support a misread number

An assistant might cite the right contract page while using an amount whose digit was misread by OCR. A page reference alone does not establish numeric correctness. The failure began upstream of answer generation.

This illustrative evaluation uses synthetic purchasing letters and tables. For every important claim, compare extracted text and structure with what a reviewer can see in the image. The objective is to measure decision-relevant failures rather than demonstrate recognition on a few clean pages.

Build a representative reference sample

Sample clean, skewed, faint and multicolumn pages from actual document types. Label multipage tables, overlapping stamps, headers, footnotes and mixed Persian/Latin identifiers separately. A sample dominated by digital PDFs does not represent an archive dominated by old scans.

Have domain reviewers prepare reference text, reading order and critical fields. Keep sensitive material within authorized review boundaries; use synthetic or permitted examples for public demonstrations. Hold out documents until the final comparison so tuning does not simply fit the demonstration pages.

Verify language support for the exact feature

Microsoft's language documentation separates Read and Layout support by model and feature. Persian support in one table does not establish equal support for handwriting, tables, forms and every prebuilt processor. Record the tested service version and processing path.

Printed text, handwritten notes and locating a signature are distinct tasks. Successful text recognition does not authenticate a signature. Each claimed capability needs separate evidence and an appropriate review path for uncertainty.

Keep search normalization separate from source alteration

Persian/Arabic letter variants, half-spaces and digit forms can affect retrieval. Unicode normalization defines particular equivalences; it is not a substitute for every application-specific character or digit mapping. Document those additional rules explicitly.

Preserve original text and imagery and link search-normalized text back to them. In the proposed workflow, normalization may help find a word, but it must not silently repair a contract identifier or date without evidence. Retain page-region provenance for important extracted values.

Assess relationships, not only recognized words

A tax amount placed under the total column can create a wrong report even if every digit was recognized. Evaluate row/column associations, nested headers, page continuation and units, as well as paragraph reading order.

Create a controlled table with similar rows and different units. Compare each value together with its row, column, unit and page. A visually attractive reconstructed table is not success if those relationships are wrong. Ambiguous cases should permit source-region review rather than forced inference.

Report three layers of quality

Character and word error rates assess transcription. Field checks assess amounts, dates and identifiers. Application tests assess whether an employee receives the right evidence-based answer. A strong text average can hide severe failures in a few critical fields.

Report sample counts and scoring conventions. Specify how spaces, half-spaces and digit variants are handled. Compare strict scoring with predefined normalized scoring; their difference helps distinguish superficial variation from application-relevant errors.

Do not confuse image quality with field correctness

Google Cloud documents image-quality indicators, defect types such as blur or cutoffs, and limitations of those indicators. A quality score is not the probability that every extracted amount is correct. A readable page can still contain a difficult table or one damaged critical field.

Our proposed review route combines defect type with field impact. A low-impact letter might be reprocessed while a disputed purchase amount needs review. Calibrate thresholds on labeled organizational samples and measure review workload and delay rather than adopting a universal cutoff.

Follow the image through to the final answer

Run the chosen extraction through the real chunking and search pipeline. Ask questions that depend on a table cell, policy exception or exact number. Check retrieved text, source-page location and whether the answer uses an unverified extracted value.

Deliver document categories, tool version, reference data, field failures and review policy. Retain difficult cases for future comparisons. These are evaluation recommendations, not a claimed accuracy rate for Persian OCR or certification of a specific deployed product.

For more on this topic, read Connecting AI answers to organizational documents in the Liyan knowledge base.