Document OCR
Reading text out of a photograph or a scan. Straightforward in English, genuinely difficult in Arabic, and the step everything else depends on when a customer sends a picture of a document.
Reading text out of a photograph or a scan. Straightforward in English, genuinely difficult in Arabic, and the step everything else depends on when a customer sends a picture of a document.
What it does
Optical character recognition turns an image containing words into text a system can work with. It matters because a large share of documents customers send are not files — they are photographs, taken on a phone, at an angle, in poor light, of a piece of paper.
Where recognition fails, everything downstream fails silently. The extracted text looks like text, the assistant answers from it confidently, and the answer contains a figure that was never in the document. That failure mode is worse than an outright refusal because nobody can see it happening.
Where it shows up in a conversation
Customer uploads
Photographs of bills, letters, contracts and identity documents.
Scanned archives
Historical records that exist only as images.
Forms
Checking a submitted form for completeness before it enters a queue.
Bilingual documents
Official documents that mix Arabic and English on the same page.
Handwriting
Limited but sometimes present — and worth knowing where the boundary is.
Quality checking
Telling a customer immediately that a scan is unreadable, rather than after review.
Why it is harder in two languages
Arabic recognition is structurally harder than English and the reasons are worth understanding because they explain why vendor quality varies so much here. Arabic is cursive: letters join, and their shape changes depending on position in the word. The clean letter-by-letter segmentation that English recognition relies on simply does not apply.
Diacritics carry meaning and are frequently faint, absent or lost to compression. Numerals appear in two forms and documents mix them freely. And layout works against the recogniser: Arabic reads right to left while embedded tables, figures and English text run the other way, so a bilingual invoice requires the system to handle both directions on one page.
The practical consequence is that a system which handles English documents excellently may be substantially worse on the Arabic documents your customers actually send. This is the single capability most worth testing with your own material rather than a vendor sample.
What to look for when you evaluate it
| Arabic accuracy on real documents | Tested with photographs and scans of the kind you actually receive, not clean typed samples. |
|---|---|
| Bilingual layout | Whether a page mixing Arabic and English reassembles correctly rather than interleaving nonsense. |
| Photograph handling | Angle, lighting, shadow and phone compression, which describe most real uploads. |
| Confidence reporting | Whether the system flags a poor read rather than returning uncertain text as though it were certain. |
| Numeral handling | Both numeral systems, correctly, including where a document mixes them. |
| Failure behaviour | Whether it asks for a better image or answers from partially recognised text. |
Where it should not be trusted alone
Recognition output should never be treated as certain where the number matters. A blurred digit produces text that reads perfectly and states the wrong amount, and no downstream component can detect that.
The defence is to surface uncertainty rather than hide it. Where a document could not be read cleanly, the correct behaviour is to say so and ask for a better copy — not to answer from what was recovered and hope.
It should also not be used for identity verification on its own. Reading a name from an identity document tells you what the image contained; it does not tell you the document is genuine or that the person presenting it is its holder.
How this fits the whole
No single capability answers a question on its own. A conversation passes through several in sequence — understanding what was asked, finding the relevant material, composing a reply, checking it before it is sent — and the quality of the result is set by the weakest link rather than the strongest.
That has a practical consequence for evaluation. Vendors tend to demonstrate their strongest component, and a system with excellent retrieval and weak language handling will demo beautifully and disappoint in production, because the demo was conducted in the language and phrasing the system handles best.
It also explains why grounding matters more than raw capability. A more capable model that answers from its own training rather than from your material produces confident, fluent, unsupported answers — which is a worse outcome than a less capable one that retrieves correctly and declines when it cannot. Capability without grounding increases the cost of being wrong rather than reducing it.
The pieces are described separately here because that is how they are evaluated and configured. They are not experienced separately: a customer asking a question encounters one system, and judges it as one.
Where this sits in a conversation
- Something arrivesA typed message, a spoken sentence, an uploaded document. The first job is establishing what was actually received — which language, which script, whether it is legible, whether it is one question or several.
- It is interpretedWorking out what is being asked rather than what words were used. The same question arrives phrased twenty different ways, in two languages, often mixed, frequently misspelt, sometimes as a fragment.
- Material is retrievedThe relevant part of your own approved content is found. This is where answer quality is largely decided: a correct answer assembled from the wrong source is still wrong.
- A reply is composedIn the language of the question, in the configured tone, from the retrieved material and nothing else. Where the material is silent, the reply says so rather than filling the gap.
- It is checkedBefore sending, the reply is examined for claims the retrieved material does not support and for personal data that should not be repeated back. This runs on every reply.
- It is deliveredAs streamed text, as speech, or as a structured response — and the conversation is recorded so that what happened can be reviewed later.
Why this is built rather than bought in
Every capability described here could, in principle, be obtained by calling somebody else's service. That is how most assistants in this market are assembled, and it is why so many of them cannot answer the question that decides regulated procurements: where does the data go.
When a component is a call to an external provider, every question that passes through it leaves the organisation. That may be perfectly acceptable for a retailer answering questions about opening hours. It is usually not acceptable for a bank explaining a transaction, a hospital confirming an appointment, or a public body handling a citizen case — and the constraint is architectural, so it cannot be configured away later.
The second consequence is control over behaviour. A capability obtained as a service behaves the way the provider decides, changes when the provider changes it, and cannot be tuned for the specific way your customers speak or write. A capability that runs inside your own estate can be adjusted for dialect, for your terminology, and for the particular failure modes your material produces.
The third is continuity. External services are deprecated, repriced and withdrawn. A deployment whose core capability depends on somebody else's roadmap inherits that roadmap, including the parts nobody announced in advance.
Measuring this component honestly
| Measured in which language? | Nearly every published benchmark in this field was developed against English. An overall figure that averages across languages hides exactly the gap that matters in this market. |
|---|---|
| Measured on what input? | Clean or realistic. Read speech or spontaneous speech. Typed text or phone-typed text with autocorrect. The difference between these is usually larger than the difference between vendors. |
| Measured by whom? | Self-reported figures with an undescribed method are marketing. Ask for the test set and the procedure. |
| What counts as correct? | A surprising number of published figures count a partially correct answer as correct. Ask what the scoring rule was. |
| How does it fail? | A component that degrades gracefully is worth more than one with a higher headline figure that fails silently and confidently. |
| Does it report uncertainty? | A component that surfaces low confidence lets the system confirm rather than guess. One that hides it produces confident errors downstream. |
What to ask about this specifically
Ask for the Arabic figure
Not the overall figure. Nearly every published benchmark in this field was developed against English, and the gap between the two languages is where deployments disappoint.
Ask how it was measured
Against what test set, by whom, on what kind of input. A number without a described method is marketing rather than measurement.
Ask what it does when uncertain
Whether uncertainty is surfaced or hidden. A component that hides low confidence produces confident errors downstream.
Ask about real conditions
Noisy audio, poor scans, dialect, informal phrasing, mixed languages. Laboratory conditions are not predictive of contact-centre reality.
Ask where processing happens
For any component touching personal data, this is a procurement question rather than a technical curiosity in regulated sectors.
Ask what is retained
What data this component keeps, for how long, and whether it is used to improve anything.
Common questions
Yes, and this is the capability most worth testing with your own documents. Arabic recognition is structurally harder than English and quality varies more between vendors here than almost anywhere.
They are the normal case rather than the exception. Angle, lighting and compression are what real uploads look like, and performance on clean scans does not predict performance on these.
To a limited extent, and the boundary matters. Where handwriting is central to your use case it should be tested specifically rather than assumed.
It says the document could not be read cleanly and asks for a better copy. Answering from partially recognised text is how an assistant states a figure that was never in the document.
It has to. Official documents here routinely mix Arabic and English on one page, running in opposite directions, and a recogniser that assumes one direction reassembles them into nonsense.
No. It reads what the image contains. Whether a document is genuine and whether the presenter is its holder are separate questions requiring proper verification.