每条基于 RAG 的本地化流水线，都有同一个盲区

只要本地化流水线用检索增强生成把术语表条目注入模型上下文，它就存在一个从未被真正衡量过的检索召回率问题。

这种模式几乎随处可见：给输入文本做嵌入，用余弦相似度搜索术语库，再把 top-k 结果注入提示词。输出语法完全正确，术语却错了。除非有人同时懂两种语言，还熟悉术语表，否则这种错误根本看不出来。

我们最开始也是这么做的。后来，我们拿生产环境里的术语表去测检索召回率，结果发现：在真实负载上，系统漏掉了绝大多数本该命中的术语。

为什么句子级嵌入会漏掉术语表条目？#

一个术语表条目通常只有 1–3 个词。比如 “Localization engine”、“Access token”、“Deployment pipeline”。

而输入文本往往是一个 JSON 对象，其中的值短则两个词（按钮标签），长则两百个词（产品描述）。当完整字符串 “Configure the localization engine for production deployment” 被拿去做嵌入时，生成的向量捕捉的是整句话的语义——大致和配置、生产系统有关。与术语表相关的短语 “localization engine”，就在句子级表示里被抹平了。

这个句向量与术语表条目 “localization engine” 的余弦相似度，通常会落在 0.6–0.7 区间，低于检索阈值。术语明明就在输入里，检索系统却没找到。

问题的本质是粒度不匹配：用句子级表示去查询短语级目标。嵌入模型确实忠实表达了整句话的含义，但其中的术语组成部分，并不会在向量空间里拥有独立区域。

我们是踩过坑才意识到这一点的。在生产负载里——嵌套 JSON 对象、20–50 个键、不同长度的值混在一起——句子级检索漏掉了绝大多数适用的术语表条目。本地化请求顺利完成，输出读起来也很流畅。但 “localization engine” 却变成了 “translation tool”——语法没问题，语义也接近，术语却错了。而流水线依然报告成功。

N-gram 拆分如何修复术语表检索？#

最终有效的修复方式，是在嵌入前先把输入拆成短语级单元。每个字符串值都会变成一组相互重叠的 n-gram 窗口：

Input: "Configure the localization engine for production"

1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
          engine for, for production]
3-grams: [configure the localization, the localization engine,
          localization engine for, engine for production]

每个 n-gram 都会成为一次独立检索查询。“Localization engine” 会以独立短语的形式查询术语表，并以较高相似度找到对应匹配。

这条拆分流水线包括：

1. 递归提取嵌套 JSON 结构中的所有字符串值
2. 按句子切分，去除 HTML 和标记注释
3. 规范空白字符，移除外层引号，反转义格式内容
4. 从每个句子中生成相互重叠的 1-gram、2-gram 和 3-gram 短语

一段 50 词的文本大约会产生 150 个 n-gram。一个包含 20 个键的典型 API 负载，通常会得到 1,000–3,000 个可检索短语。每个短语都独立生成嵌入，每个嵌入都会针对术语表的向量索引执行一次最近邻查询。

我们在暴露原始问题的同一批生产负载上测量了前后差异。现在，术语表条目不再受周围句子上下文影响——哪怕是埋在 200 词产品描述里的 2 词术语，也能获得和独立标签相同的召回率。

面对不同规模的术语表，自适应检索如何工作？#

对于大型术语表，N-gram 拆分加批量嵌入是正确做法；但对于小型术语表，这套方式后来被证明在算力上过于浪费。

一个配置了 8 个术语表条目的本地化引擎，用直接注入会更快——一次数据库查询、结果确定、亚毫秒级完成。一个拥有 2,000 个条目的本地化引擎，则必须使用向量搜索——上下文窗口限制和相关性稀释，让全量注入根本不可行。

系统按请求运行三种检索模式，并根据该语言对的术语表基数进行选择：

区分预加载和搜索的基数阈值，来自对生产流量延迟特征的分析，并会随着嵌入模型性能、术语表规模分布和基础设施特征的变化持续调整。我们最初上线的阈值大约只维持了三周，遥测数据就显示应该调整。此后它已经被改过多次——我们发现，随着引擎不断积累术语表条目，以及供应商更新带来嵌入模型特性的变化，最优阈值会持续漂移。

检索延迟随术语表复杂度变化，而不是随负载大小变化。一个只有 10 个条目的本地化引擎，无论输入有多长，都能在个位数毫秒内完成。一个拥有 500 个条目的本地化引擎则会启用完整拆分流水线，但仍能控制在持久化后台工作流步骤的延迟预算之内。

术语表检索的相似度阈值如何校准？#

每个 n-gram 嵌入都会查询向量索引，寻找高于相似度阈值的最近邻。低于阈值的匹配会被当作噪声丢弃。

这个阈值会同时决定检索精确率和召回率：

• 过于宽松： 不相关术语会混入提示词。模型看到了并不适用于当前输入的术语表上下文，有时还会照着用——最终输出带上了无关领域的术语。
• 过于严格： 合法的变体表达和词形变化会被排除在外。比如 “Deploying” 无法匹配术语表条目 “deploy”，召回率就会下降。

我们发现，合适的阈值会因语言对而异。英语→德语的检索相似度分布，与英语→日语并不相同，因为源 n-gram 与术语表条目之间的形态距离在结构上就不同。用单一的全局阈值，会让不同语言对的召回率表现不一致。

现在，这个阈值会根据独立评分流水线给出的各语言对质量评分持续校准。当评分系统检测到术语表不遵循情况上升（输入里有、输出里却没有的术语变多）时，就说明检索召回率下降了，阈值会适当放宽。当评分发现模型套用了无关术语时，就说明误报注入增加了，阈值会收紧。

这项校准每周运行一次，而且必须如此——嵌入模型的行为会随着供应商更新而变化，团队新增术语会改变术语表分布，产品演进也会持续改变输入文本特征。

检索到的术语表条目如何注入本地化模型？#

检索到的术语表条目会被分成两类约束，并在模型系统提示词中以不同方式执行：

不可翻译项——必须在目标输出中原样保留的源语言字符串，例如品牌名、技术标识符、产品名。模型会逐字保留这些内容。

自定义翻译——覆盖模型自身判断的源语→目标语映射。比如，“Localization engine” 必须译为 “moteur de localisation”。模型会把这类要求视为不可协商的词汇约束。

这两类内容都会作为规则注入系统提示词，并被明确赋予高于模型默认行为的优先级。提示词层级会确保术语表合规性压过模型自身的语言偏好。

这种区分在评分时非常关键：独立评分模型会分别检查，不可翻译项是否被原样保留，自定义翻译是否被准确应用。两类约束，对应两套验证标准。我们很早就发现，如果把它们混成一个统一的“术语表”类别，评分就会失真——某个术语本该翻译却被原样保留（反之亦然），在统一检查下仍可能被判为正确。

面对自己不懂的语言，如何验证本地化质量？#

整条检索与本地化流水线，完全可能在没有任何报错的情况下运行完毕，却产出术语错误的结果。漏掉一个术语表条目，不会触发任何错误信号；错误套用一条自定义翻译，接口照样返回 200。流水线成功了，输出却错了。

这就是大多数团队始终没能补上的本地化可观测性缺口。

因此，检索必须与独立的异步评分联动。本地化请求完成后，独立的评分模型会根据本地化引擎配置，对输出进行评估：

• 术语表遵循性——不可翻译项是否被原样保留？自定义翻译是否被准确应用？
• 指令遵循性——是否遵守了特定语言对的规则？
• 自定义评分标准——由本地化团队为每个引擎定义的质量维度

评分模型运行在与本地化模型分离的基础设施上。它们以异步方式在后台工作流中执行，并会在每一次经过本地化引擎且启用了评分功能的请求完成后触发。一个模型负责本地化，另一个模型负责评分。跨模型评估消除了自评偏差。

评分结果会反向用于检索校准：

1. 评分发现某个语言区域对的术语表遵循率持续走低
2. 排查后发现检索召回率下降——阈值相对于当前术语表分布发生了漂移
3. 调整阈值后，召回率恢复，遵循度评分趋于稳定

这个闭环，正是系统具备自我修正能力的关键。评分补上了检索本身缺失的可观测性。没有它，团队就等于在把本地化内容发布到自己并不掌握的语言里，却没有任何信号能说明他们建立的术语表是否真的被执行了。

为什么检索召回率会随时间产生复利效应？#

每一次正确应用术语表术语的本地化请求，都会强化整个产品的术语一致性。每一次漏掉术语的请求，都会引入漂移——一个界面写着“localization engine”，另一个写着“localization tool”，第三个又写着“localization module”。在 30 个语言区域和每周发布的节奏下，这些不一致会不断累积。

高检索召回率与低检索召回率之间的差别，不在于单次请求的质量高低，而在于它是否构成一种会持续累积的一致性机制。高召回率意味着术语表能在每个界面、每个语言区域、每次发布中稳定统一地生效。低召回率则意味着术语表只是偶尔起作用——从结构上看，这几乎等同于没有术语表，只是退化得更慢。

这对本地化工程意味着什么#

这里描述的检索问题，并不只属于某一种具体实现。对于任何试图通过基于嵌入的搜索来实现术语表感知本地化的系统，这都是一个结构性问题。句子级输入表示与短语级术语表目标之间的粒度错配，无论使用哪种嵌入模型、哪种向量数据库，或由哪种 LLM 生成输出，都会存在。

构建本地化自动化的团队面临一个选择：要么接受带着隐性召回缺口的句子级检索，要么搭建能够补上这一缺口的分解与校准基础设施。第二条路需要三套系统——n-gram 分解、自适应检索，以及能将结果反馈到阈值管理中的评分闭环。每套系统都有各自的运行节奏：输入格式变化时，分解逻辑需要演进；术语表增长时，检索阈值会随之偏移；而随着本地化团队逐步明确哪些维度对自身内容更重要，评分标准也会不断细化。

要把检索增强本地化做到生产级质量，这不是一次性交付，而是一项持续的工程实践——系统需要被构建、埋点、观测，并持续调优。围绕这项工作的本地化工程学科之所以正在形成，正是因为背后的运营现实非常清楚：本地化基础设施需要像后端服务、CI/CD 流水线和可观测性体系一样，获得持续投入与维护。

下一步#

FAQ#

什么是检索增强本地化（RAL）？ 检索增强本地化会在推理阶段为每个本地化请求注入术语表术语、品牌语调规则和语言区域专属指令——本质上就是将 RAG 背后的“检索-注入”模式应用到本地化中。在一项覆盖五家 LLM 提供商和五种欧洲语言的对照研究中，与未做上下文增强的同款模型相比，RAL 将术语错误降低了 17–45%。

为什么句子级嵌入会漏掉术语表术语？ 术语表术语通常只有 1–3 个词。当它们作为完整句子的一部分被嵌入时，会被稀释进句子级语义向量中。嵌入捕捉的是整句话的整体语义——“Configure the localization engine for production”中的“localization engine”并不会作为独立单元被识别出来。结果就是，句子向量与术语表条目之间的余弦相似度会低于检索阈值。

n-gram 分解如何提升检索召回率？ 系统不会直接对完整输入字符串做嵌入，而是先将文本拆解为相互重叠的 1-gram、2-gram 和 3-gram 短语，再分别进行嵌入。每个短语都会成为一个独立的检索查询。这样一来，一个埋在 200 词段落中的 2 词术语表术语，也能获得与独立标签相同的召回率——因为它是脱离周围上下文、被单独查询的。

系统使用多少种检索模式？ 三种。跳过（术语表条目为零——无需检索）、预加载（低于基数阈值——直接加载全部条目）和向量搜索（高于阈值——执行完整的 n-gram 分解与嵌入）。系统会根据特定语言区域对的术语表基数，为每个请求选择对应模式。

相似度阈值如何维护？ 阈值会基于独立评分流水线产出的、按语言区域对划分的质量分数，每周进行校准。当术语表未遵循的趋势上升时，就会放宽阈值以提升召回率；当不相关术语渗入提示词时，则会收紧阈值。由于形态差异程度不同，不同语言区域对需要不同的阈值。

跨模型评分如何用于本地化质量评估？ 每次本地化请求完成后，一个运行在独立基础设施上的单独模型会评估：术语表术语是否被正确应用、语言区域专属指令是否得到遵循，以及自定义质量标准是否达标。一个模型负责本地化，另一个模型负责评分。这既消除了自评偏差，也补上了检索本身缺失的可观测性。

当术语表检索召回率较低时会发生什么？ 低检索召回率意味着术语表触发不稳定——一个界面用了正确术语，另一个却没有。在 30+ 个语言区域和每周发布的节奏下，这些不一致会持续累积，最终演变成术语漂移。术语表虽然存在，却没有真正形成约束。拉长到数月来看，这在结构上几乎等同于没有术语表。

什么是本地化可观测性缺口？ 本地化流水线完全可能在不报错的情况下运行完毕，却产出术语不正确的结果。漏掉术语表术语不会产生任何错误信号——API 返回 200，译文本身在语法上也成立。所谓可观测性缺口，就是“流水线执行成功”与“术语使用正确”之间的那段空白。独立评分通过衡量每一次请求的术语表遵循度，来补上这一缺口。