Москва: проверенные б/у ноутбуки с гарантией и проверкой перед оплатой
+7 906 722-94-45

Главная → Статьи → Интерпретируемость моделей: SHAP на практике

Интерпретируемость моделей: как объяснять предсказания с помощью SHAP

SHAP: значения Шепли, глобальная и локальная интерпретация, waterfall и summary plots, поиск утечек данных и ограничения метода.

Прямой ответ

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

SHAP (SHapley Additive exPlanations) — метод на основе значений Шепли из кооперативной теории игр. Каждому признаку назначается вклад в отклонение предсказания от базового значения, причём вклады всех признаков в сумме дают итоговое предсказание. Это свойство аддитивности делает объяснения согласованными, в отличие от простой важности признаков.

Два уровня интерпретации:

  • Глобальная. Какие признаки влияют на модель в целом и как именно (направление и сила). Используется при приёмке модели и ревью признаков.
  • Локальная. Почему конкретный объект получил такой скор. Используется в разборе кейсов и при объяснении решений пользователям.
import shap

explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X_test)

# глобальная картина
shap.summary_plot(shap_values, X_test)

# объяснение одного объекта
shap.waterfall_plot(shap.Explanation(
    values=shap_values[0],
    base_values=explainer.expected_value,
    data=X_test.iloc[0].values,
    feature_names=X_test.columns.tolist(),
))

Что SHAP даёт на практике:

  1. Поиск утечек данных. Признак с аномально большим влиянием, которого не должно быть в момент предсказания, виден сразу. Это самый частый способ обнаружить «признак из будущего».
  2. Проверку логики. Если модель считает отток по числу обращений в поддержку — логично; если по дню недели — повод разобраться.
  3. Объяснение отказов. Для кредитных и страховых сценариев объяснение часто требуется по правилам, а не только по желанию.
  4. Диагностику дрейфа. Изменение структуры влияний со временем — сигнал, что изменились данные или поведение; см. мониторинг моделей.

Практика: как использовать объяснения в работе

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

Разбор отдельного случая.

def explain_one(idx: int) -> dict:
    sv = shap_values[idx]
    contrib = sorted(zip(X_test.columns, sv), key=lambda p: -abs(p[1]))
    return {"base": float(explainer.expected_value),
            "prediction": float(base_pred[idx]),
            "top_factors": [(n, round(float(v), 4)) for n, v in contrib[:5]]}

Такой ответ удобно показывать оператору: «скор высокий, потому что: 3 обращения за неделю (+0.31), договор истекает (+0.18)…».

Сравнение с permutation importance. Permutation importance отвечает на вопрос «насколько упадёт качество, если перемешать признак», SHAP — «каков вклад признака в конкретное предсказание». Методы дополняют друг друга: расхождение между ними — повод проверить корреляции признаков.

Рекомендации:

  1. Не интерпретируйте коррелирующие признаки по отдельности. Если два признака дублируют друг друга, SHAP «размажет» вклад между ними, и каждый будет выглядеть малозначимым.
  2. Выбирайте правильный explainer. TreeExplainer для деревьев, LinearExplainer для линейных моделей, KernelExplainer как универсальный, но медленный.
  3. Считайте SHAP на выборке, а не на всём датасете. Для глобальной картины достаточно нескольких тысяч объектов.
  4. Фиксируйте версию модели вместе с объяснениями. Объяснение, построенное на другой версии, вводит в заблуждение.
  5. Проверяйте объяснение на устойчивость. Если небольшое изменение входа резко меняет структуру объяснений, модель неустойчива — и это важнее, чем само объяснение.

Практический сценарий: SHAP показал признак, которого не должно быть

Контекст: модель прогнозирования оттока с ROC-AUC 0.95; команда собиралась выкатывать.

  1. Проверка объяснений. В топ-3 по глобальному влиянию оказался признак days_since_last_login с вкладом, втрое превышающим остальные.
  2. Разбор. Для клиентов, которые уже ушли, признак принимает большие значения по определению: они не заходят в сервис. То есть признак кодирует сам факт оттока, а не его причину.
  3. Проверка на валидации. После удаления признака качество упало до 0.81 — это и есть честная оценка модели.
  4. Исправление. Признак пересчитали на момент события (число дней с последнего входа до начала прогнозного окна), а не на момент сбора данных; добавили проверку доступности признаков в пайплайн.
  5. Профилактика. Ревью SHAP-графиков стало обязательным шагом приёмки модели, а не опциональной визуализацией.

Вывод: объяснения — это инструмент валидации. Модель с «необъяснимо хорошим» качеством почти всегда использует признак, который в проде недоступен.

Как оформить объяснение для бизнеса. Три правила: показывать не больше трёх факторов, переводить названия признаков в язык предметной области и указывать направление влияния словами, а не числами. Формулировка «скор высокий, потому что клиент обращался в поддержку трижды за неделю» понятнее, чем список значений Шепли.

FAQ

Чем SHAP отличается от важности признаков в дереве? Встроенная важность считает, насколько признак уменьшает примесь в среднем по дереву; она не учитывает направление влияния и плохо работает с коррелирующими признаками. SHAP даёт согласованные вклады с направлением и объясняет конкретное предсказание.

Медленно ли считается SHAP? Для деревьев — приемлемо на тысячах объектов благодаря TreeExplainer. Для произвольных моделей KernelExplainer требует тысяч проходов модели, поэтому объяснения строят на выборке.

Можно ли показывать SHAP конечным пользователям? Да, но в упрощённом виде: топ-3 фактора в понятных формулировках. Сырые значения Шепли без контекста бесполезны и могут быть неверно истолкованы.

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

Источники: SHAP docs, Unified approach to interpreting model predictions (arXiv), scikit-learn permutation importance — ссылки в шапке.