Human-in-the-loop (HITL)

Human-in-the-loop (HITL) — это паттерн, в котором автоматический процесс останавливается в заранее заданной точке и ждёт решения человека: одобрения, исправления, запрета действия или дополнительных входных данных. По актуальным источникам на 2026-08-18 HITL — не отдельная модель и не один продукт, а способ встроить человеческий контроль в агент, RAG-конвейер, ML-сервис или orchestration workflow.

Английский термин: Human-in-the-loop. Сокращение: HITL. В официальных документах рядом встречаются operational labels human review workflow, human loop, approval и callback-based human validation; единого русского перевода в source pack не зафиксировано, поэтому на практике чаще оставляют аббревиатуру HITL.

Простыми словами

Грубо говоря, HITL — это ситуация, когда автоматизация делает работу сама, но на важной развилке спрашивает вас. Не «человек всё делает вручную», а «система доходит до checkpoint и просит подтвердить, поправить или остановить результат».

Простой пример: агент подготовил письмо клиенту, но перед отправкой должен получить ваше явное подтверждение. Или RAG-система собрала ответ по документам, но если вопрос чувствительный или результат сомнительный, ответ уходит на проверку редактору.

Как это работает

Google Cloud описывает HITL как вставку человеческого вмешательства в заранее определённой контрольной точке: агент ставится на паузу, ждёт review и продолжает работу только после того, как человек одобрит, исправит или дополнит вход. В Airflow это шаги workflow, которые приостанавливают pipeline ради input, approval или intervention; в AWS A2I — human review workflow плюс отдельный human loop для конкретного объекта проверки.

Запрос / данные
      ↓
Модель, агент или RAG-конвейер
      ↓
Checkpoint / правило эскалации
(низкая уверенность, рискованное действие,
нужна модерация или внешнее подтверждение)
      ↓
Пауза выполнения
      ↓
Человек: approve / reject / correct / add input
      ↓
Возврат решения в систему
      ↓
Продолжить / повторить / остановить / эскалировать

1. Система выполняет автоматические шаги: retrieval, генерацию, классификацию, рассуждение или orchestration.
2. Срабатывает правило, по которому автоматического результата недостаточно. В AWS это может быть human review для ML-результатов; в guidance OpenAI — важная работа или действия высокого риска.
3. Процесс переходит в состояние ожидания. В tutorial Airflow 3.3.1 указано, что с версии 3.3 waiting HITL tasks используют состояние awaiting_input, управляемое scheduler; в 3.1 и 3.2 ожидание строилось через trigger-based deferral.
4. Человек возвращает решение обратно в процесс. В Google Cloud Workflows это может быть callback endpoint: workflow ждёт авторизованный HTTP POST и после него продолжает execution.
5. Система фиксирует исход и решает, что делать дальше: отправить действие, заблокировать его, вернуть результат на доработку или передать следующему этапу.

Практическая оговорка: сам HITL-паттерн не равен готовому интерфейсу для reviewer. В текущем архитектурном guidance Google Cloud это именно паттерн, а внешний контур взаимодействия с человеком вы проектируете сами.

Где применяется

• Агентные действия с высоким риском. OpenAI рекомендует держать человека в контуре для important work, а в system card для Operator отдельно указано, что рискованные действия требуют human oversight и явного подтверждения. Среди примеров названы покупки, отправка email и удаление событий календаря.
• Проверка результатов ML при низкой уверенности. AWS A2I реализует HITL через human review workflow и human loop. Во встроенных типах задач документация называет извлечение key-value через Textract и image moderation через Rekognition; для собственных сценариев можно вызывать StartHumanLoop.
• Оркестрация data- и ML-pipeline. Документация providers-standard для Apache Airflow описывает HITL operators как шаги workflow, которые ставят автоматизированные pipelines на паузу ради human input, approval или intervention.
• Workflow-подтверждение через callback. В tutorial Google Cloud Workflows показан переводческий процесс: workflow создаёт callback endpoint, ждёт explicit HTTP POST от человека и сохраняет в Firestore значение approved=true или false.

Практический пример

Сценарий: HITL перед отправкой RAG-ответа клиенту. Это не готовый продукт, а рабочая схема, собранная из текущих паттернов Google Cloud, Airflow и рекомендаций по oversight.

1. RAG-конвейер собирает документы, например после chunking, извлекает релевантные фрагменты и формирует черновой ответ.
2. Оркестратор проверяет правила эскалации: ответ затрагивает деньги, удаление данных, внешнюю отправку, модерацию или выглядит подозрительно из-за возможной инъекции промпта.
3. Если правило сработало, workflow ставится на паузу. В Airflow это может быть HITL step; в Google Cloud Workflows — ожидание через callback.
4. Reviewer получает черновик ответа, набор источников и контекст, который собрал агент. Если в системе есть reasoning model или целая chain, reviewer проверяет не только финальную фразу, но и достаточность оснований для действия.
5. Человек выбирает одно из решений: «одобрить», «исправить», «запретить действие» или «эскалировать дальше».
6. Система записывает результат и либо отправляет ответ, либо возвращает его на доработку, либо завершает execution без действия.

Практически checkpoint лучше ставить не везде, а только там, где цена ошибки выше задержки. Иначе HITL превращается в ручную очередь и перестаёт быть полезной автоматизацией.

Чем отличается от human review workflow, human loop и callback

Есть и более широкая академическая трактовка. Обзорные статьи по HITL для machine learning и NLP относят сюда не только runtime-approval, но и разметку, демонстрации, экспертные знания и feedback по ходу жизненного цикла модели. Поэтому vendor docs обычно говорят о более узком, прикладном смысле: пауза, человеческая проверка и продолжение выполнения.

Ограничения и заблуждения

• Заблуждение: «HITL = ручная работа вместо автоматизации». Нет. Смысл паттерна в выборочном человеческом вмешательстве на определённых шагах, а не в полном переводе процесса на ручной режим.
• Заблуждение: «добавили approval — получили гарантию правильности». Источники описывают механизм oversight и pause/resume, но не обещают, что любое человеческое ревью автоматически уберёт ошибки. HITL снижает риск в важных точках, но не заменяет качество модели и ясные правила эскалации.
• HITL требует инфраструктуры вокруг себя. Для Google Cloud Workflows callback endpoint действует в рамках того execution, где был создан, а отправка callback требует IAM-разрешения workflows.callbacks.send в роли Workflows Invoker.
• Поведение зависит от версии платформы. В текущих docs Airflow tutorial версия — 3.3.1, а providers-standard docs — 1.17.0. Release notes указывают, что HITL operators требуют Airflow 3.1+ и пакет apache-airflow-providers-standard.
• Не каждый managed-сервис доступен всем. AWS прямо пишет, что SageMaker A2I больше не открыт для новых клиентов; существующие клиенты могут продолжать работу, но новые функции не планируются.
• Для RAG это не отдельная «фича платформы». По текущему source pack HITL лучше понимать как поперечный паттерн контроля для агентов, orchestration и ML, а не как режим, который существует только внутри RAG.

Редакционное ограничение: материал опирается только на supplied source pack и фиксирует состояние документов на 2026-08-18. Цены, региональная доступность и будущие изменения версий здесь не проверялись исчерпывающе и должны уточняться на официальных страницах конкретного инструмента.

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

Связанные термины и инструменты

Если вы строите агентную систему, HITL чаще всего сочетается с понятиями chain, reasoning model и защитой от prompt injection. Для RAG также полезно понимать, как качество chunking влияет на извлечение и, значит, на то, когда вообще нужен human checkpoint.

Из инструментов в текущих источниках чаще всего встречаются Apache Airflow HITL Operators, Google Cloud Workflows callbacks и Amazon Augmented AI (A2I). Для Airflow важно проверить совместимость с Airflow 3.1+ и наличие пакета apache-airflow-providers-standard; для A2I — статус аккаунта, потому что сервис закрыт для новых клиентов.

Источники

• Using Amazon Augmented AI for Human Review – Amazon SageMaker AI
• Prerequisites to Using Augmented AI – Amazon SageMaker AI
• airflow/RELEASE_NOTES.rst at main · apache/airflow · GitHub

• Choose a design pattern for your agentic AI system | Cloud Architecture Center | Google Cloud Documentation
• Core Components of Amazon A2I – Amazon SageMaker AI
• HITLOperator (Human-in-the-loop) — Airflow 3.3.1 Documentation
• Human in the Loop (HITL) Operators — apache-airflow-providers-standard Documentation
• Create a human-in-the-loop workflow using callbacks | Workflows | Google Cloud Documentation
• Wait using callbacks | Workflows | Google Cloud Documentation
• Responsible and safe use of AI | OpenAI
• Operator System Card | OpenAI
• A Survey of Human-in-the-loop for Machine Learning
• Putting Humans in the Natural Language Processing Loop: A Survey

Вопросы и ответы

Human-in-the-loop и manual review — это одно и то же?

Не совсем. HITL — более широкий паттерн: человек участвует в определённых контрольных точках процесса. Manual review может быть одним из шагов такого паттерна, но сам по себе не описывает, как workflow ставится на паузу и затем возобновляется.

Где ставить human checkpoint в агенте или RAG?

По текущим источникам разумные места — рискованные действия, низкая уверенность ML-результата, модерация и внешние side effects. Google Cloud рекомендует заранее определять checkpoint, а OpenAI — сохранять human oversight для important work и действий высокого риска.

Можно ли сделать HITL без специального managed-сервиса?

Да. В source pack Google Cloud рассматривает HITL как архитектурный паттерн, а не только как продукт. На практике вам всё равно нужны механизм паузы, интерфейс для reviewer и безопасный способ вернуть решение в execution.

Подходит ли HITL только для RAG?

Нет. По supplied sources HITL встречается в agent workflows, orchestration, ML review и более широком ML/NLP lifecycle. Для RAG это полезный сценарий, но не единственная область применения.

Почему вокруг HITL бывает путаница?

Потому что академические обзоры используют термин широко — от разметки данных до feedback в обучении, — а vendor docs обычно говорят о более узком runtime-сценарии: пауза, человеческая проверка и продолжение выполнения.