Modern Arabic NLP: Implementing RAG for Arabic Dialects

Why Arabic NLP is different

Arabic is a morphologically rich, right-to-left language with a shared Modern Standard Arabic (MSA) register and dozens of regional dialects — Levantine, Gulf, Egyptian, Maghrebi and more. A single root generates many surface forms through affixes, clitics and templatic morphology, and diacritics (tashkeel) that disambiguate meaning are almost always omitted in real-world text. Off-the-shelf English NLP pipelines routinely fail on these characteristics, so building Arabic-first systems requires a deliberate pipeline.

1. Normalisation and tokenisation

• Unify alef variants (أ إ آ → ا) and yaa/alef-maqsura (ى ↔ ي) when appropriate for search, but preserve them for generation.
• Strip tatweel (ـ) and control marks; keep diacritics only if your downstream task uses them.
• Use a subword tokenizer trained on Arabic (SentencePiece / BPE with Arabic corpora) rather than whitespace tokenisation — Arabic clitics like "و", "ل", "ب", "ك" attach to the following word.
• Prefer models with strong Arabic coverage: AraBERT, CAMeLBERT, MARBERT, Jais, and multilingual LLMs (GPT-4 class, Claude, Gemini) that were trained with substantial Arabic data.

2. Handling dialects

Users write in dialect, but most reference content is written in MSA. Two practical strategies:

• Dialect → MSA rewriting at query time using a small instruction-tuned model. This gives you cleaner embeddings against MSA corpora.
• Dual-index retrieval: keep one index over the original text and one over an MSA-normalised copy, then merge results. This preserves dialect-specific terms while still matching MSA sources.

3. Embeddings that understand Arabic

Choose an embedding model with genuine Arabic training data — multilingual E5, BGE-M3, Cohere multilingual v3, and OpenAI's text-embedding-3-large all perform well. Evaluate on your own data with a held-out set of query / relevant-document pairs; MTEB Arabic tasks are a starting point but not a substitute for domain evaluation.

4. A minimal Arabic RAG pipeline

1. Ingest: normalise text (see step 1), split into ~300–500 token chunks with 10–20% overlap, and store both the raw and normalised chunk.
2. Embed the normalised chunk and index it in a vector database (pgvector, Qdrant, Pinecone).
3. Query rewrite: if the incoming query is dialectal, rewrite it to MSA and expand it with 2–3 paraphrases.
4. Hybrid retrieve: run BM25 over the raw text alongside vector search over normalised text, then fuse with Reciprocal Rank Fusion.
5. Rerank the top 20–50 hits with a cross-encoder that supports Arabic (BGE-Reranker-v2-M3 works well).
6. Generate: prompt the LLM in Arabic, quote the retrieved passages verbatim, and require citations. Instruct the model to answer in the same variety (MSA or dialect) as the question.

5. Evaluation

Build a small (100–300 items) evaluation set in the actual dialects your users write. Measure retrieval (Recall@k, nDCG), answer faithfulness (does every claim appear in a retrieved chunk?), and answer quality rated by a native Arabic speaker. Automated LLM-as-judge is useful but should be spot-checked — LLM judges are still weaker in Arabic than in English.

6. Common pitfalls

• Mixing Arabic and Latin numerals inconsistently — normalise one way and stick to it.
• Losing RTL punctuation direction when concatenating retrieved chunks; render with proper dir="rtl".
• Chunking on periods only — Arabic uses "،" and "؛" heavily. Split on multiple punctuation markers.
• Assuming an English system prompt will produce Arabic-quality output. Write the system prompt in Arabic when the user writes in Arabic.

Where Damasol applies this

We ship these patterns inside Mashroei (business intelligence for Arabic-speaking founders), Wakeeli (Arabic-first legal agent), and Awaiina (Arabic conversational commerce). Each product ships its own dialect coverage, evaluation set, and reranking pipeline — because a generic multilingual model is not enough to serve the Arab world well.