Human-in-the-loop для AI

Центральная задача этого подхода — подключать человека в конкретной точке риска и давать ему достаточно контекста для реального, а не формального контроля. Для демонстрации достаточно один раз получить правдоподобный результат, но production-система должна воспроизводить поведение в заданных условиях, останавливаться на границе полномочий и оставлять доказательства для разбора. Поэтому команда начинает не с выбора framework, а с task contract: цель, входные данные, допустимые действия, критерий успеха, риск и владелец результата.

Для human-in-the-loop правильный baseline начинается с явных порогов эскалации и четкого распределения решений между автоматикой и человеком. Автономность добавляют только после измеримого выигрыша на репрезентативных задачах. Такой порядок сохраняет понятную точку отказа, не прячет управление внутри LLM и позволяет доказать, что дополнительная агентность действительно лучше детерминированного workflow.

Policy классифицирует действие по влиянию, обратимости, уверенности и стоимости. Для нужного tier агент создаёт approval request с намерением, доказательствами, diff, альтернативами и сроком действия; workflow блокирует side effect до решения уполномоченной роли. Все сообщения и артефакты содержат correlation ID, версию схемы, временную метку и provenance. Такое разделение позволяет воспроизводить решение, заменять модель или инструмент и сравнивать новую версию с baseline без изменения всего продуктового контракта.

Человек подтверждает конкретное действие, а не весь будущий цикл; любое существенное изменение аргументов аннулирует предыдущее approval. Данные пользователя, инструкции, результаты инструментов и policy metadata следует хранить как разные классы информации. Оркестратор передаёт минимально необходимый контекст, а persistent state хранит ссылки на проверенные артефакты вместо бесконечной истории сообщений.

Approval fatigue превращает контроль в автоматическое нажатие кнопки, особенно когда запрос скрывает критические детали в большом trace. Причину не следует маскировать общим retry: повтор без новой информации лишь увеличивает расходы и риск повторного side effect. Система классифицирует ошибку как transient, contract, policy, data или model failure и для каждого класса задаёт отдельный контролируемый переход.

Минимальный набор защиты включает risk-based routing, компактный evidence view, separation of duties, expiry, escalation SLA и выбор approve, edit, reject или abort. Негативные тесты охватывают пустой результат, timeout после уже выполненного действия, невалидную схему, изменение прав, конфликт версий, недоверенную инструкцию и исчерпанный бюджет. Высокорисковая неопределённость завершается отказом или передачей человеку, а не импровизацией.

Offline evaluation проверяет outcome и траекторию отдельно. Основные сигналы: approval precision, доля исправленных действий, время ожидания, override rate, expired requests, incident escape rate и reviewer load. Метрики сегментируются по типу задачи, риску, языку, инструменту и версии модели; среднее значение не должно скрывать провал критического сегмента. Эталон фиксирует инварианты и запрещённые события, но допускает несколько корректных путей.

Наблюдаемость для human-in-the-loop должна фиксировать причину эскалации, evidence bundle, решение reviewer, latency и override. Trace должен позволять восстановить не только финальный ответ, но и решения, которые к нему привели. Чувствительные значения редактируются до записи, retention ограничивается, а каждый alert привязывается к конкретному owner и runbook.

Новую реализацию human-in-the-loop целесообразно вводить через canary, измеряя false escalation и небезопасные auto-approval. Перед расширением трафика команда сравнивает task success, критические нарушения policy, latency, cost и частоту ручных эскалаций с действующим baseline. Prompt, policy, tool schema и model version изменяются независимо, чтобы каждую регрессию можно было локализовать.

Rollback должен возвращать не абстрактную «старую версию», а совместимый набор: pending approvals, reviewer context и decision policy. Активные задачи либо завершаются по предыдущему контракту, либо мигрируют по проверенному правилу. После инцидента очищенный trace становится regression case, а команда проверяет альтернативные пути к тому же нежелательному side effect.

Human-in-the-loop полезен только тогда, когда reviewer видит достаточно evidence, имеет время и полномочия изменить решение. Экран approval должен показывать точное действие, целевой ресурс, ожидаемый эффект, неопределённость и вариант rollback. Общая кнопка «подтвердить всё» создаёт automation bias и не является надёжным контролем.

Gate размещают перед необратимым или высокорисковым side effect, а не после него. Approval привязывают к contract ID, payload hash и expiry, чтобы его нельзя было повторно использовать для другой операции. Измеряйте override rate, время review, обнаруженные ошибки и нагрузку от false positives. Если люди систематически подтверждают без проверки, workflow нужно перепроектировать.

• Показывайте точный payload.
• Добавляйте expiry и binding.
• Измеряйте реальную пользу review.