Anyone who has used an LLM voice assistant has heard it read out "The price is $3.45" verbatim: dollar signs, abbreviations, raw URLs and compact numbers are forms optimized for reading on screen, and they become disasters once they reach Text-to-Speech (TTS). A three-author paper from NAVER LABS Europe, accepted to the EMNLP 2026 main conference, lays out a different route: instead of bolting on downstream rewriting modules, directly align the LLM to be speakable from the start (arXiv:2609.01246).
The problem: LLMs are trained for eyes, not ears
Current LLMs are trained on textual data and preferences that target written output. The result is grammatically correct, helpful text that is full of TTS-unfriendly surface forms: symbols, abbreviations, raw URLs and compact numeric notation. The industry-standard fix is a text-normalization post-processing module between the LLM and the TTS engine, but the paper identifies three costs: post-processing adds noticeable latency; it cannot run until a complete sentence has been generated; and it is inherently tied to the tokenization and input format of each specific TTS system — swap the synthesis engine and the rewriting rules may simply fail.
The approach: make speakability a preference alignment target
The authors formalize TTS-friendly text generation as a preference alignment problem and build two preference datasets from scratch: CORA, a synthetic coffee-ordering assistant benchmark with 262 preference tuples targeting conversational responses, and Recipe, 300 tuples sampled from the RecipeNLG corpus (originally 2.2 million cooking recipes) targeting procedural descriptions. Each tuple pairs a TTS-friendly response with a TTS-unfriendly one, covering symbols, abbreviations, numeric shorthands and raw URLs.
Method-wise they adopt the FaST (Feature-aware Sampling and Tuning) framework: instead of a black-box reward model, an LLM automatically discovers a set of interpretable high-level features (such as "numbers spelled out", "abbreviation density", "natural conversational tone"), scores responses per feature, learns feature weights, and then aligns via sampling and tuning. On CORA, the largest negative-weight feature learned is exactly "compact numeric formatting" (-0.50), followed by abbreviation density (-0.32); the top positive weights are natural conversational tone and spelled-out numbers (+0.33 each).
Results: winning with 10 examples
The comparison spans five alignment baselines — prompting, SFT, DPO, GRPO and RFT — across two data regimes (10 vs. 100 training samples) and two model families (Qwen3-4B and SmolLM3-3B). FaST achieves the best TTS-friendliness/helpfulness tradeoff even in the 10-sample low-data regime.
The contrast with two-step text normalization is telling. Post-processing zero-shot output with PolyNorm (Qwen3-4B, few-shot) does push CORA TTS-friendliness to 4.92, but per-response latency doubles from 1.6 to 3.4 seconds; FaST reaches 4.73 in a single step while scoring higher on helpfulness (4.86 vs 4.72). On Recipe the gap widens: PolyNorm 8.5 seconds vs FaST 4.4 seconds.
A human listening study (MUSHRA protocol, 14 valid raters on Prolific) confirms the ranking: FaST scores 68.3, ahead of DPO (55.9) by 12.4 points (p=0.003) and Prompting (51.4) by 16.9 points (p=0.001). The team also validated that their cheap heuristic metric achieves a system-level Spearman correlation of -1.00 with the TTS-to-ASR round-trip metric on CORA — the five systems rank identically, meaning speakability can be assessed without actually running synthesis.
One illustrative example: asked "How much is the banana bread slice?", the zero-shot model answers "$3.45", while the FaST-aligned model says "three point forty-five dollars" — the number is spoken out.
So what
The implications go beyond voice assistants. First, optimizing text generation for a downstream consumption context can be done as lightweight preference alignment that starts working with 10 examples — practical for teams without large annotation budgets. Second, the heuristic metric correlates strongly with human listening judgments, and the authors explicitly note it can be used directly as a reward model — evaluation as reward, connecting to the verifiable-reward RL line of thinking. Third, the limitations are clear: experiments cover English and two domains only, models stop at 3B/4B parameters, and the framework applies to cascade LLM-to-TTS architectures, not end-to-end speech LLMs.
Datasets, metrics and code are open-sourced at github.com/naver/tts-friendly-gen. As voice becomes a default interface for agents, "writes well" and "speaks well" are diverging into two distinct optimization targets — and this paper formally pulls the latter into the alignment agenda.