les plus utilis\u00e9s en RAG<\/strong>.<\/figcaption><\/figure>\n\n\nUne fois les vecteurs obtenus, le classement est le m\u00eame pour toutes les familles. Pour une requ\u00eate
<\/span> <\/span>Ici \n\t\t\t\n\t\t\t\tLe vecteur en pointill\u00e9s a le double de la longueur de b mais pointe dans la m\u00eame direction : son cosinus avec a est inchang\u00e9. L’angle compte, pas la longueur.<\/figcaption><\/figure>\n\n\nUn d\u00e9tail qui relie les deux familles : dans sa forme la plus simple, un retriever peut tr\u00e8s bien calculer des TF-IDF pour tous les documents, puis le cosinus entre chacun et la requ\u00eate, et classer selon ce score. La m\u00e9canique du classement est donc la m\u00eame ; ce qui change, c’est la mani\u00e8re de fabriquer les vecteurs<\/strong>.<\/p>\nLe reste de la famille<\/h3>\n Les embeddings contextuels suffisent pour b\u00e2tir un syst\u00e8me de base, mais d’autres m\u00e9thodes existent :<\/p>\n
\nla r\u00e9cup\u00e9ration sparse apprise<\/em> (SPLADE, DeepCT) et la r\u00e9cup\u00e9ration dense<\/em> (DPR, ANCE) ;<\/li>\nla r\u00e9cup\u00e9ration qui combine sparse et dense (ColBERT) ;<\/li>\n le cross-encoder<\/em>, qui compare directement la paire requ\u00eate-document ;<\/li>\nla r\u00e9cup\u00e9ration par graphes, qui interroge les relations entre entit\u00e9s plut\u00f4t que des vecteurs de texte.<\/li>\n<\/ul>\nTu n’as pas \u00e0 tout coder : LangChain propose des retrievers d\u00e9j\u00e0 int\u00e9gr\u00e9s. Ce sont les bases vectorielles elles-m\u00eames (FAISS, Pinecone, Milvus, Weaviate, ces deux derniers offrant une recherche hybride), les services des fournisseurs cloud (Amazon Kendra, Azure AI Search, Google Vertex AI Search) ou des connecteurs vers des ressources web (Wikip\u00e9dia, Arxiv, AskNews).<\/p>\n
Sous le capot : un encodeur ou deux ?<\/h2>\n Comment un retriever dense calcule-t-il son score ? Deux architectures s’opposent, et leur diff\u00e9rence explique une bonne part de ce qui suit.<\/p>\n
Avec un encodeur unique<\/strong>, on donne au mod\u00e8le la requ\u00eate et le document en m\u00eame temps. Il peut alors faire jouer l’auto-attention entre tous leurs mots, et la sortie est un score de similarit\u00e9. C’est pr\u00e9cis, mais le texte entier (requ\u00eate plus document) doit tenir dans la fen\u00eatre du mod\u00e8le, 512 jetons pour BERT, et il faut repasser la requ\u00eate avec chacun des documents du corpus : le co\u00fbt devient prohibitif.<\/p>\nLe bi-encodeur<\/strong> coupe le probl\u00e8me en deux : un encodeur lit la requ\u00eate, un autre lit chaque document. Les vecteurs des documents sont calcul\u00e9s une fois et rang\u00e9s dans une base ; \u00e0 chaque requ\u00eate, il ne reste qu’\u00e0 comparer son vecteur \u00e0 ceux de la base par le cosinus. C’est bien plus rapide, mais moins pr\u00e9cis, car on perd une partie des interactions entre les termes de la requ\u00eate et ceux du document.<\/p>\n\n\n\nArchitecture<\/th>\n Ce qu’elle lit<\/th>\n Atout<\/th>\n Limite<\/th>\n<\/tr>\n<\/thead>\n \n\nEncodeur unique<\/td>\n Requ\u00eate et document ensemble<\/td>\n Interaction fine entre leurs mots<\/td>\n Il faut le repasser sur tout le corpus<\/td>\n<\/tr>\n \nBi-encodeur<\/td>\n Requ\u00eate d’un c\u00f4t\u00e9, chaque document de l’autre<\/td>\n Vecteurs de documents calcul\u00e9s d’avance, recherche rapide<\/td>\n Interactions mot \u00e0 mot perdues<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\t\t\t\n\t\t\t\tSur ce sch\u00e9ma, le retriever est tout ce qui se trouve entre la question et les \u00ab documents similaires \u00bb : un mod\u00e8le d’embedding, puis un index. Le LLM n’arrive qu’apr\u00e8s.<\/figcaption><\/figure>\n\n\nLe choix de l’encodeur n’est pas anodin. Il p\u00e8se sur le co\u00fbt (un embedder est un Transformer : plus il est grand, plus le calcul co\u00fbte, et un encodeur ferm\u00e9 facture son API \u00e0 l’usage), sur le stockage (plus les vecteurs sont grands, plus il co\u00fbte), sur la latence, et sur la performance. Certains encodeurs sont sp\u00e9cialis\u00e9s (finance, m\u00e9decine, science, code) et certains g\u00e8rent une centaine de langues. Un bon point de d\u00e9part est le classement MTEB de Hugging Face, mais ses r\u00e9sultats sont souvent auto-d\u00e9clar\u00e9s et peuvent surestimer les capacit\u00e9s d’un mod\u00e8le si des donn\u00e9es de test ont fui dans son entra\u00eenement : teste plusieurs mod\u00e8les sur tes propres donn\u00e9es<\/strong>.<\/p>\nReste \u00e0 stocker ces vecteurs. FAISS n’est pas con\u00e7u pour cr\u00e9er, modifier ou supprimer des donn\u00e9es : il convient si la base est immuable. Les bases SQL qui acceptent les vecteurs passent mal \u00e0 l’\u00e9chelle. Les bases d\u00e9di\u00e9es sont en g\u00e9n\u00e9ral la meilleure solution pour la performance, gr\u00e2ce \u00e0 la recherche approch\u00e9e des plus proches voisins, dont HNSW sacrifie un peu de pr\u00e9cision mais va bien plus vite qu’une recherche exacte comme l’indexation Flat.<\/p>\n
Voir un retriever dense tourner<\/h2>\n Voici la fonction de r\u00e9cup\u00e9ration d’un agent qui recommande des films. Les descriptions de films ont \u00e9t\u00e9 d\u00e9coup\u00e9es en passages, transform\u00e9es en vecteurs par un encodeur embedder<\/code> et rang\u00e9es dans une collection Chroma, collection<\/code>. Au moment de la requ\u00eate, on r\u00e9utilise le m\u00eame encodeur<\/strong> pour la question.<\/p>\ndef retrieve_documents(query, collection, top_k=5):\n query_embedding = embedder.encode(query).tolist()\n results = collection.query( query_embeddings=[query_\nembedding], n_results=top_k )\n chunks = []\n titles = []\n for document in results['metadatas'][0]:\n chunks.append(document['chunk'])\n titles.append(document['original_title'])\n return chunks, titles\n<\/code><\/pre>\nLis la fonction comme une d\u00e9finition de retriever : elle prend une requ\u00eate, un nombre top_k<\/code>, et rend une liste de passages avec leurs titres, rang\u00e9s du plus proche au plus lointain. results['metadatas'][0]<\/code> d\u00e9signe les m\u00e9tadonn\u00e9es de notre unique requ\u00eate, d’o\u00f9 l’on extrait le texte du passage et le titre du film d’origine.<\/p>\nUne question en langage courant passe donc par exactement la m\u00eame porte que le mot \u00ab won \u00bb de tout \u00e0 l’heure : requ\u00eate en entr\u00e9e, liste class\u00e9e en sortie. Seule la d\u00e9finition de \u00ab proche \u00bb a chang\u00e9.<\/p>\n
Quand la question ne ressemble pas aux documents<\/h2>\n Le retriever compare une requ\u00eate \u00e0 des documents. Si les deux ne sont pas formul\u00e9s de la m\u00eame fa\u00e7on, la bonne r\u00e9ponse peut dormir au fond de la liste. On agit alors sur la requ\u00eate avant de la lui confier, souvent avec l’aide d’un LLM.<\/p>\n
\nLa d\u00e9composition<\/strong> d\u00e9coupe une question complexe en sous-requ\u00eates ind\u00e9pendantes. Aucun passage ne r\u00e9pond peut-\u00eatre \u00e0 \u00ab qui a invent\u00e9 le t\u00e9l\u00e9graphe et le t\u00e9l\u00e9phone ? \u00bb, mais chacune des deux moiti\u00e9s trouvera le sien.<\/li>\nLa r\u00e9\u00e9criture<\/em> reformule un \u00e9nonc\u00e9 en requ\u00eate de recherche exploitable : \u00ab je n’arrive pas \u00e0 envoyer d’e-mails depuis mon t\u00e9l\u00e9phone \u00bb devient \u00ab \u00e9tapes de d\u00e9pannage pour r\u00e9soudre les probl\u00e8mes d’envoi d’e-mails sur smartphone \u00bb.<\/li>\nL’expansion<\/em> ajoute des termes ou g\u00e9n\u00e8re plusieurs variantes de la requ\u00eate (cinq, par exemple), ce qui augmente le rappel. Mal ma\u00eetris\u00e9e, elle peut r\u00e9duire la pr\u00e9cision et diluer l’intention d’origine.<\/li>\n<\/ul>\nLa plus surprenante est HyDE<\/strong> (Hypothetical Document Embeddings<\/em>). On demande au LLM d’\u00e9crire une r\u00e9ponse hypoth\u00e9tique \u00e0 la question, sans consulter la base, puis on utilise le vecteur de cette r\u00e9ponse pour la recherche. L’id\u00e9e : m\u00eame imparfaite, une r\u00e9ponse invent\u00e9e ressemble davantage aux vrais passages pertinents que la question brute.<\/p>\noriginal_query = "How does climate change affect polar bears?"\nsystem_prompt = "You are an expert in climate change and arctic life."\nhyde_prompt = f"Generate an answer to the question: {original_query}"\n\nfrom openai import OpenAI\nclient = OpenAI()\nresponse = client.chat.completions.create(\n model="gpt-4o-mini",\n messages=[\n {"role": "system", "content": system_prompt},\n {"role": "user", "content": hyde_prompt}\n ]\n)\nhy_answer = response.choices[0].message.content\n\nembeddings = OpenAIEmbeddings(model="text-embedding-3-large")\nhyde = embeddings.embed_query(hy_answer)\n<\/code><\/pre>\nLe code fait deux choses : le LLM gpt-4o-mini<\/code> r\u00e9dige hy_answer<\/code>, puis embed_query<\/code> convertit cette r\u00e9ponse en vecteur hyde<\/code>. C’est ce vecteur, et non celui de la question, qui sert \u00e0 interroger l’index. OpenAIEmbeddings<\/code> est la classe de la biblioth\u00e8que langchain_openai<\/code> d\u00e9j\u00e0 crois\u00e9e dans les exemples de retrievers int\u00e9gr\u00e9s.<\/p>\nLe LLM n’a pas besoin de conna\u00eetre la vraie r\u00e9ponse, ce n’est m\u00eame pas le but : il sait seulement reconna\u00eetre dans la question des motifs pertinents, et ce sont eux qui font remonter les bons passages. HyDE aide surtout quand le rappel est faible, ou quand les documents viennent d’un domaine que l’encodeur n’a jamais vu.<\/p>\n
Un retriever ne travaille pas seul<\/h2>\n Quand le retriever est entour\u00e9, ses d\u00e9fauts se compensent.<\/p>\n
Mots et sens, ensemble<\/h3>\n Les retrievers lexicaux et denses ont des angles morts oppos\u00e9s : certains passages ne sont pertinents que parce qu’ils contiennent un mot-cl\u00e9 pr\u00e9cis (un nom de produit, de personne), alors que tous les passages qui contiennent ce mot ne le sont pas, surtout pour une requ\u00eate qui vise un concept. La recherche hybride<\/a> combine les deux et choisit combien de passages prendre \u00e0 chaque type de recherche ; c’est l’un des composants les plus utilis\u00e9s dans les pipelines actuels.<\/p>\nDans l’impl\u00e9mentation vue en exemple, la fonction calcule l’embedding de la requ\u00eate, interroge ChromaDB d’un c\u00f4t\u00e9 et Elasticsearch de l’autre, puis concat\u00e8ne les deux listes de r\u00e9sultats. On peut aussi aiguiller la requ\u00eate avant de chercher : s’il y a des mots-cl\u00e9s pr\u00e9cis, une recherche par mots-cl\u00e9s, sinon une recherche s\u00e9mantique. La r\u00e8gle ci-dessous en est la version la plus simple, o\u00f9 "specific_keyword"<\/code> est un mot-cl\u00e9 fictif \u00e0 remplacer par le tien.<\/p>\ndef advanced_query_routing(query):\n """\n Determines the retrieval method based on the presence of specific\nkeywords in the query.\n Args:\n query (str): The user's query.\n Returns:\n str: 'textual' if the query requires text-based retrieval,\n'vector' otherwise.\n """\n if "specific_keyword" in query:\n return "textual"\n else:\n return "vector"\n<\/code><\/pre>\nChercher large, puis trier<\/h3>\n Voici un dilemme : augmenter k<\/em> fait monter le rappel de la r\u00e9cup\u00e9ration, mais donne trop de mati\u00e8re au LLM. Le reranking<\/strong> le r\u00e9sout en deux temps. D’abord une r\u00e9cup\u00e9ration classique d’un grand nombre de passages ; ensuite un second mod\u00e8le, le reranker, r\u00e9ordonne cette pr\u00e9s\u00e9lection et ne garde que les k<\/em> meilleurs.<\/p>\nLe reranker prend en compte l’information contrast\u00e9e avec la requ\u00eate et lit chaque passage en contexte<\/em> avec elle, ce que ne fait pas un bi-encodeur. On en rencontre plusieurs types :<\/p>\n\nles cross-encodeurs<\/strong> (comme BGE), qui lisent la requ\u00eate et un passage \u00e0 la fois et renvoient une similarit\u00e9 entre 0 et 1 ;<\/li>\nles rerankers multi-vecteurs<\/em> (comme ColBERT), moins gourmands en calcul, car l’interaction entre les deux textes intervient en fin de traitement ;<\/li>\nles LLM<\/em> utilis\u00e9s comme rerankers : pointwise<\/em> (un document \u00e0 la fois), pairwise<\/em> (deux documents, lequel est le plus pertinent ?) ou listwise<\/em> (une liste \u00e0 classer, avec un risque de co\u00fbt \u00e9lev\u00e9) ;<\/li>\ndes LLM ajust\u00e9s au classement, comme RankT5.<\/li>\n<\/ul>\nLe cross-encodeur n’est donc rien d’autre que l’encodeur unique de tout \u00e0 l’heure : trop lent pour balayer un corpus entier, il trouve sa place sur une pr\u00e9s\u00e9lection courte. Apr\u00e8s le reranking, on peut encore filtrer les passages dont la similarit\u00e9 est sous un seuil, qui ne contiennent pas certains mots-cl\u00e9s, ou qui sont plus anciens qu’une date.<\/p>\n
Ce qu’un retriever ne fait pas<\/h2>\n Il ne distingue pas toujours \u00ab proche \u00bb de \u00ab pareil \u00bb.<\/strong> La similarit\u00e9 entre deux embeddings vient du fait que des mots apparaissent dans la m\u00eame fen\u00eatre de contexte : le mod\u00e8le ne distingue donc pas les synonymes des antonymes. Cette limite est d\u00e9crite pour les embeddings de mots, mais elle rappelle que \u00ab proche \u00bb n’est pas \u00ab pertinent \u00bb.<\/p>\nIl ignore ton domaine.<\/strong> Les benchmarks g\u00e9n\u00e9ralistes mesurent une performance g\u00e9n\u00e9rale, qui peut \u00eatre mauvaise dans ton domaine ou pour ta t\u00e2che. Quand le mod\u00e8le d’embeddings et le mod\u00e8le de g\u00e9n\u00e9ration sont d\u00e9velopp\u00e9s et ajust\u00e9s s\u00e9par\u00e9ment, leurs r\u00e9sultats peuvent \u00eatre incoh\u00e9rents dans les domaines sp\u00e9cialis\u00e9s ; les ajuster conjointement pour un domaine de niche corrige ce d\u00e9calage. L’entra\u00eenement peut prendre trois formes : ajuster d’abord le retriever puis le geler (retriever-first<\/em>, adapt\u00e9 quand la pr\u00e9cision de la recherche prime, comme dans un moteur de recherche juridique), laisser un LLM superviser l’entra\u00eenement du retriever (LLM-first<\/em>), ou entra\u00eener les deux ensemble de bout en bout.<\/p>\nIl ne cherche pas que du texte.<\/strong> Pour des contenus m\u00ealant image, son et vid\u00e9o, la r\u00e9cup\u00e9ration d\u00e9pend de la strat\u00e9gie d’embeddings : similarit\u00e9 classique avec des embeddings partag\u00e9s, r\u00e9cup\u00e9ration multi-vecteurs qui interroge chaque espace d’embeddings propre \u00e0 une modalit\u00e9, ou r\u00e9cup\u00e9ration textuelle suivie de la r\u00e9cup\u00e9ration des fichiers bruts associ\u00e9s.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tLes points proches sur ce sch\u00e9ma repr\u00e9sentent des contenus de m\u00eame sens mais de natures diff\u00e9rentes : un mot, une photo et un son peuvent voisiner dans le m\u00eame espace.<\/figcaption><\/figure>\n\n\nIl ne s’am\u00e9liore pas seul.<\/strong> Chacun de ses d\u00e9fauts a sa rustine, que tu as d\u00e9j\u00e0 crois\u00e9e dans cet article :<\/p>\n\n\n\nCe que le retriever rate<\/th>\n Ce qu’on ajoute<\/th>\n<\/tr>\n<\/thead>\n \n\nRequ\u00eate complexe, faible rappel<\/td>\n Transformation de la requ\u00eate : d\u00e9composition, r\u00e9\u00e9criture, expansion<\/td>\n<\/tr>\n \nMots-cl\u00e9s pr\u00e9cis non retrouv\u00e9s<\/td>\n Recherche hybride : BM25 plus vecteurs, score pond\u00e9r\u00e9<\/td>\n<\/tr>\n \nTypes de requ\u00eates tr\u00e8s vari\u00e9s<\/td>\n Routage de la requ\u00eate vers le bon outil<\/td>\n<\/tr>\n \nPassages pertinents perdus par un top-k arbitraire<\/td>\n Reranking<\/td>\n<\/tr>\n \nDocuments d’un autre domaine<\/td>\n R\u00e9ponse hypoth\u00e9tique (HyDE) ou questions hypoth\u00e9tiques par passage<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\ud83d\udccc \u00c0 retenir<\/strong> Un retriever est une fonction qui transforme une requ\u00eate en liste class\u00e9e. Mots exacts, vecteurs ou graphe changent la fa\u00e7on de trier, jamais le contrat : de l’ordre d\u00e9pend tout ce qui passe ensuite.<\/p>\n<\/blockquote>\n\n\n<\/p>\n","protected":false},"excerpt":{"rendered":"
Un retriever re\u00e7oit une question et renvoie des passages class\u00e9s par pertinence. D\u00e9couvre ses familles (mots, vecteurs, hybride), du code et ses limites.<\/p>\n","protected":false},"author":1,"featured_media":462,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-463","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-rag"],"_links":{"self":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts\/463","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/comments?post=463"}],"version-history":[{"count":4,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts\/463\/revisions"}],"predecessor-version":[{"id":802,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/posts\/463\/revisions\/802"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/media\/462"}],"wp:attachment":[{"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/media?parent=463"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/categories?post=463"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ranksignal.fr\/blog\/wp-json\/wp\/v2\/tags?post=463"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Une](\"https:\/\/www.ranksignal.fr\/wp-content\/uploads\/2026\/10\/b1_ch04_role_retriever-scaled.png\")