DeepL говорит, что он лучший. GPT говорит, что он лучший. Ваш глоссарий не согласен с обоими: где-то между первой и последней партией утверждённый термин для «Plan» молча превратился во что-то другое, а тикеты в поддержку пришли раньше, чем кто-либо заметил.
AI-перевод — незаметное узкое место локализации в 2026 году: индустрия активно бенчмаркает LLM против нейронного машинного перевода, но разработческая часть пайплайна — контроль глоссария, чанкинг, шлюзы качества, стоимость за миллион слов — по-прежнему почти не задокументирована. Маркетинг вендоров говорит «наша модель лучшая», научные статьи измеряют то, что нельзя задеплоить, а средний слой, который реально работает в продакшне, отсутствует.
Это руководство покрывает обе половины: что на самом деле показывают бенчмарки провайдеров (с методикой для проведения собственного) и продакшн-пайплайн, который мы построили — глоссарий → чанкинг → перевод → контроль → QA — с контролем расходов, который делает месяц на миллион слов доступным.
Что на самом деле меняет перевод на LLM
Ключевой вывод: LLM-перевод заменяет «правильно» на «правильно в контексте» — и это меняет пайплайн, а не только движок.
Нейронный MT переводит предложения. LLM переводят в контексте: они могут соблюдать глоссарий, держать голос бренда, следовать стайл-гайдам и обрабатывать неоднозначность, которую посегментные системы сглаживают. Разницу создают три возможности:
- Контроль терминологии. Глоссарий — это входные данные, а не надежда. Модель можно обязать использовать утверждённый термин для названия продукта или юридической фразы — принудительно, а не по просьбе.
- Контекстные окна. Абзац, страница, документ — модель видит больше одного предложения, что устраняет межпредложенческие ошибки ссылок, которыми страдает MT.
- Управляемый вывод. Тон, формальность, аудитория — «формально для юридических текстов, дружелюбно для онбординга» — это промпт, а не смена модели.
Заблуждение, которое стоит устранить: LLM-перевод — это не «лучший MT». Это другой инструмент с другими издержками — выше стоимость за слово, выше контроль. Пайплайн ниже существует именно для того, чтобы эти издержки окупились.
Зачем строить собственный пайплайн перевода
Ключевой вывод: пайплайн нужен потому, что вендоры продают движки, а не гарантии — контроль глоссария, измеримое качество и падающие цены на модели вы строите сами.
Три причины владеть пайплайном, а не арендовать вендора перевода:
- Терминология — это контракт. Названия брендов, юридические термины, продуктовые строки — ваш глоссарий — это бизнес-актив, и только пайплайн может соблюдать его единообразно в каждой партии и на каждом языке.
- Качество должно быть измеримым. «Выглядит нормально» не переживёт продуктовое ревью. Пайплайн с автоматизированным этапом QA даёт оценку по каждой партии и каждому языку — та же дисциплина оценки, которую наш гайд по тестированию применяет ко всему остальному.
- Цены на модели продолжают падать. Каждое новое поколение моделей снижает цену за слово. Пайплайн, который относится к модели как к конфигурируемому компоненту, автоматически забирает эти снижения; контракт с вендором — нет.
Альтернатива — вендор перевода — покупает удобство и продаёт lock-in. Сравнение ценности в этой серии показывает, почему модельный слой должен оставаться решением, которое вы контролируете, и та же логика применима к переводу.
Бенчмарк провайдеров: качество, стоимость и задержка по языковым парам
Ключевой вывод: рейтинги качества зависят от языковой пары и устаревают за месяцы — прогоняйте собственный корпус и относитесь к любому опубликованному рейтингу, включая наш, как к снимку момента.
Ландшафт 2026 года действительно спорный: независимые оценки вроде бенчмарка LLM-перевода от intlpull и опроса моделей 2026 от Lokalise показывают, как frontier-модели меняются местами в зависимости от языковой пары и типа задач, а бюджетные модели сокращают отставание на распространённых парах. Что структурно верно:
- Frontier-модели лидируют на низкоресурсных парах и в тонких регистрах — разрыв реален там, где обучающих данных мало.
- Бюджетные и open-weight модели близки на высокоресурсных парах — английский↔испанский, французский, немецкий, японский — где «достаточно хорошо» почти равно «отлично».
- Разброс между провайдерами меньше, чем разброс между дизайнами промптов. Инъекция глоссария и чанкинг влияют на качество сильнее, чем выбор модели, на большинстве пар.
Стоимостная сторона: цена за миллион слов зависит от уровня модели и поведения кэша — frontier-уровни стоят кратно больше бюджетных, а кэширование на стабильных сегментах (блоки с повторяющимся текстом, общие строки) сжимает реальную ставку. Каталог моделей отслеживает актуальную доступность; сверяйте тарифы на страницах провайдеров на момент покупки, потому что бюджеты на перевод чувствительны именно к этим цифрам.
Собственный бенчмарк за полдня: возьмите 20 репрезентативных строк на целевой язык, прогоните их через две модели-кандидата плюс ваш текущий MT и попросите носителя языка оценить их вслепую. Это тот же метод, который используют индустриальные статьи, и он отвечает на единственный вопрос, который имеет значение, — для вашего продукта и ваших языков.
Как построить пайплайн: глоссарий → чанкинг → перевод → контроль → QA
Ключевой вывод: пять этапов, один контракт — глоссарий — это данные, QA — это шлюз, а всё между ними — механика.
Скелет, на унифицированном chat endpoint:
import json
from openai import OpenAI
client = OpenAI(base_url="https://api.tokspan.com") # unified endpoint — one key for every model
GLOSSARY = [ # enforced, not suggested
{"source": "Checkout", "target": "Finalizar Compra", "lang": "es"},
{"source": "Plan", "target": "Tarifa", "lang": "es"},
]
def translate(text, lang, model="gpt-4o-mini"):
sys = (
"You are a professional translator. Use the glossary exactly; "
"never translate glossary terms differently. Keep the brand voice."
f"\n\nGlossary: {json.dumps(GLOSSARY)}"
)
return client.chat.completions.create(
model=model,
messages=[{"role": "system", "content": sys},
{"role": "user", "content": text}],
).choices[0].message.content
# Stage 5: the gate
def qa(original, translated, lang):
verdict = client.chat.completions.create(
model="gpt-4o", # a different model as judge — never the translator
messages=[{"role": "user", "content":
f"Rate this translation 0-10 for accuracy, terminology, and tone: "
f"\nSource: {original}\nTarget: {translated}"}],
).choices[0].message.content
return float(verdict) >= 7
Пять этапов, у каждого своё правило:
- Глоссарий — структурированные данные, инжектируемые в system prompt. Контракт — «точно», а не «желательно».
- Чанкинг — на уровне абзацев, а не предложений, чтобы контекст сохранялся; сегменты с терминологией держите цельными.
- Перевод — уровень модели — это решение маршрутизации: бюджетный уровень для boilerplate-текстов, frontier-уровень для маркетинговых копий (кастомная маршрутизация делает это посегментно).
- Контроль — сканируйте вывод на предмет терминов глоссария; любой промах переводится заново с выделенным глоссарием. Именно этот цикл превращает терминологию из надежды в гарантию.
- QA — шлюз с LLM-судьёй, использующий другую модель, чем переводчик, с пороговой оценкой по каждому сегменту. Партии, не прошедшие шлюз, не публикуются; применяется методология оценки по ссылке выше.
Как контролировать качество и стоимость
Ключевой вывод: стоимость за миллион слов — проектируемый параметр: тиринг, кэширование и батчинг стабильно снижают её на 60-80% без ущерба качеству.
Модель расходов в одну строку: стоимость за миллион слов = ставка модели × коэффициент раздувания токенов (переводы раздувают токены: корпус в 1M слов обычно превращается в 1.3-1.6M токенов после учёта оверхэда промпта). Три рычага:
- Тиринг по типу сегмента. Boilerplate, UI-строки и юридические стандартные тексты работают на бюджетных моделях; маркетинг и брендовые копии — на frontier-уровне. Такой микс обычно на 50-70% дешевле, чем всё на frontier.
- Кэшируйте стабильные 80%. Меню, лейблы, повторяющиеся блоки — стабильные префиксы повторяющихся сегментов попадают под кэш-цены по доле входной ставки. Перевод — одна из лучших нагрузок для кэширования, потому что одни и те же строки повторяются в каждой языковой партии.
- Батчинг офлайн-процессов. Полнодокументный перевод, выгрузки строк и ночные синхронизации терпимы к задержкам — паттерн batch-скидки из этой серии применяет скидку 50% именно к таким нагрузкам.
И оборотная сторона той же монеты: порог QA-шлюза и модель-судья версионируются как код. Каждое обновление модели перепрогоняет eval-набор, прежде чем попасть в продакшн, — дисциплина, которая не даёт «модель стала лучше» превратиться в «глоссарий стал хуже».
Частые ошибки, ломающие качество перевода
Ключевой вывод: четыре отказа — каждый невидим в демо и дорог в продакшне.
- Дрейф глоссария. Нет цикла контроля, нет сканирования вывода — утверждённый термин становится «обычно». Контроль — это этап, а не предпочтение.
- Чанкинг, убивающий контекст. Посегментные чанки разрывают межпредложенческие ссылки и расщепляют фразы с терминологией. Чанкинг по абзацам с границами, учитывающими глоссарий, — это минимум.
- Оценка по одной метрике. Один BLEU вознаграждает «буквально правильно» и наказывает «естественно правильно». Используйте оценку судьёй плюс выборку носителей языка — тот же двухдорожечный паттерн, что и в оценке любого другого LLM-вывода.
- «Машинная» локализация без адаптации. Перевод — это не локализация: даты, валюты, единицы измерения и культурные отсылки требуют обработки локали после перевода, а не вместо него. Последний этап пайплайна — адаптация локали, и если его пропустить, «страница тарифов» превращается в тикет в поддержку.
FAQ
Лучше ли LLM-перевод, чем DeepL или Google MT?
По контролю терминологии и регистру — да: LLM следуют глоссариям и стилевым инструкциям, которые MT не может. По стоимости за слово и на простых высокоресурсных парах MT по-прежнему выигрывает. Решение — это контроль против стоимости, а не «хорошо против плохо».
Как оценивать качество перевода?
Оценка судьёй (моделью, отличной от переводчика) плюс выборка носителей языка на фиксированном eval-наборе. Один BLEU вводит в заблуждение — он измеряет буквальное совпадение, а не естественность. Версионируйте eval-набор и перепрогоняйте его при каждом обновлении модели.
Сколько стоит перевод за миллион слов?
Примерно ставка модели, умноженная на раздувание токенов в 1.3-1.6 раза: бюджетные уровни намного дешевле frontier-уровней, а кэширование и батчинг сжимают реальную ставку ещё сильнее. Стройте модель расчёта, а не догадку; формула из этого руководства — отправная точка.
Как обеспечить соблюдение терминологии?
Инъекция глоссария плюс сканирование вывода на контроль: каждый сегмент сверяется с глоссарием, а промахи переводятся заново с выделенным термином. «Желательно» — это надежда; «сканируй и повтори» — гарантия.
Стоит ли батчить задачи перевода?
Офлайн-перевод — выгрузки строк, синхронизация документов, ночные процессы — это каноническая batch-нагрузка: терпимая к задержкам, высокообъёмная и со скидкой 50% на batch-уровне каждого крупного провайдера. Интерактивный перевод UI остаётся realtime.
Справится ли бюджетная модель с переводом?
На высокоресурсных парах — да: разрыв с frontier невелик там, где обучающих данных много. Низкоресурсные пары и тонкие регистры по-прежнему оправдывают frontier-уровень. Именно для посегментного решения о маршрутизации и существует пайплайн.
Итоги
AI-перевод через LLM API — это вопрос контроля, а не выбора моделей: контроль глоссария превращает терминологию в контракт, QA-шлюз с судьёй делает качество измеримым, а тиринг, кэширование и батчинг превращают стоимость в проектируемый параметр. Рейтинги провайдеров — снимки: прогоняйте собственный корпус на своих языковых парах тем методом, которым пользуется каждый серьёзный бенчмарк. Затем постройте пайплайн один раз — и каждое новое поколение моделей сделает его дешевле.
Ваши языки, ваш корпус, ваш вердикт. Получите ключ TokSpan API и прогоните одни и те же строки через несколько моделей; $5 бесплатных кредитов покроют первую партию бенчмарка.