Researchers teach LLMs to adapt to dialect: the CAP method and 10 model families

Chat models almost always answer in standard English, whatever dialect they are spoken to in. Researchers checked what actually happens inside post-training. They took 10 open model families and examined each stage: supervised fine-tuning, DPO and reinforcement learning. The conclusion: responses that look the same hide unequal treatment of different dialects. In the DPO update, British and Australian spelling is preferred over AAE (African American English) and Singlish in all 10 families. To fix this, the authors propose CAP, calibrated accommodation pairs, a preference dataset.

What shows up in the update, not in the response

A typical audit looks at the model's output. The user writes in a dialect, the model answers in standard English, and the picture looks even: everyone is standardized the same way. The authors show that this is not enough. Post-training does standardize responses to any informal signal overall, but that is only the surface.

To look deeper, they read what exactly each update prefers. They took two replies with identical content: one matches the user's dialect, the other does not. They then compared which way the model shifts, adjusting for how likely each reply was before training. Without this calibration, it is easy to confuse "the model already writes this way often" with "training pushes it to write this way."

After the adjustment, the picture diverges from the visible one. The DPO update prefers matching British and Australian spelling, but is not inclined to match AAE and Singlish. This reproduced across all 10 families. At the same time, the models themselves can produce AAE features when asked. So the ability exists, but preference training does not reward it by default.

CAP: pairs that reward dialect density

CAP is built as preference data with two conditions. The model is rewarded for matching the density of the user's dialect. Standard English users, meanwhile, keep getting standard English. The second part matters: without it, the method turns into a universal "dialect" mode that nobody asked for.

Testing on a fully open model produced the following results:

• convergence grows on dialect features that CAP was not trained on;
• no noticeable increase in dialect was found for standard English users;
• instruction following does not suffer;
• one-sided pairs produce a comparable gain, but only through overshooting: the model goes beyond the user's style and imposes the dialect.

Why one-sided pairs are worse

The simplest way to make a model answer in a dialect is to collect pairs in which the dialect response always wins. The convergence metric will improve. But the model starts speaking "more dialectally" than the user and applies this where it is not needed. The authors call this overshooting. So a convergence number without control over density is misleading. Calibrated pairs remove the skew: the reward is tied to how much dialect the user had, not to the mere presence of dialect features.

What to change in the evaluation pipeline

The main practical takeaway concerns audits. If a team checks only the model's responses, it may miss that the DPO stage has already locked in a preference for some varieties of English. You need to look at the update itself: compare pairs with identical content and account for the baseline probability of each reply.

For those who build preference data, the takeaway is this: check not only whether the model adapts, but how much. A test on standard English users is mandatory, otherwise an improvement for one group will turn into a degradation for another. A test on features absent from training shows whether the model learned general accommodation or memorized a set of specific constructions.

The code is published on GitHub in the kouzhizhuo/cap-accommodation repository. So far the method has been tested on one fully open model, but the audit across 10 families provides a ready-made protocol that can be run on any other.