One knowledge base, two languages: a bilingual Arabic and English assistant for UAE customers

The situation

A UAE utility handled a large volume of customer questions about bills, connections, moving home and service interruptions. Customers wrote in Modern Standard Arabic, Gulf Arabic, English, and frequently a mix of Arabic and English in the same message, sometimes in Latin script. The knowledge base was inconsistent: some policies existed only in English, some only in Arabic, and translations drifted out of date.

An earlier chatbot pilot had worked well in English and poorly in Arabic. Leadership wanted an assistant that treated Arabic speakers as first-class users, answered from current policy and never exposed customer data outside the country.

What had to be true

• Answer in the customer's language, whichever language the source document was written in.
• Cite the policy behind every answer, so agents and customers can check it.
• Handle real Arabic: dialect, spelling variation, diacritics and code-switching.
• Measure quality per language, not as one blended score that hides Arabic failures.
• Keep personal data in the country and out of prompts where it isn't needed.

Architecture

The data flow, end to end

Retrieval-augmented generation grounds answers in retrieved documents rather than the model's memory, which is what makes citations possible³. Multilingual embedding models make the cross-language part work: models such as multilingual E5 were trained on large collections of multilingual text pairs so that equivalent meaning in different languages lands close together². Embedding choice is covered in choosing embedding models and hybrid search in hybrid search for RAG.

The hard part: Arabic that real customers write

Benchmarks use clean Modern Standard Arabic. Customers don't. The work that made the difference was unglamorous:

• Normalising letter variants and removing diacritics for keyword search, while keeping the original text for display.
• Adding a keyword index alongside vector search, because product names, area names and account terms are often written inconsistently.
• Building the evaluation set from real anonymised questions in Gulf Arabic, Modern Standard Arabic, English and mixed messages, scored separately.
• Choosing the answering model on that evaluation set. Arabic-centric models such as Jais were developed precisely because Arabic is underserved, with training that combined a large Arabic corpus with English data¹; the right choice is whichever performs best on your own questions.

The general approach to evaluation is in evaluation sets that predict production.

How it ran

Key decisions and trade-offs

The federal Personal Data Protection Law governs personal data processing in the UAE⁴. Commentary notes it does not apply in the DIFC and ADGM free zones or to health data covered by separate law, and that transfers abroad are generally limited to jurisdictions with adequate protection⁵. Redaction and in-country hosting kept the design simple under those rules; see UAE PDPL and AI architecture.

What I'd do again, and differently

Again: build the bilingual evaluation set first and launch to agents before customers. Differently: involve content owners earlier. Many "Arabic quality" problems were really missing or outdated Arabic source content, not model weaknesses.

If you serve customers in Arabic and English, my AI architecture work and the fractional CTO in the UAE page describe how I approach it, or analyse your challenge and bring the result to a call.