Пока модель едет в прод, бизнес теряет миллиарды

Лайфхаками, как этого избежать, на Scoring Day поделился Александр Шишорин, ex-руководитель по моделированию в ОКБ.

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

При этом в политиках управления модельным риском длинный time-to-market почти нигде не фигурирует как риск, хотя каждые 1–2 года банки могут терять огромные деньги всего лишь из-за плохо выстроенной операционки.

Как же сократить лаг между появлением данных в проде и включением модели в бизнес-процесс?
1. Сдвигайте выборку с целевой переменной максимально близко к текущему моменту.
Например, если таргет — 90+ на 12 месяцев, двигайте его как можно ближе к today. Дальше:
• проверяйте модель на коротких целевых переменных;
• делайте гигиеническую проверку: качество на длинном и коротком таргете должно быть сопоставимым.
Полезно также проверить, что модели на коротких таргетах «разваливаются» быстрее, чем на длинных.

2. Жестко разделяйте R&D и RUN.
Подключение новых источников, новые подходы к моделированию, feature engineering, миграции данных и системы исполнения моделей — все это зона R&D. Такие задачи нужно вести параллельно основному процессу и интегрировать в RUN примерно раз в 6–12 месяцев.

А сам RUN должен быть максимально автоматизирован, с минимальным участием ЛПР в итерациях по приемке моделей.

3. Стройте инфраструктуру фичей.
Обычно все говорят только про Feature Store, но по факту нужны две вещи:
• Feature Store;
• интерфейсы для использования фичей.

Критично вывести в прод длинный список фичей: 50, 100, 300, 4000 — сколько получится. Именно это радикально сокращает время подготовки данных и автоматизирует сбор продуктивных данных на ретродате. Даже если Feature Store еще не идеален, длинный список фичей в проде плюс интерфейсы — это уже половина решения.

Что это дает на практике:
• базовые модели с Gini 50–70 по сегментам;
• ещё +5–15% качества при донастройке под задачи конкретного клиента;
• более понятные модели;
• возможность быстро делать drill-down при деградации;
• постоянный поток гипотез для улучшений.

Подход можно описать одной фразой: «Делай базу до отказа»
Feature engineering и длинный список фичей — это дорого и долго, но именно они позволяют быстро строить сильные модели.

Что интересного можно делать с длинным списком фичей
Когда у вас 3000 фичей, открываются новые задачи. Например:

Задача 1. Модель работает хорошо в сегментах A и B, но плохо в C
Полный перебор фичей займет вечность. Но можно начать с простого:
• корреляций;
• анализа различий Gini фичей в разрезе сегментов.

Это быстро покажет, куда идти дальше: во feature selection, feature engineering или заняться перевзвешиванием.

Задача 2. Быстрый baseline без нейросетей, долгого отбора фичей и тяжелых вычислений.

Здесь можно использовать метод главных компонент для сжатия размерности. В сыром виде он работает плохо, потому что среди 3000 фичей много мусора. Но если сначала кластеризовать фичи по однофакторным характеристикам (Gini, его вариация, drop-out-of-time и т.д.), можно потерять всего около 3% качества, но получить baseline за 1–3 дня.

Это позволяет быстро понять целевой уровень качества и поставить задачу дата-сайентисту.

Задача 3. Горизонтальное федеративное обучение между двумя DS-командами на домене кредитных историй.

Проблема стандартная: у разных команд разные списки фичей. Хотя домен один — кредитная история.

Можно «подружить» два списка через эмбеддинги: сначала моделировать не дефолт, а фичи одной команды через фичи другой. После этого можно переходить к федеративному обучению.

Главный вывод
Работа с длинными списками фичей кажется скучной. Но на самом деле — это один из самых мощных источников эффективности.

Но только если:
• фичи находятся в проде;
• их можно прогонять на ретроспективе 3–5 лет.