Une phrase, un texte, ou un livre ?
ça tourne dans ton navigateur. Aucun appel au serveur : le tirage est calculé ici.
La découpe en jetons est une chose. Ce qu'on donne à lire au modèle en est une autre, complètement séparée — et la réponse n'est ni la phrase, ni le texte, ni le livre.
La réponse courte
On lui donne CTX jetons. C'est tout. CTX est un nombre que tu choisis en construisant le modèle, et les frontières du monde réel — fin de phrase, fin d'article, fin de livre — n'existent que si tu les fabriques toi-même.
1. Le pré-entraînement : le fleuve
Tous les documents sont collés bout à bout en un seul long ruban, puis on y découpe des fenêtres au hasard, n'importe où. Une fenêtre peut commencer au milieu d'un mot et enjamber deux articles. Ça n'a aucune importance : la tâche — « prédis le jeton suivant » — est valable à n'importe quel endroit du ruban.
…
…
tirage local · le mécanisme est celui du run-034, qui tire 48 fenêtres à chaque pas
| à ce CTX | fenêtres |
|---|---|
| un livre de 400 000 caractères | — |
| les 60 M de caractères du run-034 | — |
| ce que le run-034 a réellement lu (8 000 pas × 48) | — |
Un détail assumé du run-034 : les articles y sont séparés par une ligne vide, pas par un jeton de fin de document. Rien n'empêche donc le modèle d'apprendre à enchaîner un article sur le suivant. Les vrais pré-entraînements insèrent un EOS entre les documents.
2. Pourquoi une fenêtre, et pas tout le ruban ?
Parce que ça ne rentre pas. Chaque jeton regarde tous les autres : une séquence de n jetons fabrique une grille de n² cases, par tête et par couche. Avec la configuration exacte du run-034 — 8 couches, 6 têtes, lots de 48 :
| CTX | cases d'attention | mémoire (fp16) |
|---|---|---|
| 256 — le run-034 | 151 M | 0,30 Go |
| 1 024 | 2,4 G | 4,83 Go |
| 4 096 | 38,7 G | 77 Go |
| 16 384 | 618 G | 1 237 Go |
…
arithmétique sur la configuration du run-034 — le P100 de Kaggle a 16 Go
Le fleuve entier d'un seul coup, ce serait 8,3 × 10¹⁸ cases. Ce n'est pas cher : c'est impossible.
Ce n'est pas une limite lue quelque part — elle a déjà été payée en minutes de GPU. Au run-004c, un essai est mort en cours de route : lot de 512 → grilles d'attention au-delà de 16 Go de VRAM.
run-004c, essai abandonné · EXPERIENCES.md
La table de positions est un mur, pas un ralentissement
Un modèle qui apprend ses positions en garde une table d'exactement CTX lignes. Au-delà, il n'y a pas de vecteur : ce n'est pas lent, ça n'existe pas. Et forcer ne suffit pas — le run-004e a agrandi une fenêtre de 250 à 500 : la loss s'est améliorée et la génération est devenue du gribouillis, parce que les 250 positions neuves n'avaient presque jamais été entraînées.
Et il faut un lot, donc un rectangle
L'entraînement avance par paquets — 48 séquences à la fois, sinon le gradient est trop bruité et la carte tourne à vide. Un lot est un tableau rectangulaire : toutes les lignes de la même longueur. Un seul texte géant, c'est un lot de un.
Un effet secondaire qu'on n'a pas cherché : couper au hasard plutôt qu'en tranches fixes donne bien plus d'exemples différents du même corpus. Presque aucune des fenêtres du run-034 n'est identique à une autre — de l'augmentation de données gratuite.
La fenêtre est une limite de la machine, pas de la tâche. « Prédis le jeton suivant » fonctionnerait très bien sur 60 millions de caractères d'affilée. C'est le n² et la table de positions qui imposent la lucarne — et c'est pour ça qu'allonger le contexte est un domaine de recherche à part entière. Les quatre verrous, en détail : jusqu'où le modèle peut lire.
3. Le fine-tuning : l'exemple
Ici, tout s'inverse. Une séquence = un exemple, jamais deux collés, et les frontières deviennent l'essentiel de ce qu'on enseigne.
| la pièce | à quoi elle sert |
|---|---|
| le gabarit | marquer où finit la question et où commence la réponse |
| l'EOS | la touche qui apprend au modèle à s'arrêter |
| le masque à −100 | ne noter que la réponse : il apprend à répondre, pas à écrire des questions |
| le remplissage | rendre le lot rectangulaire, et l'exclure de la note |
Ce qui arrive sans EOS
Le modèle de base du run-015 ne l'a jamais appris. Résultat mesuré : à qui lui pose une question, il répond… puis enchaîne une deuxième question qu'il invente lui-même, puis une troisième, sans jamais s'arrêter. Il n'a pas de notion de fin parce qu'on ne lui en a jamais montré une. Voir le chapitre LLM.
4. Les trois régimes, côte à côte
| régime | ce qu'on donne | les frontières | exemple ici |
|---|---|---|---|
| pré-entraînement | un ruban unique, coupé au hasard | ignorées | run-034, 60 M de caractères |
| fine-tuning | une séquence par exemple, remplie | sacrées | run-015, gabarit + EOS |
| séquences d'objets | un objet par séquence | sacrées | run-004b, un dessin = BOS … END |
5. Et à l'inférence ?
Là, une vraie frontière existe enfin : ta requête. Et un livre n'y rentre pas. Trois sorties, dont ce projet en a mesuré deux :
| stratégie | score | où |
|---|---|---|
| tronquer — on jette le début | 41 | run-051, le plancher |
| le modèle prend des notes | 49 | run-051 |
| le harnais prend les notes (30 lignes de regex) | 132 | run-051 |
| tout donner d'un coup | 213 | run-051, l'oracle inatteignable |
| découper et retrouver le bon morceau | — | pas encore fait ici |
Sur 240 questions. Détail dans EXPERIENCES.md, run-051.
La règle, en une phrase
Le tokenizer ne connaît qu'un flux. Les frontières — phrase, document, livre — n'existent que si tu les fabriques, avec un jeton séparateur et un masque. Le pré-entraînement s'en passe volontairement ; le fine-tuning en dépend entièrement.