Comment les grands modèles de langage ont appris à parler

Il y a quelque chose d’un peu troublant dans une première vraie conversation avec une machine.

Vous tapez une question. La réponse arrive presque aussitôt. Elle contient des paragraphes. Elle se souvient de ce que vous avez dit trois messages plus tôt. Elle peut expliquer une règle fiscale, réécrire une lettre d’amour, trouver l’erreur dans un programme Python et, si vous le demandez gentiment, inventer une histoire du soir sur un dragon déprimé qui travaille à la comptabilité.

Naturellement, on imagine un petit savant électronique caché dans l’ordinateur : il aurait lu Internet et fouillerait maintenant dans sa mémoire pour trouver la réponse.

Il n’y en a pas.

Ce qui se passe réellement est moins magique et, d’une certaine façon, beaucoup plus étrange.

Un grand modèle de langage (Large Language Model, LLM) moderne est un immense système mathématique entraîné à reconnaître les régularités du langage et à prédire ce qui va probablement suivre. Il procède un petit morceau de texte à la fois. De ce talent apparemment modeste naît une étonnante collection de capacités : écrire, traduire, programmer, résumer, répondre, analyser des documents et tenir des conversations qui semblent remarquablement humaines.

Pour comprendre pourquoi ces machines fonctionnent, et pourquoi elles se trompent parfois avec une assurance spectaculaire, il faut remonter bien avant ChatGPT, les processeurs graphiques et même l’industrie informatique moderne.

Avant le chatbot, il y avait une question

En 1950, le mathématicien britannique Alan Turing publia un article au titre merveilleusement direct : Computing Machinery and Intelligence.

L’article commençait par une question :

Les machines peuvent-elles penser ?

Turing en vit immédiatement la difficulté. Personne ne s’accordait sur une définition précise de la pensée. Les philosophes en débattaient depuis des siècles, sans même avoir besoin d’une prise électrique.

Il proposa donc quelque chose de plus pratique.

Imaginez une conversation écrite avec deux interlocuteurs invisibles. L’un est humain, l’autre est une machine. Si la machine converse assez bien pour que vous ne puissiez pas les distinguer de façon fiable, observer ce qu’elle sait faire est peut-être plus utile que débattre de sa capacité à « penser ».

Cette idée devint le test de Turing.

Turing n’inventa pas le grand modèle de langage. Il fit quelque chose de plus important : il contribua à déplacer la question de « Qu’est-ce que l’intelligence ? » vers « Quel comportement nous convaincrait de sa présence ? ».

Pendant des décennies, la réponse resta surtout théorique.

Les ordinateurs excellaient en arithmétique. La conversation, c’était une autre affaire.

Apprendre le langage aux ordinateurs, règle après règle

Les premiers programmes de langage étaient souvent construits à coups de règles.

Si tu vois ce mot, fais cela. Si une phrase a cette structure, classe-la ainsi. Si l’utilisateur parle de sa mère, demande-lui peut-être ce qu’il ressent envers elle.

Cela donnait des démonstrations ingénieuses, mais avec un problème fondamental : le langage humain refuse de se tenir tranquille.

Nous sommes sarcastiques. Nous omettons des mots. Nous inventons des expressions. Le sens change selon le contexte. En anglais, « That’s sick » peut évoquer une maladie ou un excellent solo de guitare.

Écrire assez de règles pour couvrir le langage ordinaire revenait un peu à rédiger un mode d’emploi pour avoir une personnalité.

Dans les années 1980 et 1990, les chercheurs se tournèrent de plus en plus vers les statistiques.

Plutôt que d’expliquer exactement le langage à l’ordinateur, on pouvait lui montrer d’énormes quantités de texte et laisser les mathématiques découvrir les régularités.

Une famille importante fut celle des modèles de langage à n-grammes.

Un tel modèle observe de courtes suites de mots et demande en substance :

Étant donné les mots que je viens de voir, quel mot vient habituellement ensuite ?

Face à l’expression anglaise :

peanut butter and… — beurre de cacahuète et…

vous attendriez probablement confiture plutôt qu’hélicoptère.

La machine pouvait apprendre la même chose en comptant les exemples.

C’était rudimentaire face à l’IA moderne, mais une transformation profonde avait eu lieu. On n’expliquait plus chaque règle à l’ordinateur. Il commençait à apprendre des régularités à partir de données.

Les mots deviennent des nombres

Un ordinateur ne comprend pas le mot chat comme la créature poilue assise sur votre clavier qui vous empêche de travailler.

Les ordinateurs comprennent les nombres.

Il fallait donc transformer le langage en mathématiques sans perdre tout son sens en chemin.

Une avancée importante fut le plongement lexical, ou word embedding.

Un mot est représenté par une longue liste de nombres : un point dans un espace mathématique de plusieurs centaines, voire milliers de dimensions.

Cela paraît abstrait, mais l’intuition est simple.

Les mots qui apparaissent dans des circonstances similaires tendent à acquérir des représentations numériques similaires.

Roi et reine se retrouvent liés. Paris et France aussi, ainsi que Tokyo et Japon, chien et chiot.

Le modèle ne possède pas une petite entrée de dictionnaire « chiot = jeune chien ». Il apprend ces relations parce que ces mots reviennent dans des voisinages linguistiques apparentés.

Pour la première fois, les machines disposaient de quelque chose comme une carte mathématique du sens.

Mais un autre problème subsistait.

Le langage n’est pas un sac de mots liés. L’ordre et le contexte comptent.

Comparez :

The bank approved my mortgage. — La banque a accepté mon prêt immobilier.

Et :

We sat on the bank of the river. — Nous nous sommes assis sur la berge.

Même mot anglais, bank. Mondes entièrement différents.

Pour bien traiter le langage, un modèle doit considérer les liens entre les morceaux d’une phrase, pas seulement ses mots isolés.

Ce qui nous amène à la percée qui a changé l’IA moderne.

Le Transformer arrive

En 2017, huit chercheurs publièrent Attention Is All You Need.

Le titre avait un petit côté provocateur. Les conséquences furent immenses.

L’article présentait une architecture appelée Transformer.

Son idée centrale était un mécanisme appelé attention.

L’attention permet au modèle de parcourir une séquence et d’évaluer quels éléments d’information sont particulièrement pertinents les uns pour les autres.

Prenez cette phrase :

Maria put the glass on the table because it was wet.

Maria a posé le verre sur la table parce que « it » était mouillé. Mais qu’est-ce qui était mouillé ?

Le verre ? La table ?

Un système de langage utile doit examiner les mots environnants et leurs relations pour décider.

L’attention fournit un mécanisme mathématique pour cela.

Au lieu de traiter le langage uniquement comme une chaîne rigide — premier mot, deuxième, troisième —, un Transformer peut examiner de nombreuses relations dans le texte et leur attribuer des importances différentes.

Cela rendit l’entraînement bien plus efficace sur le matériel parallèle moderne et permit de construire des modèles beaucoup plus grands.

Puis, en grandissant, ils firent quelque chose d’étonnant.

Ils devinrent utiles pour des tâches que personne n’avait explicitement programmées.

« Grand », mais grand comment ?

Dans 8B, 14B ou 70B, le B signifie billion en anglais, soit milliard.

Un modèle 8B contient environ huit milliards de paramètres.

Un paramètre est une valeur numérique ajustable dans un réseau de neurones.

Imaginez une gigantesque table de mixage avec des milliards de petits boutons.

Au début, ils sont mal réglés. Le modèle prédit mal.

L’entraînement présente des exemples, mesure les erreurs et tourne légèrement les boutons.

Encore et encore, un nombre de fois presque inimaginable.

Finalement, leur disposition capture une immense collection de régularités.

Ces valeurs enregistrées sont généralement appelées les poids du modèle.

Quand vous téléchargez un fichier de cinq, dix, vingt ou cinquante gigaoctets, une grande partie est tout simplement une énorme collection de nombres appris.

Le savoir du modèle n’est pas rangé dans une encyclopédie avec des chapitres « Napoléon », « Python » et « Comment préparer des lasagnes ».

Il est réparti dans les poids.

C’est pourquoi un modèle peut être brillant à un instant et bizarre au suivant.

Ce ne sont pas des bases de données traditionnelles.

Ce sont des machines à régularités.

La plus petite unité de conversation n’est pas un mot

Supposons que vous écriviez :

I absolutely love this computer.

Le modèle ne découpe pas forcément cette phrase comme vous comptez ses mots.

Avant que le texte arrive au réseau, un autre programme, le tokeniseur, le découpe en unités appelées tokens.

Un token peut être un mot entier.

Un morceau de mot.

Un signe de ponctuation.

Une partie d’un nombre.

Computer peut former un token pour un modèle et plusieurs pour un autre.

C’est essentiel : les systèmes d’IA mesurent leur espace de travail en tokens, pas en pages ni en mots.

Une limite de 32 000 tokens ne signifie pas 32 000 mots.

Elle signifie environ 32 000 morceaux selon le tokeniseur du modèle.

Différentes langues peuvent consommer des nombres différents de tokens pour la même idée. Anglais, russe, espagnol, chinois, code et notation mathématique peuvent être découpés différemment.

Voilà pourquoi les comptes de tokens semblent parfois mystérieux au début.

Le modèle lit la même phrase que vous, mais mathématiquement il peut voir une collection de morceaux très différente.

La ponctuation invisible des conversations avec l’IA

Une autre catégorie de tokens reste généralement invisible.

Ce sont les tokens spéciaux.

Imaginez une pièce de théâtre sans noms pour indiquer qui parle. Vous seriez vite perdu.

Les conversations avec l’IA ont le même problème.

Il faut des repères invisibles pouvant signifier :

Les instructions du système commencent ici.

C’est l’utilisateur qui parle.

L’assistant doit maintenant répondre.

Ce message est terminé.

Un exemple important est le token de fin de séquence (End-of-Sequence, EOS).

C’est une ponctuation particulière que comprend le modèle plutôt que le lecteur.

Chaque famille utilise différents tokens spéciaux, généralement insérés automatiquement par l’application.

Vous ne les verrez peut-être jamais.

Mais ils prennent de la place.

Nous arrivons ainsi à l’un des aspects les plus mal compris de l’IA locale.

Le modèle a un bureau, et ce bureau n’est pas infini

Chaque modèle de langage possède une fenêtre de contexte.

C’est la quantité d’information avec laquelle il peut travailler activement à un instant donné.

Imaginez un chercheur brillant avec une immense bibliothèque, mais un seul bureau.

Les livres représentent les connaissances acquises pendant l’entraînement.

Le bureau représente la fenêtre de contexte.

Tout ce qu’il doit considérer maintenant doit tenir sur ce bureau.

Votre question prend de la place.

L’historique aussi.

Un document aussi.

Le code aussi.

Les consignes aussi.

Les outils aussi.

La réponse a elle aussi besoin de place.

Un modèle annoncé à 32 000 tokens ne vous offre donc pas 32 000 tokens pour votre document.

Vous en avez peut-être déjà dépensé plusieurs milliers avant son arrivée.

C’est particulièrement important pour les agents : instructions système, descriptions d’outils, compétences chargées, résultats de recherche, fichiers, actions précédentes et historique peuvent arriver avant même la tâche qui vous intéresse.

La fenêtre théorique et le contexte de travail utilisable ne sont pas la même chose.

Cette différence est l’une des raisons de la création de Green Zone.

Le modèle a aussi besoin d’un carnet

Un autre consommateur de mémoire porte un nom merveilleusement obscur :

Cache de clés et de valeurs (Key-Value Cache, KV cache).

On dirait quelque chose de caché dans un serveur de bases de données. L’idée est bien plus simple.

Imaginez une longue conversation.

À chaque nouvelle phrase, votre interlocuteur ne reprend pas depuis le début pour recalculer mentalement toutes les phrases précédentes.

Il conserve des informations de travail sur ce qui s’est passé.

Un Transformer fait quelque chose d’analogue.

En traitant les tokens, il calcule des informations internes appelées clés et valeurs. Au lieu de tout recalculer pour chaque nouveau token, le système les conserve temporairement dans le KV cache.

Les poids ressemblent au savoir appris à long terme ; le KV cache, au carnet temporaire de la conversation en cours.

Plus la conversation s’allonge, plus le carnet grossit.

Et ce carnet occupe de la mémoire.

D’où un problème pratique important.

Un modèle peut techniquement tenir sur votre carte graphique et être presque inutilisable pour le travail prévu.

Supposons qu’elle possède 32 gigaoctets de mémoire vidéo (Video Random Access Memory, VRAM).

La VRAM est la mémoire rapide utilisée par le processeur graphique (Graphics Processing Unit, GPU).

Si les poids occupent 27 gigaoctets, vous pouvez être tenté de célébrer.

Vingt-sept est inférieur à trente-deux.

Victoire !

Pas forcément.

Il reste environ cinq gigaoctets pour le KV cache, les tampons du programme, la mémoire temporaire et tout le nécessaire pendant l’inférence.

C’est comme acheter un canapé qui tient dans le salon, mais empêche d’ouvrir la porte.

Le canapé rentre.

Le salon ne fonctionne plus.

Quantification : apprendre aux grands nombres à voyager léger

C’est ici qu’intervient la quantification.

Les poids sont des nombres. Les ordinateurs peuvent les stocker avec différents degrés de précision numérique.

Davantage de précision conserve davantage d’information par nombre, mais demande plus de mémoire.

La quantification utilise moins de bits pour stocker ces nombres.

Imaginez consigner des mesures de laboratoire.

Vous pouvez écrire :

3.14159265358979

Ou :

3.14

La seconde version prend moins de place. Elle abandonne aussi de la précision.

La quantification applique une version bien plus sophistiquée de cette idée aux poids des réseaux de neurones.

Vous rencontrerez Q8, Q6, Q5 et Q4.

Le Q signifie quantifié.

Le chiffre indique approximativement le nombre de bits utilisés pour représenter les poids.

Q8 utilise environ huit bits.

Q4, environ quatre.

Q4 demande donc généralement beaucoup moins de mémoire que Q8.

Cela ne transforme pas un modèle de huit milliards de paramètres en un modèle de quatre milliards.

Il possède toujours environ huit milliards de paramètres.

Vous avez simplement compacté leur représentation numérique.

Il y a une contrepartie.

Moins de précision économise de la mémoire, mais perd de l’information.

Heureusement, les méthodes modernes préservent parfois étonnamment bien la qualité. Une bonne version Q4 ou Q5 peut être très utile tout en occupant beaucoup moins de mémoire qu’une version seize bits.

Vous rencontrerez aussi la virgule flottante sur 16 bits (FP16) et le Brain Floating Point 16 (BF16).

Ce sont des formats de précision supérieure courants en IA.

La question pratique n’est pas :

Quel format a le plus de précision ?

Mais :

Quel format fournit une qualité suffisante tout en laissant assez de mémoire pour mon travail ?

Voilà une bien meilleure question.

Pourquoi un modèle Instruct a de bonnes manières

Les noms de modèles donnent des indices.

Par exemple :

Qwen 8B Instruct

Qwen indique la famille.

8B indique environ huit milliards de paramètres.

Instruct signifie tout autre chose.

Après son énorme entraînement initial, le modèle peut manier le langage assez bien tout en restant un interlocuteur maladroit.

Vous demandez :

Explique la gravité à un enfant de douze ans.

Un modèle simplement préentraîné n’a pas nécessairement appris à se comporter comme un assistant utile.

Les développeurs ajoutent donc un entraînement avec des exemples de consignes et de réponses souhaitables.

C’est l’ajustement sur instructions.

Le modèle voit des exemples comme :

Utilisateur : Résume ce paragraphe.

Suivis d’un résumé utile.

Ou :

Utilisateur : Écris une fonction Python qui trie ces données.

Suivis du code approprié.

Avec assez d’exemples, il comprend mieux le schéma :

Une personne me demande quelque chose ; je dois essayer de le faire.

D’où le mot Instruct.

C’est davantage une description de son éducation qu’une mesure de son intelligence.

Le modèle de base est allé à l’école.

Le modèle Instruct a aussi suivi des cours de savoir-vivre.

L’ajustement fin : renvoyer le modèle à l’école

Plus généralement, l’ajustement fin, ou fine-tuning, consiste à poursuivre l’entraînement d’un modèle déjà formé pour un usage plus spécialisé.

Imaginez quelqu’un qui, après une formation universitaire générale, entre en médecine.

Il n’oublie pas comment lire ou compter.

Il acquiert une formation spécialisée.

Un modèle général peut ainsi être adapté à la programmation, la médecine, la finance, l’assistance clientèle, la rédaction juridique ou certains styles d’interaction.

L’ajustement complet peut coûter cher, car il modifie énormément de poids.

Une technique plus légère, l’adaptation de faible rang (Low-Rank Adaptation, LoRA), permet une adaptation plus efficace en entraînant des composants supplémentaires relativement petits.

Imaginez LoRA comme des annotations soigneusement préparées ajoutées à une encyclopédie, plutôt qu’une réécriture de l’ouvrage.

Le livre principal reste presque inchangé.

Trois familles de Transformer

Tous les Transformer ne sont pas construits pour le même travail.

Une catégorie est l’encodeur.

Il lit des informations et en produit une représentation numérique.

BERT, de Google, est un exemple célèbre.

Les encodeurs servent notamment à reconnaître le sujet d’un texte, trouver des documents similaires, extraire des noms ou classer des sentiments.

Il existe ensuite les décodeurs.

Ils génèrent de nouveaux tokens.

La plupart des modèles conversationnels locaux — Llama, Qwen, Mistral, Gemma et autres — appartiennent principalement à cette famille.

Ils savent répondre, écrire, programmer et prolonger des séquences.

Enfin, les systèmes encodeur-décodeur, également appelés séquence à séquence, réunissent les deux.

Une partie lit l’entrée. Une autre produit la sortie.

T5 et BART en sont des exemples.

Ils se sont révélés particulièrement utiles pour traduire et résumer.

Inutile de mémoriser ces catégories pour utiliser l’IA locale.

Mais elles expliquent pourquoi deux modèles portant l’étiquette Transformer peuvent se comporter très différemment.

Un pick-up et une Formule 1 ont tous deux un moteur.

Vous ne choisiriez pas entre eux en comptant seulement les cylindres.

L’étrange puissance du prochain token

Voici peut-être le fait le plus étrange sur les grands modèles de langage.

Au fond, beaucoup de modèles génératifs sont entraînés à une tâche presque embarrassante de simplicité :

prédire la suite.

Vous écrivez :

La capitale de la France est…

Le modèle attribue des probabilités aux prochains tokens possibles.

Paris reçoit une probabilité très élevée.

Banane en reçoit, espérons-le, une très faible.

Le modèle choisit un token.

Puis recommence.

Encore.

Et encore.

Des milliers de fois.

De cette répétition naissent des paragraphes, programmes, explications, traductions, poèmes, arguments, plaisanteries et parfois des absurdités complètes, débitées avec l’assurance de quelqu’un qui indique le chemin dans une ville où il n’a jamais mis les pieds.

Ce dernier point compte.

Un LLM n’est pas une machine à vérité.

C’est une machine à prédiction.

Son objectif est de produire une suite plausible, pas de jurer sous serment que chaque phrase est exacte.

Voilà pourquoi il peut halluciner : produire une information convaincante, mais fausse.

Le mot est imparfait. Le phénomène est réel.

Le modèle ne « ment » pas nécessairement.

Il génère une suite conforme aux régularités apprises, même lorsque le fait sous-jacent est faux.

Du chatbot à l’agent

Seul, un modèle de langage ne peut que générer de l’information.

Un agent d’IA ajoute des outils.

Retrouvons notre chercheur à son bureau.

Sans outils, il répond avec ses souvenirs et les documents placés devant lui.

Donnons-lui maintenant :

une calculatrice,

un moteur de recherche,

un accès aux fichiers,

une base de données,

un interpréteur Python,

et la permission d’effectuer certaines actions.

Il devient beaucoup plus utile.

Un agent fonctionne de façon similaire.

Le LLM fournit la composante de langage et de décision.

Les logiciels ordinaires exécutent les actions.

Pour obtenir un nombre dans une base, il demande l’outil correspondant.

Pour examiner un fichier, il demande un outil de lecture.

Pour calculer, il appelle une calculatrice au lieu d’essayer d’en être une.

Cette distinction compte : on parle parfois des agents comme si le modèle avait magiquement acquis de nouveaux pouvoirs.

Ce n’est pas le cas.

Il a reçu des outils.

Un menuisier avec une perceuse reste le même menuisier.

La perceuse change simplement ce qu’il peut accomplir.

L’IA locale change les questions

Dans un service d’IA en ligne, le matériel appartient à quelqu’un d’autre.

Vous envoyez la demande.

Un centre de données lointain se charge des processeurs graphiques, de la mémoire, du refroidissement, des alimentations et de l’effrayante facture d’électricité.

Exécuter un modèle localement change la relation.

Le matériel est désormais le vôtre.

Des questions autrefois réservées aux ingénieurs des centres de données arrivent sur votre bureau.

Combien ai-je de VRAM ?

Quelle taille font les poids ?

Quelle quantification choisir ?

Combien de contexte puis-je me permettre ?

Combien de mémoire prendra le KV cache ?

Puis-je charger ce modèle et garder assez de place pour quelque chose d’utile ?

Au début, cela ressemble à une soupe de lettres.

GPU. VRAM. KV. Q4. Q8. FP16.

Mais sous ces sigles se trouve un problème très ordinaire :

Vous avez une place limitée. Que voulez-vous y mettre ?

C’est ce problème que Green Zone cherche à rendre visible.

La différence entre tenir et fonctionner

Imaginez deux personnes préparant leurs valises.

La première remplit entièrement la sienne de vêtements.

Elle réussit triomphalement à fermer la fermeture éclair.

Victoire ?

Puis elle se souvient des chaussures, des médicaments, de la brosse à dents et du passeport qui a mystérieusement fini tout au fond.

La seconde laisse volontairement de la place.

Techniquement, la première valise contient plus de vêtements.

En pratique, la seconde est mieux préparée au voyage.

L’IA locale rencontre le même problème.

Vous pouvez charger le plus gros modèle possible et vous féliciter parce qu’il tient.

Mais s’il ne reste presque rien pour le contexte et l’état de travail, vous avez peut-être construit un système impressionnant qui accomplit difficilement la tâche pour laquelle vous l’avez acheté.

Choisir un modèle n’est donc pas un concours du plus gros nombre suivi de B.

Une configuration utile est un équilibre.

Capacités du modèle.

Quantification.

Contexte.

KV cache.

Outils.

Fichiers.

Historique.

Place pour la réponse.

Et mémoire physique disponible sur votre carte graphique.

La meilleure configuration n’est pas forcément le plus gros modèle que le matériel arrive à charger.

C’est celle qui lui laisse assez de place pour travailler.

Une fois cette différence comprise, la forêt intimidante de chiffres sur les pages de téléchargement devient beaucoup moins mystérieuse.

Vous ne demandez plus :

Puis-je faire entrer ce modèle à tout prix dans ma carte graphique ?

Vous posez la vraie question :

Si je mets ce modèle sur ma carte graphique, combien de place restera-t-il pour penser, se souvenir de la conversation, utiliser mes fichiers et terminer le travail ?

C’est là que l’IA locale cesse d’être une collection de caractéristiques mystérieuses et devient un problème d’ingénierie que chacun peut comprendre.