做了三个月 16 语种字幕翻译后，我发现生产级 LLM 翻译远不只是 Prompt

过去三个月，我一直在优化视频字幕的 LLM 翻译，主要涉及中文到英语、日语、韩语、西班牙语等多个语种。

真正进入生产场景之前，我曾经认为，LLM 翻译的核心问题无非是选择一个合适的模型，再写出足够完善的 Prompt。

但实际做下去之后，我发现字幕翻译远不只是把一句中文转换成另一种语言。

系统不仅要保证语义准确、表达自然，还要处理字幕行对应、术语一致性、阅读速度、标点规范和平台风格。单次调用可以生成一份“看起来不错”的译文，但要长期稳定地产出可交付内容，依靠的不是一个万能 Prompt，而是初译、程序校验、定向修正、人工反馈和数据回流共同组成的质量体系。我最终发现，字幕翻译最难的不是让模型翻对一次，而是让系统能够发现它什么时候翻错了，并只修复真正有问题的部分。

本文中的案例均经过简化和匿名化，只用于说明错误类型和处理思路。以下结论主要来自视频字幕翻译场景，不一定适用于文学、法律等其他翻译任务。

一、字幕翻译是一个有优先级的多目标任务

普通文本翻译通常关注语义、流畅性和语言风格。

字幕翻译在此基础上，还增加了行级结构、阅读速度和播放时长等限制。一句话即使意思大致正确，也可能因为下面这些问题而无法直接交付：

• 译文太长，观众来不及阅读；
• 原文和译文行数不一致；
• 相邻字幕内容发生错位；
• 同一角色在不同位置出现多个译名；
• 译文中残留没有处理的源语言；
• 输出中混入解释、序号或其他无关内容；
• 为了压缩长度，删除了关键剧情信息。

这些目标之间还会发生冲突。

例如，为了降低 CPS（Characters Per Second，每秒字符数）而过度压缩，可能导致语义缺失；机械地保持中文断行，又可能破坏目标语言的自然语序。

因此，字幕翻译首先需要确定质量目标之间的优先级。

在目前的实践中，我更倾向于采用下面的顺序：

语义准确与完整性 ＞ 字幕行对应与术语一致性 ＞ CPS 与可读性 ＞ 风格和表达润色

最重要的原则是：

不要为了修复低优先级问题，制造更高优先级的问题。

CPS 超限需要处理，但不能以改变否定关系、人物关系、金额或关键剧情为代价。

二、初译决定质量上限，但不应该承担所有职责

初译是整个链路中最核心的语义生成环节。

如果初译已经误解了人物关系、否定语气或者事件之间的关系，后面的格式规则通常无法将其救回来。

例如，原文表达的是一种猜测：

她不会知道我把钱拿给另一个人买房去了吧？

初译却可能变成：

她永远不会知道我拿钱买了房子。

两句话表面上表达了相似的事件，但实际上已经发生了多处偏移：

• 猜测语气变成了确定判断；
• “给另一个人买房”变成了笼统的“买房”；
• 说话人的担心被弱化；
• 人物之间的动作关系发生变化。

这类错误不能通过删除标点或压缩字符数解决，只能重新理解原文，再对问题行进行定向翻译。

但是，“初译重要”并不意味着要把所有要求都塞进一个 Prompt，让模型一次性完成全部任务。

更合理的职责划分是：

初译优先处理

• 语义准确和内容完整；
• 人物关系、指代和上下文；
• 否定、金额、时间等关键信息；
• 目标语言的自然表达；
• 角色名和核心术语。

程序优先处理

• 字幕 ID 是否缺失；
• 是否出现空行；
• 输出结构是否正确；
• 是否超过长度或 CPS 阈值；
• 是否存在重复标点；
• 是否混入明显错误的文字或符号。

可以把两者的关系概括为：

初译负责质量上限，校验器负责稳定下限。

Prompt 应该尽力生成正确结果，但不应承担所有能够被程序准确判断的问题。

三、Prompt 的核心不是堆禁止项，而是组织任务优先级

在优化过程中，一个很自然的做法是不断增加负向提示词：

• 不要漏译；
• 不要错译；
• 不要改变行数；
• 不要遗留原文；
• 不要过度扩写；
• 不要输出解释；
• 不要超过长度限制。

这些要求并不是没有价值，但如果只是不断增加“不要做什么”，Prompt 很容易越来越长，模型却仍然不知道：当多个要求发生冲突时，到底应该优先满足哪个。

例如，“尽量简洁”和“不得遗漏信息”可能发生冲突；“严格保持字幕行”和“使用自然语序”也可能发生冲突。

因此，一个相对清晰的字幕翻译 Prompt，至少需要包含下面几个部分：

[任务定义]
将源语言字幕翻译为目标语言，用于视频字幕展示。

[任务优先级]
1. 保证语义准确和内容完整；
2. 保证字幕行对应和术语一致；
3. 在不损失语义的前提下控制长度；
4. 最后优化自然度和平台风格。

[硬约束]
- 每条输入必须有对应输出；
- 不得缺行、合并或输出额外解释；
- 不得修改已经确认的术语；
- 严格遵守规定的输出格式。

[软约束]
- 使用目标语言的自然语序；
- 尽量简洁、口语化；
- 避免不必要的重复；
- 在语义完整的前提下控制字幕长度。

[上下文与术语]
提供必要的剧情、角色关系和术语信息。

[输出协议]
使用稳定、便于程序解析的结构返回结果。

Prompt 最重要的作用不是穷举所有错误，而是告诉模型：

哪些任务必须完成，哪些只是优化目标，以及发生冲突时应该如何取舍。

模型参数同样需要通过具体模型和测试集验证。字幕翻译通常更重视稳定性，因此可以从相对保守的生成配置开始测试，但不存在适用于所有模型和所有语种的固定最佳参数。

四、只靠 Prompt 无法稳定保证行级结构

即使 Prompt 已经明确要求“每行一一对应”，模型仍然可能出现：

• 把两三行合并成一行；
• 漏掉某个字幕行；
• 将某行内容放到相邻字幕中；
• 输出了正确数量的行，但内容整体发生错位；
• 为了使用目标语言自然语序，擅自重组字幕结构。

这类问题说明，生成约束不等于确定性保证。

字幕行完整性更适合通过结构化协议和程序校验完成，例如：

输入：
101 | 第一行字幕
102 | 第二行字幕
103 | 第三行字幕

输出：
101 | 第一行译文
102 | 第二行译文
103 | 第三行译文

程序可以检查：

• 每个输入 ID 是否都有输出；
• 是否出现额外 ID；
• 是否存在空内容；
• 输出能否被正常解析。

但 ID 完整也不代表语义一定正确。

模型可能给出了全部 ID，却将第二行的内容翻到了第三行。因此，结构校验只能证明“形式完整”，不能证明“语义归属正确”。

这类问题通常需要进一步结合：

• 重复内容检测；
• 相邻行语义对齐；
• LLM 定向诊断；
• 高风险内容的人工复核。

相比让模型每次都“全面反思整段翻译”，我更推荐具体地告诉它检查什么：

• 哪一行可能漏译；
• 哪个术语没有出现；
• 哪一行可能与前后字幕错位；
• 哪一行超过了长度限制；
• 哪一行仍然包含不应该保留的源语言。

流程可以简化为：

初译
  → 程序检查
  → 定位问题行和问题类型
  → 只修正存在问题的字幕
  → 再次校验

核心原则是：

先检查，再路由；哪里有问题，就只修哪里。

这样既能减少不必要的模型调用，也能降低“修复一处、改坏另一处”的概率。

五、CPS 和术语需要单独处理

1. CPS 压缩不是简单删词

假设原文是一句很短的质问：

你们谁拿的？

某些语言的直译可能比较长。为了适应字幕阅读速度，可以将其压缩成目标语言中更口语、更直接的表达。

但压缩之前必须先判断：

• 被删除的信息是否已经能从画面或上下文中得到；
• 是否删除了否定词、数字或人物关系；
• 是否改变了说话人的语气；
• 是否让原本明确的指向变得模糊。

比较合理的 CPS 修正过程是：

1. 判断超长是否由直译、重复或不必要扩写造成；
2. 删除目标语言中可以自然省略的内容；
3. 保留关键动作、否定、数字和人物关系；
4. 压缩后重新检查语义和术语。

CPS 应该作为一个明确的检测信号，而不是驱动模型盲目删词的唯一目标。

2. 术语不能只靠提醒

角色名、地名和专有名词是字幕翻译中非常常见的问题。

同一个角色可能在不同位置出现：

• 音译和意译混用；
• 全名和简称不一致；
• 不同模型阶段使用了不同译名；
• 初译正确，但后续压缩又把术语改坏。

只在 Prompt 中写“请保持术语一致”，往往不够稳定。

更有效的做法包括：

• 在翻译前识别并替换已经确认的术语；
• 将术语作为不可随意修改的锚点；
• 初译、校验和修正阶段使用同一份术语信息；
• 对最终结果再次做术语命中检查。

这相当于把：

希望模型记住术语

转变为：

系统主动保护已经确认的术语。

六、多语种应该共享框架，而不是共享所有规则

多语种系统可以共享统一的处理框架：

• 相同的字幕 ID 协议；
• 相同的错误分类方式；
• 相同的重试和失败处理机制；
• 相同的指标和回归流程。

但具体语言规则不能完全共用。

英语

常见问题包括表达膨胀、中文语序残留、跨行句法不自然，以及人名、货币和称谓表达不统一。

日语

需要特别关注人物性别、敬语、第一人称和句末语气。中日共享大量汉字，因此不能简单地把“出现汉字”等同于“残留中文”，否则会造成大量误报。

韩语

需要关注敬语等级、语序调整和句尾表达。目标语言为了自然表达而调整成分顺序，并不一定意味着字幕错位。

西班牙语

需要关注性别、单复数、呼语标点和疑问句格式。同一句中文在缺少人物信息时，可能无法正确决定形容词或代词的性别形式。

因此，更合理的设计是：

统一系统框架，按语种配置规则。

需要按语言分别处理的内容通常包括：

• 长度和 CPS 标准；
• 标点与空格规范；
• 源语言残留检测；
• 人物性别和敬语；
• 专有名词形式；
• 断行习惯；
• 检查规则的白名单和例外情况。

通用检测器在一个语种中有效，放到另一个语种中可能产生大量误报。多语种质量控制最忌讳的，就是用一套粗暴规则处理全部语言。

七、没有数据闭环，优化就无法被证明

修改 Prompt、增加校验规则或者增加一次模型修正，都不能自动说明系统变好了。

某几个案例改善，可能只是局部现象；某类错误减少，也可能同时引入另一类错误。

要判断一次改动是否有效，至少需要记录：

• 初译结果；
• 自动检查发现的问题；
• 修正前后的结果；
• 最终人工版本；
• 使用的模型和 Prompt 版本；
• 术语和规则版本；
• 各阶段耗时和调用成本；
• 人工修改类型和修改量。

在指标上，可以同时关注：

• 严重错译和漏译率；
• 字幕行异常率；
• 术语一致性；
• CPS 超限率；
• 自动修正触发率；
• 人工修改字数；
• 人工修改时间；
• 一次通过率或轻改通过率；
• 单位内容的处理成本和时延。

但人工修改字数不能单独代表翻译质量。

修改一个标点和纠正一个关键否定词，修改字符数可能都很少，业务风险却完全不同。因此，还需要建立错误分类和严重程度：

• 高风险：剧情翻反、身份或人物关系错误；
• 中风险：漏译、术语错误、金额和时间错误；
• 体验问题：表达不自然、CPS 超限；
• 低风险：标点、空格和格式问题。

不过，字符修改率仍然可以作为衡量人工返工量的一个客观指标。下面是以中文为源语言的阶段性统计；数值表示机器译文到最终人工版本之间的字符修改率，越低意味着需要人工改动的字符越少：

从这组数据看，引入翻译 Agent 后，五个语种的字符修改率都明显下降；在已有后续实验数据的阿拉伯语、日语和土耳其语中，继续精细化提示词又进一步降低了修改率。印地语和葡萄牙语在这一阶段暂无“继续精细化提示词”的统计，因此不做跨阶段推断。

需要强调的是，这个指标适合衡量返工量，不足以单独判断翻译质量。它还需要与严重错译、漏译、术语错误等分类指标结合，避免少量但高风险的修改被低字符修改率掩盖。

完整的优化流程应该是：

收集线上问题
  → 判断错误类型和严重程度
  → 加入回归测试集
  → 修改 Prompt、规则或术语
  → 离线回归
  → 检查是否引入其他退化
  → 小范围验证
  → 再决定是否推广

没有回归测试的优化，很容易变成“修好了当前案例，却不知道其他地方是否变差”。

八、总结：生产级字幕翻译不是一个 Prompt

经过这段时间的实践，我逐渐形成了几个判断：

初译决定质量上限，但不应该承担全部职责。

Prompt 的核心是组织任务优先级，而不是无限追加禁止项。

生成约束无法替代程序校验，字幕 ID 完整也不代表语义一定正确。

泛化反思不一定有效，针对具体问题的定向诊断通常更稳定。

多语种应该共享系统框架，但不能共用全部语言规则。

没有数据回流和回归评测，任何优化都可能只是局部感觉变好。

一个相对完整的字幕翻译质量体系，可以概括为：

初译保证基础语义质量
  → 程序发现确定性问题
  → LLM 定向处理复杂问题
  → 人工兜底高风险内容
  → 修订数据进入评测和迭代闭环

生产环境最终需要优化的，也不只是某一个抽象的翻译分数。

真正影响业务价值的是：

• 严重错误是否减少；
• 人工修改时间是否下降；
• 一次通过率是否提高；
• 单位内容成本是否降低；
• 系统能否稳定处理更多语言和更多内容。

从这个角度看，LLM 字幕翻译真正困难的部分，并不是完成一次翻译，而是把一次概率性的模型输出，逐渐变成一个可检查、可修正、可评估、可持续优化的生产系统。