Модель для очереди проверок: как оценить качество при лимите в 100 заявок

Если специалисты проверяют только 100 заявок в день, качество модели нужно оценивать на этой очереди. Покажем расчёт precision@k, охвата нарушений и стабильный порядок при одинаковых баллах.

Решение ограничивает пропускная способность

Антифрод-модель расставляет заявки по подозрительности. Служба проверки может разобрать сто случаев за смену. В такой системе изменение порога с 0,7 на 0,6 имеет прямое операционное последствие: очередь способна вырасти в несколько раз. Порог, найденный на прошлом месяце, не гарантирует прежнего объёма в новом потоке.

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

Здесь k относится к объектам очереди. Это отличается от многоклассовой top-k accuracy, где для одного объекта проверяют попадание правильного класса в несколько предложенных вариантов. Для очереди заявок достаточно сортировки строк и подсчёта известных исходов.

Посчитаем очередь на маленьком дне

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

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

items = [
    ("a", .95, 1), ("b", .90, 0), ("c", .90, 1),
    ("d", .80, 1), ("e", .40, 0), ("f", .10, 0),
]
k = 3
queue = sorted(items, key=lambda x: (-x[1], x[0]))[:k]
hits = sum(x[2] for x in queue)
positives = sum(x[2] for x in items)
precision = hits / len(queue)
recall = hits / positives
print([x[0] for x in queue])
print(f"precision@{k}={precision:.3f}; recall@{k}={recall:.3f}")
assert hits == 2 and positives == 3
assert [x[0] for x in queue] == ["a", "b", "c"]

В очередь попадут a, b и c. Две полезные проверки из трёх дают precision 0,667, а два найденных нарушения из трёх — recall 0,667. Заявка d осталась за границей мощности. Если сотрудники могут проверить четвёртую заявку, охват вырастет до единицы, но это уже другой режим работы. Сравнивайте модели при одинаковом k и на одинаковом потоке.

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

Баллы моделей могут иметь разный масштаб: одна выдаёт 0,8, другая 0,3 на тех же объектах. Для фиксированной очереди важен порядок, поэтому сравнивайте состав выбранных заявок и известные исходы. Если затем понадобится автоматическое действие по вероятности, отдельно проверяйте калибровку и цену ошибки.

После выбора версии сохраните id поступивших заявок, баллы, дату формирования очереди и версию модели. Это позволит позже присоединить результаты проверки и восстановить, почему конкретная заявка была выбрана. Когда доля проблем меняется, один и тот же precision при одинаковом k может означать совсем другую полноту; оба числа нужны рядом.

Для следующего шага пригодится выбор порога по стоимости ошибок.

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

Продолжить на практике

  • ML Engineer / Data Scientist: табличные модели в продакшн ↗

    Практический курс для тех, кто хочет получить навыки ML Engineer / Data Scientist на реальных табличных задачах. В курсе Вы не просто обучите CatBoost/LightGBM, а соберёте полноценный production-style пайплайн: подготовка данных, feature engineering (генерация признаков), корректная валидация, защита от leakage (утечек), тюнинг через Optuna, интерпретация через SHAP, batch-инференс и REST API для предсказаний.