📄 Enhancing Dialectal Arabic Intent Detection through Cross-Dialect Multilingual Input Augmentation

Summary

Arabic intent detection is difficult because regional dialects differ widely in vocabulary, spelling and structure, and they borrow words from other languages. The authors test whether a dialectal utterance becomes easier to classify when it comes with machine translations into Modern Standard Arabic (MSA) and English. They use two datasets: the Palestinian (PAL) portion of ArBanking77, with 77 banking intents, and a new GPT-4-generated Tunisian migration corpus labelled for intent strength. Translations come from AraT5-MSAizer (dialect to MSA) and Helsinki-NLP/opus-mt-ar-en (Arabic to English). Each version of the text gets its own encoder: CAMeLBERT-Mix for dialect, MARBERT for MSA and BERT-base-uncased for English. The [CLS] vectors from these encoders are concatenated and passed to a linear classifier. Adding views helps step by step. On the Tunisian data, accuracy climbs from 43.3% with dialect alone to 94.0% with all three inputs. On PAL, it rises from 87.7% to 93.5%. The work suggests that cheap, off-the-shelf translation can compensate for scarce annotated dialect data.

Key points

• The datasets are ArBanking77 PAL (10,821 queries, split 9197/1234/1624, 77 intents) and a 2,000-item Tunisian migration set. The migration set was generated with GPT-4, checked by a native Tunisian speaker, and labelled non-intent, weak intent or strong intent.
• There are three configurations:
  • DOM: dialect only.
  • DMM: dialect + MSA, a 1536-dimensional concatenated [CLS] vector.
  • DMEM: dialect + MSA + English, a 2304-dimensional vector.
• Migration results are 0.433, 0.843 and 0.940 accuracy, with macro F1 rising from 0.35 to 0.94. PAL results are 0.877, 0.893 and 0.935 accuracy, with macro F1 rising from 0.87 to 0.92.
• The translation models are AraT5-MSAizer (BLEU 21.79 on OSACT 2024) and opus-mt-ar-en (BLEU 49.4 on Tatoeba).
• Training uses:
  • batch size 8 with AdamW;
  • learning rate 1e-5 (Migration) and 3e-5 (PAL);
  • gradient clipping at 1.0 and early stopping;
  • 3 epochs;
  • frozen lower encoder layers on the small migration set.

Interesting ideas

• I1. Keep the raw noisy input and add machine-normalized parallel views of it, so the model can draw on both the original wording and a cleaner standardized rendering.
• I2. Give each view its own encoder and tokenizer instead of forcing one shared vocabulary, then fuse at the sentence level.
• I3. Use an ablation ladder that adds one view at a time (single, then dual, then triple input) to show how much each extra source of evidence contributes.
• I4. Build a small domain dataset with an LLM, then have a native-speaker expert validate every item. This gives a fast route to labelled data in a niche domain.
• I5. With little data and several large encoders, freeze the lower layers and clip gradients so that only the task-specific upper layers adapt.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (tokens): informal or dialectal English (slang spellings, regional forms) could get a normalized parallel version for tagging and lemmatizing. The original tokens would stay linked, so every normalization remains traceable.
• I2 (tree): gparse could encode the original sentence and its normalized variant with separate encoders. Comparing the two parses would help with UD dialect conversion.
• I3 (learn): when silver data is built from several witness parsers, adding witnesses one by one would measure each one's marginal value. This would sit alongside negative controls.
• I4 (learn): LLM-teacher-generated items for school tests or word problems could pass through a human-checked tier before being used as gold evaluation data.
• I5 (learn): this could stabilize fine-tuning of gparse or multi-encoder components on small specialised treebanks without erasing pretrained knowledge.