Машинный перевод — отличный первый проход. Для многих типов контента этого достаточно. Но некоторым материалам перед выпуском нужно больше: сначала очистить исходный текст от опечаток, подключить переводчика-человека, добиться звучания как у текста, написанного носителем языка, и проверить, не потерялся ли смысл после перевода туда и обратно.
Все эти шаги можно собрать самостоятельно: вызвать перевод, прогнать текст через грамматическую проверку, отправить результат на проверку, дождаться ответа, перевести обратно, чтобы проверить смысловой дрейф, и согласовать расхождения. Сам перевод — самая простая часть. Сложнее всего — оркестровать ожидания, порядок выполнения и сбои между этапами. А сложнее всего из всего этого — рецензент, который отвечает только через два дня.
Пайплайн — это все эти шаги, уже собранные в единую цепочку. Каждая стадия — необязательная обёртка вокруг основного этапа перевода, включаемая в движке локализации (или переопределяемая для конкретного запроса), и выполняемая внутри надёжной асинхронной задачи, которая уже берёт на себя повторы и изоляцию сбоев. Вы выбираете стадии, платформа запускает их по порядку и фиксирует, что произошло. В сухом остатке идея одна: оберните этап перевода ровно теми стадиями, которые вам нужны.
Только для Async API
Стадии пайплайна применяются только к задачам, созданным через Async Localization API. Синхронный эндпоинт /localize выполняет только основной этап перевода — любая конфигурация пайплайна в движке для него игнорируется. Стадии проверки человеком нужен процесс, который может простоять на паузе два дня; в одном цикле запрос/ответ для такого ожидания нет места. Пайплайн живёт там, где задача действительно надёжна.
На этой странице
Зачем нужен пайплайн#
Обычный перевод никак не учитывает, с каким именно контентом он работает. Юридическому тексту важна буквальная точность по отношению к исходнику. Маркетинговый текст должен звучать так, будто его написал носитель языка, а не будто его просто перевели. Пользовательский исходный текст сначала стоит очистить от опечаток, чтобы одна ошибка не отравила каждую целевую локаль. А контент в регулируемых сферах требует утверждения квалифицированным специалистом.
Это разные задачи, и пайплайн позволяет одному движку справляться с любой из них, комбинируя стадии вместо того, чтобы навязывать один сценарий всем случаям. Ничего не включаете — получаете обычный перевод. Включаете стадию проверки человеком — задача ставится на паузу для вашей команды. Включаете стадию перефразирования — результат переписывается так, чтобы звучать естественно. На странице каждой стадии ниже прямо сказано, для какого контента она подходит — и, не менее прямо, для какого не подходит, чтобы вы не включили стадию, которая работает против вашей цели.
Настройки по умолчанию задаются один раз на вкладке Pipeline в движке, а для отдельной отправки их можно переопределить объектом pipelineConfig в запросе — для неуказанных стадий используются настройки движка. О механике обоих уровней читайте на странице Configure the pipeline.
Краткий обзор стадий#
Пайплайн оборачивает основной этап локализации. Можно включить любую комбинацию стадий — в этом фиксированном порядке. Отключённые стадии полностью пропускаются. У каждой стадии есть отдельная страница с полным описанием поведения, сценария сбоя и вызова для её включения.
AI-редактирование до локализации
Необязательно. AI-агент очищает исходный payload — исправляет опечатки, грамматику и орфографию — ещё до начала перевода, чтобы одна ошибка в исходнике не разошлась по всем целевым локалям. Стадия некритичная. См. Pre-localization AI edit.
Основная локализация
Выполняется всегда. Ваш движок применяет свою конфигурацию модели, глоссарий, тональность бренда и инструкции, чтобы получить перевод. Это единственная стадия, которую нельзя отключить — всё остальное только оборачивает её.
Проверка человеком после локализации
Необязательно. Перевод проверяет человек — ваша команда в дашборде (Internal Review) или профессиональный переводчик от внешнего провайдера (External Review). Задача ставится на паузу и ждёт результат через событийный механизм, поэтому длительная проверка не расходует вычислительные ресурсы во время ожидания. См. Human review.
AI-оценка после локализации
Необязательно и запускается только после того, как проверка человеком дала результат. AI-агент согласовывает правки человека с глоссарием, тональностью бренда и инструкциями вашего движка. Это не то же самое, что AI Reviewers, которые оценивают качество, не меняя текст. См. AI review.
Перефразирование для естественного текста
Необязательно. AI-агент переписывает перевод так, чтобы он звучал как естественный, идиоматичный текст для целевой локали, сохраняя смысл, плейсхолдеры и теги. Стадия некритичная. Подходит для маркетинговых текстов; пропускайте её там, где важна буквальная точность. См. Rephrase for natural copy.
Проверка обратным переводом
Необязательно. Результат переводится обратно на исходный язык, AI сравнивает его с оригиналом, а смысловой дрейф помечается как minor, major или critical — серьёзные и критические проблемы исправляются автоматически. Классический приём человеческого QA, доведённый до автоматизации. См. Back-translation check.
Что сбой стадии делает с задачей#
Самое очевидное возражение против шестиступенчатого пайплайна: каждая добавленная стадия — это ещё одна потенциальная точка сбоя. Значит ли это, что с ними задача чаще будет падать? Нет. Сбой на некритичной стадии не приводит к сбою всей задачи. Предредактирование и перефразирование — стадии некритичные: если любая из них завершается ошибкой, последний корректный результат просто передаётся дальше без изменений, а задача продолжается. Вместо падения задача переходит в состояние предупреждения, и каждая включённая стадия оставляет запись, по которой можно точно понять, что именно было выполнено.
Так устроен весь пайплайн: оберните этап перевода ровно теми стадиями, которые вам нужны, выполняйте их внутри задачи, которая уже умеет справляться со сбоями, и получайте отдельную запись по каждой стадии. О том, как задача в деградированном состоянии сообщает о себе и как устроена инспекция по стадиям, читайте на странице Observe pipeline runs. Ниже — сами стадии; начните с той, которая подходит для вашего контента.
