What is dense passage retrieval (DPR), and how is it different from keyword search?
Finding passages by comparing embeddings, from one encoder for questions and one for passages, instead of matching words. The 2020 DPR paper showed it beating BM25 keyword search on open-domain question answering.
advanced · Also called DPR, Dense Retrieval, Dual Encoder Retrieval
Dense passage retrieval finds the passages that answer a question by meaning rather than by shared words. Every passage in a library is turned into an EmbeddingEmbeddingA list of numbers that stands for the meaning of a piece of text, an image or other data. Things with similar meaning get similar numbers, so a computer can find them. ahead of time. When a question arrives it is embedded too, and the passages whose embeddings sit closest are returned.
"Dense" describes the numbers. A keyword index is sparse: a list with a slot for every word in the vocabulary, almost all of them zero for any one passage. An embedding is a few hundred or a few thousand numbers, every one of them used.
The paper that named it
The name comes from a 2020 paper by Vladimir Karpukhin and colleagues. Before it, systems that answered questions from Wikipedia mostly found their passages with BM25, a keyword method. DPR trained 2 encoders, one for questions and one for passages, on pairs of questions and the passages that answer them, so a question and its answer land close together. On top-20 retrieval, finding the right passage among the first 20, it beat a strong BM25 system by 9 to 19 percentage points.
A few weeks later the first RAG paper, by Patrick Lewis and others including Karpukhin, used a dense retriever of this kind over Wikipedia to feed a model that writes answers. That pairing, a dense retriever and a generator, is the outline of RAGRAGA way to answer from your own documents. A search finds the passages that match the question, and they are added to the prompt before the model writes. systems today.
How it is used now
The idea won, the exact model did not. Today the encoder is usually a general-purpose embedding model, hosted or open, that embeds both questions and passages, often with a marker saying which is which. The embeddings sit in a vector databaseVector DatabaseA database built to store embeddings and quickly find the ones closest to a query, which is how AI apps search by meaning., which finds the nearest ones quickly with an approximate index such as HNSWHNSWHierarchical Navigable Small World: a vector index that links each vector to its near neighbours in layers of graphs, so a search hops from coarse to fine and checks only a small share of the vectors..
What it misses
Dense retrieval is strong where questions and passages use different words, and weak on exact strings: an error code, a part number, a name the model has rarely seen. Anthropic's write-up on retrieval gives the example of an exact error code that embeddings can miss and keyword search finds. So production systems rarely rely on dense retrieval alone. They run it beside BM25, as hybrid searchHybrid SearchRunning a keyword search (usually BM25) and a vector search for the same query and merging the 2 ranked lists, so exact terms like a product code and loose wording like "money back" are both found., and put a RerankingRerankingA second search step that reads each candidate passage together with the question and scores how well it answers, so the best few of a fast first search go to the model in the right order. step after both.
Sources