AI不平等是一个真实存在却经常被忽视的问题。当一款语音助手只支持主流语言，当一张图片的描述文本对屏幕阅读器用户完全缺失，当模型对带口音的普通话识别率明显偏低，这些细节背后反映的是同一件事：技术资源分配的不均衡。低资源语言使用者和残障群体在AI产品中往往处于弱势地位，而改变这一现状需要从数据、模型到产品设计的系统性努力。本文将从问题成因、低资源语言技术方案和无障碍设计实践三个角度展开讨论。
AI不平等从哪里来：数据、算力与设计假设的三重偏差
第一重偏差来自数据。大模型的能力上限基本由训练语料决定，而互联网文本天然向少数几种高资源语言倾斜。英语在常见训练语料中的占比通常超过一半，中文、西班牙语、法语等紧随其后，而全球七千多种语言中的绝大多数，可用的数字化语料可能只有几百万甚至几十万条，有的甚至完全没有书面语料。数据稀缺直接导致模型在这些语言上表现糟糕，表现为频繁的语码混杂、语法错误和事实幻觉。
第二重偏差来自算力和经济成本。为一种使用人口只有几百万的语言单独训练一个大模型，投入产出比在商业上很难成立。这导致技术公司倾向于优先服务大市场，小语种用户被迫接受翻译质量低劣的中间方案，或者干脆被排除在产品之外。这种选择本身没有恶意，但累积效果就是系统性的不平等。
第三重偏差最隐蔽，它藏在设计假设里。很多AI产品的默认用户画像是“视力正常、听力正常、使用标准输入法、能流畅阅读文本”的人。比如纯视觉验证码把视障用户挡在门外，纯语音交互界面对听障用户不可用，密集的长文本输出对阅读障碍用户极不友好。这些假设很少被写进需求文档，却在每一处交互细节中发挥作用。
低资源语言的技术方案：从语料建设到跨语言迁移
解决低资源语言问题的第一步是语料建设。常见的数据来源包括：公开授权的政府文书、宗教文本（这类文本往往是最早被数字化的）、维基百科和开源字幕库、以及社区众包。近年来一个重要趋势是利用母语使用者社区的力量，像Masakhane这样的非洲NLP社区，通过志愿者标注和整理，为数十种非洲语言构建了可用的数据集。对于工程团队来说，与其等待完美数据，不如先从清洗现有噪声数据、构建领域词典、建立评测基准做起。
在模型层面，跨语言迁移是目前性价比最高的路线。多语言预训练模型（如mBERT、XLM-R）通过共享参数，让高资源语言学到的语言知识迁移到低资源语言上。实际操作中通常会采用两阶段微调：先在高资源语言上做任务微调，再用少量低资源语言数据继续训练。下面是一个基于Hugging Face的示例：
from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments
# 使用多语言预训练模型作为基础
tokenizer = AutoTokenizer.from_pretrained("xlm-roberta-base")
model = AutoModelForSequenceClassification.from_pretrained(
"xlm-roberta-base",
num_labels=3
)
# 两阶段微调：先在高资源语言数据上训练
# 再用少量低资源语言数据继续微调（继续训练示例）
training_args = TrainingArguments(
output_dir="./low_resource_finetuned",
learning_rate=2e-5,
per_device_train_batch_size=16,
num_train_epochs=3,
evaluation_strategy="epoch",
save_strategy="epoch"
)
# low_resource_dataset 为少量标注好的低资源语言数据
# trainer = Trainer(model=model, args=training_args, train_dataset=low_resource_dataset)
# trainer.train()</code>
除了迁移学习，还有几条值得关注的路线。一是机器翻译辅助：把低资源语言的少量平行语料与 pivoting 技术（以高资源语言为桥梁）结合，快速构建翻译能力。二是合成数据：用高资源语言生成模型翻译或改写出伪平行语料，再过滤噪声。三是词表与脚本适配：很多低资源语言使用的文字系统未被词表完整覆盖，扩展tokenizer的词表能显著减少UNK token，直接提升表征质量。评测环节同样关键，不要只看整体准确率，要按语言分组报告指标，否则低资源语言的退化会被平均值掩盖。
无障碍设计实践：让AI产品对所有人可用
无障碍设计的第一原则是遵循WCAG（Web内容无障碍指南）的POUR框架：可感知、可操作、可理解、鲁棒。落到AI产品上，具体要做的事情非常具体。首先是输出侧的可感知性：模型生成的图片必须配有有意义的替代文本，这正是多模态模型可以大显身手的地方，用视觉模型自动生成图片描述，能让替代文本覆盖率从几乎为零提升到接近百分之百。
其次是输入侧的多通道支持。语音、文本、触摸不应是互斥选项而应是可切换的通道。一个对话式AI界面，如果只提供语音交互，就等于把听障用户排除在外；如果输出只有密集长文本，视障用户通过屏幕阅读器逐句听取时认知负担极重。更好的做法是支持结构化输出、分段摘要、语速调节，并为语音输出提供实时字幕。
工程实现上，Web端的语义化标签是无障碍的基石。用<button>而不是用<div>模拟按钮，用<label>绑定表单控件，为动态更新内容提供aria-live区域，这些细节决定了屏幕阅读器用户的实际体验：
<!-- 语义化按钮，键盘和屏幕阅读器天然可用 --> <button type="button" aria-label="重新生成回答">重新生成</button> <!-- 表单控件与标签显式关联 --> <label for="lang-select">界面语言</label> <select id="lang-select"> <option value="bo">藏语</option> <option value="ug">维吾尔语</option> </select> <!-- AI回答动态更新时，用aria-live通知屏幕阅读器 --> <div id="ai-response" role="status" aria-live="polite"> 回答将在此处显示 </div>
还有一个容易被忽略的维度是认知无障碍。AI生成的回答往往冗长且结构松散，对认知障碍用户和老年用户不友好。产品层面可以提供简单语言模式（Plain Language Mode），要求模型用短句、常见词汇和清晰的分步结构作答。测试环节也不应只依赖自动化的无障碍扫描工具，一定要邀请真实的残障用户参与可用性测试，自动工具能发现缺失标签，但发现不了混乱的交互逻辑。
把公平性纳入研发流程：可执行的改进清单
理念和单点优化之外，真正让改变发生的是流程固化。建议团队建立一份公平性检查清单，在需求评审、模型评测和发布验收三个节点强制执行。模型评测按语言、口音、年龄段分组报告指标；界面走查覆盖键盘-only操作、屏幕阅读器走查、对比度检查、字幕完整性；数据治理明确低资源语料的授权合规与社区回馈机制。
值得强调的是，低资源语言和无障碍设计并非纯公益投入，它们往往能带来意外的产品收益。为低资源语言优化的模型通常在高资源语言上也有提升，因为多语言联合训练本身是一种正则化；而无障碍设计的受益人群远大于残障群体，字幕服务于嘈杂环境的所有人，简单语言模式帮助非母语使用者。技术包容性做得越好，产品的真实可用人群就越广，这才是解决AI不平等的商业逻辑与技术逻辑的交汇点。