去年我在排查一个多语言客服机器人的线上问题时遇到了一个非常典型的场景同一套大模型服务英文对话的解决率超过 90%切换到乌尔都语之后整个系统的回答质量立刻崩塌——不是语气生硬而是模型经常给出与问题完全无关的回复。一开始团队以为是提示词写得不好或者温度参数没调对。但换了好几种提示策略之后问题依旧。后来我们把输入文本在 tokenizer 层打出来看才发现根因远不在提示词层面那句话被切成了几十个碎片部分关键信息在分词阶段就被拆得面目全非。这个是今天很多大模型应用团队都会遇到的隐形坑。表面上看模型是多语言的号称支持上百种语言但在真实的 AI 基础设施中从数据采集、分词器设计、指令微调到评测基准每一个环节都默认建立在主流语言之上。那些不在主流语言覆盖范围内的使用者会在模型的输出里被系统性地忽略。本文将拆解这种结构性沉默产生的技术根源并给出开发者在现有基础设施上能做哪些具体改进。1. 这篇文章真正要解决的问题先说清楚Structural Silence结构性沉默指的是什么。它不是指某个模型不支持某种语言也不是指机器翻译效果差这种孤立问题。它描述的是AI 系统从数据、算法、评测到产品策略的完整价值链中都默认服务于主流语言使用者导致少数语言使用者在大模型应用里没有可用的服务、没有可靠的评测、没有反馈通道最终表现为系统性地失声。为什么这件事值得技术团队现在关注原因有几个很多企业做大模型落地时只验证了英语或中文场景就以为产品已经多语言化。这个假设在真实使用中会反复出问题。修复这类问题的成本会随着产品上线时间推移持续上升。上线越久用户产生的行为数据和反馈越是集中在高质量语言上少数语言的数据进一步萎缩修复的边际成本更高。全球范围内的开发者工具、SaaS 产品、客服系统都在接入大模型能力如果底层基础设施对语言有选择性那么整个行业都会把一部分用户排斥在 AI 红利之外。这篇文章主要面向这样三类读者正在做多语言产品的大模型应用开发者想搞清楚为什么模型在部分语言上表现差。负责 AI 基础设施或数据平台的技术负责人想在架构层面降低语言偏差带来的风险。做 NLP/AI 工程研究的同学希望了解语言多样性与模型基础设施之间的技术连接点。读完这篇文章你会得到一个可以落地的分析框架当模型在少数语言上表现不佳时应该从哪几个层面排查每一步怎么验证以及怎样在工程上逐步改善。2. 基础概念语言基础设施的四个层面要理解结构性沉默你需要先理解现代大模型服务所依赖的语言基础设施。它通常包含四个层面任何一个层面出问题最终都会表现为模型输出质量下降。2.1 数据层数据层是最底层也是影响最大的一个环节。大模型的预训练语料、指令微调数据、偏好对齐数据都是从互联网和人工标注管道中获得。互联网语料天然存在语言能力的不平衡。英语内容在互联网上占据绝对主导地位中文、西班牙语、阿拉伯语等虽然有不小的体量但相比英语仍有数量级差距而斯瓦希里语、孟加拉语、缅甸语、泰卢固语等语言公开语料可能只有英语语料的几十万分之一。2.2 词法层词法层主要指 tokenizer分词器。大模型不会直接读原始文本而是先通过 tokenizer 把文本切成 token 序列。当前主流的 BPEByte Pair Encoding算法依赖语料中的 token 频次来决定合并顺序。主流语言的高频子词会被优先合并进词表而少数语言里常见的词缀、音节能被合并的机会少得多。后果是同一个语义量的文本英语可能需要 100 个 token缅甸语可能需要 300 个 token。这不仅影响生成速度还会影响模型对语义的捕捉能力。2.3 模型层模型层包括预训练基座、继续预训练、指令微调、RLHF 或 DPO 对齐过程。模型层的问题通常不是一个模型不支持某语言而是模型对某种语言的表征能力弱导致它即使看到正确的输入也无法在内部空间里形成有效的语义映射。2.4 评测与产品层很多团队在模型上线前只用英文或中文测试集做评测。即使模型发布方声称支持一百种语言评测报告里覆盖的语言往往也非常有限。产品层则面临更现实的问题少数语言用户的反馈往往很难进入产品迭代的数据管道因为用量少、标注难、ROI 看起来低。下面这个表可以帮你快速定位问题所在的层面层面典型症状排查方向数据层模型生成流畅但事实错误多缺乏语感检查预训练语料与微调数据的语言分布词法层回答很慢输入被切成大量碎片对比不同语言的 token 数量模型层同义输入不同语言表现差异大逻辑能力不迁移检查模型的多语言评测细分指标评测与产品层团队看不到问题用户不反馈检查评测数据集的语言覆盖与反馈通道这四层相互嵌套多数时候你遇到的是多层问题叠加。3. 技术根源之一数据管道中的主流语言马太效应数据层的问题是整个结构性沉默的起点也是最难在短期内修复的一层。3.1 互联网语料分布的不平衡预训练语料通常来自 Common Crawl、Wikipedia、书籍、代码仓库等公开来源。这些来源对语言的覆盖天然不均。以 Common Crawl 为例它虽然包含大量语言但清洗后真正可用于训练的高质量文本英语占比遥遥领先。少数语言的网页数量本来就少且其中还混入大量机器翻译文本、低质量内容和格式混乱的页面过滤后剩下的可训练语料更少。这种不均衡直接影响了模型对语言的学习深度。预训练阶段模型需要大量样本来记住一门语言的语法模式、常用搭配和世界知识。数据量不足时模型可以生成听起来像那么回事的文本但一旦涉及复杂推理、文化背景或专业术语就会迅速露出破绽。3.2 清洗与过滤规则隐含语言偏见更隐蔽的问题在于数据处理流程里的很多通用规则并不是真正通用的。去重算法往往基于英语的句子结构设计对形态丰富的语言如土耳其语、芬兰语可能出现错误合并或错误分割。基于语言标识的过滤模型可能把某些少数语言的高质量文本误判为低质量内容因为过滤模型本身也是在主流语言上训练的。长度过滤规则会删除很多短文本但某些语言的信息密度较高一个短句包含的语义量可能抵得上英语一个长句。这些规则看起来是中性技术决策但对语言分布的影响是实实在在的。3.3 数据稀缺的负循环少数语言数据少模型表现差模型表现差用户不使用该语言的生成能力用户不使用企业没有动力去采集和标注该语言的数据缺少数据模型继续差。这是一个典型的马太效应也是结构性沉默最难打破的地方。工程层面的含义是如果团队只依赖在互联网上抓更多数据这一条路少数语言支持几乎不可能自然改善。必须有意识地设计数据补充策略。4. 技术根源之二分词器设计中的语言盲区这一层是很多开发者在实际调试中最容易遇到的问题也最值得单独拿出来分析。4.1 BPE 分词的核心逻辑当前主流大模型基本都使用 BPE 或类似算法构建词表。BPE 的思路不复杂从一个字符级别的词汇表出发反复统计训练语料中相邻 token 的出现频率每次把最高频的一对合并成新 token直到达到预设的词表大小上限。这个算法本身无所谓语言偏见但它对训练语料的频率分布高度敏感。主流语言中频繁出现的子词单元会被快速合并占据大量词表配额少数语言中同样常见的词缀和音节因为整体出现次数不够多只能停留在单字符或双字符的粒度。4.2 少数语言在 token 层面的代价举个例子假设一个缅甸语单词在语义上等价于英语的 understanding英语里它可能被切成understanding两个 token而缅甸语因为没有进入合并优先级可能被切成三到四个甚至更多的单字符 token。token 数量多的直接后果有三个生成速度变慢因为模型每生成一个 token 都需要一次前向计算。上下文窗口被浪费本来能容纳 8000 token 的上下文用少数语言可能实际只包含 3000 token 的语义量。语义建模困难模型在注意力机制中可获取的上下文信息变少远距离依赖更难捕捉输出质量进一步下降。4.3 在本地验证 tokenizer 的语言覆盖HuggingFace 的transformers和tokenizers库可以很方便地查看不同语言在同一个模型下的 token 数量差异。下面的代码展示了一个最小验证方式# 文件路径check_tokenizer.py from transformers import AutoTokenizer model_id meta-llama/Llama-3.1-8B-Instruct tokenizer AutoTokenizer.from_pretrained(model_id) texts { english: The quick brown fox jumps over the lazy dog., swahili: Mbweha mwepesi wa kahawia anaruka juu ya mbwa mvivu., burmese: မြန်မာနိုင်ငံသည် အရှေ့တောင်အာရှတွင် တည်ရှိသည်။, } for lang, text in texts.items(): tokens tokenizer.encode(text) print(f{lang}: {len(tokens)} tokens - {tokens[:10]}...)运行后你可能会发现同样语义长度的句子英语是 10 个 token而缅甸语是 20 甚至 30 个 token。这个数字的差异会直接反映在 API 成本和生成延迟上。4.4 应对思路词表扩展与语言感知分词部分团队会通过扩展词表来缓解这个问题。具体做法是在目标语言语料上重新训练一个额外的 BPE 词表把原模型词表里缺失的该语言高频子词加进去然后调整 embedding 矩阵的维度。这种方案需要继续预训练或者做 embedding 初始化过程相对复杂但它比什么都不做更有效。还有一种更轻量的思路是使用语言感知的分词策略例如在识别到少数语言文本时先用一个针对该语言的预分词器做预处理再送入通用 tokenizer但这需要团队有较强的 tokenizer 定制能力。5. 技术根源之三指令微调、对齐与评测的系统性遗漏模型预训练完成之后往往还要经过指令微调SFT和人类偏好对齐RLHF/DPO才能成为可用的对话产品。这两个阶段的数据语言分布同样会加剧结构性沉默。5.1 指令数据以主流语言为主目前公开的高质量指令数据集以英语为主导。很多开源社区的数据集是拿 GPT 系列模型或人工标注生成的天然继承了对英语的偏好。即便有一些多语言指令数据集覆盖的语言也主要集中在西语、法语、德语、中文等高资源语言低资源语言的指令样本可能只有几百条。SFT 的目标是让模型学会服从指令的模式。当指令数据里 95% 是英语时模型会隐性地把高质量回答这件事与英语的词汇、句式、知识组织方式绑定。切换到少数语言时模型不知道该调用哪一套行为模式。5.2 RLHF 中的奖励模型偏好偏好对齐阶段奖励模型Reward Model负责给候选回答打分。奖励模型本身也是在一个偏好数据集上训练的而这个偏好数据集同样以英语为主。当模型输出少数语言时奖励模型可能因为训练数据不足而给出不稳定的分数导致强化学习过程无法有效优化该语言的输出质量。这意味着即使你做了一轮 RLHF模型在少数语言上的表现也未必会提升反而可能因为奖励信号的噪声而退化。5.3 评测基准的语言覆盖再看评测层面。很多模型发布报告里的多语言能力是怎么证明的通常的做法是抽几个公开的多语言基准比如 MMLU 的多语言子集、XNLI、FLORES 机器翻译基准但这些基准覆盖的语言和被真实使用的语言集合之间存在明显差距。测试集里没有的语言团队在开发过程中就看不到问题更谈不上修复。这是结构性沉默在工程流程上的一个关键原因不可见则不可改进。5.4 建立语言覆盖清单一个直接的工程建议是在模型上线之前先建立一份语言覆盖清单明确以下问题问题说明你的产品实际服务哪些语言从用户需求出发而不是从模型支持列表出发每个语言在评测集里有多少样本少于 500 条的语言不能作为有效评测依据每个语言在真实流量中有多少曝光确认低表现语言是否真的存在实际用户该语言的上线标准是什么不要用英语标准一刀切但至少要设定质量底线6. 真实影响面从看不见到用不了结构性问题往往不会直接报错它的危害在于让一部分用户和开发者在同一个系统里逐渐失联。这部分我们按不同角色拆开看。6.1 对终端用户服务质量断崖少数语言用户向客服机器人提问时系统可能给出语法通顺但语义完全偏离的回答。用户尝试两三次后就会放弃之后转向人工渠道或者直接流失。更麻烦的是很多产品会在大模型输出结果不理想时静默地降级为简单关键词匹配的兜底回答。于是用户感知到的是这个产品根本不支持我的语言。6.2 对开发者问题定位难开发者在排障时通常会先怀疑提示词、温度参数、上下文长度。对少数语言的输入这些常规手段几乎不奏效因为问题根源不在推理策略而在模型内部的多语言能力分布。团队很难区分这是模型能力上限还是当前配置没调好这会让排障陷入长期停滞。6.3 对研究者缺少可靠基线对少数语言做研究的人很难找到可靠的评测基线。如果连一个标准测试集都没有任何改进都无法被量化验证。研究进展缓慢反过来又导致工程改进缺乏方法指引。6.4 对商业团队市场扩张受限如果 SaaS 产品计划进入东南亚、南亚或非洲市场大模型语言覆盖能力会成为隐性门槛。销售团队签下客户后交付团队才发现产品在本地语言上表现不佳交付周期被拉长客户满意度下降。从商业角度看这已经不是技术债而是营收风险。7. 工程实践从分词到微调的全链路改进这一部分直接从操作层面讲在现有基础设施上能做的改进按优先级和成本从低到高排列。7.1 先测量再优化改动之前先做一个语言质量盘点。推荐做法是选取目标语言的高频业务场景准备 100 到 300 条高质量测试 prompt分别在当前模型上测试记录输出质量、token 消耗和延迟。这个测量动作应该覆盖数据、词法、模型、评测四个层面。7.2 数据侧定向补充与合成数据只靠公开语料很难解决少数语言数据稀缺。可以考虑以下手段采集目标语言的高质量网页、书籍和政府公开文档时使用更严格的语言识别模型。使用机器翻译生成训练数据的镜像版本但只作为辅助不能作为唯一来源。在指令微调阶段把少数语言的高质量 seed 样本通过人工编写和翻译扩展成一批覆盖典型业务场景的指令数据。合成数据有风险尤其是翻译内容可能带有翻译腔和事实偏移。务必要做一轮人工抽检确认目标语言表达的自然度。7.3 tokenizer 侧检查并优化分词效率可以先运行上文的分词检查脚本统计目标语言的平均 token/词比。如果明显偏高再考虑词表扩展。下面给出一个使用 SentencePiece 训练小型扩展词表的示意流程# 文件路径train_extended_sp.py import sentencepiece as spm # 假设 target_corpus.txt 是目标语言的清洗后文本 spm.SentencePieceTrainer.train( inputtarget_corpus.txt, model_prefixsp_extended, vocab_size16000, model_typebpe, character_coverage0.9995, )训练出扩展词表后再对比原始 tokenizer 与扩展词表在测试句子上的分词效率。效率提升显著时才值得把扩展词表合入主流程。7.4 模型侧继续预训练或 LoRA 适配如果预算允许优先考虑在目标语言语料上做继续预训练continued pretraining让模型重新熟悉该语言的数据分布。如果预算有限LoRA 或 QLoRA 是可接受的低成本替代。下面是一个用 PEFT 加载模型做语言适配的示例结构# 文件路径lora_adapt.py from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model model_id your-base-model tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained(model_id) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, ) peft_model get_peft_model(model, lora_config) peft_model.print_trainable_parameters()值得注意LoRA 适配通常只改变模型在特定任务或特定语言上的输出风格不能解决数据层和分词层的根本问题。它更适合快速让系统在某个语言上可用而不是彻底重建多语言能力。7.5 评测侧搭建目标语言的小型基准没有评测就没有改进。团队可以自己搭建一个小规模的多语言评测集包含以下三类样本真实业务对话从客服日志、工单系统、用户反馈中脱敏后沉淀。公开测试集过滤从 XNLI、FLORES、BUCC 等公开基准中筛选目标语言子集。人工构建的对抗样本专门测试模型对文化背景、谚语、低资源词汇的理解。评测集不需要一开始就很大100 到 300 条高质量样本已经足够发现大多数问题。8. 运行结果与效果验证完成以上改进后如何判断真的有效建议用同一组测试集做前后对比并记录关键指标。8.1 验证流程冻结测试集选择 200 条目标语言测试 prompt不随机更换。逐项打分可以请熟悉该语言的人员从语义准确性、语言自然度、任务完成度三个维度打分1 到 5 分。记录 token 成本对比改进前后生成相同回答的平均 token 数。记录延迟统计 P50 和 P95 生成延迟。8.2 预期结果判断指标改进前改进后判断依据任务完成度1.8 分3.5 分是否达到业务最低可用标准token 数/回答320 tokens210 tokens成本是否下降P95 延迟4.2s2.8s用户是否可以接受需要提醒的是如果只做了 LoRA 适配而没有处理词法层token 数和延迟可能不会显著下降。如果你在验证中发现某项指标没有变化说明对应层面的问题还没被解决应该回到第 7 节对应的小节继续排查。9. 常见问题与排查思路在支持少数语言的实践中团队通常会遇到下面这些问题。这里整理成一张排查表方便直接对照问题现象可能原因排查方式解决方案模型生成内容语法通顺但语义完全偏题数据层语义覆盖不足模型缺少该语言的推理 anchor检查预训练语料中该语言的占比跑 50 条种子 prompt 看错误分布定向补充高质量语料做继续预训练或 LoRA 适配单条输入被切出大量 token生成延迟高tokenizer 对该语言分词效率差运行分词对比脚本统计 token/词比扩展词表换用语言感知更强的 tokenizer 或模型英文评测分数高目标语言评测分数突然下降指令微调或对齐阶段的主流语言偏好单独运行目标语言评测集查看逐条输出在 SFT 数据中加入目标语言指令样本单独做一轮偏好适配目标语言用户反馈量极少像是没人在用用户已经流失或产品入口屏蔽了该语言检查接入渠道的语言识别逻辑和客服转人工记录确认语言路由逻辑恢复该语言入口主动收集失败案例SFT 后模型反而放弃了目标语言改用英文回复SFT 数据主要覆盖英文模型决策倾向英文检查 SFT 数据中的语言分布比例在 SFT 阶段加入语言保持正则项或强制指令如果排查后依然无法定位建议直接做语言分组的 A/B 测试将同一 API 请求分别用英语和目标语言发出去观察系统在不同语言下的内部路由与提示模板是否一致。很多时候问题出在业务代码里的语言分支逻辑而非模型本身。10. 最佳实践与工程建议前面几节讲的是怎么修这一节讲的是怎么长期避免踩坑。结构性沉默不是一次性 bug它是系统设计中的默认假设长期积累的结果。10.1 在需求评审阶段引入语言风险评估每次产品迭代如果涉及面向用户的内容生成都应该增加一个语言覆盖检查问题这次改动会影响哪些语言受影响语言在评测集里的样本量是否足够如果不够是否需要先补充测试数据10.2 建立语言相关的可观测性指标不要把语言维度排除在监控之外。建议在日志中记录每次请求的检测语言、token 数和生成延迟并按语言维度聚合告警。以下是一个简化的日志埋点结构{ request_id: req_8f3a2b1c, detected_language: my, prompt_tokens: 128, completion_tokens: 96, latency_ms: 2350, model_id: llama-3.1-8b-instruct, error_kind: none, region: sea }有了这个结构化日志后续做语言维度的体验分析会顺畅很多也可以在模型升级前后快速对比不同语言的表现变化。10.3 维护一份语言支持状态文档团队内部应有一份实时更新的语言支持状态表内容包括该语言是否上线、评测集样本量、最近一次人工评估分数、已知问题链接。这个文档比任何口头承诺都更能避免上线事故。10.4 注意安全与数据合规边界面向少数语言用户的数据采集通常涉及跨境数据流动和隐私合规问题。务必确保训练数据的采集有合法授权用户数据在使用前完成脱敏处理涉及生产环境的任何语言支持变更先在测试环境验证并且保留回滚机制。改进语言覆盖是长期工程不是一次性任务不要为了追求数据量而突破合规底线。10.5 认知层面把语言多样性当作工程质量指标语言支持不应该是政治正确或者加分项它应该是一个工程指标。你的模型是否在缅甸语上能用和你服务的可用性、可靠性、成本控制一样都是产品质量的一部分。只有当团队把语言多样性当成硬指标来管理结构性沉默才可能真正被打破。11. 从 AI 基础设施层面重新理解语言公平回到开头那个客服机器人的例子。真正的问题不是模型不懂乌尔都语而是整套 AI 基础设施从语料采集到评测反馈都没有把乌尔都语当作一等公民来对待。这是一条漫长的链路任何一环的默认假设都在放大语言多样性上的差距。从工程视角看语言公平不是抽象概念它具体表现为数据管道里少数语言有没有独立的采集、清洗和质量评估流程。tokenizer 里目标语言的词元效率有没有被监控。模型训练里指令微调和对齐阶段有没有纳入目标语言样本。产品评测里上线标准是否考虑了多语言维度。线上可观测性里是否按语言维度记录了延迟和错误率。作为开发者你可能无法在一篇文章或一个版本里解决所有问题。但你可以从今天开始做一件事找到你的产品服务但尚未纳入评测的语言建一个一百条的测试集跑一遍看看现在的系统到底表现如何。很多时候打开灯看到问题就已经解决了一半。