Cluster label

A cluster label is the short title and one-sentence summary generated to describe one cluster’s fragments — something like “Population movements between Europe and Asia Minor, 1920s.” It is produced by combining the cluster’s top TF-IDF terms with a small text LLM that turns them into readable prose, applied after an unsupervised algorithm has already formed the grouping. The label describes what a human reading the grouping would call it; it does not decide what belongs in the grouping.

Why the distinction matters

HDBSCAN groups fragments by similarity in embedding space with no concept of a name — its output is membership, not meaning. A separate model reads the grouped fragments afterwards and writes a label for them. That two-step separation matters because it means the label can be wrong about what a cluster is called while the clustering itself is entirely sound, and vice versa: a well-named cluster can still be a bad grouping if the underlying embeddings didn’t actually place similar fragments near each other. Reading the label as a claim about the archive — rather than as one model’s gloss on what an algorithm already grouped — collapses two independent sources of possible error into one.

What it is not

A cluster label is not a claim made by the researcher who owns the dataset, and it is not a generated summary of the source material’s content in the sense that a research finding would be. It is model output describing model output: an LLM’s attempt to name a grouping an unsupervised algorithm produced, disclosed as such via the same provenance mechanism as every other derived text in Archēglyph. Quoting a cluster label as if it were a scholarly claim about the corpus — “the archive shows that population movements increased” — misattributes an algorithmic gloss to the archive itself.

Editable, and the edit persists

A generated label can be renamed from the cluster card, and the rename persists — the system does not regenerate over a researcher’s correction on the next view. This matters because the right response to a bad label is usually not to distrust the clustering, but to fix the one thing that actually was wrong: the two or three words describing it. See Reading clusters as a researcher for the practical workflow — read the exemplar quotations before the title, and treat the title as provisional until the fragments confirm or contradict it.

A worked example

A cluster’s top TF-IDF terms might be harvest, wheat, tenant, arrears, quarter-day. The label model turns that into “Tenant farming and rent disputes” — a reasonable gloss. But if the underlying cluster actually mixes two adjacent but distinct themes (rent disputes and crop-failure correspondence that happens to share vocabulary), the label will smooth over that mixture rather than flag it, because the label model only sees the words it was given, not the judgment call about whether those words represent one coherent theme or two. Reading the exemplar fragments — not just the label — is what catches this.

Limitations

A label is generated from a cluster’s most statistically distinctive terms, so it inherits whatever those terms miss: a cluster whose real unifying feature is how something is written (register, tone) rather than what it discusses will get a label built from vocabulary that may not capture the actual commonality at all. Labels are also regenerated whenever the underlying clustering re-runs with a different embedding model or parameters — unless a researcher’s manual rename has been saved for that specific version — so a label cited from one dataset version is not guaranteed to describe the same grouping, or exist at all, in the next.

Bottom line

A cluster label is a model’s best short gloss on a grouping another model already formed — useful for orientation, renamable when it is wrong, and never a substitute for reading the fragments it is trying to summarise.

FAQ

← Back to the glossary