Человек в контуре — организация процесса, при которой результат работы модели проходит проверку человеком прежде, чем стать действием: отправкой, платежом, записью в систему, юридически значимым решением.
Где проверка обязательна
Необратимые действия. Действия, видимые клиенту. Решения с юридическими последствиями. Всё, что касается денег, здоровья и трудовых отношений.
Здесь проверка не тормозит процесс, а делает его допустимым: без неё систему нельзя выпускать в работу независимо от того, насколько она хороша в тестах.
Три точки вставки
До действия. Агент готовит операцию целиком, человек подтверждает, код исполняет. Самый строгий вариант: между подготовкой и исполнением гарантированно есть человек. Плата — скорость процесса равна скорости подтверждающего.
После черновика. Агент готовит текст или документ, человек правит и сам отправляет. Проверка слита с работой: каждая правка одновременно и контроль, и данные для дообучения промптов. Подходит там, где «исполнение» — это и есть публикация подготовленного.
По исключениям, постфактум. Всё исполняется автоматически; на проверку уходит только спорное — плюс случайная выборка для аудита. Вариант для обратимых действий с потолком ущерба: дешёвый в эксплуатации, но ошибку видно после того, как она произошла.
Выбор точки определяется ценой ошибки и потоком. Чем дороже ошибка и меньше поток, тем раньше контур: единичные платежи — до действия; сотни писем в день — после черновика или по исключениям. Сдвиг точки позже — это и есть повышение автономности, со всеми его правилами.
Как не превратить в имитацию
Главная опасность — не отсутствие проверки, а её формальность. Человек, подтверждающий сотню решений в день, через неделю нажимает «да» не читая. Контур формально есть, фактически нет.
Проверять выборочно, а не всё. Сплошная проверка гарантирует невнимательность.
Ставить проверку туда, где модель не уверена. Если система умеет оценивать свою уверенность, внимание тратится на спорные случаи.
Привязывать к порогу. Сумма выше определённой, новый контрагент, нетиповой запрос — на проверку; остальное автоматически.
Показывать основание. Проверяющий должен видеть, на чём построено решение, а не только сам вывод. Иначе проверить нечего.
Собирать исправления. Каждая правка — данные о том, где система ошибается систематически.
Кто отвечает
Тонкий момент, который стоит проговорить до запуска. Подтверждение человеком переносит на него ответственность за результат — и это правильно, если у него есть реальная возможность проверить. Если решение непрозрачно, а времени на разбор нет, подтверждение превращается в перекладывание ответственности на того, кто не мог ничего изменить.
Что показывать проверяющему
Подготовленное действие целиком, а не только вывод. Основание: на каких данных построено решение, из какого документа взято, какой фрагмент процитирован.
Отметку уверенности, если система умеет её оценивать. И возможность исправить, а не только принять или отклонить: исправление — это данные для улучшения, отклонение таких данных не даёт.
Одна сущность — одно подтверждение. Кнопка «подтвердить все двадцать писем» одним кликом — та же формальность, только с другой стороны: проверяется список, а не содержание. Пачки допустимы для однотипных мелких операций, но не там, где каждое действие видимо клиенту.
Тайм-аут означает отказ. Неподтверждённое за разумное время действие не исполняется, а возвращается в очередь с эскалацией. Подтверждение не должно быть действием по умолчанию — ни кнопкой Enter, ни автопродлением.
Числовой уверенности модели доверять ограниченно. Калибровка вероятностей у языковых моделей слабая: «уверенность 0,9» не означает «право в девяти случаях из десяти». Рабочие замены — наблюдаемые сигналы спора: нужных данных не было в контексте, два источника конфликтуют, значение вне привычного диапазона, адресат новый. Именно они стоят в правилах эскалации.
Что мерить
Долю исправлений и их характер. Долю отклонений. Среднее время на одно подтверждение — если оно падает до секунд, проверка стала формальной.
И отдельно: долю случаев, когда ошибка прошла проверку и обнаружилась позже. Это прямой показатель того, работает контур или создаёт иллюзию контроля.
Доля ручных проверок — операционная метрика, а не константа. Считается по типам действий: для необратимых она осознанно зафиксирована, для обратимых — должна снижаться по мере накопления статистики исправлений. Растущая очередь подтверждений при стабильном качестве системы означает, что пороги пора пересматривать — по данным, а не по ощущению «пусть ещё посмотрит».
Частые вопросы
Обязательно ли проверять все решения?
Нет, и сплошная проверка обычно вредна: она гарантирует невнимательность. Работает выборочная проверка плюс обязательная там, где модель не уверена или превышен порог по сумме и типу операции.
Как понять, что контур работает, а не имитируется?
По доле исправлений. Если проверяющий почти никогда ничего не меняет, он либо не читает, либо проверка не нужна — и оба варианта стоит разобрать. Полезно также замерять время, которое человек тратит на одно подтверждение.
Кто отвечает за ошибку, если человек подтвердил?
Формально — тот, кто подтвердил. Поэтому важно, чтобы у него была реальная возможность проверить: видно основание решения и есть время на разбор. Подтверждение непрозрачного решения в потоке — это перекладывание ответственности, а не контроль.
Где ставить проверку — до действия или после черновика?
По цене ошибки и потоку. Дорогие и редкие операции — до действия: человек гарантирует исполнение. Массовая подготовка текстов и документов — после черновика: проверка слита с правкой и даёт данные для улучшения. Обратимые операции с потолком ущерба — по исключениям, постфактум.
Что делать, если очередь подтверждений растёт?
Разбирать по классам, а не поднимать лимиты вслепую. Обычно растёт из-за одного-двух типов действий: их либо упрощают агенту (добавить данные в контекст, сузить инструмент), либо — при стабильном качестве и сотнях случаев без содержательных правок — переводят в автопрогон с выборочной проверкой. Механика перехода описана в статье про автономность.
Можно ли автоматизировать саму проверку?
Частично: формальные критерии — сумма, адресат, соответствие шаблону — проверяются кодом до показа человеку, и на стол попадает только прошедшее фильтры. Но перекладывать проверку целиком на вторую модель имеет смысл только при формальных критериях и некоррелированных ошибках; в спорных случаях человек остаётся последним звеном, потому что несёт ответственность за решение.