Comment un modèle apprend à écrire : tokens, transformateurs et prompts

Quand un modèle répond quelque chose d'intéressant, la sensation est de quelqu'un qui pense. Ce qu'il y a derrière est plus prosaïque et plus facile à suivre : un modèle entraîné à prédire quel token vient après une séquence, en répétant cette opération token par token jusqu'à fermer la réponse. Ce post parcourt le cycle complet : comment se découpe le texte, comment il devient des vecteurs, comment on lui demande les choses et comment on construit un agent dessus. Ce qui suit vient du module « Introduction to generative AI and agents » de Microsoft Learn.

L'astuce expliquée

Il n'y a pas d'assistants derrière le rideau : il y a des techniques mathématiques de statistique, de data science et d'apprentissage automatique. Au noyau se trouvent les LLM (large language models) et les SLA (small language models) compacts, entraînés à générer des complétions à partir d'un prompt, qui est l'instruction qu'on lui écrit. L'image la plus proche est un correcteur prédictif surpuissant : la même intuition qui complète le mot pendant que vous écrivez, portée à l'échelle de centaines de milliers de termes.

La conséquence pratique est que le modèle ne consulte rien pendant qu'il rédige : il suit le motif statistique qu'il a appris. C'est pourquoi ce que vous contrôlez de l'extérieur sont deux leviers concrets, comment le modèle prépare le texte et ce que vous lui écrivez, et c'est pourquoi le reste de ce post s'occupe des deux.

Tokenisation : le texte se découpe d'abord

Le texte d'entraînement est divisé en tokens, qui peuvent être des mots, des sous-mots ou de la ponctuation, et chaque token reçoit un identifiant entier unique. Avec plus de données, plus de tokens entrent dans le vocabulaire ; les vocabulaires des LLM actuels ont des centaines de milliers de tokens.

La taille du vocabulaire compte pour deux raisons. En coupant les mots longs en sous-mots, le modèle peut représenter des termes rares sans qu'il existe une entrée par mot de la langue. Et en travaillant avec des identifiants entiers, l'opération interne devient arithmétique : le texte cesse d'être du texte et devient un tableau de nombres qu'on peut comparer, mesurer et transformer.

Le transformateur : deux blocs qui font des travaux différents

Les modèles d'aujourd'hui s'appuient sur un transformateur, et à l'intérieur deux blocs coexistent.

L'encodeur convertit les tokens en embeddings, qui sont des vecteurs avec des attributs linguistiques et sémantiques, en appliquant une attention multi-têtes. L'attention évalue comment chaque token est influencé par son contexte : le mot « banque » reçoit un vecteur différent selon que la phrase parle de rivière ou de prêts.

Le décodeur prédit itérativement le token suivant en considérant seulement les tokens précédents, avec ce qu'on appelle l'attention masquée. Ce bloc s'est entraîné sur des séquences complètes, en comparant chaque prédiction à ce qui venait après dans le texte de référence, et répète le processus jusqu'à ce que la séquence soit finie.

flowchart LR
    T[Texte d'entraînement] --> K[Tokenisation : mots et sous-mots avec identifiant]
    K --> E[Encodeur : embeddings avec attention multi-têtes]
    E --> D[Décodeur : prédit le token suivant]
    D -->|continue| E
    D -->|fin de séquence| S[Réponse complète]

En termes simples : le texte se découpe, chaque morceau devient un vecteur qui connaît son contexte, et le décodeur devine d'affilée le prochain morceau jusqu'à ce qu'il soit temps de s'arrêter.

Les messages : système, utilisateur et historique

Les instructions reçues par le modèle se séparent en deux types. L'instruction système fixe le comportement, le ton et les contraintes, et c'est l'application qui la fixe, pas la personne qui tape. L'instruction utilisateur provoque la réponse à une question ou instruction concrète, et le modèle la sert en respectant le message système. Dans un chat, celui qui utilise l'application ne voit et ne tape que ses propres prompts ; le système opère toujours en dessous.

À cela s'ajoute l'historique : pour maintenir la cohérence, l'application inclut des versions résumées de ce qui a été dit dans les requêtes suivantes, si bien que la sixième question de la conversation se comprend toujours avec la première. Le résumé est délibéré : l'application envoie un extrait de la conversation, pas la transcription complète, et ainsi le message ne grandit pas sans contrôle.

flowchart TD
    Sys[Message système : rôle, ton et limites] --> M
    Hist[Historique résumé] --> M
    Doc[Documents récupérés par RAG] --> M
    Usr[Message de l'utilisateur] --> M
    M[Prompt assemblé] --> LLM[Modèle : prédit la réponse token par token]

Le prompt qui atteint le modèle est la somme de ces quatre pièces, et c'est pourquoi deux personnes qui posent la même question peuvent recevoir des réponses différentes : le même message n'arrive pas.

RAG : des données réelles dans le prompt

RAG (génération augmentée par récupération) récupère de l'information pertinente, comme des documents ou des e-mails, et l'ajoute au prompt pour que la réponse s'appuie sur des données réelles. L'exemple classique est la question sur le plafond de dépenses de voyage : sans RAG le modèle répond avec un chiffre générique ; avec RAG il récupère la politique de dépenses de l'organisation et répond avec le nombre qui commande à l'intérieur.

Il vaut noter que le mécanisme est simple : on ne réentraîne pas le modèle, on agrandit le message. Ce changement dans le prompt est ce qui transforme une réponse d'internet en réponse de l'organisation.

Quatre conseils pour mieux écrire un prompt

La source ferme la partie prompts avec quatre recommandations concrètes :

Être clair et spécifique. Une demande vague renvoie une réponse vague.
Ajouter du contexte. Sujet, public et format : qui va lire cela et sous quelle forme.
Utiliser des exemples. Le style désiré se montre, se demande une fois et se répète.
Demander une structure. Puces, tableaux ou listes numérotées quand le résultat doit avoir une forme.

Un exemple de prompt bien construit commence par « Tu es un assistant technique » dans le message système, et continue dans celui de l'utilisateur avec « Résume les trois risques principaux de migrer la base de données, pour un comité de direction, en puces d'une ligne ». Les quatre conseils y sont tous là : rôle fixe, contexte avec public, demande spécifique et format demandé. Le contre-exemple est « Parle-moi du problème », qui ne fixe ni rôle, ni public, et ne demande pas de forme : la sortie sort rédigée au hasard.

La morale est gênante et utile : la qualité de la réponse dépend autant du modèle que de la demande qui lui est envoyée.

Les quatre conseils se complètent. Être clair et spécifique évite que le modèle ait à deviner la demande. Ajouter du contexte (sujet, public, format) lui donne de quoi répondre, parce que la même question posée pour un comité de direction et pour un groupe de travail demande deux réponses différentes. Utiliser des exemples fixe le style de sortie avec deux ou trois lignes au lieu d'un paragraphe de description. Et demander une structure transforme un texte en vrac en puces, tableaux ou listes numérotées qui se lisent vite.

Agents et systèmes multi-agents

Un agent combine trois choses : un LLM pour raisonner et rédiger, des instructions qui définissent son rôle et son comportement, et des outils de connaissance ou d'action. Avec ces pièces, il automatise des tâches et collabore comme assistant numérique.

Quand la tâche est grande, on construit un système multi-agents : plusieurs agents spécialisés communiquent entre eux par des prompts et se répartissent le travail. L'un recueille des données, un autre analyse, un autre agit, fonctionnant comme une équipe humaine. L'exemple de support le montre proprement : un classificateur reçoit le ticket et détermine la tâche, un analyseur interroge la base de connaissances et un troisième exécute l'action de répondre ou d'escalader. Le résultat est un personnel avec IA qui gère des flux de travail complexes.

Le point n'est pas le nombre d'agents : chacun a un rôle borné par ses instructions et son outil, et la coordination passe par des messages écrits, avec tout le bon et tout le fragile que cela comporte.

Ce qui reste

Deux idées à emporter. Le modèle prédit, il ne cherche pas : quand il rédige il ne consulte pas de sources, il suit des motifs appris pendant l'entraînement. Et le prompt est la moitié de la réponse : clarté, contexte, exemple et structure font plus pour la réponse que de changer de modèle à l'aveugle. C'est pourquoi il vaut écrire le message système une fois, avec soin, et traiter chaque prompt utilisateur comme un ordre de travail et non comme une conversation de couloir.

Limite de cette source : elle explique le mécanisme à haut niveau et n'apporte pas de mesures de qualité par type de prompt, donc comparer deux rédactions reste une affaire d'essai dans son propre cas.

*Source : le module « Introduction to generative AI and agents » de Microsoft Learn.*