Clustering training: where group quality breaks down
Clustering is deceptively simple: any method will produce a split into groups, even if there is nothing in the data to group.
The model is trained, the metric is calculated, the report is sitting there — yet the clusters match neither customer segments, nor failure types, nor anything that can be relied on for decisions. In most cases, the cause is not the algorithm, but what happened before it.
Most often, clustering quality breaks on inconsistent features. If some fields are normalized to a common form, some contain missing values, and categorical values are encoded arbitrarily, the distance between records stops reflecting anything.
Feature preparation is not "tidying up the data" but a decision about which differences between objects we consider meaningful.
K-Means and density-based methods such as DBSCAN and HDBSCAN react differently to different scales: for some, a dominant feature pulls the entire split, while for others neighboring points go into noise.
The second source is outliers in the data. Single anomalies shift centroids and drag entire groups along, while density-based methods declare them noise and silently lose part of the observations.
The third is the absence of a quality criterion: if it is not fixed in advance what we consider a successful split and how we check group stability, the debate about the number of clusters turns into eyeballing variants.
Metrics such as silhouette from scikit-learn are useful, but by themselves do not answer whether the groups make sense for the task.
That is why our clustering training starts with features, criterion, and outlier handling — and only then with method selection.
Measurable effect: stable segments and less manual work
Clustering is considered tuned not when the algorithm has produced a split, but when that split reproduces on new data.
Therefore we fix three measurable indicators: cluster stability upon retraining, the share of outliers in the overall record stream, and the amount of manual review that remains on the customer's side.
These are exactly what show whether the model works as a tool or merely draws pretty groups on a historical slice.
We define the split quality criterion before launch, rather than selecting it to fit the result.
Usually this is a combination of internal evaluation (silhouette, within-group density) and drift checking: cluster composition is compared across runs on different time windows, and if labels "move" more than the agreed share, the configuration is revisited.
K-Means is convenient when the number of groups is known in advance; DBSCAN and HDBSCAN determine it from data density themselves — this is fundamental for streams where new record types appear gradually.
A separate metric is the share of outliers. It is not "hidden" by distributing noise among the nearest groups: records that fall into no cluster go as a separate stream to manual review or into a queue for retraining.
For labeled business streams, we aim for single-digit percentages of outliers: if it is a third, the problem is not the algorithm but the features.
The result is that segments found on historical data repeat on new records, and manual review shrinks to a narrow layer of ambiguous cases.
We work on a standard production stack, including scikit-learn, so the model is handed over to the internal team without vendor lock-in to us.
Clustering training: comparison of methods and operating modes
The choice of method is determined not by popularity, but by the data structure and what is done next with the result: customer segmentation, anomaly detection, or feature compression. Below are four working options and their boundaries of applicability.
| Approach | When it fits | Limitations |
|---|---|---|
| Centroid-based (K-Means and related) | Numeric features, groups are compact and similar in size, number of clusters is known from business logic | Number of groups is set manually, result is sensitive to feature scale and outliers, poorly separates nested and elongated groups |
| Density-based (DBSCAN, HDBSCAN) | Group shape is arbitrary, boundaries are blurred, some points are noise that must not be forced into a cluster | Requires tuning neighborhood parameters; in high dimensions, distances lose contrast |
| Hierarchical | A nesting tree is needed and justification for why exactly this number of groups was chosen | Merges are irreversible; on large volumes, computation is noticeably slower |
| Re-clustering of existing groups | Labels or segments already exist; need to check their homogeneity and split overly large ones | Inherits errors of the original split; requires stability metrics |
In practice, the approaches do not compete: a density-based run finds natural concentrations and noise, a centroid-based one refines boundaries within them, and re-clustering checks whether heterogeneous groups have been merged into one segment.
We fix the choice of consistency metric and thresholds before launch so that the result reproduces on new data slices, not only on the training sample.
Implementation stages: from data audit to model handover
Clustering differs from supervised tasks in that there are no labels and the "correct answer" cannot be looked up. Therefore, the sequence of steps here is stricter: first we fix what we consider a good result at all, and only then do we touch the algorithm. Otherwise, the number of groups is selected for a pretty picture, not for the task.
- Data audit — we profile the dataset: missing values and their nature, duplicate records, outliers, units of measurement, distribution drift between extracts. The output is a list of columns that may be fed into the model and a decision on what goes into cleaning.
- Definition of the quality criterion — we agree on how the result will be measured before launch: compactness (silhouette coefficient), group separability, split stability upon recalculation. We align it with the substantive meaning: how homogeneous a segment should be and whether small groups are acceptable.
- Feature preparation — scaling adjusted for outliers, encoding categorical fields, calculating a joint metric for mixed types. It is at this step that most of the quality is decided: inconsistent scales distort the result more than changing the algorithm.
- Parameter tuning — for K-Means we select the number of groups, for DBSCAN the radius and density threshold, for HDBSCAN the minimum cluster size. We compare options on the same grid and leave noise points as a separate class rather than spreading them across groups.
- Validation on a holdout sample — training on one part, evaluation on an independent one: we check whether the structure persists, whether labels are stable, and whether there is overfitting to a particular slice. We fix the random seed and the version of prepared features so the result reproduces.
- Model handover — we deliver the trained model, feature transformation as a separate artifact, a scoring script for new data, and a report with metrics and applicability boundaries. We separately describe at what data drift the split loses meaning and recalculation is needed.
Output artifacts: diagrams, pipeline code, regulations
The customer retains not a "model in a notebook," but a kit that your team runs and maintains without us: data is described, code works, split quality is measurable, and operations are regulated.
Everything is handed over to your repository with change history and deployment instructions on a clean environment.
- Feature description. Which fields and derived metrics are used as input, how missing values and outliers are handled, what values are scaled with — this description allows the dataset to be reproduced on a new slice.
- Pipeline code. Data preparation, training of K-Means, DBSCAN, and HDBSCAN, parameter search, split selection, and writing labels back to storage. Runs with a single command, with no manual steps.
- Quality report. Compactness and separability metrics, share of points assigned to noise, cluster stability on subsamples — with thresholds below which the split is considered unsuitable.
- Rerun procedure. Frequency, data window, retraining conditions, and actions when metrics degrade: who runs it, what they check, when they stop the pipeline.
- Data access rights. Roles for reading raw data, writing labels, and running the pipeline; secrets are stored separately, and personal fields are masked before training.
- Diagrams and pipeline map. Sources, intermediate layers, target tables, and control points — so a new engineer can understand it without messaging us.
- Split version log. Which features and parameters produced which result — with the ability to roll back to a previous split.
Each artifact can be checked, run, and modified by your team.
Case study: how segmentation quality grew after retuning
The clustering case here is illustrative: the customer came with a dataset collected from several sources — form requests, an extract from the accounting system, and support tickets.
Everything was in one table, and the segmentation did not add up: analysts rechecked every group manually.
Metrics before retuning
Clustering on the original features produced a silhouette coefficient of around 0.18 — segment boundaries were blurred, and some groups overlapped almost completely.
Around 40% of records went into noise or changed their label on a rerun: about a third of the dataset turned out to be unstable, and such labels cannot be relied on in work.
Heterogeneous records with different scales and formats "pulled" centroids toward themselves and blurred the boundaries between groups.
Feature reconstruction and change of approach
Features were rebuilt using scikit-learn: text fields were decomposed into numeric vectors, categories were consolidated into a single reference list, ranges were brought to a common scale, and derived features were added — recency of contact, frequency, and depth of interaction.
They abandoned forced partitioning: the density-based approach determines the number of groups itself and puts atypical records into a separate noise class instead of assigning them to the nearest segment.
Metrics after
The silhouette grew to 0.46, the share of unstable records fell from 33% to 7%, and noise accounted for 12% and is explicitly marked — it is visible and can be reviewed separately.
Segments stopped falling apart when a fresh extract was added; rebuilding the model on new data takes minutes instead of hours of manual reconciliation. Such a dataset is already suitable for communication segmentation and ticket prioritization.
How do density-based methods differ from centroid-based ones?
Centroid-based methods — for example, K-Means — treat a cluster as a compact group around a center: the algorithm minimizes within-group variance and assigns each point to the nearest center.
The boundaries are convex, the number of groups is set in advance, and the result depends on the initial placement of centers. The key consequence: any point, including an obvious outlier, necessarily receives a group number and shifts the center toward itself.
Density-based methods (DBSCAN and its hierarchical variants) determine membership differently: a cluster is an area where points are densely packed, separated from neighbors by sparse regions.
The shape of clusters is not postulated in advance, so elongated, ring-shaped, and nested structures are found correctly.
But a threshold appears — the neighborhood radius and minimum number of neighbors — and a point that does not reach the density is marked as noise in the data instead of being assigned to the nearest group.
Working with noise changes the result more than it seems. With the centroid-based approach, several outliers redraw the boundary between neighboring groups; with the density-based approach, they are excluded from the calculation and can be reviewed separately.
The price is sensitivity to the threshold: if density is heterogeneous in different parts of the data, a single radius cuts some areas and merges others.
Practical conclusion: on compact and well-separated groups, both families will produce a similar picture. As soon as cluster shape is complex or noise is noticeable, the choice of method determines whether we see the real structure or a split artifact.
Therefore, before training, we look at the distribution of distances to neighbors and check split stability on subsamples.
Doubts before starting: noise, overfitting, labeling
Before starting, the same doubts come up: overlapping clusters, choice of the number of groups, model behavior on new data. We make decisions based on metrics — stability on subsamples, share of outliers, distances to centers.
A pipeline assembled once is reused: on new datasets, the features and thresholds change, not the training logic.
Clusters overlap — is that a problem?
Overlap is a property of the data, not an error of the method.
For boundary points, we calculate membership probability instead of a hard label and assign controversial ones to noise: the density-based approach does not assign a point at random but acknowledges that it lies between groups.
How to choose the number of groups without overfitting it?
We select the number of groups by stability: we train on different subsets and see whether cluster composition persists. If the cores break down differently on repeat, that is overfitting to the sample. We check the final value against the number of segments that makes sense for the task.
What will happen on new data?
Hard clustering assigns a point to the nearest center, and the centers are fixed during training. Density-based methods are retrained on a schedule or via approximation. The share of points far from any center is calculated separately: its growth signals data drift.
How to avoid overfitting?
Overfitting looks like clusters of two or three points. To prevent it, we limit dimensionality, set a minimum group size, and do not discard noise for the sake of a pretty picture. A split is workable if it reproduces on data the model has not seen.
Let's discuss the task and come back with a work plan
It is better to start the conversation not with algorithm choice but with the data: clustering rests on features, scale, and what you consider a useful group.
K-Means, DBSCAN, and HDBSCAN produce different results on the same dataset — that is why we build the work plan and timeline estimate after we see the data composition and acceptance metric.
What to send and what we will clarify so we do not have to guess:
- An extract in its original form — one or two files or a database extract as is: from them we assess missing values, feature types, and volume.
- A statement of the task — which objects we group and what a "meaningful group" means to you.
- Current hypotheses and labels, if they already exist: this will show which features definitely work.
- Infrastructure constraints — where the model can be trained and where data may be exported.
- Requirements for personal data and access: masking, anonymization, role separation.
- Integration points — where features come from and in what form the result goes into your systems.
- Acceptance criterion — by which number or manual check you will understand that quality is sufficient.
After that, we will come back with a work plan: feature preparation stages, method selection for your data type, a way to assess cluster stability, and a timeline estimate for each stage. Describe the task in free form — that is enough to start.
