Comment fonctionnent vraiment les grands modèles de langage

Ce qu’est un LLM (et ce qu’il n’est pas)

Un grand modèle de langage est un réseau de neurones entraîné sur d’immenses quantités de texte pour modéliser la probabilité du prochain token étant donné les tokens précédents. « Large » renvoie à des milliards de paramètres ajustables (poids) et à des corpus d’entraînement qui peuvent couvrir une grande partie du web public, des livres et des collections sous licence. Le modèle ne stocke pas des phrases dans une table de recherche ; il compresse des régularités du langage — et de nombreuses associations factuelles qui apparaissent dans ces régularités — dans ces poids.

Appeler cela « comprendre » est une métaphore. Littéralement, le système calcule une distribution sur les prochains tokens possibles et en choisit un (ou échantillonne dans la distribution). Des comportements qui ressemblent à du raisonnement, de l’empathie ou de la planification émergent quand ces comportements étaient des motifs utiles à imiter dans les données d’entraînement. C’est puissant pour la rédaction et l’explication ; ce n’est pas une garantie de vérité ni de logique cohérente.

Les données d’entraînement façonnent le comportement

Avant les détails d’architecture, considérez le régime alimentaire. Le pré-entraînement expose le modèle à du texte divers : prose encyclopédique, forums, dépôts de code, actualités, fiction, et plus. Le modèle ne « lit » jamais avec intention ; il voit des séquences de tokens et apprend à prédire les continuations. Tout ce qui apparaît souvent — API courantes, dates célèbres, idiomes de code récurrents — devient statistiquement facile à reproduire. Des faits rares, privés ou récents peuvent ne jamais apparaître assez fortement dans les poids pour être récupérés de façon fiable sans outils externes.

Tokenisation : du texte aux ID de tokens

Les réseaux de neurones opèrent sur des nombres, pas sur des chaînes Unicode. Un tokenizer découpe le texte brut en tokens — morceaux qui peuvent être des mots entiers, des sous-mots ou de la ponctuation — et mappe chaque morceau à un ID entier d’un vocabulaire fixe (souvent des dizaines de milliers d’entrées). Des mots anglais courants comme « the » peuvent être un seul token ; mots rares ou fautes se découpent en fragments plus petits pour que le modèle puisse encore les traiter sans vocabulaire infini.

Tokens versus mots

Les interfaces produit affichent souvent des limites en « mots » ou caractères, tandis que le modèle facture et tronque par tokens. Un prompt court en anglais peut faire ~1,3 token par mot en moyenne, mais code, URL et scripts non latins peuvent utiliser plus de tokens par caractère visible. Ce décalage explique pourquoi un « essai de 2000 mots » tient dans un produit mais déborde un autre, et pourquoi un blob JSON consomme vite le contexte même s’il paraît petit à l’écran.

Quand vous avez besoin de comptes exacts pour brouillons ou limites, utilisez le compteur de mots et le compteur de caractères SmartKitio sur la chaîne réelle. Le décompte interne de tokens du modèle fait foi pour le modèle — mais reste opaque dans la plupart des interfaces de chat.

Embeddings : les tokens en vecteurs

Chaque ID de token est converti en vecteur de haute dimension (un embedding). Tôt dans le réseau, des tokens proches se situent dans des directions similaires : pluriels près des singuliers, mots-clés de programmation les uns près des autres, etc. Ces vecteurs sont appris pendant l’entraînement, pas écrits à la main. Ils permettent au modèle de généraliser : si « json » et « JSON » partagent des contextes statistiques, leurs représentations peuvent s’aligner même quand le tokenizer les traite différemment.

Le transformer et l’auto-attention

Les LLM modernes sont dominés par l’architecture transformer introduite par Vaswani et al. (2017). Des couches empilées appliquent l’auto-attention : la représentation de chaque token est mise à jour par des combinaisons pondérées de tous les autres tokens du contexte actuel. Les poids d’attention sont calculés à partir de projections apprises — grossièrement, « combien le token B doit-il influencer le token A pour cette tâche de prédiction ? » — plutôt qu’à partir de règles de grammaire fixes.

Pourquoi l’attention compte

Les anciens modèles de séquence peinaient avec les dépendances longue distance parce que l’information devait passer par de nombreuses étapes séquentielles. L’attention laisse des tokens distants interagir directement dans une couche, ce qui aide pour la coréférence (« Alice … she »), les longs blocs de code et les instructions multi-étapes dans un seul prompt. La profondeur (nombreuses couches) et la largeur (grandes tailles cachées) permettent au modèle de construire des features hiérarchiques : syntaxe locale dans les premières couches, structure discursive et thématique plus large dans les dernières.

Fenêtre de contexte : le passé visible

À l’inférence, le modèle ne peut s’attendre qu’aux tokens actuellement chargés dans la fenêtre de contexte — une longueur maximale fixe qui varie selon le produit (milliers à millions de tokens dans des systèmes spécialisés). Tout ce qui est hors fenêtre est invisible sauf si vous le résumez ailleurs ou utilisez la retrieval pour injecter des extraits. Les longues conversations ont donc besoin de compression, fenêtres glissantes ou mémoire externe ; sinon le modèle oublie littéralement les instructions du début.

La prédiction du prochain token comme objectif central

Pendant le pré-entraînement, le modèle voit une séquence et apprend à prédire chaque prochain token. Les mauvaises suppositions produisent un signal de loss ; l’optimisation ajuste les poids pour réduire cette loss sur des milliards d’exemples. Grammaire, style, bribes factuelles et motifs de code sont tous des effets secondaires de bien faire ce travail sur du texte divers. Il n’y a pas de module séparé étiqueté « faits » ou « éthique » sauf si des étapes d’entraînement ultérieures ajoutent explicitement des objectifs (par exemple preference tuning sur des sorties notées par des humains).

Inférence, température et décodage

L’entraînement enseigne des probabilités ; l’inférence les utilise pour produire du texte. Le décodage glouton choisit toujours le prochain token de plus haute probabilité — déterministe mais parfois répétitif. L’échantillonnage pioche dans la distribution, ce qui ajoute de la variété. La température met à l’échelle les logits avant softmax : température basse accentue la distribution (continuations plus sûres, plus plates) ; température haute l’aplatit (plus créatif, plus erratique). L’échantillonnage top-p (nucleus) tronque la queue des tokens peu probables pour réduire le nonsense sans figer entièrement la sortie.

La taille de la fenêtre de contexte limite combien de tokens précédents entrent dans l’attention à chaque pas. Un long prompt système plus des docs récupérés plus l’historique de chat se disputent le même budget ; quand la fenêtre est pleine, les tokens les plus anciens sortent du champ sauf si le produit les résume. Le décodage est autorégressif : chaque token généré est ajouté et réinjecté, donc un mauvais token tôt peut orienter la suite — non parce que le modèle « change d’avis », mais parce que les pas suivants conditionnent sur l’erreur.

Entraînement versus inférence

Pourquoi les modèles peuvent paraître intelligents

Le langage humain encode déjà des étapes de raisonnement, des réserves et du dialogue. Un modèle entraîné à prédire ce texte émettra parfois des explications pas à pas parce que ces motifs réduisaient l’erreur de prédiction sur les documents d’entraînement. L’échelle augmente la fidélité de ces motifs : plus de paramètres peuvent stocker des associations plus nuancées. Cela peut ressembler à un tuteur ou un pair programmeur. Cela reste de la complétion de motifs sauf si couplé à des outils qui ancrent les sorties dans des vérifications — compilateurs, calculatrices, retrieval ou bases de données.

Hallucinations et limites (aperçu)

Quand le modèle manque de preuves, la même machinerie produit encore des tokens fluides — d’où les hallucinations. Il hérite aussi de biais et angles morts des données d’entraînement, peut mal gérer les contrefactuels et confabuler bibliothèques ou URL plausibles. Limites de contexte, quirks de tokenisation et aléa d’échantillonnage ajoutent d’autres modes d’échec. Ce sont des conséquences architecturales, pas des bugs occasionnels ; les atténuations vivent dans la conception de processus (retrieval, vérification, revue humaine), pas en souhaitant que le modèle soit une base de données.

Un exemple simplifié pas à pas

Travailler avec du texte structuré

Les LLM peuvent proposer des formes JSON et reformater des payloads désordonnés, mais ils peuvent omettre des virgules, dupliquer des clés ou inventer des champs. Pour une sortie machine-readable, traitez le modèle comme assistant de brouillon et passez le résultat par un formateur ou validateur. Le formateur JSON SmartKitio aide à inspecter la structure localement ; il ne remplace pas la validation de schéma contre votre vrai contrat API.

Fine-tuning et alignement (brièvement)

Après le pré-entraînement, beaucoup de produits appliquent d’autres étapes : fine-tuning supervisé sur dialogues curatés, optimisation de préférences à partir de notes humaines, ou entraînement à l’usage d’outils qui apprend au modèle à appeler recherche ou interpréteurs de code. Ces étapes changent le ton, les refus de sécurité et la volonté de citer l’incertitude — elles ne remplacent pas le mécanisme central de prédiction du prochain token. Les assistants augmentés d’outils paraissent plus fiables parce que des programmes externes récupèrent des faits ou exécutent des calculs, pas parce que le transformer de base a acquis une conscience.