Ноль ошибок — не нулевой риск

Команда проверила ИИ на 50 документах, не увидела ошибок и уже обсуждает отключение ручной проверки. Робот-стажёр Внутрик мысленно заказал себе табличку «отличник». Но в выборке из 50 примеров вполне могут не встретиться редкие ошибки, дорогие для бизнеса. Для пилота это повод продолжить проверку, а не обещать безошибочную обработку заявок, счетов или договоров.

NIST в работе об оценке ИИ отдельно различает результат на конкретном наборе тестов и ожидаемое качество на похожих будущих задачах. Второе нельзя получить простым переименованием первого: надо объяснить, как отбирались примеры и какова неопределённость оценки. Для руководителя это означает, что фраза «на тестах всё верно» пока не является ответом на вопрос «сколько ошибок будет в месяц».

Что именно считать ошибкой

До запуска модели задайте единицу проверки. Для извлечения реквизитов это может быть документ целиком, отдельное поле либо событие «система отправила неверный платёж без подтверждения». Это разные показатели. Один счёт с неверным ИНН и верной суммой может дать высокую точность по полям, но неприемлемый операционный риск.

Составьте короткую шкалу:

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

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

Сколько наблюдений даёт ноль ошибок

Покажем простой модельный расчёт, а не универсальный сертификат надёжности. Пусть каждый тест независим, отобран из той же стабильной совокупности, что и будущие задачи, критерий ошибки закреплён заранее, а система между тестами не меняется. Если на n испытаниях ошибок нет, точная односторонняя верхняя 95-процентная граница для неизвестной вероятности ошибки равна 1 − 0,05^(1/n). Это следует из биномиальной модели, описанной в статистических материалах NIST.

Получается примерно следующее:

  • 50 проверок без ошибок: верхняя граница около 5,8%;
  • 100 проверок без ошибок: около 3,0%;
  • 300 проверок без ошибок: около 1,0%.

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

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

Как собрать проверку без дорогой лаборатории

Для малого бизнеса разумно начать с одного узкого процесса: например, черновик ответа на типовые обращения или извлечение полей из счетов. Зафиксируйте версию модели, промпт, правила RAG-поиска, справочники и настройки. Сотрудники, которые знают исходный процесс, размечают правильный результат и тип ошибки до того, как увидят ответ ИИ, где это возможно.

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

На этапе «быстрого дыма» 30–50 кейсов помогают выявить явные сбои архитектуры. Но это не основание для заявления о малой вероятности редкой критической ошибки. Для более строгой оценки потребуется больше независимых случаев в каждой важной группе; если данных мало, оставьте человеку подтверждение на критических действиях. У RAG-системы проверяйте не только ответ, но и найденный первоисточник, актуальность документа и права доступа. У агента — отдельно корректность предложенного действия и факт его разрешённого исполнения.

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

Модельный бюджет: 300 кейсов × 4 минуты экспертной проверки = 20 часов. Если для внутреннего расчёта принять полную стоимость часа специалиста 1 500 ₽, ручная оценка составит 30 000 ₽. Это не рыночная цена и не обещание результата: сюда не входят подготовка эталонов, исправление процесса, вычисления, инфраструктура и повторные тесты. В компании с дорогими ошибками такая проверка может стоить меньше одной неверной операции; в низкорисковом сценарии она может быть избыточной.

Считайте стоимость не за запрос к модели, а за принятый результат: затраты на модель или API, интеграцию, человеческую проверку, возвраты, исправления и поддержку разделите на число корректно завершённых операций. Подход к экономике единицы результата описывает FinOps Foundation. Если автоматизация экономит минуту ввода, но добавляет две минуты проверки, красивый показатель «цена токена» не отражает результата.

Сравните три режима на одинаковых кейсах: полностью ручной процесс, ИИ как черновик с подтверждением человеком и частичная автообработка только низкорисковых случаев. Для каждого измерьте время, цену исправлений и число пропущенных критических ошибок. Локальная модель может быть уместна, если документы нельзя выводить во внешний API или объём нагрузки оправдывает собственный контур; но локальность сама по себе не повышает точность и не отменяет затрат на сопровождение. Пилот должен отвечать на вопрос о выгоде конкретного процесса, а не о модности способа запуска.

Решение на следующей неделе

Назначьте владельца процесса и владельца проверки. Выберите один тип документов, опишите 3–5 критических полей или действий, соберите первую разнородную выборку и зафиксируйте порог допуска до теста. Сохраните версии входных данных, эталонов, модели и правил, чтобы через месяц сравнивать одинаковое с одинаковым. Если на 50 кейсах всё прошло гладко, расширяйте выборку и оставляйте ручное подтверждение там, где цена ошибки высока. Если результат плохой, выясняйте причину по группам: возможно, нужен не новый ИИ, а чище справочник или надёжнее интеграция.

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