LLM 多语言任务横评

之前的LLM 中英翻译能力对比只覆盖中英互译。但很多出海项目需要的是非中英语言下的直接生成和推理能力——比如用日语写客服回复、用西班牙语做指令遵循、用阿拉伯语处理从右到左的文本排版。这类场景和”翻译质量”是两码事：模型不是在翻译，而是要直接用目标语言思考和输出。本文聚焦这一块。

一、测试设计说明

本次测试选取 GPT-4o、Claude Sonnet 3.7、Gemini 2.5 Pro、DeepSeek-V3 四个模型，覆盖 5 种非中英语言：日语、韩语、法语、西班牙语、阿拉伯语。测试内容不是翻译，而是直接用目标语言给出指令，让模型直接用该语言回答，考察三个维度：

评分同样由母语或高水平使用者独立评估，以下分数为近似参考值，基于有限测试样本，不代表全量场景表现。

核心观察：西语、法语这类拉丁语系资源丰富的语言，各模型表现都不错且差距小；阿拉伯语和韩语是明显的弱项区间，模型之间的差距在这两种语言上被放大。

一个容易被忽略的问题是：同一道推理题，用英语问和用小语种问，正确率可能不同。我们用相同的逻辑推理题（英语原版 + 各语言人工翻译版）测试：

模型	英语正确率	日语正确率	阿拉伯语正确率	损耗幅度
GPT-4o	92%	88%	79%	中等
Claude Sonnet 3.7	94%	90%	81%	中等
Gemini 2.5 Pro	91%	89%	84%	较小
DeepSeek-V3	88%	80%	68%	较大

现象解释：模型的推理能力本质上依赖训练数据中该语言的覆盖量和质量。英语数据最充分，推理链路最稳定；小语种数据相对少，模型有时会在”用该语言组织推理过程”这一步出现质量下降，即使最终答案的语言理解本身没问题。

工程启示：如果任务本身是推理密集型（比如复杂逻辑判断、多步计算），即使目标用户使用小语种，也可以考虑内部用英语推理、最后一步再翻译成目标语言输出，这样能保留推理准确率，只是要多做一次转换。

测试指令（日语原文）：

お客様から「注文した商品がまだ届いていません」というクレームが来ました。丁寧かつ迅速に対応する返信メールを書いてください。

模型	表现
GPT-4o	敬语使用基本准确，但个别措辞偏”教科书式”，母语者能感觉出轻微生硬
Claude	敬语层次把握较好，语气自然，但句式结构有时偏长
Gemini	整体自然度较高，符合日本商务邮件的常见模板结构
DeepSeek	敬语使用有明显不准确之处（该用尊他语的地方用了自谦语），需要人工校对

结论：日语等敬语体系复杂的语言，模型之间的地道性差距比语法正确性差距更明显——语法都对，但”得体程度”不同,这一点纯自动化评测很难量化，建议关键场景（如面向真实客户的文案）保留人工校对环节。

阿拉伯语评分明显偏低的一部分原因是从右到左（RTL）排版和中英文混排的处理不稳定，尤其是当阿拉伯语文本中夹杂数字、英文品牌名或代码片段时：

阿拉伯语 + 英文品牌名混排示例：
"يمكنك استخدام Claude API للحصول على..."

多个模型在这种混排场景下偶尔出现文本方向错乱、标点位置错误的问题。如果产品面向阿拉伯语等 RTL 语言用户，建议：

场景	建议
面向欧洲市场（法语/西语/德语等）	GPT-4o、Gemini、Claude 均可，差距不大，可按成本选
面向日韩市场	Gemini 2.5 Pro 或 GPT-4o 综合表现较稳，DeepSeek 需要更多校对
面向中东市场（阿拉伯语）	优先做人工校对环节，不完全依赖模型自动生成客户可见文案
多语言推理密集型任务	内部用英语推理链路 + 最后一步翻译输出，规避语言损耗
成本优先、语言要求不高	DeepSeek-V3 性价比仍然突出，但小语种场景质量差距比中英场景更明显

Q：是不是模型参数越大，多语言能力就越强？ 不完全是，训练数据中各语言的比例和质量影响更大。一些中等规模模型因为多语言语料配比更均衡，在小语种上反而优于参数更大但英语语料占比过高的模型。

Q：多语言能力会随模型更新明显提升吗？ 会，尤其是资源相对稀缺的语言，是各家厂商持续投入的方向之一，具体提升幅度以各家发布的评测报告和实际测试为准。

Q：需要针对多语言场景做特殊的 prompt 设计吗？ 建议做。比如在 system prompt 中显式声明目标语言的正式程度、敬语层级要求，能显著改善输出的地道性,尤其是日语、韩语这类对语境敏感的语言。

需要同时测试多个模型在不同语言场景下的表现？YoTradeApi 提供 GPT、Claude、Gemini、DeepSeek 等模型的统一 API 中转，一个账号按量计费，方便快速对比横评。