# D5 · Retrieval-Augmented Generation Chunking, embeddings, vector stores, file search, récupération hybride, formatage des citations, évaluation des réponses ancrées, et gestion de la fraîcheur et des permissions dans la récupération sur l’API OpenAI. import { Accordions, AccordionItem } from '@prosefly/astro-components'; Ce domaine représente environ **16 %** de l’examen blanc OAI-API — à peu près **10 des 60 items** — et reflète le cours Academy *Build with Retrieval-Augmented Generation* (100 min). Il teste si vous savez ancrer les réponses d’un modèle dans vos propres documents : découper (chunk) et embedder le contenu, le stocker dans un **vector store**, récupérer avec **file search** et des méthodes hybrides, formater les **citations**, évaluer si les réponses sont réellement ancrées, et gérer la **fraîcheur** et les **permissions** pour que la récupération renvoie la bonne preuve, autorisée et à jour. ## Ce que vous devez savoir Le RAG met vos documents devant le modèle au moment de la réponse au lieu de se fier à la connaissance d’entraînement. Vous **chunkez** les documents en passages, les **embeddez** en vecteurs, et les stockez dans un **vector store**. Au moment de la requête vous **récupérez** les chunks les plus pertinents (sémantique, mot-clé, ou **hybride**) et les passez comme contexte pour que le modèle réponde à partir de preuves et **cite** ses sources. Le RAG est le bon choix quand la connaissance est vaste, privée ou changeante — vous mettez à jour le store au lieu de réentraîner. Les parties difficiles ne sont pas la plomberie : ce sont bien chunker, récupérer les bons passages, prouver que les réponses sont **ancrées**, garder le contenu **frais**, et faire respecter les **permissions** pour que les utilisateurs ne voient que ce qu’ils ont le droit de voir. ## Objectifs d’apprentissage À la fin de cette page, vous devriez être capable de : 1. **Chunker** les documents intelligemment et expliquer pourquoi la taille de chunk importe. 2. Créer des **embeddings** et un **vector store**, et répondre avec **file search**. 3. Utiliser la **récupération hybride** (sémantique + mot-clé) et savoir quand elle bat la sémantique pure. 4. **Formater les citations** et **évaluer les réponses ancrées**. 5. Gérer la **fraîcheur** pour que le contenu périmé ne soit pas récupéré. 6. Faire respecter les **permissions** pour que la récupération respecte qui peut voir quoi. --- ## 5.1 Quand le RAG, et le pipeline ```text INGESTION (offline) REQUÊTE (online) ──────────────── ────────────── documents question utilisateur │ chunk │ embed de la requête ▼ ▼ chunks ── embed ──► vecteurs ──► VECTOR STORE ──► récupérer les top-k chunks │ ▼ prompt = question + chunks │ ▼ le modèle répond AVEC citations ``` Le RAG bat le fine-tuning et bat le fait de tout mettre dans le prompt quand le socle de connaissances est vaste, privé ou fréquemment mis à jour : vous éditez le store, pas le modèle. :::tip[Signal d’évaluation] « Répondre uniquement à partir de nos documents », « citer la source », « la connaissance change chaque semaine » ou « la réponse doit être ancrée » sont des items RAG. « Fine-tuner sur les documents » est le distracteur classique quand le contenu change ou doit être cité. ::: ## 5.2 Chunking La taille de chunk arbitre entre le rappel, la précision et le coût. | Taille de chunk | Effet | Risque | | --- | --- | --- | | Trop grande | Chunks moins nombreux, larges ; plus de tokens par hit | Récupère du texte non pertinent ; dilue le signal | | Trop petite | Précis mais fragmenté | Éclate une réponse entre chunks ; perd le contexte | | Bien dimensionnée (souvent quelques centaines de tokens, avec chevauchement) | Passages cohérents qui tiennent chacun seuls | — | Le chevauchement (overlap) entre chunks adjacents préserve le contexte qui serait sinon coupé à une frontière. Respectez la structure du document — chunkez sur les titres/paragraphes plutôt que sur des comptes de caractères fixes quand c’est possible. ## 5.3 Embeddings et le vector store Les embeddings transforment le texte en vecteurs pour que les passages sémantiquement similaires se situent près les uns des autres. Un **vector store** les indexe pour une récupération rapide du plus proche voisin. Avec la plateforme OpenAI vous pouvez créer un vector store managé et utiliser **file search** sans exécuter votre propre base de données vectorielle. ```python vs = client.vector_stores.create(name="hr-policies") client.vector_stores.files.upload_and_poll( vector_store_id=vs.id, file=open("leave-policy.pdf", "rb"), ) resp = client.responses.create( model="gpt-5.6-terra", input="How many days of paid parental leave do I get?", tools=[{"type": "file_search", "vector_store_ids": [vs.id]}], ) print(resp.output_text) # réponse ancrée dans les fichiers téléversés, avec citations ``` ## 5.4 Récupération hybride La recherche sémantique pure peut manquer les termes exacts (un code produit, une chaîne d’erreur, un numéro de clause juridique) ; la recherche par mot-clé pure manque les paraphrases. La récupération **hybride** combine les deux et rerank généralement. | Méthode | Forte pour | Faible pour | | --- | --- | --- | | Sémantique (vecteur) | Paraphrase, sens, synonymes | ID exacts, tokens rares, phrases exactes | | Mot-clé (lexical) | Termes exacts, codes, noms | Synonymes, intention | | **Hybride + rerank** | Les deux, avec un reranker pour ordonner | Plus de pièces mobiles à régler | Si les utilisateurs cherchent par identifiants exacts (SKU, codes d’erreur, numéros de clause), la récupération hybride bat matériellement la sémantique pure. ## 5.5 Citations et réponses ancrées Une réponse ancrée pointe vers le passage qui étaye chaque affirmation. Deux choses à bien faire : - **Formatage des citations :** renvoyez la source (fichier, section, et idéalement l’extrait cité) pour qu’un lecteur puisse vérifier. File search renvoie des citations que vous exposez à l’utilisateur. - **Discipline de réponse ancrée :** demandez au modèle de répondre *uniquement* à partir du contexte récupéré et de dire « non trouvé dans le matériel fourni » quand le contexte n’étaye pas de réponse — plutôt que de combler le vide à partir de la connaissance d’entraînement. ```text Réponse : "Le congé parental payé est de 16 semaines." [leave-policy.pdf, §4.2] Contrôle : ouvrir §4.2 → confirme 16 semaines → ancré. Si le chunk ne disait rien → le modèle devrait dire "pas dans la politique", et non inventer un nombre. ``` ## 5.6 Évaluer les réponses ancrées Le RAG a deux surfaces de défaillance, et vous évaluez chacune : | Défaillance | Où | Métrique | | --- | --- | --- | | **Manque de récupération** | Le bon chunk n’est pas récupéré | Rappel de récupération @ k | | **Réponse non ancrée** | Chunk récupéré mais réponse non étayée | Score de fidélité / d’ancrage (juge LLM ou humain) | | **Réponse incomplète** | Certains chunks d’appui récupérés, d’autres manqués | Complétude face à la référence | C’est là que D5 rencontre D3 : construisez un jeu de données de questions avec réponses de référence et passages d’appui, et gradez à la fois la récupération et l’ancrage. « La réponse sonne juste » n’est pas une mesure d’ancrage. ## 5.7 Fraîcheur et permissions | Préoccupation | Problème | Traitement | | --- | --- | --- | | **Fraîcheur** | Récupérer une version de politique remplacée | Réindexer au changement ; stocker les dates de version/d’effet ; filtrer sur l’actuelle ; supprimer les docs périmés | | **Permissions** | Un utilisateur récupère un document qu’il ne devrait pas voir | Faire respecter l’accès à la récupération : filtrer selon les droits de l’utilisateur ; partitionner les stores par locataire/rôle | :::caution[Les permissions relèvent de la récupération, pas du prompt] Dire au modèle « ne révèle pas les documents que l’utilisateur ne peut pas voir » n’est pas un contrôle — la conception sûre filtre l’*ensemble de candidats* à ce à quoi l’utilisateur a droit *avant* la récupération, pour que le contenu restreint n’atteigne jamais le contexte. ::: ## Cadre de décision Utilisez le cadre **GROUND** pour concevoir et défendre un système RAG. | Lettre | Étape | Question | | --- | --- | --- | | **G** | Good chunks | Les chunks sont-ils cohérents, bien dimensionnés, conscients de la structure, chevauchés ? | | **R** | Retrieval method | Sémantique, mot-clé, ou hybride — les utilisateurs cherchent-ils par ID exacts ? | | **O** | Only from context | Le modèle répond-il uniquement à partir des preuves récupérées et dit-il « non trouvé » sinon ? | | **U** | Uphold permissions | L’ensemble de candidats est-il filtré aux droits de l’utilisateur avant la récupération ? | | **N** | New content | Le store est-il réindexé au changement avec filtrage de version/fraîcheur ? | | **D** | Demonstrate grounding | Évaluez-vous le rappel de récupération et la fidélité des réponses sur un jeu de données ? | L’étape que la plupart des équipes sautent est **D** — elles livrent un RAG qui récupère de façon plausible mais ne mesure jamais si les réponses sont réellement étayées. ## Erreurs fréquentes | Erreur | Pourquoi elle survient | Que faire à la place | | --- | --- | --- | | Fine-tuner sur des documents qui changent ou doivent être cités | Confondre connaissance et récupération | Utiliser le RAG ; mettre à jour le store, citer la source | | Chunks trop grands | Moins de fichiers à gérer | Bien dimensionner avec chevauchement ; respecter la structure | | Recherche sémantique pure pour les requêtes par ID exact | La sémantique est le défaut | Utiliser la récupération hybride quand les termes exacts comptent | | Laisser le modèle répondre depuis l’entraînement quand le contexte est vide | Biais de serviabilité | Instruire « répondre uniquement à partir du contexte ; dire non trouvé » | | Aucune citation | Sauté par rapidité | Renvoyer source + extrait pour que les réponses soient vérifiables | | Ne jamais mesurer l’ancrage | « Ça sonne juste » | Évaluer le rappel de récupération et la fidélité sur un jeu de données | | Contenu périmé récupéré | Pas de réindexation au changement | Réindexer à la mise à jour ; filtrer sur les versions actuelles | | Permissions appliquées dans le prompt | Le plus facile à greffer | Filtrer les candidats par droit avant la récupération | ## Défi de mise en situation **Mise en situation.** Un fournisseur de santé construit un assistant qui répond aux questions des cliniciens à partir de protocoles internes. Exigences : les réponses doivent citer la section exacte du protocole ; les cliniciens ne doivent récupérer que les protocoles de leur propre service ; les protocoles sont révisés chaque mois et l’ancienne version ne doit jamais être citée ; et certaines questions référencent des codes de protocole exacts comme `PROT-CARD-014`. Un ingénieur propose : fine-tuner un modèle sur tous les protocoles, lui dire dans le prompt système de « ne répondre que pour le service de l’utilisateur et citer les sections », et re-fine-tuner chaque mois. **Trace de raisonnement d’expert.** 1. **Le fine-tuning est le mauvais cœur.** Les protocoles changent chaque mois et les réponses doivent citer des sections exactes. Le fine-tuning fige un instantané dans les poids, ne peut pas citer un extrait de source, et force un réentraînement coûteux chaque mois. Le RAG est correct : mettre à jour le store, récupérer, citer. 2. **Les permissions doivent être appliquées à la récupération.** Une instruction de prompt « ne répondre que pour le service de l’utilisateur » n’est pas un contrôle — le modèle *voit* toujours les chunks des autres services s’ils sont dans l’ensemble de candidats. La conception sûre filtre l’ensemble de candidats au service du clinicien *avant* la récupération, p. ex. des stores partitionnés ou des filtres de métadonnées, pour que les protocoles hors périmètre n’atteignent jamais le contexte. 3. **La fraîcheur nécessite du versioning, pas seulement de la réindexation.** Réindexer chaque mois, mais aussi étiqueter chaque chunk d’une date d’effet/version et filtrer la récupération à la version actuelle pour qu’un protocole remplacé ne soit jamais cité. 4. **Les codes exacts exigent la récupération hybride.** `PROT-CARD-014` est un token exact rare que la recherche sémantique pure peut manquer ; l’hybride (mot-clé + sémantique) avec reranking le récupère de façon fiable. 5. **Ancrer et citer.** Instruire le modèle de répondre uniquement à partir des chunks récupérés et de renvoyer le protocole et l’extrait de section ; si les chunks ne répondent pas, le dire plutôt qu’inventer. 6. **Le mesurer.** Construire une évaluation de questions de cliniciens avec la bonne section de protocole, et grader le rappel de récupération et la fidélité des réponses — surtout qu’aucune fuite inter-services ne se produise. **Décision conforme à l’examen :** un RAG avec un vector store, un filtrage par service au moment de la récupération, un filtrage de version/fraîcheur, une récupération hybride pour les codes exacts, des réponses ancrées-et-citées, et une évaluation d’ancrage. **Pas** le fine-tuning, **pas** des « contrôles » de permission basés sur le prompt. ## Pièges d’évaluation | Piège | Pourquoi il est tentant | Le discriminant | | --- | --- | --- | | « Fine-tuner sur les documents » | Ça ressemble à enseigner au modèle | La connaissance changeante/citable relève du RAG, pas des poids | | « Dire au modèle de ne pas révéler les docs restreints » | Simple à écrire | Les permissions doivent filtrer l’ensemble de candidats avant la récupération | | « La recherche sémantique gère tout » | C’est le défaut | Les ID/codes exacts nécessitent la récupération hybride | | « Ça sonne juste, donc c’est ancré » | La fluidité fait figure d’ancrage | Mesurer la fidélité face au passage récupéré | | « Des chunks plus grands sont plus sûrs » | Moins à gérer | Les chunks surdimensionnés diluent la pertinence ; bien dimensionner avec chevauchement | | « La réindexation gère la fraîcheur » | À moitié vrai | Il faut aussi un filtrage de version/date pour que les anciennes versions ne soient pas citées | | « Mettre tout le socle de connaissances dans le prompt » | De grandes fenêtres de contexte existent | La récupération est moins chère, à jour, et filtrable par permissions | ## Questions d’entraînement Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler. A. Fine-tuner un modèle sur tous les documents chaque semaine. B. Le RAG : chunker et embedder dans un vector store, récupérer au moment de la requête, et citer les sources récupérées. C. Coller tous les documents dans chaque prompt. D. Se fier à la connaissance d’entraînement du modèle. **Réponse : B.** Une connaissance vaste, changeante et citable est le cas canonique du RAG : mettre à jour le store et citer les passages récupérés. Le fine-tuning hebdomadaire (A) est coûteux et ne peut pas citer, tout coller (C) est infaisable, et la connaissance d’entraînement (D) n’est ni privée ni à jour. A. Augmenter la taille de chunk. B. Utiliser une récupération hybride qui combine recherche par mot-clé et sémantique, avec reranking. C. Fine-tuner sur les codes d’erreur. D. Baisser le reasoning effort. **Réponse : B.** Les tokens exacts rares sont une force du mot-clé et une faiblesse de la sémantique, donc la récupération hybride les attrape. Des chunks plus grands (A) ne corrigent pas le matching lexical, le fine-tuning (C) est le mauvais outil, et l’effort (D) est sans rapport avec la récupération. A. Dans le prompt système, en instruisant le modèle de ne pas révéler les autres services. B. À la récupération, en filtrant l’ensemble de candidats aux droits de l’utilisateur avant de passer le contexte au modèle. C. Dans les données d’entraînement du modèle. D. Nulle part ; les utilisateurs s’autorégulent. **Réponse : B.** Les permissions doivent filtrer ce qui est récupéré pour que le contenu restreint n’atteigne jamais le contexte. Une instruction de prompt (A) expose toujours les chunks récupérés, les données d’entraînement (C) ne peuvent pas faire respecter un accès par utilisateur, et l’autorégulation (D) n’est pas un contrôle. A. Augmenter les top-k chunks récupérés à 100. B. Instruire le modèle de répondre uniquement à partir du contexte récupéré et de dire que la réponse n’est pas dans le matériel fourni sinon. C. Utiliser un modèle plus grand. D. Retirer les citations. **Réponse : B.** La discipline de réponse ancrée exige de répondre uniquement à partir du contexte et d’admettre quand il est absent. Inonder de chunks (A) ajoute du bruit, un modèle plus grand (C) peut toujours répondre de façon non ancrée, et retirer les citations (D) empire les choses. A. Le rappel de récupération — le bon chunk d’appui a-t-il été récupéré ? B. La fidélité — chaque affirmation est-elle étayée par le contexte récupéré ? C. Le nombre de paramètres du modèle. D. La couleur du badge de citation. E. L’heure de la requête. **Réponse : A et B.** Le RAG a deux surfaces de défaillance — la récupération et l’ancrage — donc vous mesurez le rappel de récupération et la fidélité des réponses. Le nombre de paramètres (C), la couleur de l’UI (D) et l’heure de requête (E) sont sans rapport avec la qualité d’ancrage. A. Les chunks sont trop petits. B. Les chunks sont trop grands, donc chaque chunk récupéré dilue le passage pertinent avec du texte sans rapport. C. Le modèle d’embedding est mauvais. D. Le vector store est plein. **Réponse : B.** Les chunks surdimensionnés récupèrent de larges passages qui mêlent texte pertinent et non pertinent. Ils ne sont pas trop petits (A) ; rien n’indique le modèle d’embedding (C) ni un store plein (D) comme cause. A. Une fenêtre de contexte plus grande. B. Des métadonnées de version/date d’effet sur les chunks avec récupération filtrée à la version actuelle, et suppression des docs remplacés. C. Un reasoning effort plus élevé. D. Plus de subagents. **Réponse : B.** La fraîcheur nécessite un étiquetage de version/date et un filtrage pour que seule la version actuelle soit récupérable, plus la suppression des anciennes. La taille du contexte (A), l’effort (C) et les subagents (D) n’empêchent pas les versions périmées d’être citées. A. Pour augmenter délibérément le coût de stockage. B. Pour préserver le contexte qui serait sinon coupé à une frontière de chunk pour qu’une réponse enjambant la frontière soit récupérable. C. Pour rendre les embeddings plus rapides. D. Le chevauchement n’est jamais utilisé. **Réponse : B.** Le chevauchement garde intact le contexte enjambant une frontière pour qu’un passage pertinent ne soit pas éclaté de façon irrécupérable. Il ne s’agit pas de coût (A) ni de vitesse (C), et c’est une technique standard (D). A. Rien ; sonner juste suffit. B. Une évaluation de réponses ancrées mesurant le rappel de récupération et la fidélité sur un jeu de données labellisé. C. Un vector store plus grand. D. Une température plus basse. **Réponse : B.** Sonner juste n’est pas de l’ancrage ; vous devez mesurer la récupération et la fidélité sur un jeu de données. Lire quelques réponses (A) manque les échecs systématiques, la taille du store (C) est sans rapport, et la température (D) ne mesure pas l’ancrage. A. Rien ; vous devez construire votre propre base de données vectorielle. B. La récupération sur les fichiers téléversés avec citations, sans exécuter votre propre base de données vectorielle. C. Le fine-tuning automatique du modèle. D. Une résidence de données UE garantie. **Réponse : B.** File search récupère sur un vector store managé et renvoie des citations sans que vous exploitiez une base vectorielle. Il ne nécessite pas votre propre base (A), ne fait pas de fine-tuning (C), et ne garantit pas à lui seul la résidence (D). A. La connaissance change fréquemment et vous voulez la mettre à jour sans réentraîner. B. Les réponses doivent citer le passage source exact. C. Vous voulez changer le style d’écriture du modèle de façon permanente. D. Vous voulez réduire à zéro le nombre d’appels d’API. E. Vous voulez que le modèle mémorise tout. **Réponse : A et B.** Le RAG convient à la connaissance changeante (mettre à jour le store) et aux réponses citables (récupérer le passage). Le changement de style permanent (C) est un usage du fine-tuning, le RAG ne supprime pas les appels d’API (D), et la mémorisation (E) est l’opposé de la récupération. A. Supposer que la fonctionnalité de citation est cassée et retirer les citations. B. Faire une analyse des échecs sur les passages cités vs d’appui : vérifier si la récupération a renvoyé le bon chunk et si le modèle a attribué l’affirmation au bon. C. Augmenter le reasoning effort à `max`. D. Passer à Chat Completions. **Réponse : B.** Les mauvaises citations sont une défaillance d’ancrage/attribution diagnostiquée en comparant les chunks récupérés à l’affirmation ; l’analyse des échecs isole si la faute vient de la récupération ou de l’attribution. Retirer les citations (A) masque le problème, l’effort (C) ne corrige pas l’attribution, et la surface d’API (D) est hors sujet. A. Le RAG est toujours plus précis quel que soit le contexte. B. Récupérer uniquement les chunks pertinents est moins cher par requête, garde les réponses ciblées, et permet de filtrer par permissions et fraîcheur. C. La fenêtre de contexte est en fait trop petite pour le manuel. D. Les prompts ne peuvent pas contenir de documents. **Réponse : B.** La récupération n’envoie que les passages pertinents, réduisant le coût en tokens et le bruit tout en permettant un filtrage de permissions et de fraîcheur que l’approche du manuel complet ne permet pas. Le RAG n’est pas inconditionnellement plus précis (A), 900 pages tiennent probablement (C), et les prompts peuvent contenir des documents (D) — c’est juste gaspilleur. A. Les bons chunks sont récupérés mais le modèle n’en répond pas fidèlement ; resserrer l’instruction d’ancrage et vérifier l’attribution. B. Le vector store est vide. C. Les chunks sont trop petits. D. Le modèle d’embedding est cassé. **Réponse : A.** Un rappel élevé avec une fidélité basse signifie que la récupération fonctionne mais que le modèle s’éloigne de la preuve, donc le correctif est la discipline d’ancrage et les vérifications d’attribution. Un store vide (B) effondrerait aussi le rappel, et ni des chunks trop petits (C) ni un embedder cassé (D) ne correspondent à un rappel élevé. ## Points clés à retenir - Le RAG ancre les réponses dans vos documents ; préférez-le au fine-tuning quand la connaissance est vaste, privée, changeante ou doit être citée. - Chunkez en passages cohérents, bien dimensionnés, chevauchés, qui respectent la structure du document. - Stockez les embeddings dans un vector store et répondez avec file search ; utilisez la récupération hybride quand les ID exacts comptent. - Faites répondre le modèle uniquement à partir du contexte récupéré et citez l’extrait source ; faites-lui dire « non trouvé » plutôt qu’inventer. - Évaluez à la fois le rappel de récupération et la fidélité des réponses sur un jeu de données labellisé. - Faites respecter les permissions en filtrant l’ensemble de candidats avant la récupération, jamais avec une instruction de prompt. - Gardez le contenu frais avec un filtrage de version/date et une réindexation pour que les documents remplacés ne soient jamais cités.