Логистическая регрессия: как прогнозировать вероятность события и читать odds

Вопрос до формулы

В бинарной задаче легко свести ответ модели к 0 или 1 и потерять половину информации. Вероятность 0,51 и 0,99 окажутся одним классом, хотя решение бизнеса и риск совсем разные. Логистическая регрессия даёт понятный baseline, но требует проверки качества вероятностей, порога и дисбаланса классов.

Объяснять логистическую регрессию лучше через вероятности и ошибки, а не через log-odds. Покажи, сколько случаев попадёт в ручную проверку, сколько плохих событий удастся предотвратить и какую цену имеет пропуск. Такой разговор связывает модель с процессом и делает требования к данным прозрачными.

Что именно измеряем

Модель оценивает вероятность события через sigmoid от линейной комбинации признаков. Коэффициент линейной части связан с изменением log-odds, поэтому его нельзя читать как прямые процентные пункты вероятности. Для бизнеса важнее связка: ranking quality, calibration, threshold, cost of false positive и cost of false negative.

Раздели данные по времени, обучи baseline и получи probability, а не только class. Оцени ROC-AUC или PR-AUC в зависимости от баланса, Brier score и calibration curve. Порог выбирай на валидации по стоимости ошибок и ограничениям capacity. После запуска следи за drift и фактическими исходами.

Расчёт на примере

Модель предсказывает риск default по заявке. При пороге 0,5 она пропускает 92% заявок, но теряет много плохих клиентов. При пороге 0,3 recall растёт, однако одобрений становится меньше. Выбор порога — не техническая деталь: он зависит от стоимости просрочки, доступного ручного review и целей кредитного продукта.

Начни с таблицы ошибок и baseline rate. Построй calibration по decile вероятности, сравни predicted и observed rate. Затем оцени несколько порогов в терминах денег и объёма работы. Не оптимизируй порог на test. Зафиксируй, какая дата считается outcome и сколько времени нужно для созревания метки.

Проверка устойчивости

До интерпретации проверь единицу наблюдения, период и правило включения. Затем пересчитай результат на небольшой выборке, где ответ известен заранее, и сравни с разумной альтернативой: другим горизонтом, зрелой когортой или user-level агрегацией.

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

• Зафиксируй baseline до просмотра результата.
• Проверь пропуски, дубли и зрелость периода.
• Покажи размер выборки и диапазон неопределённости.

Ошибки интерпретации

Высокий ROC-AUC не гарантирует хорошую calibration. Accuracy бесполезна при редком событии. Случайный split создаёт утечку времени, если поведение меняется. Коэффициент не равен причинному влиянию признака. И нельзя называть модель надёжной, если test не содержит свежие сегменты, которые появятся после запуска.

Рабочий вывод: «Модель хорошо ранжирует заявки, PR-AUC выше baseline, но вероятности завышены в верхнем decile. При пороге 0,28 ожидаемый loss минимален при текущей capacity review; перед rollout нужна перекалибровка и мониторинг по self-employed».

Практика

Для любого binary target составь таблицу decile: n, mean predicted, observed rate, false positives, false negatives. Затем посчитай стоимость ошибок при трёх порогах. Если порог выбирается только по AUC, добавь бизнес-ограничение. Это превращает модель из абстрактного классификатора в рабочее решение.

from sklearn.linear_model import LogisticRegression
from sklearn.calibration import calibration_curve

model = LogisticRegression(max_iter=1000).fit(X_train, y_train)
p = model.predict_proba(X_valid)[:, 1]
fraction, mean_pred = calibration_curve(y_valid, p, n_bins=10)

• Сохрани период и параметры расчёта.
• Назови хотя бы один крайний случай.
• Сформулируй вывод отдельно от гипотезы о причине.

Решение для команды

Рабочий вывод: «Модель хорошо ранжирует заявки, PR-AUC выше baseline, но вероятности завышены в верхнем decile. При пороге 0,28 ожидаемый loss минимален при текущей capacity review; перед rollout нужна перекалибровка и мониторинг по self-employed».

Объяснять логистическую регрессию лучше через вероятности и ошибки, а не через log-odds. Покажи, сколько случаев попадёт в ручную проверку, сколько плохих событий удастся предотвратить и какую цену имеет пропуск. Такой разговор связывает модель с процессом и делает требования к данным прозрачными.