让语音助手把「The price is $3.45」原样念出来的尴尬,用过 LLM 语音助手的人基本都遇到过:美元符号、缩写、裸网址、紧凑数字,这些为屏幕阅读优化的文本形态,到了语音合成(TTS)环节就成了灾难。NAVER LABS Europe 的三位研究者在 EMNLP 2026 主会论文中给出了一条新路线:与其在下游加重写模块,不如直接把 LLM 对齐成「开口就能念」的模型(arXiv:2609.01246)。
问题出在哪:LLM 是为眼睛训练的
当前 LLM 的训练数据和偏好标注几乎全部面向书面文本,结果是语法正确、信息有用,但充满 TTS 不友好的表层形态:符号、缩写、原始 URL、紧凑数字记法。业界常规解法是在 LLM 和 TTS 之间插一个文本正规化后处理模块,但论文指出三个代价:后处理带来可感知的延迟;必须等完整句子生成后才能运行;而且天然绑定每个 TTS 系统特定的 tokenization 和输入格式——换一个合成引擎,重写规则可能全部失效。
解法:把「可朗读性」做成偏好对齐
研究团队把 TTS 友好文本生成形式化为偏好对齐问题,从零构建了两个偏好数据集:CORA(合成的咖啡点单助手场景,262 条偏好元组,主打对话式回复)和 Recipe(基于 220 万条食谱的 RecipeNLG 语料采样出 300 条,主打程序性描述),每条数据包含一好一坏两个版本,覆盖符号、缩写、数字速记和裸 URL 等典型坑。
方法上采用 FaST(Feature-aware Sampling and Tuning)框架:不用黑盒 reward model,而是让 LLM 自动发现一组可解释的高层特征(比如「数字是否拼写出来」「缩写密度」「对话语气自然度」),按特征打分、学权重、再采样对齐。在 CORA 上学到的最大负权重特征正是「紧凑数字格式」(-0.50),其次是缩写密度(-0.32);最大正权重是自然对话语气和数字拼写(各 +0.33)。
结果:10 条数据就能赢
对比实验覆盖 prompting、SFT、DPO、GRPO、RFT 五类基线,在 10 条和 100 条训练样本两个档位、Qwen3-4B 和 SmolLM3-3B 两个模型家族上跑——FaST 在 10 条样本的低数据档位就拿下 TTS 友好度和 helpfulness 的最佳平衡。
与两步式文本正规化的对比更能说明问题:用 PolyNorm(Qwen3-4B few-shot)后处理零样本输出,CORA 上 TTS 友好度确实冲到 4.92 分,但单条回复延迟从 1.6 秒翻倍到 3.4 秒;FaST 单步拿到 4.73 分,helpfulness 反而更高(4.86 对 4.72)。Recipe 数据集上差距更大:PolyNorm 8.5 秒对 FaST 4.4 秒。
人工听测(MUSHRA 协议,Prolific 众包 14 位有效评审)给出一致排序:FaST 68.3 分,领先 DPO(55.9 分)12.4 分(p=0.003),领先 Prompting(51.4 分)16.9 分(p=0.001)。团队还验证了便宜的启发式指标与 TTS→ASR 回环指标的系统级 Spearman 相关在 CORA 上达到 -1.00——五个系统排序完全一致,意味着评估可朗读性未必真要跑一遍合成。
一个直观例子:问「香蕉面包多少钱」,零样本模型答「$3.45」,FaST 对齐后回答「three point forty-five dollars」——数字直接念出来。
所以呢
这篇论文的启示不止于语音助手。其一,「为下游消费场景优化文本生成」可以做成轻量偏好对齐,10 条数据就能启动,对没有大规模标注预算的团队很实用;其二,启发式指标与人工听测强相关,作者明确说它可以直接当 reward model 用——评估即奖励,对接可验证奖励的 RL 思路;其三,局限同样清楚:实验只覆盖英语和两个领域,模型止步 3B/4B,且只适用于级联 LLM→TTS 架构,端到端语音大模型不适用。
数据集、指标和代码已开源(github.com/naver/tts-friendly-gen)。语音交互正在成为 Agent 的默认界面,「写得好」和「说得好」正在分化成两个不同的优化目标——这篇论文把后者正式拉进了对齐的版图。