# General Translation Knowledge Base: AI 翻译的准确度足以用于生产环境应用吗？
URL: https://generaltranslation.com/zh/kb/is-ai-translation-accurate.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 对于使用广泛的语言，通常可以，但前提是它要先通过针对你自己的语言、UI 字符串和高风险内容的评估。在 WMT25 中，Gemini 2.5 Pro 在 16 个语言对中有 10 个达到或超过了人工参考译文的水平，但文档级基准测试无法说明简短的界面字符串是否已经可以上线。
Category: 翻译
Last updated: 2026-10-20
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-20

在文档翻译上表现出色的引擎，照样可能把按钮标签翻错。单独一个“Save”，既可能是“保存文件”，也可能是“节省开支”。比较各个引擎时，请使用你的产品实际需要的字符串、上下文和语言。

## 如今 AI 翻译的准确度如何？

WMT (机器翻译会议) 每年举办 General Machine Translation 共享任务，由专业人工标注员对各翻译系统进行比较评测。在 [WMT25 研究结果](https://aclanthology.org/2025.wmt-1.22/) (Kocmi et al., 2025) 中，组织方用刻意挑选的高难度文档测试了 60 个系统，其中包括 20 个大语言模型和三个在线翻译服务；随后由专业标注员在 16 个语言对上，对自动排名靠前的系统 (目标为每个语言对 18 个) 进行评分。对应用开发团队而言，有四项结果值得关注：

* **在该基准的部分测试中，顶尖系统已达到甚至超过人工参考译文。** Gemini 2.5 Pro 在 16 个语言对中有 14 个进入第一梯队，其中 10 个与人工翻译持平或更优。而在提供了人工参考译文的 15 个语言对中，人工参考译文仅有 6 个进入第一梯队。作者也指出，标注过程中可能存在风格偏好，而且这些参考译文并未像某些专业交付物那样经过完整的润色。
* **术语和语法仍会出错。** 该任务的测试集发现，在部分语言对中，顶尖系统在领域专有术语、非标准输入以及性别选择和语法一致方面仍有困难。
* **低资源语言则是另一番情形。** 译入马赛语的结果&quot;基本无法使用&quot;，系统常常输出斯瓦希里语；要求译成埃及阿拉伯语时，系统往往输出的是现代标准阿拉伯语。
* **自动评分会产生误导。** 在自动指标中排名第一的系统，在人工标注员的评估中排名明显靠后。作者据此得出结论：质量的最终评判仍应以人工评估为准。

需要注意两点局限。WMT 将商业服务匿名为 ONLINE-B、ONLINE-G 和 ONLINE-W，因此无法据此判断&quot;DeepL 与 Google Translate 孰优孰劣&quot;。此外，它测试的是完整文档 (新闻、社交媒体帖子、语音转录稿、文学和教育类文本) ，能为模型提供的上下文远比一个仅有两个词的 UI 字符串丰富。

## MT 引擎、大语言模型与人工译者相比如何？

三者都能产出准确的译文，区别在于它们能利用哪些上下文，以及把哪些工作留给你。

| 方式                                            | 擅长之处                     | 可利用的上下文                                                     | 留给你的工作                            |
| --------------------------------------------- | ------------------------ | ----------------------------------------------------------- | --------------------------------- |
| 神经机器翻译引擎 (Google Translate、DeepL)             | 快速、一致、低成本地翻译句子和文档        | 词汇表；DeepL 还提供上下文字段、正式程度设置和自定义指令；Google 的 Advanced 版本还支持示例句对 | 短字符串的上下文、占位符、复数形式、审校和投递           |
| 直接调用大语言模型 (OpenAI API、Claude API、Gemini API)  | 输出流畅，能遵循有关语气、术语和格式的指令    | 你在提示词中提供的任何内容                                               | 为每个字符串准备上下文、在多次运行间保持术语一致、校验输出以及投递 |
| General Translation                           | 在发布过程中生成应用和文件的译文         | 标记的 JSX 结构或文件上下文、共享的词汇表和自定义提示词                              | 在其编辑器中审校措辞，并测试翻译后的产品              |
| 专业人工译者                                        | 能把握习语、文化、品牌调性以及法律或受监管类文本 | 产品本身、风格指南，以及随时向你提问                                          | 交付周期和按字计费的成本，且每次发布都会增加            |

具体到 DeepL 与 Google Translate 的对比：WMT 没有点名评测二者，因此建议比较各自 API 支持的功能。DeepL 的 [translate API](https://developers.deepl.com/api-reference/translate) 提供 `context` 参数，可影响翻译结果，但其内容本身不会被翻译，也不计费；此外还提供 `formality` 设置 (限受支持的语言) 、词汇表，以及最多 10 条自定义指令。Google 的 [Cloud Translation](https://docs.cloud.google.com/translate/docs/overview) Advanced 版本除神经模型外，还提供 Translation LLM、词汇表和自适应翻译——后者可从少量示例句对中学习。做出选择之前，请先挑一些你自己的字符串，在你的目标语言上分别用两者试译一下。

## AI 翻译错误从何而来

上下文缺失、模型局限和集成失误，都可能导致生产环境中出现错误。请留意以下几类常见问题：

* **含义模糊的短字符串。** &quot;Save&quot; 在德语中既可以是 *speichern* (写入磁盘) ，也可以是 *sparen* (节省开支) 。如果只给模型这一个词，它只能靠猜。
* **术语漂移。** 同一个产品名称或功能术语，在应用中是一种译法，在文档中却是另一种，或者每次发布的译法都不一样。
* **正式程度与语体。** 德语的 *du* 与 *Sie*、法语的 *tu* 与 *vous*、日语的敬语等级。如果没有明确规则，模型会逐条字符串各自选择，导致同一界面中两种语体混用。
* **占位符与标记。** 重命名或丢失 `{{name}}`、`{count}` 或 `<1>terms</1>`，可能导致运行时插值失败。不过，为适应目标语言，调整完整占位符的顺序有时是必要的。
* **复数形式。** 英语有两个复数类别，而波兰语有四个，阿拉伯语有六个 ([CLDR 复数规则](https://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html)) 。如果只翻译英语的 `one` 和 `other` 字符串，其余类别就会缺失。 (参见[如何在 React 中处理复数形式？](/kb/how-to-handle-plurals-in-react)) 。
* **长度限制。** 即使译文含义正确，也可能超出固定宽度的按钮或标签页。请在实际使用的字体和布局中测量文本；仅靠字符数限制并不能确保放得下。
* **低资源语言与方言。** WMT25 的结果表明，一旦超出使用广泛的语言范围，翻译质量就会急剧下降，方言也可能被同化为标准变体。

## 团队如何让 AI 翻译达到生产级水准

真正把 AI 翻译投入使用的团队，都会在模型之外做好五件事：

1. **为每个字符串附带上下文**：说明它出现在哪里、起什么作用，并为任何有歧义的内容添加备注。
2. **用词汇表固定术语**，包括任何情况下都不应翻译的名称。
3. **统一制定风格规则**：按语言规定正式程度、目标受众和惯例。
4. **由合格的审校人员审校高风险用户交互界面**：定价、结账、法律文本、安全提示以及任何受监管的内容。对于风险较低的字符串，应根据各语言的实测结果制定审校策略，而不是把自动化检查当作翻译质量评估。
5. **在发布前运行自动化 QA 检查**，排查机械性错误：消息族和占位符是否匹配、必需的复数类别是否齐全，以及是否超出布局限制。[JSON 翻译指南](/kb/translate-json-files)列出了适用于 i18next 和 ICU 文件的这些检查。这些检查不评估含义或流畅度。

开始评估时，请使用真实的标签、完整句子、错误消息、插值、复数形式和领域术语。将源文本、上下文、模型版本、输出和审校人员的发现集中保存。比较输出时不要让审校人员知道结果出自哪个系统，并按语言和严重程度报告错误。当模型或翻译指引发生变化时，用相同的用例重新检查。这样才能为你的发布策略提供依据，而这是单凭 WMT 结果无法提供的。

对于一次性文本、内部内容或你会亲自检查的原型，可以直接使用机器翻译引擎或 LLM。对于法律、医疗和受监管的文本，以及最讲究细微差别的品牌文案，请交给专业译员。如果这些译文需要随产品发布持续保持最新，请选择 General Translation：它将源上下文、共享术语、生成和审校串联起来，无需你围绕每次模型调用自行搭建这条流水线。WMT25 并未评估 General Translation，因此其排名不能作为 GT 翻译质量的证据。

## General Translation 如何补充上下文并保持一致性

在 React 应用中，General Translation 的 [`<T>`](/docs/react/reference/components/t) 组件用于将一段 JSX 标记为待翻译内容。CLI 会提取其中的文本和元素结构，由 GT 的服务生成译文，再由 SDK 负责渲染。如有含义模糊之处，可以通过 [`context`](/docs/react/reference/components/t#context) 属性添加备注加以说明：

```tsx title="SaveButton.tsx"
import { T } from 'gt-react';

export function SaveButton() {
  return (
    <T context="Editor toolbar. Save means write the document to disk.">
      <button>Save</button>
    </T>
  );
}
```

该备注会告诉模型，这里的 &quot;Save&quot; 应译为 *speichern* (保存) ，而不是价格切换开关 (&quot;Save 20%&quot;) 中所用的 *sparen* (节省) 。对于使用 CLI 翻译的 JSON 和 YAML 文件，可以通过配套的[键级元数据](/docs/cli/reference/keyed-metadata)文件为每个键提供同样的说明，还可以选择用 `maxChars` 限制长度。

一致性则由仪表板中的上下文组保障：词汇表可在所有语言中固定产品名称等术语，自定义提示词可设定规则 (例如德语中使用正式的 &quot;Sie&quot;) ，并在分配到的所有项目间共享。 (参见[为翻译定义上下文](/docs/platform/dashboard/guides/defining-context-for-translations)。) 之后，审校人员可以在仪表板的 **译文** 页面中检查和编辑任意译文，并排对比不同区域设置。 (参见[审校和编辑译文](/docs/platform/dashboard/guides/reviewing-translations)。) 如需了解这与逐个字符串调用 Google Translate 有何不同，请参阅 [General Translation 与 Google Translate 对比](/kb/general-translation-vs-google-translate)。

## 要点总结

* 在 WMT25 中，Gemini 2.5 Pro 在 16 个语言对中有 10 个达到或超过了人工参考译文的水平，但译入马赛语等低资源语言时，质量基本无法使用。
* 请在每种目标语言中测试短字符串、术语、正式程度、占位符、复数类别和布局；文档级基准测试覆盖不到你的界面。
* 上下文、词汇表和风格规则能够提升输入质量。自动化检查负责验证结构；合格的审校人员则负责评估语义，并判断是否可以发布。
* WMT 对商业引擎做了匿名处理，因此请用你自己的字符串来比较 DeepL 和 Google Translate，并对比两者 API 支持的输入：DeepL 提供上下文字段和正式程度设置，Google 则支持基于示例句对的自适应翻译。

## Related questions

- [Google Translate 替代方案：General Translation 与 Google Translate 对比](https://generaltranslation.com/zh/kb/general-translation-vs-google-translate.mdx): Google Translate 适合快速翻译一次性文本，但要以另一种语言发布产品，还需要结合上下文翻译每个字符串、保持术语一致、正确处理变量和复数形式、进行审校，并建立发布流程。General Translation 能理解代码中每个字符串的上下文，将从代码、审校到每一次发布的整个本地化工作流全面自动化。
- [如何翻译 i18n JSON 文件？](https://generaltranslation.com/zh/kb/translate-json-files.mdx): 只翻译 JSON 区域设置文件中的字符串值。非复数键、{{name}} 之类的占位符以及标签都应保持不变，但复数键会因语言而异：例如波兰语需要 inbox_few 和 inbox_many。请使用能识别文件格式的工具或 API，然后先解析并验证输出，再进行审校。
- [什么是翻译管理系统（TMS）？](https://generaltranslation.com/zh/kb/what-is-a-translation-management-system.mdx): 翻译管理系统（TMS）是一种用于存储源内容及其译文、并运行翻译工作流的软件，涵盖翻译记忆库、词汇表、审校、机器翻译和集成等功能。其翻译记忆库通过精确匹配或模糊匹配复用以往的译文。常见的 TMS 有 Crowdin、Lokalise、Phrase、Smartling 和 Transifex。
- [General Translation 与 TMS（Crowdin、Lokalise、Phrase）对比](https://generaltranslation.com/zh/kb/general-translation-vs-tms.mdx): 如果开发者希望译文生成、源自代码的上下文以及审校流程都与产品发布紧密衔接，请选择 General Translation。你可以保留现有的消息目录和渲染库，也可以直接编写内联 JSX，无需翻译键。TMS 适合以语言供应商、CAT 编辑器和 XLIFF 交换为核心的翻译项目，其集成可以自动完成文件传输。
- [如何在 React 中处理复数形式？](https://generaltranslation.com/zh/kb/how-to-handle-plurals-in-react.mdx): 在 React 中处理复数形式时，应为每种语言的每个复数形式各准备一个句子，并按该语言的复数规则选出对应句子——英语有 2 种形式，俄语有 4 种，阿拉伯语有 6 种。gt-react 和 gt-next 提供的 General Translation `<Plural>` 组件只需接收你的源语言形式，General Translation 便会生成每种目标语言所需的形式。

## Previous and next questions

- Previous question: [应该自建 i18n，还是使用 General Translation？](https://generaltranslation.com/zh/kb/general-translation-vs-in-house-i18n.mdx)
- Next question: [什么是 hreflang？如何设置？](https://generaltranslation.com/zh/kb/what-is-hreflang.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.
