6 октября 2026Команда Сарнас

ML в страховании: разрозненные данные, дрейф признаков и причинные вопросы

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

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

Что именно ломается на практике

Три проблемы называются самыми частыми.

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

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

Третья — разочарование в ML из-за малого числа признаков: модель на 10 признаках не считает точнее старого способа расчёта.

Порядок действий: сначала признаки, потом данные, потом алгоритм

Рекомендуемая последовательность обратна привычной.

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

Затем собирают данные: единое хранилище, куда данные из всех систем стекаются в сыром виде с общими ключами связывания (data lake), и витрину признаков (feature store) с одинаковой логикой расчёта для обучения и боевого применения. Это долго и не продаётся красиво, но основной эффект находится именно здесь.

Только после этого выбирают алгоритм. На широком признаковом пространстве ML окупается, на десяти полях — нет, и тюнинг гиперпараметров этого не меняет.

Объяснимость и причинные вопросы

Вопрос объяснимости решают заранее: в регулируемых видах модель, которая не умеет обосновать решение, может получить вопросы от регулятора — ни ст. 11 Закона об организации страхового дела, ни ст. 10 293-ФЗ об актуарной деятельности не отменяли.

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

Корреляция против причинности

Обычная ML-модель отвечает на вопрос «что произойдёт». Каузальные модели обещают ответить на вопрос «что произойдёт, если мы вмешаемся». Разница принципиальна: статистическая закономерность разрушается, как только на неё начинают давить с целью управления.

Аппарат для причинных вопросов существует: causal trees, causal forests, uplift-моделирование, double machine learning, x-learner. Но чтобы вытащить причинный эффект из наблюдательных данных — тех, что накопились сами, без эксперимента, — нужно допущение об отсутствии неучтённых конфаундеров: что все переменные, влияющие одновременно и на «вмешательство», и на результат, наблюдаются. Смещение от скрытых конфаундеров не уменьшается с ростом выборки.

Каузальные методы требуют аккуратной валидации из-за переобучения: в одном исследовании на канадском страховом наборе данных causal forest показал высокое качество на обучающей выборке, но на валидации и вне выборки — около нуля.

Валидация на временных данных

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

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

Правило #33 «Rules of ML» требует обучать модель на данных до определённой даты, а тестировать на данных, появившихся после неё: если модель построена на данных до 5 января, тестировать её надо на данных с 6 января и позже. Измерение на более поздних данных лучше отражает работу системы в продакшене. Ожидается, что качество на новых данных будет ниже, но не радикально хуже. Из-за дневных эффектов средние показатели могут не совпасть, но AUC должен быть достаточно близким.

Training-serving skew

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

Лучшее решение — явно мониторить skew, чтобы изменения в системе и данных не вносили его незаметно. Чтобы обучение соответствовало обслуживанию, сохраняют набор признаков, используемых при обслуживании, и направляют их в лог для использования при обучении. Даже если это нельзя сделать для каждого примера, стоит делать это для небольшой доли, чтобы проверять согласованность между обслуживанием и обучением.

Группировка и стратификация в кросс-валидации

Обычный KFold делит все образцы на k фолдов равного размера, обучает на k−1 фолдах, а оставшийся использует для теста. GroupKFold разбивает данные по группам так, чтобы один и тот же субъект не попадал одновременно в обучение и тест: каждый субъект находится в отдельном тестовом фолде, и один и тот же субъект никогда не оказывается и в тесте, и в обучении. Тестовые наборы GroupKFold, как и у KFold, образуют полное разбиение всех данных.

StratifiedGroupKFold объединяет стратификацию по классам с удержанием группы целиком в одном сплите. Это полезно при несбалансированных данных, когда один GroupKFold даёт перекошенные разбиения.

GroupShuffleSplit ведёт себя как комбинация ShuffleSplit и LeavePGroupsOut и генерирует последовательность случайных разбиений, в каждом из которых часть групп откладывается. Каждый train/test-сплит выполняется независимо, без гарантированной связи между последовательными тестовыми наборами.

LeaveOneGroupOut оставляет в тесте образцы одной конкретной группы, информация о группах передаётся массивом. Обучающая выборка состоит из всех образцов, кроме относящихся к этой группе, что эквивалентно LeavePGroupsOut с n_groups=1 и GroupKFold с n_splits, равным числу уникальных меток. LeavePGroupsOut удаляет образцы, относящиеся к P группам, перебирая все возможные комбинации, поэтому при P>1 тестовые наборы перекрываются. Такие схемы полезны, когда есть несколько экспериментов, или когда группы — это год сбора образцов, что позволяет делать кросс-валидацию по временным разбиениям.

Метрики по классам и сегментам

Средняя точность скрывает дорогие ошибки, поэтому метрики считают по отдельным классам. Функция precision_recall_fscore_support вычисляет precision, recall, F-меру и support для каждого класса. Чтобы получить метрики отдельно по каждому классу, задают average=None — тогда возвращается массив со значением для каждого класса. Разбиение по сегментам задаётся параметром labels, который перечисляет метки для включения в отчёт. classification_report строит текстовый отчёт с основными метриками классификации.

Собственные метрики и мультиметрическая оценка

Собственную функцию оценки создают через make_scorer, передавая python-функцию и параметр greater_is_better. Если функция возвращает loss, указывают greater_is_better=False, и scorer инвертирует знак выхода, чтобы соблюсти соглашение кросс-валидации о том, что большее значение лучше. Для метрик, требующих вероятностей, задают response_method="predict_proba"; если функция может использовать и решающие значения, и вероятности, передают список, и scorer возьмёт первый доступный метод в указанном порядке.

Несколько метрик одновременно в cross_validate задают через параметр scoring тремя способами: как итерируемое из строковых имён метрик, как список предопределённых имён scorer'ов, либо как словарь, отображающий имя scorer'а на функцию оценки. При мультиметрической оценке возвращается словарь с ключами вида test_<scorer1_name>, test_<scorer2_name>, fit_time, score_time. При return_train_score=True добавляются и train_-ключи.

Матрица ошибок, ROC и Brier score

confusion_matrix строит матрицу ошибок, где каждая строка соответствует истинному классу, а элемент i,j — число наблюдений, фактически принадлежащих группе i, но предсказанных как группа j. Для бинарных задач из неё получают количества истинно отрицательных, ложноположительных, ложноотрицательных и истинно положительных результатов. Доля ложноположительных результатов вычисляется как fp / (fp + tn).

roc_curve строит кривую ROC, откладывая долю истинно положительных среди положительных против доли ложноположительных среди отрицательных при разных порогах. Функция требует истинные бинарные значения и оценки цели — вероятности положительного класса или неотпороговые решающие значения.

brier_score_loss вычисляет Brier score — строго правильное правило оценки, равное средней квадратичной ошибке между истинными метками и вероятностными предсказаниями. Чем ниже значение, тем лучше оценки вероятностей, и лучший результат достигается только когда предсказанные вероятности равны истинным. Для бинарного случая Brier score обычно делится на два и лежит в диапазоне [0,1]; параметр scale_by_half выбирает одно из двух определений.

Мониторинг: свежесть, проблемы до экспорта, тихие отказы

При запуске ML-системы в первую очередь рекомендуют мониторить свежесть модели и проблемы до экспорта, а не только метрики модели. Правило #8 требует знать требования к свежести системы: насколько падает качество, если модель устарела на день, неделю или квартал, — от этого зависят приоритеты мониторинга. Правило #9 требует обнаруживать проблемы до экспорта моделей и делать sanity checks прямо перед экспортом, например проверять разумность работы на отложенных данных или AUC. Причина в разнице последствий: проблемы неэкспортированной модели требуют лишь email-алерта, а проблемы пользовательской модели могут требовать пейджера.

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

Проверка, что качество не случайно

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

Для надёжных результатов n_permutations должно быть больше 100, а cv — от 3 до 10 фолдов. Вычисление использует полный перебор и внутренне обучает (n_permutations + 1) * n_cv моделей, поэтому применимо только к малым наборам данных; параметр n_jobs распараллеливает вычисления.

Интерпретируемость

Правило #14 советует начинать с интерпретируемой модели, потому что это упрощает отладку. Линейная, логистическая и пуассоновская регрессии напрямую мотивированы вероятностной моделью, и каждое предсказание интерпретируется как вероятность или ожидаемое значение. Это делает их проще для отладки, чем модели с целями, напрямую оптимизирующими точность классификации или ранжирования. Например, если вероятности при обучении отклоняются от предсказанных, это отклонение может выявить проблему. С простыми моделями легче справляться с петлями обратной связи.

Книга Christoph Molnar «Interpretable Machine Learning» посвящена тому, чтобы делать модели и их решения интерпретируемыми, поскольку компьютеры обычно не объясняют свои предсказания, что может вызывать проблемы — от вопросов доверия до незамеченных ошибок. Читатель знакомится с простыми интерпретируемыми моделями, такими как деревья решений и линейная регрессия. Основной фокус — на модельно-агностических методах интерпретации чёрных ящиков: одни методы, например LIME и значения Шепли, объясняют отдельные предсказания, а другие, например permutation feature importance и accumulated local effects, дают представление об общих связях между признаками и предсказаниями. Книга также представляет методы, специфичные для глубоких нейронных сетей. Все методы объясняются подробно и критически обсуждаются: как они работают, их сильные и слабые стороны и как их интерпретировать.

Ограничения и открытые вопросы

Стоимость ложных срабатываний и пропущенного ущерба напрямую не вычисляется — показан только пример вычисления доли ложноположительных результатов. Соотношение ROC AUC и Brier score с реальной полезностью модели при несбалансированных классах не раскрыто.

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