Нужен ли платный источник признаков: как провести ablation по группам

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

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

Что именно выключаем

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

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

Сравнение должно сохранять данные и бюджет

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

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

Обучим две линейные модели

В примере собственный признак x и внешний score описывают разные части целевой величины. Мы действительно обучаем обе модели методом наименьших квадратов через numpy.linalg.lstsq. Синтетические данные помогают проверить процедуру: они не определяют полезность конкретного коммерческого API.

import numpy as np
rng = np.random.default_rng(29)
n = 240
x = rng.normal(size=n)
external = .6*x + rng.normal(size=n)
y = 15 + 2*x + 3*external + rng.normal(0, .8, n)
features = {'internal_only': x[:,None],
            'with_external': np.column_stack([x,external])}
cut = 180
mae = {}
predictions = {}
for name, X in features.items():
    train = np.column_stack([np.ones(cut), X[:cut]])
    test = np.column_stack([np.ones(n-cut), X[cut:]])
    coef = np.linalg.lstsq(train, y[:cut], rcond=None)[0]
    predictions[name] = test@coef
    mae[name] = float(np.abs(y[cut:]-predictions[name]).mean())
    print(name, 'MAE', round(mae[name], 4))
gain = mae['internal_only']-mae['with_external']
monthly_requests, cost_per_request = 10000, .2
print('MAE_reduction', round(gain, 4))
print('monthly_source_cost', monthly_requests*cost_per_request)
assert len(predictions['with_external']) == n-cut
assert gain > 0

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

Переведём улучшение в решение

Пропустите оба набора предсказаний через одинаковое рабочее правило. Например, округление до упаковки и ограничение вместимости склада. Сравните итоговые издержки на одном историческом потоке. Добавьте стоимость запросов к источнику, сопровождения и согласованных последствий его недоступности. Эти величины должны относиться к одному периоду и масштабу использования.

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

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

Отдельно испытайте недоступность и задержку источника. Приёмка планового отказа от подписки и аварийного fallback различается: первая допускает переобучение и полный внутренний pipeline, вторая должна работать сразу при конкретном сбое. Зафиксируйте качество резервного пути и частоту его использования в мониторинге.

В вычисленном примере MAE внутренней модели составляет около 2,5539, полной — 0,7418. Разница равна примерно 1,812 единицы на объект. При условных десяти тысячах запросов по 0,2 стоимость источника составляет две тысячи за месяц. Эти два результата имеют разные единицы и поэтому остаются отдельными строками до расчёта стоимости рабочих ошибок.

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

Платный курс «ML Engineer / Data Scientist: табличные модели в продакшн» даёт практику генерации признаков, сравнения моделей, интерпретации и тюнинга через Optuna. Затем вы собираете воспроизводимый batch-инференс и API. Посмотрите программу курса, чтобы проверять ценность новых данных через контролируемые эксперименты и доводить выбранную конфигурацию до сервиса.

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

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

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