Как посчитать выгоду ML-модели до расширения запуска

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

С чем сравниваем

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

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

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

Расчёт одного месяца

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

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

documents, minutes = 10_000, 4
manual, automatic, audit_fraction = 3_000, 7_000, 0.10
audit = round(automatic * audit_fraction)
saved_minutes = documents * minutes - (manual + audit) * minutes
hours = saved_minutes / 60
hour_value, usable_share = 600, 0.40
service_cost = 50_000
expected_errors = automatic * 0.01
error_cost = expected_errors * 300
effect = hours * hour_value * usable_share - service_cost - error_cost
print("saved_hours", hours, "errors", expected_errors)
print("nominal_value", hours * hour_value, "effect", round(effect))
assert hours == 420 and round(effect) == 29800

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

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

Откуда взять качество автоматической ветви

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

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

Проверьте чувствительность перед покупкой ресурсов

Пересчитайте сценарий при меньшей доле автоматизации, более дорогой ошибке и большем объёме аудита. Посмотрите, что именно меняет знак эффекта. Если результат держится только при полном использовании каждого освобождённого часа, сначала подтвердите организационное изменение. Если главная неопределённость — ошибка на новом типе документов, полезнее дополнительная проверка, чем ускорение инференса.

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

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

Следующий шаг в практике

В курсе табличных моделей вы строите корректную валидацию, сравниваете CatBoost и LightGBM, анализируете ошибки и доводите модель до batch-инференса и REST API. Это следующий технический шаг для пилота: получить воспроизводимые прогнозы и отчёт качества, на которых можно основать расчёт полезности своего процесса. Откройте программу платного курса «ML Engineer / Data Scientist: табличные модели в продакшн».

Связанный разбор: как выбирать порог по цене ошибок.