Автоматизация без проверки человеком существует только там, где ошибка дешевле контроля. Во всех остальных случаях вопрос не «нужен ли человек», а где именно его поставить и сколько случаев ему отдать.
Ответ на этот вопрос определяет экономику проекта сильнее, чем качество модели. Система с точностью 95% и сплошной проверкой экономит меньше, чем система с точностью 85% и проверкой одной шестой случаев. Поэтому схему контроля я проектирую вместе с самим конвейером, а не после него — это часть работы по автоматизации процессов.
Оговорка о границе темы: речь идёт о проверке внутри конвейера с фиксированной последовательностью шагов. Вопрос, давать ли автономию системе, которая сама выбирает действия, — другой, и разобран отдельно: «Автономный агент или с подтверждением».
Четыре схемы контроля
Сплошная проверка
Человек проверяет всё. Система готовит, он подтверждает.
Экономия — только на подготовке: не набирать, а проверить. Обычно это 40–60% времени, что немало, но потолок низкий.
Оправдана: на запуске, пока нет статистики ошибок; там, где цена ошибки высока; в регулируемых сферах.
Проверка по порогу уверенности
Система обрабатывает сама то, в чём уверена, остальное отдаёт человеку.
Основная рабочая схема. Порог — рычаг, которым настраивается баланс между экономией и риском.
Требует, чтобы уверенность вообще была измерима. Способы получить её — проверки формата, наличие подтверждающего фрагмента, согласие нескольких прогонов: «Извлечение данных из документов».
Выборочная проверка
Система работает сама, человек проверяет случайную долю — например, каждый двадцатый случай.
Не защищает от конкретной ошибки, но обнаруживает деградацию качества. Применяется вместе с порогом, а не вместо него.
Проверка по правилу
Проверяются не неуверенные случаи, а те, что попадают под правило: сумма выше лимита, новый контрагент, нестандартный тип.
Хорошо сочетается с порогом: одно ловит неуверенность модели, другое — существенность последствий.
Где ставить проверку в конвейере
Ключевое решение, и оно почти всегда одно и то же:
> Проверка ставится перед необратимым действием, а не после каждого шага.
Промежуточные шаги — классификация, извлечение полей, определение маршрута — проверять по отдельности незачем: ошибка на них ловится дальше по цепочке и обратима. А вот отправка клиенту, платёж, изменение учётных данных — точки, после которых исправлять дорого.
Второе правило: проверять результат, а не процесс. Человеку нужно показать, что система собирается сделать, а не как она к этому пришла. Разбор промежуточных шагов нужен при диагностике, а не при рутинном подтверждении.
Как посчитать стоимость проверки
Расчёт, который стоит сделать до выбора схемы. Числа условные.
Поток 2 000 операций в месяц, ручная обработка — 5 минут, проверка подготовленного — 1 минута, полная стоимость часа 1 000 ₽.
| Схема | Ручных операций | Проверок | Часов | Стоимость |
|---|---|---|---|---|
| Без автоматизации | 2 000 | — | 167 | 167 000 ₽ |
| Сплошная проверка | — | 2 000 | 33 | 33 000 ₽ |
| Порог, 20% на проверку | — | 400 | 7 | 7 000 ₽ |
| Порог, 20%, из них 5% сложных по 5 мин | — | 400 | 9,5 | 9 500 ₽ |
Что видно. Переход от ручной обработки к сплошной проверке даёт основную часть экономии — впятеро. Дальнейшее сокращение доли проверок даёт ещё почти впятеро, но уже от меньшей базы.
Отсюда практический вывод: начинать со сплошной проверки не страшно. Она уже даёт большую часть эффекта и при этом безопасна. Снижать долю проверок можно потом, опираясь на накопленную статистику ошибок.
Обратная сторона. Если доля проверок не снижается со временем, значит либо порог не настроен, либо качество недостаточно. Это стоит отслеживать как отдельный показатель.
Главная опасность: формальное подтверждение
Схема с проверкой ломается предсказуемым образом. Человек, подтверждающий сотый однотипный результат за день, перестаёт смотреть. Нажатие «согласовать» превращается в ритуал, и контроль существует только на схеме.
Это не гипотеза, а закономерность: чем выше точность системы, тем меньше внимания уделяет проверяющий, потому что ошибки почти не встречаются. Парадокс в том, что улучшение системы ухудшает качество контроля.
Что с этим делать:
Не отдавать на проверку то, в чём система уверена. Чем меньше поток на проверку, тем внимательнее проверяющий. Сплошная проверка — худший режим с точки зрения внимания.
Показывать, на что смотреть. Не всю карточку, а подсвеченное поле, вызвавшее сомнение, с указанием причины: «ИНН не прошёл проверку», «позиция не найдена в справочнике».
Не делать подтверждение одним кликом там, где важно. Для существенных случаев — явный ввод или выбор, а не кнопка «ок».
Измерять качество проверки. Подмешивать в поток заведомо неверные случаи и смотреть, ловятся ли они. Неприятная, но действенная мера для ответственных участков.
Смотреть на время проверки. Если среднее время подтверждения — полторы секунды, никто ничего не проверяет.
Разбор: проверка, которая не работала
Задача. Конвейер обработки счетов. Извлечённые данные уходили бухгалтеру на подтверждение, дальше в учёт.
Что было. Сплошная проверка всех документов. Точность извлечения высокая, поэтому подтверждение свелось к нажатию кнопки.
Что обнаружилось. При квартальной сверке нашлись ошибки в суммах — те самые, что должны были ловиться проверкой. Разбор показал: среднее время подтверждения документа составляло около двух секунд. Прочитать карточку за это время невозможно.
Бухгалтер не халтурил: за три месяца ошибок почти не встречалось, и внимание закономерно ушло.
Что сделали.
Ввели пороги и проверки формата — часть документов стала проходить без человека.
На проверку стали попадать только те, где что-то не сошлось: не прошла контрольная сумма, сумма строк не равна итогу, контрагент не найден. Поток на проверку сократился примерно вчетверо.
В интерфейсе подсветили конкретное поле и причину сомнения вместо показа всей карточки.
Для документов свыше определённой суммы убрали подтверждение одним кликом — потребовали ввести сумму вручную для сверки.
Результат. Время проверки одного документа выросло — с двух секунд до примерно двадцати. Это выглядит как ухудшение и является улучшением: проверка стала настоящей. Общие затраты времени при этом снизились, потому что документов на проверку стало вчетверо меньше.
Вывод. Сплошная проверка создаёт иллюзию контроля. Реальный контроль получается тогда, когда на проверку попадает мало случаев и по каждому понятно, что именно вызвало сомнение.
Частые вопросы
Нужно ли проверять всё, что делает автоматизация?
На запуске — да, пока нет статистики ошибок. Дальше разумно перейти к проверке по порогу уверенности: система обрабатывает сама то, в чём уверена, а спорные случаи отдаёт человеку. Сплошная проверка ограничивает экономию и, что важнее, снижает внимательность проверяющего.
Где в конвейере ставить проверку?
Перед необратимыми действиями: отправкой клиенту, платежом, изменением учётных данных. Промежуточные шаги проверять по отдельности незачем — ошибки на них обратимы и ловятся дальше по цепочке.
Как не получить формальное «согласовано»?
Сократить поток на проверку, подсвечивать конкретное поле и причину сомнения вместо показа всей карточки, а для существенных случаев требовать явного действия вместо кнопки. Полезно отслеживать среднее время проверки: полторы секунды означают, что никто ничего не смотрит.
Как определить, в чём система уверена?
Через программные проверки — контрольные суммы, форматы, диапазоны, наличие значения в справочнике, — а также через согласие нескольких прогонов и наличие подтверждающего фрагмента в исходнике. Собственная оценка уверенности модели ненадёжна: она систематически завышена.
Какая доля случаев должна уходить на проверку?
Столько, сколько нужно, чтобы пропущенные ошибки оставались в допустимых пределах. Величина определяется ценой ошибки, а не желаемой экономией. Важнее следить за динамикой: если доля не снижается месяцами, значит пороги не настроены или качество недостаточно.
Можно ли обойтись без человека вовсе?
Там, где ошибка дешевле контроля и легко обратима — да. Там, где действие необратимо или последствия существенны, — проверка остаётся, даже если система работает хорошо. Хорошая работа системы не отменяет ответственности за результат.
Что дальше
Как получить признаки уверенности — «Извлечение данных из документов» и «Структурированный вывод модели». Что должно происходить при сбоях — «Обработка ошибок в ИИ-автоматизации». Вопрос автономии для систем, выбирающих действия самостоятельно, — «Автономный агент или с подтверждением».
Проектирование конвейеров с продуманным контролем — часть работы по автоматизации процессов.