1.1 多语言能力的定义与边界：理解、生成、翻译与跨语言推理
我刚接触多语言模型那会儿，脑子里想得特别简单，能把中文翻成英文，就算多语言了。真跑起业务来才发现这个理解太窄。一个模型处理多种语言，不只是把一句话从A语言搬到B语言，它得能听懂用户在用不同语言说什么，能用对应语言把答案写出来，能判断两种语言表达的是不是同一个意思，还得能拿着中文的问题去读英文的材料，再把结论用中文讲回来。这几件事看着相关，做起来的难度完全不在一个量级上。
我习惯把多语言能力拆成四块来看。理解是底座，模型要能读懂不同语言的输入，包括口语化的、带方言味的、夹杂英文单词的那种真实语料。生成是往外输出，考验的是语法对不对、语感顺不顺、有没有一股翻译腔。翻译介于两者之间，要求源语言和目标语言的信息尽量对齐。跨语言推理最容易被人忽略，它要求模型在一个语言里获得信息，在另一个语言里完成判断。前面三块做得不错，第四块掉链子的模型，我见过不少。
说到边界，我想强调一点，多语言能力不等于所有语言都同等水平。很多模型自称支持上百种语言，实际拿低资源语言去测，出来的结果会让人皱眉头。真正的边界在哪里？我个人的判断是看它能不能在目标语言上稳定完成复杂任务，而不是看它的语言列表有多长。列表长是宣传口径，任务稳才是能力边界。这个区分看着简单，落到选型上能省掉很多返工。
1.2 语言覆盖范围与语言家族分布：高资源、中资源与低资源语言
语言这件事，天然就不公平。英语、中文、西班牙语这些，互联网上的文本量大、标注数据多，模型训练起来吃得饱。斯瓦希里语、乌尔都语、缅甸语这些，能找到的公开语料就薄得多。我平时看模型的语言支持清单，会先把它分成高资源、中资源、低资源三层去看。高资源语言是模型的主战场，中资源语言是及格线附近，低资源语言才是真正暴露技术水平的地方。
语言家族的分布也挺有意思。同一个语系里的语言，模型学起来会互相借力，罗曼语族内部、斯拉夫语族内部，迁移效果普遍比跨语系好。我见过阿拉伯语学得不错的模型，转头去处理豪萨语就明显吃力，语系距离摆在那里。这不是模型偷懒，是共享表示在语系相近的时候更容易对齐。做选型的时候，我会特意去看目标语言跟高资源语言之间的亲缘关系，远的话就得多留一手准备。
有个细节容易被忽视，语言覆盖范围不能只看"有没有"，还要看"深不深"。某些模型对低资源语言能说几句，但一涉及专业领域、长文本、多轮对话，就原形毕露。我一般会准备一套自己的小测试集，挑几个业务里真会遇到的句子，挨个语言过一遍。这比看官方公布的覆盖率数字实在得多。
1.3 多语言能力与单语性能、跨语言一致性的关系
很多人默认一个逻辑，单语强的模型多语言也强。这个假设部分成立，部分不成立。单语性能好，说明模型对语言本身的结构、词汇、表达习惯吃得透，这是多语言的地基。可多语言还多了一层东西，就是语言之间的对齐。我见过单语评测分数很漂亮的模型，翻译过去之后就丢了关键信息，或者用目标语言回答时逻辑跟源语言对不上。地基好不等于楼盖得稳。
跨语言一致性是个很能说明问题的指标。同一个问题，用中英日三种语言分别问，模型给出的核心结论应该是一致的。要是中文说A，英文说B，用户就会犯嘀咕，到底信哪个。我在实际测试里经常做这种平行提问，能快速看出模型的语言间表示是不是真对齐了。对齐好的模型，换语言问就像换了个壳，里面还是同一个人。对齐差的模型，换语言问像换了个脑子。
这里有个微妙的失衡现象值得说。多语言训练有时候会拖累单语性能，尤其是高资源语言。模型把容量分给了更多语言，原本母语上的那点优势可能被稀释。我做项目时会盯着两头看，一头看目标语言的表现，一头看主力语言有没有掉分。只顾着扩语言数量、把主力语言做退步了，这笔账怎么算都不划算。
1.4 业务场景驱动的能力需求拆解：客服、内容出海、跨境检索与本地化
脱离场景谈多语言能力，很容易变成纸上谈兵。拿客服来说，用户不会按教科书说话，会有错别字、会有语气词、会中英混着来。这时候模型的理解鲁棒性比翻译准确性更重要。我的经验是，客服场景要优先保证意图识别和多轮上下文不丢，回答可以稍微朴素一点，但绝不能答非所问。多语言客服最怕的就是语言切换时把前文忘了。
内容出海对生成能力的要求是另一种风格。不是把中文稿子逐句翻过去就完事，得让目标语言的读者读着自然，标题得有当地的味道，案例得符合当地的文化语境。我处理这类需求时，会让模型先理解内容的核心意图，再用目标语言重新组织表达，而不是贴着一句一句翻。翻译腔在营销内容里是致命的，用户一眼就能看出来这是机翻。
跨境检索的难点在跨语言推理。用户用中文搜一个英文资料里的概念，模型得先把查询意图翻译成合适的目标语言表达，再去检索，最后把结果用中文说清楚。这条链路里任何一环断了，用户体验就垮。本地化则是把这些能力打包落地，语言、文化、格式、合规都得照顾到。我越来越觉得，多语言能力最终不是比谁的榜单分数高，而是比谁能在具体场景里少出岔子。
2.1 主流评测基准梳理：多语言理解、生成、翻译与跨语言推理任务
我刚开始搭多语言评测这一摊子的时候，犯过一个典型的错误，拿着一份英文榜单的分数就以为看懂了模型的多语言实力。后来被现实教育了几回才知道，评测这件事得按任务类型分开看。多语言理解这块，XNLI、XCOPA、MMLU的多语言版本是我常翻的几套，前者测的是推理判断，后面那个覆盖面更宽，学科知识、常识推理都塞进去了。XTREME系列算是老牌的综合集，任务种类多，拿来做横向摸底比较顺手。
生成类评测要难搞得多。翻译有WMT和Flores-200撑着，句子对齐、评测流程都成熟，跑出来的BLEU、COMET分数至少有个参照。可真到了开放式生成，比如让模型用印尼语写一段产品介绍，或者用波兰语回一封客服邮件，标准答案根本不存在，自动指标就有点使不上劲。我处理这类需求时通常会自己搭一套小规模的人工评分表，流畅度、信息完整度、语气贴合度各打一分，虽然土，但比盯着一个虚高的自动分靠谱。
跨语言推理是我最看重的一块。XCOPA和XStoryCloze这类基准设计的思路挺聪明，同一个推理题翻译成多种语言，看模型是不是在每种语言下都能给出同样的判断。这种设计直接戳中语言对齐的软肋。我印象很深的一次测试，某模型在英文版XCOPA上表现相当体面，切到斯瓦希里语版本直接掉了二十多个点，那一刻你就明白它所谓的多语言能力，水分在哪里。
2.2 评测维度设计：准确性、流畅性、文化适配、鲁棒性与公平性
准确性最好量化，对错分明，自动判分跑一遍就出结果。可多语言场景下，准确性这一根柱子撑不起整个评测体系。我见过准确率很高的模型，输出的句子语法没毛病、意思也对，读起来就是一股浓浓的机翻味，母语者一看就皱眉。流畅性这东西自动指标抓不住，得靠人。我的做法是每个目标语言找一两个母语使用者，让他们盲评打分，成本不低，但省不得。
文化适配是最容易被漏掉的一维。同一句营销文案，直译过去意思没错，放在当地语境里可能冒犯人，或者根本不接地气。我测过一个案例，模型把中文里的某种吉祥寓意直接搬到阿拉伯语场景，字面翻译无误，文化上完全错位。这一维没法用现成基准测，只能靠场景化的测试集去挖。我通常会准备一批带文化负载的词、节日、称谓、禁忌话题，专门看模型怎么处理。
鲁棒性和公平性我放在一起说。鲁棒性测的是输入有噪声时模型扛不扛得住，拼写错误、语码混合、方言变体，真实用户就是这么说话的。公平性测的是不同语言之间的表现落差，一个模型英语九十分、缅甸语四十分，这个差距本身就是问题。我会把各语言分数拉成一张表，看分布是平的还是断崖式的。断崖太陡的模型，宣称支持再多语言我也不敢往业务里推。
2.3 低资源语言评测的样本构建与数据质量控制
低资源语言的评测集，市面上能直接拿来用的少得可怜。多数时候得自己造。我造样本走过的弯路不少，最早图省事，拿英文测试集机器翻译成目标语言，翻完直接用。结果测出来的分数虚高，模型在翻译腔的句子上表现良好，一换成本地人真实的说话方式就露馅。机器翻译会把源语言的句法结构带过去，造出来的样本根本不像母语者写的东西。
后来我改了流程，机器翻译只作为初稿，必须过母语者润色这一关。润色的人要做的不是纠语法，是把句子改成本地人真正会说的样子，该用口语词就用口语词，该调整语序就调整。这个环节慢，一个语言几百条样本能耗掉好几天，可数据质量上去了，评测结果才有解读价值。我现在的原则是宁要三百条地道的样本，不要三千条翻译腔的样本。
数据质量控制还有一层是标注一致性。同一个样本给两个母语标注者，判断不一致的情况太常见了，尤其是涉及语气、得体性这种主观维度。我会先做一轮标注校准，把分歧大的样本挑出来讨论，定好标准再正式开标。低资源语言找标注者本身就难，很多语言全国能胜任的就那么一小撮人，更得把流程做扎实，别浪费宝贵的人力。
2.4 跨语言迁移效果评估：零样本、少样本与跨语言泛化指标
零样本跨语言迁移的评测逻辑挺直观，模型只在英语上见过某个任务，直接拿到目标语言上测，看它能不能举一反三。这个设置最考验共享表示的质量。我做过一组对比，同一个模型架构，词表覆盖广的版本在零样本迁移上明显更强，词表窄的版本遇到目标语言就开始瞎猜。评测的时候我会把零样本成绩单独列出来，它反映的是模型的底子，不是靠目标语言数据喂出来的。
少样本设置更贴近实际落地。业务方手里往往能凑出几十上百条目标语言的标注数据，拿这点数据做微调，效果能提多少，这是个很实际的问题。我评估的时候会设计梯度，零样本、十六样本、一百样本各测一轮，画出学习曲线。曲线陡的模型说明它迁移潜力大，给点数据就能起来；曲线平的模型，可能得靠大量数据硬堆，成本完全不一样。
跨语言泛化指标这块，我习惯看两个东西。一个是语言间的方差，各语言分数是不是稳定，方差大说明模型偏科。另一个是迁移增益，目标语言上微调之后相对零样本提升了多少。这两个指标放在一起看，能区分出"本来就强"和"学得快"两种模型。有些模型零样本成绩平平，给几条样本就窜上去了，这种在实际项目里反而更好用。
2.5 评测陷阱与结果解读：数据泄漏、语言偏差与基准饱和
数据泄漏是多语言评测里最隐蔽的坑。公开基准在网上挂了这么多年，训练语料里混进去太正常了。我遇到过模型在某个基准上分数高得离谱，细查发现测试集的原文在某开源数据集中出现过。这种分数没有意义，拿来选型会误导决策。我现在的习惯是，对分数异常高的模型保持警惕，能拿到训练数据说明的话尽量核对一下，拿不到就用自己造的私有测试集做交叉验证。
语言偏差藏在基准的设计里。很多多语言基准是从英文任务翻译扩展出来的，任务本身的设计逻辑就带着英文思维，翻译成别的语言之后，有些题目在文化上根本不成立。用这种基准测出来的低分，未必是模型不行，可能是题目本身不适合那个语言环境。我读分数的时候会先问一句，这套题对目标语言公平吗，不公平的话，这个分数只能当参考。
基准饱和是这两年越来越明显的现象。头部模型在经典基准上分数咬得死死的，差距都在小数点后面，区分度基本没了。这种情况下继续拿老基准排名次，意义不大。我的应对是把评测重心往更难的、更贴近真实场景的任务上挪，长文本、多轮对话、专业领域、文化敏感内容，这些地方还大有空间。基准是工具不是目的，模型好不好用，最终还得回到具体业务里去验证。
3.1 低资源语言支持的技术路径：多语预训练、词表扩展与持续预训练
我接触过低资源语言项目之后才明白，模型能不能支持一门语言，从预训练阶段就定下了大半基调。多语预训练是最主流的路子，把几十上百种语言的语料混在一起喂给模型，让它自己在训练过程中摸索语言之间的共性。这个思路有效，可执行起来有个绕不开的问题——语料配比。高资源语言的数据量是低资源语言的几百上千倍，不加干预的话模型学到的能力分布会严重倾斜。我见过有的模型号称支持上百种语言，实际上去测那些低资源语言，生成质量跟高资源语言完全不在一个量级。
词表扩展是我在实际项目里经常用到的补救手段。很多模型的词表是以英语为中心构建的，低资源语言的字符和子词被切得七零八落，一个词进去变成十几个碎片。这种切分方式让模型学起来特别吃力。给词表里补充目标语言的常用子词，等于把入门门槛降下来。我做斯瓦希里语适配的时候就走过这条路，扩完词表再做继续训练，模型输出的连贯性肉眼可见地变好。代价是嵌入层要重新初始化，等于给模型开了个新口子，后续训练得跟上，不然扩了也是白扩。
持续预训练是我认为性价比最高的路径，尤其是业务方手里已经有了一些目标语言的语料。拿一个多语底座模型，在目标语言的通用语料上再跑一轮预训练，让模型把那门语言的统计规律吃透。这件事听起来简单，实际操作时学习率、语料质量、训练步数都得仔细调。我做过一个缅甸语的项目，持续预训练跑了大概几十亿token，效果比直接在目标语言上做指令微调好出一截，原因就在于预训练阶段打的是语言能力的底子，底子不牢，后面怎么微调都受限。
3.2 跨语言迁移的作用机制：共享表示、语言对齐与迁移增益来源
跨语言迁移这件事，我越做越觉得它像一种隐性的翻译能力——模型在英语上学到的东西，能通过某种内部表示迁移到另一门语言上。这个机制的底座是共享表示。多语模型在训练过程中会把不同语言映射到一个公共的语义空间里，意思相近的句子不管用什么语言写，在向量空间里的距离会靠得比较近。我做过一些表示相似度的分析，高资源语言和低资源语言之间的对齐质量，直接决定了零样本迁移的效果好坏。
语言对齐的质量参差不齐。英语和法语、西班牙语这些同属印欧语系的语言，对齐做得相当漂亮，迁移几乎不费劲。换到英语和约鲁巴语、英语和藏语这种语言距离远的组合，对齐质量断崖式下降。我观察到的现象是，模型对低资源语言的处理方式更接近一种粗糙的模式匹配，而不是真正的语义理解。它在英语里学到的推理链条，迁到低资源语言上时经常断掉，输出看着像模像样，逻辑上站不住。
迁移增益的来源我琢磨了很久。一部分来自词汇层面的重叠，尤其是那些从高资源语言借词比较多的语言，词表覆盖好，迁移就顺。另一部分来自句法结构的相似性，语序接近的语言之间迁移效率明显更高。还有一部分我觉得跟训练数据的分布有关，如果低资源语言在预训练语料里出现的上下文足够多样，模型对这门语言的建模就更扎实。这三者叠加起来，构成了迁移效果的实际上限。我在项目里评估迁移潜力时，会先看看这几个维度的基础条件，条件太差的，就得靠数据和微调去硬补。
3.3 低资源场景下的数据增强、翻译增强与参数高效微调
低资源语言的标注数据少得可怜，这是绕不开的现实。我做的第一个低资源语言项目，手里只有几百条人工标注的样本，直接拿去微调一个大模型，效果基本等于没调。数据增强在这种情况下几乎是必选项。最简单的做法是回译，把目标语言句子翻译成英语再翻回来，得到语义相同但表达有变化的样本。这个方法能扩充数据量，副作用是会引入翻译噪声，回译出来的句子有时会偏离原意，用的时候得筛。
翻译增强我用得更多一些。拿高资源语言的标注数据，机器翻译成目标语言，形成平行语料，再拿去做训练。这个路子的问题我前面提过，机翻会带来翻译腔，模型学到的可能是机器翻译的说话方式，不是母语者的表达习惯。我的处理办法是把机翻数据和少量人工润色的数据混在一起用，比例上人工数据占大头，机翻数据做补充。另外我会专门挑一些句式简单的机翻样本，复杂句式翻出来质量太差，反而污染训练集。
参数高效微调在低资源场景里几乎是标配。全参数微调对数据量的要求太高，几百条样本根本喂不饱，还容易过拟合。LoRA这类方法冻结大部分参数，只训练少量适配模块，在低资源语言上表现相当稳。我做过一组对比，同样的数据量下，LoRA微调的效果比全参数微调更稳定，泛化能力也更好。适配模块的体积小，切换语言的时候按需加载，工程上也好管理。我现在做低资源语言适配，默认先上参数高效方案，除非数据量足够大，才会考虑放开更多参数。
3.4 跨语言迁移效果的影响因素：语言距离、数据规模与模型规模
语言距离这个因素，我吃过它的亏之后才真正重视起来。早期做多语言项目，我习惯用一套方法论套所有语言，英语上跑通的流程直接搬到目标语言。后来发现语言距离远的组合，同样的方法效果差出一大截。英语和荷兰语之间，迁移几乎无感，模型稍微见一点目标语言数据就能起来。英语和泰语之间，光靠迁移根本不够，词表、句法、文字系统全都不一样，得把数据增强和持续预训练都堆上去才有效果。
数据规模的影响是非线性的。我观察到的规律是，目标语言数据从零到几百条这个阶段，提升最陡；几百条到几千条，提升放缓但还在涨；再往上走，边际收益递减得厉害。这个曲线对不同语言还不一样。语言距离近的，曲线很快就平了，说明迁移本身就够用。语言距离远的，曲线爬升的时间更长，需要更多数据才能把模型拉到可用的水平。我在做资源规划的时候，会先看目标语言跟高资源语言的距离，再决定数据投入的规模，不然容易投错方向。
模型规模的作用有点微妙。大模型在跨语言迁移上的起点更高，零样本表现明显好于小模型，这是我在多个项目里反复验证过的。大模型对低资源语言的处理更稳，输出的语法错误更少，语义漂移也更轻。代价是推理成本高，部署起来重。小模型不是不能用，前提是得有足够的目标语言数据做微调，把迁移的短板补上。我的经验是，低资源语言场景下，模型规模和数据规模之间是一种补偿关系，预算有限的时候，宁可模型小一点，把省下来的资源投到数据建设上，效果往往更实在。
3.5 低资源语言支持中的文化知识与本地化表达挑战
语言支持做到一定程度，技术问题会退居其次，文化问题浮上来。我做过一个豪萨语的内容生成项目，模型语法上没有大毛病，词汇选择也基本正确，可生成的文本读起来就是不对劲。找母语者一看，问题出在表达习惯上。豪萨语里很多场景有固定的说法、惯用语、称谓方式，模型完全按英语逻辑组织句子，意思对，味道全错。这类问题靠增加语料解决不了，得有意识地把文化知识喂进去。
本地化表达的挑战在于它很难标准化。同一个意思，不同地区、不同社会阶层的说法可能完全不同。模型训练语料里覆盖的往往是某一种主流表达，边缘群体的说法就被漏掉了。我处理这类需求时，会专门收集一批场景化的表达样本，比如问候语、节日祝福、商务称谓、禁忌话题的委婉说法，做成一个小型测试集，看模型能不能在这些点上不出错。这个测试集的规模不用大，但覆盖面要广，能暴露出模型在文化层面的盲区。
文化知识的注入是个慢功夫。我试过在指令微调数据里混入文化相关的问答对，效果有，但不够系统。后来改成分层策略，通用语料打底，文化语料做补充，再针对具体业务场景做定向微调。这个流程跑下来，模型在文化适配上的表现明显好转，可离母语者的水平还有距离。我现在对这件事的预期比较务实，模型能做到不出文化硬伤、表达基本得体，就算达标，剩下的细腻之处，还是得靠本地人工把关。
4.1 基于评测反馈的模型迭代：数据配比、课程学习与语言均衡
评测结果拿回来之后怎么用，这件事比评测本身更让我头疼。我见过不少团队花大力气跑完一堆基准，分数往报表上一贴，然后就没有然后了。我的做法是先把评测结果按语言拆开看，找出模型在哪几门语言上跌得最狠，再看跌的原因是什么。是词表覆盖不够，还是训练语料里这门语言的上下文太单一，又或者是评测集本身有标注问题。这个诊断过程我通常会拉上数据团队一起过一遍，把问题定位到具体的语言和任务类型上。
定位完之后，数据配比是第一个要动的地方。多语预训练里高资源语言天然占大头，模型的能力分布跟着数据分布走，低资源语言就被挤到了墙角。我一般会做温度采样或者按语言重加权，把低资源语言的采样概率提上来。这个比例不能拍脑袋定，得结合评测反馈反复调。我做阿拉伯语方言适配的时候，把海湾方言和埃及方言的采样权重提高了三倍，评测分数上去了一截，但标准阿拉伯语的生成质量轻微下滑。这种此消彼长的关系在配比调整里很常见，需要根据业务优先级做取舍。
课程学习的思路我用得越来越多，尤其是在多语言混合训练的时候。先让模型在语料质量高、语言距离近的数据上跑，再逐步引入噪声大、语言距离远的数据。相当于先搭一个稳的底座，再往上垒复杂的部分。我做过一组对比实验，用课程学习策略训练出来的多语模型，在低资源语言上的零样本表现比随机混合训练高出一截。语言均衡是另一个抓手，我习惯在训练过程中监控各语言的loss曲线，哪门语言掉队了就单独给它加餐，有时候是补数据，有时候是单独跑几轮微调，把均衡性拉回来。
4.2 低资源语言能力提升的工程实践：数据闭环、人工评估与社区共建
低资源语言的数据建设是个长期活儿，靠一次性投入根本撑不住。我现在做项目会先搭一个数据闭环，把线上推理产生的日志、用户反馈、人工抽检结果都收回来，筛选出有价值的样本补充到训练集里。这个闭环跑起来之后，数据量会慢慢滚起来，模型的效果也跟着往上走。我做过一个斯瓦希里语的客服场景，头三个月数据量翻了四倍，大部分来自线上日志的回流清洗。闭环的关键是筛选标准要严，垃圾数据混进去比数据不够更可怕。
人工评估在低资源语言场景里绕不开。自动指标在这类语言上经常失灵，BLEU分数看着不错，实际读起来完全不是那么回事。我现在的做法是每轮迭代都留一批样本给母语者做盲评，评的维度包括语法正确性、表达自然度、文化得体性。评出来的结果跟自动指标做交叉比对，两边差距大的样本专门拿出来分析。这个过程费时费力，可效果比纯看指标靠谱得多。我见过模型在自动指标上涨了两个点，人工评估反而退步的情况，原因就是模型学会了迎合指标，输出变得更机械。
社区共建这条路我越来越看好。低资源语言的使用者分散在全球各地，单靠一家公司的力量去覆盖所有语言根本不现实。我参与过几个开源多语言项目，社区贡献的语料和评测集对模型能力的提升帮助很大。社区共建的难点在于质量把控和激励机制，贡献上来的数据水平参差不齐，得有一套审核流程。我的经验是先把贡献门槛降低，把数据收上来，再靠人工加自动的方式做清洗。愿意贡献母语数据的人本身就是稀缺资源，得让他们觉得这件事有价值。
4.3 跨语言迁移效果的持续监测与风险治理：偏见、幻觉与安全
模型上线之后，跨语言迁移的效果不是一劳永逸的。数据分布在变，用户的使用方式在变，模型的表现也会漂移。我现在的做法是给每门上线语言配一套监测指标，按周跑一次抽检，看生成质量有没有下滑、幻觉率有没有抬头。这套监测体系在低资源语言上尤其必要，因为这类语言的训练数据少，模型本来就处在一个不太稳的状态，稍有风吹草动就容易出问题。我遇到过缅甸语模型上线两个月后生成质量明显下降的情况，排查了半天发现是线上日志回流的数据里混进了大量机翻内容，把模型的表达习惯带偏了。
偏见问题在跨语言场景里表现得特别隐蔽。模型在高资源语言上做了偏见对齐，换到低资源语言上，同样的偏见可能又冒出来了。我做过一组测试，用不同语言问同一个涉及性别、种族、地域的问题，模型在英语上的回答比较中性，在豪萨语和乌尔都语上的回答就暴露出明显的刻板印象。原因是这些语言的偏见对齐数据几乎为零，模型学到的还是预训练语料里的原始分布。治理这类问题得从数据入手，针对目标语言补充偏见对齐样本，把高资源语言上验证过的对齐方法迁移过去。
幻觉在低资源语言上是重灾区。模型对低资源语言的建模不够扎实，遇到不确定的内容时更容易编造。我见过模型在藏语问答里生造出一个根本不存在的机构名称，语法通顺、格式规范，读起来像模像样，一查全是假的。这类问题在客服、医疗、法律这些高 stakes 场景里特别危险。我的处理办法是在低资源语言上加大事实性校验的力度，用检索增强生成把外部知识引进来，同时给输出加置信度标记，让用户知道哪些内容需要人工核实。安全治理这件事没有终点，只能持续盯着。
4.4 多语言AI的应用落地路径：本地化产品、跨语言检索与全球内容生成
本地化产品是我看到落地最扎实的一条路。很多出海企业需要把产品界面、帮助文档、营销素材适配到几十种语言，传统靠人工翻译加本地化团队的模式成本高、周期长。模型进来之后，初稿生成的速度快了不止一个量级，人工的角色从翻译变成审校和润色。我参与过一个电商出海的项目，用模型做商品标题和描述的本地化生成，覆盖了十几种语言，人工审校的工作量降了六成左右。这条路的关键是把人工审校环节保留住，模型出初稿，人把控质量和调性，纯靠模型直接上线风险太大。
跨语言检索的需求这两年涨得很快。用户用母语提问，后台需要检索多语言的知识库，再把结果用用户的语言呈现出来。这个场景对模型的跨语言理解和对齐能力要求很高。我做过一个跨境法律咨询的检索系统，用户用中文问东南亚某国的法规，系统需要检索当地语言的法规原文，理解内容之后用中文回答。难点在于法律术语的跨语言对齐，很多概念在不同法系里没有完全对应的词，模型处理不好就会给出似是而非的答案。我的解决办法是在检索层做术语映射表，把关键概念的跨语言对应关系人工梳理一遍，再让模型在这个框架下工作。
全球内容生成是另一个爆发点。品牌方需要针对不同市场产出符合当地文化习惯的内容，不是简单的翻译，而是用当地人的表达方式重新讲一遍故事。这件事对模型的文化适配能力要求极高。我做过一个快消品牌的全球社交媒体内容项目，同一个产品卖点，在印尼市场要用当地流行的梗和表达方式，在德国市场要突出功能和数据。模型生成的初稿能打个底，可文化层面的细腻调整还是得靠本地团队。我对这条路的判断是，模型能把内容生产的效率提上去，但文化把关这件事短期内离不开人。
4.5 未来趋势：统一多语言基准、低资源语言生态与跨语言通用智能
统一多语言基准这件事，我觉得是接下来一两年最值得关注的方向。现在的评测基准太散了，每家用自己的一套测试集，结果之间没法横向比较。我见过同一个模型在不同的多语言榜单上排名差了十几位，原因是评测集的侧重点和难度分布完全不同。行业需要一个覆盖语言足够广、任务类型足够全、标注质量足够硬的统一基准，把模型的多语言能力放在同一把尺子下量。这件事靠单家机构做不成，得有联盟性质的协作，把各家的评测集和数据贡献出来，做统一清洗和校准。
低资源语言的生态建设是个慢变量，但我认为它的重要性被低估了。现在大部分低资源语言的支持方式是“嫁接”式的，拿高资源语言的模型能力往低资源语言上迁，迁过去的模型带着浓重的高资源语言烙印。真正健康的生态应该是每门语言都有自己的高质量语料、评测集、微调数据和母语者社区。我参与的几个开源项目在往这个方向走，速度慢，可积累下来的东西是实打实的。这件事需要公共资金、企业和社区三方一起投入，纯靠商业逻辑推不动。
跨语言通用智能是个更远的愿景。现在模型的多语言能力更像是多门单语能力的拼盘，语言之间的协同和互补还很弱。我期待看到的是模型能把不同语言里的知识真正打通，用一种语言里学到的推理能力去增强另一种语言的表现，而不是简单的迁移。这个方向的研究还在早期，我看到的几个尝试都还比较初步，可方向是对的。多语言能力的终局不是支持的语言数量有多少，而是模型能不能在不同语言之间自由地调度知识和推理，像一个真正的多语者那样思考。这件事需要时间，也需要整个行业在数据、评测、算法上持续投入。
