Qu'est-ce qu'un LLM, vraiment ?

Un LLM est une fonction : du texte en entrée, une distribution de probabilité sur le jeton suivant en sortie. La génération n'est que cette fonction en boucle — échantillonner un jeton, l'ajouter, tout renvoyer en entrée, recommencer — jusqu'à un jeton d'arrêt ou une limite de longueur. Chaque produit construit dessus, des applis de chat aux agents de code, est une orchestration enroulée autour de cette boucle.

Le fichier du modèle lui-même tient en deux choses : des milliards de poids en virgule flottante (les paramètres) et un graphe de calcul figé qui les combine (voir l'intérieur du transformer). Il n'y a là-dedans ni base de données, ni moteur de règles, ni mémoire de travail. À l'inférence, les poids sont figés ; tout ce que le modèle « se souvient » pendant une conversation n'est que du texte posé dans votre fenêtre de prompt.

La boucle principale

Pseudo-code du moteur de génération tout entier. Rien de ce qu'un vendeur livre n'est plus profond que ceci :

tokens = tokenize(prompt)
while not done and len(tokens) < max_context:
    probs = model(tokens)             # une passe avant
    next  = sample(probs, temperature)
    tokens.append(next)
    stream_to_user(next)
    if next == stop_token:
        done = True

Deux réglages de cette boucle dominent le comportement au quotidien, et aucun ne vit dans les poids : la température (l'audace de l'échantillonnage) et le contexte maximal (le volume de conversation qui tient). Ce sont tous deux des paramètres d'exécution appliqués par votre moteur (voir paramètres moteur).

Ce que sont physiquement les poids

Un modèle « 7B », ce sont 7,000,000,000 paramètres en virgule flottante. La taille de stockage ne dépend que de la précision, pas de l'intelligence :

Mêmes poids, stockage plus grossier — vous échangez un peu de qualité contre beaucoup de mémoire (voir quantification). Le compte lui-même est fixé à l'entraînement ; utiliser le modèle ne le change jamais.

L'échelle des tailles

Le nombre de paramètres est l'étalon brut mais honnête de ce qui est arrivé, et quand :

Chaque échelon vaut environ 10× le précédent, et chacun débloque des comportements que le plus petit était simplement incapable de produire — pas « pareil mais un peu mieux ». L'échelle a apporté des compétences ; l'empaquetage les a rendues utilisables.

Aucune mémoire entre les sessions

Le modèle est sans état. L'état vit dans la conversation : la fenêtre glissante des jetons que vous et lui avez produits. Fermez l'onglet et il disparaît ; ouvrez un nouveau chat et il ignore votre existence. Chaque fonction « mémoire » est un enrobage qui réinjecte de l'ancien texte dans le nouveau prompt.

Conséquence pratique : ce que vous gardez dans la fenêtre est tout ce qu'il sait à l'instant présent. Les longues conversations tronquent silencieusement leur propre début une fois la fenêtre pleine — le modèle ne « remarque » pas le texte manquant (voir jetons).

Fluide n'est pas correct

L'objectif d'entraînement est la continuation plausible, pas la vérité. Les angles vifs :

• Le modèle produit des mensonges assurés et bien formés. L'hallucination est une propriété de la prédiction du jeton suivant, pas un bug que quelqu'un a oublié de corriger.
• La fluidité est un mauvais signal de vérité : une réponse fausse se lit exactement aussi bien qu'une juste.
• L'étalonnage est bancal. Demandez « quel est ton niveau de confiance ? » et vous obtiendrez souvent un chiffre inventé.
• Les faits courants sont fiables — ils sont apparus des millions de fois à l'entraînement. Les faits de longue traîne se dégradent en douceur vers la fiction assurée.
• Les modèles penchent pour l'acquiescement : contestez une réponse correcte et il peut céder. Exactitude et assurance sont des axes différents.
• Une sortie forcée et vérifiable (JSON à champs à remplir, choix multiples) vaut mieux que de demander au modèle de s'introspecter.

Les connaissances sont figées à l'entraînement

Tout ce que le modèle sait a été incorporé lors de son entraînement ; il existe une date de coupure, et aucune quantité de discussion ne met à jour les poids. Des faits frais exigent d'injecter du texte dans le contexte (récupération) ou un nouvel entraînement (voir entraînement). Le modèle ne peut pas non plus citer d'où vient un fait — il n'a aucun index de son corpus, seulement l'écho du corpus dans ses poids.

Les capacités arrivent de façon inégale

L'échelle n'ajoute pas la compétence en douceur :

• Sous ~3B : bon autocomplètement, extraction, classification ; le raisonnement multi-étapes échoue le plus souvent.
• 7–9B : suivi d'instructions fiable, code correct ; l'arithmétique et les longues chaînes restent chancelantes.
• 30B+ : planification, nuance, code plus difficile — qui arrivent tard et un peu soudainement.
• Le MoE complique l'échelle : jugez selon les paramètres actifs, pas totaux.

Donc « plus gros c'est mieux » est vrai en moyenne et trompeur dans le détail : certaines tâches atteignent un plateau tôt, d'autres s'allument tard. Faites vos benchmarks sur votre tâche, pas au feeling (voir choisir un modèle).

Le produit est la boucle, emballée

Quand vous utilisez un produit à base de LLM, voici à peu près ce qui se passe :

1. Votre texte est tokenisé.
2. Le prompt système, les définitions d'outils, les documents récupérés et l'historique de conversation sont concaténés en un seul prompt.
3. Le modèle exécute la boucle ci-dessus et diffuse des jetons en flux.
4. Le code d'enrobage analyse la sortie, appelle des outils, réinjecte les résultats et relance.
5. L'interface affiche du markdown et appelle ça une conversation.

Les étapes 1, 2, 4 et 5 ne sont pas le modèle. Une fois que vous avez intégré que le modèle est une fonction sans état texte-entrée/texte-sortie à fenêtre fixe, le reste de ce guide est de la comptabilité : la taille de la fenêtre (jetons), la vitesse de la boucle (préremplissage vs décodage), l'endroit où elle tourne (panorama du matériel) et comment la piloter (prompting).

Voir aussi : jetons · l'intérieur du transformer · paramètres · entraînement