Tokenisation, fenêtre de contexte, attention, pré-entraînement contre affinage, LoRA, RAG, hallucinations, quantification et évaluation : les grands modèles de langage en entretien.
Cliquez sur une question pour dérouler la réponse attendue.
Un grand modèle de langage est un réseau de neurones entraîné à prédire le jeton suivant dans une séquence de texte, sur un corpus de plusieurs milliers de milliards de jetons. C’est tout ce qu’il fait, et il faut savoir le dire simplement en entretien.
Il apprend une distribution de probabilité : pour un début de texte donné, quelle est la probabilité de chaque jeton possible ensuite. Générer une réponse, c’est répéter cette prédiction jeton par jeton, en réinjectant chaque fois ce qui vient d’être produit.
C’est la partie contre-intuitive, et celle qui distingue un candidat qui a compris. Pour bien prédire le mot suivant sur l’ensemble du texte écrit par l’humanité, il faut incidemment apprendre la grammaire, les faits, le raisonnement de surface, la traduction et le style. La tâche est triviale à énoncer ; l’atteindre force le modèle à représenter beaucoup de structure.
Il ne consulte pas de base de données pendant qu’il répond, sauf si on lui en branche une. Il n’a pas de mémoire entre deux conversations, sauf si on la lui construit. Et il ne sait pas ce qu’il ignore : il produit le texte le plus probable, ce qui n’est pas la même chose que le texte vrai.
Un jeton est un fragment de texte fréquent, entre le caractère et le mot. Ce découpage garde un vocabulaire fini tout en sachant écrire n’importe quel mot inconnu, y compris un nom propre.
Lire la réponse détailléeUn plongement (embedding) est la représentation d’un jeton, d’une phrase ou d’un document par un vecteur de nombres réels — typiquement de 384 à 3072 dimensions. Cette représentation est apprise, pas définie à la main.
La propriété qui rend les plongements utiles : la proximité dans l’espace correspond à la proximité de sens. « médecin » est près de « chirurgien », loin de « bicyclette ». Cette proximité se mesure presque toujours par la similarité cosinus, l’angle entre les deux vecteurs, parce qu’on s’intéresse à la direction et non à la longueur.
L’exemple classique des directions — roi moins homme plus femme donne quelque chose près de reine — illustre l’idée, mais il faut savoir le nuancer : il tenait bien sur les anciens plongements statiques, il est beaucoup moins net sur les modèles contextuels actuels.
C’est cette contextualisation qui a rendu les anciens plongements obsolètes pour la plupart des usages.
Un plongement optimisé pour la similarité de sens n’est pas optimisé pour la pertinence question-réponse. Une question et sa réponse ne se ressemblent pas textuellement. Les bons modèles de recherche sont entraînés spécifiquement sur des paires question-passage, souvent avec des encodages différents pour la requête et le document — c’est ce qu’on appelle un modèle asymétrique.
Un modèle de conversation est le produit de trois étapes successives, de coûts et de natures très différents. Savoir les distinguer est une question de cadrage fréquente, parce qu’elle révèle si le candidat sait où il peut intervenir.
Prédire le jeton suivant sur des milliers de milliards de jetons de texte brut. C’est là que le modèle acquiert la langue, les faits et les structures de raisonnement. Coût : plusieurs millions à dizaines de millions de dollars, des milliers de GPU pendant des semaines. Personne ne refait cette étape en dehors d’une poignée de laboratoires.
Le résultat est un modèle « de base » : il complète du texte, mais il ne suit pas d’instruction. Demandez-lui « Quelle est la capitale du Portugal ? » et il pourra continuer avec « Quelle est la capitale de l’Espagne ? », parce que c’est une suite plausible dans un corpus.
On l’entraîne ensuite sur des dizaines à centaines de milliers de paires instruction, réponse idéale écrites ou validées par des humains. La tâche technique est identique — prédire le jeton suivant — mais les données changent tout : le modèle apprend le format du dialogue et l’habitude de répondre à ce qu’on lui demande.
Coût : des ordres de grandeur plus faible. C’est l’étape accessible, celle qu’on refait pour spécialiser un modèle sur un domaine, un ton ou un format de sortie.
L’affinage supervisé apprend une réponse acceptable ; il n’apprend pas à distinguer deux réponses acceptables dont l’une est meilleure. On collecte donc des comparaisons humaines — entre deux réponses, laquelle préférez-vous — et on optimise le modèle pour maximiser la préférence.
Deux familles : le RLHF, qui entraîne un modèle de récompense puis optimise par apprentissage par renforcement, et le DPO et ses variantes, qui optimisent directement sur les paires sans modèle de récompense séparé — plus simple, plus stable, largement adopté depuis.
C’est cette étape qui produit l’utilité, la politesse et les refus.
La question de suivi habituelle. Aucune de ces étapes n’ajoute de connaissance de façon fiable. L’affinage sur un corpus interne enseigne surtout une forme, un vocabulaire, un format ; il n’installe pas des faits récupérables sur demande, et il risque de faire oublier des capacités générales. Pour de la connaissance factuelle, c’est le RAG qu’il faut, pas l’affinage. Confondre les deux est l’erreur la plus commune sur ce sujet.
La fenêtre de contexte est le nombre de jetons que le modèle peut avoir sous les yeux en une fois : l’invite système, l’historique de la conversation, les documents fournis et la réponse en cours de génération, tout compris.
Deux raisons, et il faut donner les deux.
Le coût quadratique de l’attention. Chaque jeton regarde tous les autres : doubler le contexte quadruple le calcul. C’est la contrainte fondamentale.
Le cache des clés et des valeurs. Pendant la génération, le modèle conserve en mémoire GPU un état pour chaque jeton déjà vu. Ce cache croît linéairement avec le contexte, et il devient rapidement plus gros que les poids du modèle. C’est souvent lui, et non le calcul, qui limite le nombre de requêtes servies en parallèle.
C’est la réponse qui distingue. Les modèles récents annoncent des centaines de milliers de jetons, mais leur capacité à utiliser cette longueur est inégale. Le phénomène documenté est celui du milieu perdu : l’information placée au début et à la fin du contexte est bien exploitée, celle du milieu beaucoup moins.
Conséquence pratique : entasser cinquante documents dans le contexte plutôt qu’en sélectionner trois pertinents dégrade la réponse, en plus de coûter dix fois plus cher. Un long contexte ne remplace pas une bonne recherche.
Résumer l’historique ancien, ne garder que les tours récents en clair, ou passer à une mémoire externe interrogée à la demande. Tronquer silencieusement est le pire choix : le modèle perd l’instruction système sans que rien ne le signale.
Ce sont les deux réglages de l’échantillonnage : ils ne changent pas le modèle, ils changent la façon de tirer un jeton dans la distribution qu’il produit.
À chaque pas, le modèle donne un score pour chaque jeton du vocabulaire. La température divise ces scores avant le softmax.
À température 0, on prend systématiquement le maximum : c’est le décodage glouton.
Aussi appelé échantillonnage par noyau. On trie les jetons par probabilité décroissante, on ne garde que ceux dont les probabilités cumulées atteignent p, et on tire dans ce sous-ensemble renormalisé.
L’intérêt par rapport au top-k, qui garde un nombre fixe de candidats : la taille du sous-ensemble s’adapte. Quand le modèle est certain, deux ou trois jeton suffisent à atteindre 0,9 ; quand il hésite, la coupe laisse passer cinquante candidats. Le top-k fixe garde du bruit dans le premier cas et censure dans le second.
L’usage courant est d’ajuster l’un des deux, pas les deux à la fois : leurs effets se composent de façon difficile à raisonner.
Même à température 0, une même invite ne redonne pas forcément la même réponse d’un appel à l’autre sur un service hébergé : le regroupement des requêtes, la précision réduite et la répartition sur des matériels différents introduisent une variation. « Déterministe » veut dire « sans échantillonnage aléatoire », pas « reproductible au jeton près ».
Le modèle optimise la vraisemblance du texte, pas sa vérité : une référence inventée est statistiquement plausible. On réduit le phénomène par l’ancrage, pas par une consigne de ne pas inventer.
Lire la réponse détailléeOn récupère les passages pertinents et on les donne au modèle avec la question. Le RAG apporte la connaissance à jour et citable ; l’affinage apporte la forme et le comportement.
Lire la réponse détailléeOn sépare d’abord la récupération de la génération : le bon passage est-il remonté ? Cela partage le problème en deux et évite de régler des invites quand c’est l’index qui échoue.
Lire la réponse détailléeLe découpage est le réglage le plus déterminant d’un RAG, et le moins discuté. Un mauvais découpage plafonne la qualité du système quelles que soient les couches au-dessus.
Un passage doit être assez petit pour que son plongement soit spécifique — un vecteur qui résume trois pages ne ressemble à aucune question précise — et assez grand pour contenir une réponse complète et son contexte.
En pratique, on part de 300 à 800 jetons avec un chevauchement de 10 à 20 %, puis on ajuste selon le corpus. Le chevauchement existe pour qu’une phrase à la frontière ne perde pas sa moitié.
C’est le point qui distingue une réponse d’ingénieur. Une coupe tous les 500 jetons ignore le document ; il faut couper sur ses articulations naturelles : titres, sections, articles d’un contrat, paragraphes.
Le principe : découper d’abord par titre, et ne subdiviser que les sections trop longues. Une section courte reste entière même si elle fait 80 jetons.
Une technique simple et très rentable : préfixer chaque passage de son contexte — titre du document, chemin des sections, date. Le passage indexé devient « Politique de congés > Congés parentaux > … », ce qui aide à la fois le plongement et le modèle qui le lira.
Variante plus poussée : indexer un petit passage pour la précision de la recherche, mais fournir au modèle une fenêtre élargie autour de lui. On gagne sur les deux tableaux, précision de la récupération et complétude du contexte.
Pas au jugé. On construit un jeu de questions avec le passage attendu, on mesure le rappel pour deux ou trois stratégies, et on choisit. Le découpage est un paramètre à valider, pas une convention à recopier.
Les deux, et savoir pourquoi est le vrai sujet de la question.
La recherche lexicale, dont BM25 est la référence, compte les termes partagés en pondérant par leur rareté. Elle trouve la correspondance exacte : un code d’erreur, une référence produit, un numéro d’article, un nom propre. Elle est rapide, explicable, et ne demande aucun modèle.
La recherche vectorielle compare des plongements. Elle trouve « comment annuler mon abonnement » à partir de « résilier mon contrat », sans un mot en commun. Elle capte le sens.
La lexicale rate toute reformulation : l’utilisateur et le document ne partagent aucun terme, il n’y a aucun appariement.
La vectorielle rate l’exactitude. Un identifiant comme ERR-4471 est une chaîne rare, mal représentée, et elle sera confondue avec ERR-4417. C’est un échec spectaculaire et fréquent, parce qu’il touche précisément les requêtes de support technique.
On exécute les deux et on fusionne les classements. La méthode standard est la fusion réciproque des rangs : chaque document reçoit un score fondé sur sa position dans chaque liste, et l’on additionne. Son avantage est de ne pas exiger que les scores des deux systèmes soient comparables entre eux — ils ne le sont pas.
L’alternative est une somme pondérée des scores normalisés, avec un poids à régler. Plus fin, plus fragile.
Après fusion, un réordonnancement par encodage croisé sur les vingt ou trente premiers candidats. Ce modèle lit la question et le passage ensemble et donne un score de pertinence direct ; il est trop lent pour balayer l’index mais parfait pour trancher entre quelques candidats.
L’architecture qui en résulte — lexicale et vectorielle en parallèle, fusion, réordonnancement, génération — est le schéma par défaut d’un RAG sérieux.
La recherche vectorielle pour le sens, la lexicale pour l’exactitude, la fusion parce que les requêtes réelles mélangent les deux, et un réordonnancement parce que la précision du haut de liste est ce qui compte pour un contexte de quelques passages.
À corriger la principale faiblesse de la recherche vectorielle : elle compare deux vecteurs calculés indépendamment.
Un modèle de plongement encode la question d’un côté, le passage de l’autre, sans qu’ils se voient. C’est ce qui permet de précalculer l’index — et c’est ce qui limite la finesse : le vecteur du passage doit résumer tout ce qu’on pourrait lui demander, sans savoir ce qu’on lui demandera.
Un encodeur croisé prend la paire question-passage en une seule entrée. L’attention circule entre les deux, et le modèle produit un score de pertinence direct. Il est nettement plus précis.
Le prix : rien n’est précalculable. Il faut une passe complète par candidat, ce qui interdit de balayer un million de documents.
On paie le modèle coûteux sur cent passages au lieu d’un million.
Parce qu’un RAG ne fournit au modèle que quelques passages. Que la bonne réponse soit au rang 1 ou au rang 12 change tout, et c’est exactement là que la recherche vectorielle est incertaine. Ajouter un réordonnanceur est un changement local, sans réindexation, qui améliore fréquemment la justesse de plusieurs points.
Ce dernier point est celui que peu de candidats mentionnent, et c’est celui qui montre l’expérience de production.
On gèle les poids du modèle et on n’entraîne que deux petites matrices ajoutées à côté. Moins de 1 % des paramètres suffit à obtenir la quasi-totalité du gain d’un affinage complet.
Lire la réponse détailléeRarement, et jamais en premier. La réponse attendue est un ordre d’escalade, pas un choix binaire.
Sauter directement à l’affinage est l’erreur la plus commune, et un intervieweur la guette.
Il faut savoir énoncer ce qui bloque, sinon la réponse est théorique.
Un modèle affiné fige un instantané. Le modèle de base progresse, et votre variante affinée sur l’ancienne génération devient rapidement moins bonne que le nouveau modèle sans affinage du tout. J’ai vu ce scénario plusieurs fois : trois mois de travail rendus inutiles par une nouvelle version. Sur un projet à horizon long, c’est un argument sérieux pour rester sur l’invite tant qu’elle suffit.
Deux façons d’entraîner un modèle sur des préférences humaines plutôt que sur des réponses de référence.
L’affinage supervisé apprend à imiter une bonne réponse. Mais pour la plupart des questions, il n’existe pas une bonne réponse : il en existe beaucoup, dont certaines meilleures que d’autres. Écrire la réponse idéale est difficile ; comparer deux réponses est facile. L’alignement exploite cette asymétrie.
Cette pénalité est le détail à savoir expliquer. Sans elle, le modèle trouve des textes qui trompent le modèle de récompense sans être bons : c’est le piratage de la récompense, qui produit des réponses interminables, flatteuses et creuses.
Il faut faire tourner quatre modèles en même temps — la politique, la référence, la récompense, la valeur — ce qui est lourd en mémoire. L’entraînement est instable et sensible aux hyperparamètres. Et le modèle de récompense, lui-même imparfait, devient une cible à exploiter.
L’optimisation directe des préférences part d’une observation mathématique : sous l’objectif du RLHF, la politique optimale a une forme fermée en fonction de la récompense. On peut donc inverser la relation et réécrire l’objectif directement en fonction de la politique, ce qui élimine le modèle de récompense.
Il reste une perte supervisée sur les paires : augmenter la vraisemblance de la réponse préférée, diminuer celle de l’autre, en régularisant par rapport au modèle de départ. Pas d’apprentissage par renforcement, deux modèles au lieu de quatre, un entraînement stable.
Le DPO obtient des résultats comparables pour une complexité bien moindre, ce qui explique son adoption large — y compris chez ceux qui gardent le RLHF pour les dernières étapes. Les variantes qui ont suivi, comme les objectifs sans modèle de référence, poursuivent la même simplification.
Ce qui reste vrai des deux : la qualité est bornée par celle des annotations. Des annotateurs qui préfèrent systématiquement les réponses longues et assurées produisent un modèle long et assuré, y compris quand il a tort. C’est une des racines des hallucinations, et le lien mérite d’être fait.
Représenter les poids du modèle avec moins de bits : 8 bits, 4 bits, parfois moins, au lieu des 16 bits habituels. L’objectif est la mémoire et la vitesse, pas la qualité.
Un modèle de 7 milliards de paramètres :
C’est ce calcul que l’intervieweur veut voir. Il faut y ajouter le cache des clés et des valeurs, qui n’est pas négligeable sur un long contexte.
Point souvent manqué. La génération est limitée par la bande mémoire, pas par le calcul : à chaque jeton produit, il faut relire tous les poids depuis la mémoire du GPU. Diviser leur taille par quatre divise ce trafic par quatre, et le débit monte à peu près d’autant. Le gain de vitesse vient du transfert, pas de l’arithmétique.
Naïvement, on ramène chaque poids sur une grille de valeurs. Le problème est la présence de quelques valeurs extrêmes qui étirent l’échelle et écrasent tous les autres poids sur peu de niveaux.
Les méthodes utilisées traitent ce problème :
De 16 à 8 bits, la dégradation est en pratique négligeable. À 4 bits avec une bonne méthode, elle est faible mais mesurable, et elle se manifeste d’abord sur les tâches les plus exigeantes : raisonnement long, code, langues peu représentées. En dessous de 4 bits, elle devient visible.
La règle empirique utile à citer : un modèle plus grand quantifié en 4 bits vaut généralement mieux qu’un modèle plus petit en 16 bits, à mémoire égale.
Pas avec les classements publics. On construit un jeu de cas issus du produit, on définit ce qui compte, et on mesure à chaque changement d’invite ou de modèle comme on ferait tourner des tests.
Lire la réponse détailléeUne invite est une spécification. Ce qui la rend bonne est ce qui rend une spécification bonne : elle dit précisément ce qu’on attend, dans quel format, et ce qu’il faut faire dans les cas limites.
La tâche, énoncée sans ambiguïté. « Résume ce texte » laisse tout ouvert. « Résume ce texte en trois phrases, à destination d’un dirigeant, en te limitant aux décisions à prendre » est exécutable.
Le format de sortie, décrit explicitement. Si vous voulez du JSON, donnez le schéma. Si vous voulez trois puces, dites trois puces. La majorité des sorties « mal formatées » viennent d’un format jamais spécifié.
Deux ou trois exemples. C’est le levier le plus efficace pour une tâche précise. Un exemple d’entrée avec sa sortie idéale vaut mieux qu’un paragraphe de consignes, parce qu’il lève les ambiguïtés que vous n’avez pas vues.
Le contexte nécessaire, et rien de plus. Fournir les informations utiles ; ne pas noyer la consigne dans dix documents dont deux servent.
Le traitement des cas limites. Que faire si l’information n’est pas dans le texte ? Si la question sort du périmètre ? Sans réponse à ces questions, le modèle improvise, et il improvise différemment chaque fois.
Placer les consignes avant les documents longs, et les rappeler brièvement après. Sur un contexte étendu, ce qui est au milieu est le moins bien exploité, et une consigne enfouie entre deux documents est souvent perdue.
Une invite se versionne et se teste. On garde une dizaine de cas d’entrée, on compare les sorties avant et après modification. Sans cela, on corrige un cas et on en casse trois sans le savoir — c’est exactement le problème que résolvent les tests de non-régression, et une invite est du code.
Demander au modèle de dérouler son raisonnement avant de conclure plutôt que de répondre directement. C’est l’une des techniques les plus efficaces sur les tâches à plusieurs étapes.
L’explication mécanique est la bonne à donner. Le modèle produit un jeton à la fois, avec une quantité de calcul fixe par jeton. Pour une question exigeant plusieurs déductions, répondre immédiatement demande d’effectuer tout le raisonnement dans cette passe unique — ce qui est hors de portée.
Générer des étapes intermédiaires étale le calcul sur plusieurs passes. Chaque étape écrite devient une entrée disponible pour la suivante : le texte produit sert de mémoire de travail. On ne rend pas le modèle plus intelligent, on lui donne de la place.
Arithmétique en plusieurs opérations, problèmes de logique, questions exigeant de recouper deux faits, planification, code non trivial. Sur ces tâches, l’écart est important.
C’est le nuance qui distingue une bonne réponse.
Le raisonnement affiché n’est pas nécessairement le raisonnement réel. Des travaux ont montré qu’un modèle peut produire une justification qui ne correspond pas au facteur ayant déterminé sa réponse. Traiter la chaîne d’étapes comme une explication auditable est donc une erreur — c’est un mécanisme de calcul, pas un compte rendu fidèle.
La capacité du modèle à exécuter une tâche à partir d’exemples fournis dans l’invite, sans qu’aucun poids ne change. On lui montre trois paires entrée-sortie, il applique le schéma à la quatrième.
Le mot « apprentissage » est trompeur, et il faut le souligner : rien n’est appris au sens de l’entraînement. Le modèle est figé. Les exemples ne font que conditionner sa prédiction pour cet appel, et tout disparaît à l’appel suivant.
Pas tant la tâche que le format et la frontière de décision. Ils lèvent les ambiguïtés qu’une consigne écrite laisse ouvertes : quel niveau de détail, quelle casse, comment traiter les cas incertains, quoi faire d’une entrée vide.
C’est pourquoi le choix des exemples compte plus que leur nombre. Deux exemples bien choisis, dont un cas limite, valent mieux que dix exemples faciles et redondants.
Les exemples occupent du contexte et se paient à chaque appel. Sur un volume élevé, cela devient l’argument économique en faveur d’un affinage, qui déplace le comportement dans les poids.
Et l’effet sature : au-delà d’une dizaine d’exemples, le gain devient marginal, et sur un contexte long les premiers exemples peuvent être moins bien exploités que les derniers — d’où un biais de récence dont il faut se méfier quand on ordonne ses démonstrations.
En ne comptant pas sur la bonne volonté du modèle. La réponse attendue mentionne la contrainte au décodage, pas seulement une consigne dans l’invite.
Le demander dans l’invite. « Réponds en JSON. » Ça marche la plupart du temps, et « la plupart du temps » n’est pas un contrat. Le modèle ajoutera parfois un préambule, un bloc de code, une virgule finale.
Donner le schéma et un exemple. Nettement mieux. Le taux d’échec chute mais ne s’annule pas.
Le mode JSON du service, qui garantit une syntaxe valide. Attention : cela garantit du JSON parsable, pas la conformité à votre schéma. Les champs peuvent manquer ou changer de type.
Le décodage contraint, qui est la vraie réponse. À chaque étape de génération, on masque les jetons qui rendraient la sortie invalide au regard d’une grammaire ou d’un schéma. La sortie est alors structurellement garantie : ce n’est plus une probabilité, c’est une propriété du décodeur. Les sorties structurées basées sur un schéma JSON, chez les fournisseurs qui les proposent, reposent sur ce mécanisme.
L’appel de fonction, qui est la même idée exposée autrement : on déclare une signature, le modèle produit des arguments conformes.
Même avec une garantie de schéma, valider côté application. Un schéma respecté ne dit rien de la justesse sémantique : le champ date_facture peut être une date valide et fausse, le champ montant un nombre bien typé et inventé.
Donc : validation par schéma, puis contrôles métier — l’identifiant existe-t-il en base, le montant est-il dans une plage plausible, la date est-elle antérieure à aujourd’hui.
Demander à la fois un raisonnement libre et un JSON strict dans la même réponse. Soit le raisonnement pollue le JSON, soit la contrainte de format écrase le raisonnement. La solution est de prévoir un champ pour le raisonnement dans le schéma, placé avant les champs de résultat pour qu’il soit généré en premier.
En commençant par mesurer où part l’argent et le temps, qui ne sont pas au même endroit.
Le préremplissage traite l’invite : toutes les positions en parallèle, limité par le calcul. C’est ce qui détermine le temps jusqu’au premier jeton.
Le décodage produit la réponse jeton par jeton, limité par la bande mémoire puisqu’il faut relire tous les poids à chaque jeton. C’est ce qui détermine le débit ensuite.
Conséquence directe : un contexte long coûte cher en temps de première réponse, une réponse longue coûte cher en durée totale. Les leviers ne sont pas les mêmes.
Prix par requête égale jetons d’entrée fois tarif d’entrée plus jetons de sortie fois tarif de sortie. Multiplié par le volume quotidien, cela donne un budget mensuel. Faire ce calcul devant l’intervieweur, même avec des ordres de grandeur, vaut mieux qu’une liste de techniques : c’est ce qui montre qu’on sait décider où optimiser.
Le coût par requête et par fonctionnalité, le temps jusqu’au premier jeton et le temps total au 95e centile, le taux de succès du cache, la répartition des appels entre modèles. Sans ces mesures, l’optimisation est du folklore.
L’optimisation qui rend la génération autorégressive praticable, et la principale consommatrice de mémoire GPU au service d’un modèle.
Pour produire le jeton numéro n, l’attention a besoin des clés et des valeurs de tous les jetons précédents. Sans cache, il faudrait les recalculer intégralement à chaque nouveau jeton : le coût total de la génération serait cubique en longueur.
Or ces clés et valeurs ne changent pas — les jetons passés sont figés, et l’attention est causale. On les calcule donc une fois et on les garde.
Chaque nouveau jeton ne demande plus qu’une passe sur lui seul, en réutilisant le cache. Le coût par jeton devient linéaire en longueur de contexte au lieu de quadratique, et la génération passe de théorique à utilisable.
C’est aussi ce qui explique l’asymétrie de tarification entre entrée et sortie : l’entrée se traite en parallèle en une passe, la sortie exige une passe complète du modèle par jeton.
Le cache stocke deux tenseurs par couche et par jeton. Sa taille croît linéairement avec le contexte et avec le nombre de requêtes servies en parallèle. Sur un long contexte, il dépasse fréquemment la taille des poids du modèle.
C’est lui qui plafonne le nombre de conversations simultanées, bien plus souvent que le calcul. Un intervieweur qui pose cette question cherche généralement à savoir si vous avez déjà dimensionné un service.
Le cache d’invite proposé par les fournisseurs est précisément la réutilisation de ce cache entre requêtes partageant un même préfixe. C’est pourquoi la partie stable doit être placée au début : le cache est valide jusqu’au premier jeton qui diffère, et pas un de plus.
Des instructions cachées dans les données que le modèle lit prennent le pas sur les vôtres. Le modèle ne distingue pas consigne et contenu : la défense est architecturale, pas textuelle.
Lire la réponse détailléeEn traitant l’appel au modèle comme un transfert de données vers un tiers, et en appliquant les règles qu’on appliquerait à n’importe quel sous-traitant.
Un candidat qui commence par ces questions plutôt que par la technique montre qu’il a déjà passé une revue de conformité.
Un service hébergé public, avec engagement contractuel de non-rétention. Convient à beaucoup de cas, pas aux données réglementées les plus sensibles.
Un service hébergé dans votre nuage, dans votre région et votre compte, avec les données restant dans votre frontière contractuelle. C’est le compromis courant en entreprise.
Un modèle ouvert que vous servez vous-même, sur votre infrastructure. Aucune donnée ne sort. Coût réel : matériel, exploitation, et un modèle généralement moins capable que le meilleur service du marché. C’est la seule option pour certains secteurs.
Ne pas envoyer ce qui n’est pas nécessaire. Un résumé de dossier médical n’a pas besoin du nom du patient. Le principe de minimisation fait plus pour la conformité que n’importe quel chiffrement.
La pseudonymisation. Remplacer les identifiants directs par des jetons avant l’appel, restituer après. Deux limites à connaître, sinon la réponse paraît naïve : la détection automatique des données personnelles n’est jamais complète, et un texte peut réidentifier une personne sans contenir son nom, par accumulation de détails.
Le cloisonnement de l’index. Dans un RAG, la récupération doit être filtrée selon les droits de l’utilisateur, appliqués au niveau du service de recherche. Un index unique interrogé avec un compte de service qui voit tout est la faille la plus fréquente que j’aie rencontrée : le modèle devient un moyen de contourner les autorisations en place depuis dix ans.
On veut la traçabilité des appels pour le débogage et l’audit. Mais des journaux contenant les invites complètes créent une seconde copie des données sensibles, souvent moins protégée que la première, conservée plus longtemps, et accessible à toute l’équipe technique.
La règle : journaliser des identifiants et des métadonnées, expurger le contenu, et si l’on conserve des échanges pour l’évaluation, le faire dans un stockage soumis aux mêmes contrôles que la source.
Les données saisies par les utilisateurs finaux. Vos règles internes ne les contraignent pas : ils collent des contrats, des données clients, des extraits de code. Il faut le prévoir — avertissement dans l’interface, détection en entrée, et politique d’usage explicite — sinon la fuite viendra de l’usage, pas de l’architecture.
Le critère décisif est rarement la performance brute. C’est la combinaison de la confidentialité, du coût à votre volume et du contrôle que vous devez garder.
Pour un prototype ou un volume modéré, c’est presque toujours le bon départ. Commencer par autohéberger est une erreur de séquencement fréquente.
La capacité par euro dépend de la tâche. Sur de la classification, de l’extraction ou de la reformulation, un petit modèle ouvert affiné égale ou dépasse un grand modèle fermé pour une fraction du prix. Sur du raisonnement complexe, du code non trivial ou des langues peu dotées, l’écart reste en faveur des meilleurs modèles fermés.
D’où l’architecture qui gagne souvent : une flotte hétérogène. Un petit modèle ouvert pour le volume routinier, un grand modèle fermé pour les cas difficiles, avec un routage entre les deux. Proposer cela plutôt qu’un choix unique est la meilleure réponse à la question.
Un jeu d’évaluation à soi et une couche d’abstraction dans le code qui rend le fournisseur remplaçable. Avec ces deux éléments, la décision n’est plus irréversible : on essaie, on mesure, on bascule. Sans eux, on discute d’opinions.
« Ouvert » ne veut pas dire « libre ». Beaucoup de modèles distribuent leurs poids sous des licences restrictives — limites d’usage commercial, obligations d’attribution, restrictions sur l’entraînement d’autres modèles. Et « poids ouverts » n’est pas « source ouverte » : les données d’entraînement, elles, ne sont presque jamais publiées. À vérifier avant d’engager une architecture.
Entraîner un petit modèle à reproduire le comportement d’un grand, plutôt qu’à apprendre depuis les données brutes. On échange de la généralité contre de la taille sur un périmètre restreint.
Un jeu d’entraînement classique donne une seule étiquette par exemple : la bonne réponse. Le grand modèle, lui, donne une distribution complète sur les réponses possibles — et cette distribution contient de l’information supplémentaire, ce qu’on appelle les connaissances tacites. Savoir qu’une image est un chien à 70 % et un loup à 25 % en apprend plus que « chien ».
C’est aussi vrai des sorties textuelles : un grand modèle qui produit un raisonnement complet fournit une supervision beaucoup plus riche qu’une réponse finale seule.
Distillation sur les logits. On aligne les distributions de sortie du petit modèle sur celles du grand. Plus efficace, mais elle exige l’accès aux probabilités complètes — donc les poids du modèle enseignant, ou une API qui les expose.
Distillation sur les sorties. On fait générer un grand corpus de réponses par le grand modèle, et on affine le petit dessus, comme sur un jeu de données ordinaire. C’est ce qu’on fait avec un service fermé, et c’est de très loin le cas le plus courant en entreprise.
L’étape 3 est celle qu’on saute et qui coûte cher : distiller un corpus non filtré transmet fidèlement les erreurs de l’enseignant.
Sur une tâche étroite — classification, extraction, reformulation, routage — un petit modèle distillé approche souvent son enseignant pour un coût et une latence divisés par un facteur important. C’est l’une des optimisations les plus rentables en production.
Ce qu’on perd : tout ce qui sort du périmètre distillé. Le petit modèle n’a pas gagné en capacité générale, il a appris à imiter sur une distribution. Hors de cette distribution, il se dégrade sans avertir — et c’est le risque à énoncer, parce que la dégradation est silencieuse.
Les conditions d’utilisation de plusieurs fournisseurs interdisent d’utiliser leurs sorties pour entraîner un modèle concurrent. C’est une contrainte réelle, régulièrement invoquée. Le vérifier avant de lancer une campagne de génération fait partie du travail, et le mentionner en entretien montre qu’on a déjà eu cette conversation avec un service juridique.
Que la performance d’un modèle de langage suit une loi de puissance prévisible en fonction de trois quantités : le nombre de paramètres, la quantité de données d’entraînement et le calcul dépensé. La perte diminue régulièrement quand on augmente ces facteurs, sur plusieurs ordres de grandeur.
Parce que cela transforme l’entraînement d’un grand modèle en problème d’ingénierie budgétaire plutôt qu’en pari. On peut extrapoler depuis des expériences à petite échelle et prédire ce que donnera un entraînement cent fois plus gros. Sans cette régularité, personne n’engagerait des dizaines de millions sur une seule exécution.
Les premiers travaux concluaient qu’à budget de calcul donné, il fallait privilégier la taille du modèle. C’est ce qui a produit une génération de modèles très grands entraînés sur relativement peu de données.
Le résultat qui a corrigé cela — l’étude Chinchilla — a montré que ces modèles étaient largement sous-entraînés : à budget égal, un modèle plus petit entraîné sur beaucoup plus de jetons fait mieux. Le rapport optimal cité était d’environ vingt jetons d’entraînement par paramètre.
C’est le point que l’intervieweur attend, parce qu’il montre qu’on suit l’état de l’art et pas seulement le vocabulaire.
L’optimum Chinchilla minimise le coût d’entraînement. Or un modèle mis en production est servi des milliards de fois : le coût dominant est celui de l’inférence.
D’où la pratique actuelle : entraîner des modèles plus petits que l’optimum, sur beaucoup plus de données que l’optimum. On dépense davantage à l’entraînement pour obtenir un modèle moins cher à servir, et l’économie sur la durée de vie l’emporte largement. C’est ce qui explique la génération de petits modèles étonnamment performants entraînés sur des dizaines de milliers de milliards de jetons.
Sur votre corpus, avec vos questions. Le classement public sert à établir une liste de trois candidats, pas à décider.
La langue. Un modèle entraîné majoritairement sur de l’anglais se dégrade sur du français technique, et davantage sur un mélange de langues dans le même index. C’est le premier filtre, et le plus souvent négligé.
Le domaine. Le vocabulaire juridique, médical ou industriel est mal séparé par un modèle généraliste. Si votre corpus est spécialisé, ce point domine tout le reste.
La dimension du vecteur. Plus grande veut dire plus fine, mais aussi un index plus gros et une recherche plus lente. Beaucoup de modèles récents permettent de tronquer le vecteur sans réentraîner, ce qui laisse régler ce compromis après coup — un point utile à connaître.
La longueur maximale d’entrée. Un modèle limité à 512 jetons impose des passages courts, ce qui contraint votre stratégie de découpage. À vérifier avant de concevoir l’indexation, pas après.
Symétrique ou asymétrique. Point technique décisif : beaucoup de modèles de recherche attendent un préfixe différent pour la requête et pour le passage. L’oublier fait perdre plusieurs points de rappel, et le symptôme — « les résultats sont médiocres sans raison » — n’oriente pas vers cette cause.
Hébergé ou local. Un modèle local supprime le coût par appel et la sortie de données, au prix de l’exploitation. Comme l’indexation appelle le modèle une fois par passage, sur un gros corpus le calcul de coût peut être significatif.
Deux journées de travail, et la décision est fondée. C’est très en dessous du coût d’une réindexation complète découverte trois mois plus tard.
Changer de modèle de plongement impose de réindexer entièrement. Les vecteurs de deux modèles ne vivent pas dans le même espace et ne sont pas comparables. Sur un corpus volumineux, c’est une opération longue et coûteuse.
Deux conséquences pratiques : garder le texte source à côté des vecteurs pour pouvoir réindexer sans repasser par l’extraction, et versionner l’index avec le nom du modèle. Sans ce champ, une réindexation partielle mélange deux espaces vectoriels et produit des résultats incompréhensibles — une panne difficile à diagnostiquer, et une bonne chose à mentionner en entretien.
Souvent. C’est une question de maturité, et un candidat qui répond « toujours » se disqualifie plus sûrement qu’un candidat qui n’a jamais servi de modèle.
Quand une règle déterministe suffit. Valider un format d’adresse électronique, calculer une TVA, vérifier qu’une date est passée. Une expression régulière ou trois lignes de code sont plus rapides, gratuites, testables et justes à 100 %. Passer un modèle sur ce genre de tâche est un signe de mauvais jugement d’ingénierie.
Quand une requête structurée est la bonne réponse. « Combien de clients ont résilié en mars ? » est une requête SQL. Un RAG qui ramène quelques passages ne compte pas et donnera un nombre plausible et faux. La bonne architecture est de faire produire au modèle la requête, exécutée ensuite par la base — c’est la nuance qui distingue.
Quand un modèle classique fait mieux et coûte mille fois moins. Sur des données tabulaires, le gradient boosting reste la référence. Pour une classification à volume élevé avec des données annotées, un classifieur au-dessus de plongements gelés est plus rapide, plus stable et interprétable.
Quand la précision exigée est de 100 %. Comptabilité, calculs réglementaires, transactions financières. On ne construit pas une garantie forte sur un composant probabiliste sans vérification déterministe en aval.
Quand la latence est critique. Quelques centaines de millisecondes minimum, souvent plus. Sur un chemin qui doit répondre en dix millisecondes, c’est exclu.
Quand on ne peut pas expliquer la décision. Crédit, embauche, sanction : le cadre réglementaire exige une justification auditable et reproductible. Une chaîne de raisonnement produite par un modèle n’est pas une explication fidèle de sa décision.
Quand l’économie ne tient pas. Un modèle à quelques centimes par appel sur des millions d’appels quotidiens doit produire une valeur mesurable. Beaucoup de fonctionnalités impressionnantes en démonstration ne survivent pas à ce calcul.
Pour équilibrer, il faut savoir nommer ce que rien d’autre ne fait : comprendre du langage libre et non structuré, générer du texte fluide, s’adapter à une tâche nouvelle sans données annotées, et absorber la variété infinie des formulations humaines. Aucune règle écrite à la main n’y arrive.
La bonne réponse est rarement « modèle » ou « pas modèle », c’est une répartition. Le modèle à l’interface, pour comprendre l’intention et formuler la réponse ; du code déterministe pour tout ce qui doit être exact ; une base de données pour les faits et les agrégats ; des règles pour les décisions réglementées.
Le modèle traduit entre l’humain et le système. Ce qui doit être juste ne passe pas par lui.