为什么用大模型做翻译：与传统机器翻译的差异
传统机器翻译（MT）处理的是「句子」：输入一句、翻译一句，优势是快、稳、成本低，弱点是上下文弱、术语不统一、风格生硬。大模型翻译最大的不同在于它理解的是「语境」——给一段完整的段落甚至全文，它能根据前后文消解歧义，还能执行「品牌名不要翻」「语气要活泼」「保留 Markdown 格式」这类指令。对产品文案、营销材料、技术文档这类「既要准又要对味」的内容，大模型翻译的实用性远高于传统 MT。
当然，不是所有场景都要换大模型。量大、要求不高、成本敏感的普通文本，传统 MT 仍然够用；大模型更适合需要术语统一、风格控制、格式保留的中高质量翻译场景。实践中常见做法是「分级」：简单内容走传统 MT，重要内容走大模型，最关键的再人工审校。这篇讨论的是大模型这一级的工程方法：提示词、术语表、长文档处理、质量评估、批量管线。
大模型翻译的价值不在「更准」，而在「可指挥」——你能告诉它术语怎么翻、风格怎么调、格式怎么留。
- 提示词角色、翻译指令、格式约束共同决定译文质量。
- 术语表把品牌术语、专有名词的译法写死，杜绝译名漂移。
- 长文档分段策略与上下文继承决定段落间的一致性。
- 评估人工评审 + 自动指标（BLEU/COMET/回译）组合打分。
翻译提示词设计：角色、指令与格式约束
翻译提示词有四个层次。第一层是角色与受众：告诉模型它是「资深本地化翻译」，面向什么读者（产品用户、开发者、商务客户），这会影响用词和语气。第二层是任务规则：源语言、目标语言、翻译要求（忠实原文 / 意译 / 本地化改写）、专有名词处理方式、禁用的词。第三层是格式约束：保留 Markdown、代码块、链接、变量占位符不翻译；译文长度限制（如不超过原文 120%）。第四层是风格样例：给一两段「目标风格」的参考译文，模型会模仿其句式与措辞。
一个常见的坑是「过度意译」：模型为了让译文读起来顺，把产品名、版本号、法律条款里的关键措辞擅自改掉。所以提示里要明确「数字、产品名、公司名、型号、专有术语必须保留或按术语表翻译，不得意译」。另一个坑是语言混杂：明明要求翻成中文，个别句子却漏翻成英文，或者把代码注释也翻译了。格式约束里要把「哪些内容不翻」写清楚。
# 翻译系统提示模板（节选）
# 1. 角色：资深本地化翻译，精通源语言与目标语言。
# 2. 任务：将用户输入的文本从源语言翻译为目标语言。
# 3. 忠实度：语义必须忠实原文；数字、型号、产品名、品牌名不得改动。
# 4. 术语：必须使用下方术语表；术语表未覆盖的专有名词保留原文。
# 5. 格式：保留 Markdown 标记、代码、链接与占位符，不翻译。
# 6. 风格：面向目标市场普通用户，通顺自然，避免翻译腔。
# 7. 长度：译文长度控制在原文的 120% 以内。术语表与风格控制：让译文符合品牌口径
术语表是翻译工程里投入产出比最高的一环。没有术语表时，同一篇文档里「Dashboard」可能被翻成「仪表盘」「控制面板」「看板」，各翻各的；有了术语表，模型被强制按约定译名输出。术语表的构建分两步：一是盘点，把产品名、功能名、行业术语、品牌 slogan 整理出来，确定官方译名；二是沉淀，把翻译过程中人工纠正过的译名持续加进去。术语表的格式建议用「源文 → 目标译名」的列表，必要时附上上下文或禁止译法。
风格控制靠的是「风格锚点」。给模型目标风格的参考样例、明确的语气描述（正式/口语化/幽默）、以及禁忌清单（不要用网络流行语、不要过度营销腔），比抽象的「翻得好一点」有效得多。要注意，风格控制不要过度：把「请勿」翻成「千万别」这类改动会影响严谨内容的准确性，风格约束应只作用于允许发挥的内容（宣传文案、产品描述），对合同、说明书的约束应更严格。
# 术语表示例（JSON）
# [{"src": "Dashboard", "dst": "控制台", "note": "管理后台统一叫控制台"},
# {"src": "Checkout", "dst": "结算", "note": "禁止译成结账/付款"},
# {"src": "Refund", "dst": "退款", "note": "禁止译成退钱"}]
# 注入方式：把术语表转成文本拼进系统提示，并在用户消息中
# 再次强调“以上术语表为强制约束，冲突时以术语表为准”。长文档翻译：分段、上下文与格式保留
长文档不能整篇塞给模型，要分段翻译。分段策略直接决定一致性：按段落切分，每段作为一个翻译单元；段内再长的句子也别拆，避免单句翻译丢失上下文。分段之后还有两个一致性问题要解决。一是术语一致，靠术语表兜底；二是「前文引用」一致，比如前文定义了「本产品」指代某功能，后文单独翻就容易翻错指代。解决办法是「上下文继承」：翻译第 N 段时，把前一段的原文和译文作为上下文一并提供，或者先让模型通读全文生成一份「全局摘要 + 关键实体清单」，再逐段翻译。
格式保留是长文档翻译的另一个硬要求。Markdown 标题、代码块、表格、链接、图片 alt 文本的位置不能乱；代码块内部不翻译；变量占位符（比如模板里的花括号变量）保持原样。可以在分段时先把文档按结构拆成「文本块 + 非文本块」，只对文本块调用翻译，再把译文拼回原结构。这样既省 Token，又不会破坏文档骨架。
# 长文档翻译管线（伪代码）
# 1. 解析文档为块列表：文本块 / 代码块 / 表格 / 图片
# 2. 只对文本块执行翻译，代码块与占位符原样保留
# 3. 翻译时携带上一段的原文译文作为上下文
# 4. 所有文本块翻译完成后按原结构拼回
# 5. 后处理：检查占位符数量一致、链接完整、标题层级未变质量评估：从人工评审到自动指标
翻译质量怎么评估？人工评审最可靠：让熟悉两种语言的人按维度打分——准确性（语义是否忠实）、流畅性（是否通顺自然）、术语一致性（译名是否统一）、风格贴合度（是否符合目标风格）。但人工评审贵、慢，不可能每条都评，所以要搭配自动指标做「第一道筛子」。
自动指标里，BLEU 看 n-gram 重合度，只能粗筛「有没有翻」，对「翻得好不好」不敏感；COMET 类神经指标用模型给译文打分，和人工评价相关性更好，适合作为日常回归指标；回译（把译文翻回源语言再和原文比）能抓漏译、错译，但会有二次翻译误差。工程上推荐「自动粗筛 + 抽样人工精评」：全量过 COMET 阈值，低于阈值或高风险内容（合同、发布说明）转人工；定期抽一批普通内容人工复评，校准指标阈值。
| 评估方式 | 成本 | 优点 | 局限 |
|---|---|---|---|
| 人工评审 | 高 | 最可靠、可解释 | 慢、贵、难全覆盖 |
| BLEU | 极低 | 快、可批量 | 不敏感于语义与流畅度 |
| COMET 类 | 低 | 与人工相关性较好 | 依赖模型、需校准 |
| 回译 | 中 | 能抓漏译错译 | 二次翻译引入误差 |
工程实现：批量管线、缓存与后处理
批量翻译管线要考虑三个工程问题。第一个是成本与并发：翻译内容通常很大，要控制并发、做重试与退避，按内容优先级排队。第二个是缓存与复用：已翻译过的句子、段落（比如产品界面文案）命中就不必再调模型——这里的缓存可以做「完全匹配」缓存，更高级的做法是上一轮讲的语义缓存思路，对相似句子直接复用译文。第三个是后处理与人工介入位：批量翻译后要有自动后处理（术语表强制替换漏网之鱼、占位符校验、格式检查），以及一个人工审校队列，让审校人只看到「自动翻译 + 机器评分」的待审条目。
还有两个容易被忽视的点。一是「翻译记忆」：把人工改过的译文沉淀下来，下次同样或相似的源文优先用人工确认过的译法，避免重复劳动，这也是术语表之外最重要的质量资产。二是可观测：记录每个任务的源语言、目标语言、模型、Token 消耗、耗时、评分，方便看成本与质量趋势。管线稳定后，定期用回归集（一批固定的难翻句子）跑一遍，任何提示或模型的升级都能立刻看出是好是坏。
# 批量翻译 + 缓存 + 评估（伪代码）
# 1. 读取待翻译条目列表
# 2. 查缓存：完全匹配或语义命中则直接复用译文
# 3. 未命中：调用翻译接口（带术语表、风格约束、重试）
# 4. 后处理：术语强制替换、占位符校验
# 5. 自动评分：低于阈值的进入人工审校队列
# 6. 人工确认的译文写回缓存与翻译记忆适用边界与风险
大模型翻译也有明确的边界。第一是保密：发给云端模型的内容可能被用于训练或留存，涉及商业机密、用户隐私、未发布产品的内容要谨慎，要么走私有化部署，要么先脱敏再翻译。第二是幻觉：模型可能「越翻越离谱」——把不存在的词补进译文、把数字看错、把否定关系翻反，尤其是低资源语种和长难句。自动评估 + 人工抽样能兜住大部分，但风险等级高的内容必须人工终审。第三是成本：Token 消耗比传统 MT 高一个数量级，量大的场景要先算账，必要时分级翻译。
最后是策略：不要指望「模型一次翻对」，要接受「翻译是持续迭代的过程」。先把术语表和风格锚点建好，跑通小批量、人工修正、沉淀回术语表，形成质量飞轮；再逐步扩大自动化范围。这样搭建的翻译工程，才不是一次性 Demo，而是能长期稳定产出、质量可追踪的真实能力。
把翻译工程做好，靠的不是更强的模型，而是更完整的约束：术语表、风格锚点、评估闭环、人工介入位。