AI-конвейер с обязательной проверкой человеком

Что означает human-in-the-loop на практике

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

Кнопка «Подтвердить» сама по себе не создаёт безопасность. Если проверяющий не видит исходник, основания и отличия от обычного случая, он будет соглашаться автоматически или выполнять работу заново. Хороший контур уменьшает объём внимания: показывает только значимые поля, отмечает неопределённость и позволяет перейти к доказательству.

Где поставить точку проверки

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

Если процесс имеет несколько разных рисков, одной точки недостаточно. Например, сотрудник сначала подтверждает извлечённые реквизиты, а отдельный уполномоченный пользователь — платёж. Роли и основания должны соответствовать каждой операции.

Маршрутизируйте по риску, а не одной условной уверенности

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

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

Интерфейс качественной проверки

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

• Кто и какое событие запустил обработку.
• Исходное сообщение, документ или доступный фрагмент записи.
• Предложение AI в редактируемой структуре.
• Источники и признаки, на которых основано предложение.
• Отмеченные системой сомнения и отсутствующие поля.
• Точное описание внешнего действия после подтверждения.
• Кнопки принять, исправить, отклонить и передать эксперту.
• Поле причины для значимого исправления или отказа.

Архитектура управляемого конвейера

1. 01

   Создать операцию

   Присвоить идентификатор, сохранить источник, тип задачи и текущую версию правил.

2. 02

   Подготовить данные

   Проверить доступ, формат, обязательные поля и разрешённый контекст.

3. 03

   Получить предложение

   AI возвращает структурированный результат, основания и признаки неопределённости.

4. 04

   Применить правила

   Код валидирует схему, ограничения и определяет уровень проверки.

5. 05

   Поставить в очередь

   Назначить роль, приоритет и срок, не теряя исходный контекст.

6. 06

   Зафиксировать решение

   Сохранить принятую версию, исправления, автора и причину.

7. 07

   Выполнить действие

   Использовать идемпотентный вызов и записать внешний результат.

8. 08

   Обновить оценку

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

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

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

Как использовать решения проверяющих

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

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

Люди, очередь и эксплуатация

Ручной контроль имеет ограниченную пропускную способность. Если внедрить AI без проектирования очереди, сотрудники получат поток однотипных подтверждений и начнут соглашаться автоматически. Нужно определить объём, роли, приоритеты, время ожидания и резервного проверяющего. Критичные случаи не должны теряться среди низкорисковых черновиков.

• Назначить владельца правил и владельца технического контура.
• Разделить очереди по типу процесса и риску.
• Установить срок реакции и маршрут просроченного случая.
• Ограничить пакет подтверждений разумным объёмом.
• Не показывать сотруднику случаи вне его полномочий.
• Отслеживать исправления, отклонения и механическое принятие.
• Сохранять ручной путь при недоступности AI или очереди.
• Регулярно пересматривать категории обязательного контроля.

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

Как постепенно расширять автоматизацию

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

1. 01

   Теневой режим

   AI готовит решение параллельно ручному процессу, не влияя на результат.

2. 02

   Обязательная проверка

   Каждое предложение подтверждается и собирается обратная связь.

3. 03

   Выборочная проверка

   Автоматизируется только закреплённый низкорисковый класс, остальные случаи идут человеку.

4. 04

   Наблюдаемая автоматизация

   Система выполняет разрешённое действие, сохраняет основания и контролирует отклонения.

5. 05

   Повторная оценка

   Любое изменение модели, правил или данных может вернуть класс на обязательную проверку.

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

Чек-лист перед запуском

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

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