Настройка пайплайна

Задайте, какие этапы пайплайна должны выполняться, на двух уровнях: по умолчанию на движке и, при необходимости, через переопределение в отдельном запросе.

Вы уже решили, какие этапы нужны вокруг основного шага перевода. Теперь остаются два вопроса: где зафиксировать это решение и что делать, если одной задаче нужен другой сценарий? Ответ — два слоя. Движок хранит конфигурацию по умолчанию, которую наследует каждая асинхронная задача. Объект pipelineConfig в отдельной отправке переопределяет эту конфигурацию только для неё. Этапы, которые вы не включаете в переопределение, наследуются от движка, поэтому в запросе указываются только отличия.

Впервые работаете с пайплайном? Начните с раздела Обзор пайплайна, чтобы понять, что делает каждый этап. Эта страница посвящена тому, как включать этапы и переопределять их, а не тому, что именно происходит после включения.

Настройки по умолчанию на уровне движка#

Откройте вкладку Pipeline у движка в панели управления и включайте или отключайте каждый этап независимо. Эта конфигурация становится значением по умолчанию для движка: каждая асинхронная задача, отправленная в него, будет выполняться с этими этапами, если только запрос не переопределит их. Настройте один раз — и не придётся заново задавать пайплайн в каждом вызове.

У каждого этапа свой переключатель. Можно включить любую комбинацию — ни одного, все сразу или что угодно между ними:

• AI-редактирование до локализации — очищает исходный текст перед переводом.
• Проверка человеком после локализации — отправляет результат на внутреннюю или внешнюю проверку. В той же панели вы выбираете режим, уровень и тайм-аут.
• AI-оценка после локализации — остаётся отключённой, пока не включена проверка человеком; она согласует правки человека с правилами вашего движка.
• Перефразирование для естественного звучания — переписывает текст так, чтобы он звучал естественно для носителя языка. Работает независимо от других этапов.
• Проверка обратным переводом — проверяет, сохранился ли смысл после двойного перевода. Работает независимо от других этапов.

Основная локализация — не переключатель: она выполняется всегда. Остальные этапы лишь выстраиваются вокруг неё.

Именно эти настройки по умолчанию наследует каждая задача, поэтому конфигурация движка — это основа, поверх которой применяется переопределение pipelineConfig. Каждый этап соответствует отдельному ключу:

{
  "preEdit": { "enabled": true },
  "humanEdit": {
    "enabled": true,
    "provider": "internal",
    "tier": "standard",
    "timeoutHours": 48
  },
  "postEdit": { "enabled": false },
  "rephrase": { "enabled": false },
  "backTranslation": { "enabled": true }
}

Что именно контролирует каждое поле — какого провайдера проверки использовать, какой уровень выбрать, сколько ждать, — описано на отдельной странице соответствующего этапа. Здесь мы разбираем, где живёт конфигурация и как сочетаются её два слоя.

Переопределение на уровне запроса#

Большинство задач должны выполняться с настройками движка по умолчанию. Исключение — отдельная отправка, которой нужен другой пайплайн: например, разовая партия маркетинговых текстов, где нужен этап перефразирования, обычно отключённый в вашем движке, или юридический контент, для которого этот этап лучше пропустить. Если менять движок ради одной партии, это затронет и все остальные задачи.

Поэтому отличия передаются прямо в запросе. Добавьте объект pipelineConfig в тело POST /jobs/localization, и он переопределит конфигурацию движка по умолчанию только для этой отправки. На самом движке ничего не изменится; следующая задача без переопределения снова пойдёт с настройками по умолчанию.

{
  "sourceLocale": "en",
  "targetLocales": ["de", "fr"],
  "data": { "headline": "Ship in every language." },
  "pipelineConfig": {
    "rephrase": { "enabled": true },
    "backTranslation": { "enabled": false }
  }
}

Вот правило наследования, благодаря которому переопределение остаётся компактным: этап, который вы указали, переопределяется; этап, который вы пропустили, наследует конфигурацию движка по умолчанию. В приведённом выше запросе для этой конкретной задачи rephrase включён, а backTranslation выключен. preEdit, humanEdit и postEdit не указаны, поэтому они выполняются ровно так, как настроены в движке. Вы задаёте только отличия.

И ещё две вещи, которые переопределение не делает. Скажем об этом прямо, потому что именно здесь легко решить, будто оно умеет всё:

• Оно меняет только эту отправку. Оно не записывает изменения обратно в движок, так что это не способ внести постоянные изменения в конфигурацию — для этого нужна вкладка Pipeline. Используйте переопределение для разового случая, а вкладку — для новой стандартной конфигурации.
• Оно не отменяет собственные правила выполнения этапа. AI-оценка после локализации запускается только тогда, когда проверка человеком дала результат, поэтому включение postEdit ничего не изменит в задаче, где нет этапа человеческой проверки для согласования — независимо от того, на каком уровне он был включён.

Проверьте, что действительно выполнилось#

Конфигурация задаёт, какие этапы должны выполняться; запись самой задачи показывает, какие из них действительно отработали. У задачи есть массив steps[], и именно по нему вы подтверждаете, что переопределение на уровне запроса действительно сработало, а не просто было отправлено.

Как читать эти записи — stepId для каждого этапа, что означает шаг skipped, где отображаются некритичные сбои, — описано на отдельной странице.

Следующие шаги#

Теперь вы можете задать конфигурацию по умолчанию на движке и переопределить её в запросе. Дальше — отправьте задачу с переопределением или проверьте шаги выполнения, чтобы увидеть, какие этапы действительно были запущены.