Explication de la génération augmentée par la récupération d’informations : combler les lacunes de connaissance des LLM
Pourquoi les LLM hallucinent et perdent en qualité, et comment la génération augmentée par récupération de données y remédie étape par étape : segmentation en blocs, embeddings, récupération de données et amélioration du prompt.
Sources: What LLMs Often Get Wrong At, And How RAG Cures That
Où les LLM ont tendance à trébucher
Pensez aux examens oraux finaux. On révise tout la veille au soir, on entre dans la salle, on parle avec assurance à l’examinateur et on espère que tout se passera bien. Puis l’examinateur demande : « Pourquoi avez-vous choisi cette approche particulière pour votre projet ? » Soudain, le silence s’installe.
Les LLM se heurtent au même obstacle.
Ils sont conçus pour produire des réponses qui semblent convaincantes. Cela signifie qu’ils ne savent souvent pas comment admettre « Je ne sais pas ».
Il y a aussi le problème des connaissances obsolètes.
Imaginez que cet même examinateur demande :
« Pourquoi avez-vous choisi cette méthode alors qu’il en existe une meilleure aujourd’hui ? »
Vous seriez dans l’impasse.
Les LLM rencontrent ce problème précis chaque fois que les faits sur lesquels ils ont été entraînés ne reflètent plus la réalité.
Ainsi, la vraie question devient : Comment fournir à un LLM les bonnes informations, exactement au moment où il en a besoin ?
Entrée dans la génération augmentée par la récupération d’informations
Ne vous laissez pas effrayer par le nom. Il s’agit en réalité d’un processus très simple : localiser les informations pertinentes, les transmettre au modèle et le laisser les transformer en réponse.
C’est l’idée principale.
Décomposons ce qui se passe réellement derrière cette description.
Formulation du problème
Supposons que vous développiez un assistant IA interne pour une entreprise.
Cette entreprise dispose d’une quantité importante de documents : un manuel du personnel, des FAQ internes, des politiques de sécurité, etc.
Lorsque l’assistant sera opérationnel, les gens commenceront naturellement à l’utiliser. Quelqu’un tape :
"Combien de jours de congé parental ai-je droit ?"
Le problème, c’est que le modèle ne dispose d’aucune conscience intégrée des politiques spécifiques de votre entreprise. De plus, vous ne pouvez pas simplement lui fournir des centaines de documents longs dans la requête en espérant une réponse claire — cela risque de surcharger la fenêtre de contexte, de confondre le modèle et d’entraîner d’autres problèmes.
Comment fonctionne réellement RAG
Au lieu de compter sur les connaissances internes du LLM pour répondre, nous extrayons d’abord les documents pertinents de notre propre base de connaissances. Ces documents sont ensuite transmis au LLM.
Le LLM utilise ces informations fournies pour élaborer sa réponse.
En d’autres termes, le modèle n’a pas besoin de mémoriser tout ce qui existe. Il a simplement besoin des informations correctes fournies au moment opportun.
Cela soulève la question suivante : comment déterminez-vous ce qui est pertinent en premier lieu ?
Récupération
Envoyer chaque document à l’LLM pour chacune des questions serait gaspilleur et lent. Il est donc nécessaire de trouver un moyen de isoler d’abord les fragments pertinents, car examiner tout le contenu à chaque fois est coûteux et inefficace.
Pour ce faire, les documents sont divisés en parties plus petites appelées chunks. Un chunk peut concerner les règles relatives au congé de maternité, un autre peut décrire les procédures de sécurité, et un troisième encore peut expliquer le fonctionnement des remboursements de dépenses.
Localiser le chunk approprié
"Combien de temps puis-je prendre de congé après avoir eu un enfant ?"
Pendant ce temps, le document lui-même pourrait indiquer : "Les employés ont droit à 26 semaines de congé de maternité."
Les formulations diffèrent, mais le sens est identique. Pour combler cette lacune, les systèmes RAG s’appuient sur des embeddings.
À quoi servent les embeddings
Ces embeddings se trouvent à l’intérieur d’une base de données vectorielles. Lorsqu’une nouvelle question arrive, elle est également convertie en un embedding, et le système cherche les fragments correspondants les plus proches.
Le résultat est un ensemble de fragments pertinents, qui sont ensuite transmis au LLM en tant que contexte de soutien.
Augmentation
Lorsque les fragments pertinents ont été identifiés, l’étape suivante consiste à les combiner.
Ils sont insérés dans la fenêtre de contexte du LLM ensemble avec la question originale :
Context:
Employees are entitled to 26 weeks of parental leave.
Question:
How long can I stay away from work after having a baby?
À ce stade, le LLM dispose de tout ce dont il a besoin pour répondre avec précision.
Génération
C’est maintenant que le LLM excelle : il produit la réponse réelle.
Il lit à la fois la question de l’utilisateur et le contexte récupéré, puis génère une réponse :
« Vous avez droit à 26 semaines de congé parental. »
Et c’est ainsi que le cycle se termine : Récupérer → Compléter → Générer.
Le problème
Le LLM ne peut raisonner qu’en se basant sur le contexte qui a été récupéré. Si le mauvais fragment est sélectionné, la réponse finale peut malgré tout être incorrecte, même si le processus s’est déroulé correctement.
Considérez ce scénario :
Question : « Combien de temps dure le congé parental ? »
Extrait obtenu : « Informez votre manager 30 jours avant de prendre le congé parental. »
Réponse obtenue : l’assistante indique à l’employé qu’il doit informer son manager un mois entier à l’avance avant de commencer son congé parental — ce qui est techniquement lié au sujet, mais ne répond pas réellement à la durée du congé.
Améliorer la qualité de l’extraction
Alors, comment s’assurer que l’étape d’extraction met en évidence le bon matériel ?
Plusieurs facteurs sont importants ici :
Stratégie de segmentation : La manière dont les documents sont divisés influence le fait que le contexte pertinent reste intégral au sein d’un même extrait.
Qualité des embeddings : Des embeddings plus puissants facilitent l’alignement de la question d’un utilisateur avec le contenu qui y répond réellement.
Recherche technique : La combinaison d’une recherche par similarité sémantique et d’une recherche traditionnelle par mots-clés permet de prendre en compte à la fois le sens et l’expression exacte.
Réclassement : On récupère d’abord un lot initial de fragments candidats, puis on applique une deuxième étape de réclassement pour mettre en évidence ceux qui sont les plus utiles.
L’objectif fondamental reste simple : mettre le contexte approprié devant le LLM.
En résumé
RAG n’est pas un tour de magie.
Localiser les informations correctes, les transmettre au LLM et laisser le modèle générer la réponse.
C’est tout le mécanisme.
Le LLM n’a jamais eu besoin de connaître tout dès le début.
Il a seulement besoin du contexte adéquat, fourni au moment opportun.
C’est là le principe fondamental de RAG : du mauvais input entraîne un mauvais output, tandis qu’un input de qualité produit un output de qualité.
Désormais, chaque fois que quelqu’un mentionnera « RAG ceci, RAG cela », vous saurez exactement de quoi il parle.