Arabic AI

Arabic NLP: Why Understanding Arabic Is Harder Than Generating It

Modern models write beautiful Arabic. That is the problem. Fluent output is the easy half, and it hides the hard half so completely that a system can fail on most of your traffic while every reply looks correct.

11 min read August 1, 2026

Show a decision-maker an AI system answering in Arabic and the demonstration is over. The output is fluent, correctly inflected, appropriately formal. It looks like the problem has been solved.

What it demonstrates is generation, which is the easier half by a wide margin. The half that decides whether a deployment works is comprehension — and comprehension failures in Arabic are silent. The system does not stumble or produce broken text. It produces a fluent, grammatical, confident Arabic answer to a question it did not understand, which is indistinguishable from success to anyone watching.

This piece is the technical explanation of why. The business-facing version — what to demand from a vendor and how to test it — is why Saudi businesses need AI that understands local customers.

The asymmetry, stated plainly

Generating Arabic means producing text that follows the patterns of Modern Standard Arabic, and MSA is extremely well represented in training data — news, books, official documents, encyclopaedias. A model sees an enormous amount of it and learns to produce it convincingly.

Understanding Arabic means correctly interpreting what an actual person typed, and actual people do not type MSA. They type dialect, abbreviated, without diacritics, with variable spelling, mixed with English, on a phone, with autocorrect intervening. That register is far less represented in training data, and it is essentially all of your real traffic.

Worth remembering

The gap between a system’s Arabic output quality and its Arabic input comprehension is the single largest source of disappointment in Arabic AI deployments — and output quality is the only half a demonstration shows you.

Diglossia: two languages sharing a name

Arabic is diglossic to an unusual degree. Modern Standard Arabic is the written and formal register: your policies are in it, news is read in it, and essentially no one speaks it conversationally. Alongside it, regional varieties differ from MSA and from each other in vocabulary, syntax and pronunciation — enough that a Moroccan and a Saudi speaking their own dialects may struggle, while both write near-identical MSA.

For a customer-facing system this matters immediately, because the same question arrives in several forms:

One question, four registers
  1. MSAThe register your documents are written inFormal, complete, fully inflected. Almost nobody types this into a chat window.
  2. Gulf / Saudi dialectThe register your customers useDifferent question words, different verbs, different sentence shape. Not incorrect Arabic — a different variety of it.
  3. MixedArabic sentence, English nounProduct names, brands and often numbers stay in English inside an otherwise Arabic sentence. This is the normal case here, not an edge case.
  4. ArabiziArabic written in Latin letters and digitsCommon in fast informal messaging. To a system expecting Arabic script it may not register as Arabic at all.

A system that handles only the first row will appear to work in every test written by your marketing team.

All four mean "how much does it cost". A retrieval system tuned on the first will frequently miss the others, and the others are what customers type.

Concretely: the same request appears as كم السعر؟ (MSA), as بكم؟ (Gulf), as وش سعر الـ subscription؟ (mixed), and as "besh el se3r?" in Latin characters. Only the first resembles anything in your policy documents.

Spelling variation is not error

Several Arabic letters have variants that native writers use interchangeably in informal writing. These are not typos and correcting them is not the point — a system has to treat them as the same thing.

The hamza forms — أ, إ, آ and bare ا — are routinely flattened to the bare form when typing quickly. Final ة is frequently written as ه. Final ى and ي are interchanged constantly. Diacritics, which disambiguate meaning, are absent from essentially all real writing.

The consequence for search is direct: الأسعار and الاسعار are the same word to a reader and different strings to a computer. A system that does not normalise these before matching will miss a large share of genuine queries — and it will miss them silently, returning something else that seemed close.

Morphology: one word carrying a sentence

Arabic builds words from a consonantal root shaped by a pattern, then attaches prefixes and suffixes that other languages express as separate words — conjunctions, prepositions, the definite article, and pronoun objects all fuse onto the stem.

The root ك-ت-ب produces كتاب (book), كاتب (writer), مكتب (office), مكتبة (library) and مكتوب (written) — related in meaning, sharing no matchable prefix. And a single written token such as وبمكتبتهم carries "and", "in", "their" and "library" at once.

Two practical consequences follow. Keyword search performs far worse in Arabic than in English, because the surface forms differ so much. And tokenisation — the step where text is split before anything else happens — is doing much more consequential work in Arabic, which is why a pipeline built and validated on English can behave quite differently on Arabic without anyone changing a setting.

Where it actually breaks: retrieval

Putting the previous three sections together produces the specific failure that costs Arabic deployments most.

The knowledge base is in formal Arabic, because policies are written formally. The question arrives in dialect, with flattened hamzas, an English product name in the middle and no diacritics. The retrieval step tries to match them, finds nothing strongly relevant, and returns the closest passages it has. The model then does what language models do: it writes an excellent answer from weak material.

The customer receives fluent Arabic that does not answer the question. Nobody logs an error. Nothing appears in a dashboard. If the assistant was tested by asking documents about themselves in their own wording, the test suite reports near-perfect accuracy throughout. The mechanics of fixing this are in how to train an AI chatbot on your own data; the short version is normalisation before matching, keyword and meaning-based search combined, and a test set built from real phrasing.

Named entities and Saudi-specific vocabulary

General Arabic capability does not confer local knowledge, and this is a category of failure that testing in Cairo or Beirut will not surface.

Place names carry multiple accepted romanisations and multiple Arabic spellings. Government services, document types and official processes have specific names that appear constantly in customer questions and rarely in general training data. Company and product names transliterate inconsistently, often within one conversation. A system that does not recognise these treats them as unknown words and quietly degrades the retrieval that depends on them.

The fix is not more general Arabic capability. It is your own vocabulary, present in your own material, with the variants your customers actually use — which is one of the things a properly built knowledge base carries and a general model cannot.

Speech makes every one of these harder

Arabic speech recognition inherits all of the above and adds its own difficulties. Accents vary substantially across the Kingdom and much more across the Arab world. Speakers code-switch mid-sentence, so the recogniser must handle two languages in one utterance. Numbers, dates and reference codes — the things people call about — are exactly where recognition errors are least tolerable, and are often spoken in English inside an Arabic sentence.

And the output is undiacritised text, so the ambiguity that speech resolves through pronunciation is reintroduced the moment it is written down. Test Arabic speech with real callers in real conditions — background noise, a phone, an accent — rather than in a quiet room with a clear speaker, because the second test passes for systems that fail the first. See speech-to-text and AI voice agents in Saudi Arabia.

How to test Arabic properly

Most Arabic testing is generation testing wearing a comprehension label. Five practices separate the two.

A real Arabic test protocol
  1. 1Build the Arabic test set in ArabicNot translated from English tests. Translated questions carry English sentence structure and vocabulary choices, and they are easier than real ones.
  2. 2Use real customer phrasingFrom tickets, from search logs, from messaging. Dialect, abbreviations, missing diacritics, autocorrect damage and all.
  3. 3Test retrieval separately from the answerMeasure how often the correct passage is found before looking at what was written. A good answer from the wrong passage is luck, and it will not repeat.
  4. 4Include mixed-language and Latin-script messagesAn Arabic sentence with an English product name; a question typed entirely in Arabizi. Both are ordinary traffic and both break systems that pass every other test.
  5. 5Have a native Gulf speaker read the failuresNot a translator, and not a fluent MSA reader. Someone who would notice that a reply is grammatically perfect and answers a different question.

Item five is the only one that reliably catches the silent failure, because the silent failure looks correct to every automated check.

Every item is a way of testing comprehension rather than fluency. Fluency will pass regardless.

What Arabic-first means here

Almost every vendor selling into the Kingdom supports Arabic, and almost all of them are telling the truth in the narrow sense that Arabic in produces Arabic out. The meaningful question is whether Arabic was treated as its own language or as a translation target.

For Elbi that means Arabic questions are matched against Arabic material directly rather than round-tripped through English; that queries are normalised for spelling variation before anything is matched; that retrieval combines meaning-based and keyword search, because each covers the other’s weakness in Arabic specifically; that the Arabic test set is its own set built from real phrasing rather than translated English; and that the interface is genuinely mirrored rather than left-to-right with Arabic text in it.

It also means being honest about the remaining limits. No system understands every dialect equally, dialect coverage is a spectrum rather than a checkbox, and the correct response to a question the system did not follow is to say so and hand over rather than to produce elegant Arabic that misses. If you want to test any of this — ours or anyone else’s — the fastest route is your own material and your own customers’ phrasing, which we are happy to set up.

Common questions

Four reasons compounding: diglossia, where the written formal register differs sharply from what people actually type; spelling variation that native writers use interchangeably; rich morphology, where prefixes, the definite article and pronouns fuse onto a word so surface forms differ enormously; and constant code-switching with English. Each degrades matching, and they arrive together.

Because generating and understanding are different problems with different training data. Modern Standard Arabic is abundantly represented, so fluent output is straightforward. Real customer input is dialect, undiacritised, variably spelled and mixed with English, which is far less represented. The failure is silent: a grammatical, confident Arabic answer to a question the system did not follow.

Usually not. Most Arabic support means Modern Standard Arabic — the register of documents and news, and not the one anyone types into a chat window. Gulf and Saudi usage differs in question words, verbs and sentence shape. A customer writing in dialect is not writing incorrectly; a system tuned only on formal text will simply miss them.

Arabic written in Latin letters with digits standing in for sounds that have no Latin equivalent. It is common in fast informal messaging, particularly among younger customers, and a system expecting Arabic script may not register it as Arabic at all. If you serve consumers over messaging, it belongs in your test set.

Build the Arabic test set in Arabic rather than translating English tests, using real customer phrasing from tickets and logs. Measure retrieval separately from the answer, so a good reply from the wrong source is not mistaken for success. Include mixed-language and Latin-script messages. And have a native Gulf speaker read the failures — the silent failure looks correct to every automated check.

See it on your own content

A working assistant on your own material, in both languages.