AI 应用的国际化与多语言

AI 应用有个错觉：模型本来就懂多语言，所以"国际化很轻松"。错。模型能答多语言 ≠ 产品国际化。UI 要翻译、模型输出语言要可控、不同地区合规不同、文化要适配、多语言 RAG 更复杂——这些工程不做，你的"多语言 AI"只是"能蹦几个外语单词"。

一、AI 应用 i18n 的四层

1. UI 翻译      (按钮/菜单/提示的文字)
2. 模型输出语言  (让 AI 用对的语言回)
3. 知识多语言    (RAG 库的多语言检索)
4. 区域适配     (合规/文化/格式)

每层独立，都要做。

二、UI 翻译：和传统 i18n 一样

这部分和普通 Web 应用 i18n 无差，用框架管理：

• next-intl / next-i18next（Next.js）/ react-i18next（React）。
• 抽翻译到 JSON 文件（messages/zh.json、messages/en.json）。
• 按 locale 路由（/zh/...、/en/... 或 as-needed）。

const t = useTranslations();
<button>{t("submit")}</button>

要点：

• 不要硬编码文案，全走翻译键。
• 复数/性别用 ICU MessageFormat（{count, plural, one{# 条} other{# 条}}）。
• 日期/数字/货币按 locale 格式化（Intl API）。

这部分是基础，但只是 i18n 的"表面"。

三、模型输出语言：让 AI 说对的语言

模型懂多语言，但默认会用 prompt 的语言回答，不一定是用户要的语言。要主动控制：

1. 显式指定输出语言。system prompt 里写"用 {userLocale} 回答"，或参数化。

2. 跟随用户输入语言。用户用日语问，就用日语答（最自然，但要 prompt 约束"跟随用户语言"）。

3. UI 语言 ≠ 回答语言。用户界面是英文，但用户用中文提问——通常该跟随提问语言，而不是 UI 语言。

陷阱：

• 混语言。模型有时一句中英夹杂，体验差。prompt 强约束"全程单一语言"。
• 翻译腔。模型把中文想法直译成英文，生硬。要么用目标语言原生素材、要么 prompt 约束"地道表达"。

四、多语言 RAG：最难的部分

知识库含多语言文档时，RAG 复杂度上升：

1. 跨语言检索。用户用中文问，知识库有英文文档——要能跨语言匹配。对策：

• 用多语言 embedding（BGE-M3、Cohere multilingual），中英文档在同一向量空间，能跨语言检索。
• 或翻译对齐：检索时把 query 翻译成文档语言再检。

2. 输出语言统一。检索到英文文档，但要中文回答——prompt 约束"用中文总结以下英文资料"，模型能做，但要明确指令。

3. 分语言索引 vs 统一索引。

• 分语言：每个语言一个索引，检索时按用户语言查对应索引。简单但跨语言弱。
• 统一：所有语言一个索引（需多语言 embedding）。跨语言强但 embedding 要好。

多数场景用统一索引 + 多语言 embedding，跨语言能力最好。

五、区域合规：被忽视的雷区

i18n 不只是语言，还有地区法规：

• 数据驻留：欧盟用户数据不能随便传美区模型（GDPR）。
• 内容合规：某些地区对内容有特殊要求（如德国的仇恨言论法、中国的合规）。
• 模型可用性：某些模型在某些地区不可用（或需特殊部署）。

对策：

• 按 region 路由到合规的模型/部署。
• 内容层做地区化过滤/调整。
• 隐私政策、cookie 提示按地区适配。

面向全球的 AI 产品，合规是 i18n 的一部分，不能只翻语言不管法规。

六、文化适配：超越翻译

直译不等于本地化。文化差异：

• 例子/比喻。"像买大白菜一样便宜"对老外无意义，要换当地等价表达。
• 禁忌。某些话题/颜色/数字在特定文化敏感。
• 度量衡/日期/货币。习惯不同（美式日期 vs 国际、华氏 vs 摄氏）。
• 敬语/称谓。日韩等语言的敬语体系，直译会失礼。

AI 输出的文化适配，prompt 里给约束："用符合 {locale} 文化习惯的表达，避免当地禁忌"。或对关键市场做专门的 prompt/数据适配。

七、一套多语言架构（next-intl）

实战架构（和很多 Next.js AI 应用一致）：

/i18n/routing.ts         locales + defaultLocale + as-needed 前缀
/messages/{locale}.json  UI 翻译
/middleware               按 locale 路由 + cookie 持久化
/lib/ai.ts                接受 locale,system prompt 注入输出语言
/lib/rag.ts               多语言 embedding 统一索引

关键设计：

• locale 从路由/cookie 取，贯穿 UI + AI 调用。
• AI 调用传 locale，system prompt 按需切语言。
• RAG 用多语言 embedding，不按语言分库。
• hreflang 正确标注（SEO，告诉搜索引擎各语言版本）。

八、别犯的错

1. 以为模型懂多语言就不用 i18n。UI 还是中文，老外看不懂。
2. UI 语言和 AI 回答语言强绑。用户用外语问，AI 该跟随提问语言。
3. 单语 embedding 硬上多语言。中文 embedding 处理英文，检索崩。
4. 直译文化梗。没本地化，体验别扭。
5. 忽略区域合规。全球可用但合规没做，等于埋雷。

小结

AI 应用的 i18n 比传统多一层"模型/AI 部件"：

• UI 翻译：传统 i18n（框架 + JSON）。
• 模型输出语言：显式控制，跟随提问或 UI 语言。
• 多语言 RAG：统一索引 + 多语言 embedding（跨语言检索）。
• 区域合规：数据驻留、内容法规、模型可用性。
• 文化适配：超越翻译，本地化表达。

记住一句：AI 的多语言能力是"模型层"的，产品的国际化是"工程层"的——模型懂多语言只是给了你国际化的可能，真正让产品全球可用，UI/AI/RAG/合规/文化每一层都要做。把这五层做扎实，你的 AI 产品才从"能答外语"变成"真正的国际化产品"。