Du texte brut à la réponse écrite : les quatre mécanismes qui font tourner un modèle de langage. Aucun prérequis.
Un modèle de langage est un programme qui a appris, sur d'énormes quantités de texte, à répondre à une seule question : quel est le morceau de texte le plus probable après ceux-là ? Tout le reste en découle. Il ne consulte aucune base de données et ne cherche nulle part : il calcule une probabilité.
En quatre mécanismes, qui sont les quatre chapitres suivants. Le texte est d'abord découpé en morceaux numérotés, c'est le tokenizer. Chaque numéro devient ensuite une position dans un espace où le sens se calcule, c'est l'embedding. Ces positions sont corrigées les unes par les autres selon la phrase, c'est l'attention. Enfin le modèle produit sa réponse un morceau à la fois, c'est la génération.
Le trajet complet
Les paramètres d'un modèle, aussi appelés ses poids, sont les nombres ajustés pendant l'entraînement. Ils se comptent en milliards. Ce sont eux qui portent tout ce que le modèle a retenu, et ils ne bougent plus ensuite, sauf à réentraîner le modèle.
Sept mots suffisent pour lire tout le reste. Reviens-y si un terme te bloque.
| token | Un morceau de mot. La plus petite unité que le modèle manipule. « Bonjour » peut valoir 1 token, « Schtroumpfologie » 4. |
| poids | Les nombres appris pendant l'entraînement, aussi appelés paramètres. Un modèle « 8B » en contient 8 milliards. Ils ne bougent plus une fois l'entraînement terminé. |
| attention | Le mécanisme qui laisse chaque token regarder les autres et corriger son vecteur en conséquence. C'est le cœur de l'architecture Transformer, celle de tous les LLM actuels. |
| vecteur | Une liste de nombres, par exemple [0.2, −0.7, 0.1, …]. C'est ce que la machine calcule réellement. |
| embedding | Le vecteur qui représente un texte. Sa particularité : deux textes de sens proche ont des vecteurs proches. |
| fenêtre de contexte | La quantité maximale de texte qu'un modèle peut lire d'un coup, comptée en tokens. |
| LLM | Large Language Model, le modèle qui rédige la réponse finale (GPT, Claude, Mistral…). |
Un ordinateur ne manipule que des nombres. Avant toute chose, il faut donc convertir « chat » en quelque chose de calculable. C'est le rôle du tokenizer, la porte d'entrée de tout modèle de langage.
Trois découpages sont envisageables, et on comprend le bon en écartant les deux autres :
Le trajet du texte, jusqu'au sens
Chaque morceau reçoit un numéro (son ID), lu dans un dictionnaire figé. Et c'est ici qu'il faut être très clair sur une chose :
Ces numéros ne veulent rien dire. Ce sont des étiquettes arbitraires, comme des codes-barres : les IDs 331 et 332 n'ont aucun rapport entre eux. Le tokenizer ne comprend rien. Il compte, il découpe, il numérote.
Le numéro sert seulement d'adresse : il indique quelle ligne aller lire dans la grande table où sont rangés les vecteurs, la table d'embedding. Le dictionnaire (texte → numéro) est fabriqué une fois puis figé ; la table (numéro → vecteur) est apprise pendant l'entraînement et fait partie du modèle.
D'un algorithme statistique nommé BPE (Byte Pair Encoding), qui n'a rien d'intelligent. On part des caractères, puis on répète des milliers de fois la même opération : fusionner la paire de symboles la plus fréquente du corpus. « e » suivi de « s » revient partout → on crée « es ». Puis « es » + « t » → « est ». Au bout de ~100 000 fusions, on verrouille le résultat : c'est le vocabulaire.
BPE : fusionner ce qui revient souvent
Deux conséquences importantes découlent de ce mécanisme.
Première conséquence : rien ne peut planter. Sous les fusions BPE, on garde toujours les 256 octets de base. Un émoji inconnu, un caractère exotique, un fichier corrompu ? Le tokenizer redescend à l'octet brut, un token par octet. Il fragmente, mais il ne s'arrête jamais. C'est ce qu'on appelle le byte-level BPE.
Seconde conséquence : le vocabulaire est optimisé pour l'anglais, car c'est de l'anglais qu'il a majoritairement été extrait. Les autres langues sont donc découpées plus finement, donc plus de tokens pour dire la même chose :
Tokens nécessaires pour 100 mots
① Tout se compte en tokens, jamais en caractères ni en mots, puisque les limites des modèles sont exprimées ainsi.
② Un tokenizer est marié à son modèle : ses numéros ne pointent vers les bons vecteurs que pour ce modèle-là.
→ Le détail complet (fusions par rang, KV cache, coût en O(N²), tiktoken) est dans la Fiche 01, onglet « Fiches ».
À ce stade, on n'a que des numéros arbitraires. Le sens arrive à l'étape suivante, avec l'idée qui fait marcher tout le reste.
La réponse : on en fait une position dans l'espace. Chaque mot, chaque passage, devient un point. Et on s'arrange pour que les points de sens voisins soient physiquement proches.
L'espace du sens (vue simplifiée en 2D)
C'est ça, un embedding : une position. Et c'est ce qui permet au modèle de traiter pareillement deux formulations différentes. Si « le capteur sature » et « le capteur déborde » atterrissent au même endroit, il les comprend de la même façon, sans qu'elles partagent un seul mot.
Ils sont appris, sur un principe simple : un mot se définit par son entourage. Le modèle lit des milliards de phrases, et deux mots qu'on croise dans les mêmes tournures (« nourrir le ___ », « le ___ dort ») sont poussés vers des positions voisines. Personne n'a déclaré que le chat et le chien se ressemblent : ça se déduit de l'usage.
Chaque modèle apprend son propre espace. Les coordonnées d'un modèle n'ont aucun sens pour un autre. On ne mélange jamais des vecteurs produits par deux modèles différents. Deux modèles ne parlent pas la même langue géométrique, et rien ne signale l'erreur.
« Avocat » désigne un fruit et un métier. Si chaque mot n'a qu'une seule position figée, où le met-on ? Réponse : au milieu, donc dans aucune des deux zones, ce qui n'aide personne.
Un seul point pour deux sens : le compromis
La solution s'appelle l'attention : avant de figer la position d'un mot, le modèle le laisse regarder ses voisins dans la phrase et déplace sa position en conséquence. « Manger un avocat » l'envoie du côté des fruits, « appeler mon avocat » du côté du droit.
C'est le mécanisme central des Transformers, et il mérite mieux qu'une phrase. C'est tout le chapitre suivant.
→ L'arithmétique des directions (roi − homme + femme ≈ reine) et le détail des vecteurs statiques sont dans la Fiche 02, onglet « Fiches ».
Le chapitre précédent s'est arrêté sur un problème : « avocat » n'a qu'une position, coincée entre les fruits et la justice. L'attention est le mécanisme qui la déplace. C'est la pièce centrale des Transformers, et le seul endroit de tout le modèle où les tokens se parlent.
Pour ne rien dire de vague, ce chapitre et le suivant suivent un modèle réel dont les chiffres sont publics : Llama 3 8B. Tous les nombres cités sont les siens.
Après le tokenizer et la table d'embedding, ton texte n'existe plus en tant que texte. C'est un tableau : une ligne par token, et sur chaque ligne 4 096 nombres.
« le chat noir dort » à l'entrée du modèle
Une information de position vient s'ajouter. Sans elle, « le chat mange » et « mange le chat » seraient strictement identiques pour le modèle : rien, dans un tableau de nombres, ne dit dans quel ordre lire les lignes.
Deux méthodes existent. Les modèles anciens (GPT-2, BERT) ajoutent au vecteur d'entrée un second vecteur qui code « je suis en position 1, 2, 3… ».
Les modèles récents, dont Llama, utilisent RoPE : au lieu d'ajouter quelque chose, ils font tourner les vecteurs Q et K d'un angle proportionnel à la position. Conséquence utile : le score entre deux tokens ne dépend plus que de leur écart de position, pas de leur position absolue. C'est ce qui permet d'étendre la fenêtre de contexte d'un modèle après son entraînement.
Chaque token pose une question aux autres, chacun répond avec une étiquette, et celui qui pose la question récupère surtout le contenu de ceux dont l'étiquette correspond. Trois rôles, donc trois vecteurs, tirés du même vecteur de départ.
Trois vecteurs tirés du même vecteur d'entrée
Une matrice, c'est une grille de nombres. La multiplication produit un nouveau vecteur où chaque nombre de sortie est une somme pondérée de tous les nombres d'entrée. Rien de plus.
Avec un vecteur de 3 nombres et une matrice 3 × 2 :
| Entrée | Poids vers la sortie A | Poids vers la sortie B |
|---|---|---|
| 2 | 0,5 | −1,0 |
| 5 | 0,2 | 0,3 |
| 1 | 1,0 | 0,4 |
| Sortie | 2×0,5 + 5×0,2 + 1×1,0 = 3,0 | 2×(−1,0) + 5×0,3 + 1×0,4 = −0,1 |
Dans le modèle, c'est identique avec 4 096 entrées et 4 096 sorties. Il faut donc 4 096 × 4 096 = 16,8 millions de poids, ce qui est exactement la taille de WQ dans le tableau du chapitre suivant.
On multiplie terme à terme, on additionne, et il sort un seul nombre.
Q = [2, 5, 1] et K = [1, 0, 3] donnent 2×1 + 5×0 + 1×3 = 5.
Ce nombre mesure l'alignement des deux vecteurs :
Les scores sont ensuite divisés par la racine carrée de la taille du vecteur, ici √128 ≈ 11,3. Sans cette division, additionner 128 produits donne des valeurs énormes, le softmax se bloque sur un seul candidat et l'entraînement ne démarre pas.
Un softmax transforme n'importe quelle liste de nombres en probabilités. Deux opérations : on applique l'exponentielle à chaque score, puis on divise chacun par la somme totale.
L'exponentielle rend tout positif et écrase les petits écarts vers le bas tout en amplifiant les grands vers le haut. La division garantit un total de 1.
| Score brut | Exponentielle | Divisé par le total |
|---|---|---|
| 3,0 | 20,1 | 20,1 / 48,4 = 41 % |
| 2,4 | 11,0 | 11,0 / 48,4 = 23 % |
| 1,9 | 6,7 | 6,7 / 48,4 = 14 % |
| 1,2 | 3,3 | 3,3 / 48,4 = 7 % |
| tous les autres | 7,3 | 7,3 / 48,4 = 15 % |
| Total | 48,4 | 100 % |
Le même calcul sert deux fois dans le modèle : ici pour répartir l'attention sur les tokens passés, et à la toute fin pour répartir la probabilité sur les 128 256 tokens du vocabulaire.
Qui regarde qui, et combien
La zone grise n'est pas un détail. Un token ne voit jamais ce qui le suit, ce qui force le modèle à écrire de gauche à droite sans tricher, et rend possible le cache décrit au chapitre suivant.
Les étapes 2 et 4 sont le seul moment de tout le modèle où les tokens communiquent. Et elles n'utilisent aucun poids : ce ne sont que des produits entre vecteurs. Les poids sont dans les trois projections de l'étape 1, et dans le mélange final.
Un seul jeu de Q, K, V ne saurait suivre qu'une seule relation à la fois. Alors on découpe : les vecteurs Q, K et V sont coupés en 32 tranches de 128 nombres, et les quatre étapes se déroulent séparément sur chaque tranche.
Le vecteur Q, découpé en 32 têtes
Chaque tête se spécialise pendant l'entraînement : une suit le sujet du verbe, une autre l'accord en genre, une autre le guillemet à refermer. Les 32 résultats sont remis bout à bout, ce qui reconstitue 4 096 nombres, puis mélangés une dernière fois par WO. C'est cette quatrième matrice qui décide comment combiner ce que les 32 têtes ont ramené.
Dans le tableau du chapitre suivant, WQ fait 4 096 × 4 096 alors que WK et WV font 4 096 × 1 024. Ce n'est pas une coquille.
Llama 3 utilise la grouped-query attention : les 32 têtes de requête se partagent seulement 8 jeux de K et V, par groupes de 4 têtes. La qualité bouge très peu, et la mémoire du cache est divisée par 4.
Reprenons « manger un avocat ». Le token « avocat » émet un Q qui, entraînement aidant, s'aligne bien avec le K de « manger ». Ce voisin récolte donc un poids d'attention élevé, et son V pèse lourd dans le mélange. Résultat : le vecteur d'« avocat » se décale vers la zone des fruits. Avec « appeler mon avocat », c'est le K de « appeler » qui gagne, et le vecteur part vers la justice.
Le même mot, deux positions de sortie
Le vecteur qui entre dans l'attention est l'embedding statique, lu dans la table. Celui qui en sort est l'embedding contextuel. Et comme le modèle empile 32 couches, l'attention recommence 32 fois : dès la deuxième, elle travaille déjà sur des vecteurs contextuels.
→ La distinction statique / contextuel, et les deux moments où le contexte agit, sont reprises dans la Fiche 02, onglet « Fiches ».
L'attention est comprise. Reste à voir où elle se range dans la machine complète, et comment on passe d'un tableau de nombres à un mot écrit.
Le modèle produit un token à la fois. Pour chaque token produit, la totalité de ses poids est utilisée, et tout le texte déjà présent est retraversé.
Les poids ne sont pas un tas informe. Ce sont des matrices, rangées dans 32 couches empilées. Chaque couche contient exactement sept matrices : les quatre de l'attention, que tu viens de rencontrer, et trois autres. Le compte est vérifiable :
Anatomie complète de Llama 3 8B
| Bloc | Matrice | Taille | Poids |
|---|---|---|---|
| Attention | WQ | 4 096 × 4 096 | 16,8 M |
| WK | 4 096 × 1 024 | 4,2 M | |
| WV | 4 096 × 1 024 | 4,2 M | |
| WO | 4 096 × 4 096 | 16,8 M | |
| MLP | gate | 4 096 × 14 336 | 58,7 M |
| up | 4 096 × 14 336 | 58,7 M | |
| down | 14 336 × 4 096 | 58,7 M | |
| Une couche | 218 M | ||
| × 32 couches | 6,98 G | ||
| Table d'embedding + couche de sortie | 1,05 G | ||
| Total | 8,03 G | ||
① Les 32 couches ont la même structure, mais aucune ne contient les mêmes valeurs. Le modèle refait 32 fois la même opération avec 32 jeux de poids différents.
② 4 poids sur 5 sont dans le MLP, pas dans l'attention. L'attention est le mécanisme célèbre, mais ce n'est pas là qu'est stocké l'essentiel.
Toujours les deux mêmes, dans cet ordre.
Le contenu d'une couche
Le second geste s'appelle le MLP, pour multi-layer perceptron. Une fois l'attention passée, chaque ligne du tableau repart de son côté : son vecteur de 4 096 nombres est étiré à 14 336, passé dans une fonction non linéaire, puis ramené à 4 096. Aucun échange entre tokens ici : la même opération est appliquée à chaque ligne, séparément.
C'est là que sont 4 poids sur 5. L'image la plus juste : l'attention rassemble l'information utile, le MLP la traite. Les travaux de rétro-ingénierie des modèles y situent l'essentiel des associations factuelles apprises.
Sans elle, empiler 32 couches ne servirait strictement à rien. Une suite de multiplications par des matrices se réduit toujours à une seule matrice équivalente : 32 couches linéaires auraient exactement le même pouvoir qu'une seule.
La fonction non linéaire casse cette réduction. C'est elle qui rend la profondeur utile. Chez Llama, c'est une variante appelée SwiGLU, et c'est la raison pour laquelle le MLP compte trois matrices au lieu de deux : gate et up montent en parallèle, la première servant de valve sur la seconde.
Avant chacun des deux gestes, le vecteur passe par une normalisation qui ramène ses nombres à une échelle stable (RMSNorm chez Llama). Sans elle, les valeurs enflent ou s'effondrent au fil des 32 couches et l'entraînement échoue.
Ça ne change rien au raisonnement ci-dessus, mais si tu ouvres un schéma de Transformer, tu verras ces petits blocs « Norm » partout, et tu sauras à quoi ils servent.
Chacun des deux gestes ne renvoie pas un vecteur neuf : son résultat est ajouté au vecteur qui entrait. Le vecteur d'un token traverse donc les 32 couches en se faisant enrichir 64 fois, sans jamais perdre ce qu'il portait au départ.
Ce raccourci porte un nom, la connexion résiduelle. Sans lui, une pile de 32 couches serait presque impossible à entraîner : le signal se dégrade en descendant et les premières couches n'apprennent plus rien.
La traversée de la pile
En sortie de la 32ᵉ couche, on ne garde qu'une seule ligne du tableau : celle du dernier token. Les autres ont servi à la nourrir, elles ne servent plus à cet instant.
Ce vecteur de 4 096 nombres est multiplié par une dernière matrice de 4 096 × 128 256. Il en sort 128 256 scores, un par entrée du vocabulaire. Leur nom technique est logits, et tu le croiseras partout dans la documentation. Chaque score est le produit scalaire entre le vecteur final et le vecteur de sortie de ce token : plus c'est aligné, plus c'est probable.
Ces scores bruts ne sont pas des probabilités : ils peuvent être négatifs, et leur somme n'a aucune raison de valoir quoi que ce soit. Le softmax les convertit en probabilités positives dont la somme fait exactement 1. C'est la même opération qu'au chapitre précédent, appliquée cette fois au vocabulaire entier.
« Le chat dort sur le ___ »
Prendre systématiquement le plus probable donne un texte correct mais plat, et parfois des répétitions en boucle. On introduit donc du hasard contrôlé, réglé par la température.
Son mécanisme tient en une ligne : les scores bruts sont divisés par la température avant le softmax. Diviser par 0,5 double les écarts, donc concentre la probabilité sur les favoris. Diviser par 1,5 les réduit, donc aplatit la distribution et laisse passer des choix rares.
Mêmes scores bruts, trois températures
T = 0,5 · prévisible
T = 1,0 · brut du modèle
T = 1,5 · imprévisible
Un second réglage, le top-p, agit autrement : il trie les candidats par probabilité décroissante et ne garde que les premiers jusqu'à atteindre p, par exemple 0,9. Tout le reste est écarté avant le tirage, ce qui empêche un candidat absurde de sortir par malchance.
La boucle, token après token
Chaque poids du modèle est utilisé au moins une fois, soit environ 16 milliards d'opérations (une multiplication et une addition par poids). À 50 tokens par seconde, la machine tient 800 milliards d'opérations par seconde rien que pour ta réponse. C'est pour ça que ça tourne sur GPU.
Ce qui précède décrit un modèle dense : chaque poids sert à chaque token. C'est le cas de Llama 3 8B.
D'autres modèles utilisent un mélange d'experts : le MLP est découpé en blocs, et un aiguilleur n'en active que quelques-uns par token. DeepSeek-V3 annonce ainsi 671 milliards de paramètres, mais n'en fait travailler que 37 milliards pour chaque token produit. Un gros modèle en mémoire, un petit modèle en calcul.
« Il relit tout à chaque tour » est vrai mathématiquement, mais faux dans la machine. Les K et les V des tokens déjà traités ne changent jamais : ils ne dépendent que du token et de sa position, jamais de ce qui viendra après. Autant les garder en mémoire.
Le premier passage traverse donc les 32 couches avec tout le prompt d'un coup. Ensuite, à chaque tour, un seul token traverse la pile : il calcule son Q, et va lire dans le cache les K et V de tous les autres.
De la mémoire, et elle grandit à chaque token. Sur Llama 3 8B : 32 couches × 8 têtes × 128 nombres × 2 (K et V) = 65 536 nombres par token, soit 128 Ko. Une fenêtre de 8 192 tokens remplie, c'est 1 Go de mémoire GPU, en plus des 16 Go du modèle lui-même (8 milliards de poids × 2 octets chacun). C'est souvent le cache, et non le modèle, qui limite le nombre d'utilisateurs servis en parallèle.
Tout ce que le modèle a sous les yeux à un instant donné, ta question, tout ce que tu colles avec, et sa réponse en cours, doit tenir dans sa fenêtre de contexte, comptée en tokens. Au-delà, il faut couper.
Deux coûts grandissent avec la longueur, mais pas au même rythme. Les projections et le MLP coûtent proportionnellement au nombre de tokens. L'attention, elle, compare chaque token à tous les précédents : son coût croît avec le carré de la longueur. Sur un prompt court, c'est le premier qui domine ; sur un prompt très long, c'est le second qui finit par tout écraser.
Rien dans ce mécanisme ne vérifie quoi que ce soit. Le modèle optimise la plausibilité du token suivant au regard de ce qu'il a lu pendant l'entraînement, pas la vérité. Face à une question dont la réponse n'est pas dans ses poids, la suite la plus plausible reste une phrase bien tournée, alors il la produit. C'est ce qu'on appelle une hallucination : une conséquence du fonctionnement, pas une panne ponctuelle.
On la réduit de deux façons : par l'entraînement, en apprenant au modèle à reconnaître qu'il ne sait pas, et surtout en lui fournissant la matière directement dans son prompt.
→ Cette seconde méthode a un nom et un cours dédié : le RAG, donner ses propres documents au modèle.
Texte → suite d'entiers. Rien d'autre. Le sens vient après.
Le trajet complet, du texte au sens
Le tokenizer ne touche jamais au sens. Un ID est une étiquette arbitraire, comme un code-barres : 331 et 332 n'ont aucun lien. Le sens est appris bien plus loin, dans la table d'embedding.
Le modèle ne lit jamais de texte. Il lit des vecteurs. L'ID sert juste à aller chercher le bon vecteur en mémoire, par simple accès à un index.
La sortie est un tableau d'entiers. Grâce à BPE (§3), un mot fréquent tient en un seul ID.
Fréquent = 1 token · rare = plusieurs
L'espace devant un mot est collé au token. Donc chat et chat peuvent donner des IDs différents selon la position dans la phrase.
Deux tables. Le dictionnaire (texte → ID) est figé, livré en quelques Mo. La table d'embedding (ID → vecteur) est apprise et fait partie du modèle.
L'ID n'est qu'un numéro de ligne
| token | ID |
|---|---|
| Bon | 12 |
| jour | 8973 |
| ch | 331 |
| at | 266 |
| 🦊 | → octets |
| ligne | vecteur appris |
|---|---|
| 12 | −0.1 0.4 0.8 |
| 266 | 0.2 −0.3 0.1 |
| 331 | 0.9 0.3 −0.5 |
| 8973 | 0.0 0.6 −0.2 |
C'est ça qui marie un tokenizer à son modèle : les mêmes IDs ne pointent vers les bons vecteurs que pour le modèle entraîné avec ce vocabulaire-là.
Deux couches empilées. Dessous : les 256 octets → couverture totale, rien ne peut planter. Dessus : BPE → efficacité, un mot connu = 1 token.
La pile
Le dico se construit par fusions successives de la paire la plus fréquente :
Construction par fusions
La paire fusionnée est la plus fréquente de tout le corpus, pas de ce mot isolé. « es » revient partout, « ow » presque jamais.
Compilation (hors IA) : un programme statistique répète les fusions jusqu'à une taille fixe (p. ex. 100 000), puis verrouille.
Inférence (production) : le texte entrant est redécoupé en rejouant ces fusions dans leur ordre d'apprentissage, ce qui revient à reconstruire les plus gros blocs connus.
C'est l'ordre des fusions qui décide, pas le « plus long préfixe ». Ce dernier, c'est plutôt WordPiece (BERT). BPE applique ses règles par rang.
Le mot inconnu (Out Of Vocabulary) n'existe plus. Au pire, on descend à l'octet brut : 1 token par octet.
Le repli sur l'octet
Découper à l'extrême = fragmentation. Deux effets sur la machine : le coût en O(N²) de l'attention, et la saturation du KV cache (VRAM).
O(N²) sur la longueur totale de la séquence.
Un mot qui passe de 1 à 10 tokens dans un contexte de 2 000 n'ajoute que 9 tokens, pas un facteur ×100. Le ×100 ne vaut que si ce mot était toute l'entrée. Mais cumulée sur un texte entier, la fragmentation pèse vite.
Le vocabulaire BPE est sur-optimisé pour l'anglais. Tout le reste coûte plus de tokens, donc plus cher et plus lent.
Tokens pour 100 mots
Conséquences : plus de latence (time-to-first-token), plus de bande passante mémoire, facture API plus élevée.
Pas « un tokenizer par société » mais un tokenizer par lignée de modèles. On ne branche pas celui d'un modèle sur un autre : les IDs pointeraient vers les mauvaises lignes.
Un encodage partagé par une lignée
Oui, presque toujours, y compris chez OpenAI. pip install tiktoken et tu vois exactement comment le texte est découpé, en local. Ce qui est fermé, ce sont les poids. Le tokenizer n'est pas le modèle.
L'ID devient une position dans l'espace. C'est là que le sens apparaît.
L'espace sémantique (projection 2D de ~768 dimensions)
Un embedding est une position, pas une étiquette. L'ID 331 ne voulait rien dire. Ici, c'est l'inverse : la place dans l'espace EST le sens. Deux vecteurs proches = deux sens proches.
L'embedding, c'est simplement le contenu de la ligne pointée par l'ID. Mécaniquement trivial. Tout le saut est dans ce que ces nombres veulent dire.
① Proximité → similarité de sens.
② Direction → type de relation.
Les directions encodent des relations
Un mot se définit par son entourage. Deux mots qui apparaissent dans des contextes similaires sont poussés vers des vecteurs similaires.
« chat » et « chien » se rapprochent parce qu'on les croise dans les mêmes tournures (« nourrir le ___ », « le ___ dort »). Le sens n'est jamais déclaré : il est déduit des co-occurrences.
L'espace dépend du modèle qui l'a appris. Deux modèles → deux espaces sans aucun rapport. Même verrou que pour le tokenizer (fiche 01 §7).
Il n'existe pas un embedding, mais deux. Ils ne servent pas à la même chose.
C'est l'attention qui sépare les deux sens
Type 1 = l'entrée du modèle, juste après le tokenizer.
Type 2 = la sortie, après les couches d'attention.
Le contexte agit à DEUX moments différents
Le pipeline dans l'ordre : texte → tokenizer (IDs) → vecteurs statiques → attention → vecteurs contextuels.
Où tombe le vecteur STATIQUE d'un mot à deux sens ?