Три часа редактирования медицинской инструкции на 40 страниц. МТ переводит “patient consent form” как “форма согласия пациента” на строке 12, потом “форма получения согласия пациентом” на строке 47, потом “документ о согласии пациента” на строке 89. Один документ. Один термин. Три разных перевода.
Твой словарь говорит, что это должно быть одно конкретное выражение, всегда. Директивы редактирования говорят “дотримайся словаря”. Но базовый выход МТ уже неровный с предлогами и особенностями языка, поэтому ты не можешь просто это пропустить — ты должен перечитать каждое предложение, чтобы поймать эти мелкие несоответствия. Работа, которая должна была занять 3 часа, теперь занимает 5. И все потому, что машинный перевод не “понял” твой словарь.
Это не проблема навыка. Не ленивого разработчика. Это то, как на самом деле работает нейронный МТ: он предсказывает термины слово-за-словом на основе контекста, не помня, что он выбрал пять предложений назад. Твой словарь — это просто текстовый файл. МТ-движок не учится на нем; он заменяет токены на выходе, что часто разрушает грамматику вокруг них. И для многих переводчиков это — основание для недовольства.
Почему машинный перевод не может дотриматься твоего словаря (и почему это становится хуже)¶
Чтобы понять, почему МТ ломает словари, нужно понимать, как на самом деле работает нейронный машинный перевод.
Традиционный статистический МТ-движок (старые штуки, до 2015 года) сначала искал в словаре. Если он нашел совпадение, он его использовал. Без вопросов. Просто, предсказуемо, и скучно — но последовательно.
Нейронный МТ изменил все. Вместо правил, NMT-модели работают так:
- Читают исходное предложение. Модель принимает все — контекст, соседние слова, пунктуацию.
- Предсказывают токены один-за-один. Исходя из того, что она читает и что она уже выпустила до этого, она угадывает следующее целевое слово. Потом следующее. Потом следующее.
- Повторяют для каждого предложения. Модель не помнит, что она делала три предложения назад. Каждое новое предложение — это свежее предсказание.
Твой словарь невидим для этого процесса. Движок был обучен на миллиардах слов, и он изучил статистику: “когда я вижу [исходный термин] в [контекст], [целевой перевод] вероятен.” Замена словаря происходит после основного прохода перевода, так что это как сказать “мне все равно, что ты выучил — используй это вместо того.” Движок не был построен для органичной интеграции ограничений словаря; он просто заменяет токены в конце.
Вот что на самом деле происходит, когда ты добавляешь словарь к NMT-движку:
- Замена токена: Движок генерирует “consentimiento de paciente.” Словарь говорит “используй consentimiento del paciente.” Движок заменяет его. Но окружающее предложение было предсказано с предположением оригинального порядка, так что теперь ты получаешь грамматически странное.
- Слепота контекста: Словарь не имеет способа сказать “используй этот перевод только если пациент один, женского пола, и контекст хирургический.” Он применяется слепо.
- Компромисс качества: Исследования от Phrase, AppTek и TranslateFX показывают, что применение ограничений словаря снижает общее качество перевода на 5-15%, потому что движок должен работать вокруг принудительного термина вместо естественной генерации.
Поэтому словари в коммерческих МТ-движках (Google Cloud Translation, Azure, Bing) работают — они принуждают термин. Но они часто оставляют синтаксис вокруг них поломанным или неправильным, заставляя редакторов исправлять грамматику вокруг термина словаря, что перечеркивает всю цель иметь словарь.
Реальная стоимость непоследовательной терминологии (Это не просто раздражает)¶
Да, это раздражает видеть один термин, переведенный тремя разными способами. Но стоимость глубже.
Время редактирования. Непоследовательность терминологии — это #1 причина, почему редакторы сообщают, что MTPE занимает больше времени, чем ожидалось. Когда выход непоследователен, твой мозг не может полагаться на закономерности; ты должен перепроверять каждое вхождение. Исследования показывают, что редакторы тратят 30-50% времени на исправление терминов, когда словари не соблюдаются. Это деньги.
Жалобы на качество. Клиенты быстро замечают непоследовательность. Они читают переведенный документ и думают “разве переводчик не знал, что это должно быть одно и то же слово каждый раз?” Независимо от того, признают ли они это или нет, они снижают оценку за профессионализм. Для регулируемых отраслей (медицина, право, финансы) непоследовательность терминов может создать проблемы соответствия — регулирующие органы ожидают последовательного использования определенных терминов.
Ответственность и переделка. В секторах типа фармацевтика, контракты или медицинские устройства непоследовательность терминов может сделать документ неприемлемым для подачи органам власти. Ты это обнаруживаешь при проверке, а не при сдаче. Переделка стоит в 2-3 раза дороже, чем оригинальное редактирование.
Выгорание редакторов. Редакторы, которые тратят половину времени на исправление “должно-быть-автоматического”, быстро разочаровываются. Работа кажется повторяющейся и неблагодарной. Магазины, работающие с большим объемом MTPE, сообщают о 40% текучести редакторов именно из-за плохого применения словаря на стороне источника.
Потеря конкурентного преимущества. Агенции, которые доставляют последовательные, словник-соблюденные переводы, выигрывают против тех, которые этого не делают. Клиенты теперь ожидают, что MTPE выдаст выход настолько последовательный, как у человеческого переводчика, и если твой словарь не работает, ты доставляешь меньше.
Решение 1: Построй словарь, который действительно работает¶
Проблема не в словарях — проблема в плохих словарях.
Большинство словарей терпят неудачу, потому что они слишком большие, слишком общие или слишком жесткие. Ты видишь словари с 1000 записей, смешивающие “the” (определенно пропусти это) с высоко специализированными терминами. Ты видишь словари без контекста: “bank” → “banco” (мужского рода? какой вид банка?). Ты видишь словари, построенные одним человеком, который не редактирует, поэтому они включают термины, которые не подходят к грамматике целевого языка.
Работающий словарь выглядит иначе:
1. Сфокусируйся безжалостно. Включай только термины, которые: - Появляются в 80%+ исходных документов, ИЛИ - Имеют мандат клиента или критичны для бренда, ИЛИ - Являются специализированными и не интуитивными (например, “data controller” в контексте GDPR — не “data manager”).
Стремись к 100-200 терминам для большинства проектов, не 1000. Каждый термин, который ты добавляешь, обходится редакторам когнитивной нагрузкой, когда этот термин появляется. Меньший, более плотный словарь быстрее проверять.
2. Добавь контекст и информацию о грамматике. Для каждой записи: - Исходный термин и предпочтительный целевой перевод - Часть речи (существительное, глагол, прилагательное) - Контекст использования (“только в документах, обращенных к пациентам” или “только юридические контракты”) - Запрещенные альтернативы (“НЕ используй [этот синоним]”) - Морфологические варианты, если нужны
Словарь с примечаниями самодокументируется. Редакторы понимают, почему термин обязателен, а не просто что он есть.
3. Избегай переводов один-к-одному, которые не работают в целевом языке. Если английский “the” не имеет эквивалента в целевом языке, не пытайся его принуждать. Если исходный термин должен быть переструктурирован, чтобы звучать естественно в целевом языке, задокументируй эту переструктуризацию в словаре, а не как простую замену термина.
4. Храни его в терм-базе, а не в таблице. CAT-инструменты (Trados, memoQ, Smartcat, SDL) имеют модули терм-базы, которые хранят метаданные и интегрируются в рабочий процесс редактирования. Когда редактор работает над предложением, содержащим термин словаря, термин появляется как предложение или предупреждение в реальном времени. Таблицы требуют ручного поиска, который редакторы часто пропускают под давлением времени.
5. Версионируй и поддерживай его. Словари — это живые документы. Если редакторы найдут термин словаря, который не подходит, пометь его на проверку. Если обратная связь клиента меняет то, чем должен быть термин, обновь его и сообщи об изменении. Отслеживай версии, чтобы знать, какая версия была использована для какой партии.
Решение 2: Ограничивай МТ-движок (Осторожно)¶
Когда у тебя есть твердый словарь, тебе нужно рассказать МТ-движку его использовать. Есть три основных подхода, с разными компромиссами.
Замена словаря на выходе (просто, но рискованно):
Это то, что Google Translate, Bing Translator и Azure Translation делают по умолчанию. Ты прикрепляешь словарь, движок работает как обычно, потом заменяет токены на совпадения словаря на выходе.
Плюсы: Легко, без переобучения, работает с любым облачным МТ-движком. Минусы: Разрушает окружающую грамматику, снижает общее качество на 5-15%, не учитывает контекст или морфологию.
Используй это только если твой словарь очень маленький (30-50 терминов) и состоит из собственных имен или названий брендов, которые не влияют на синтаксис (например, названия компаний, названия продуктов).
Ограничения на основе разметки (лучше, требует предварительной обработки):
Ты оборачиваешь термины словаря в разметку перед отправкой на МТ, например:
<term target="consentimiento del paciente">patient consent form</term>
Некоторые МТ-движки (AppTek, определенные конфигурации Trados) распознают эту разметку и рассматривают термин словаря как “зафиксированный” — движок его не трогает, и предложение предсказывается вокруг него. Это лучше сохраняет синтаксис, чем слепая замена токена.
Плюсы: Лучшее сохранение грамматики, учитывает контекст (ты можешь добавлять разные разметки для разных контекстов). Минусы: Требует предварительной обработки исходного текста, работает только с движками, которые это поддерживают, все равно добавляет накладные расходы.
Используй это для технических и медицинских документов, где последовательность критична, но ты согласен с немного более высокой стоимостью обработки.
Обучение для конкретной сферы (лучше всего, но дорого):
Если у тебя есть 10,000+ выровненных пар предложений в твоей специализированной сфере, ты можешь тонко настроить open-source NMT-модель (Opus MT, Hugging Face transformers) или нанять сервис-провайдера (Translated, Lionbridge, AppTek) для создания своего движка. Термины словаря встроены в веса модели — ограничение словаря не требуется.
Плюсы: Движок естественно учится использовать твою терминологию, без потери качества, автоматически обрабатывает контекст и морфологию. Минусы: Высокая начальная стоимость (€5,000-25,000), требует 3-6 недель, жизнеспособно только для больших, постоянных проектов (200k+ слов/год).
Используй это, если у тебя есть стабильный, большой объем специализированного контента (техническая документация, фармацевтика, право) и ты можешь амортизировать стоимость на 12+ месяцев переводов.
Решение 3: Проверяй соответствие словарю с QA-автоматизацией¶
Вот жесткая правда: даже с отличным словарем и ограниченным МТ-движком, редакторы иногда пропускают термины словаря, если они под давлением времени или термин словаря “кажется неправильным” в контексте. Здесь вступает QA-автоматизация.
Перед тем, как редакторы даже откроют документ, запусти автоматическую QA-проверку, которая сигнализирует: - Термины в словаре, которые не появляются на выходе (пропущенные термины словаря) - Термины на выходе, которые должны быть в словаре, но их нет (нарушения последовательности) - Термины словаря, используемые грамматически странно (предлагая артефакт замены словаря)
Большинство CAT-инструментов имеют это встроенное (QA Trados, QA-проверки memoQ, валидация Smartcat). Установи на “жесткую остановку” — не позволяй редактору перейти к следующему сегменту, пока нарушения словаря не разрешены.
Данные из QA-проверок также говорят тебе, какие термины словаря вызывают проблемы (может быть, термин действительно не подходит к целевому языку, или может быть, ему нужно уточнение). Используй эту обратную связь для итерации словаря.
Исследования от Phrase и Translated показывают, что QA-валидированное соответствие словарю ловит 95%+ ошибок в терминологии до того, как человек даже их проверит, сокращая финальное время QA на 40%.
Решение 4: Используй интеграцию словаря на уровне платформы¶
Для агенций или команд, работающих с большим объемом, ручное управление словарем становится узким местом. Современные платформы перевода (Phrase, Smartcat, ChatsControl, Crowdin) теперь предлагают интегрированное управление словарем, которое комбинирует все вышеупомянутые подходы.
Эти платформы обычно предлагают: - Терм-база с рабочими процессами одобрения. Термины могут быть предложены, обсуждены, одобрены и версионированы в пределах платформы. - Введение контекста перед МТ. Платформа передает релевантные записи словаря в МТ-движок вместе с контекстом домена/тона, так что движок имеет больше информации заранее. - Интеграция редактора в реальном времени. Редакторы видят совпадения словаря и флаги QA встроенными по мере работы. - Автоматизированная предварительная валидация. Перед редактированием QA запускается автоматически и выявляет нарушения и непоследовательности словаря. - Отчетность о соответствии. Панели показывают, какие термины словаря были применены, какие были переопределены и какие вызвали проблемы.
Например, ChatsControl включает применение терминов как часть своей системы перевода: перед переводом документа ты указываешь домен (медицинский, юридический, технический), тон и словарь. AI-переводчик платформы использует этот контекст, чтобы построить план (включая сопоставление словаря), переводит против этого плана, потом проход QA повторно проверяет соответствие словарю и сигнализирует непоследовательности. Для команд, работающих с большим объемом MTPE, это сокращает время редактирования на 30-40% только на терминологии. Платформа также сигнализирует термины, которые словарь говорит должны быть использованы, но не были, облегчая редакторам выявление пропусков.
Загвоздка: платформы добавляют зависимость (ты больше не переводишь локально со своими инструментами). Но для команд, делающих 200k+ слов/месяц, преимущества управления словарем часто перевешивают блокировку инструмента.
Чек-лист лучших практик: Рабочий процесс применения словаря¶
Вот конкретный рабочий процесс, который работает:
До перевода: - [ ] Извлеки словарь из контекста проекта (документы клиента, предыдущие переводы, исследование сферы) - [ ] Построй терм-базу с 100-250 критичными терминами (не 1000) - [ ] Добавь контекст, морфологию и примечания об использовании для каждого термина - [ ] Имей как минимум одного двуязычного рецензента, одобрившего словарь перед использованием - [ ] Храни словарь в системе терм-базы (CAT-инструмент или платформа), не в таблице
При переводе: - [ ] Передавай словарь + контекст домена в МТ-движок (через разметку, параметр или платформу) - [ ] Выбирай метод ограничения на основе размера и содержания словаря (замена для имен/брендов; разметка для технических терминов; собственное обучение для больших объемов) - [ ] Логируй, какая версия словаря была использована для каждой партии (для отслеживания)
Перед редактированием: - [ ] Запусти QA-валидацию, сигнализирующую нарушения словаря - [ ] Проверь QA-отчет на термины с высокими нарушениями (эти требуют улучшения словаря) - [ ] Сообщи редакторам: “Эти термины из словаря; ты можешь переопределить только с одобрением лидера и документированной причиной”
Во время редактирования: - [ ] Редакторы работают с видимыми флагами QA; термины словаря появляются как встроенные предложения - [ ] Переопределяй термины словаря только когда это абсолютно необходимо, с примечаниями (эти примечания передаются в улучшение словаря)
После редактирования: - [ ] Запусти финальную QA, чтобы проверить соответствие словарю в завершенной работе - [ ] Извлеки переопределенные или проблемные термины для проверки словаря в следующем проекте - [ ] Задокументируй уроки (“этот термин нуждается в морфологических вариантах”, “этот термин должен быть запрещенным синонимом”, и т.д.)
Часто задаваемые вопросы¶
Почему функция словаря в Google Translate на самом деле не работает?
Бесплатные МТ-движки сравнивают словарь с исходным текстом, потом заменяют термины на выходе — но эта замена часто разрушает грамматику вокруг них. К тому же, они не учитывают контекст (bank = банк как финучреждение или берег реки), поэтому вынуждают неправильные переводы. Платные инструменты лучше фильтруют, но даже там ограничение словаря снижает качество на 5-10%.
Стоит ли использовать словарь с нейронным МТ, если он снижает качество?
Да, но не одним. Сфокусированный словарь (100-300 критичных терминов) вместе с обучением на специализированных данных и QA-проверкой превосходит как сам словарь, так и само обучение. Ключ — начать редактирование с последовательного выходного результата, а не исправлять термины с нуля. Даже 5-10% потери качества компенсируется 40-50% более быстрым редактированием исправлений терминов.
В чем разница между словарем и терм-базой?
Словарь — это простой список исходных → целевых пар. Терм-база (в CAT-инструментах типа Trados, memoQ, Smartcat) хранит метаданные: часть речи, примечания об использовании, запрещенные синонимы, правила контекста и статус одобрения. Терм-базы интегрируются прямо в интерфейс редактирования — редакторы видят предложения и предупреждения в реальном времени.
Как предотвратить ‘дрейф терминологии’ в больших проектах?
Дрейф терминологии (когда переводчики постепенно отклоняются от словаря под давлением времени) происходит в 80% больших MTPE-проектов. Решения: (1) передавай словарь МТ-движку перед каждой партией, (2) запускай автоматическую QA-проверку, которая сигнализирует о нарушении словаря до редактирования, (3) установи жесткое правило, что термины словаря обязательны (задокументируй ‘почему этот термин’ в примечаниях), (4) выборочно проверяй 5-10% завершенной работы на дрейф.
Можно ли ‘обучить’ МТ-движок дотриматься моего словаря без добавления его каждый раз?
Да, через специализированное тонкое настройка или обучение. Если у тебя есть 10,000+ выровненных пар предложений с последовательной терминологией, ты можешь тонко настроить open-source-модель (типа Opus MT) или нанять сервис-провайдера (Translated, AppTek, Lionbridge) для создания своего движка. Это встраивает твою терминологию прямо в модель — никаких ограничений словаря не требуется. Однако это стоит €5,000-20,000 в начале, поэтому это жизнеспособно только для больших объемов (100k+ слов/месяц).
Как я могу знать, что редакторы действительно используют словарь?
Включи QA-валидацию в своем CAT-инструменте (большинство имеют это встроенное), чтобы автоматически сигнализировать о нарушениях словаря. Проверяй QA-отчеты еженедельно; если нарушения растут, это означает, что редакторы перегружены или словарь неясен. Также отслеживай ‘консистентность терминологии’ как отдельную метрику — стремись к 95%+ соответствию словарю на критичных терминах. Некоторые платформы (ChatsControl, Smartcat, Phrase) показывают live-панели соответствия.
Что делать, если термин словаря не подходит к грамматике целевого языка?
Это самая распространенная причина, почему редакторы пропускают словарь. Решение: добавь морфологические варианты и примечания контекста к записи словаря. Например, если ‘Data Protection Officer’ обязателен, но не работает с немецким определением пола, добавь примечание: ‘Используй Datenschutzbeauftragte (жен.) или Datenschutzbeauftragter (муж.) в зависимости от контекста.’ Если словарь создается совместно переводчиками + клиентами, эти исключения решаются заранее, а не во время редактирования.