Why Arabic Breaks LLMs — and How to Build AI That Actually Works in Arabic

TL;DR: Arabic breaks large language models at four layers at once — tokenisation shreds Arabic words into far more tokens than English, root-and-pattern morphology explodes each word into hundreds of surface forms, most training data is formal MSA while customers write in Gulf dialect and Arabizi, and right-to-left mixed-direction text breaks the interface. The fix is not a bigger model or a translation layer. It is treating Arabic as a first-class engineering problem: normalising and grounding retrieval in Arabic, answering natively rather than translating, and evaluating on real dialect test sets reviewed by native speakers.

Why Does Arabic Break Large Language Models?

Every serious team building customer-facing AI in the Gulf hits the same wall. The demo works beautifully in English, and then someone types a normal Arabic sentence and the quality falls off a cliff. This is not because the model cannot produce Arabic — modern models produce fluent Modern Standard Arabic on demand. It is because Arabic stresses parts of the pipeline that English never touches, and those failures compound.

There is no single bug to fix. Arabic is hard for four independent reasons that stack: how text is broken into tokens, how words are built morphologically, how many different languages hide under the name "Arabic", and how the script renders on screen. An honest Arabic LLM strategy addresses all four deliberately, because skipping any one produces a bot that demos well and fails in production.

Tokenisation: Where Arabic Loses Before It Starts

A language model never sees letters. It sees tokens — subword fragments produced by a tokeniser trained, in almost every mainstream model, on a corpus dominated by English and other Latin-script languages. That tokeniser learns to represent frequent English words as a single token. Arabic, underrepresented in the training data, gets no such efficiency: common Arabic words fragment into several tokens, and many byte-level tokenisers encode each non-Latin character as multiple bytes, multiplying the count further.

The consequences are concrete and measurable:

• Cost. The same message costs materially more tokens in Arabic than in English, so Arabic conversations are structurally more expensive to run, and the gap widens on long threads.
• Context and truncation. Every extra token eats the context window. A knowledge base, conversation history, and question that fit comfortably in English can overflow in Arabic, and the usual failure is silent truncation — the model quietly loses the top of the context and answers from partial information.

You cannot retrain a frontier model's tokeniser, but you can engineer around it: keep Arabic prompts lean, retrieve narrowly so you are not stuffing the window, and budget context assuming Arabic costs more than the English equivalent. Teams that size the window on English tests and then deploy in Arabic are the ones surprised by truncation.

Morphology: One Root, Hundreds of Surface Forms

Arabic is a templatic, root-and-pattern language. Most words derive from a three-consonant root, and meaning is generated by fitting that root into patterns and by attaching clitics — prefixes and suffixes glued directly onto the word. Take the root k-t-b, which carries the idea of writing: from it you get kataba (he wrote), kitab (book), maktab (office), maktaba (library), and katib (writer) — one root, many words.

Then clitics pile on. A single orthographic word can carry a conjunction, a preposition, the definite article, a tense marker, the verb, and an object pronoun all at once — the English phrase "and they will write it" can be one Arabic word. This is why naive matching and search fail on Arabic:

• Keyword search misses. A customer asks about "the invoice" with the article and a preposition attached; your index stored the bare noun; the strings do not match even though the meaning is identical.
• Embeddings drift. The same concept appears in dozens of inflected, clitic-laden forms, and weaker multilingual embeddings place them further apart than they should, so retrieval returns the wrong chunk. Names and product codes can also acquire attached particles that a brittle parser reads as part of the token.

The engineering answer is normalisation and segmentation before you index or embed anything. Arabic-specific tooling such as CAMeL Tools or Farasa can strip clitics, normalise variants, and segment words into their meaningful units, so "the invoice" and "invoice" land in the same place. Systems that skip this inherit the morphology problem at the worst possible layer — where the model decides what facts to answer from.

Diacritics and Spelling Drift

Arabic is normally written without short vowels, so the same consonant skeleton can represent several different words and the model must disambiguate from context. On top of that, real Arabic input is full of orthographic variation that carries no meaning difference but wrecks exact matching:

• The various forms of hamza and alif written interchangeably.
• The final ya and alif maqsura swapped, and ta marbuta written as plain ha.
• Elongation marks (tatweel) added for decoration, and Latin and Arabic-Indic digits used interchangeably.

To a human these are the same word; to an unnormalised string index they are different tokens. A reliable Arabic pipeline applies a consistent normalisation pass — unifying hamza and alif variants, ya and alif maqsura, and ta marbuta, stripping tatweel, and standardising digits — on both the stored documents and the incoming query, so the two are compared on equal footing.

Right-to-Left and Mixed-Direction Rendering

Even when the model gets the language right, the interface can get the display wrong. Arabic renders right-to-left, but real messages are mixed-direction: an Arabic sentence containing an English product name, a phone number, or a URL forces the Unicode bidirectional algorithm to decide where each run starts and ends. Get it wrong and you see reversed phone numbers, misplaced punctuation, or an English clause landing in the wrong order inside an Arabic one.

This is the front end's job, not the model's, and it is routinely neglected because English-first teams never see the failure. A correct build tests the widget with genuine mixed-direction content — Arabic wrapped around Latin brand names, digits, and links — and sets text direction and bidi isolation so numbers and embedded English render as written. Messaging channels such as the WhatsApp Cloud API handle much of this, but any custom web widget must be verified deliberately, because an accurate answer displayed backwards still reads as broken.

Diglossia: MSA Versus Gulf, Egyptian, and Levantine

"Arabic" is not one language in use. Modern Standard Arabic is the formal written register — news, contracts, official communication — and it dominates model training data, which is why models answer MSA so fluently. But nobody messages a business in MSA. They write in dialect, and the dialects diverge from MSA and from each other: Gulf Arabic (Khaleeji) is not Egyptian, which is not Levantine, and within the Gulf, Emirati and Saudi usage differ again.

The failure mode is subtle and dangerous: the model does not error out on dialect, it quietly misreads it and answers confidently, and a word that means one thing in MSA can mean something else in Khaleeji. This is why Gulf Arabic NLP is its own discipline — the training data skews formal, so the last mile of reliability is dialect coverage the base model does not give you for free. You close that gap with retrieval grounding on your own dialect-aware content and evaluation sets built from real Khaleeji messages, not by hoping a bigger model has memorised your customers' phrasing.

Arabizi and Code-Switching

Two more input styles are normal in the Gulf and absent from most tokeniser training data. Arabizi is Arabic typed in Latin letters, using numerals for sounds with no Latin equivalent — 3 for the letter ain (ع), 7 for haa (ح), 2 for hamza, 5 for kha, 6 for the emphatic taa, 9 for saad, with conventions that vary by writer. A message like "mata btiftah bukra?" written as "mata btfta7 bkra?" is completely ordinary, and a bot blind to it is blind to a real share of the inbox.

Code-switching is the other: Gulf customers flow between Arabic and English inside a single sentence — "hi, 3ndkum appointment bacher evening?" — and the system has to understand the whole thing and reply in a sensible register. Neither is solved by a language dropdown. They are solved by treating language as a per-message property detected from the text, including both in your test sets, and grounding answers so that whatever script the customer uses, the facts come from the same source of truth.

Why a Machine-Translation Layer Is the Wrong Fix

The tempting shortcut is to build an English system and bolt on translation: translate the Arabic message to English, run the English pipeline, translate the answer back. It looks like reuse. In production it is a reliability tax:

• It loses dialect and register. Translation normalises Khaleeji and Arabizi into flat English, discarding exactly the signal you needed to answer well and reply in the right tone.
• It doubles the error surface. Every translation is a lossy step, and you have added two of them around your actual logic, so mistranslations of names, numbers, and negations propagate silently.
• It adds latency and cost. Two extra model calls per turn, on top of the token inefficiency Arabic already carries.
• It breaks rendering and tone. Round-tripped Arabic often reads as stiff translated English and mishandles right-to-left formatting.

The reliable pattern is to answer natively: retrieve from your knowledge base and generate the response in Arabic directly, keeping the customer's language and register end to end. Translation has a place — internal logging, or letting an English-speaking supervisor read a transcript — but not in the critical path of understanding and answering the customer.

Retrieval Grounding for Arabic

Grounding — retrieving source text and having the model answer from it rather than from memory — is the single biggest lever for Arabic reliability, because it moves the burden off the model's shaky dialect recall and onto content you control. But retrieval only helps if the Arabic-specific work is done at each stage:

• Normalise before you embed. Apply the same hamza, alif, ya, and ta-marbuta normalisation to documents and queries so morphological and orthographic variants match.
• Choose embeddings tested on Arabic. Multilingual embedding quality varies sharply across languages; pick and verify a model that actually clusters Arabic paraphrases together, rather than assuming multilingual means Arabic-capable.
• Store the source natively. Keep your Arabic knowledge in Arabic. Index it in a vector store such as pgvector alongside your English content, and let cross-lingual retrieval serve either language from the authoritative source.
• Chunk for morphology. Respect sentence and clause boundaries so clitic-heavy Arabic is not split mid-word.

Done this way, an Arabic answer is anchored to a document you control, which collapses the hallucination risk that dialect uncertainty would otherwise create. This is the backbone of our retrieval-grounded AI agents: the model's job shrinks from "know all Arabic" to "read this passage and answer in the customer's language", which it can do well.

How to Actually Evaluate Arabic Quality

Most Arabic AI ships untested, because the team measured it the way they measure English. Automatic metrics like BLEU tell you almost nothing about whether a Gulf customer felt understood. Evaluate Arabic on its own terms:

• Build dialect-specific test sets. Separate suites for MSA, Gulf dialect, Arabizi, and mixed English-Arabic, drawn from real messages your business has received, not invented textbook sentences.
• Use native human review. A native Khaleeji speaker judging whether an answer is accurate, natural, and appropriately polite catches what no metric does. Grammatical Arabic can still be tonally wrong for your brand.
• Run adversarial inputs. Deliberately test Arabizi spellings, mid-sentence switches, missing diacritics, and dialect vocabulary, and log where comprehension drops. Verify right-to-left rendering, numbers, and dates in the live widget while you are there.
• Measure per language. Track resolution and escalation rates for Arabic and English separately. If Arabic escalates to humans far more often, the gap is visible in one number and fixable with targeted tuning.

Evaluation is not a gate you pass once. Arabic quality is maintained by reviewing failed Arabic conversations on a schedule, because new dialect phrasings show up in transcripts, not in the original test plan.

Treating Arabic Reliability as a First-Class Discipline

This is why we treat Arabic as an engineering problem in its own right, not a checkbox on a feature list. Tokenisation, morphology, diacritics, bidi rendering, diglossia, Arabizi, code-switching, native grounding, and dialect-aware evaluation are each a place where a bilingual system silently degrades — and each is addressable if you decide it matters before you build. For public-facing and government services, Arabic is not optional, it is the expectation.

That is the standard behind our Arabic and English support agents and every bilingual AI chatbot we build: answer natively in the customer's language and register, ground responses in your own documents so dialect uncertainty cannot turn into confident nonsense, and evaluate on real Gulf Arabic reviewed by people who speak it. Arabic-capable AI is table stakes in the Gulf now; Arabic-reliable AI is still rare. We scope Arabic requirements explicitly on every project and send a fixed-fee proposal, because the reliability you get in Arabic is decided by choices made before the first line of the build.