Embeddings beyond search

The same list of numbers that powers RAG is useful even when no language model is involved. Once every ticket, review or item description is a point in space, you can group nearby points, flag copies, train a small classifier or recommend similar items.

The big idea

Retrieval asks "what is near this query?" The other jobs ask nearby questions of the same geometry.

• Clustering asks "which points form a cloud?"
• Near-duplicate detection asks "which pairs sit unusually close?"
• Classification asks "which labeled cloud does this point fall in?"
• Recommendations ask "which items sit near this user or this item?"
• Novelty asks "which points sit far from every cloud?"

A kitchen spice rack is a useful picture. Search is "hand me something like cumin." Clustering is "group the jars that smell alike." Dedup is "these two jars are the same cumin." The picture breaks when two texts are close in meaning but must stay separate for legal or product reasons. Geometry is a hint, not a verdict.

Walking through a week of tickets

You embed 8,000 support tickets with all-MiniLM-L6-v2 (384 numbers each). You run a clusterer such as HDBSCAN or k-means.

A new cloud of 140 tickets appears around "cannot download invoice PDF." You did not search for that phrase. The cloud formed because the embeddings sat together. That is the weekly "what are users asking?" report, without reading 8,000 threads.

Near-duplicates use a cutoff you measure yourself. On this model, true paraphrase pairs in the source sat around cosine 0.55 to 0.85, and unrelated pairs sat below 0.25. For legal or compliance text, set the cutoff high and send matches to a human queue. Do not copy 0.75 from a blog post.

For classification, freeze the embedder and train a logistic regression or a small MLP on a few hundred labeled tickets. That often beats a bag-of-words baseline and ships in a day.

Content-based recommendations embed item descriptions, or a user profile built from recent activity, and return nearest neighbors. You get similar-item recs without a full collaborative-filtering stack.

Common mistakes

• Using a retrieval embedder for paraphrase clustering without checking. Some models are trained for query-versus-passage search, others for sentence similarity. A retrieval winner can lose on clustering. Prefer STS-oriented models when the job is "are these the same?"
• Treating a high cosine as proof of a duplicate. Close is not identical. Review the pair.
• Skipping a novelty check. Points far from every cluster are new intents or junk. Look at them before they hit a production agent.

Check yourself

1. You want "what did users ask this week?" from 8,000 tickets. Do you need an LLM? No. Embed the tickets and cluster. The clouds are the themes.
2. Why is a cosine cutoff from another team's blog a bad duplicate rule? Scores belong to a model and a domain. Their 0.75 is not yours.

Key takeaways

• The same vectors support clustering, dedup, classification, recommendations and novelty.
• Calibrate any "is this a match?" cutoff on your own labeled pairs.
• Pick a model whose training job matches the use: retrieval models for search, similarity models for paraphrase clouds.
• Geometry is a hint. Humans still decide legal and compliance matches.

Further learning

Next, put those vectors in an index with vector databases.