An embedding is a vector. Similar things sit near each other. That is the whole trick, and it is why search, recommendations, and “find weird rows” can work without a perfect keyword match.
I use embeddings when word match is not how a person would look.
What I send to the model
OpenAI embedding models are my default when the text can leave the server. The OpenAI Embeddings API takes a string (or a batch) and returns a vector.
Pricing considerations: you pay for input tokens, often in large batches. Embedding a whole wiki once is fine. Re-embedding it on every page view is how you waste money. Embed when the source changes. Store the vector.
Open-source embeddings when I cannot call out:
- Sentence Transformers — the library I expect to see in Python examples
- Models on Hugging Face — pick one dimension size and stick to it. You cannot mix vectors from two models in the same index
Use cases that earn their keep
- Semantic search — “refund policy for annual plans” should find a doc that never uses those exact words
- Data classification — embed a ticket, compare to labeled examples, assign a category
- Recommendation systems — “more like this document” without hand-built tags
- Anomaly detection — a vector far from the cluster is a weird log line, a weird support ticket, a weird transaction note
What embeddings will not do
They do not answer the user. They find neighbors. The answer still comes from a chat model, a classifier, or a human looking at what you retrieved.
If two sentences are near each other and one is wrong, the embedding did its job. Your data is wrong. Fix the source.
Next
Those vectors need a place to live and a way to query nearest neighbors: