LLM для оценки качества перевода: возможности и ограничения в 2025
Большие языковые модели превратили оценку качества перевода из чисто ручного ремесла в AI-дополненный процесс. GPT-4, Claude, Gemini — эти модели уже умеют находить ошибки в переводах, объяснять, что не так, и выдавать оценки, совместимые с MQM. Причём делают это за секунды, а не за часы.
Но это не серебряная пуля. У LLM есть конкретные ограничения, которые нельзя игнорировать. Ниже — честный разбор: что они реально умеют, где врут, и как встроить их в рабочий процесс без иллюзий.
Как LLM оценивают перевод
Принципиальное отличие от старых моделей MTQE: те выдавали один числовой балл и молчали. LLM объясняет своё решение человеческим языком. Вы получаете не просто «0.87», а конкретный перечень найденных ошибок с категориями, серьёзностью и пояснениями.
Что LLM привносят в QA
| Возможность | Что это значит на практике |
|---|---|
| Вывод на естественном языке | Объясняет ошибки так, что переводчик сразу понимает, что исправить |
| Zero-shot | Работает без доменного обучения — дал промпт и пошёл |
| Контекст документа | Видит не отдельный сегмент, а текст целиком — ловит несогласованности |
| 100+ языков | Одна модель покрывает большинство языковых пар |
| Гибкие инструкции | Адаптируется под конкретные критерии через промпт |
Типичный поток
┌─────────────────────────────────────────────────────────────┐
│ Вход │
│ ┌───────────────┐ ┌───────────────┐ ┌─────────────────┐ │
│ │ Исходный текст│ │ Перевод │ │ Инструкции │ │
│ │ (английский) │ │ (немецкий) │ │ (критерии MQM) │ │
│ └───────┬───────┘ └───────┬───────┘ └────────┬────────┘ │
│ │ │ │ │
│ └──────────────────┼────────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ LLM │ │
│ │ (GPT-4/Claude) │ │
│ └────────┬────────┘ │
│ │ │
│ Выход ▼ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Аннотации ошибок с категориями ││
│ │ • Уровни серьёзности (Critical/Major/Minor) ││
│ │ • Объяснения для каждой проблемы ││
│ │ • Общий балл качества ││
│ │ • Предложения по исправлению ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Что LLM делают хорошо
На основе бенчмарков и реальных внедрений — вот где LLM показывают себя сильнее всего.
Обнаружение ошибок
Конкретные цифры точности по типам:
- Искажения смысла — 85-90%
- Пропуски и добавления — 85-90%
- Грамматика и орфография — 95%+ (тут LLM почти безупречны)
- Несогласованность терминологии — 90%+ (при наличии глоссария)
- Стиль и регистр — 80-85%
Категоризация по MQM
LLM умеют классифицировать найденные ошибки по таксономии MQM. Вот как это выглядит:
Источник: "The server will restart automatically."
Перевод: "Сервер будет перезапущен вручную."
Анализ LLM:
{
"errors": [
{
"type": "Accuracy/Mistranslation",
"source_span": "automatically",
"target_span": "вручную",
"severity": "Major",
"explanation": "'Вручную' — противоположность 'automatically'. Смысл перевёрнут."
}
],
"score": 95,
"overall_assessment": "Одна серьёзная ошибка точности, меняющая операционный смысл."
}
Такую ошибку, кстати, классический MTQE мог бы и пропустить — предложение грамматически правильное, беглое, а смысл противоположный.
Контекстуальная оценка
LLM видят дальше отдельного сегмента. Они ловят:
- Непоследовательность терминологии по документу
- Смену тона или стиля
- Нарушение связности между абзацами
- Противоречия с ранее переведённым контентом
Объяснения
В отличие от чёрных ящиков, LLM объясняют свои рассуждения:
"Перевод использует неформальное 'ты', но исходный текст
и деловой контекст предполагают 'Вы'. Ошибка Style/Register,
серьёзность Minor — смысл сохранён, но голос бренда нарушен."
Для переводчика это полезнее, чем просто красная пометка «ошибка стиля».
Бенчмарки (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с |
На основе тестовых наборов с MQM-аннотациями для EN-DE, EN-FR, EN-ZH.
Где LLM ошибаются
Честно говоря, ограничений хватает. И если их не учитывать, можно наломать дров.
Галлюцинации
LLM иногда находят ошибки там, где их нет:
Источник: "The quick brown fox"
Перевод: "Быстрая бурая лиса"
LLM (неверно): "Рекомендуется 'шустрая' вместо 'быстрая'"
Реальность: оба варианта корректны. LLM придумал проблему.
Обратный случай ещё хуже — реальная ошибка пропущена. Это случается реже, но случается.
Что делать: пороги уверенности + человеческий контроль для критического контента. Не доверяйте LLM слепо.
Нестабильная оценка серьёзности
Одна и та же ошибка при повторном запуске может получить разный уровень серьёзности:
Запуск 1: "Терминологическая ошибка — Major"
Запуск 2: "Терминологическая ошибка — Minor"
Что делать: temperature=0, структурированный JSON-вывод, калибровочные примеры в промпте.
Пробелы в доменных знаниях
Общие LLM могут не знать, что в кардиологии «стент» и «шунт» — разные вещи, или что в конкретной юрисдикции «liability» переводится иначе, чем в другой.
Что делать: давать доменный контекст, глоссарии и справочные материалы прямо в промпте.
Разброс по языковым парам
Качество сильно зависит от языковой пары:
| Языковая пара | Производительность |
|---|---|
| EN ↔ DE/FR/ES | Высокая |
| EN ↔ ZH/JA/KO | Средне-высокая |
| EN ↔ RU | Средне-высокая |
| EN ↔ AR/HE | Средняя |
| Малоресурсные пары | Ниже |
Что делать: калибровать пороги для каждой пары, усиливать человеческий контроль там, где LLM слабее.
Непоследовательность
LLM может по-разному оценить одинаковые сегменты в зависимости от их позиции в документе:
Сегмент A в позиции 10: "Ошибок не найдено"
Тот же сегмент в позиции 50: "Замечена проблема стиля"
Что делать: пакетная обработка с одинаковым контекстом, детерминированные настройки.
Внедрение на практике
Промпт-инжиниринг
Промпт — это 80% успеха. Плохой промпт → мусор на выходе, какую бы модель вы ни взяли.
Базовая структура:
Вы профессиональный оценщик качества перевода. Проанализируйте
перевод согласно стандартам MQM.
Исходный язык: {source_lang}
Целевой язык: {target_lang}
Домен: {domain}
Исходный текст:
"{source_text}"
Перевод:
"{translation}"
Контекст:
- Глоссарий: {glossary}
- Стайлгайд: {style_guide}
Оцените перевод и выдайте:
1. Список ошибок с типом, подтипом, серьёзностью, фрагментами
исходника и перевода, объяснением
2. Общий балл MQM (100 - взвешенные штрафы)
3. Краткое резюме
Ответ в формате JSON.
Продвинутый вариант с калибровкой:
Добавьте 2-3 размеченных примера перед реальной задачей. Покажите модели, что в вашем проекте считается Major, а что Minor. Это резко повышает согласованность оценок.
Пример 1 — Major:
Источник: "Do not exceed 10mg daily"
Перевод: "Принимайте 10 мг ежедневно"
Проблема: пропуск "Do not exceed" — критичная информация о безопасности
Серьёзность: Major (в фармконтексте была бы Critical)
Пример 2 — Minor:
Источник: "Click the button"
Перевод: "Нажмите на баттон"
Проблема: "баттон" → "кнопка" по глоссарию
Серьёзность: Minor (смысл сохранён, вопрос терминологического предпочтения)
Структурированный вывод
Для стабильных результатов используйте JSON-схему или function calling:
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
)
Пакетная обработка
В продакшене вы не будете отправлять по одному сегменту за раз. Группируйте связанные сегменты (скажем, по 10 из одного документа), добавляйте глоссарий и стайлгайд, запускайте параллельно через несколько экземпляров LLM, агрегируйте результаты.
┌─────────────────────────────────────────────────────────────────┐
│ Пакет переводов │
│ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │Сег 1 │ │Сег 2 │ │Сег 3 │ │Сег 4 │ │Сег 5 │ ... │
│ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘ │
│ └─────────┴─────────┼─────────┴─────────┘ │
│ │ │
│ ┌───────────▼───────────┐ │
│ │ Пакетный процессор │ │
│ │ - Группировка │ │
│ │ - Глоссарий │ │
│ │ - Стайлгайд │ │
│ └───────────┬───────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │LLM 1 │ │LLM 2 │ │LLM 3 │ Параллельно │
│ └──┬───┘ └──┬───┘ └──┬───┘ │
│ └───────────────────┼───────────────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ Агрегатор │ │
│ │ - Объединение │ │
│ │ - Расчёт баллов │ │
│ │ - Отчёт │ │
│ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
Как снизить затраты
QA на базе LLM дороже MTQE. Вот три способа это смягчить.
Многоуровневая обработка. Сегменты с высоким MTQE-баллом (0.95+) пропускаем. Средние (0.75-0.95) отправляем дешёвой модели (GPT-4o-mini). Проблемные (ниже 0.75) — лучшей модели (GPT-4 Turbo).
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 API-запросов для 100 сегментов — 10 пакетов по 10. Экономия на overhead и лучший контекст.
Кэширование. Если один и тот же сегмент встречается в разных документах (а в технической документации это обычное дело), зачем оценивать его дважды?
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
Сравнение провайдеров
OpenAI GPT-4
| Модель | Для чего | Цены (дек. 2024) |
|---|---|---|
| GPT-4 Turbo | Максимальная точность | $10/1M вход, $30/1M выход |
| GPT-4o | Баланс скорости и качества | $2.50/1M вход, $10/1M выход |
| GPT-4o-mini | Большие объёмы, низкие риски | $0.15/1M вход, $0.60/1M выход |
Сильная сторона — лучшая общая точность, надёжный JSON-вывод. Слабая — цена при масштабе и лимиты rate.
Anthropic Claude
| Модель | Для чего | Цены |
|---|---|---|
| Claude 3.5 Sonnet | Продакшен QA | $3/1M вход, $15/1M выход |
| Claude 3 Haiku | Быстрый скрининг | $0.25/1M вход, $1.25/1M выход |
Сильная сторона — нюансные объяснения, хорошо следует сложным инструкциям. Claude часто лучше объясняет почему что-то ошибка, а не просто указывает на неё.
Google Gemini
| Модель | Для чего | Цены |
|---|---|---|
| Gemini 1.5 Pro | Длинные документы | $1.25/1M вход, $5/1M выход |
| Gemini 1.5 Flash | Быстрая обработка | $0.075/1M вход, $0.30/1M выход |
Сильная сторона — огромное контекстное окно (1M+ токенов), можно загрузить целый документ. Слабая — JSON-вывод менее стабилен, промпты приходится дорабатывать.
Гибридный рабочий процесс
На практике лучше всего работает связка «LLM + человек», а не что-то одно.
┌─────────────────────────────────────────────────────────────┐
│ Входящий перевод │
└─────────────────────────────┬───────────────────────────────┘
│
┌───────────────▼───────────────┐
│ Оценка LLM │
│ (все сегменты параллельно) │
└───────────────┬───────────────┘
│
┌─────────────────────┼─────────────────────┐
│ │ │
Нет ошибок Незначительные Серьёзные/Критические
│ │ │
▼ ▼ ▼
┌─────────┐ ┌───────────┐ ┌───────────────┐
│ Принять │ │Выборка 10%│ │ 100% контроль │
│ │ │ человеком │ │ человеком │
└─────────┘ └───────────┘ └───────────────┘
│ │
▼ ▼
┌─────────────────────────────────┐
│ Отслеживание точности LLM │
│ - Сравнение LLM vs человек │
│ - Обновление метрик │
│ - Корректировка порогов │
└─────────────────────────────────┘
Ключевой момент — петля обратной связи. Вы сравниваете оценки LLM и человека, считаете процент согласия, и если он падает ниже 85%, увеличиваете долю человеческой проверки. Если растёт — уменьшаете.
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()
FAQ
Могут ли LLM заменить людей в QA перевода?
На 70-80% рутинных задач — да. Грамматика, орфография, очевидные искажения смысла — это LLM делают хорошо. Но культурная уместность, креативный контент, контекстно-зависимые нюансы — тут без человека никуда. Оптимально: LLM для первичной оценки, люди для верификации и сложных случаев.
Какой LLM лучше для QA перевода?
На 2025 год GPT-4 Turbo и Claude 3.5 Sonnet показывают лучшую точность. Для больших объёмов с низким риском подойдут GPT-4o-mini или Claude Haiku. Лучший способ выбрать — протестировать 2-3 модели на вашем реальном контенте. Модель, которая отлично работает на юридических текстах EN-DE, может быть посредственной на маркетинговых EN-ZH.
Сколько стоит QA на базе LLM?
Для GPT-4o при типичных размерах промптов: 1 000 сегментов — $0.50-1.00, 10 000 — $5-10, 100 000 — $50-100. Многоуровневый подход (MTQE-фильтрация + дешёвые модели для простых случаев) снижает затраты на 50-70%.
Как проверить точность LLM QA для моего контента?
Создайте тестовый набор: 200-500 сегментов с человеческими MQM-аннотациями. Запустите LLM и сравните — сколько ошибок совпало, совпадает ли серьёзность, как часто LLM отмечает не-ошибки. Целевой показатель для продакшена — 85%+ согласия. Повторяйте ежеквартально при обновлении моделей.
Работают ли LLM со специализированными доменами?
Да, но нужна дополнительная настройка. Для медицины или юриспруденции: давайте доменные глоссарии в промпте, включайте калибровочные примеры из вашего домена, указывайте контекст («это инструкция к лекарству»), увеличивайте процент человеческой проверки. Для очень специфичной терминологии рассмотрите RAG-подходы — подтягивание нужных терминов из базы знаний прямо в промпт.
Итог
LLM в 2025 году — мощный инструмент для QA перевода. Масштаб, объяснимость, гибкость, снижение нагрузки на человеческий QA на 60-80% — всё это реально.
Но LLM не замена человеческому суждению. Они замена ручной рутине. Выигрышная стратегия: LLM делают первый проход, люди проверяют критические случаи и калибруют систему. Со временем, по мере того как вы накапливаете данные и улучшаете промпты, доля человеческой работы снижается. Но не до нуля.
Хотите попробовать? Начните с KTTC — production-ready AI LQA с MQM-типологией и гибридными человеко-AI рабочими процессами.