Accueil › Glossaire › Dense Retrieval

Dense Retrieval (Recherche Dense)

Le dense retrieval est une méthode de recherche d’information qui utilise des vecteurs denses (embeddings) générés par des réseaux de neurones pour représenter et comparer requêtes et documents par similarité sémantique, par opposition au sparse retrieval (BM25, TF-IDF) qui repose sur la correspondance de mots-clés.

Le terme « dense » fait référence à la nature des vecteurs : chaque dimension contient une valeur non nulle (contrairement aux vecteurs « sparse » de BM25 où la quasi-totalité des dimensions sont à zéro). Un vecteur dense de 768 dimensions encode le sens global d’un texte dans un espace continu où les textes sémantiquement proches se retrouvent géométriquement proches. C’est cette propriété qui permet de retrouver un document pertinent même quand il ne contient aucun mot de la requête. Le modèle fondateur de cette approche est DPR (Dense Passage Retrieval), publié par Facebook AI Research en 2020, qui a démontré que les représentations denses surpassent BM25 de 9 à 19% en accuracy sur les benchmarks de question answering.

Dense retrieval vs sparse retrieval

Pour comprendre le dense retrieval, il faut d’abord comprendre ce qu’il remplace et complète.

Le sparse retrieval (BM25, TF-IDF)

Les méthodes classiques comme BM25 et TF-IDF représentent chaque document comme un vecteur creux (sparse) dans un espace dont chaque dimension correspond à un mot du vocabulaire. Si le vocabulaire contient 30 000 mots, chaque vecteur a 30 000 dimensions, mais la quasi-totalité sont à zéro (seuls les mots présents dans le document ont une valeur non nulle). La recherche consiste à trouver les documents dont les vecteurs partagent le plus de dimensions non nulles avec la requête, pondérées par la fréquence et la rareté.

Le sparse retrieval est rapide (grâce à l’index inversé), transparent et excellent pour les correspondances exactes de mots-clés. Mais il ne comprend pas le sens. « Voiture » et « automobile » sont deux dimensions totalement distinctes. « Réduire la latence du serveur » et « optimiser les temps de réponse de l’API » n’ont aucun mot en commun et ne seront pas mis en correspondance.

L’approche dense

Le dense retrieval résout ce problème en encodant chaque texte comme un vecteur dense de dimensions fixes (typiquement 384 à 3072) via un modèle de deep learning. Dans cet espace, le sens est distribué sur toutes les dimensions. « Voiture » et « automobile » se retrouvent proches géométriquement, car ils partagent des contextes d’usage similaires dans les données d’entraînement. La comparaison se fait par similarité cosinus ou produit scalaire.

Architecture du dense retrieval

Le dual-encoder (bi-encoder)

L’architecture standard du dense retrieval est le dual-encoder, aussi appelé bi-encoder. Deux encodeurs Transformer (typiquement BERT) produisent chacun un vecteur :

L’encodeur de requête (question encoder) prend la requête Q en entrée et produit un vecteur dense q de 768 dimensions (pour un modèle BERT-base). Typiquement, le vecteur du token [CLS] ou un mean pooling des tokens est utilisé.

L’encodeur de passage (passage encoder) prend un document ou passage P et produit un vecteur dense p. Les deux encodeurs partagent souvent la même architecture mais peuvent avoir des poids distincts (dans DPR original, ils sont initialisés depuis le même BERT mais fine-tunés séparément).

Le score de pertinence est calculé comme le produit scalaire des deux vecteurs : score(Q, P) = q · p. C’est une opération triviale et ultra-rapide, ce qui permet de comparer la requête à des millions de passages pré-encodés en quelques millisecondes via un index ANN (FAISS, HNSW).

Indexation et recherche ANN

La force du dense retrieval en production tient à la séparation entre encodage et recherche. Les passages sont encodés une seule fois (offline) et leurs vecteurs sont stockés dans un index ANN (Approximate Nearest Neighbor). Les bibliothèques comme FAISS (Meta), HNSW (implémenté dans la plupart des bases vectorielles) permettent de trouver les k plus proches voisins parmi des millions de vecteurs en quelques millisecondes.

Pour donner un ordre de grandeur : le Wikipedia anglais (~21 millions de passages) encodé par DPR occupe environ 65 Go en float32. Avec la quantification binaire (Binary Passage Retriever), ce stockage se réduit à ~2 Go avec une perte de recall négligeable.

Entraînement d’un dense retriever

Apprentissage contrastif

Le dense retrieval s’entraîne par apprentissage contrastif. Pour chaque requête, on dispose d’un passage positif (réponse correcte) et de plusieurs passages négatifs (non pertinents). Le modèle apprend à maximiser la similarité entre requête et positif tout en minimisant la similarité avec les négatifs.

La loss function standard est la Negative Log-Likelihood (NLL) sur les in-batch negatives : dans un batch de B requêtes, les passages positifs des autres requêtes servent de négatifs. Avec un batch de 128, chaque requête est contrastée avec 127 négatifs sans coût d’encodage supplémentaire.

Le rôle critique des hard negatives

La qualité des négatifs d’entraînement est déterminante. Des négatifs aléatoires sont trop faciles : le modèle apprend à distinguer des thèmes complètement différents, ce qui est trivial. Les « hard negatives » sont des passages sémantiquement proches de la requête mais pas réellement pertinents. DPR utilise BM25 pour miner ces hard negatives : les passages bien classés par BM25 mais qui ne contiennent pas la réponse sont de bons candidats.

Les approches plus récentes comme ANCE (Approximate Nearest Neighbor Negative Contrastive Estimation) utilisent le dense retriever lui-même (mis à jour de façon asynchrone) pour miner des hard negatives encore plus informatifs pendant l’entraînement. RocketQA combine plusieurs stratégies de mining avec du denoising pour atteindre des performances supérieures.

Pré-entraînement spécialisé

Certains modèles comme Contriever (Meta), coCondenser ou RetroMAE utilisent un pré-entraînement spécifiquement conçu pour le retrieval (avant le fine-tuning contrastif). L’idée est de mieux préparer les représentations du Transformer pour la tâche de retrieval. Contriever, par exemple, utilise un pré-entraînement non supervisé qui permet un excellent zero-shot performance sans aucune donnée annotée.

Les principaux modèles de dense retrieval

Le benchmark MTEB (Massive Text Embedding Benchmark) est la référence pour comparer objectivement les modèles de dense retrieval sur 56 datasets couvrant 8 tâches (recherche, similarité, classification, clustering, etc.).

Le dense retrieval dans les pipelines RAG

Le dense retrieval est le composant de retrieval par défaut dans les architectures RAG (Retrieval-Augmented Generation). Le pipeline type :

1. Indexation : Les documents sont découpés en chunks (200 à 500 tokens), chaque chunk est encodé en vecteur dense par un modèle d’embedding, et les vecteurs sont stockés dans une base vectorielle.

2. Retrieval : Quand l’utilisateur pose une question, elle est encodée en vecteur et les k plus proches voisins sont récupérés de la base vectorielle. C’est le dense retrieval.

3. Enrichissement (hybrid search) : En parallèle, une recherche BM25 lexicale récupère des candidats supplémentaires. Les deux listes sont fusionnées par RRF.

4. Reranking : Un cross-encoder reclasse les candidats fusionnés pour ne garder que les plus pertinents.

5. Génération : Les top chunks sont injectés dans le prompt du LLM, qui génère la réponse.

Le dense retrieval seul (sans hybrid search ni reranking) donne des résultats corrects mais pas optimaux. Les meilleurs systèmes RAG en production utilisent toujours le pipeline complet. C’est la combinaison des approches qui fait la qualité du résultat final.

Limites du dense retrieval

Correspondances exactes manquées. C’est la faiblesse structurelle. L’article fondateur de DPR le reconnaît explicitement : sur la requête « Who plays Thoros of Myr in Game of Thrones? », DPR échoue à retrouver le passage contenant le nom « Thoros of Myr » alors que BM25 le trouve immédiatement. Les noms propres rares, les codes, les identifiants techniques sont mal capturés par les vecteurs denses.

Généralisation zero-shot. Un dense retriever entraîné sur un domaine spécifique peut mal généraliser sur un domaine non vu. Des études montrent que BM25 surpasse les dense retrievers en zero-shot dans certains scénarios. Les modèles récents (Contriever, E5, BGE) améliorent significativement cette situation grâce à un pré-entraînement plus diversifié.

Coût d’infrastructure. Le dense retrieval nécessite un GPU pour l’encodage initial (encoder 1 million de passages prend quelques heures sur un GPU moderne), une base vectorielle pour le stockage et la recherche, et un modèle d’embedding à maintenir. C’est plus complexe et coûteux qu’un simple index BM25.

Dépendance au modèle d’embedding. Les vecteurs sont propres au modèle qui les a générés. Changer de modèle impose de ré-encoder tout le corpus. Et la qualité du retrieval est plafonnée par les connaissances du modèle pré-entraîné : un modèle ne peut pas retrouver des informations dont les concepts sont absents de ses données d’entraînement.

Opacité. Contrairement à BM25 où vous pouvez tracer exactement quels mots ont matché, le dense retrieval est une boîte noire. Des travaux récents sur les sparse autoencoders permettent de décomposer les embeddings en unités interprétables, mais cette recherche en est encore à ses débuts.

Implémentation : de DPR à la production

DPR avec HuggingFace Transformers

from transformers import DPRQuestionEncoder, DPRQuestionEncoderTokenizer
from transformers import DPRContextEncoder, DPRContextEncoderTokenizer
import torch

# Charger les encodeurs DPR pré-entraînés
q_encoder = DPRQuestionEncoder.from_pretrained(
    "facebook/dpr-question_encoder-single-nq-base"
)
q_tokenizer = DPRQuestionEncoderTokenizer.from_pretrained(
    "facebook/dpr-question_encoder-single-nq-base"
)

ctx_encoder = DPRContextEncoder.from_pretrained(
    "facebook/dpr-ctx_encoder-single-nq-base"
)
ctx_tokenizer = DPRContextEncoderTokenizer.from_pretrained(
    "facebook/dpr-ctx_encoder-single-nq-base"
)

# Encoder une requête
question = "Who plays Thoros of Myr in Game of Thrones?"
q_input = q_tokenizer(question, return_tensors="pt")
q_embedding = q_encoder(**q_input).pooler_output  # (1, 768)

# Encoder des passages
passages = [
    "Paul Kaye portrays Thoros of Myr in the HBO series.",
    "Game of Thrones is a fantasy TV series by HBO.",
]
ctx_input = ctx_tokenizer(passages, return_tensors="pt", padding=True)
ctx_embeddings = ctx_encoder(**ctx_input).pooler_output  # (2, 768)

# Calculer les scores de similarité
scores = torch.matmul(q_embedding, ctx_embeddings.T)
print(scores)  # Le premier passage obtient un score plus élevé

En production avec Sentence Transformers

En pratique, la bibliothèque Sentence Transformers offre une interface plus simple et des modèles plus récents et performants que le DPR original :

from sentence_transformers import SentenceTransformer, util

# Modèle plus moderne que DPR
model = SentenceTransformer('intfloat/multilingual-e5-large')

# Encoder le corpus (fait une seule fois)
passages = ["passage 1...", "passage 2...", "..."]
# Préfixe "passage:" pour les documents, "query:" pour les requêtes
corpus_embeddings = model.encode(
    ["passage: " + p for p in passages],
    convert_to_tensor=True
)

# Recherche
query = "query: Qui joue Thoros dans Game of Thrones ?"
query_embedding = model.encode(query, convert_to_tensor=True)
hits = util.semantic_search(query_embedding, corpus_embeddings, top_k=5)

Les modèles E5 utilisent des préfixes (« query: », « passage: ») pour différencier l’encodage asymétrique entre requêtes courtes et passages longs. Cette distinction améliore significativement la qualité du retrieval.

Évolutions et directions de recherche

Hybrid dense-sparse : La combinaison du dense retrieval avec BM25 via le hybrid search est devenue le standard. Les vecteurs denses capturent le sens, BM25 capture les correspondances exactes. Les bases vectorielles modernes (Weaviate, Qdrant, Elasticsearch) supportent nativement cette combinaison.

Sparse learned representations (SPLADE) : Des modèles comme SPLADE produisent des vecteurs sparse appris (pas statiques comme BM25), qui combinent la structure d’un index inversé avec l’apprentissage neural. C’est un pont entre dense et sparse retrieval.

Late interaction (ColBERT) : ColBERT encode requête et documents en matrices de vecteurs au niveau des tokens, permettant une interaction fine tout en conservant la possibilité de pré-calculer les embeddings de documents. C’est un compromis entre la scalabilité du bi-encoder et la précision du cross-encoder.

Compression et quantification : Le Binary Passage Retriever (BPR) remplace les vecteurs float32 par des codes binaires, réduisant le stockage de 65 Go à 2 Go pour Wikipedia avec une perte de recall minime. La quantification scalaire (int8) réduit le stockage de 4x. Ces techniques sont essentielles pour le déploiement à très grande échelle.

Interprétabilité : Les sparse autoencoders appliqués aux embeddings DPR permettent de décomposer les vecteurs en unités interprétables, étiquetables par des humains. C’est une direction de recherche prometteuse pour rendre le dense retrieval plus transparent.

Verdict

Le dense retrieval a transformé la recherche d’information en passant de la correspondance de mots à la compréhension du sens. C’est le composant qui rend possible la recherche sémantique, le RAG et tous les systèmes d’IA qui ont besoin de retrouver de l’information pertinente dans de grands corpus. DPR a ouvert la voie en 2020, et les modèles actuels (E5, BGE, Cohere Embed, text-embedding-3) ont poussé la qualité bien au-delà du modèle fondateur.

Mais le dense retrieval n’est pas autosuffisant. Il rate les correspondances exactes, peut mal généraliser hors domaine, et produit des résultats opaques. Le pipeline optimal en 2026 combine dense retrieval + BM25 (hybrid search) + reranking par cross-encoder. Le dense retrieval est la brique centrale, pas la solution complète. C’est cette combinaison disciplinée d’approches complémentaires qui produit les meilleurs résultats en production.