大语言模型翻译质量评估：2025年能力与局限

两年前，翻译质量评估还是纯人工活。现在GPT-4、Claude、Gemini这些大模型已经能识别翻译错误、解释问题原因、按MQM标准给出结构化评估了。2025年，LLM做翻译QA不是实验室里的玩具，而是很多团队的日常工具。

这篇文章讲LLM在翻译QA中的实际能力、踩过的坑，以及怎么在本地化工作流中用好它们。

LLM评估翻译质量的方式

传统MTQE模型只吐一个分数，LLM不一样。它通过自然语言理解来分析翻译，能给出详细的、人能看懂的评估。

LLM做翻译QA有几个天然优势：

基本评估流程

┌─────────────────────────────────────────────────────────────┐ │ 输入 │ │ ┌───────────────┐ ┌───────────────┐ ┌─────────────────┐ │ │ │ 原文 │ │ 译文 │ │ 指令 │ │ │ │ (英语) │ │ (德语) │ │ (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年）

基于EN-DE、EN-FR、EN-ZH语言对的MQM注释测试集

坑在哪里

说完优点说问题。LLM做翻译QA有几个坑是绕不过去的。

幻觉

LLM有时候会凭空标记一个不存在的错误，或者漏掉真正的问题。

误报示例： 原文: "The quick brown fox" 译文: "敏捷的棕色狐狸" LLM（错误地）: "轻微流畅性问题——考虑使用'迅速的'代替'敏捷的'" 实际情况: 两种译法都完全没问题。 

怎么办：设置置信度阈值，关键内容必须人工复核。

严重程度判断不稳定

同一个错误跑两次，可能一次说"重大"一次说"轻微"。这个问题我们在生产环境里确实遇到过。

应对办法：temperature设成0，用结构化输出，做校准提示。

专业领域知识不够

通用LLM对医学术语的细微差别、特定司法管辖区的法律用语、行业黑话、文化梗这些东西理解有限。你不能指望一个通用模型懂所有行业。

解决方案：在提示词里给够领域上下文、术语表和参考材料。

语言对之间差异大

低资源语言对的表现明显弱一截。按语言对校准阈值，性能不够的语言对加人工审核。

一致性没保障

同一段内容在文档开头和结尾可能得到不同评价。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分数超高的片段直接放行，中等的用便宜模型过一遍，只有低分片段才用最好的模型。

defevaluate_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 defget_cached_evaluation(source, target): cache_key = hashlib.md5(f"{source}||{target}".encode()).hexdigest() if cache_key in evaluation_cache: return evaluation_cache[cache_key] returnNone

各家LLM怎么选

OpenAI GPT-4系列

整体准确性最好，JSON输出稳定，语言覆盖广。量大的时候成本和速率限制要注意。

Anthropic Claude

推理能力强，解释写得细致，复杂指令的遵循度高。部分地区可用性稍低。

Google Gemini

上下文窗口大（1M+ token），价格有竞争力。JSON输出的稳定性差一些，可能需要更多提示词调优。

混合工作流才是正解

说实话，2025年纯靠LLM或纯靠人工都不是最优解。最有效的做法是把两者拼起来。

┌─────────────────────────────────────────────────────────────┐ │ 翻译输入 │ └─────────────────────────────┬───────────────────────────────┘ │ ┌───────────────▼───────────────┐ │ LLM评估 │ │ (所有片段，并行) │ └───────────────┬───────────────┘ │ ┌─────────────────────┼─────────────────────┐ │ │ │ 无错误 轻微错误 重大/严重 │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌───────────┐ ┌───────────────┐ │ 接受 │ │抽样10% │ │ 100%人工 │ │ │ │ 人工QC │ │ 审核 │ └─────────┘ └───────────┘ └───────────────┘ │ │ ▼ ▼ ┌─────────────────────────────────┐ │ LLM准确性跟踪 │ │ (比较LLM与人工) │ │ - 更新置信度分数 │ │ - 调整阈值 │ │ - 改进提示 │ └─────────────────────────────────┘ 

LLM先过一遍所有片段。没问题的直接放行，轻微问题的抽10%给人工看看，重大和严重错误100%送人工审核。然后持续比较LLM和人工的判断，调整置信度和阈值。

defupdate_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能否处理医疗或法律翻译等专业领域？

可以，但需要额外设置。对于专业领域：

1. 在提示中提供特定领域的术语表
2. 在校准中包含您领域的错误示例
3. 使用领域上下文（"这是药品说明书"）
4. 为高风险内容增加人工审核比例
5. 考虑对非常专业的术语使用微调或RAG方法

往哪走

LLM做翻译QA这件事，2025年已经过了"能不能用"的阶段，进入了"怎么用好"的阶段。它提供了规模（用一致标准评估海量片段）、可解释性（详细的、可执行的反馈）、灵活性（通过提示词适配不同需求），还有成本效率（减少60-80%的人工QA工作量）。

但说到底，LLM不是万能的。它处理不了需要深度文化判断的东西，它会犯低级错误，它的稳定性还有待提高。我觉得接下来一两年，谁能把LLM + 人工的混合工作流跑得最顺畅，谁在翻译质量管理上就占优势。

准备实施基于LLM的翻译QA？试用KTTC获得具有MQM合规性和混合人机AI工作流程的生产就绪AI LQA。