Fondamentaux LLM : RAG, ancrage, sortie structurée

Pourquoi ce module

Ce sont les questions qui ouvrent presque tous les entretiens FDE, et ce sont les plus faciles à rater — parce qu'on croit les connaître.

« Faut-il fine-tuner ou faire du RAG ? » a une bonne réponse et elle tient en une phrase. « Le client veut que le modèle ne dise jamais rien qui ne soit dans ses documents » a une réponse honnête et une réponse commerciale, et l'examinateur attend l'honnête.

Ce module pose les quatre notions sur lesquelles tout le reste s'appuie : d'où vient la connaissance du modèle, comment on contraint sa sortie, pourquoi il n'est pas déterministe, et ce qui se passe quand on lui donne trop de contexte.

Objectifs pédagogiques

1. Trancher entre RAG et fine-tuning selon la nature du besoin, et justifier
2. Expliquer ce qu'apporte réellement la sortie structurée en production
3. Répondre honnêtement à la demande « qu'il ne dise jamais rien d'inventé »
4. Décrire le phénomène lost in the middle et ses conséquences pratiques
5. Expliquer pourquoi deux exécutions identiques donnent des réponses différentes

Plan détaillé

1. Où vit la connaissance : RAG, fine-tuning, contexte
2. L'ancrage — et pourquoi « jamais rien d'inventé » est un mensonge
3. La sortie structurée
4. Le non-déterminisme
5. Le long contexte et lost in the middle
6. Quatre points opérationnels
7. Glossaire du module

1. Où vit la connaissance : RAG, fine-tuning, contexte

Trois façons de faire arriver de l'information à un modèle. Elles ne s'opposent pas, elles n'agissent simplement pas au même endroit.

🎯 La question d'entretien, et sa réponse. « Le client a une base de connaissances qui change chaque semaine. Fine-tuning ou RAG ? »

RAG, et l'argument décisif est la fraîcheur, pas le coût. Un modèle fine-tuné fige la connaissance au moment de l'entraînement : chaque mise à jour hebdomadaire exigerait un ré-entraînement, et entre deux ré-entraînements le modèle affirmerait avec aplomb des choses périmées — sans qu'on puisse savoir lesquelles.

Le second argument, souvent oublié et souvent décisif chez un grand compte : la traçabilité. Le RAG peut citer sa source, le fine-tuning non. Dans un contexte industriel ou réglementé, une réponse non traçable est inutilisable quelle que soit sa justesse.

Le bon usage du fine-tuning existe pourtant : quand ce qu'on veut enseigner est un comportement stable — un format de sortie particulier, un ton, un vocabulaire métier, une façon de raisonner. Pas des faits.

⚠️ Le distracteur classique. « Le fine-tuning est moins cher que le RAG » — faux dans les deux sens : le fine-tuning a un coût d'entraînement élevé et un coût de mise à jour récurrent, le RAG a un coût par requête (embedding, contexte plus long). On ne les compare pas sur le prix, on les compare sur la nature de ce qu'on veut faire apprendre.

2. L'ancrage — et pourquoi « jamais rien d'inventé » est un mensonge

Grounding (ancrage) : contraindre la réponse à s'appuyer sur des sources fournies, et rendre ce lien vérifiable.

Le client formule presque toujours la demande ainsi : « Je veux qu'il ne dise jamais rien qui ne soit pas dans nos documents. » C'est une demande légitime et une garantie impossible.

La réponse honnête, celle qui est attendue en entretien :

« On ne peut pas le garantir, parce que le modèle génère du texte token par token : rien dans son fonctionnement ne l'empêche de produire une phrase plausible non soutenue par les passages. Ce qu'on peut faire, c'est le rendre rare et le rendre visible. Rare, en fournissant les bons passages et en instruisant le modèle de refuser quand ils ne suffisent pas. Visible, en mesurant un taux de fidélité — pour chaque affirmation, le passage cité la soutient-il ? — et en refusant de mettre en production sous un certain seuil. Je vous propose un chiffre mesuré, pas une garantie. »

Cette réponse est meilleure que « oui bien sûr » y compris commercialement : elle établit que vous savez ce que vous vendez, et elle vous protège le jour où le système se trompe — parce qu'il se trompera.

💡 Ce que ça donne en pratique. Sur un RAG de notices industrielles, une évaluation de fidélité mesure le taux de citation : quelle proportion des lignes produites porte une citation vérifiable ? Un premier passage à 78 % n'est pas un mauvais chiffre en soi — l'information est dans les 22 % restants, pas dans le score. C'est exactement le sujet du module F4.

3. La sortie structurée

Structured output : contraindre le modèle à produire une sortie conforme à un schéma (typiquement JSON Schema), au niveau du décodage.

Ce que la sortie structurée apporte vraiment, et c'est la formulation attendue : elle supprime la couche de parsing défensif. Sans elle, le code appelant doit gérer des sorties presque-valides — une virgule en trop, un préambule « Voici le JSON demandé : », un champ manquant — et cette couche défensive est fragile, silencieuse quand elle échoue, et impossible à tester exhaustivement.

⚠️ Le contresens fréquent. La sortie structurée ne rend pas le contenu plus juste. Un modèle peut produire un JSON parfaitement conforme au schéma et factuellement faux. Elle garantit la forme, jamais le fond. Un candidat qui dit « ça réduit les hallucinations » a mal compris — et c'est un distracteur classique en QCM.

4. Le non-déterminisme

« Pourquoi les réponses de votre agent varient-elles entre deux exécutions identiques ? » La réponse honnête tient en trois causes, et il faut les distinguer.

🎯 La réponse d'entretien. « Même à température zéro, on ne garantit pas une reproduction exacte : le non-déterminisme est aussi numérique, au niveau du calcul sur GPU. Donc on ne conçoit pas un système qui exige des sorties identiques — on conçoit un système dont les sorties sont équivalentes, et on mesure cette équivalence. C'est pour ça que les évaluations comparent des propriétés, pas des chaînes de caractères. »

C'est un point de conception, pas une anecdote : il explique pourquoi on n'écrit jamais un test qui compare la sortie d'un LLM à une chaîne attendue.

5. Le long contexte et lost in the middle

Les fenêtres de contexte atteignent le million de tokens. La tentation est immédiate : pourquoi faire du RAG si on peut tout mettre dans le contexte ?

Lost in the middle désigne un phénomène mesuré : la capacité du modèle à utiliser une information dépend de sa position dans le contexte. Une information placée au début ou à la fin est bien exploitée ; la même information au milieu d'un contexte long est nettement moins bien retrouvée.

Trois conséquences pratiques, qui sont autant de réponses d'entretien :

1. Un contexte plus grand n'est pas un contexte mieux utilisé. Remplir un million de tokens de documents dégrade la qualité au lieu de l'améliorer.
2. L'ordre des passages compte. Placer les passages les plus pertinents aux extrémités plutôt que de les empiler au hasard — c'est un des rôles du reranking (module F2).
3. Le RAG reste pertinent malgré le long contexte : il ne sert pas seulement à contourner une limite de taille, il sert à ne montrer que ce qui est pertinent, ce qui est un objectif en soi.

Ajoutez-y le coût et la latence : mille pages dans le contexte à chaque question, c'est un coût par requête multiplié et un temps de première réponse dégradé.

⚠️ Le distracteur. « Lost in the middle, c'est quand le modèle perd le fil d'une longue conversation » — non, c'est une propriété de position dans le contexte, mesurée sur une seule requête, pas un effet de mémoire conversationnelle.

6. Quatre points opérationnels

Ceux-là ne s'inventent pas : ils viennent de systèmes en production, et ils tombent souvent en relance.

6.1 Prompt système ou description d'outil ?

On croit que tout se règle dans le prompt système. Faux, et la distinction est structurelle :

Les descriptions d'outils sont la surface de décision de l'agent. Une description vague produit un mauvais choix d'outil, qu'aucun prompt système ne corrigera.

Le prompt système cadre le comportement général ; la description d'outil est ce que le modèle lit au moment de choisir. Quand la précision de sélection d'outil chute, on réécrit les descriptions — pas le prompt système.

6.2 Pourquoi les identifiants exacts résistent aux embeddings

TT-104, BA-0071-C, une référence pièce : ces tokens se comportent mal en recherche vectorielle, et la raison est mécanique, pas une préférence d'ingénieur.

La valeur d'un tel token est sa forme de surface exacte — et le découpage en sous-mots (BPE) détruit précisément cela. TT-104 devient TT + - + 104, morceaux dont le voisinage sémantique n'a aucun rapport avec la référence d'origine.

C'est la raison pour laquelle un bras lexical reste nécessaire sur un corpus technique (module F2). À énoncer ainsi : ce n'est pas que le vectoriel est « moins bon », c'est qu'il n'a rien à capturer.

6.3 Cache de prompt : l'ordre est l'optimisation

Le cache de prompt facture une fraction du prix un préfixe identique d'une requête à l'autre. D'où la question : où mettre ce qui change ?

La partie volatile va à la fin. Un seul caractère volatil en tête invalide tout le préfixe mis en cache.

L'ordre à respecter : règles système → schémas d'outils → puis passages récupérés et tour utilisateur. Un horodatage en première ligne annule le bénéfice entier.

6.4 Le risque peu discuté du décodage contraint

Retour sur la sortie structurée, avec sa contrepartie :

Masquer les tokens pour satisfaire une grammaire supprime l'échappatoire du modèle. Là où la réponse honnête était « je ne sais pas », un enum obligatoire force une valeur.

Le correctif tient en une ligne de schéma : toujours prévoir une branche null ou "inconnu". Sans elle, on a converti une incertitude en affirmation — l'exact contraire de ce qu'on cherchait.

7. Glossaire du module

Atelier (60 min)

1. RAG ou fine-tuning (20 min) — pour cinq besoins clients au choix, tranchez et écrivez l'argument décisif en une phrase. Vérifiez qu'aucun de vos arguments n'est « c'est moins cher ».
2. La réponse honnête (20 min) — rédigez puis dites à voix haute, en anglais, votre réponse à « I want it to never say anything that isn't in our documents ». Chronométrez : viser 60 à 90 secondes.
3. Le piège de la sortie structurée (20 min) — expliquez à voix haute pourquoi la sortie structurée ne réduit pas les hallucinations. Si vous hésitez, relisez le § 3.

Pour aller plus loin

• 🎯 Parcours : F0 — Le métier de FDE ← → F2 — Récupération & RAG
• 📚 Approfondissement : M5 — Long-context strategies et M3 — Hallucination mitigation et eval LLM
• 🛠 Entraînement : thème foundations de la banque fransys-fde — 12 QCM