Паттерны human-in-the-loop для ИИ-процессов

Большинство команд используют фразу "human in the loop" как успокаивающую формулу. Звучит безопасно. Звучит ответственно. Но часто это означает, что никто не решил, что именно делает человек.

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

Эта статья даёт практическую модель выбора правильного паттерна.

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

Начните с последствий

Не начинайте с модели. Начните с последствий неправильного вывода.

Задайте пять вопросов:

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

Чем больше ответов «да», тем конкретнее должна быть роль человека.

Паттерн 1: человек утверждает каждое действие

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

Примеры:

• отправка письма клиенту,
• публикация публичной статьи,
• возврат денег,
• удаление записей,
• изменение пункта договора,
• рекомендация по найму.

Модель готовит черновик или рекомендацию. Человек утверждает, редактирует или отклоняет. Финальное действие не происходит, пока утверждение не записано.

Хороший дизайн утверждения включает:

• понятный diff или предпросмотр,
• источники, которые были использованы,
• уверенность модели или флаги риска, если они есть,
• путь отклонения в один клик,
• обязательную причину override в высокорисковых процессах,
• audit log с проверяющим, временем и финальным действием.

Это самый дорогой паттерн, но для значимых действий он является правильным дефолтом.

Паттерн 2: человек проверяет исключения

Используйте это, когда большинство случаев рутинные, но часть неоднозначна или рискованна.

Примеры:

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

Процесс обрабатывает нормальные случаи и отправляет исключения в очередь.

Маршрутизация исключений требует конкретных правил. Одной «низкой уверенности» обычно слишком мало. Лучше работают такие триггеры:

• отсутствуют обязательные поля,
• извлечённые значения противоречат друг другу,
• язык не поддерживается,
• тип документа не распознан,
• тон клиента выше порога риска,
• аккаунт уровня enterprise,
• действие пересечёт денежный или data threshold,
• исходные данные устарели.

У очередей исключений должны быть владелец и SLA. Если никто не проверяет очередь каждый день, система не уменьшила работу, а спрятала её.

Паттерн 3: человек проверяет выборку

Используйте это, когда последствия невысокие, но важен дрейф качества.

Примеры:

• внутренние резюме,
• тегирование контента,
• извлечение action items из встреч,
• обогащение нечувствительных CRM-полей,
• предложенные ссылки на базу знаний.

Процесс работает автоматически. Человек проверяет выборку: например, 5 процентов выводов, 20 случайных случаев в неделю или каждый вывод после изменения новой версии промпта.

Выборка работает только тогда, когда исправления возвращаются в систему:

• фиксируйте, что было неправильно,
• классифицируйте тип ошибки,
• обновляйте промпт, retrieval, схему или правила инструментов,
• добавляйте примеры в evals,
• отслеживайте error rate со временем.

Выборка — это система качества. Это не gate для запуска.

Паттерн 4: человек аудирует постфактум

Используйте это, когда процесс низкорисковый, обратимый и высокообъёмный.

Примеры:

• внутреннее тегирование,
• поиск дублей,
• draft-only предложения для базы знаний,
• маршрутизация затрат между моделями,
• форматирование, не видимое клиенту.

Процесс работает. Логи, dashboard и периодические аудиты обнаруживают проблемы.

Этот паттерн допустим только если:

• действия обратимы,
• у процесса есть kill switch,
• логи достаточно подробны, чтобы восстановить решения,
• цена пропущенной ошибки низкая,
• пользователи знают, как сообщить о плохом выводе.

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

Паттерн 5: человек владеет решением

Используйте это, когда ИИ помогает анализировать, но не должен принимать решение.

Примеры:

• найм,
• кредитный или eligibility screening,
• юридическая стратегия,
• медицинский совет,
• серьёзность инцидента безопасности,
• выбор поставщика,
• крупные закупочные решения.

Модель может резюмировать доказательства, перечислить tradeoffs, сгенерировать вопросы или сравнить варианты. Владелец решения-человек подписывает финальное суждение.

Процесс должен явно это показывать:

• "ИИ-сгенерированный анализ, не решение."
• "Владелец решения: имя или роль."
• "Проверенные доказательства: источники."
• "Известные ограничения."
• "Финальное обоснование."

Это предотвращает распространённый сбой: гладкая рекомендация модели становится решением по умолчанию.

Простая матрица утверждения

Используйте это как отправную точку:

| Последствие процесса | Дефолтный паттерн человека | | --- | --- | | Внутреннее, обратимое, низкая видимость | Постфактум-аудит | | Внутреннее, повторяемое, чувствительное к качеству | Проверка выборки | | Неоднозначные случаи в рутинном потоке | Проверка исключений | | Видимое клиенту или внешнее действие | Утверждать каждое действие | | Разрушительное, финансовое, юридическое, HR, регулируемое | Человек владеет финальным решением |

Матрица не закон. Это forcing function. Если выбираете более лёгкий паттерн, запишите почему.

Спроектируйте экран проверки

Хороший экран проверки снижает усталость проверяющего.

Показывайте:

• что предлагает система,
• какие доказательства она использовала,
• что изменится относительно текущего состояния,
• почему элемент попал на проверку,
• разрешённые действия,
• флаги риска,
• дедлайн, если он есть.

Избегайте:

• вывода полного промпта,
• требования читать сырые логи,
• скрытия исходных документов,
• только кнопок "approve" и "reject", когда нужен вариант "edit",
• ситуации, где для проверки одного случая нужно открыть пять систем.

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

Определите правила остановки

Каждому human-in-the-loop процессу нужны правила остановки.

Примеры:

• Более 3 процентов выбранных выводов не проходят чеклист.
• Обнаружена утечка данных между клиентами.
• Более пяти высокорисковых исключений остаются непроверенными 24 часа.
• Обновление промпта или модели увеличивает rejection rate на 50 процентов.
• Процесс создал внешнее действие, которое должно было требовать утверждения.

Правило остановки должно говорить, кто ставит процесс на паузу и что происходит дальше.

Частые ошибки

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

Слепое утверждение батчей. Batch approval полезен, но только после того, как фильтры и выборка доказали однородность батча.

Нет обучения проверяющих. Проверяющим нужны примеры хороших, плохих и пограничных случаев.

Нет feedback loop. Если исправления не улучшают промпты, retrieval, схемы или исходные данные, проверка становится постоянным ручным трудом.

Нет планирования capacity. 10 процентов исключений при 1000 случаях в день — это 100 человеческих задач. Это команда, а не примечание.

Вывод

Human-in-the-loop дизайн — это не один паттерн. Это набор контролей, сопоставленных с последствиями.

Используйте:

• утверждение для действий с высокими последствиями,
• проверку исключений для неоднозначных случаев,
• выборку для дрейфа качества,
• аудит для низкорисковой обратимой работы,
• владение решением человеком для настоящих бизнес-решений.

Практический тест простой: если модель ошибается, кто замечает, кто может остановить процесс и что именно он делает? Если вы не можете ответить, процесс не готов.