翻译结果出来了。德语、法语、日语，全部齐全，格式也都正确。它们看上去没问题——但如果那是你看不懂的语言，“看上去没问题”只是信心，不是验证。而翻译最容易悄悄出错的，偏偏正是你最需要它准确无误的那一点：含义。
backTranslation 阶段无需再加一道人工复核，也能补上这个缺口。它会把每条输出再译回源语言，让 AI 将这次回译与你最初提交的原文进行比对，并标出语义发生偏移的地方。你不再只是相信含义经得起往返翻译——而是看着流水线亲自把这件事核实清楚。
stepId: backTranslation本页介绍的就是这个阶段：每一步具体做什么、语义偏移如何分级，以及哪些情况会自动修正。刚接触流水线？先看 流水线概览，了解各阶段如何围绕核心翻译步骤展开。要启用它，请参阅 配置流水线；要查看一次运行产出了什么，请参阅 观察流水线运行。
本页内容
检查如何工作#
这个阶段会在核心翻译之后运行——如果启用了 rephrase，则也会在它之后运行——因此它验证的始终是当前最优输出，也就是原本会直接交付出去的那版文本。整个过程分三步。
检测偏移
AI agent 会将回译结果与你提交的原始源文进行比对，并按严重程度为任何差异分级：minor、major 或 critical。
按需修正
当分级结果为 major 或 critical 时，系统会再进行一次 AI 处理，调整正向译文以消除语义偏移。minor 级别的差异会记录下来用于可观测性，但保留原样——不会因为措辞上的细微变化就重写输出。
所以，这项检查不只是告诉你含义变了——对于真正重要的情况，它会在译文到达用户之前，先把正向译文修正好。
语义偏移如何分级#
一次往返翻译不可能逐字逐句还原原文。两位译者——或者同一个 AI 在两个方向上翻译——表达同一个意思时，本来就可能用不同说法。这是正常现象，不是缺陷。分级机制的作用，就在于区分无害的改写和真正发生变化的含义：
| 严重程度 | 含义说明 | 该阶段会怎么处理 |
|---|---|---|
minor | 措辞不同，但含义未变——比如同义替换、语序调整或风格上的取舍。 | 记录，但不修正。 |
major | 含义已经偏移到足以产生影响——比如重点变化、限定条件遗漏，或表述的主张被改动。 | 通过一次修正处理调整正向译文。 |
critical | 含义已经错了——比如否定关系颠倒、数字变化，或术语被反转。 | 通过一次修正处理调整正向译文。 |
这层区分正是关键。如果一个检查会“修正”每一句只是换了种说法的句子，它只会打乱本来就没问题的译文，反而掩盖真正的问题；如果一个检查什么都标出来却什么都不修，那你得到的只会是一份更长的报告。分级的意义，就是让这个阶段放过无害的差异，只把修正能力用在含义确实发生偏移的地方。
哪些会自动修正，哪些不会
只有 major 和 critical 级别的语义偏移会触发修正处理。minor 级别的偏移会被展示出来用于可观测性，但输出本身不会改动。如果你希望不分级别、每一处差异都交由人工查看，那就是 human review 的职责——回译是自动化护栏，不是人工审校的替代品。
经典方法，自动执行#
回译并不是 Lingo.dev 发明的。它是人工翻译中经典的质量保障方法：由第二位译者把目标语言文本再译回源语言，再由编辑对两者进行比对，从而找出含义丢失的地方。它能抓住单次正向翻译最容易掩盖的问题——译文读起来很流畅，意思却悄悄偏了。
这条流水线只是把同样的方法交给 LLM 来执行，让它们代替第二位译者和编辑。方法本身早已成熟；被自动化的是人力投入和等待时间。这也正是这个阶段存在的原因——不是为了给流程加一点 AI 色彩，而是把一种公认有效的语义校验直接嵌入你的任务里，对每个 locale、每一次运行都执行。
何时启用#
只要“意思翻错了”的代价很高，而你自己又无法阅读目标语言去发现问题，回译就值得启用。尤其适合这些场景：
- 内容属于 法律、医疗、金融或技术 领域——在这些场景里，否定关系被翻反、限定条件发生偏移，都是真实风险，不只是风格差异。
- 你要发布到 团队里没人看得懂的 locale，这时回译就是你判断含义是否保真的唯一窗口。
- 输出内容 高风险、低体量——比如合同条款、剂量说明、合规通知——这时额外校验的成本，与出错的代价相比几乎可以忽略。
它会多做一次翻译——所以成本更高
它会对每条输出执行一次完整的回译和 AI 比对；此外，只要语义偏移被评为 major 或 critical，还会再加一次修正处理——因此，启用回译的任务会比只做正向翻译消耗更多模型资源。每个已启用阶段都会在任务中记录各自的成本，所以你可以准确看到这项检查额外增加了多少开销。在语义保真值得这笔成本的地方打开它；对于高体量、低风险、正向翻译已经足够的字符串，则可以关闭它。
它和 rephrase 搭配得很自然：rephrase 负责让文案读起来像母语创作，回译则确认这种更自然的改写，依然忠实表达了源文的意思。两者可分别开关——详见 配置流水线。
如何查看结果#
和所有流水线阶段一样，启用后的回译检查会把自己的记录写入任务的 steps 数组中。使用 GET /jobs/localization/:jobId 获取任务后，backTranslation 这一步会告诉你检查是否运行，以及它是如何处理的：
{
"id": "ljb_C3d4E5f6G7h8I9j0",
"status": "completed",
"outputData": { "clause": "Diese Vereinbarung darf nicht ohne schriftliche Zustimmung übertragen werden." },
"steps": [
{
"stepId": "localize",
"type": "action",
"status": "completed",
"errorMessage": null,
"createdAt": "2026-04-17T10:00:00Z",
"startedAt": "2026-04-17T10:00:00Z",
"completedAt": "2026-04-17T10:00:09Z"
},
{
"stepId": "backTranslation",
"type": "action",
"status": "completed",
"errorMessage": null,
"createdAt": "2026-04-17T10:00:09Z",
"startedAt": "2026-04-17T10:00:09Z",
"completedAt": "2026-04-17T10:00:21Z"
}
]
}一个 completed 的 backTranslation 步骤，表示这项检查已经完整跑完；如果它将语义偏移评为 major 或 critical，那么你看到的 outputData 就是修正后的正向译文，而不是检查前的版本。更完整的说明——包括检查标记了哪些严重级别，以及某个阶段的 failed 或 skipped 对整个任务意味着什么——请参阅 观察流水线运行，这是解读 steps 和 warnings 的权威文档。
这就是整个阶段：先回译，再分级比对，最后在含义发生偏移时进行修正——让每条输出的语义保真都在流程中被直接验证，而不是事后默认它没问题。你可以按请求启用它，也可以把它设为引擎默认值，然后通过这一步确认往返之后含义依然成立。
