您为德国团队开发了一个聊天机器人。用户界面是德语。源文档部分为德语，部分为英语。助手背后的工具希望使用英文枚举值、英文功能描述、英文产品名称等所有英文内容。
然后有人用德语问了一个非常正常的问题，模型选择了正确的工具，传递了一个德语参数，而不是英语参数，然后整个事情就悄然崩塌了。
这种情况我已经见过很多次了，所以我不再认为这是翻译问题。**这是一个执行问题。
我目前的默认做法很简单：用户想说什么语言就让他们说什么语言，但只要可靠性确实重要，就让 LLM 用英语完成检索、推理和工具工作。然后在这个循环之外将答案本地化。
这听起来有点异端。在我看来，这也是目前最实用的方法。
研究开始大声说出这句话
数字不再微妙。
在MASSIVE-Agents 基准中，研究人员对 52 种语言、47,020 个样本和 21 个模型的多语言函数调用进行了评估。所有语言的最佳平均得分仅为 34.05%。英语达到了 57.37%。阿姆哈拉语降至 6.81%。
这可不是一个小的质量波动。这是一个可靠性悬崖。
还有更接近真实系统问题的[Lost in Execution]（https://arxiv.org/abs/2601.05366）。论文显示，许多多语言工具调用失败都发生在模型已经理解了意图并选择了正确工具之后。主要问题是参数值语言不匹配。通俗地说，模型知道要做什么，但却用用户语言而不是界面语言来表达可执行位，因此调用还是失败了。
这种情况不仅限于工具调用。Etxaniz 及其同事在 多语言语言模型的英语思维能力更强吗? 一文中发现，在五项任务中，自我翻译成英语的结果始终优于直接非英语推理。他们的措辞直截了当，令人耳目一新：模型 "在非英语语言的提示下无法充分发挥其多语言潜力"。
所以是的，多语言模型令人印象深刻。但是，如果你的标准不是 "听起来不错"，而是 "在生产中必须表现正确"，那么英语在很多时候看起来仍然是更安全的操作语言。
为什么 RAG 会在同一个地方断裂
人们听到这个论点通常会首先想到代理。函数调用、结构化输出、API 执行，诸如此类。
RAG 也有同样的弱点，只是早了一层。
如果你的检索层必须将用户的本地用语与混合语言编写的内容相匹配，同时还要使用不一致的术语、翻译过的产品名称和半本地化的分类标签，那么你就会创造更多机会，让系统在开始生成之前就发生偏移。老实说，这就是很多人抱怨 "模型不可靠 "的原因。模型可能是好的，但内容界面却不是。但内容界面却不是。
我宁愿尽早规范化。
将问题翻译成英语。根据英语规范语料库进行检索。让模型在一个稳定的术语层上进行推理。必要时生成英文版的答案草稿。然后为用户翻译或本地化最终答案。
这样，您就可以在一个地方保持命名的稳定性：
- 一个规范文档标题
- 一个规范的产品词汇
- 一个统一的工具模式
- 一套统一的检索标签
您仍然可以在外部支持每种用户语言。您只需停止要求核心执行路径在每一步都完美地使用多种语言。
这不是反本地化
恰恰相反。
糟糕的多语言人工智能架构通常会首先伤害本地用户。他们得到的是漂亮的本地化界面，然后隐藏在界面下的以英语为中心的系统却表现不一致，让他们付出代价。
正确的本地化意味着要诚实地对待语言在哪些地方应该灵活运用，哪些地方不应该。
对我来说，这种划分是这样的
- 本地化用户界面、提示、帮助文本、入职培训和最终答案。
- 本地化人们在市场中需要直接阅读的源内容。
- 如果内部工具定义、规范标识符、检索标签和推理枢纽是最稳定的层，则将其保留为英文。
- 在本地化输出具有法律、监管或合同权重的情况下，添加明确的后处理或人工审核。
最后一点比团队愿意承认的更为重要。如果模型是与人对话，本地化就是一个用户体验决策。如果模型是在与另一个系统对话，语言就是界面合同。
这两者不是一回事。
我现在最信任的架构
这是我目前最信任的多语言人工智能产品版本：
1.用户用自己的语言提问。 2.系统将请求翻译或规范化为英语。 3.根据英文规范数据进行检索、推理、排序和工具调用。 4.将最终答案本地化为用户的语言。 5.高风险输出在离开系统前会有额外的验证步骤。
这在哲学上并不纯粹。它在操作上是合理的。
好在最近的研究也指出了同样的方向。Lost in Execution发现，对用户查询进行预翻译通常比事后修复能更好地减少语言不匹配错误，尽管它仍然不能完全恢复英语级别的性能。这与许多构建者在实践中已经怀疑的情况不谋而合。如果等到最后才清理多语言不一致问题，通常为时已晚。
当然，也有例外。如果你正在为低资源语言、特定领域语言或文化依赖性措辞进行构建，将所有内容翻译成英语可能会带来漂移。上述论文明确警告了这一点。所以，不要把这变成教条。
但作为企业副驾驶、内部助理、多语种 RAG 和工具使用代理的默认设置，我认为这条规则的适用性出奇地好。
这对 Rasepi 意味着什么？
这正是我如此关注规范内容结构的原因。
如果你的知识库有一个简洁的源代码层、稳定的术语和可控的本地化，那么人工智能就更容易被信任。如果每种语言版本都在执行路径中独立漂移，你就会要求模型在系统应该精确的地方随机应变。
Rasepi 的整个方法就是围绕着将这些关注点清晰地分离出来而构建的。保持核心规范。有意识地进行本地化。跟踪存在变体的地方。不要因为用户界面是多语言的，就认为堆栈的每一层都应该是多语言的。
我曾经认为，最好的多语言人工智能体验意味着 "用用户的语言完成一切"。现在我不再这么想了。对于那些必须检索正确的段落、选择正确的工具并返回值得信赖的内容的系统来说，就不是这样了。
实际规则很简单：用户应保持本地化，但 LLM 的执行路径应保持稳定。现在，这通常意味着中间是英语，边缘是本地化。
这将随着时间的推移而改变。我希望它能尽快改变。但是，如果您现在正在发货，而且可靠性比美观更重要，那么我会让模型用英语思考，让您的产品用用户的语言说话。
