Embeddings Explained for Product and Business Teams

The word that keeps turning up in every AI proposal

If you have sat through a pitch for an AI assistant, a smarter site search or a recommendation feature, someone has said 'we will embed your content'. It is usually said quickly, as though everybody knows what it means, and product managers nod along.

Embeddings are worth understanding properly, because they drive a lot of design decisions: what gets stored, what it costs, why search sometimes misses obvious results, and what happens when you change provider. None of it needs maths.

What an embedding is, without maths

Imagine placing every product in your catalogue on an enormous map, where items that mean similar things sit close together. Waterproof hiking boots end up near walking socks and gaiters, far from office chairs. An embedding is simply each item's coordinates on that map.

The map has hundreds or thousands of dimensions rather than two, and the coordinates are produced by an embedding model trained on huge amounts of text. You cannot read meaning off a single number, but the distances are meaningful. Finding 'things like this one' becomes finding the nearest points, which computers do very fast.

Crucially, 'boots for wet weather' and 'waterproof walking footwear' share almost no words and land close together. That is what keyword search could never do.

What embeddings are used for

Several of these need no language model at all, which makes them cheaper and more predictable than people expect. Clustering customer feedback with embeddings is one of the most useful afternoon projects in applied AI.

What they cost and where they live

• Creating them is cheap. Embedding an entire document library is typically a small one-off cost, whether through an API or an open-source model on your own hardware.
• Storing them is modest. Each vector is a few kilobytes; a million chunks fits comfortably in an ordinary database.
• Searching them needs a vector index. PostgreSQL with pgvector handles most SME workloads; dedicated vector databases suit very large or high-traffic ones.
• Updating them is ongoing: new and changed content must be re-embedded, which needs a pipeline rather than a one-off script.

Our guide to vector database choices compares the storage options in more depth.

The limits product teams should plan around

• Exact details are fuzzy. Part numbers, invoice references and prices are poorly represented. Pair embeddings with keyword search, as in hybrid search.
• Negation is weak. 'Dairy-free' and 'contains dairy' can sit uncomfortably close.
• Similar is not relevant. The nearest document is about the same topic, not necessarily the one that answers the question.
• Models are not interchangeable. Vectors from one embedding model mean nothing to another. Switching model means re-embedding everything.
• Domain jargon can be misread. General models may not know that two internal product names are related.
• Embeddings can leak. Vectors derived from personal data are still personal data, and text can partly be reconstructed from them.

None of these is a reason to avoid embeddings. They are reasons to test on your own content rather than trusting a demo built on Wikipedia articles.

A simple test works well for product teams. Take 30 real searches your users made that failed or returned poor results, run them against an embedding index of your content, and have someone who knows the content score the top five results for each. It takes a day, needs no production code, and tells you more than any vendor comparison chart about whether semantic search will help your particular users.

Choosing an embedding model

For most business uses the differences between reputable embedding models are smaller than the differences made by clean content, sensible chunking and hybrid search. That said, a few factors genuinely matter.

1. Languages: check performance on every language your content uses
2. Domain: legal, medical and code-heavy content may benefit from specialised models
3. Hosting: API models are simplest; open-source models keep data in-house
4. Dimensions: smaller vectors are cheaper to store and search, often with little quality loss
5. Stability: pick a model you can pin, because a silent update would invalidate your index

How SpiderHunts uses embeddings in projects

At SpiderHunts, embeddings sit underneath most of our search, assistant and matching work, but we rarely lead with them. We start with the problem, test embeddings against plain keyword search on a sample of real queries, and use whichever wins, which is often a combination.

If you are exploring a search or matching feature, our AI integration service can prototype it on your own data within a couple of weeks, which is usually enough to see whether it is worth building properly.

Frequently asked questions