AI 应用国际化：Locale 契约、RAG、工具与发布门禁

核心摘要

AI 应用并不存在一个包办所有决策的 locale 字符串。它需要由应用拥有的 Locale 契约：

language + region + jurisdiction + time zone + currency
+ units + product market + terminology + policy + fallback

这些字段影响不同决策，不能彼此推断。fr-CA 可以表达语言偏好，但不能单独证明用户位置、税务状态、法律辖区、币种或同意状态。

生产级本地化，是让 Prompt、检索、工具、安全规则、输出格式和评测共同遵守这份契约。翻译只是系统中的一个活动。

核心要点

• 用 BCP 47 表达语言标签，但不能让它承担标准未定义的事实。
• 用 CLDR 支持的库处理 Locale 数据和格式。 手写日期、复数、数字和货币规则无法规模化。
• 保持任务意图稳定，再本地化行为。 单一基础语言字符串不应成为唯一事实源。
• RAG 与工具必须有 Locale 策略。 错误法律、价格、API、日期解析或单位，会把流畅文本变成产品事故。
• 每个市场独立发布。 每个 Locale 都需要原生任务、安全探针、工具测试和回滚负责人。

用契约替代一个 Locale 字符串

字段与职责

W3C 建议根据 BCP 47 选择语言标签，并使用能表达必要差异的最短标签。Subtag 越多，并不自动意味着越准确。

Locale 解析优先级

一个可解释的默认顺序是：

1. 当前操作的显式偏好；
2. Workspace 或 Tenant 策略；
3. 账户偏好；
4. 已验证的应用上下文；
5. 仅用于展示的 Accept-Language；
6. 成文产品默认值。

IP 推导国家可以作为弱运营信号，但不能可靠证明语言、身份、居住地或司法辖区。每个解析字段都应保留来源，让下游区分用户选择和默认值。

Go 示例：应用自有 Locale 解析

示例使用已规范化 BCP 47 标签的严格 Allowlist。生产平台应使用支持标准的语言标签库和基于 CLDR 的格式化器，不能手动拆分标签。

package main

import (
	"errors"
	"fmt"
)

type LocaleContract struct {
	LanguageTag       string
	Region            string
	Jurisdiction      string
	TimeZone          string
	Currency          string
	Units             string
	Market            string
	Terminology       string
	PolicyVersion     string
	RetrievalFallback string
	Source            string
}

type RequestContext struct {
	OperationLanguage string
	WorkspaceLanguage string
	AccountLanguage   string
}

var supported = map[string]bool{
	"en-US": true,
	"de-DE": true,
	"ja-JP": true,
	"pt-BR": true,
	"zh-CN": true,
}

func resolveLanguage(ctx RequestContext) (string, string, error) {
	candidates := []struct {
		tag    string
		source string
	}{
		{ctx.OperationLanguage, "operation"},
		{ctx.WorkspaceLanguage, "workspace"},
		{ctx.AccountLanguage, "account"},
		{"en-US", "product_default"},
	}
	for _, candidate := range candidates {
		if candidate.tag == "" {
			continue
		}
		if supported[candidate.tag] {
			return candidate.tag, candidate.source, nil
		}
	}
	return "", "", errors.New("no supported language")
}

func main() {
	tag, source, err := resolveLanguage(RequestContext{
		OperationLanguage: "pt-BR",
		WorkspaceLanguage: "en-US",
	})
	fmt.Println(tag, source, err)
}

Resolver 只返回语言偏好与来源。地区、司法辖区、币种和时区必须来自各自可信输入或已批准默认值。

Prompt 本地化：统一任务契约，多种语言实现

分离不变量与 Locale 模块

任务契约应定义与语言无关的行为：

task_id
required inputs
permitted tools
success criteria
facts that require evidence
prohibited side effects
output schema
global safety invariants

Locale 模块再定义：

instruction realization
approved terminology
register and politeness
examples and counterexamples
formatting constraints
local escalation wording
local policy overlays
evaluation cases

这样可以避免两个极端：

• 把一个英文 Prompt 逐句直译到全部市场；
• 每个语言维护互不相关的 Prompt，行为漂移却没有共同契约。

Prompt 发布证据

每个任务和 Locale 都应保留：

• 任务契约版本；
• Locale 模块版本；
• 翻译/作者与评审者；
• 术语来源；
• Prompt Diff；
• 模型快照和解码参数；
• 原生评测结果；
• 未解决的语言或策略例外。

双语评审者负责检查含义，目标语言的真实任务用户负责检查行为是否实用和自然。语言流畅不足以证明可用。

Locale-aware RAG 本质上是来源治理

按语言过滤是必要条件，但远远不够。检索元数据应包含：

检索决策顺序

1. 判断问题实际需要的适用范围。
2. 应用租户与权限过滤。
3. 应用司法辖区、产品和生效日期约束。
4. 使用请求语言检索。
5. 证据不足时执行配置好的回退策略。
6. 在引用中保留源语言和翻译路径。
7. 告诉生成器哪些来源权威、冲突或缺失。

BordIRLines 研究说明，多语言检索不能简化成“只检索提问语言文档”：来源语言构成会影响一致性和地缘偏差，检索系统本身也可能偏爱某些语言。跨语言来源选择必须作为系统行为接受评测。

禁止静默跨市场回退

缺少本地来源时，应明确选择一种结果：

• 停止：高风险法律、医疗或金融任务；
• 提示后使用全球指南：低风险文档场景；
• 跨语言检索：另一语言存在获批权威来源；
• 升级处理：需要人工或本地专家复核。

必须记录触发了哪条策略。静默用美国答案替代欧盟或日本政策，比明确说明“缺少本地证据”更危险。

工具与 Agent 也需要 Locale-aware 契约

本地化改变的是动作，而不只是文字：

解析、规范化、确认

对于有后果的动作：

1. 按 Locale 契约解析输入；
2. 转换成有类型的内部表示；
3. 向用户展示规范化解释；
4. 仍有歧义时要求确认；
5. 向工具传递有类型参数；
6. 验证最终状态并保持无关状态不变。

不能让 LLM 输出自由格式日期字符串后直接传给 API。

安全策略：全球不变量与本地实现

本地化不能削弱核心安全，应分层组织：

1. 全球不变量：禁止伤害与不可妥协控制。
2. 司法辖区规则：法律要求的差异。
3. 文化和语言实现：术语、示例、升级方式、语气。
4. 产品策略：市场可用性与支持路径。

测试至少覆盖：

• 委婉语、方言、Code-switching 和音译；
• 非英文 Prompt Injection；
• 混合语言工具参数；
• 拒答一致性和过度拒答；
• 受保护群体与文化特定伤害；
• 跨语言泄漏受限内容。

不能把更弱的安全 Prompt 翻译版本称为“本地适配”。

衡量真实产品的多语言评测

三类互补测试集

翻译的一致性集合有助于隔离语言影响；原生市场集合可以暴露翻译无法创造的本地假设。WorldBench 通过文化落地工作流，同时检查任务完成和周边状态保持，展示了这种差异。

指标

• 任务成功和最终状态正确性；
• 非目标状态保持；
• 事实结论是否由权威证据支持；
• 术语一致性；
• 日期、数字、币种、姓名和单位准确性；
• 工具选择与有类型参数准确性；
• 安全误杀和漏放率；
• 回退与升级是否正确；
• 按 Locale 的 P50/P95 延迟与 Token/成本分布；
• 合格母语评审者的可接受性。

聚合总分会掩盖单个语言或市场失败。发布门禁应按 Locale 和高风险任务类型分别执行。

发布与回滚

Locale 就绪门禁

1. 已记录规范标签与受支持变体。
2. Locale 字段均有权威来源和优先级。
3. 用户可见值使用 CLDR 支持的格式化。
4. 任务契约与 Locale 模块独立版本化。
5. 检索来源有适用范围、权威级别和生效日期。
6. 缺证据回退策略已测试。
7. 工具参数被解析为有类型值，歧义时会确认。
8. 原生评测与一致性评测通过。
9. 安全探针覆盖 Code-switching 和本地滥用方式。
10. 该 Locale 有监控、负责人、Feature Flag 与回滚方案。

回滚行为，不回滚用户数据

应版本化：

• Prompt 与术语模块；
• 检索索引和来源策略；
• 模型路由；
• 工具 Schema；
• 安全 Overlay；
• 评测集。

回滚应恢复上一个已批准行为，同时按适用保留策略保存审计事件和用户数据。

常见失败模式

常见问题

Accept-Language 足够吗？

它适合展示偏好，不适合确定司法辖区、币种、时区或产品权益。它还是一个偏好列表，不是身份或位置证明。

是否应维护一个英文 Master Prompt？

应维护统一任务契约。参考语言实现有助于协作，但每个已发布 Locale 都需要经过评审的 Prompt 模块和行为证据。

能否使用机器翻译？

可以作为草稿或带来源记录和质量控制的运行时组件。高影响指令、政策、术语和评测需要适当人工复核。

RAG 是否总应优先同语言文档？

不一定。来源选择应优先考虑权威性、适用范围、时效和策略。跨语言检索可能增加重要证据，但翻译路径和冲突必须可见。

为什么本地化 Agent 要测状态保持？

Agent 可能完成目标动作，同时破坏无关文件或记录。Locale 解析和工具错误让最终状态与非目标状态保持检查不可或缺。

一手资料

• W3C Internationalization，Choosing a Language Tag：BCP 47 语言标签选择与只使用必要 Subtag 的原则。
• Unicode Consortium，Unicode Locale Data Markup Language, UTS #35：CLDR Locale 标识、匹配、日期、数字、单位等规范。
• Li 等，Multilingual Retrieval Augmented Generation for Culturally-Sensitive Tasks：跨语言检索构成、一致性与偏差证据。
• Ranaldi 等，WorldBench: Culturally Grounded Benchmark for Multilingual Agents：原生语言、文化落地 Agent 任务与最终状态保持评测。
• AI 产品隐私工程：Locale 契约涉及的司法辖区、目的、供应商和数据血缘控制。

关联学习路径

• AI SaaS 定价：市场、币种、权益和 Price Book 本地化。
• Prompt Engineering：结构化任务指令与行为约束。
• RAG：多语言证据背后的检索架构。
• Context Engineering：组合 Locale、策略、证据和工具上下文。

总结

AI 本地化是本地正确行为的工程能力。应用必须拥有显式 Locale 契约，使用标准处理标签和格式，治理多语言证据，约束 Locale-sensitive 工具，并通过共享不变量与原生任务分别评测每个市场。

只有当产品能够解释使用了哪些假设、检索了哪些证据、应用了哪项策略，以及如何验证最终状态时，该 Locale 才真正具备发布条件。