Data analysis | Анализ данных | DA

Сегментация с помощью K-means на Python

Предположим, что надо сегментировать банковские точки продаж по признакам:

▶️Число клиентов
▶️Доход (млн руб.)
▶️Конверсия в продукты
▶️Среднее время обслуживания (мин)
▶️Жалобы на 1000 клиентов
▶️Число конкурентов рядом

Вообще, сегментация через k-means осуществляется по принципу "чем меньше расстояние между значениями, тем лучше". То есть этот метод не различает контекст и будет просто объединять максимально похожие друг на друга точки в одну группу. Это не скоринг, где точки будут отсортированы по рейтингу. И результаты сегментации надо будет интерпретировать уже вручную в зависимости от того, что получится.

🟠В нашем контексте это будет полезно для того, чтобы определить, какие паттерны вообще существуют и что делать.

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

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

А третья группа может иметь мало клиентов и мало конкурентов - это уже другой пул проблем и задач.

🟠Итак, приступим. Сначала как обычно импортируем библиотеки и подключаемся к источнику данных. Также нужно будет отдельно выделить признаки для сегментации в датафрейм:

import pandas as pd
from sklearn.preprocessing import StandardScaler
from sklearn.cluster import KMeans

######
#ИСТОЧНИК ДАННЫХ + СОЗДАНИЕ DF
######

features = [
    'clients',
    'income_mln',
    'conversion_pct',
    'service_time_min',
    'complaints_per_1k',
    'competitors_nearby'
]

X = df[features]

Затем важный шаг - нормализация данных. Она приводит все данные к одному масштабу. Это особенно важно в нашем случае, потому что все признаки у нас имеют разные единицы измерения. И чтобы не происходило смешивания, этот метод приводит каждое значение к "общему знаменателю", рассчитывая среднее и стандартное отклонение по каждому столбцу.

scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)

Наконец, запускаем саму сегментацию. Для этого нужно настроить сам алгоритм. То есть указать количество кластеров (пусть будет n_clusters=4), проставить random_state (чтобы алгоритм всегда выдавал один и тот же результат, начиная с одной точки) и указать число повторений (n_init=10) для бОльшей точности.

И затем этот алгоритм применить уже к нормализованным данным (X_scaled):

kmeans = KMeans(n_clusters=4, random_state=42, n_init=10)
clusters = kmeans.fit_predict(X_scaled)
df['cluster'] = clusters
print(df.groupby('cluster')[features].mean().round(2))

В итоге получится 4 группы точек продаж, сгруппированных по ранее указанным признакам. Для каждой группы будет указано среднее значение каждого признака.

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

for cluster_id in sorted(df['cluster'].unique()):
    ids = df[df['cluster'] == cluster_id]['branch_id'].tolist()
    print(f"Кластер {cluster_id}: {ids}")

Выведет 4 списка (по 1 на группу), где будут указаны номера точек продаж.

Если бы рост в IT был лестницей, большинство было бы Senior.

Но на собеседованиях выясняется, что опыт, стаж и “я уже Middle” почти ничего не решают.

Илья Шишков 11 лет работал в Яндексе и провёл 250+ интервью и видел это постоянно. В канале @imhired разбирает, по каким признакам кандидатов относят к Junior, Middle и Senior - и почему многие готовятся совсем не к этому.

Начни с первого файла👇
(руководство по решению любой алгори...)

Что такое Data Mesh?

Data Mesh - относительно новое понятие в управлении данными, которое используется как альтернатива традиционным DWH.

🟠Главный акцент тут - на децентрализованности. В классическом подходе хранилища данных обслуживает какая-то конкретная специализированная на этом команда. Она, как правило, извлекает данные из источников, трансформирует их и загружает в DWH, которым потом пользуются разные отделы в компании.

При таком подходе существуют свои недостатки. Например, при увеличении объема данных нагрузка на команду DWH так же увеличивается, что приводит либо к росту издержек, либо к снижению скорости обработки, либо к снижению качества и т.д. Также инженеры могут находиться в отрыве от всех бизнесовых контекстов и тонкостей и заниматься только техническими вопросами, что может приводить к неточностям.

🟠Подход Data Mesh решает эти недостатки тем, что смещает фокус обслуживания только лишь с 1 команды на все отделы в компании. Условно, продуктовые отделы, отделы маркетинга и финансов теперь сами отвечают за размещение и поддержку тех данных, которыми они пользуются или которые они производят.

И хоть идея подхода звучит красиво, на деле имеет множество недостатков:

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

Во-вторых, в разных отделах теперь будут нужны сотрудники, которые одновременно и технически подкованы, чтобы управлять данными своего отдела, и разбираются в бизнес-контексте своих данных.

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

Ну и также, скорее всего, нужно будет возиться с доступами. И вероятнее всего могут возникнуть проблемы при миграции уже существующих данных с традиционного DWH в Data Mesh.

🟠Но а в целом, если решить все эти вопросы, то Data Mesh даст преимущества в виде:

▶️Масштабируемости, потому каждый новый домен добавляется автономно

▶️Качества, скорости и актуальности данных, потому что за каждыми данными будет стоять своя компетентная команда

▶️Гибкости, потому что под данные можно будет выбирать не только, например, традиционные СУБД, а перемешивать и NoSQL, и Data Lake, и колоночные СУБД и т.д. Главное, чтоб это было согласованно.

Регрессия с контролем ковариат на Python

Допустим, есть такие данные:

▶️customer_id - ID клиента
▶️avg_balance - Средний баланс за период
▶️total_spent - Суммарные траты за тот же период
▶️age - Возраст
▶️income - Доход (если есть)
▶️months_with_bank - Сколько клиент уже в банке (в месяцах)
▶️num_products - Количество продуктов в банке

И есть гипотеза: "Чем больше средний баланс клиента, тем больше его суммарные расходы".

Предположим, что мы провели корреляционный анализ и выяснили, что связь действительно есть. Теперь нужно выяснить причину этой связи: действительно ли баланс влияет на траты? Или же это траты влияют на баланс? Или есть какие-то иные факторы?

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

import pandas as pd
import numpy as np
import statsmodels.api as sm

######
#ИСТОЧНИК ДАННЫХ + СОЗДАНИЕ DF
######

X_simple = sm.add_constant(df[['avg_balance']])
y = df['total_spent']

model_simple = sm.OLS(y, X_simple).fit()
print(model_simple.summary().tables[1])

Первым делом всё импортируем, создаём датафрейм и строим обычную линейную регрессию.

Данные выведутся в виде таблицы, где нам важна ось Х. Таблица содержит несколько "технических" полей, которые в целом можно и проигнорировать. Можно оставить только самое важное:

▶️coef - коэффициент, показывающий, на сколько руб. вырастут суммарные траты при увеличении среднего баланса на 1 рубль.

▶️P>|t| - коэффициент стат значимости, показывает, насколько данным можно доверять. Если < 0.05, то всё хорошо.

▶️[0.025 0.975]. Доверительный интервал, который показывает "разброс" значений первого коэффициента coef. То есть траты не обязательно должны расти, например, на 0.4. Они могут вырасти и на 0.39, и на 0.41 - и это будет ок.

🟠Всё это может напоминать уже проведенный ранее корреляционный анализ, но всё же есть отличия.

Корреляция Спирмена (которая использовалась ранее) отличается от линейной регрессии тем, что она даёт только лишь 1 число - коэффициент корреляции, который показывает лишь силу связи. Линейная регрессия же показывает уже конкретно с помощью coef, какой будет эффект.

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

🟠Еще стоит отметить, что это - первоначальные данные, которые просто описывают исходный датасет. Далее с этими данными мы будем сравнивать результаты ковариатов.

🟠Идем дальше:

models = {
    'age': ['age'],
    'income': ['income'],
    'tenure': ['months_with_bank'],
    'products': ['num_products']
}

for name, cov in models.items():
    X = sm.add_constant(df[cov + ['avg_balance']])
    coef = sm.OLS(y, X).fit().params['avg_balance']
    print(f"С контролем {name:10}: {coef:.4f}")

Этот скрипт построит регрессию с контролем ковариат (поля age, income, months_with_bank и num_products) и сравнит её с первоначальной.

На выходе получим 4 значения coef при avg_balance - по одному для каждой модели с контролем одного фактора. Там, где эта разница больше всего (например, было 0.4, а стало 0.2 при факторе income), там и потенциально скрыто наибольшее влияние на траты. Следовательно, в дальнейшем анализе надо будет присмотреться не к avg_balance как к причине роста трат, а к income.

RFM-анализ на SQL

Один из довольно часто встречающихся на практике кейсов - сегментация пользователей (или RFM-анализ). Цель анализа - разделить клиентов на группы (сегменты), чтобы понять, кто из них самый ценный, кто требует внимания, а кого, возможно, уже не вернуть.

Осуществляется на основе:

▶️Recency — когда последний раз покупал?
▶️Frequency — сколько раз покупал?
▶️Monetary — сколько потратил?

Базовый запрос выглядит так:

WITH clients as (
SELECT
customer_id,
CURRENT_DATE - MAX(order_date) AS recency_days,

COUNT(order_id) AS frequency,
SUM(price) AS monetary_value
FROM orders
GROUP BY customer_id)

Из таблицы заказов считается разница между сегодняшним числом (или отчетной датой) и датой последнего заказа, а также считается число заказов и их сумма в разрезе каждого клиента.

Далее подключается скоринговая модель. Основной смысл таков: разбить клиентов на 5 квантилей и на основании этих 3 показателей присвоить им рейтинги. Для Recency ценятся наиболее свежие даты, а для Frequency и Monetary - чем больше, тем лучше.

Используем оконную функцию NTILE(5), которая делит клиентов на 5 равных частей:

SELECT
customer_id,

NTILE(5) OVER (ORDER BY recency_days) AS r_score,

NTILE(5) OVER (ORDER BY frequency DESC) AS f_score,

NTILE(5) OVER (ORDER BY monetary_value DESC) AS m_score

FROM clients

На выходе получится сгруппированная ранее таблица клиентов, к которой добавится 3 столбца, в каждом из которых будет число от 1 до 5 - это будет рейтинг клиента.

С этими рейтингами можно поступать по-разному. Можно всё агрегировать в единый итоговый 15-балльный рейтинг, а можно оставить как есть и смотреть рейтинги в разрезе 3 показателей - тут зависит от целей.

Методы вроде TTT-E2E меняют правила игры: вместо хранения всего контекста в памяти модель доучивается прямо во время инференса, сжимая информацию в веса.

Результат — константная латентность, качество как у full attention и скорость RNN.

TTT-E2E использует два цикла предобучения:

1️⃣ Внутренний — для обновления части весов при генерации каждого токена;
2️⃣ Внешний — для инициализирующих параметров.

На инференсе динамические веса обучаются на лету и сбрасываются после запроса, что делает предобучение вычислительно тяжелым и требует мощного GPU с большим VRAM.

Собрать такую машину локально — дорого и долго. К счастью, в immers.cloud за пару минут можно запустить сервер с нужной видеокартой — и сразу клонировать репозиторий TTT-E2E без настройки драйверов. Платите только за время работы сервера.

Теперь независимые исследователи могут воспроизводить эксперименты, ранее доступные лишь крупным лабораториям.