GLM как фундамент: почему он до сих пор держит тарификацию
Градиентный бустинг выучивает зависимости сам, GLM требует, чтобы их задали руками. Звучит как аргумент в пользу бустинга — но только если в данных есть что выучивать. В тарификации массовых видов в модель обычно попадают 6–15 признаков из той же анкеты, на которой построен действующий тариф: пол, возраст, стаж, регион, мощность. Актуарии за двадцать лет перебрали эти поля и их парные взаимодействия — молодой водитель на мощной машине, частые обращения при близости клиники к офису. Бустинг на тех же шести полях находит примерно то же самое, а прирост точности съедается стоимостью мониторинга дрейфа и объяснений регулятору.
Настоящее преимущество бустинга — не в алгоритме как таковом, а в способности работать с широким пространством признаков и вытаскивать сочетания из десятка переменных, каждую из которых аналитик не станет выписывать вручную. Но это преимущество включается только тогда, когда признаки есть. Поведение при покупке, история отношений с компанией, детали убытков, внешние источники, телематика — сотни переменных вместо десяти. Без них смена алгоритма не даёт ничего: разница между GLM и бустингом на шести полях остаётся в пределах погрешности.
Отсюда практический вывод: вопрос «GLM или бустинг» поставлен неверно. Оба стоят на одном фундаменте — теории вероятностей и матстатистике, новой науки за тридцать лет не появилось. Сначала считайте, сколько признаков на клиента доступно сегодня и сколько можно добавить малой кровью. Эта цифра и определяет, есть ли смысл менять алгоритм. На широком признаковом пространстве ML окупается; на десяти полях — нет, и тюнинг гиперпараметров этого не изменит.
Ловушка узкого признакового пространства
Попробуйте ответить на простой вопрос: какие закономерности может найти алгоритм в поле, значение которого вы уже двадцать лет считаете вручную? Никаких. Именно это и происходит, когда градиентный бустинг обучают на тех же анкетных признаках, что лежат в основе действующего тарифа.
Дело не в алгоритме. Бустинг честно ищет структуру в том пространстве, которое ему дали. Если пространство узкое, искать нечего — модель воспроизводит зависимости, известные актуарию наизусть: молодые водят рискованнее, стаж снижает частоту, женщины чаще обращаются в поликлиники, близость медучреждения к офису поднимает число визитов. Взаимодействия второго порядка внутри такого набора тоже давно перебраны вручную, потому что их немного и они на виду.
Отсюда распространённый сценарий: полгода работы, лицензии, команда дата-сайентистов, а на выходе прирост точности в пределах погрешности. Дальше ищут виноватых. Хотя причина в другом — модель поставили в телегу и ждали, что она станет болидом. Мощный двигатель тут ни при чём.
И тюнинг гиперпараметров эту ситуацию не переворачивает. Он меняет, как алгоритм обходит уже имеющееся пространство признаков, но не расширяет его. Перебор параметров не создаст переменную, которой нет в данных. Если шесть полей анкеты — это всё, что подано на вход, никакая сетка поиска не вытащит из них сигнал, которого там не лежит.
Данные, разбросанные по системам: где рвётся клиент
На слайде — блок «ML-модель» в центре схемы. На календаре — шесть месяцев. По факту модель подключается последней, а всё остальное время проект стоит на двух блоках, которые на слайде нарисованы стрелочками между прямоугольниками.
Первый — источники. Клиент живёт в учётной системе, в мобильном приложении, в колл-центре, в веб-аналитике маркетинга. В каждой системе он опознан по-своему: в одной — по паспорту, в другой — по id личного кабинета, в третьей — по номеру полиса. Данные по одному человеку не сшить, потому что сшивать их нечем. Хуже того, связь теряется внутри одного вида страхования: в одном договоре человек — страхователь, в другом — застрахованный, в третьем — водитель, допущенный к управлению, в четвёртом — выгодоприобретатель. Формально это один клиент, фактически — четыре несвязанные записи.
В ДМС источников ещё больше: реестры услуг от клиник, звонки в медпульт, телемедицина, личный кабинет, CRM, сайт. Каждый источник по отдельности ценен, вместе они не сшиты или сшиты криво. Любой ML-проект утыкается именно в это.
Второй блок — единое хранилище и витрина признаков. Нужен data lake, куда данные из всех систем стекаются в сыром виде с общими ключами связывания. Многие вместо озера делают свалку данных и называют её хранилищем. Сверху — feature store: место, где на каждого клиента лежат уже посчитанные переменные, с версиями и механикой обновления. Ключевое требование — одинаковая логика расчёта признака на обучении и в проде. Если она расходится, модель на тестах показывает одно, в бою другое, и заметить это трудно: ошибок нет, просто качество несопоставимо ниже.
Продать такой проект тяжело. Долго, скучно, на слайде не выглядит инновацией. Поэтому продают модель. Модель на десяти признаках. Она не считает точнее старого калькулятора — и дальше весь ИИ объявляют профанацией. Материал разбирает этот сценарий подробно: Почему ML-модель в андеррайтинге находит только то, что вы и так знали.
Data lake, витрина признаков и расхождение обучения с продом
Что делает озеро данных озером, а не свалкой? Формально оба варианта — это папка, куда стекаются выгрузки из учётных систем, приложения, колл-центра и веб-аналитики. Разница в наличии сквозных ключей связывания: в озере записи про одного человека сходятся в одну точку, в свалке они просто лежат рядом. Автор статьи на Хабре прямо предупреждает: многие компании вместо data lake строят свалку и продолжают считать, что хранилище у них есть.
Дальше начинается слой, от которого зависит, доедет ли модель до прода. Это feature store — витрина признаков. На каждого клиента здесь лежат уже посчитанные переменные, и у каждой есть механика обновления, версия и, что важнее всего, одна и та же логика расчёта для обучения и для боевого применения. Именно на этом пункте стоит остановиться.
Представьте, что при обучении возраст клиента вы брали на дату оформления полиса, а в проде система подставляет текущий возраст. Или в обучающей выборке стаж считался на начало договора, а в проде — на конец. Никаких ошибок система не выдаёт, пайплайн не падает, алерты молчат. Просто модель на тестах показывает одно, а в бою — совсем другое, и качество падает незаметно, потому что сравнивать не с чем. Расхождение между train- и prod-логикой признака — одна из самых частых причин такого разрыва, и заметить её трудно именно из-за тишины в логах ().
Отсюда практический вывод для команды. Порядок работ выглядит так: сначала посчитать, сколько переменных на клиента доступно сегодня и сколько можно добавить малой кровью. Эта цифра и решает, есть ли смысл вообще менять алгоритм. Потом — долгий этап сборки: единое хранилище, сквозные ключи, витрина признаков с единой логикой. И только после этого выбирать модель. На широком признаковом пространстве ML окупается; на десяти полях из анкеты — нет, и тюнинг гиперпараметров этого не исправит.
«Что произойдёт» и «что произойдёт, если вмешаться»
Обычная ML-модель отвечает на вопрос «что произойдёт». Каузальная — на вопрос «что произойдёт, если мы вмешаемся». Разница между этими формулировками стоит денег, и в андеррайтинге это особенно заметно.
Возьмём франшизу. Модель показывает: клиенты с франшизой реже заявляют убытки. Логичный следующий шаг — предложить франшизу всем и ждать падения убыточности. Только обычная модель такой вывод не подтверждает. Она видит связь и молчит о её природе: то ли франшиза дисциплинирует поведение, то ли её выбирают те, кто и без неё уверен в своей аккуратности и просто хочет платить меньше. Если верно второе, при массовом внедрении эффект растворится — осторожные клиенты закончатся, а франшизу начнут брать все подряд.
Похожая развилка с телематикой: полисы с устройством показывают лучшую убыточность, но устройство ли меняет манеру вождения — или его ставят люди, которые и так ездили аккуратно и охотно взяли скидку? Общая причина, влияющая и на «вмешательство», и на результат, — это конфаундер. Пока аккуратность водителя не измеряется, никакая математика не отделит эффект устройства от эффекта самоотбора: модель выдаст число, число будет смещённым, а выглядеть будет убедительно, с доверительным интервалом и p-value.
Отдельно стоит сказать про рост выборки. Обычная статистическая погрешность падает, когда данных становится больше, — это усваивают на первом курсе. Смещение от неучтённого фактора не падает вообще. Миллион полисов вместо ста тысяч даст лишь более узкий доверительный интервал вокруг неверного значения, и аргумент «дайте больше данных, модель разберётся» здесь не работает.
Инструменты для причинных вопросов существуют и применяются в страховании давно: causal trees и causal forests, uplift-моделирование, double machine learning, x-learner. Работы по uplift-моделированию удержания клиентов выходили ещё в 2012 году, а причинностный подход к оценке ценовой эластичности в автостраховании публиковался в 2014-м. Новизна здесь не в методах, а в том, что их вынесли на витрину как прорыв.
Главное ограничение — допущение об отсутствии неучтённых конфаундеров: предполагается, что все переменные, влияющие одновременно и на вмешательство, и на результат, вы наблюдаете. В литературе это называют ахиллесовой пятой неэкспериментальных исследований, и из самих данных допущение принципиально не проверяется — его либо обосновывают содержательно, либо принимают на веру. Uplift-моделирование надёжнее всего работает поверх данных проведённых экспериментов, а не поверх накопленной истории. Если есть возможность назначить условие случайно — например, протестировать скидку на случайной подвыборке клиентов, — оценки становятся гораздо устойчивее к скрытым факторам.
Крысиные хвосты и акулы: почему большая выборка не спасает от смещения
Допущение об отсутствии неучтённых конфаундеров — единственное звено в каузальной цепочке, которое нельзя проверить статистикой. Его формулировка проста: вы наблюдаете все переменные, влияющие одновременно и на «вмешательство», и на результат. В исследовательской литературе это место называют ахиллесовой пятой неэкспериментальных работ. Из самих данных его не вывести — либо обосновываете содержательно, либо принимаете на веру.
Вернёмся к телематике. Если аккуратность водителя нигде не зафиксирована, а она двигает и решение поставить устройство, и частоту убытков, никакая математика не отделит эффект устройства от эффекта самоотбора. Модель всё равно выдаст число — с доверительным интервалом и p-value, — но это число будет смещённым.
Здесь и прячется ловушка, в которую легко угодить. Обычная статистическая погрешность с ростом выборки падает — это усваивают на первом курсе. Смещение от неучтённого фактора не падает вообще. Миллион полисов вместо ста тысяч даст лишь более узкий интервал вокруг неверного значения. Аргумент «наберите больше данных, и модель разберётся» в этом случае не работает: вы просто повышаете уверенность в неправильном ответе.
С каузальными методами связана и отдельная головная боль — переобучение, которое здесь устроено хитрее, чем у обычных моделей. В работе Belbahri, Gandouet и Kazma (2020) на канадском страховом наборе causal forest показал коэффициент Qini около 5,9 на обучающей выборке и почти ноль — на валидации и вне выборки. Модель отлично объясняла то, на чём училась, и не переносила это на новые данные. Метод не плохой — он требует предельно аккуратной валидации.
Единственный способ получить чистый ответ на причинный вопрос — рандомизация. Всё каузальное моделирование на наблюдательных данных есть лишь попытка приблизиться к тому, что даёт эксперимент. Если есть возможность назначить условие случайно — например, проверить скидку на случайной подвыборке клиентов, — оценки становятся несопоставимо надёжнее. Uplift-модели лучше всего работают поверх данных проведённых экспериментов, а не поверх накопленной истории.
Что делать: порядок шагов от данных к алгоритму
Начните с арифметики, а не с выбора алгоритма. Посчитайте, сколько переменных на клиента у вас есть прямо сейчас и сколько вы можете добавить без больших затрат. Эта цифра и решает, стоит ли вообще трогать модель. Если на руках те же поля из анкеты, что и двадцать лет назад, смена алгоритма ничего не изменит: бустинг отработает примерно те же зависимости, что актуарии уже выжали руками, а прирост точности съедят затраты на поддержку, мониторинг дрейфа и объяснения регулятору.
Дальше — хранилище. Данные из учётной системы, приложения, колл-центра и веб-аналитики должны стекаться в одно место, в сыром виде и с общими ключами связывания. Клиента часто не сшивают даже внутри одного вида страхования: в одном договоре он страхователь, в другом — застрахованный, в третьем — водитель, допущенный к управлению. Пока это не склеено единым идентификатором, ни один алгоритм не увидит общей картины.
Поверх хранилища нужна витрина признаков — уже посчитанные переменные с версиями и единой логикой расчёта для обучения и для боевого применения. Тут кроется тихая ошибка: если признак при обучении считался иначе, чем в проде, модель будет работать без сбоев, но качество окажется несопоставимо хуже тестового. Заметить это трудно именно потому, что никаких ошибок система не выдаёт.
Схема проекта выстраивается линейно: источники → data lake → витрина признаков → модель. Модель подключается последней, а основные сроки уходят на два средних блока. Соблазн продать руководству «внедрение ИИ» на десяти признаках велик, но именно там проект и утыкается в потолок. «Озеро данных» тоже легко превратить в свалку — формально хранилище есть, а связанных данных по-прежнему нет.
Алгоритм выбирайте только после того, как признаковое пространство расширено. Широкий набор полей — это то, где ML действительно окупается: он подхватывает взаимодействия, до которых человек не додумается, включая сочетания десятка слабых факторов. На узком наборе тюнинг гиперпараметров не заменит данных.
Отдельно решите вопрос объяснимости. В регулируемых видах модель, не умеющая обосновать решение, рискует получить вопросы от регулятора — ссылки на ст. 11 Закона об организации страхового дела и ст. 10 293-ФЗ об актуарной деятельности никто не отменял.
И последний шаг касается причинных вопросов. Если по итогам вы собираетесь менять тариф, вводить скидку или условие, заложите возможность случайного назначения хотя бы на подвыборке. Оценки на данных эксперимента надёжнее любых выводов из накопленной истории, где вмешательство и результат могли определяться общим скрытым фактором.
Выводы: где ML окупается, а где нет
Три вещи, которые стоит унести из этой статьи.
Первое: алгоритм — не узкое место. Разрыв между GLM и бустингом в тарификации без изменения набора данных лежит в пределах погрешности. Всё, что модель может выжать из шести–пятнадцати полей анкеты, актуарии уже выжали руками за двадцать лет.
Второе: причинный вывод не выводится из истории автоматически. Смещение от неучтённого фактора не исчезает с ростом выборки — миллион полисов даст лишь более узкий интервал вокруг неверной цифры. Чистое решение даёт только рандомизация.
Третье: инструмент причинного анализа рабочий, но с очерченной зоной. Causal forests и uplift-модели уместны там, где есть эксперимент или где вы можете содержательно обосновать полноту наблюдаемых факторов. Обещание «модель сама найдёт причину в ваших данных» — из презентации, а не из практики.
Практический совет: прежде чем подписывать бюджет на ML-проект, проверьте два артефакта — есть ли в компании единое хранилище, куда все источники стекаются в сыром виде с общими ключами, и есть ли витрина признаков с одинаковой логикой расчёта для обучения и для боевого применения. Если хотя бы одного нет — начинайте с него, а не с выбора алгоритма.
Источник: Хабр
