Проверка человеком

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

Обычно встроить человека в автоматизированный поток — значит выбрать один из неудобных путей: держать запрос открытым, пока кто-то читает перевод, собирать собственную очередь проверки или вручную интегрировать API поставщика переводов. Этот этап решает всё внутри самой задачи. Когда humanEdit включён, асинхронная задача запускает движок, затем ставится на паузу до проверки человеком — вашей командой или внешним специалистом — и возобновляется с его правками, передавая этот результат на все последующие этапы.

Этот этап идёт после Rephrase и до Post-edit в пайплайне локализации и, как все остальные этапы, применяется только к задачам, созданным через Асинхронный API локализации. Не знакомы с пайплайном? Начните с обзора.

На этой странице

• Как работает пауза
• Внутренняя проверка
• Права доступа
• Внешняя проверка
• Порог качества
• Тайм-аут
• Как включить этап

Как работает пауза#

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

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

Кто проверяет переводы, настраивается отдельно для каждого языка и каталога. В настройках движка «Ручная проверка» для них выбирается группа принятия решений — ваша команда или внешний поставщик. Приостановка, возобновление и перенос результатов работают одинаково в обоих случаях. Переводы, для которых не назначена группа, отправляются без проверки.

Внутренняя проверка#

Ваша команда проверяет переводы прямо в дашборде Lingo.dev. Ожидающие проверки элементы появляются в Queue (/orgs/<org-id>/queue) как элементы Human review, а проверяющие получают уведомления о новых поступлениях. Проверяющий открывает элемент, редактирует нужные ключи, затем нажимает Approve as-is или, если что-то было изменено, Approve with edits — кнопка показывает количество правок, например Approve with 2 edits. Задача возобновляется с результатом проверки.

Проверки не закрепляются за кем-то одним и не блокируются. От группы принятия решений, в которую направлена проверка, зависит, кто получит уведомление по почте. Все, у кого есть право Проверять переводы, могут видеть любую открытую проверку и принимать по ней решение.

Internal Review доступна в плане Enterprise. Если план включает эту функцию, новый движок начинает с Internal Review; если нет — с External Review, а опция Internal review отмечена тегом Enterprise. Выбирайте её, когда в команде есть языковая экспертиза и вы хотите полностью контролировать финальную формулировку без привлечения сторонних специалистов.

Права доступа#

Внутренняя проверка доступна не всем в организации — очередь защищена правами доступа, так что перевод на стадии проверки видят только те, кому вы открыли доступ. Администратор организации назначает доступ через роли (Настройки → Роли):

Два разрешения намеренно разделены. Проверяющему достаточно Review translations — одного этого разрешения хватает на всю работу: редактировать, утверждать как есть, утверждать с правками. Manage reviews — для тех, кто руководит процессом: оно добавляет историю проверок по всей организации, но не включает доступ к очереди само по себе. Выдавайте оба разрешения тому, кто и проверяет, и отчитывается; только первое — тому, кто просто работает с очередью.

Внешняя проверка#

Если в вашей команде некому проверять переводы для локали, направьте её во внешнюю группу принятия решений через учётную запись Lingo.dev или свою учётную запись у поставщика, например BLEND. Тогда перевод отправится квалифицированному профессиональному переводчику. Задание приостанавливается так же и возобновляется, когда поставщик возвращает отредактированный перевод. В вашем коде ничего не меняется: разница лишь в том, кто читает строку, а не в том, как выполняется задание.

Выбирать уровень не нужно — площадка сама оценивает квалификацию переводчика. Внешняя проверка оплачивается за каждое слово: через ваш план Lingo.dev, если вы используете учётную запись Lingo.dev, или напрямую поставщику, если используете свою.

Внешняя проверка тоже появляется в Queue; при открытии в ней указан Qualified translator как проверяющий. Пользователь с правом Review translations может открыть её и взять на себя: выбрать Approve as-is или Approve with edits — и задача завершится здесь, не дожидаясь переводчика. В подтверждении Take over this review указывается стоимость — до того как вы подтвердите действие. Взять задачу бесплатно можно только пока ни один переводчик не приступил к работе; если переводчик уже начал, его вознаграждение выплачивается в любом случае — независимо от того, воспользуетесь ли вы его результатом.

Здесь важно сказать прямо: Внешняя проверка — это реальный переводчик по ту сторону процесса, со всеми вытекающими сроками и стоимостью. Это не «более быстрая модель». Используйте её там, где важна именно человеческая экспертиза, — для регулируемых текстов и критически важного контента, — а для основной массы контента, которой это не требуется, опирайтесь на сценарий только с AI.

Порог качества#

Не каждый перевод требует участия человека. Задайте Quality threshold (1–100) в настройках Human review, и AI-эвалюатор будет оценивать каждый перевод до отправки на проверку. Оценка на уровне порога или выше — перевод публикуется без участия человека, а этап humanEdit фиксируется как skipped; ниже порога — перевод отправляется на проверку в обычном режиме. Оставьте поле пустым, чтобы проверять всё. В конфиге это qualityThreshold в humanEdit.

У перевода, опубликованного таким образом, нет результата от человека, поэтому Post-edit для него не выполняется.

Тайм-аут#

Этап с человеком добавляет риск, которого нет у AI-этапов: человек может вообще не ответить. Проверяющий в отпуске, поставщик перегружен, про элемент забыли. Если не задать границы, задача будет ждать бесконечно.

Ожидание ограничено. Вы сами задаёте, сколько рабочий процесс ждёт результата от человека, — параметр Timeout в часах в настройках Human review; timeoutHours в конфиге. Он применяется к обоим режимам проверки. Если таймаут истекает без ответа, этап помечается как skipped, и задача продолжается с AI-переводом в качестве финального результата. По умолчанию — 48 часов. В Queue проверка с истёкшим таймаутом отображается как Closed without a decision.

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

Как включить этап#

humanEdit настраивается в движке на вкладке Пайплайн. Подробнее о настройке этапов пайплайна см. в разделе Как настроить пайплайн. Структура настроек этого этапа:

{
  "humanEdit": {
    "enabled": true,
    "timeoutHours": 48,
    "qualityThreshold": 85,
    "routes": [
      { "pool": "<legal-reviewers-pool-id>", "match": { "locales": ["de"], "path": ["docs/legal/**"] } },
      { "pool": "<lingo-external-pool-id>", "match": { "locales": [] } }
    ]
  }
}

routes направляет каждый язык и каталог в группу принятия решений: пустое значение locales означает любой язык, а отсутствие path — любой каталог. Приоритет у наиболее точного маршрута. Если для целевого перевода нет подходящего маршрута, он отправляется без проверки. provider и tier — устаревшие поля. Они считываются, только пока routes пусто. timeoutHours — ограничение, заданное параметром Время ожидания, а необязательное поле qualityThreshold (1–100) — значение параметра Порог качества.

Если маршрут указывает на архивную или удалённую группу, задание не запустится и завершится с ошибкой HumanReviewPoolUnusable. Чтобы оно могло запуститься, в движке нужно настроить маршрут к другой группе.

Когда этап срабатывает, он записывает себя в задачу в разделе stepId: "humanEdit" со статусом completed, failed или skipped — это та же запись шага, которую создаёт каждый этап. Как читать эти записи, описано в разделе Observe pipeline runs.

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