What Arabic Dialect Math Problems Reveal About Model Reasoning

What Arabic Dialect Math Problems Reveal About Model Reasoning

6 min read

A new benchmark called DAR-MGSM tests whether large language models can do grade-school math across five Arabic dialects, and finds that cultural localization, not just translation, breaks reasoning in ways accuracy scores hide.

TL;DR: A new benchmark shows that when you adapt math word problems to local Arabic culture, not just translate the words, model accuracy drops and the internal reasoning path changes, which means your “multilingual” eval is probably measuring translation, not understanding.

The primary source here is DAR-MGSM (Dialectal Arabic Multilingual Grade School Math), posted to arXiv under both cs.AI and cs.CL as “Benchmarking Arabic Dialects for Math Problems.” It is the first manually curated benchmark for math reasoning across Dialectal Arabic, and it does something most multilingual benchmarks skip: it separates the act of translating a problem from the act of localizing it.

That distinction is the whole story. Most of us treat “does the model work in language X” as a translation question. This paper says that is the easy half. The hard half is culture, and culture is where the reasoning quietly falls apart.

What is DAR-MGSM actually measuring?

MGSM is the multilingual version of GSM8K, the grade-school math word problem set everyone cites. DAR-MGSM extends that idea into Dialectal Arabic, which matters because Arabic is not one thing. Modern Standard Arabic (MSA) is the written, formal register. What people actually speak in Cairo, Casablanca, Riyadh, Beirut, and Baghdad diverges enough that treating them as one language is a modeling error, not a simplification.

The benchmark covers five major dialects plus MSA, and it ships in two parallel versions. One is translated-only: same problem, rendered into the dialect. The other is translated and culturally localized: the entities and references get swapped for regional ones. A problem about buying apples at a generic store becomes a problem grounded in a specific regional context, with names and references that fit the place.

a single math problem branching into two paths, one plain and one woven with regional cultural markers

Here is why that design is smart. If you only translate, you can’t tell whether a model is reasoning or pattern-matching against the English training distribution it has seen a thousand times. The GSM8K problems have effectively leaked into every large model’s training data in one form or another. A faithful translation keeps the underlying structure familiar. Localization breaks that familiarity while keeping the math identical. The arithmetic doesn’t change. The surface does.

So DAR-MGSM is really two measurements stacked: can the model handle the dialect, and can it handle the math when the cultural scaffolding is unfamiliar.

Why does cultural localization hurt accuracy?

The headline finding is that performance generally declines on the localized version. The eleven models evaluated, a mix of Arabic-centric and general multilingual LLMs, did worse when the problems were culturally grounded rather than plainly translated.

That is the part worth sitting with. The math did not get harder. The numbers are the same. What changed is that the problem no longer looks like the training data.

This is a distribution-shift result dressed in a linguistics costume. When a model has seen countless near-identical English and MSA math problems, a translated version is close enough to trigger the learned pattern. A localized version, with unfamiliar entities and regional references, pushes the input off the well-worn path. The model has to actually parse and reason rather than recognize. And accuracy drops.

The paper is careful here: the magnitude varies across models. Arabic-centric models showed different levels of sensitivity to localization. That is not a footnote. It means some models have genuinely absorbed cultural and dialectal variety, while others are passing the translated test on familiarity alone and getting exposed the moment you localize. A single aggregate number would hide that completely. You need the paired versions to see it.

What does the interpretability analysis add?

This is the finding I’d put on the whiteboard. The authors ran a mechanistic interpretability analysis and found that translated and localized variants of the same problem often induce distinct internal reasoning trajectories, even when aggregate accuracy stays similar.

Read that twice. Same math, same answer, same score, different path through the model.

two different internal routes through a layered network converging on the same endpoint

For a practitioner, this is the warning label on every multilingual eval you’ve ever trusted. Matching accuracy does not mean matching behavior. Two versions of a problem can score identically and the model can be arriving at those answers by completely different internal routes. One route might be robust. The other might be fragile, dependent on a surface cue that vanishes under slightly different phrasing or a harder variant.

Accuracy is a lagging indicator here. It tells you the model got the right answer on this set, today. It does not tell you the reasoning will hold when the distribution shifts again. The interpretability result says the reasoning is already shifting underneath a flat accuracy curve. If you only watch the top-line score, you are blind to that drift until it bites you in production, probably on exactly the inputs that differ most from your eval set.

What should builders do with this?

The obvious lesson is for anyone shipping into Arabic-speaking markets, but the deeper lesson is for everyone running multilingual or localized products in any language.

First, stop conflating translation with localization in your evals. If your non-English test set was produced by running English problems through a translation API, you are measuring the easy half. You are not testing whether the model handles the culture your actual users live in. DAR-MGSM’s two-version design is a template you can copy: build a translated-only set and a culturally localized set, and diff the scores. The gap between them is your real exposure.

Second, don’t trust aggregate accuracy as proof of equivalence across languages or locales. The interpretability finding is the catch most readers will miss. Equal scores can hide unequal reasoning. If you have the tooling, probe the internal behavior, not just the output. If you don’t, at least stress-test the localized variants harder, because that is where fragility hides.

Third, treat “Arabic support” or any language claim as a question, not a checkbox. The paper shows Arabic-centric models varied in how well they handled dialect and localization. Vendor marketing flattens all of that into one word. Your eval should break it back apart: which dialect, translated or localized, and does accuracy survive contact with real cultural grounding.

The quiet point across both the accuracy and interpretability results is that reasoning is not language-neutral. A model that reasons well in English and MSA is not guaranteed to reason the same way in Egyptian or Moroccan Arabic, even when the final answers match. DAR-MGSM gives us a way to see that, and seeing it is the first step to not getting surprised by it. Build the paired eval. Watch the gap. The number that matters is not how well your model scores in one locale, it’s how much that score moves when you make the problem look like the place your users actually come from.