Human-in-the-loop: человек в контуре

Human-in-the-loop — это способ проектирования AI- и ML-систем, при котором человек остается частью рабочего контура: размечает данные, проверяет спорные ответы, утверждает критичные решения или вмешивается при сбоях. Подход нужен там, где одной автоматизации недостаточно по качеству, риску или требованиям контроля. Он не подходит для задач с жесткими ограничениями по задержке, для полностью формализуемых процессов с низкой ценой ошибки и для случаев, где участие человека номинально и не влияет на исход.

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

Если совсем просто, Human-in-the-loop, или HITL, означает: модель не получает право действовать в одиночку там, где ошибка может стоить денег, времени, репутации или безопасности. Она делает черновик, оценку или рекомендацию, а человек подтверждает, исправляет или останавливает действие.

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

HITL встречается в двух основных формах. Первая — на этапе обучения: люди размечают данные, исправляют ответы модели и формируют эталон. Вторая — на этапе эксплуатации: система сама обрабатывает простые случаи, а неоднозначные или опасные передает на ручную проверку.

Признак настоящего Human-in-the-loop: человек не просто «смотрит», а может изменить решение, а его действия фиксируются и используются для улучшения системы.

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

На этапе обучения

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

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

На этапе эксплуатации

1. Система получает входные данные и выдает результат: прогноз, извлеченные поля, классификацию, сгенерированный текст или рекомендованное действие.
2. Параллельно считается сигнал риска: уверенность модели, нарушение правил, новизна примера, чувствительность данных, сумма транзакции, влияние на пользователя.
3. Если случай простой и риск низкий, система завершает его автоматически или создает черновик без срочной ручной проверки.
4. Если случай спорный, модель не уверена или правила обнаружили аномалию, задача маршрутизируется человеку.
5. Человек подтверждает, исправляет, отклоняет решение или эскалирует его дальше. Исправления сохраняются в журнале и затем используются для настройки правил, промптов, датасетов и самой модели.

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

Что важно в реализации

• Ясные правила эскалации. Нужно заранее определить, какие случаи уходят человеку: низкая уверенность, конфликт между источниками, неизвестный класс, высокая сумма, чувствительный запрос.
• Хороший интерфейс ревьюера. Человек должен видеть не только ответ модели, но и исходные данные, доказательства, историю, причины срабатывания маршрута.
• Право на override. Если оператор не может отменить действие системы, это не контроль, а декорация.
• Логи и обратная связь. Без журналирования нельзя понять, где ошибается модель, а где ошибаются люди.
• Контроль качества ревьюеров. Люди тоже ошибаются, устают и расходятся в оценках, поэтому нужны инструкции, калибровка и выборочный аудит.

Зачем нужно

• Снижать цену ошибки. Даже хорошая модель проваливается на редких, новых и пограничных случаях. Человек нужен как предохранитель.
• Обрабатывать неоднозначность. В реальных процессах часто важен контекст, который не помещается в простой набор признаков.
• Соблюдать требования контроля. В ряде процессов нужен осмысленный человеческий надзор, журнал решений и возможность объяснить итог.
• Собирать качественный фидбек. Исправления операторов — это ценный материал для переобучения и улучшения маршрутизации.
• Управлять дрейфом. Когда данные меняются, ручная проверка помогает заметить, что модель больше не работает так, как ожидалось.
• Разделять рутину и исключения. Автоматизация забирает массовые повторяющиеся задачи, а человек концентрируется на сложных случаях.

Для практиков важно измерять не только качество модели, но и качество всего контура. Полезны такие показатели, как доля полностью автоматических кейсов, доля эскалаций, время ручной проверки, число отмен после проверки, согласованность ревьюеров и категории причин, по которым кейсы уходят человеку. Иначе можно получить модель с хорошей офлайн-метрикой, но плохой операционной экономикой.

Пример

Практический сценарий — обработка входящих счетов и актов в финансовой команде. OCR или мультимодальная модель извлекает поставщика, сумму, НДС, дату, номер договора и реквизиты. На бумаге это выглядит как идеальный кандидат для полной автоматизации, но в реальности документы приходят в разном качестве, с нестандартной версткой, несколькими таблицами и противоречивыми полями.

1. Модель извлекает поля и возвращает оценку уверенности по каждому из них.
2. Правила проверяют, совпадает ли поставщик со справочником, соответствует ли сумма лимитам, есть ли договор, не дублируется ли номер документа.
3. Если документ типовой, все поля распознаны уверенно и правила не нашли конфликтов, система создает черновик проводки или карточки на оплату.
4. Если сумма необычна, реквизиты не совпадают, документ плохо читается или модель не уверена в ключевых полях, кейс уходит бухгалтеру.
5. Бухгалтер исправляет поля, указывает причину ошибки и подтверждает итог. Эти причины потом разбирают: где нужен новый шаблон, где слаб OCR, где не хватает бизнес-правил, а где стоит переобучить модель.

Здесь Human-in-the-loop полезен не потому, что «ИИ почти все понимает», а потому что процесс грамотно разделен: машина быстро снимает рутину с типовых документов, а человек забирает исключения, где цена ошибки выше. Если же отправлять бухгалтеру почти каждый документ, автоматизация теряет смысл. Если, наоборот, не отправлять почти ничего, растет риск неверных оплат и проблем в учете.

Заблуждения и ограничения

• «Если человек смотрит, система безопасна». Не всегда. Люди подвержены automation bias: они часто соглашаются с машиной, особенно когда интерфейс подает ответ как «наиболее вероятный» или когда поток задач слишком большой.
• «Человек всегда исправит ошибку модели». Нет. Если у ревьюера нет времени, контекста, инструкции или полномочий, он превращается в узкое место без реального повышения качества.
• «HITL решает проблему галлюцинаций LLM». Он снижает риск попадания неверного ответа в прод, но не устраняет причину. Если поток ошибок велик, ручная проверка просто не масштабируется.
• «Можно добавить ручную проверку в конце и этого достаточно». Нет. Если не продуманы маршрутизация, журнал причин, критерии эскалации и обратная связь в обучение, система останется хаотичной.

Есть и прямые ограничения. Human-in-the-loop плохо подходит для задач, где решение нужно за миллисекунды, например в некоторых контурах реального времени. Он может быть экономически невыгоден при огромном потоке низкорисковых операций, если стоимость ручной проверки выше возможного ущерба от редкой ошибки. Он также сложен там, где для проверки нужны редкие специалисты, а их время дефицитно и дорого.

Отдельная проблема — качество человеческих решений. Разные эксперты могут по-разному трактовать один и тот же случай. Поэтому HITL требует не только модели, но и дисциплины: инструкций, обучения ревьюеров, процедур разрешения несогласия и регулярного пересмотра правил. Без этого вы не уменьшаете неопределенность, а просто переносите ее с модели на людей.

Частые вопросы

Чем Human-in-the-loop отличается от обычной ручной проверки?

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

Как понять, какие случаи отправлять человеку?

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

Решает ли HITL проблему галлюцинаций больших языковых моделей?

Частично и только на уровне последствий. Если человек проверяет критичные ответы до отправки пользователю, риск снижается. Но источник проблемы остается: модель по-прежнему может уверенно выдавать неверную информацию.

Где чаще всего возникает узкое место?

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

Связанные понятия

Понятие	Суть	Чем отличается от HITL
Human-on-the-loop	Человек наблюдает за системой и вмешивается при необходимости, но не участвует в каждом решении.	Контроль слабее и более надзорный; подходит, когда поток слишком велик для постоянной ручной проверки.
Human-out-of-the-loop	Система действует полностью автоматически без обязательного участия человека в конкретном кейсе.	Максимум скорости и масштаба, но выше требования к качеству, тестированию и управлению риском.
Active learning	Модель выбирает наиболее полезные или неуверенные примеры для разметки человеком.	Это один из механизмов Human-in-the-loop на этапе обучения.
RLHF	Настройка модели на основе человеческой обратной связи.	Человек влияет на обучение, но не обязательно участвует в каждом производственном решении.
Human oversight	Более широкий термин для человеческого надзора над автоматизированной системой.	HITL — частный случай, где человек встроен именно в контур принятия или проверки решений.

На практике выбор между этими схемами зависит от цены ошибки, допустимой задержки, объема потока и доступности экспертов. Чем выше риск и неоднозначность, тем больше оснований оставлять человека внутри контура, а не только над ним.