If you’re familiar with the basic concept of text embeddings but wondering how to put them to work, you’ve come to the right place. We’ll dissect vectors, tokenization, similarity calculation, go down the rabbit hole of evaluating embedding models, and show you real-world use cases.

What are text embeddings?

Text embeddings are numerical representations of words, sentences, or documents that capture their semantic meaning and relationships. They’re generated by embedding models that convert text into vectors — arrays of numbers that machine learning algorithms can process and compare.

ML engineers use text embeddings to help software applications recognize relationships between words and sentences, making it easier to search, categorize, and analyze large volumes of data.

Say you’ve got thousands of incoming support tickets daily. Customers report all imaginable problems, but you need to categorize and label them. One way to automate this process is to use a pretrained text embedding model to convert each ticket into a vector.

For example, two customers submit the following messages:

“I was charged twice for my subscription”: [0.21, -0.47, 0.83, ...]
“There’s a duplicate payment on my account”: [0.19, -0.45, 0.80, ...]

These are simplified, illustrative vectors.

Although the customers use different words, they’re describing the same problem. The embedding model captures this relationship by placing their vectors close together in a mathematical space. Both tickets get categorized and routed to the billing team.

Text embeddings use cases in business

Text embeddings are used in a range of natural language processing (NLP) tasks, including:

Semantic search: Finding relevant information based on meaning. Delivery Hero uses product and query embeddings alongside keyword search to help grocery customers find relevant products. For example, a search for “low fat yogurt” can surface Greek yogurt or yogurt containing 0.5% fat, even without an exact wording match.
Text classification: Categorizing text, such as identifying spam emails or sorting documents by topic. MindCraft.ai developed a document classification system that uses transformer-based text embeddings and machine learning to categorize corporate documents and identify sensitive information for GDPR compliance.
Clustering: Grouping similar documents or pieces of text to identify patterns. Doczy.ai converts contract text into embeddings and groups semantically related clauses and concepts, even when different contracts express similar obligations using different wording.
Retrieval-augmented generation (RAG): Retrieving relevant information that an LLM can use to generate more accurate, context-aware responses. Ring uses Amazon Titan text embeddings within a multilingual RAG chatbot to retrieve relevant support documentation before generating answers to customers' questions across international markets.
Recommendation systems: Suggesting related articles, products, or other content based on textual similarities. LinkedIn's JUDE system uses LLM-generated text embeddings of job descriptions and member profiles to improve job recommendations, capturing relationships between candidates' backgrounds and available positions.
Named entity recognition (NER): Helping identify and classify names of people, organizations, and places in text. Amazon Health Services uses NER to identify medical concepts in customer queries, such as diseases, symptoms, medications, and treatments. It combines that understanding with embedding-based similarity search to connect queries with relevant healthcare products and services.
Machine translation: Supporting models that translate text between languages. Transglot uses text embeddings in semantic translation memory to identify previously translated passages with similar meanings, helping localization workflows reuse existing translations.

How do text embeddings work?

So how does an embedding model decide which numerical values to assign to a piece of text, and why should we trust it?

It all starts with training. Embedding models learn from large collections of text, looking for patterns in how words are used together. For example, traditional models like Word2Vec learn by predicting a word from its surrounding words, or vice versa. Modern retrieval-focused models often use contrastive learning. They’re trained to assign higher similarity scores to relevant query-document pairs than to unrelated ones.

Once the model is trained, here’s what happens when you give it a new piece of text:

Tokenization. The model first breaks the text into smaller pieces called tokens. These might be entire words, parts of words, or punctuation marks. Each token receives a numerical ID from the model’s vocabulary, which doesn't carry any meaning on its own.
Encoding and pooling. The model processes these tokens using the patterns it learned during training and produces a vector. Each number in the vector is a coordinate or component, and a dimension is the axis along which that number defines the vector’s position. Each value contributes to the text’s position in a mathematical space, known as an embedding space.
Similarity calculation. To find related text, a retrieval system compares the query embedding with document embeddings using a similarity measure such as cosine similarity or dot product

That’s how online stores, for example, return matching items to a user’s query.

What is the difference between word, sentence, and document embedding?

The main difference is how much text each embedding represents in a single vector. You can create embeddings for individual words, complete sentences, or entire documents, depending on what information you want to capture.

Word embeddings capture relationships between individual words, recognizing that “outage” and “downtime” are related concepts.
Sentence embeddings understand the meaning of entire sentences, even when they express the same idea in different words.
Document embeddings represent an entire document as one vector, rather than creating a separate vector for each sentence. This helps preserve the general subject and find other documents covering the same subject; however, details may be harder (if not impossible) to retrieve.

How granular should you go? The right level depends on your data and what you’re trying to accomplish.

For larger documents, a common practice is to split text into smaller chunks and generate a separate embedding for each. This way, you’ll get the overall meaning of the document AND specific details, which might be lost during document embeddings.

How much does chunk size affect the quality of embeddings?

Quite a bit. According to Rahul Kumar, VP of AI engineering at Xenoss, the challenge is finding a chunk size that captures one complete idea without losing important context. He explains the trade-off:

“Chunk size sets how much semantic context one embedding carries. A bigger chunk gives the vector more context, but it also averages more topics into one vector. A chunk covering three topics lands in the middle and matches none of them well. A smaller chunk keeps the meaning sharp, but it can lose the context that made it findable.”

That’s why Kumar recommends choosing a chunking strategy based on the content rather than sticking to one fixed size. As he puts it, “fixed-size with overlap is only fine for uniform text like emails or scraped web pages.”

For structured documents like contracts or policies, recursive, structure-aware splitting is a better fit. Semantic chunking, meanwhile, can work well for transcripts because it splits text where the topic or meaning shifts.

Text embeddings vs. keyword search

Why use text embeddings when you can simply search for keywords? Because keyword search relies on matching terms, while embedding-based semantic search can retrieve relevant information even when the query and document use different words.

But semantic similarity doesn’t always mean relevance. Shaw Talebi, founder of AI Builder Academy, demonstrates this limitation using a resume search system. In Talebi’s case, when searching for a “data engineer with Apache Airflow experience,” only one of the top five results mentioned Apache Airflow, and it ranked third — even though three other resumes in the dataset listed that skill.

This means semantic search is useful for finding conceptually related information, but it can miss exact requirements like technical skills, product identifiers, or error codes.

To fix this problem, Rahul Kumar recommends choosing a retrieval approach based on where the retrieval system falls short:

Hybrid search (the combination of keyword matching with semantic search) is the default when queries carry exact terms, like SKUs, error codes, or legal references.
Rerankers earn their cost when only the top few results matter, like answers generated from retrieved context.
Graph retrieval helps when the answer spans across multiple connected data sources.

Kumar also shared how his team put these approaches into practice. In one project, they ran BM25 keyword search and vector search side by side, merged the results using reciprocal rank fusion (RRF), and used an LLM to rerank the top 124 results down to 6.

“Moving to graph-first retrieval, with vector search finding similar latent spaces and then a two-hop graph walk, raised ranking quality (nDCG) from 0.58 to 0.67 and cut p90 retrieval time from 19s to under 3s,” adds Kumar.

Types of text embedding models

All embedding models, by and large, do the same — learn relationships in text. However, they differ by the job they’re trained for, what information they consider, and the tasks they’re designed to handle.

Static word embedding models

Traditional word embedding models learn dense numerical representations of words based on patterns of word usage across large text collections. These embeddings are static, meaning each word gets the same vector regardless of its meaning in a particular context.

Two well-known methods are:

: Developed by Google in 2013, it learns representations from neighboring words using two architectures: Continuous Bag of Words (CBOW), which predicts a word from its neighbors, and skip-gram, which predicts neighboring words from a given word.
GloVe (Global Vectors for Word Representation): Developed at Stanford in 2014, it uses word co-occurrence statistics to learn relationships between words.

Contextualized language models

Unlike static embeddings, general-purpose language models produce contextual representations that change depending on the surrounding text. This helps models distinguish between different meanings of the same word.

BERT (2018, Google): Uses bidirectional self-attention to consider words on both sides of a token. For example, it generates different representations for “bank” in “I deposited money at the bank” and “I sat on the bank of a river.”
GPT (2018, OpenAI): Uses transformer-based representations that account for preceding text while predicting the next token. GPT models are primarily designed for language generation.

Sentence and document embedding models

Represent longer pieces of text, from individual sentences to paragraphs and entire documents, as vectors.

Doc2Vec: Extends Word2Vec-style learning to sentences, paragraphs, and documents. It can help group related articles or classify documents by subject.
Universal Sentence Encoder (USE): Developed by Google in 2018 to generate fixed-length representations of sentences and short paragraphs for semantic similarity and text classification.
Sentence-BERT (SBERT, 2019): Developed by Nils Reimers and Iryna Gurevych at Technical University Darmstadt, it builds on Google’s BERT model and is commonly used for semantic search, paraphrase detection, and clustering.
pplx-embed-v1 (2026, Perplexity): A state-of-the-art text embedding model built for real-world, web-scale retrieval, this family uses diffusion-based pretraining to turn a causal language model into a bidirectional encoder. It generates dense embeddings for independently encoded queries and documents, with quantization-aware training to reduce storage costs. Our 4B INT8 model achieved 69.66 nDCG@10 on the multilingual MTEB retrieval benchmark, compared with Google’s gemini-embedding-001 at 67.71.
pplx-embed-context-v1 (2026, Perplexity): Addresses a common problem with document chunking: passages can lose their meaning when separated from the surrounding text. Using late chunking, the model processes the document before pooling contextualized token representations into separate chunk embeddings. Our 4B model achieved 81.96 nDCG@10 on ConTEB, compared with 79.45 for voyage-context-3.
pplx-embed-v2-context (2026, Perplexity): Takes contextual retrieval further. Instead of training only to find the passage containing an answer, it learns to identify supporting passages that help explain or verify that answer. The model uses relevance signals distilled from a context compression model during training, without requiring that teacher at inference time. Our 9B preview achieved 45.5% answer recall and 40.6% evidence recall at 10 results on context-bench.

Perplexity’s models also allow storing embeddings at scale. The models produce INT8 and binary embeddings, reducing storage requirements by 4x and 32x, respectively, compared to FP32.

Model

Dimensions

Context

MRL

Quantization

Instruction

Pooling

pplx-embed-v1-0.6B

1024

32K

Yes

INT8/BINARY

Mean

pplx-embed-v1-4B

2560

32K

Yes

INT8/BINARY

Mean

pplx-embed-context-v1-0.6B

1024

32K

Yes

INT8/BINARY

Mean

pplx-embed-context-v1-4B

2560

32K

Yes

INT8/BINARY

Mean

pplx-embed model dimensions, context length, quantization, and pooling configuration

Dense, sparse, and multi-vector embeddings

There’s one more distinction worth understanding, particularly for semantic search. Embedding models can differ in how they represent text and calculate relevance.

Dense embeddings: Represent text using compact vectors in which most values are nonzero.
Sparse embeddings: Use mostly zero-valued vectors, with learned weights associated with important terms. Models such as SPLADE (2021) learn which terms matter for retrieving relevant documents.
Multi-vector embeddings: Retain several vectors for a piece of text, allowing more detailed comparisons between queries and documents. Models such as ColBERT (2020) use these representations for more detailed query-document comparisons.
Models combining multiple approaches: BGE-M3 (2024), developed by BAAI, supports dense, sparse, and multi-vector retrieval within the same model.

How to choose and evaluate a text embedding model

Public benchmarks such as MTEB are a good starting point. Use them to shortlist two or three models that support your languages, input lengths, and deployment requirements. But don’t pick a winner just yet. We can’t stress enough the importance of testing those models on your own data.

Here’s a practical evaluation workflow:

Build a test dataset. Collect 50-100 representative search queries as an initial evaluation set (you may need more), including tricky cases such as paraphrases, technical terminology, and exact error codes. For each query, identify which documents or passages contain relevant answers. These relevance labels become your ground truth.
Measure retrieval quality. Test each model against the same evaluation dataset, keeping document preparation and retrieval conditions comparable while following model-specific requirements for query formatting, normalization, and similarity scoring. Then calculate the following metrics using Sentence Transformers’ InformationRetrievalEvaluator:Recall@k: Gives the proportion of relevant passages that appear in the top k results.MRR: Measures how high the first relevant result appears in the rankings.nDCG@k: Measures how well the top k results are ranked based on their relevance.
Recall@k: Gives the proportion of relevant passages that appear in the top k results.
MRR: Measures how high the first relevant result appears in the rankings.
nDCG@k: Measures how well the top k results are ranked based on their relevance.
Benchmark latency and throughput. Measure how long each model takes to embed a query, ideally reporting median (p50) and 95th-percentile (p95) latency under realistic load.
Calculate storage and operating costs. Vector storage depends on the number of embeddings, their dimensions, and numerical precision. For example, one million 768-dimensional FP32 embeddings require approximately 3.1 GB of raw vector storage, excluding indexing overhead. To reduce storage requirements, you can quantize the vectors to lower numerical precision. Switching from FP32 to INT8, for instance, reduces raw vector storage by roughly 4 times. However, compression can affect retrieval quality, so rerun your evaluations to check the trade-off.

Ultimately, compare the results side by side: retrieval metrics, p95 latency, throughput, storage, and cost. Choose the model that meets your quality requirements within your production constraints.

When should you use embeddings instead of an LLM?

With LLMs handling everything from document analysis to complex reasoning, it’s quite tempting to throw all your text at a model and let it figure things out. But you probably won’t be happy to pay for that.

Additionally, LLMs are better at judging and composing but limited by how much information they can fit into a single prompt. Embeddings, on the other hand, are cheap, fast, consistent, and work across millions of items.

“Embeddings win at search, recommendations (“more like this”), spotting duplicates, like repeated support tickets, and grouping large volumes of content by topic. They are also strong across languages. An LLM wins when the task needs reasoning: summarising, comparing options, or writing an answer. Most real systems need both, each doing the part it’s good at,” concludes Kumar.

What developers get wrong about text embeddings

To find out what developers tend to overlook, I spoke with Rahul Kumar and Xibeijia Guan, data scientist at Ahrefs. They highlighted six mistakes worth watching out for:

Skipping text preprocessing. If the input data contains HTML, navigation menus, ads, or other irrelevant content, preprocessing steps such as boilerplate removal can help improve embedding quality by removing unnecessary information.
Ignoring the model’s maximum input length. Different models have different token limits and truncation behaviors. Text exceeding the limit may be truncated, causing important information to be lost.
Not following model-specific requirements. Some embedding models require specific prefixes, such as query: and passage:, or different instructions for different tasks. Not following these requirements can reduce retrieval performance.
Using an incompatible similarity measure. Cosine similarity and dot product aren’t always interchangeable. Check whether embeddings are normalized and use the scoring method recommended for the model and vector index.
Mistaking topical similarity for relevance. In narrow-domain collections, many documents may be semantically similar without answering the same question. Inspect failed queries and ranking distributions. Test lexical or hybrid retrieval, reranking, and metadata filters when users need exact information.
Ignoring embedding normalization. Different embedding models may output normalized or unnormalized vectors. Check whether the embeddings are normalized and whether additional normalization is needed, depending on the similarity metric you use.

Text embeddings FAQs

1. How do I generate text embeddings?

The simplest approach is to use a pretrained embedding model. With Python’s Sentence Transformers library, for example, you can load a model such as all-MiniLM-L6-v2, pass your text to model.encode(), and get a numerical vector back. Alternatively, you can generate embeddings through an API.

For semantic search or RAG, you’d typically split your documents into chunks, generate an embedding for each, and store the vectors in a searchable index.

2. What are the best embedding models for text?

Several models are worth considering, depending on what you’re building:

Perplexity’s pplx-embed-v1: Built for large-scale dense retrieval, with INT8 and binary embeddings that reduce vector storage requirements.
Perplexity’s pplx-embed-context-v1: Useful for retrieving passages from long documents where individual chunks lose meaning without their surrounding context.
all-MiniLM-L6-v2: Good for lightweight, local semantic search, clustering, and sentence similarity tasks. Produces compact 384-dimensional vectors but truncates inputs longer than 256 word pieces.
BGE-M3: Useful for multilingual RAG and hybrid retrieval. Supports over 100 languages and combines dense, sparse, and multi-vector representations.
Qwen3-Embedding: A strong candidate for multilingual search, code retrieval, and task-specific embeddings. Offers open-weight 0.6B, 4B, and 8B models with instruction support.
OpenAI’s text-embedding-3-large: An API-based option for semantic search and document retrieval when you don’t want to host a model. Supports up to 3,072 dimensions, which you can reduce to save storage.
Google’s Gemini Embedding models: Useful for managed retrieval applications. Gemini Embedding 2 also supports searching across text, images, audio, video, and PDFs in a shared embedding space.

3. Can I use an LLM as an embedding model?

Yes, but there’s a difference between a general-purpose LLM and one optimized for embeddings. LLMs produce internal vector representations of text, which you can extract and pool into a single embedding. However, those vectors aren’t necessarily useful for semantic search without additional training.

For example, Qwen3-Embedding uses an LLM backbone that’s further trained for embedding and retrieval tasks. So, while you can adapt an LLM to generate embeddings, a dedicated embedding model is usually the more practical starting point.