神经机器翻译 vs 大模型翻译:到底改变了什么
谷歌翻译、DeepL、Papago 这类经典神经机器翻译(NMT)系统,是在平行语料上专门训练的编码器-解码器模型。它们逐句翻译,几乎不记得上下文。这种设计让它们快速、便宜、结果确定:同样的输入几乎总是产生同样的输出。但最常见的失败也源于此:先行词在第三句,第十二句的代词性别就错了;产品名在标题里被意译,正文里却被音译;说明书翻到一半,敬语突然变成了随意的口吻。
大语言模型(LLM)的翻译方式不同。它在一个上下文窗口内通读整段文字,因此跨句指代、反复出现的说法、全文术语在数千词的范围内都能保持一致。它还能听从指令:你可以给它术语表、目标语体、字数限制,或"品牌名不要翻译"之类的规则,它通常会遵守。代价是更慢、每字成本更高,而且是非确定性的——同一个提示词可能产出不同措辞,模型也可能悄悄把歧义抹平,而不是指出来。
实用的判断标准是:大批量、低风险、追求速度的文本用专用 NMT;当上下文、语气和术语一致性比延迟更重要时,用 LLM 翻译。这个工具做的,就是生成让 LLM 路线真正奏效的、指令充分的提示词。
语体不是可选项:韩语敬语、日语敬语与欧洲语言的 T-V 之分
英语大多把礼貌藏在措辞选择里,所以英语使用者总是低估翻译中"语体"(而非词汇)所占的分量。韩语几乎在每个句子的动词词尾上都把礼貌语法化了:해체(반말,亲近随意)、해요체(日常敬语)、합쇼체(新闻和商务文书的正式体)都是同一句英文的"正确"译法,选错一个,读起来不是无礼就是僵硬得可笑。日语在此之上又叠加了敬语体系:除了简体和です/ます体,还有尊敬语和谦让语两套独立的动词,抬高谁的动作,动词本身就要换。欧洲语言则有 T-V 之分:法语 tu/vous、德语 du/Sie、西班牙语 tú/usted——在商务德语里,对英语中早就直呼其名的人,默认仍然要用 Sie。
机器翻译只能猜测语体,而短输入往往缺少可供猜测的表面线索。这是最容易修复的翻译失败:把语体明确写出来。告诉模型谁在说话、对谁说、在什么场合——"企业写给成年客户的客服回复,礼貌但不生硬",猜测空间就完全消失了。翻译成你看不懂的语言时,让模型说明它选择了哪种语体,这样母语审校者可以直接核对这个选择,而不必反向推断。
Weak prompt:
"Translate to Korean: We're sorry, but your refund could not be processed."
Strong prompt:
"Translate to Korean. Context: customer-support email from an
e-commerce company to an adult customer. Register: polite 해요체,
warm but professional. Keep the brand name 'PayNow' untranslated.
Text: We're sorry, but your refund could not be processed."
Result (weak): 환불을 처리할 수 없다. <- abrupt, near-반말
Result (strong): 죄송하지만 PayNow에서 환불을
처리하지 못했어요. <- correct register日语和韩语为什么让翻译器崩溃:「は/が」、主语省略与量词
最危险的翻译错误,是那些流畅、合乎语法、但意思错了的输出。日语的「は」和「が」是经典案例。「は」标记话题("说到X"),「が」标记语法主语,换用一个,重点或意思就变了:「私は行きます」是中性的"我会去",而「私が行きます」意为"去的人是我"——是对"谁去?"的回答。翻译器把两者都压平成 "I will go",对比就丢了;反过来翻译时,它还得凭空造出英语从未表达过的区分。
日语和韩语都是可以省略主语的语言:只要语境能补上,主语和宾语就会消失。韩语的「어제 봤어요」字面上就是"昨天 看了",谁看了什么必须从前文恢复。逐句处理的 NMT 只能猜,而它最爱的猜测是"我",这就是为什么机翻的韩语对话里到处是幽灵般的第一人称主语。拿到全文上下文的 LLM 猜得好得多——但前提是你真的把全文给它,而不是孤零零一行。
还有量词的问题。日语数扁平物用「枚」、数机器用「台」、数小动物用「匹」;中文必须用量词(一本书、三张桌子);韩语的固有词数词和汉字词数词要搭配不同的单位名词。量词用错,母语者一眼就能看出,而你完全看不见。所以要始终连同上下文一起翻译,任何面向客户的文本都请母语者把关。
Context-free input (1 line):
"봤어요?"
NMT output:
"Did you see it?" <- "you"/"it" are pure guesses
Same line with context supplied:
"A: 어제 새로 나온 예고편 봤어요?
B: 아직요. 오늘 밤에 보려고요."
LLM output:
"A: Did you watch the new trailer that came out yesterday?
B: Not yet. I'm planning to watch it tonight."
Rule: never translate dialogue line-by-line.
Paste the whole exchange and translate it in one pass.可落地的翻译工作流:上下文、术语表与回译
专业译者不会立刻动笔,他们先搭建上下文。你可以分三步借用这套纪律。
第一,把上下文放在最前面。在正文之前,写明领域(法律、医疗、营销、日常聊天)、读者、目的,以及诸如 UI 字符串最大长度之类的限制。两句话的背景说明,往往比任何事后修改都更能提升译文质量。
第二,维护术语表。每个产品名、功能名、职位名都应有且只有一个批准译法,并且每次翻译请求都要把这份清单贴进去。术语漂移——同一个功能在帮助中心里被叫成三个名字——是 AI 翻译文档最常见的缺陷,而贴上术语表能消除其中大半。也要列出"不要翻译"的内容:品牌名、代码标识符、法律术语。
第三,用回译来验证,但要小心。在一个全新的请求里(不要在同一段对话里,那样模型能看到原文照抄)把译文翻回源语言。回译是冒烟测试:它能可靠地发现漏译、否定颠倒和数字错误,但无法证明语感、语体和自然度——生硬的译文往往回译得完美无缺。凡涉及法律、医疗、金融后果的文本,回译只能作为母语人工审校的补充,永远不能取而代之。
Glossary block to prepend to every request:
GLOSSARY (use exactly these translations):
- "Workspace" -> 워크스페이스 (never 작업 공간)
- "billing cycle" -> 결제 주기
- "seat" -> 시트 (a license, not 좌석)
DO NOT TRANSLATE: SDK.ac, OAuth, API key, webhook
CONTEXT: SaaS admin console UI. Max 20 characters
per string. Register: 합쇼체 for buttons, 해요체 for
descriptions. Return a table: source | translation.仍会出错的地方——以及什么时候该找人工
即使提示词写得完美,仍有一些类别错得足够频繁,每次都值得人工检查。习语和文字游戏在模型没识别出来时会被直译:"break a leg"(祝演出成功)在真实字幕里变成过"把腿摔断吧"。人名地名的音译前后不一——不锁定拼写的话,김서연可能在同一份文档里同时写成 Kim Seo-yeon、Seoyeon Kim 和 Kim Seoyeon。日期和数字会悄悄变格式:03/04/2026 在纽约是3月4日,在伦敦是4月3日;中文的"亿"、韩语的"억"在英语里没有干净的对应单位,金融文本里极易差出一个数量级。单位、货币和法律术语(consideration、force majeure、韩国的전세)常常没有真正的对等词,需要的是本地化改写而不是翻译。
请把 AI 翻译当作一份高水平的初稿。对低风险内容——内部备忘、社区帖子、客服话术——通读一遍后发布,质量确实够用。但对合同、医疗说明、安全警告,以及语气本身就是产品的营销文案,未经审校绝不够格。模型不会告诉你它对哪一句没有把握;无论对错,它输出的口吻都同样自信。让一位母语者在不看原文的情况下冷读译文,至今仍是性价比最高的质量检查。