Human-in-the-loop - не человек рядом с нейросетью
Human-in-the-loop, HITL - это процесс, в котором система обязана получить человеческое решение или вклад в определённой точке. Человек может подтвердить действие, исправить результат, выбрать вариант, добавить недостающие сведения или передать случай специалисту.
Фраза «ответ проверяет менеджер» ничего не гарантирует, если менеджер не видит источник, не понимает ограничений, не может отменить действие или получает сотни карточек без времени на анализ. Контроль проектируется как часть workflow.
Три режима человеческого контроля
| Режим | Когда человек участвует | Пример |
|---|---|---|
| Human-in-the-loop | До продолжения конкретного workflow | Подтверждение отправки платежа |
| Human-on-the-loop | Наблюдает и вмешивается при сигнале | Оператор следит за агентом в sandbox |
| Human-over-the-loop | Задаёт правила, аудит и governance | Комитет утверждает границы автономности |
| Post-review | После результата на выборке | Контроль качества писем |
Режим выбирают по риску. Post-review подходит для обратимого текста, но не предотвращает уже совершённый перевод денег или раскрытие данных.
Почему человек в контуре тоже ошибается
Ревьюер может автоматически соглашаться с уверенно сформулированным предложением, уставать от одинаковых запросов, пропускать важное доказательство или не иметь достаточных полномочий. Это называют в том числе automation bias и rubber-stamping.
NIST подчёркивает необходимость определить роли и ответственность human-AI configuration, документировать ограничения и оценивать процессы oversight. Поэтому качество HITL зависит от интерфейса, обучения, нагрузки и независимости решения, а не от самого факта клика.
Карта риска: где ставить обязательный approval
- Можно ли полностью и быстро отменить результат?
- Затрагивает ли действие деньги, права, здоровье или безопасность?
- Меняет ли оно данные другого человека или организации?
- Покидают ли чувствительные данные разрешённую границу?
- Создаёт ли действие юридически или публично значимое сообщение?
- Есть ли независимая программная проверка?
- Понимает ли система собственную неопределённость?
- Каков масштаб одной ошибки и серии ошибок?
- Можно ли остановить действие до побочного эффекта?
Чем выше последствия и ниже обратимость, тем раньше ставится человеческая точка. Microsoft рекомендует требовать approval для действий, которые трудно отменить или которые затрагивают людей, деньги и compliance.
Матрица автономности: не делите мир на auto и manual
| Уровень | Что делает ИИ | Что делает человек |
|---|---|---|
| Suggest | Готовит вариант и доказательства | Сам выполняет действие |
| Draft | Создаёт объект без публикации | Редактирует и отправляет |
| Approve | Готовит точный вызов | Подтверждает до исполнения |
| Exception | Автоматизирует разрешённые случаи | Разбирает исключения |
| Supervised auto | Исполняет и пишет trace | Следит, останавливает, аудитирует |
Уровень назначается не всему продукту, а конкретному действию и сегменту. Агент может автоматически искать документы, создавать черновик и требовать approval только перед отправкой.
Четыре паттерна HITL
Approval должен описывать конкретное действие
Карточка «Агент хочет использовать email tool. Разрешить?» слишком абстрактна. Покажите адресатов, тему, вложения, источник адреса, полный текст или diff, последствия и возможность отмены. Для изменения данных - объект, старое и новое значение.
Спроектируй approval card для действия [название]. Входные данные: [поля]. Последствие: [что изменится]. Риски: [список]. Опиши блоки интерфейса: кто инициировал, точное действие, объект, before/after, доказательства, предупреждения, возможность отмены и четыре решения approve/reject/edit/escalate. Не скрывай критическое поле внутри сворачиваемого текста.
Checkpoint: workflow должен безопасно ждать
При запросе участия агент не должен продолжать работу в фоне. Workflow сохраняет checkpoint: состояние, pending request, trace ID, версии инструкций, предлагаемый tool call и срок действия решения. Microsoft Agent Framework описывает pause/request-response и восстановление pending requests из checkpoint.
После рестарта запрос должен быть воспроизводим, а approval - однократным. Используйте idempotency key, optimistic locking и проверку, что объект не изменился за время ожидания. Если изменился, старое подтверждение аннулируется.
Очередь ручной проверки: маршрутизация и приоритет
Все исключения не должны падать в общий inbox. Маршрутизируйте по компетенции, риску, языку, клиенту и сроку. Отдельно выделяйте возможную утечку, финансовое действие и влияние на человека.
- Стабильный case ID и trace ID.
- Тип действия и severity.
- Причина маршрутизации.
- Deadline и возраст заявки.
- Нужная роль и компетенция.
- Предложение ИИ и evidence.
- История предыдущих решений.
- Версии модели, prompt и правил.
- Допустимые решения и комментарий.
SLA, timeout и отсутствие ревьюера
Определите, сколько workflow может ждать. После deadline безопасное поведение - не всегда auto-approve. Для денежного перевода правильнее отменить pending action, для ответа поддержки - передать дежурной группе или отправить нейтральное сообщение о задержке.
| Ситуация | Безопасный fallback |
|---|---|
| Approval истёк | Отменить действие и запросить заново |
| Нет специалиста | Эскалировать следующей роли |
| Объект изменился | Инвалидировать старое решение |
| Очередь перегружена | Ограничить вход или перейти в draft-only |
| Сервис review недоступен | Закрыть опасные tools по fail-safe |
Confidence score не должен единолично решать судьбу случая
Порог уверенности полезен для маршрутизации, если score откалиброван на ваших данных. Но модель может быть уверенной в ошибке, а разные версии дают несопоставимые значения. Сочетайте score с детерминированными правилами, типом действия, сегментом и ценой ошибки.
Порог выбирают на размеченном наборе и проверяют после обновления. Для критических запретов approval обязателен независимо от confidence.
Интерфейс ревьюера должен помогать думать независимо
Если сначала показать красивый ответ модели крупным шрифтом, человек якорится на нём. Для задач с объективным результатом полезно сначала показать исходные данные и вопрос, затем предложение ИИ. Выделяйте доказательства и расхождения, а не объяснение уверенным тоном.
- Сравнение source и output рядом.
- Подсветка изменённых и неподтверждённых полей.
- Короткая рубрика решения.
- Горячие клавиши без скрытия последствий.
- Обязательная причина для reject и критического edit.
- Возможность сообщить о системной проблеме.
Audit trail: что нужно сохранить
Журнал связывает case, модельное предложение, evidence, policy result, личность и роль ревьюера, решение, правку, время, исполненный tool call и итог. Чувствительные поля маскируются и имеют отдельный доступ.
Нельзя переписывать историю после edit: храните первоначальное предложение и diff. Это позволяет оценить реальную добавленную ценность человека, найти systematic error и расследовать инцидент.
Метрики HITL: скорость без качества опасна
| Метрика | Что показывает |
|---|---|
| Approval rate | Как часто предложение принимают без правки |
| Edit и reject rate | Где ИИ требует вмешательства |
| Time to decision | Задержку очереди и интерфейса |
| Escalation rate | Нехватку компетенции или контекста |
| Post-approval error | Ошибки, пропущенные человеком |
| Inter-reviewer agreement | Однозначность правил |
| Override reason | Какие дефекты надо исправлять системно |
Высокий approval rate может означать хорошую модель или механическое подтверждение. Проверяйте его вместе с временем решения, audit sample и downstream errors.
Решения ревьюеров превращаются в evals, но не автоматически в обучение
Подтверждённые edits и rejects - ценный источник regression cases. Перед использованием проверьте качество решения, согласованность рубрики, права на данные и смещения конкретной группы ревьюеров.
Проанализируй журнал HITL без персональных данных. Поля: [описание]. Сгруппируй причины reject/edit по типу действия, версии и сегменту. Отдели единичные ошибки от повторяющихся паттернов. Для каждого паттерна предложи: deterministic validator, изменение workflow, новый eval case или необходимость обучения ревьюеров. Не предлагай автоматически обучать модель на всех решениях.
Как постепенно расширять автономность
- Начать с suggest-only и измерить качество.
- Разрешить draft для обратимых действий.
- Ввести approval с полным evidence.
- Автоматизировать узкий низкорисковый сегмент.
- Оставить risk rules и случайный audit.
- Провести canary и проверить incidents.
- Расширять только один параметр за раз.
Автономность можно быстро уменьшить feature flag или kill switch. Откат не должен требовать обновления модели или долгого deploy.
Правовые требования зависят от сценария и юрисдикции
Human oversight может быть не только продуктовым выбором. Официальная страница Еврокомиссии по AI Act относит appropriate human oversight к требованиям для high-risk AI и указывает на обязанности deployers по мониторингу. Конкретная классификация, сроки и обязанности зависят от роли, системы и юрисдикции.
Эта статья не заменяет юридическую оценку. Для найма, кредитования, медицины, образования, биометрии, правоприменения и других значимых решений привлекайте профильных специалистов до запуска.
План внедрения за четыре недели
Финальный чек-лист Human-in-the-loop
- Каждое consequential action классифицировано.
- Указаны роль и полномочия ревьюера.
- Approval происходит до побочного эффекта.
- Workflow сохраняет checkpoint и pending request.
- Повторное исполнение защищено idempotency key.
- Карточка показывает точное действие и последствия.
- Доступны approve, reject, edit и escalate.
- Evidence отделено от модельного объяснения.
- Есть SLA, timeout и fail-safe.
- Очередь маршрутизируется по риску и компетенции.
- Confidence не отменяет критические rules.
- Audit trail хранит исходный output и diff.
- Измеряются errors после approval.
- Ревьюеры обучены и могут остановить систему.
- Решения пополняют проверенный eval-набор.
- Автономность меняется по сегментам и feature flag.
- Есть kill switch и план отката.
Цель HITL - не перенести ответственность за слабую систему на оператора. Хороший контур даёт человеку понятное решение, достаточные доказательства, реальные полномочия и разумную нагрузку.