Обучение модели кластеризации данных: K-Means, DBSCAN, HDBSCAN

Обучение модели кластеризации данных — задача, с которой сталкиваются при сегментации клиентов или анализе текстов. Алгоритмы K-Means, DBSCAN, HDBSCAN — основа, но без правильной настройки результат неудовлетворителен. Например, на 500 тысячах записей K-Means даёт силуэт 0.19 и шум. Причина — неверный выбор числа кластеров и алгоритма, не учитывающего форму данных. Наш пайплайн автоматически подбирает алгоритм и число кластеров, добиваясь стабильных бизнес-интерпретируемых результатов.

MiniBatchKMeans с batch_size=2048 работает в 10-15 раз быстрее стандартного K-Means на датасетах >100k записей, что критично для оперативного анализа. Для текстовых данных используем HDBSCAN с предварительным снижением размерности UMAP — это позволяет выделять кластеры произвольной формы без указания их количества.

Проблемы, которые решает кластеризация

Кластеризация — обучение без учителя, выявляющее скрытую структуру данных: сегменты клиентов, тематические кластеры документов, аномальные группы транзакций. Основные проблемы, с которыми к нам приходят:

• Неправильный выбор числа кластеров. Метод локтя часто даёт неоднозначный ответ, а субъективный выбор ведёт к неинтерпретируемым сегментам.
• Масштабирование на большие объёмы. K-Means на 1 млн записей может считать минуты, MiniBatchKMeans — секунды.
• Кластеризация текстов. Классические алгоритмы плохо работают на Bag-of-Words — нужны эмбеддинги и HDBSCAN.

Наш опыт показывает: правильно настроенный пайплайн кластеризации даёт прирост в точности сегментации до 40% по сравнению с ad-hoc подходами.

Как выбрать алгоритм кластеризации?

Выбор алгоритма — ключевое решение. Сравним основные методы.

На практике для большинства задач мы используем K-Means с MiniBatch для больших данных и HDBSCAN для текстов и аномалий. GMM хорош, когда кластеры перекрываются.

Практический пайплайн: K-Means с автоматическим выбором k

from sklearn.cluster import KMeans, MiniBatchKMeans
from sklearn.preprocessing import StandardScaler
from sklearn.metrics import silhouette_score, calinski_harabasz_score
import numpy as np
import matplotlib.pyplot as plt

class ClusteringPipeline:
    def __init__(self, scale: bool = True):
        self.scaler = StandardScaler() if scale else None
        self.model = None

    def find_optimal_k(self, X: np.ndarray,
                        k_range: range = range(2, 20)) -> int:
        """Метод локтя + силуэт для определения K"""
        if self.scaler:
            X = self.scaler.fit_transform(X)

        inertias = []
        silhouettes = []

        for k in k_range:
            kmeans = MiniBatchKMeans(n_clusters=k, random_state=42,
                                    batch_size=1024)
            labels = kmeans.fit_predict(X)
            inertias.append(kmeans.inertia_)

            if len(X) > 50000:
                sample_idx = np.random.choice(len(X), 10000)
                sil = silhouette_score(X[sample_idx], labels[sample_idx])
            else:
                sil = silhouette_score(X, labels)
            silhouettes.append(sil)

        # Метод локтя — точка перегиба
        diffs = np.diff(inertias)
        diffs2 = np.diff(diffs)
        elbow_k = k_range[np.argmax(diffs2) + 2]

        # Лучший силуэт
        best_sil_k = k_range[np.argmax(silhouettes)]

        # Консенсус: ближайшие k из двух методов
        optimal_k = (elbow_k + best_sil_k) // 2
        print(f"Elbow method: k={elbow_k}, Silhouette: k={best_sil_k}, Chosen: k={optimal_k}")
        return optimal_k

    def fit(self, X: np.ndarray, k: int = None):
        if self.scaler:
            X_scaled = self.scaler.fit_transform(X)
        else:
            X_scaled = X

        if k is None:
            k = self.find_optimal_k(X_scaled)

        self.model = MiniBatchKMeans(n_clusters=k, random_state=42,
                                    batch_size=2048, n_init=10)
        self.labels = self.model.fit_predict(X_scaled)
        return self

    def evaluate(self, X: np.ndarray) -> dict:
        X_scaled = self.scaler.transform(X) if self.scaler else X
        return {
            'silhouette': silhouette_score(X_scaled, self.labels, sample_size=min(10000, len(X))),
            'calinski_harabasz': calinski_harabasz_score(X_scaled, self.labels),
            'n_clusters': len(np.unique(self.labels)),
            'cluster_sizes': dict(zip(*np.unique(self.labels, return_counts=True)))
        }

Мы используем MiniBatchKMeans с batch_size=2048 для ускорения на больших данных. Пример: на 500 000 записей пайплайн находит оптимальное k за 2 минуты.

Кейс: сегментация клиентов ритейла

Недавно мы кластеризовали клиентскую базу крупного ритейлера (2 млн записей). Использовали MiniBatchKMeans с консенсусным k=7. Получили silhouette 0.42 — на 0.15 выше, чем предыдущее решение. Кластеры оказались однородными по частоте покупок, среднему чеку и категориям. Бизнес использовал сегменты для персонализации рассылок — конверсия выросла на 18%. Инженер заказчика отметил: "Кластеризация помогла выделить 7 сегментов, которые ранее были неочевидны, и это напрямую повлияло на конверсию."

HDBSCAN для текстовых данных

import hdbscan
from sentence_transformers import SentenceTransformer

def cluster_documents(texts: list[str], min_cluster_size: int = 10) -> list[int]:
    # Эмбеддинги
    model = SentenceTransformer('all-MiniLM-L6-v2')
    embeddings = model.encode(texts, batch_size=256, show_progress_bar=True)

    # Снижение размерности перед кластеризацией
    from umap import UMAP
    umap_model = UMAP(n_components=10, random_state=42, metric='cosine')
    reduced = umap_model.fit_transform(embeddings)

    # HDBSCAN
    clusterer = hdbscan.HDBSCAN(
        min_cluster_size=min_cluster_size,
        metric='euclidean',
        cluster_selection_method='eom',
        prediction_data=True
    )
    labels = clusterer.fit_predict(reduced)

    # -1 = noise/outlier
    print(f"Found {len(np.unique(labels[labels >= 0]))} clusters")
    print(f"Noise points: {(labels == -1).sum()}")
    return labels

В проекте по кластеризации техподдержки мы обработали 100 000 тикетов. HDBSCAN выделил 15 тематических кластеров и 12% шума (аномальные запросы). Time-to-insight сократился с недели до часа.

Процесс работы: от аналитики до деплоя

Наш процесс включает этапы:

1. Аналитика: определение цели — что кластеризовать (клиенты, документы, транзакции) и как интерпретировать.
2. Проектирование: выбор алгоритма, метрик, пайплайна.
3. Разработка: код, оптимизация гиперпараметров (k, min_cluster_size, метрика расстояния).
4. Валидация: вычисление silhouette, Calinski-Harabasz, визуализация (t-SNE, UMAP), бизнес-проверка.
5. Деплой: интеграция в продуктивную среду, мониторинг дрейфа кластеров.

Сроки — от 2 до 4 недель в зависимости от сложности данных.

Как интерпретировать кластеры?

def describe_clusters(X_df: pd.DataFrame, labels: np.ndarray) -> dict:
    """Автоматическое описание каждого кластера"""
    cluster_descriptions = {}

    for cluster_id in np.unique(labels):
        if cluster_id == -1:
            continue
        mask = labels == cluster_id
        cluster_df = X_df[mask]

        # Центроид кластера в признаковом пространстве
        centroid = cluster_df.mean()

        # Наиболее отличительные признаки (выше/ниже среднего)
        overall_mean = X_df.mean()
        diff = (centroid - overall_mean) / X_df.std()
        top_features = diff.abs().nlargest(5).index.tolist()

        cluster_descriptions[cluster_id] = {
            'size': mask.sum(),
            'size_pct': mask.mean(),
            'top_features': {f: float(centroid[f]) for f in top_features},
            'centroid': centroid.to_dict()
        }

    return cluster_descriptions

Хорошая кластеризация имеет силуэтный коэффициент >0.3, бизнес-интерпретируемые кластеры и стабильность при повторных запусках (Jaccard similarity >0.8 между запусками).

Что входит в работу

• Документация: отчёт с выбором алгоритма, описанием кластеров, визуализациями.
• Код пайплайна: чистый, задокументированный, с README.
• Дашборд мониторинга: график силуэта, стабильности кластеров.
• Обучение команды: 1-2 сессии по интерпретации и использованию модели.
• Пост-релизная поддержка: 2 недели консультаций.

Получите консультацию по вашему проекту — мы подберём оптимальный алгоритм и настроим пайплайн под ваши данные. Закажите обучение модели кластеризации с гарантией качества.

Подробнее о cluster analysis.

Data Engineering для ML: пайплайны, разметка и качество данных

«У нас много данных» — фраза, которая на деле часто означает «у нас много сырых логов в S3, которые никто не трогал два года». Перед тем как обучить модель, нужно понять, что вообще есть: какова структура, есть ли дубли, как часто меняется схема, насколько репрезентативна выборка.

Data Engineering для ML — не просто ETL. Это построение воспроизводимой инфраструктуры данных, которая делает обучение моделей надёжным, а переобучение — предсказуемым. По опыту нашей команды (8 лет в дата-инжиниринге, более 30 проектов в ML) каждая вторая проблема в продакшене связана не с архитектурой модели, а с качеством данных.

ETЛ-пайплайны для ML: чем отличаются от BI

ETL для аналитики и ETL для ML — разные задачи. В аналитике важна агрегация, в ML — индивидуальные записи с историей. В аналитике train/val/test split не нужен, в ML — критичен. В аналитике skew данных мешает интерпретации, в ML — напрямую влияет на качество модели.

Инструменты. Apache Spark (Wikipedia) для больших объёмов (10GB+): PySpark с DataFrames, оптимизации через partitioning и caching. dbt для трансформаций поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версионируется, тестируется. Pandas + Polars для объёмов до нескольких GB — Polars в 5-10x быстрее Pandas на типичных трансформациях.

Temporal splits. Для ML важно, что split по времени, а не случайный. Если данные временные (транзакции, события пользователей), случайный split даёт data leakage: модель видит «будущие» данные при обучении. Правило: train на периоде T1-T2, validation на T2-T3 (с gap для предотвращения leakage), test на T3-T4. Неправильный split может стоить 10–15% качества модели на валидации.

Инкрементальные пайплайны. Модель переобучается еженедельно на новых данных. Нужен пайплайн, который инкрементально добавляет новые записи к обучающей выборке, не перегружая всё с нуля. Delta Lake или Apache Iceberg — форматы с ACID-транзакциями, Change Data Capture, time travel.

Как избежать training-serving skew с помощью Feature Store

Feature Store решает проблему рассинхронизации между обучением и инференсом. Самая коварная ошибка в ML-инфраструктуре — training-serving skew: признак считается по-разному в обучении и в продакшене. Модель учится на «правильных» данных, а инференс получает другие.

Feast (open source) — офлайн store на Parquet/Delta в S3 для обучения, онлайн store на Redis для low-latency инференса (<10ms). Feature definitions как Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition, используется везде. Нет расхождений.

Потоковые признаки. Когда признак должен обновляться в реальном времени (количество транзакций за последние 10 минут), нужна потоковая обработка. Apache Kafka + Apache Flink или Kafka Streams для вычисления признаков в реальном времени → запись в онлайн store. Сложнее, дороже, нужно только когда staleness признаков критична для качества.

Разметка данных: как не потратить бюджет впустую

Разметка — самая трудоёмкая и недооцениваемая часть ML-проекта. Плохо размеченные данные не исправит никакая архитектура.

Label Studio — open source, поддерживает разметку изображений (bounding box, polygon, segmentation), текста (NER, классификация), аудио, видео. Поднимается за 10 минут через Docker. Для небольших команд — первый выбор.

Оценка качества разметки. Inter-annotator agreement — насколько согласны разметчики между собой. Cohen's Kappa > 0.8 — хорошо, 0.6-0.8 — приемлемо, < 0.6 — задача неоднозначна или инструкция плохая. Пересечение разметок (10-20% примеров размечают два независимых аннотатора) — обязательная практика.

Active learning. Не размечать случайные примеры, а выбирать те, на которых модель наиболее неуверена (low confidence, high uncertainty). Позволяет добиться того же качества при 50-70% объёма разметки. Modals, Prodigy, Label Studio поддерживают active learning workflows. На одном из проектов для NLP мы сократили бюджет на разметку в 2,5 раза за счёт active learning.

Синтетические данные. Когда реальных данных мало или получить их дорого. Для CV: рендеринг в Blender/Unity с реалистичными текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Риск: модель обучается на distribution синтетических данных, а не реальных — нужна осторожность и проверка на реальном holdout.

Качество данных: валидация и мониторинг

Great Expectations — de facto стандарт для data validation в ML-пайплайнах. Expectations — это декларативные утверждения о данных: «колонка age содержит значения от 0 до 120», «колонка user_id не содержит null», «распределение amount не отклоняется более чем на 20% от baseline». Запускается в пайплайне, при провале — блокирует прохождение.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation с type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель ожидает данные за последние N дней. ETL упал, данные не обновились — модель использует устаревшие признаки. Мониторинг свежести данных: timestamp последней записи в каждой таблице, алерт при задержке > порога.

Дедупликация. Дубликаты в обучающей выборке завышают метрики (одни и те же примеры в train и val) и искажают веса модели. MinHash LSH для приближённой дедупликации больших датасетов. Для точной — хэш по нормализованному контенту.

Инструменты валидации: сравнение

Хранилища и форматы

Для большинства ML-проектов на старте: Parquet в S3 + DVC для версионирования. Delta Lake или Iceberg — когда появляется потребность в инкрементальных обновлениях или time travel.

Что входит в проект по дата-инжинирингу для ML

Мы предоставляем полный цикл:

• Аудит существующих данных и пайплайнов (1 неделя).
• Проектирование архитектуры: выбор инструментов, форматов, способов разметки.
• Реализация ETL/ELT пайплайна с валидацией и мониторингом.
• Документация кода и процессов (model card, data card).
• Обучение вашей команды работе с пайплайном.
• SLA на сопровождение и поддержку.

Как мы строим пайплайн: пошагово

1. Аудит существующих данных. Профилирование: ydata-profiling (бывший pandas-profiling) генерирует HTML-репорт со статистиками, дистрибуциями, корреляциями, missing values за минуты.
2. Проектирование пайплайна. Определяем источники данных, частоту обновления, требования к latency признаков, объёмы.
3. Реализация и тестирование. Unit-тесты на трансформации, integration-тесты на пайплайн, data validation через Great Expectations.
4. Деплой и мониторинг. Алерты на freshness, quality checks, аномалии в объёмах данных.

Почему стоит доверить это нам

Мы занимаемся дата-инжинирингом и ML с 2016 года. За это время реализовали более 40 проектов — от построения пайплайнов для NLP-моделей до разметки датасетов для компьютерного зрения. Гарантируем воспроизводимость пайплайнов и полную прозрачность процессов. В каждом проекте используем инструменты с открытым исходным кодом, чтобы вы не были привязаны к вендору.

Свяжитесь с нами для бесплатного аудита ваших данных — оценим текущий пайплайн и предложим roadmap. Закажите построение ML-пайплайна под ключ.