Прямой ответ
Интерпретируемость — возможность объяснить, почему модель приняла конкретное решение. Она нужна не «для галочки»: объяснения помогают находить утечки данных, проверять здравый смысл модели, отвечать на вопросы бизнеса и разбирать инциденты.
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 даёт на практике:
- Поиск утечек данных. Признак с аномально большим влиянием, которого не должно быть в момент предсказания, виден сразу. Это самый частый способ обнаружить «признак из будущего».
- Проверку логики. Если модель считает отток по числу обращений в поддержку — логично; если по дню недели — повод разобраться.
- Объяснение отказов. Для кредитных и страховых сценариев объяснение часто требуется по правилам, а не только по желанию.
- Диагностику дрейфа. Изменение структуры влияний со временем — сигнал, что изменились данные или поведение; см. мониторинг моделей.
Практика: как использовать объяснения в работе
Приёмка модели. Перед выкаткой просмотрите глобальные влияния и проверьте три вещи: нет ли признаков, недоступных в момент предсказания; соответствуют ли направления влияний здравому смыслу; не доминирует ли один признак подозрительно сильно.
Разбор отдельного случая.
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 — «каков вклад признака в конкретное предсказание». Методы дополняют друг друга: расхождение между ними — повод проверить корреляции признаков.
Рекомендации:
- Не интерпретируйте коррелирующие признаки по отдельности. Если два признака дублируют друг друга, SHAP «размажет» вклад между ними, и каждый будет выглядеть малозначимым.
- Выбирайте правильный explainer.
TreeExplainerдля деревьев,LinearExplainerдля линейных моделей,KernelExplainerкак универсальный, но медленный. - Считайте SHAP на выборке, а не на всём датасете. Для глобальной картины достаточно нескольких тысяч объектов.
- Фиксируйте версию модели вместе с объяснениями. Объяснение, построенное на другой версии, вводит в заблуждение.
- Проверяйте объяснение на устойчивость. Если небольшое изменение входа резко меняет структуру объяснений, модель неустойчива — и это важнее, чем само объяснение.
Практический сценарий: SHAP показал признак, которого не должно быть
Контекст: модель прогнозирования оттока с ROC-AUC 0.95; команда собиралась выкатывать.
- Проверка объяснений. В топ-3 по глобальному влиянию оказался признак
days_since_last_loginс вкладом, втрое превышающим остальные. - Разбор. Для клиентов, которые уже ушли, признак принимает большие значения по определению: они не заходят в сервис. То есть признак кодирует сам факт оттока, а не его причину.
- Проверка на валидации. После удаления признака качество упало до 0.81 — это и есть честная оценка модели.
- Исправление. Признак пересчитали на момент события (число дней с последнего входа до начала прогнозного окна), а не на момент сбора данных; добавили проверку доступности признаков в пайплайн.
- Профилактика. Ревью SHAP-графиков стало обязательным шагом приёмки модели, а не опциональной визуализацией.
Вывод: объяснения — это инструмент валидации. Модель с «необъяснимо хорошим» качеством почти всегда использует признак, который в проде недоступен.
Как оформить объяснение для бизнеса. Три правила: показывать не больше трёх факторов, переводить названия признаков в язык предметной области и указывать направление влияния словами, а не числами. Формулировка «скор высокий, потому что клиент обращался в поддержку трижды за неделю» понятнее, чем список значений Шепли.
FAQ
Чем SHAP отличается от важности признаков в дереве? Встроенная важность считает, насколько признак уменьшает примесь в среднем по дереву; она не учитывает направление влияния и плохо работает с коррелирующими признаками. SHAP даёт согласованные вклады с направлением и объясняет конкретное предсказание.
Медленно ли считается SHAP?
Для деревьев — приемлемо на тысячах объектов благодаря TreeExplainer. Для произвольных моделей KernelExplainer требует тысяч проходов модели, поэтому объяснения строят на выборке.
Можно ли показывать SHAP конечным пользователям? Да, но в упрощённом виде: топ-3 фактора в понятных формулировках. Сырые значения Шепли без контекста бесполезны и могут быть неверно истолкованы.
Что делать, если объяснение противоречит ожиданиям бизнеса? Разбираться, а не отключать объяснения. Либо модель нашла реальную закономерность, о которой не знали, либо в данных есть смещение или утечка. В обоих случаях это полезная находка — она стоит проверки гипотезы через корректную валидацию.
Источники: SHAP docs, Unified approach to interpreting model predictions (arXiv), scikit-learn permutation importance — ссылки в шапке.