Home / Retrieval models / Dense Retrieval Explained

Dense Retrieval Explained

Dense retrieval is search that encodes queries and passages separately into dense embedding vectors with a neural network, then returns the passages whose vectors are closest to the query’s. “Dense” means every dimension of the vector carries a value, in contrast to sparse retrieval’s mostly empty term vectors. Because passages are encoded once, offline, a search only needs to encode the query and look up its nearest neighbours in a vector index such as HNSW. The model learns, from pairs of questions and relevant passages, to place texts with the same meaning close together even when they share no words. That solves the vocabulary mismatch that limits keyword search. Dense retrieval’s weaknesses are exact identifiers, rare jargon and domains the model never saw, which is why it is often combined with sparse retrieval in hybrid search. Weaviate’s vector search is dense retrieval.

What does dense retrieval mean?

Dense retrieval means retrieving documents by comparing dense vector embeddings of the query and the documents, produced by a trained neural encoder, instead of by matching words. The vectors are dense because every one of their few hundred or few thousand dimensions holds a value.

An encoder, usually a transformer such as BERT or one of its descendants, reads a passage and outputs a fixed-length vector, for example 384 or 768 numbers. No single number means a word or a topic; meaning is spread across all of them. The encoder is trained so that a question and a passage that answers it end up close together, measured by dot product or cosine similarity.

The contrast with sparse retrieval is in the representation. Sparse vectors have one dimension per vocabulary term and are almost all zeros, so matching depends on shared words. Sparse retrieval covers that family, and dense vs sparse retrieval compares them directly. Retrieval models explained places both in the wider landscape. The mechanics of a dense retriever start with its two encoders.

How does dense retrieval work?

Dense retrieval works by encoding every passage into a vector ahead of time, storing the vectors in an approximate nearest neighbour index, then encoding each query at search time and fetching the nearest passage vectors. The expensive encoding of the corpus happens once.

This layout is called a dual encoder or bi-encoder. Some models use one shared encoder for both sides, sometimes with different prefixes for queries and passages; others train two separate encoders. Either way, both outputs live in the same space so their similarity is meaningful.

Search over millions of vectors needs an index. Comparing a query with every vector is exact but slow at scale, so systems use approximate nearest neighbour indexes. Weaviate’s default is HNSW, a layered graph that finds near neighbours in a small number of steps, with settings that trade recall for speed. ANN recall covers what the approximation costs. The quality of the results, though, depends on how the encoder was trained.

How are dense retrievers trained?

Dense retrievers are trained on pairs of queries and relevant passages with a contrastive objective that raises the similarity of each correct pair and lowers the similarity of incorrect ones. The choice of incorrect passages, called negatives, matters as much as the positives.

Karpukhin and colleagues’ Dense Passage Retrieval paper, DPR, presented at EMNLP 2020, trained BERT-based question and passage encoders on question-answering data. It used in-batch negatives: for each question, the passages paired with the other questions in the batch serve as negatives. It also added hard negatives, passages retrieved by BM25 that look relevant but do not contain the answer. The authors reported that DPR outperformed a BM25 baseline on passage retrieval for several open-domain QA datasets.

Later work refined each piece. Training with hard negatives mined by the model itself, distilling from a cross-encoder teacher, and large-scale pre-training on weakly paired text from the web all improved results. Modern general-purpose embedding models are built this way, then fine-tuned on many tasks. The training data decides what the model knows, which shows up in its strengths and weaknesses.

What is dense retrieval good at?

Dense retrieval is good at matching meaning across different wording, handling natural language questions, and working across languages or modalities when the model is trained for them. It removes the need for exact word overlap.

A question like “how do I get my money back” finds a passage titled “Refund policy” because the encoder learned that the two mean the same thing. Paraphrases, synonyms and questions phrased differently from documents all benefit. Multilingual models place a question in one language near passages in another, and multimodal models place text near images.

Dense retrieval also produces a single vector per passage that is cheap to store and compare, which suits large collections when combined with quantization. Weaviate’s vector search, its model provider integrations and its compression options are built around this. These strengths come with predictable limits.

Where does dense retrieval fail?

Dense retrieval fails on exact identifiers, rare terms, negation and look-alike passages, and on domains its training data did not cover. Its single vector per passage can blur details that a person would treat as decisive.

Product codes, error numbers and names are the clearest case. A general encoder treats “ERR-4012” and “ERR-4021” as near-identical noise, while keyword search matches the right one exactly. Long passages are averaged into one vector, so a single key sentence can be drowned out. Look-alike passages, such as “enable” and “disable” versions of the same instruction, sit close together because they share almost every word.

Domain shift is the other limit. Thakur and colleagues’ BEIR benchmark, published in 2021, evaluated retrievers on many domains and found that dense models trained on one domain often generalised worse than BM25 to new ones at the time. Newer embedding models have narrowed that gap, but testing on your own queries remains essential. Why vector search returns irrelevant results covers diagnosis. Several designs address these limits.

Which approaches improve on single-vector dense retrieval?

Approaches that improve on single-vector dense retrieval include late interaction with one vector per token, cross-encoder reranking of the top results, and hybrid search with a sparse retriever. Each recovers detail that one vector loses.

Late interaction models, such as ColBERT, keep a vector for every token and score a query against a passage by matching each query token to its best passage token. That preserves fine detail at the cost of much larger indexes; ColBERT and late interaction and multi-vector search cover them. Cross-encoders read the query and passage together, which is too slow for the whole collection but precise for reranking the top results, as compared in bi-encoder vs cross-encoder and covered in cross-encoders.

Learned sparse models, such as SPLADE, attack the problem from the sparse side, covered in SPLADE and learned sparse retrieval. Agents that call retrieval repeatedly can mix all of these, as described in agentic retrieval and agentic search. The most common fix, though, is pairing dense with sparse retrieval.

How is dense retrieval used with sparse retrieval?

Dense retrieval is used with sparse retrieval through hybrid search, which runs both and fuses their ranked lists so that meaning matches and exact-term matches both reach the top. In Weaviate, one hybrid query does both.

Weaviate’s hybrid search runs its dense vector search and its BM25F keyword search in parallel and fuses the results. By default it uses relative score fusion and an alpha of 0.75, which weights the dense side more. Lowering alpha favours the sparse side for collections full of codes and names. A query can also use the dense side alone with a near_text or near_vector search.

articles = client.collections.use("HelpArticle")

dense_only = articles.query.near_text(query="how do I get my money back", limit=5)
hybrid = articles.query.hybrid(query="refund for order ERR-4012", alpha=0.5, limit=5)

The near_text query needs a collection configured with a vectorizer, so Weaviate can embed the query text. The mechanics of fusion are in how hybrid search works. Before relying on either, measure on your own data.

What are the main types of information retrieval?

The main types of information retrieval models are Boolean models, vector space models and probabilistic models, with neural models such as dense retrieval as the modern addition. Dense retrieval is a learned descendant of the vector space idea.

Boolean retrieval returns documents that exactly satisfy a logical query, such as “refund AND card NOT gift”, with no ranking. Vector space models represent documents and queries as term vectors, classically TF-IDF, and rank by similarity. Probabilistic models estimate how likely a document is to be relevant, and BM25 descends from this line. Dense retrieval keeps the vector space idea but learns the vectors with a neural network instead of counting words.

Information retrieval differs from data retrieval. Data retrieval, as in a database query, returns records that exactly match conditions, such as all orders over a price. Information retrieval ranks documents by how well they satisfy an information need, which is fuzzy by nature. Semantic search systems often do both at once: a filter for exact conditions and a dense or hybrid ranking for relevance.

Dense retrieval encodes queries and passages into dense vectors with a trained neural encoder and returns the nearest passages from a vector index. Its dual-encoder design makes search fast because passages are encoded once, and contrastive training with in-batch and hard negatives teaches the model to place matching meanings together. It excels at paraphrase and natural questions and struggles with exact identifiers, look-alikes and unfamiliar domains. Pair it with sparse retrieval in hybrid search, rerank the top results when precision matters, and test the encoder on your own queries before trusting it.