Most engineers encounter embeddings the first time they build semantic search. You convert text to vectors, store them in Pinecone or pgvector, query by cosine similarity, done. Useful feature, clear use case, move on.
That framing is costing you. Embeddings aren’t a search primitive. They’re a general-purpose representation layer, and once you see them that way, you’ll find a dozen places in your stack where you’re working harder than you need to because you haven’t put them to work.
Your classification pipeline is probably overengineered
Here’s a pattern that shows up constantly: a team needs to classify user inputs, support tickets, or content into categories. They fine-tune a model, build a labeled training set, set up a retraining pipeline, and ship something that works reasonably well but is brittle and expensive to maintain.
The simpler version: embed your examples and your input, then compare distances. If you have a handful of labeled examples per category, nearest-neighbor classification over embeddings often performs comparably to a fine-tuned classifier, with none of the retraining overhead. You add a new category by adding examples, not by kicking off a training run.
This isn’t always the right answer. High-volume production classification at scale may justify the fine-tuning cost. But for the enormous middle ground of internal tools, moderation pipelines, and routing logic, the embedding approach is faster to ship and easier to iterate on.
Deduplication and fuzzy matching are unsolved problems you’re solving wrong
If you’ve ever tried to deduplicate a database of company names, product titles, or user-submitted text, you know that exact matching gets you maybe 60% of the way there, and rule-based fuzzy matching gets messy fast. “Acme Corp”, “ACME Corporation”, and “Acme, Corp.” are the easy cases. The hard ones are where meaning overlaps but strings don’t.
Embedding similarity handles this naturally because it operates on meaning, not character sequences. Two product descriptions that describe the same thing in different words will cluster together in embedding space even if they share almost no tokens. Building a deduplication pass with embedding similarity, followed by a lightweight confirmation step, is genuinely practical and often more accurate than the elaborate string-matching logic teams build instead.
The same principle applies to data deletion and cleanup workflows. When you need to find and remove related records across a messy dataset, semantic similarity is a tool worth having.
Embeddings give you a cheap, surprisingly good anomaly detector
Anomaly detection usually implies setting up a separate ML pipeline, defining what “normal” looks like, and maintaining a model that drifts as your data changes. That’s the right approach when anomaly detection is core to your product. For everything else, there’s a simpler path.
If you embed a stream of events (user actions, API calls, log messages, whatever), normal behavior clusters together in vector space. Unusual behavior lands far from those clusters. You can set a distance threshold from the centroid of recent normal behavior and flag anything that exceeds it. This won’t beat a dedicated anomaly detection system tuned by an ML team. It will beat nothing, which is what most products currently have.
Practically: embed a rolling window of recent normal inputs, compute a centroid, and alert when new inputs fall outside a distance threshold you tune empirically. You can get this running in an afternoon.
Embeddings make your recommendation logic honest
Recommendation systems built on collaborative filtering (users who liked X also liked Y) have a cold-start problem and a popularity bias problem. New items don’t get recommended because they have no interaction history. Popular items get over-recommended because they have lots of it.
Content-based recommendations using embeddings sidestep both issues. Embed the item itself, not its interaction history, and you can recommend a brand-new piece of content the moment it’s published, because its similarity to other content is computable immediately. You’re recommending based on what something is, not how many people have clicked it.
This pairs well with interaction signals rather than replacing them. But if your recommendation logic currently has a cold-start problem, embeddings are the most direct fix available.
The counterargument
The fair pushback here is that embeddings are not magic. They inherit the biases of the models that produce them. They’re opaque, which makes debugging hard. A nearest-neighbor result that seems wrong gives you almost no information about why it’s wrong. And embedding quality varies significantly across domains: a general-purpose embedding model trained on web text may perform poorly on specialized technical or medical language without fine-tuning.
All of that is true. The point isn’t that embeddings are universally the right tool. It’s that they’re underused relative to how often they’re the right tool. Most teams reach for them once, for semantic search, and stop. The cases above aren’t exotic research applications. They’re practical patterns that work in production today, with models you already have access to.
If you’re already storing embeddings for search, you’re paying the storage and compute cost anyway. The question is whether you’re extracting the full value from the representation you’ve already built. In most stacks, the answer is no.
Treat the embedding layer as infrastructure, not a feature. Build it once, reuse it across classification, deduplication, anomaly detection, and recommendation. You’ll write less code, maintain fewer pipelines, and find that a surprising amount of your ML roadmap was actually the same problem in different clothes.
