Qu’est-ce que RAG et pourquoi est-il nécessaire ?

Gains :

Expliquer que RAG injecte du contexte sans modifier les poids du modèle et fonctionne avec une logique « d'examen à livre ouvert »
Comparaison de RAG avec des approches de réglage fin et de contexte long en fonction du coût, de la rapidité et du scénario d'utilisation
Répertorier les étapes d'un pipeline RAG typique composé de phases d'indexation et de requête

Quelle que soit la puissance d'un modèle de langage (une intelligence artificielle qui comprend et produit du texte ; nous l'appellerons désormais modèle pour faire court), il ne connaît pas le contrat que votre entreprise a signé hier, votre page wiki interne (base de connaissances interne) ou la note de version publiée ce matin. Le modèle est limité aux connaissances générales à la date de sa formation ; C'est ce qu'on appelle la « date limite de scolarité ». RAG (Retrieval-Augmented Generation) comble exactement cette lacune : il trouve les documents de l'entreprise liés à la question, les donne au modèle comme contexte (c'est-à-dire le texte supplémentaire qu'il lira en produisant la réponse) et fait produire la réponse en fonction de ce contexte.

Dans cette unité, nous verrons clairement ce qu'est RAG, quand il est préféré à quelles alternatives, et les étapes d'un pipeline RAG typique. Toutes les unités suivantes approfondiront les parties de cette carte une par une.

L'idée de base de RAG : examen à livre ouvert

Expliquons RAG en une phrase : "Trouvez d'abord le document pertinent, puis demandez au modèle de lire ce document et d'imprimer la réponse en conséquence."

L’analogie la plus utile est la suivante : RAG fait passer le modèle d’un « examen à livre fermé » à un « examen à livre ouvert ». Lors de l'examen à livre fermé, l'étudiant répond uniquement de mémoire ; Il existe un risque élevé d’inventer ce dont vous ne vous souvenez pas. Lors de l'examen à livre ouvert, l'étudiant répond en regardant la source placée devant lui. Dans RAG, le modèle ne répond plus à partir de sa propre mémoire, mais à partir du texte actuel et spécifique que vous lui donnez.

Point critique : RAG ne modifie pas les poids du modèle, c'est-à-dire les milliards de paramètres numériques que le modèle a appris. Vous ne recyclez pas le modèle. Pour chaque question, vous injectez des morceaux de texte pertinents pour cette question dans l'invite (texte d'instruction envoyé au modèle). Vous n'avez donc pas besoin de recycler le modèle lorsqu'un document est mis à jour ; il vous suffit d'actualiser l'enregistrement concerné dans la base de données de recherche.

Indice : Deux questions déterminent la qualité du RAG : (1) Avez-vous trouvé le bon document ? (2) Le modèle l'a-t-il lu correctement ? Le premier est la « qualité de récupération », le second est la « qualité de génération ». Les deux sont mesurés et améliorés séparément.

RAG, mise au point ou contexte long ?

Trois chemins sont souvent confondus lorsqu’on cherche une solution à un problème organisationnel. Clarifions leurs différences. Le réglage fin consiste à mettre à jour les pondérations du modèle avec vos données et à lui apprendre un nouveau comportement/style. Un contexte long signifie remplir tous les documents directement dans l'invite sans aucune sélection.

Approche

Qu'est-ce que

Quand est-ce approprié ?

Coût / Risque

CHIFFON

Injecte le document pertinent comme contexte

Informations fréquemment changeantes, détaillées et spécifiques

Faible ; facile à mettre à jour, la source peut être citée

Mise au point

Met à jour les poids avec de nouvelles données

Style/format/enseignement des langues fixes

Élevé ; Recyclage requis à chaque mise à jour

Contexte long uniquement

Remplit tous les documents dans l'invite

Petit ensemble de documents stationnaires

Le coût du jeton et le risque de « perdre la partie médiane » augmentent

En règle générale : le réglage fin apprend au modèle à parler ; RAG indique au modèle ce qu'il doit savoir. Dans la plupart des scénarios d'entreprise, RAG est essayé en premier car il est bon marché, peut être mis à jour et peut afficher la source de la réponse. Un contexte long est raisonnable si l'ensemble de documents est vraiment petit et fixe (par exemple, un seul manuel de 20 pages) ; Mais avec des milliers de pages, cela coûte cher et le modèle peut manquer des informations au milieu d'un long texte.

Un pipeline RAG typique

RAG se compose de deux phases principales : l'indexation (préparation, effectuée une fois ou périodiquement) et l'interrogation (s'exécute sur chaque question de l'utilisateur).

Indexation étape par étape (hors ligne, sans attente de l'utilisateur) :

Collecter : extraire des documents de sources (PDF, wiki, système de tickets, base de données, e-mail).
Chunking : divisez un texte long en morceaux plus petits et gérables.
Intégrer : convertissez chaque partie en intégration (le vecteur numérique qui porte la signification du texte).
Enregistrer : écrivez les vecteurs avec le texte et les métadonnées (source, date, informations d'autorisation) dans la base de données de vecteurs.

Requête étape par étape (en ligne, pendant que l'utilisateur attend) :

Convertissez la question de l'utilisateur en intégration.
Récupérez les pièces les plus similaires dans la base de données vectorielles.
Placez ces éléments + cette question dans un modèle d'invite.
Obtenez la réponse contextuelle et ses sources à partir du modèle.

# Aperçu conceptuel de la phase d'enquête (ne dépend pas de la langue) question = "Combien de jours de congé annuel ?" Fitting.CONTEXT:{parts}QUESTION : {question}"""answer = model.uret(prompt) # par ex. modèle : claude-opus-4-8

Ce flux est une carte de chaque étape, que nous détaillerons une par une dans les unités suivantes.

Invite faible/Invite forte

Même avec le même contexte RAG, la qualité de l'invite change la réponse.

Invite faible (ouverte à l'ajustement du modèle, ne nécessite pas de ressources) :

Utilisez ces informations et dites congé annuel : {parts}. Question : {question}

Invite puissante (mise à la terre + autorisation "Je ne sais pas" + demande de ressources) :

Répondez uniquement en fonction du CONTEXTE ci-dessous. S'il n'y a pas de réponse claire dans le contexte, écrivez « Je n'ai pas trouvé d'informations à ce sujet dans la documentation » ; Ne devinez pas. Ajoutez la balise [Source : file_name] de l'article sur lequel vous comptez à la fin de votre réponse. CONTEXTE : {pièces} QUESTION : {question}

Trois mini-étuis

Cas 1 — Assistant RH (Ressources Humaines). Une entreprise dispose d’un manuel RH de 340 pages et les salariés posent en moyenne 90 questions par jour. Des ajustements ont été tentés, mais comme le manuel était mis à jour mensuellement, un recyclage était nécessaire à chaque fois ; Le coût atteignait des milliers de dollars par mois. Après le passage à RAG, la mise à jour a été réduite à l'étape de « réindexation du document » (minutes) et le taux de bonnes réponses est passé de 71 % à 93 % en mesure manuelle.

Cas 2 – Support client. L'équipe d'assistance dispose de 12 000 tickets résolus et de 800 articles d'aide. Il faut en moyenne 4 minutes à un représentant pour trouver manuellement une réponse. Lorsque l'assistant du RAG apportait les 5 enregistrements les plus pertinents et produisait une ébauche de réponse, le temps était réduit à 40 secondes ; Mais l'équipe a pris conscience du risque de « paraître incertain en apportant le mauvais article » et a rendu obligatoire la citation de la source.

Cas 3 — Droit. Une équipe contractante a demandé : « dans quels contrats la clause de confidentialité dure-t-elle 5 ans ? » il pose la question. Dans le cadre de l'essai en contexte long, 60 contrats ont été remplis en une seule invite ; le modèle a sauté les deux contrats du milieu. Lorsque seuls les éléments pertinents étaient introduits avec RAG, le coût du jeton diminuait de 80 % et les sauts manquants étaient réinitialisés.

Pourquoi RAG est-il nécessaire ?

Actualité : vous accédez aux informations après la date limite de formation.
Information particulière : Vos documents internes ne sont inclus dans la formation d'aucun modèle ; Vous seul pouvez donner.
Vérifiabilité : vous pouvez citer la source de la réponse (citation) – essentiel pour l'audit et la confiance.
Contrôle des hallucinations : Il s'appuie sur le texte placé devant lui plutôt que sur la constitution d'un modèle.
Coût : La mise en service est beaucoup moins coûteuse et plus rapide que le réglage fin.

Attention : RAG n'est pas magique. Si vous apportez la mauvaise pièce, le modèle arrive à la mauvaise réponse en ayant l’air « confiant ». Gardez à l’esprit la phrase « Qualité de récupération = qualité RAG ».

Erreurs courantes

Confondre RAG avec un réglage fin : RAG ne modifie pas les poids ; Cela ajoute simplement du contexte. Confondre ces deux éléments conduira à choisir la mauvaise architecture.
Ne pas autoriser « Je ne sais pas » : si l'invite laisse le modèle libre de remplir le vide, il se rattrapera.
Ne pas citer les sources : une réponse sans source ne peut pas être vérifiée ; L'utilisateur ne peut pas remarquer l'erreur.
Tout regrouper dans une seule invite : un contexte long semble bon marché, mais il est coûteux et manque les informations du milieu.
Rester bloqué dans la génération sans mesurer la récupération : si la réponse est mauvaise, demandez d'abord "La bonne pièce est-elle arrivée ?" devrait être demandé.

En résumé

RAG est une approche qui injecte des documents pertinents à la question dans le modèle en tant que contexte ; ne modifie pas les pondérations (« examen à livre ouvert »).
Affinement du style/format de l'enseignement, RAG donne des informations actuelles et spécifiques ; le contexte long fonctionne bien pour les petits ensembles fixes. Dans la plupart des scénarios, RAG est essayé en premier.
Le pipeline comporte deux phases : l'indexation hors ligne (morceau + intégration + sauvegarde) et l'interrogation en ligne (récupération + invite + génération).
RAG offre rapidité, informations spécifiques, vérifiabilité, contrôle des hallucinations et faible coût.
La qualité du système dépend directement de la qualité de la récupération : une mauvaise pièce signifie une mauvaise réponse.

Tâche de candidature

Choisissez une véritable source d'information provenant de votre propre équipe (par exemple un document de procédure ou une page FAQ). (1) Écrivez 5 questions factuelles sur cette source. (2) Notez quelle partie du document contient la bonne réponse pour chaque question – cela devient votre liste de « réponses en or ». (3) À l'aide du modèle « invite forte » ci-dessus, collez manuellement la section appropriée comme contexte et demandez un modèle. (4) Comparez la réponse donnée par le modèle avec la réponse en or et marquez comme vrai/faux. Il s'agit de la première version manuelle de l'évaluation que vous automatiserez dans les prochaines unités.

liste de contrôle

[ ] Je peux expliquer en une phrase que RAG ne change pas les poids, il ajoute simplement du contexte.
[ ] Je peux faire la distinction entre RAG, réglage fin et contexte long et quand ce qui est approprié.
[ ] Je peux compter les phases d'indexation (collecter-shred-embed-save) et de requête (embed-fetch-prompt-generate) dans l'ordre.
[ ] Je sais pourquoi j'ai ajouté les instructions « si ce n'est pas dans le contexte, dites que je ne sais pas » et « citer la source » à l'invite.
[ ] Je peux adapter le principe "Qualité de récupération = Qualité RAG" à mon propre cas.