Guide

Statut éditorial : Validé

Utiliser un retriever pour le RAG avec LangChain

Construire et évaluer la couche de récupération d’un RAG LangChain avec filtres, recherche hybride et citations.

Classification du contenu

Types

  • RAG et recherche vectorielle

Technologies

Niveau
Intermédiaire
Publié le
10 août 2026
Dernière relecture
31 août 2026
Prochaine vérification
3 mars 2027

Dans LangChain, un retriever est une interface qui reçoit une requête non structurée et renvoie une liste de Documents. Il est plus général qu’une base vectorielle : il peut interroger un index lexical, un service externe ou fusionner plusieurs recherches. C’est lui qui décide quelles preuves atteignent le modèle.

Construire une première référence

Chargez des sources, découpez-les en fragments et conservez des métadonnées stables : identifiant, URL, version, langue, tenant et droits. Créez les embeddings puis la base vectorielle, et exposez-la comme retriever. Commencez avec une recherche simple et un petit top-k avant d’ajouter compression ou reranking.

Filtrer avant de classer

Appliquez les autorisations et la portée documentaire avant la recherche. Le modèle ne doit jamais choisir le tenant. Les filtres de date, produit, langue ou version réduisent le bruit et évitent qu’un score sémantique rapproche des documents interdits. Gardez les identifiants de source jusque dans la réponse pour produire des citations.

Améliorer seulement après mesure

Une recherche hybride combine vocabulaire exact et similarité sémantique. Un reranker réordonne davantage de candidats avec un modèle plus précis. La réécriture de requête aide certaines questions ambiguës. Chaque couche ajoute latence et coût : ne la conservez que si elle améliore le rappel ou la précision sur votre dataset.

Évaluer séparément

Pour chaque question, indiquez les fragments attendus. Mesurez s’ils figurent dans les premiers résultats, puis analysez scores, métadonnées et passages manqués. Évaluez ensuite fidélité et pertinence de la réponse. Une réponse plausible ne doit pas masquer un retriever qui a choisi la mauvaise source.

FAQ

Un retriever doit-il utiliser des embeddings ?

Non. Il peut encapsuler BM25, une API de recherche ou une combinaison.

Augmenter top-k améliore-t-il toujours le RAG ?

Non. Trop de passages diluent le contexte et augmentent le coût.

Faut-il créer une classe personnalisée ?

Seulement si l’interface standard ou un Runnable simple ne suffit pas à votre logique.

Retriever avec filtres et score minimal

~~~python from langchain_chroma import Chroma from langchain_openai import OpenAIEmbeddings

store = Chroma( collection_name="documentation", embedding_function=OpenAIEmbeddings(model="text-embedding-3-small"), ) retriever = store.as_retriever( search_type="similarity_score_threshold", search_kwargs={ "k": 6, "score_threshold": 0.72, "filter": {"tenant_id": "acme"}, }, ) documents = retriever.invoke("Comment réinitialiser un mot de passe ?") context = "\n\n".join( f"[{doc.metadata.get('source')}] {doc.page_content}" for doc in documents ) ~~~

Le filtre de tenant doit venir de l’identité authentifiée, jamais du texte de la question. Si aucun document ne dépasse le seuil, répondez que les sources sont insuffisantes au lieu de forcer une génération. Évaluez séparément le rappel du retriever et la qualité de la réponse : un bon LLM ne compense pas durablement des documents introuvables.

Sources utilisées