大语言模型翻译质量评估：2025年能力与局限
两年前，翻译质量评估还是纯人工活。现在GPT-4、Claude、Gemini这些大模型已经能识别翻译错误、解释问题原因、按MQM标准给出结构化评估了。2025年，LLM做翻译QA不是实验室里的玩具，而是很多团队的日常工具。
这篇文章讲LLM在翻译QA中的实际能力、踩过的坑，以及怎么在本地化工作流中用好它们。
LLM评估翻译质量的方式
传统MTQE模型只吐一个分数，LLM不一样。它通过自然语言理解来分析翻译，能给出详细的、人能看懂的评估。
LLM做翻译QA有几个天然优势：
| 能力 | 描述 |
|---|---|
| 自然语言输出 | 用人话解释错误 |
| 零样本学习 | 不需要特定领域训练就能干活 |
| 上下文理解 | 能考虑文档级的上下文 |
| 多语言 | 支持100+语言对 |
| 灵活指令 | 通过提示词适配不同质量标准 |
基本评估流程
┌─────────────────────────────────────────────────────────────┐
│ 输入 │
│ ┌───────────────┐ ┌───────────────┐ ┌─────────────────┐ │
│ │ 原文 │ │ 译文 │ │ 指令 │ │
│ │ (英语) │ │ (德语) │ │ (MQM标准) │ │
│ └───────┬───────┘ └───────┬───────┘ └────────┬────────┘ │
│ │ │ │ │
│ └──────────────────┼────────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ LLM │ │
│ │ (GPT-4/Claude) │ │
│ └────────┬────────┘ │
│ │ │
│ 输出 ▼ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • 带类别的错误注释 ││
│ │ • 严重程度级别（严重/重大/轻微） ││
│ │ • 每个问题的解释 ││
│ │ • 总体质量分数 ││
│ │ • 改进建议 ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
LLM现在能做什么（2025年实测）
擅长的部分
从实际跑过的benchmark和生产环境来看，LLM在这几个方面表现不错。
错误检测方面：误译和含义变化能抓到85-90%，遗漏和添加也是85-90%，语法拼写错误最准，95%以上，有术语表的情况下术语不一致能到90%+，风格语域问题稍弱，80-85%。
错误分类方面，LLM可以按MQM分类法给错误归类：
示例输出：
原文: "The server will restart automatically."
译文: "服务器将手动重启。"
LLM分析:
{
"errors": [
{
"type": "Accuracy/Mistranslation",
"source_span": "automatically",
"target_span": "手动",
"severity": "Major",
"explanation": "译文说'手动'，但原文说'自动'——含义被颠倒。"
}
],
"score": 95,
"overall_assessment": "一个改变操作含义的重大准确性错误。"
}
上下文评估是LLM的一大亮点。它能看到单个片段之外的东西——文档级一致性、全文术语使用、语气连贯性、前后文的呼应关系。这一点传统工具做不到。
还有一个好处：LLM会解释它的判断。不像黑盒模型只给个分数，LLM能说出"译文用了非正式的'你'，但商业语境应该用'您'，这是风格/语域的轻微错误，不影响含义但影响品牌一致性"。这种解释对译员来说特别有价值。
各模型跑分（2025年）
| 模型 | 错误检测 | 严重程度准确性 | MQM对齐 | 速度 |
|---|---|---|---|---|
| GPT-4 Turbo | 87% | 82% | 高 | 2-4秒 |
| Claude 3.5 Sonnet | 86% | 84% | 高 | 2-3秒 |
| Gemini 1.5 Pro | 84% | 80% | 中 | 2-4秒 |
| GPT-4o | 85% | 81% | 高 | 1-2秒 |
| Claude 3 Haiku | 78% | 75% | 中 | 0.5-1秒 |
基于EN-DE、EN-FR、EN-ZH语言对的MQM注释测试集
坑在哪里
说完优点说问题。LLM做翻译QA有几个坑是绕不过去的。
幻觉
LLM有时候会凭空标记一个不存在的错误，或者漏掉真正的问题。
误报示例：
原文: "The quick brown fox"
译文: "敏捷的棕色狐狸"
LLM（错误地）: "轻微流畅性问题——考虑使用'迅速的'代替'敏捷的'"
实际情况: 两种译法都完全没问题。
怎么办：设置置信度阈值，关键内容必须人工复核。
严重程度判断不稳定
同一个错误跑两次，可能一次说"重大"一次说"轻微"。这个问题我们在生产环境里确实遇到过。
应对办法：temperature设成0，用结构化输出，做校准提示。
专业领域知识不够
通用LLM对医学术语的细微差别、特定司法管辖区的法律用语、行业黑话、文化梗这些东西理解有限。你不能指望一个通用模型懂所有行业。
解决方案：在提示词里给够领域上下文、术语表和参考材料。
语言对之间差异大
| 语言对 | 相对性能 |
|---|---|
| EN ↔ DE/FR/ES | 高（基准语言） |
| EN ↔ ZH/JA/KO | 中高 |
| EN ↔ AR/HE | 中 |
| 低资源语言对 | 较低 |
低资源语言对的表现明显弱一截。按语言对校准阈值，性能不够的语言对加人工审核。
一致性没保障
同一段内容在文档开头和结尾可能得到不同评价。LLM不是精密仪器，它会"走神"。用批处理保持一致的上下文，设置确定性参数，能缓解但不能完全消除这个问题。
怎么实施
提示词工程
提示词写得好不好直接决定结果质量。基本结构：
您是专业的翻译质量评估员。根据MQM（多维质量指标）
标准分析以下翻译。
源语言: {source_lang}
目标语言: {target_lang}
领域: {domain}
原文:
"{source_text}"
译文:
"{translation}"
附加上下文:
- 术语表术语: {glossary}
- 风格要求: {style_guide}
评估翻译并提供:
1. 错误列表，包含:
- 错误类型（准确性、流畅性、术语、风格、区域、设计）
- 具体子类型
- 严重程度（严重、重大、轻微）
- 原文片段和目标片段
- 解释
2. 总体MQM分数（100 - 加权扣分）
3. 简要质量摘要
以JSON格式回复。
想要更稳定的结果，可以加校准示例：
您是LQA评估专家。在评估之前，请查看这些校准示例，
它们展示了本项目的正确严重程度分配：
示例1 — 重大错误：
原文: "Do not exceed 10mg daily"
译文: "每天服用10毫克"
问题: 遗漏了"Do not exceed"——缺少安全关键信息
严重程度: 重大（在医疗/制药上下文中将是严重）
示例2 — 轻微错误：
原文: "Click the button"
译文: "点击按键"
问题: "按键"可按术语表改为"按钮"
严重程度: 轻微（含义保留，术语偏好）
现在评估：
[...]
结构化输出
用JSON模式或函数调用来保证输出格式一致：
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4-turbo",
messages=[...],
response_format={
"type": "json_schema",
"json_schema": {
"name": "translation_evaluation",
"schema": {
"type": "object",
"properties": {
"errors": {
"type": "array",
"items": {
"type": "object",
"properties": {
"error_type": {"type": "string"},
"subtype": {"type": "string"},
"severity": {"enum": ["Critical", "Major", "Minor"]},
"source_span": {"type": "string"},
"target_span": {"type": "string"},
"explanation": {"type": "string"}
},
"required": ["error_type", "severity", "explanation"]
}
},
"score": {"type": "number", "minimum": 0, "maximum": 100},
"summary": {"type": "string"}
},
"required": ["errors", "score", "summary"]
}
}
},
temperature=0
)
批处理架构
生产环境里不可能一个片段一个片段调API。需要批处理：
┌─────────────────────────────────────────────────────────────────┐
│ 翻译批次 │
│ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │片段1 │ │片段2 │ │片段3 │ │片段4 │ │片段5 │ ... │
│ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ │
│ │ │ │ │ │ │
│ └─────────┴─────────┼─────────┴─────────┘ │
│ │ │
│ ┌───────────▼───────────┐ │
│ │ 批处理器 │ │
│ │ - 按上下文分组 │ │
│ │ - 包含术语表 │ │
│ │ - 添加风格指南 │ │
│ └───────────┬───────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │LLM 1 │ │LLM 2 │ │LLM 3 │ 并行 │
│ └──┬───┘ └──┬───┘ └──┬───┘ │
│ │ │ │ │
│ └───────────────────┼───────────────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ 结果聚合器 │ │
│ │ - 合并结果 │ │
│ │ - 计算分数 │ │
│ │ - 生成报告 │ │
│ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
省钱的办法
LLM做QA比MTQE贵。怎么控制成本？
分层处理是最有效的：MTQE分数超高的片段直接放行，中等的用便宜模型过一遍，只有低分片段才用最好的模型。
def evaluate_segment(segment, mtqe_score):
if mtqe_score >= 0.95:
return {"status": "auto_approve", "score": 98}
elif mtqe_score >= 0.75:
return evaluate_with_llm(segment, model="gpt-4o-mini")
else:
return evaluate_with_llm(segment, model="gpt-4-turbo")
把相关片段打包发送也能省不少。100个片段不是100个API调用，打成10个批次，每批10个。
batch_prompt = f"""
评估来自同一文档的这10个片段：
片段1：
原文: "{seg1_source}"
译文: "{seg1_target}"
片段2：
...
"""
还有就是缓存。同样的源文-译文对没必要重复评估。
import hashlib
def get_cached_evaluation(source, target):
cache_key = hashlib.md5(f"{source}||{target}".encode()).hexdigest()
if cache_key in evaluation_cache:
return evaluation_cache[cache_key]
return None
各家LLM怎么选
OpenAI GPT-4系列
| 模型 | 最适合 | 定价（2024年12月） |
|---|---|---|
| GPT-4 Turbo | 最高准确性 | $10/1M输入, $30/1M输出 |
| GPT-4o | 速度/质量平衡 | $2.50/1M输入, $10/1M输出 |
| GPT-4o-mini | 大批量、低风险 | $0.15/1M输入, $0.60/1M输出 |
整体准确性最好，JSON输出稳定，语言覆盖广。量大的时候成本和速率限制要注意。
Anthropic Claude
| 模型 | 最适合 | 定价 |
|---|---|---|
| Claude 3.5 Sonnet | 生产QA | $3/1M输入, $15/1M输出 |
| Claude 3 Haiku | 快速筛选 | $0.25/1M输入, $1.25/1M输出 |
推理能力强，解释写得细致，复杂指令的遵循度高。部分地区可用性稍低。
Google Gemini
| 模型 | 最适合 | 定价 |
|---|---|---|
| Gemini 1.5 Pro | 长文档 | $1.25/1M输入, $5/1M输出 |
| Gemini 1.5 Flash | 快速处理 | $0.075/1M输入, $0.30/1M输出 |
上下文窗口大（1M+ token），价格有竞争力。JSON输出的稳定性差一些，可能需要更多提示词调优。
混合工作流才是正解
说实话，2025年纯靠LLM或纯靠人工都不是最优解。最有效的做法是把两者拼起来。
┌─────────────────────────────────────────────────────────────┐
│ 翻译输入 │
└─────────────────────────────┬───────────────────────────────┘
│
┌───────────────▼───────────────┐
│ LLM评估 │
│ (所有片段，并行) │
└───────────────┬───────────────┘
│
┌─────────────────────┼─────────────────────┐
│ │ │
无错误 轻微错误 重大/严重
│ │ │
▼ ▼ ▼
┌─────────┐ ┌───────────┐ ┌───────────────┐
│ 接受 │ │抽样10% │ │ 100%人工 │
│ │ │ 人工QC │ │ 审核 │
└─────────┘ └───────────┘ └───────────────┘
│ │
▼ ▼
┌─────────────────────────────────┐
│ LLM准确性跟踪 │
│ (比较LLM与人工) │
│ - 更新置信度分数 │
│ - 调整阈值 │
│ - 改进提示 │
└─────────────────────────────────┘
LLM先过一遍所有片段。没问题的直接放行，轻微问题的抽10%给人工看看，重大和严重错误100%送人工审核。然后持续比较LLM和人工的判断，调整置信度和阈值。
def update_confidence(llm_result, human_result):
agreement = compare_evaluations(llm_result, human_result)
update_stats(
language_pair=llm_result.lang_pair,
error_type=llm_result.error_type,
severity=llm_result.severity,
human_agreed=agreement
)
if get_recent_accuracy() < 0.85:
increase_human_review_rate()
这个循环跑起来之后，LLM的准确率会越来越高，人工审核比例会越来越低。
FAQ
LLM能否替代人工进行翻译质量评估？
LLM可以有效处理70-80%的常规QA任务，但无法完全替代人工评估员。它们擅长检测客观错误（拼写、语法、明显误译），但在细微判断（文化适当性、创意内容、上下文相关含义）方面存在困难。最佳方法是混合的：LLM用于初步评估和标记，人工用于验证和边缘情况。
哪个LLM最适合翻译质量评估？
截至2025年，GPT-4 Turbo和Claude 3.5 Sonnet为翻译QA提供最佳准确性。对于大批量、低风险内容，GPT-4o-mini或Claude Haiku提供良好的成本性能平衡。最佳选择取决于您的具体语言对、领域和预算。我们建议在您的实际内容上对2-3个模型进行基准测试后再做决定。
基于LLM的翻译QA成本是多少？
成本因批量和模型而异。对于GPT-4o在典型翻译QA提示大小下：
- 1,000个片段: ~$0.50-1.00
- 10,000个片段: ~$5-10
- 100,000个片段: ~$50-100
使用分层方法（MTQE过滤 + 简单情况使用更便宜的模型）可以在保持质量的同时降低50-70%的成本。
如何验证我的内容的LLM QA准确性？
创建一个包含200-500个带有人工MQM注释的片段的测试集。运行LLM评估并比较：
- 错误检测率（LLM是否发现相同的错误？）
- 严重程度对齐（LLM是否分配相似的严重程度？）
- 误报率（LLM多久标记一次非错误？）
生产使用的目标是85%+的一致性。模型更新时每季度重新验证。
LLM能否处理医疗或法律翻译等专业领域？
可以，但需要额外设置。对于专业领域：
- 在提示中提供特定领域的术语表
- 在校准中包含您领域的错误示例
- 使用领域上下文（"这是药品说明书"）
- 为高风险内容增加人工审核比例
- 考虑对非常专业的术语使用微调或RAG方法
往哪走
LLM做翻译QA这件事，2025年已经过了"能不能用"的阶段，进入了"怎么用好"的阶段。它提供了规模（用一致标准评估海量片段）、可解释性（详细的、可执行的反馈）、灵活性（通过提示词适配不同需求），还有成本效率（减少60-80%的人工QA工作量）。
但说到底，LLM不是万能的。它处理不了需要深度文化判断的东西，它会犯低级错误，它的稳定性还有待提高。我觉得接下来一两年，谁能把LLM + 人工的混合工作流跑得最顺畅，谁在翻译质量管理上就占优势。
准备实施基于LLM的翻译QA？试用KTTC获得具有MQM合规性和混合人机AI工作流程的生产就绪AI LQA。