多语言模型

• query 翻译（实时翻译查询）与语料翻译（离线翻译全部文档）两种方案
• 质量、成本、延迟的权衡
• 语料规模与更新频率的适配

query 翻译是实时把用户问题翻译成目标语言再检索，成本低、延迟可控、翻译对象少，但每次查询都要翻译、且翻译质量影响检索质量。语料翻译是离线把整个知识库翻译成统一语言，检索时无需翻译、效果好，但翻译成本与语料规模成正比、更新时需重新翻译、翻译失真会污染语料。取舍原则：语料规模小、更新频率低、内容稳定时，语料翻译更划算（一次性成本摊薄）；语料规模大、更新频繁、实时性要求高时，query 翻译更合适（避免每次更新重译）。实践中常混合：把高频稳定的核心语料预翻译，把长尾/热更内容用 query 翻译。

本质是"翻译成本放在离线还是在线"。语料翻译把成本摊销到静态内容，query 翻译把成本摊到每次请求。规模与更新频率决定哪个更经济。

• 低资源语言（小语种）训练数据稀疏
• 多语言模型在低资源语言上的性能衰减表现
• 衰减的应对

多语言模型虽声称支持多语言，但各语言表现极不均衡：高资源语言（英、中、西、法）训练数据充足，性能好；低资源语言（小语种、方言）训练数据稀疏，性能明显衰减——表现为理解准确率下降、生成质量差、变体少见、幻觉率上升、指代与语义理解弱。衰减原因主要是训练语料比例失衡。应对方法：构建低资源语言的评测集量化衰减；用该语言的微调/适配数据增强；对该语言做 query 翻译到高资源语言再检索；或采用专门的跨语言模型与回译数据增强。

多语言模型的"多语言"是相对的，数据分布决定能力分布。识别低资源语言的衰减并针对性补偿（评测、微调、翻译路由）是工程常态。

• 缺乏本地语料的困境
• 翻译回灌（把高资源语言语料翻译成小语种）
• 数据增强与质量控制

小语种 RAG 常因缺乏本地语料而检索失败。翻译回灌策略：把高资源语言（如英语）的优质语料翻译成小语种，回灌进知识库，扩充本地语料。工程要点：选择高质量源语料（避免翻译放大错误）；用翻译回译（back-translation）校验翻译质量，丢弃质量差的；对翻译内容保留"原文-译文"双语言关联，便于溯源与双路检索；对翻译质量做母语者抽样验收。数据增强还可结合同义改写、模板扩充。核心是"质量优先于数量"，避免低质量翻译污染检索。

翻译回灌本质是"借高资源语言积累来补足低资源语言"。关键是质量控制——翻译错误会污染语料，因此回译校验与抽样审核必不可少。

• 回译校验（back-translation）
• 双语检索对比（原语种直接检索 vs 翻译后检索）
• 翻译错误放大检索失败的机制

query 翻译错误会直接导致检索失败，因为检索对查询词敏感。验证方法：一是回译校验，把翻译后的 query 再翻译回原语种，与原 query 对比，语义偏差大则说明翻译质量差；二是双语检索对比，分别用原语种 query 和翻译后 query 检索，对比命中结果与相关性，若翻译后检索明显变差则丢弃翻译结果、回退到原语种检索。工程上可对翻译结果做"置信度门控"，低置信度时走备选路径（同时检索原语种与翻译语种）。核心是防止单一翻译错误链式放大失败。

query 翻译的验证核心是"交叉验证"。回译衡量语义保真，双语对比衡量实际检索效果，两者结合才能在翻译错误时兜底，避免错误放大。

• 向量归一化（L2 归一化）
• 距离度量（余弦相似度 vs 内积 vs 欧氏距离）
• 统一向量空间下的可比性

中英文混合检索通常用多语言/跨语言 embedding 模型（如 bge-m3、mE5）把中英文映射到同一向量空间。归一化上，要对向量做 L2 归一化再用余弦相似度，这样不同语言、不同长度的文本向量具备可比性，也便于用内积近似余弦。距离度量上，归一化后余弦相似度与内积等价，比欧氏距离更适合高维语义检索的中文英文混合场景。要注意：即使同空间，跨语言对齐质量也有限，需用评测集验证中英文互检的召回；字符级差异（中文分词、英文子词）会影响 embedding，需统一预处理。

混合检索的"可比性"来自归一化与合适的度量。L2 归一化+余弦相似度是跨语言检索的标准做法，能削弱向量范数差异带来的偏差。

• 语言识别（input language detection）
• 用户偏好语言（UI 语言、地域、历史选择）
• 生成语言的路由决策

多语言生成前需要确定"用哪种语言输出"。语言识别用轻量分类器或 LLM 判断用户输入/请求的语言；同时结合用户偏好（UI 语言设置、地域、历史会话语言、用户显式选择）做路由决策。路由规则：通常以"用户偏好语言"为主，用户未设置时回退到输入语言或地域语言。可多路策略：允许用户显式指定语言覆盖；对同名多语言内容按偏好路由；生成时把语言指令写入 system prompt 强制输出语言。关键是要避免"用户用中文问，模型却答英文"的错位。

语言路由是"用户体验"的硬约束。语言识别+偏好优先级组合，能保证输出语言符合用户预期，减少跨语言错位。

• 双语双路检索（原语种+翻译语种各检索一路）
• 结果的去重（同一文档的两个语言版本）
• 引用来源对齐（双语版本映射到同一原始地址）

双语双路检索会同时从原语种语料和翻译语料检索，可能返回同一文档的两个语言版本，造成冗余。去重策略：以文档的唯一 ID（而非语言版本）为去重键，同一文档的多个语言版本只保留一个（按用户偏好语言优先）；或对结果做语义去重，相似度过高的合并。引用来源对齐则要把每个语言版本映射到"唯一原始来源"（如原文的文档 ID、页码、段落），保证引用指向同一源头，避免出现"同一内容两个来源"的混乱。设计上维护一个"文档唯一 ID↔多语言版本"的映射表。

双语双路的关键是"去重与对齐"——既要避免重复结果，又要保证两个语言版本指向同一个可靠来源。映射表是核心数据结构。

• i18n 框架（文案资源、语言包）
• 语气本地化（正式/口语化、文化表达）
• 单位/日期/货币/时区本地化

出海本地化工程化核心是"把本地化集中到可管理的资源层"。用 i18n 框架管理文案 key-value 语言包，做到"代码与文案解耦"；语气本地化通过文案模板与 tone 指南（不同地区的人际距离、礼貌程度不同）配置；单位本地化（国际单位制、英制、度量衡）、日期/时间格式、货币、时区、数字分隔符要按 locale 正确处理。AI 生成内容也需走本地化：生成 prompt 中注入 locale 与语气指南，输出单位/日期按 locale 格式化。重点是"locale 无状态贯穿"——从请求到生成到展示全程携带 locale。

i18n 的本质是"把文化差异显式建模为配置"。文案、语气、单位、格式都按 locale 管理，AI 生成与静态文案共用一套 locale 决策，避免碎片化。

• 文化敏感性的区域差异
• 区域化护栏（rules）的配置
• 检测与拦截机制

同一内容在不同文化语境下敏感性不同（宗教、习俗、禁忌、历史叙事）。区域化护栏做法：按区域配置"敏感规则集"，把特定宗教/习俗/禁忌的约束写进 system prompt 或护栏规则；对生成内容做敏感性检测（关键词、LLM 判断、文化审查器），命中高风险内容时拦截、改写或降级；对特定区域可做更严格的审查。工程上把护栏做成"区域→规则"的路由表，随请求的地域、语言、用户画像生效。还要注意护栏本身不能过度，避免压制正常的文化表达。

文化敏感性的核心是"区域差异"而非一刀切。护栏要按区域参数化，并在一侧拦截、另一侧放行，避免全球统一管制造成误伤。

• 合规口径的区域差异
• 按区域参数化 Prompt
• 合规路由与版本管理

同一问题在不同地区可能有不同合规口径（如医疗建议、金融表述、数据合规）。配置方法是把"区域合规口径"作为 Prompt 的可变层：prompt 拆成"通用结构 + 区域合规片段"，按请求地域加载对应地区的合规约束片段拼进 prompt。工程上做合规口径的版本管理（每个区域一份合规规则，可独立更新），并用区域路由决定加载哪份。关键是要保证"口径统一、可审计"——同一地区内所有请求口径一致，变更可追溯。对高合规地区可加二次校验（LLM 合规检查）。

合规口径差异的本质是"同一任务、不同约束"。把合规做成地域路由的 Prompt 片段，可复用又与地区解耦，兼顾统一与差异。

• 母语者评测的必要性
• 招募渠道与筛选
• 评测流程与质量控制

本地化质量（语气、文化、地道性）机器难以完全判定，需要母语者验收。招募：通过本地化众包平台、译员社区、本地渠道招募目标语言母语者；筛选时做语言能力测试（判断是否母语者、是否理解产品语境）。评测流程：给母语者设计场景化评测任务（对话、翻译、内容生成），用结构化评分表（准确度、语气自然度、文化合适度、格式正确性）打分，并收集自由文本反馈。质量控制：评测者间一致性（多人评分取均值、看一致性）、质检员复核、按样本量统计置信区间。注意评测样本要覆盖不同场景与难易度。

母语者评测是本地化质量的门槛。关键是"招募、筛选、结构化评分、一致性控制"全流程，避免主观随意导致质量不稳定。

• EU AI Act 的风险分级与合规要求
• 中国生成式 AI 管理办法的备案与内容治理要求
• 多区域部署的差异化合规

EU AI Act 按风险分级（不可接受风险、高风险、有限风险、最小风险），高风险 AI 需满足透明度、数据治理、人类监督、风险评估、日志等要求；生成式 AI 需标注 AI 生成内容、遵守版权。中国《生成式人工智能服务管理暂行办法》要求算法备案、大模型备案、内容安全治理（训练数据、生成内容审核）、用户权益保护。多区域部署的差异化要求：欧盟侧重透明、可解释、风险分级与数据保护；中国侧重备案、内容审核、属地化。工程上要按区域配置合规能力（内容审核、透明标注、日志留存、备案材料），并做区域化合规矩阵。

多区域合规不是"统一遵守"，而是"按区域要求差异化实现"。要建立区域-合规能力映射，把备案、审核、透明、日志等能力按区域启停。

• C2PA 内容来源标识与数字水印
• 不同辖区的互认差异
• 标准落地与互操作

C2PA（内容来源与真实性联盟）与内容水印用于标识 AI 生成内容的来源与真实性。跨境互认问题在于：不同司法辖区对内容标识的强制程度、技术标准、信任体系（谁可以签发证书、谁验证）不一致，导致一方签发的标识在另一方不被信任或无法验证。工程上要采用开放标准（C2PA 协议、可互操作的签名体系），建立多方信任锚（由可被各方认可的证书机构签发），并做好"标识可验证、可生存"（水印抗压缩、抗篡改）。同时不同地区对"哪些内容必须标识、标识到什么程度"的法规要求不同，需按区域配置。

跨境互认的核心是"技术标准统一 + 信任体系互通"。开放标准与可信签发方是解决互认的前提，法规差异则需按区域落地。

• 就近接入（边缘 PoP、区域网关）
• 延迟优化（TTFT、缓存、推理加速）
• 区域路由与容灾

多区域推理的延迟优化核心是"就近接入"：用户请求路由到最近的区域推理节点（DNS/边缘网关/Anycast 就近），减少网络跨区往返。同时优化推理本身延迟：TTFT（首 token 时间）用 prompt caching、预填充优化；P95 用推理加速（量化、投机采样、批处理）；对静态内容用 CDN 缓存。还要做区域容灾与故障转移（某区域不可用时切换到邻近区域）。区域间数据一致性、模型版本一致性也需治理，避免不同区域返回不同版本结果。

就近接入解决"网络延迟"，推理优化解决"计算延迟"，两者结合才能压低端到端 P95。区域路由还需兼顾容灾与版本一致性。

• Prompt 的版本化与区域化
• 单一代码库+环境化配置
• 版本与区域的对应关系

用单一代码库管理多区域 Prompt 的关键是"Prompt 作为配置，按区域+版本双维度管理"。把 Prompt 定义成结构化配置（模板+变量+区域覆盖），存进代码库或配置中心，每个区域可以有自己的 Prompt 版本；发布时按 region 选择对应版本。做法：维护"区域→Prompt 版本"的映射表，代码库中用版本化目录组织（如 prompts/{region}/{version}/），配合 CI 校验与灰度发布。这样既能全局演进（共用模板），又能区域差异化（区域覆盖），且变更可审计、可回滚。

单一代码库管理多区域 Prompt 的本质是"版本化 + 区域化 + 声明式"。把 Prompt 当配置管理，兼具复用、差异、审计与回滚能力。

• 各平台审核政策差异（内容、隐私、AIGC 标识）
• 审核合规准备
• 差异化应对

海外社媒与应用商店对 AI 应用审核政策各不相同：有的要求 AI 生成内容需标识、有的对数据收集/隐私披露要求严格、有的对 AI 生成 IP/版权有特殊要求、有的对特定功能（如未成年保护、深度伪造）有专门限制。应对策略：建立"平台-政策"合规清单，逐平台梳理审核要求；在产品侧做能力开关（内容标识、隐私选项、年龄限制）以适配不同平台；审核资料准备（隐私政策、数据清单、AI 生成说明）；对高风险功能在特定平台做功能裁剪或灰度。同时关注政策更新，及时调整。

平台审核差异的本质是"一个产品、多套合规门槛"。要有平台化开关与合规清单，按平台差异化配置，而非一刀切。

• 跨语言对齐（cross-lingual alignment）的概念
• bge-m3 等模型的对齐能力
• 评估与提升

跨语言对齐指跨语言 embedding 能把不同语言的语义相近文本映射到相近向量。bge-m3 支持多语言且含多语言训练，宣称有较好的跨语言对齐，但真实对齐质量仍依赖语言组合与领域。评估方法：用跨语言检索评测集（query 用 A 语言、文档用 B 语言，测 recall@K），或平行语料（中英对的相似度是否高于非对）验证对齐。提升手段：若对齐差，可做双语/多语言微调（用平行语料继续训练）、用 query 翻译到统一语言再检索、或多语言+翻译双路检索。关键是要用评测集量化对齐，而非只信模型宣传。

bge-m3 等模型的对齐是"统计上较好、具体语言上需验证"。跨语言检索评测是衡量对齐质量的唯一可靠方式，决定了能否直接跨语言检索。

• RTL（右到左）语言适配
• 多语言文本的布局差异
• AI 生成内容与 UI 的协调

多语言 UI 布局适配重点在 RTL 语言（阿拉伯语、希伯来语等）：文本从右到左、方向性（direction）、镜像布局（图标、进度条、对齐方向翻转）。工程上用 CSS dir="rtl" + 逻辑属性（margin-inline-start 等）取代物理属性，实现自动镜像。AI 生成内容也要适配：生成文本的换行、截断、对齐要考虑 RTL 与不同字符宽度；长文本（中文无空格换行、英文有空格）的断行策略不同。多语言还要处理字体（某些语言需特殊字体）、字符集、数字格式。核心是"direction 语境贯穿渲染与生成"。

RTL 适配是"方向性"而非"翻译"问题。用逻辑属性与 dir 统一处理，让布局随 locale 自动镜像，AI 内容也遵循相同方向规则。

• 实验隔离的原则
• 区域间相互污染来源（共享缓存、共享流量、共享评测集）
• 隔离与归因设计

多区域 A/B 实验相互污染主要来自：共享语义缓存（某区域实验变体污染另一区域）、共享评测集/发布链路（灰度流量跨区域）、评审样本被多区域复用、以及用户跨区域导致版本不一致。避免污染的做法：实验按区域独立命名空间与流量分桶（实验标签随请求区域隔离）；缓存设计加上实验版本键（不同实验组用不同缓存键，避免跨组命中）；评测集按区域隔离并标注来源；发布灰度按区域独立控制，避免跨区域串流。关键是"实验标识与归因键要包含区域维度"。

污染的本质是"隔离边界不清"。实验标识、缓存键、评测集、发布都带上区域维度，才能保证归因干净、结论可信。

• 数据驻留（data residency）要求
• 区域化数据存储与处理
• 出境合规与边界

数据驻留要求特定区域的数据存储与处理在该区域内完成，不得出境。架构方案：按区域部署数据与存储（区域数据库、区域对象存储、区域向量库），请求按区域路由到本地存储处理；跨区域数据流动受控（需要合规评估或脱敏后才可出境）；用户数据与区域锚定（用户归属明确到区域）。对 AI 应用，模型推理可在区域内或区域外（需评估），但数据（用户内容、检索库）要驻留。还要做数据分类（哪些必须驻留、哪些可出境）、出境审计与加密。核心是"区域边界 = 数据边界"。

数据驻留的本质是"用区域边界约束数据流动"。区域化存储 + 区域路由 + 出境管控是标准架构，需与合规审计结合。

• 海外支付与国内支付的差异
• 账目隔离与税务合规
• 资金与对账的边界

海外支付（Stripe、Creem 等）与国内业务涉及不同支付体系、税务与合规要求，需要隔离。做法：海外与国内使用独立的支付渠道与单据（各自商户、各自结算、各自对账）；账目按区域/币种隔离记账，避免混账；税务合规分离（海外 VAT/GST、国内发票/税务）分别处理；跨境资金兑换与汇兑单独核算；对账系统按区域独立跑批，汇总时做合并报表。关键是要"资金流、账目流、税务流三隔离"，避免跨区域合规穿透。

支付合规隔离的本质是"分区域管理资金与账目"。独立渠道、独立对账、独立税务处理，才能满足各自区域的合规要求。