Почему высокая точность может быть плохой инвестицией

В презентации AI-пилота часто появляется одна удобная цифра: «точность 95%». Для руководителя она почти бесполезна без трёх уточнений: насколько редок важный случай, какие именно ошибки совершает система и сколько стоит каждый тип ошибки.

Официальный курс Google по метрикам классификации напоминает: accuracy — доля всех правильных решений — подходит как грубая оценка на сбалансированных данных. При редком целевом событии она вводит в заблуждение. Если только 1% обращений требует особой реакции, система, которая всегда отвечает «обычное обращение», покажет 99% accuracy и пропустит все важные случаи.

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

Поэтому экономика AI-автоматизации начинается не с цены токенов и не с рейтинга модели. Она начинается с матрицы ошибок и владельца, который назначает цену каждому исходу.

Матрица ошибок на языке процесса

Для бинарной маршрутизации есть четыре результата:

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

Precision отвечает на вопрос, какая доля поднятых тревог действительно была важной. Recall показывает, какую долю всех важных случаев система обнаружила. Изменение порога обычно двигает эти показатели в разные стороны: более осторожный порог ловит больше риска, но увеличивает ручную очередь.

Выбор «положительного» класса тоже является управленческим решением. Для обработки входящих писем положительным можно считать либо «можно ответить автоматически», либо «нужно передать специалисту». Второй вариант часто удобнее для риска: recall сразу показывает долю найденных опасных исключений. Если команда не договорилась о направлении метрики, одинаковое слово «точность» может описывать противоположные вещи.

Как перевести ошибки в рубли

Сначала измеряют базовый ручной процесс, затем оценивают пять компонентов:

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

Последний пункт считают как вероятность последствия, умноженную на его стоимость. Например, не каждое пропущенное договорное исключение приводит к убытку. Но если вероятность материального события равна 10%, а средний ущерб — 200 000 рублей, ожидаемая стоимость одного такого пропуска составляет 20 000 рублей.

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

Модельный расчёт для очереди исключений

Представим сервисную компанию, которая обрабатывает 10 000 входящих документов или сообщений в месяц. Только 2%, то есть 200 случаев, требуют специалиста. Полностью ручная обработка занимает в среднем две минуты на элемент. При полной стоимости часа 1 500 рублей базовый труд стоит около 500 000 рублей в месяц.

На проверочной выборке выбранный порог дал такой результат:

  • 190 из 200 важных случаев отправлены специалисту;
  • 10 важных случаев пропущены;
  • 500 обычных случаев ошибочно отправлены на проверку;
  • 9 300 обычных случаев корректно прошли автоматический маршрут.

Общая accuracy составляет 94,9%. Recall важных случаев — 95%. Precision очереди — около 27,5%: большинство поднятых тревог окажутся обычными, но это может быть разумной платой за редкий дорогой пропуск.

Допустим, проверка одного исключения занимает четыре минуты. Очередь из 690 элементов потребует 46 часов, или 69 000 рублей. Выборочный аудит 2% автоматических решений добавит примерно 6,2 часа, или 9 300 рублей. Модель, инфраструктура и поддержка стоят 60 000 рублей в месяц. Если ожидаемый ущерб одного пропуска принят равным 20 000 рублей, десять пропусков добавят 200 000 рублей.

Модельная полная стоимость автоматизированного режима — около 338 300 рублей в месяц. Экономия относительно ручного процесса — около 161 700 рублей до учёта разовой интеграции. Но при ожидаемом ущербе 50 000 рублей на пропуск тот же порог даст стоимость около 638 300 рублей и станет хуже ручной обработки на 138 300 рублей.

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

Архитектура безопасной очереди

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

1. **Приём и нормализацию.** Система проверяет формат, обязательные поля, дубликаты и источник.
2. **Классификацию.** Модель возвращает класс, оценку уверенности и техническую версию модели.
3. **Детерминированные запреты.** Правила без участия LLM останавливают операции по сумме, типу клиента, персональным данным или ключевым словам.
4. **Маршрутизацию по зонам.** Безопасная зона допускает автоматический черновик, средняя идёт в обычную очередь, критическая — приоритетному специалисту.
5. **Человеческое решение.** Интерфейс показывает исходный объект, предложение модели, причину маршрута и допустимые действия.
6. **Исполнение.** Отдельный сервис выполняет только подтверждённое или заранее разрешённое действие.
7. **Журнал и обратную связь.** Сохраняются порог, результат, исправление, время проверки и фактическое последствие.

Очередь должна иметь SLA и ограничение размера. Если поток превысил способность команды проверять исключения, система обязана перейти в безопасный режим: задержать автоматизацию, расширить ручной маршрут или временно отключить действие. Незамеченная очередь — это не экономия, а отложенный ручной труд.

Какие данные и интеграции потребуются

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

Минимальные интеграции:

  • источник документов, писем или заявок;
  • справочник клиентов и договорных условий;
  • очередь задач с приоритетами и сроками;
  • интерфейс подтверждения и исправления;
  • журнал версий модели, порогов и правил;
  • аналитика по TP, FP, TN, FN, времени и последствиям;
  • ручной маршрут при недоступности модели.

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

Где уместны локальная модель, RAG и агент

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

**RAG** полезен, когда решение зависит от актуального регламента или условий конкретного договора. Поиск должен возвращать разрешённые документы и их версии. Он не заменяет порог риска: найденный фрагмент тоже может быть неполным или неверно применённым.

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

Пилот с экономическими воротами

**Неделя 1.** Опишите положительный класс и стоимость каждого исхода. Замерьте ручное время и долю редких случаев.

**Неделя 2.** Разметьте выборку и сравните модель с простым правилом и человеческой базой. Проверьте precision и recall отдельно по важным сегментам.

**Неделя 3.** Запустите теневой режим. Модель предлагает маршрут, но рабочий процесс остаётся ручным. Собирайте ошибки, исправления и время.

**Неделя 4.** Рассчитайте несколько порогов. Для каждого покажите объём очереди, пропуски, стоимость проверки, инфраструктуру и ожидаемый ущерб.

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

Что взять руководителю

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

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