Pourquoi ton modèle parle mal

Lance scripts/generate.py depuis le chapitre 14 et lis la sortie. Tu obtiendras quelque chose comme :

ROMEO: Speak, my lord. The night is past, and yet the dawn is far. I have not seen the lady. JULIET: My lord, the friar hath sent for thee. ROMEO: I cannot. The hour is...

Reconnaissable. Retours à la ligne shakespeariens, noms de personnages en majuscules, vocabulaire parfois élisabéthain. Localement cohérent — à l’intérieur d’une phrase, la syntaxe tient à peu près. Globalement incohérent — les scènes ne s’enchaînent pas, les personnages disent des choses que leur pièce ne leur ferait jamais dire, les noms ne correspondent pas toujours à celui qui parle.

Lance maintenant scripts/sample_gpt2.py du chapitre 15 sur le même prompt. Paragraphes cohérents, complétions factuelles, plus un mot d’élisabéthain. Les paramètres ont changé ; l’architecture, non. L’écart de qualité vient de trois axes orthogonaux — échelle, données et alignement — dont aucun ne vit dans le code que tu as écrit.

1. Échelle

Ton modèle : ~14M paramètres, ~272k tokens d’entraînement (le corpus TinyShakespeare du chapitre 11), ~10 minutes de CPU.

GPT-3 : 175 milliards de paramètres, 300 milliards de tokens, des semaines sur des centaines de GPU.

Soit environ quatre ordres de grandeur d’écart en paramètres et six en tokens d’entraînement. L’observation empirique — codifiée en scaling laws par Kaplan et al. (2020) puis affinée par Hoffmann et al. (2022, « Chinchilla ») — est que la qualité d’un modèle s’améliore de façon prévisible et régulière avec le compute et les données, avec des rendements décroissants à chaque échelle.

La règle Chinchilla, en pratique : le nombre compute-optimal de tokens d’entraînement vaut à peu près 20 × le nombre de paramètres. En dessous, tu sous-apprends. Au-dessus, tu gaspilles du compute qui aurait mieux servi dans un modèle plus gros.

Implémente la règle et place quelques modèles connus sur la carte.

// Chinchilla rule of thumb (Hoffmann et al., 2022):
// the compute-optimal number of training tokens is roughly
// 20 × the number of model parameters.
function optimalTokens(params) {
  return params;
}
return optimalTokens;

Ton modèle 14M du chapitre 13 se situe très en dessous de la ligne Chinchilla — il est massivement sous-entraîné, ce qui explique pourquoi « plus de steps » aide autant à cette échelle. GPT-3 lui-même est, notoirement, sous-entraîné selon l’estimation de Chinchilla ; Chinchilla (DeepMind, 70B paramètres, 1,4T tokens) est justement le point de données qui a montré qu’à budget de compute égal, plus petit mais mieux entraîné bat plus gros mais sous-entraîné.

À retenir : l’essentiel de l’écart de qualité entre ton modèle et un LLM moderne, c’est de l’échelle. Fais tourner exactement la même architecture 10 000 fois plus grande et tu obtiens quelque chose de nettement plus capable. Ça ne veut pas dire que préentraîner depuis zéro soit le bon choix business ; en général, ça ne l’est pas.

2. Données

Le deuxième axe, c’est ce à partir de quoi le modèle apprend. Ton corpus d’entraînement est TinyShakespeare — environ 1,1M de caractères (~272k tokens GPT-2), un auteur, une époque, un registre. Un LLM moderne s’entraîne sur des centaines de milliards de tokens couvrant des livres, du code, des maths, de la conversation, des manuels techniques, de la presse, de la fiction, des réseaux sociaux, des pages web, des articles scientifiques, plusieurs langues, et des exemples d’instruction-following soigneusement construits.

Ce que ça change en sortie :

• Prompts hors distribution. Demande à ton modèle Shakespeare de parler de JavaScript : il n’en a aucune idée, le mot n’est jamais apparu à l’entraînement. ChatGPT répond parce que le texte pertinent était dans son corpus.
• Factualité. Ton modèle n’a jamais vu de texte factuel, donc il ne peut pas produire de faits. Il hallucine par construction, pas par accident.
• Diversité de registre. Ton modèle parle un seul registre : le théâtre anglais archaïque. Un LLM généraliste doit choisir un registre à partir du contexte et s’y tenir.

Ajouter davantage du même type de texte aide moins qu’ajouter des types différents. La composition du mélange d’entraînement est un problème de recherche à part entière.

3. Alignement

L’échelle et les données te donnent un modèle bon pour prédire le token suivant. Ce n’est pas la même chose qu’être utile. Un GPT-3 brut, à qui l’on pose une question, produira souvent une continuation plausible qui n’est pas une réponse — parce que dans les données d’entraînement, les questions sont souvent suivies d’autres questions, de citations d’articles, de silence, de digressions.

Le troisième axe, c’est le travail qui transforme un prédicteur de token en assistant :

• Le fine-tuning supervisé (SFT) sur des exemples de « bonnes » réponses écrites par des humains.
• L’apprentissage par renforcement à partir de retours humains (RLHF), ou ses variantes : on entraîne un modèle de récompense sur des préférences humaines, puis on optimise le modèle de langage contre lui.
• L’optimisation directe des préférences (DPO) et sa famille : plus récentes, moins chères que le RLHF.

Un modèle de chat moderne a consacré une part significative de son compute à cette phase d’alignement. Sans elle, le même modèle de base est bien moins agréable à utiliser.

Dans notre périmètre, on fait la première des trois étapes. Le chapitre 17 déroule le SFT sur ton modèle du chapitre 13, avec un petit dataset et le bon masque de loss. Les étapes de préférence (RLHF, DPO) demandent des données de préférence et un modèle de récompense qu’on n’entraînera pas — mais le SFT seul referme l’essentiel de l’écart de forme. La plus grande partie du sentiment « ça ne ressemble pas à un assistant » vient de l’absence de SFT, pas de l’absence de RLHF.

4. Comment savoir si tu progresses ?

La boucle d’entraînement rapporte un nombre appelé loss. Plus bas, c’est mieux. Nécessaire mais pas suffisant : c’est un scalaire unique qui ne survit pas à la comparaison entre datasets, vocabulaires ou tailles de modèle.

Perplexité — la version lisible de la loss

La perplexité vaut exp(loss). Elle a une unité sur laquelle tu peux raisonner : le nombre moyen de tokens suivants également probables que le modèle envisage encore, une fois le contexte lu. Une perplexité de 1 veut dire certitude totale ; une perplexité égale à la taille du vocabulaire veut dire uniforme (aucun apprentissage). Quelques repères sur de l’anglais courant :

• Bigramme du chapitre 1 : ~100 à 1000 selon le corpus.
• Ton modèle du chapitre 13 sur la validation Shakespeare : ~10 à 30 (selon la durée d’entraînement).
• GPT-2 small (~120M paramètres) sur Wikipedia : ~30 à 40.
• LLM de frontière sur le même Wikipedia : ~15 à 20.

Plus bas est mieux, mais la comparaison n’a de sens que sur le même dataset. Une perplexité sur Shakespeare n’est pas directement comparable à une perplexité sur Wikipedia ou sur du code.

Les suites de benchmarks

Quand un papier annonce « performance améliorée de X % », il parle en général d’un benchmark comme :

• HellaSwag — choisir la fin de phrase la plus plausible parmi 4 candidates (raisonnement de sens commun).
• MMLU — des questions à choix multiples sur 57 domaines (étendue des connaissances).
• LAMBADA — prédire le dernier mot d’un paragraphe (dépendance à longue portée).

Ils existent pour que des modèles différents soient comparables sur un même axe. Ils sont conçus pour des modèles d’au moins un milliard de paramètres. À ton échelle, les scores de benchmark sont surtout du bruit — un modèle de 14M sur MMLU restera près de la barre des 25 % du hasard, quelle que soit la qualité de son entraînement. Ne les cours pas après.

Le qualitatif est honnête

Pour les petits modèles, l’évaluation la plus utile consiste à lire ce que le modèle dit. Prends 5 à 10 prompts qui exercent le comportement qui t’intéresse. Génère avec ton modèle et avec un baseline de confiance (le modèle du chapitre 13, ou GPT-2 small via transformers.js) côte à côte. Après quelques centaines de comparaisons, tu construis une intuition qu’aucun scalaire ne remplace.

C’est cette intuition que la suite du livre exploite : le SFT change la forme, LoRA règle une spécialisation étroite, la quantification change le coût. Chaque levier déplace un axe différent de la sortie, et il faut voir ces axes avant de pouvoir choisir lequel tirer.

5. Où se trouve généralement l’argent

Soyons honnêtes : à cette échelle, ton modèle entraîné n’est pas utile comme produit généraliste. Il est excellent comme objet pédagogique. Tu as écrit chaque ligne, observé chaque courbe de loss, et tu peux expliquer chaque paramètre. C’est la base dont tu as besoin avant de décider où dépenser de l’argent.

Commercialement, la valeur vient en général d’un de ces quatre endroits :

• Un avantage sur les données. Tu as des données privées, propres, spécifiques à ton domaine, que tes concurrents n’ont pas.
• L’intégration dans un workflow. Le modèle s’installe au milieu d’un processus métier pénible et en retire du temps, des erreurs ou du coût de support.
• La spécialisation. Un petit modèle réglé pour une tâche étroite peut battre un gros modèle généraliste sur le coût, la latence, la confidentialité ou la fiabilité.
• L’efficacité de service. Quantification, cache, batching et routing rendent la même capacité moins chère à faire tourner.

Il existe aussi de vraies applications pour des modèles proches de notre échelle, à condition de les entraîner sur les bonnes données :

• L’autocomplétion embarquée pour un petit domaine précis (un éditeur de code dédié à un projet, un CMS qui complète des titres d’articles).
• La détection d’anomalies par perplexité. Entraîne sur un domaine, signale tout ce dont la perplexité dépasse nettement la ligne de base.
• Le transfert de style, si le style cible est bien défini.
• La classification avec une petite queue d’instruction — le modèle produit un token, tu vérifies s’il correspond à la classe attendue.

L’affirmation « il faut 100 milliards de paramètres pour être utile » est vraie pour le dialogue généraliste. Pour des tâches étroites, des modèles bien plus petits suffisent souvent. Les chapitres 17 et 18 sont pratiques pour cette raison : le fine-tuning change le comportement, la quantification change le coût.

Pour aller plus loin

• Hoffmann et al., « Training Compute-Optimal Large Language Models » (2022). Le papier Chinchilla.
• Kaplan et al., « Scaling Laws for Neural Language Models » (2020). L’original.
• Ouyang et al., « Training language models to follow instructions with human feedback » (2022). Le papier InstructGPT, fondation de l’alignement moderne.

Ça referme l’arc « construis ton LLM ». La partie V est du travail pratique par-dessus : donner au modèle la forme du chat, puis le rendre moins cher et utilisable.

Prochaine étape : la partie V commence avec donner des instructions à ton modèle — la manière la plus directe et la moins chère de transformer le prédicteur de token du chapitre 13 en modèle qui répond vraiment aux questions.