Du prompt à la réponse : comprendre le fonctionnement complet d’un LLM

La question quitte le champ de saisie

Tout commence dans une interface, par exemple un écran de chat. Imaginons : « Explique-moi simplement comment fonctionne l'IA. » À cet instant, le navigateur contient seulement du texte ; aucun calcul neuronal n’a encore eu lieu.

L’interface réunit le message, l’identifiant de la conversation, le modèle choisi et certains réglages dans les données de la requête (payload).

{
  "message": "Explique-moi simplement comment fonctionne l'IA.",
  "conversationId": "conversation-123",
  "model": "selected-model"
}

Dans une vraie application, l’interface enverrait ensuite ces données au serveur par une requête HTTP, souvent vers une API. Le navigateur n’exécute pas pour autant le modèle.

Dans le cours :Leçon 14 · Du champ de saisie au modèle

Le serveur vérifie et dirige la demande

Le backend reçoit la requête. Il identifie la route et peut vérifier l’authentification (qui fait la demande ?) et l’autorisation (qu’a-t-elle le droit de faire ?). Il valide aussi les champs, leur type, leur taille et les réglages autorisés, puis dirige la demande vers le service qui parlera au modèle.

Ces étapes relèvent de l’application et de son infrastructure, pas du réseau neuronal. Une personne peut être authentifiée sans avoir le droit d’utiliser tous les modèles ou toutes les données.

Dans le cours :Leçon 14 · Du champ de saisie au modèle

L’application prépare ce que le modèle va lire

La question seule ne constitue pas toujours l’entrée envoyée au modèle. Un composant d’assemblage du contexte peut réunir les instructions système ou développeur, la question, une partie de l’historique, des informations utiles de l’application et les paramètres de génération. L’ensemble doit respecter une hiérarchie d’instructions : un document externe ne doit pas pouvoir se faire passer pour une consigne de confiance.

Ce contexte peut être sérialisé avec un format de conversation puis transmis au moteur d’inférence, directement ou au moyen de l’API d’un fournisseur. Le contexte a une taille limitée par la fenêtre de contexte.

Dans le cours :Leçon 14 · Du champ de saisie au modèle

Le texte devient une suite de tokens et d’identifiants

Le modèle ne reçoit pas directement les caractères comme le ferait un programme qui manipule une chaîne. Un tokenizer découpe le texte en unités appelées tokens : un token peut être un mot, un morceau de mot, une ponctuation ou une autre unité.

"Le chat mange."  →  ["Le", " chat", " mange", "."]
                      →  [10, 11, 12, 13]

Chaque unité est remplacée par un Token ID tiré du vocabulaire du tokenizer. Ce découpage pédagogique n’est pas une règle universelle : il dépend du tokenizer, et un mot peut correspondre à plusieurs tokens.

Dans le cours :Leçon 01 · TokenisationLeçon 02 · Identifiants numériquesLeçon 13 · Tokenisation BPE

Les identifiants deviennent des vecteurs numériques

Le modèle utilise chaque identifiant pour retrouver un vecteur dans sa table d’embeddings. Cette représentation interne est apprise pendant l’entraînement. Elle n’est ni une définition de dictionnaire ni une étiquette explicitement attribuée au mot.

Ces embeddings de tokens ne doivent pas être confondus avec les vecteurs produits par un modèle spécialisé pour rechercher des documents par sens : les principes mathématiques se ressemblent, mais les objectifs diffèrent.

Dans le cours :Leçon 03 · Embeddings

Le modèle tient compte de l’ordre des tokens

« Le chien poursuit le chat » et « Le chat poursuit le chien » partagent des mots, mais pas le même sens. Le Transformer doit donc intégrer leur ordre. Les informations positionnelles peuvent être ajoutées aux représentations ; d’autres architectures, comme RoPE, les introduisent dans les calculs d’attention, en particulier dans les Queries et les Keys.

Ces méthodes ont des implémentations différentes. Leur objectif commun est de donner au modèle des informations sur les positions et leurs relations.

Dans le cours :Leçon 05 · Encodage positionnel

Les blocs Transformer mélangent et transforment l’information

Dans un bloc Transformer, l’auto-attention (Self-Attention) permet à chaque position de tenir compte d’autres positions autorisées. Trois projections portent les noms Query (Q), ce que la position cherche ; Key (K), ce qui aide à établir une correspondance ; et Value (V), l’information qui sera combinée.

Les scores entre Query et Key sont normalisés par Softmax en poids d’attention, puis ces poids servent à combiner les Values. Le masque causal empêche une position de consulter les tokens futurs. Plusieurs têtes d’attention peuvent apprendre des relations différentes avant que leurs résultats soient combinés.

Le bloc comprend aussi des connexions résiduelles, une normalisation telle que LayerNorm ou RMSNorm, puis un réseau Feed-Forward qui transforme chaque position avec des projections et une non-linéarité. L’ordre précis dépend de l’architecture.

Dans le cours :Leçon 06 · Matrice d’attentionLeçon 07 · Bloc Transformer

Les blocs sont empilés

Un LLM enchaîne généralement de nombreux blocs : la sortie de l’un alimente le suivant, et chaque couche possède ses paramètres appris. Les représentations évoluent au fil de cette profondeur.

Il ne faut pas supposer que chaque couche remplit seule une tâche linguistique précise : les comportements appris peuvent émerger et se répartir sur plusieurs couches.

Dans le cours :Leçon 07 · Bloc Transformer

La tête de langage calcule les scores des tokens possibles

Après une normalisation finale éventuelle, la Language Modeling Head (LM Head) projette la représentation vers les choix du vocabulaire. Elle produit un score par token candidat : ces scores bruts sont les logits. Avec 50 000 tokens dans le vocabulaire, la position considérée reçoit 50 000 scores.

Un score plus élevé indique un candidat mieux classé, mais les logits ne sont pas eux-mêmes des probabilités. Pendant la génération, on utilise généralement les scores de la dernière position disponible pour choisir le token suivant.

Dans le cours :Leçon 08 · Logits et probabilités

Les scores deviennent une distribution de probabilités

Une fonction Softmax appliquée aux logits peut les transformer en valeurs positives dont la somme vaut 1. Par exemple : token A 75 %, token B 20 %, token C 5 %. Cette distribution décrit les prédictions du modèle ; elle ne garantit pas que la réponse soit vraie.

La température modifie la concentration de cette distribution : une valeur faible favorise les mieux classés ; une valeur plus élevée répartit généralement davantage les chances. Elle influe sur la diversité possible, pas sur les connaissances apprises.

Dans le cours :Leçon 08 · Logits et probabilités

Le moteur choisit le prochain token

Une stratégie de décodage transforme la distribution en un Token ID. Le décodage glouton prend toujours le score maximal ; l’échantillonnage probabiliste (sampling) tire un candidat selon les probabilités. Le choix change le comportement et la diversité, mais aucune stratégie ne garantit une réponse correcte.

Dans le cours :Leçon 09 · Sampling et décodage

La génération avance token après token

Le moteur ajoute le token choisi à la séquence, recalcule les scores et sélectionne le suivant. C’est la génération autorégressive : chaque token est prédit à partir du préfixe déjà disponible, et la réponse n’est donc pas nécessairement produite d’un seul coup.

Le moteur s’arrête, par exemple, à un token de fin, une limite de tokens, une séquence d’arrêt configurée, une annulation ou une erreur. Le motif d’arrêt importe : une limite peut couper une réponse en plein milieu.

Dans le cours :Leçon 04 · Prédiction du token suivantLeçon 09 · Sampling et décodage

Prefill et Decode organisent le calcul

La phase de Prefill traite les tokens du prompt dans le Transformer et prépare la génération. Les positions du prompt peuvent être calculées en parallèle, tout en respectant le masque causal. La phase de Decode produit ensuite les tokens l’un après l’autre.

Pour ne pas recalculer les clés et valeurs des positions déjà traitées, le moteur garde généralement un cache KV. Cette optimisation évite du travail répétitif au prix d’une consommation mémoire supplémentaire. Le Prefill désigne le premier passage du prompt dans le Transformer, pas une étape ajoutée après le premier token.

Dans le cours :Leçon 15 · Cache KV et vitesse

Les identifiants sont reconvertis en texte

Le tokenizer décode les Token IDs générés pour reconstruire une chaîne lisible : par exemple [10, 11, 12, 13] → « Le chat mange. ». Certains tokens représentent des morceaux de mots ou des octets. On ne peut donc pas supposer qu’un token correspond toujours à un mot ou à un caractère Unicode isolé.

Dans le cours :Leçon 16 · Du modèle à l’écran

Le streaming fait apparaître la réponse progressivement

Sans streaming, l’application attendrait la fin de toute la génération avant d’afficher le résultat. Avec le streaming, le moteur transmet les fragments à mesure qu’ils sont produits ; le backend les relaie au navigateur qui met l’interface à jour.

Un mécanisme fréquent est Server-Sent Events (SSE), qui transporte des événements progressifs sur HTTP : un fragment de texte, un autre, puis un événement de fin. Le système doit aussi gérer l’annulation, les déconnexions et les clients lents pour éviter l’accumulation de données.

event: delta
data: {"text":"Bonjour"}

event: delta
data: {"text":", voici ma réponse."}

event: done
data: {"finishReason":"stop"}

Dans le cours :Leçon 16 · Du modèle à l’écran