多语言大模型与跨语言能力

1. 多语言能力是怎么来的？
1. 根源是预训练语料的语言构成：哪种语言数据多，哪种能力就强。
2. tokenizer 也在投票：英文主导词表下，其他语言被切得很碎。
3. 语言之间存在迁移：高资源语言学到的推理和世界知识会跨语言共享。
4. 指令微调若以英文为主，其他语言的任务表现也要靠迁移撑。
5. 所以多语言能力是"数据配比 + tokenizer + 微调分布"三者的合力。
6. 模型规模越大迁移越明显，小模型跨语言衰减更快。
7. 面试要点：能从数据和词表两个层面解释"为什么英语强小语种弱"。

2. 为什么低资源语言效果差？
1. 数据稀缺：互联网文本里小语种占比极低，学不充分。
2. tokenizer 压缩率差：同样内容 token 数是英文的几倍，窗口等效变小。
3. 高质量指令数据少，对齐和任务能力都是英文数据"翻译迁移"来的。
4. 文化知识缺乏：本地常识、地名人名在语料里出现频率太低。
5. 评测也缺：小语种基准少且质量参差，改进难以度量。
6. 结果是理解、生成、推理全面偏弱，而不只是某一环。
7. 优化路径：扩词表、继续预训练、翻译增强语料、社区共建评测。

3. 跨语言迁移和一致性问题是什么？
1. 同一个事实用不同语言问，答案可能不一致甚至矛盾。
2. 知识在参数里以"语言绑定"的形式存储，跨语言对齐并不完美。
3. 推理能力迁移好于知识迁移：数学各语言都行，本地知识各语言都弱。
4. 训练时做跨语言一致性数据（平行语料、翻译对齐）能改善。
5. 检索场景更明显：中文知识库用英文问题查，召回会掉。
6. 产品上要做"语言一致性"测试，不能假设能力全球均匀。
7. 面试加分：能区分"能力迁移"与"知识对齐"这两个不同层面。

4. 中英混合（code-switching）输入怎么处理？
1. 真实用户输入经常中夹英：品牌名、专业术语、缩写混在中文里。
2. tokenizer 要能平滑处理混排，不能因为切分问题破坏语义。
3. 训练数据要有自然混排语料（论坛、弹幕、技术社区），不是纯单语。
4. 提示词可要求输出语言跟随用户主语言，避免语言跳变。
5. 检索场景要做混合语言索引，query 里英文关键词也能命中中文文档。
6. 评测集专门构造混排样本：术语混排、品牌混排、emoji 混排。
7. 面试时强调"混排是常态不是异常"，评测要反映真实分布。

5. 翻译场景和通用多语言对话的要求差在哪？
1. 翻译要忠实原文，允许直译的生硬；对话要自然地道，允许意译。
2. 翻译评测有成熟指标和人工标准，对话评测更主观更难。
3. 翻译关注术语一致性、风格、格式的保留（如代码注释、表格）。
4. 对话关注文化适配：称呼、礼貌等级、节日常识这些不是翻译能覆盖的。
5. 专门翻译模型和通用模型可以并存：垂直翻译要精确控制时用专模型。
6. 文档翻译的排版、术语库、记忆库是工程问题，模型只是其中一环。
7. 面试要点：说清"忠实度"与"地道度"是两个不同的优化目标。

6. 多语言怎么评测？有什么坑？
1. 基准层面：翻译用 FLORES 类集合，理解用各语言版 MMLU 类。
2. 坑一：答案泄露语言——模型用英文思考后翻译成小语种，掩盖真实能力。
3. 坑二：翻译腔评测数据，考的是翻译不是语言能力。
4. 坑三：文化偏差，本地常识题被按西方常识出题，结果系统性错。
5. 自建评测要用母语者标注，至少覆盖核心市场的语言。
6. 报告时按语言分别给分，平均分会掩盖某个语言的塌方。
7. 面试要点：指出"评测数据本身的翻译质量"是常见盲区。

7. 想支持一门新语言，技术上怎么做？
1. 先评估 tokenizer 对该语言的压缩率，太差就要考虑词表扩充。
2. 收集该语言语料：公开文本、翻译平行语料、领域数据。
3. 继续预训练：以不伤原有能力为前提，混入足量英语数据做"保鲜"。
4. 指令微调：构建该语言的指令数据，或从英文指令翻译增强。
5. 评测先行：用母语者建一套小而准的评测集，全程用它做回归。
6. 词表扩充是大动作，涉及所有下游重训，能不动就不动。
7. 面试时按"评测、数据、续训、回归"四步答，体现工程闭环。

8. 文化与本地化为什么不只是翻译问题？
1. 同样的产品话术，不同文化对礼貌、直接程度的预期不同。
2. 法律合规差异：数据展示、免责声明、隐私表述各地要求不同。
3. 格式本地化：日期、货币、地址、姓名顺序都有本地惯例。
4. 敏感话题地图：某地的节日、宗教、政治话题要有针对性护栏。
5. 模型的世界知识本身带文化偏向，本地常识可能真不知道。
6. 本地化要母语者参与审核，机器翻译审不出文化问题。
7. 面试要点：举一个"翻译对了但文化上冒犯"的例子最有说服力。

9. 多语言 RAG 有什么特殊问题？
1. 跨语言检索：query 语言和文档语言不一致时召回显著下降。
2. embedding 模型的多语言对齐能力参差，选型要实测跨语言召回。
3. 方案一：查询翻译成文档语言再检索，增加一道工序和误差。
4. 方案二：多语言 embedding 直接跨语言检索，依赖模型对齐质量。
5. 知识库本身多语言时，要做语言路由，避免给用户错语言的引用。
6. 生成端还要处理"引用文档语言"与"回答语言"的转换。
7. 面试能画出"query 语言识别 → 检索策略 → 回答语言控制"这条链即可。

10. 多语言场景下的安全有什么不同？
1. 越狱攻击在低资源语言上成功率更高，因为安全训练数据少。
2. 内容审核模型对非主流语言误判率更高，漏放和误伤并存。
3. 多语言测试要成为安全红队的固定科目，不能只测中英文。
4. 方言、俚语、拼音缩写等变体是绕过审核的常见通道。
5. 翻译中间层可能引入语义漂移，安全过滤放在哪一层要仔细设计。
6. 各地区法规不同：同一句话在某些市场违法，要有地区化策略。
7. 面试要点：能说出"安全能力也有语言不平等"就是有洞察。

11. 做多语言产品最容易踩的坑？
1. 只在英文/中文上测试就全球上线，小语种市场体验崩塌。
2. 用平均分评估多语言模型，掩盖某个关键市场的塌方。
3. 忽略 tokenizer 成本差异，某些语言用户账单贵几倍。
4. 知识库只有中文，海外用户检索全靠硬扛。
5. 本地化只做了界面翻译，没审模型输出的文化适配。
6. 评测集机器翻译凑数，测出来的好成绩是假的。
7. 安全护栏只在主语言生效，其他语言成了绕过通道。

包含的内容比较多，这里只做了简单的截图介绍，需要拿来学习的小伙伴查看下方图片！

📚 大模型面试题系列 · 持续更新

INTRO_REMOVED

长按识别二维码，添加微信好友

获取完整版面试题合集，注明「面试」通过好友申请