Tokenization & embeddings
Étape 1 : le texte en tokens
Un modèle ne lit pas des lettres : il lit des tokens, des fragments fréquents appris par compression statistique (BPE : on fusionne itérativement les paires de caractères les plus fréquentes). « anticonstitutionnellement » → anti|constitution|nellement ; « chat » → un seul token.
Pourquoi ça TE concerne directement :
- la facturation des API LLM est au token (~4 caractères/token en anglais, plus en français) ;
- la fenêtre de contexte est en tokens — « 128k » = tokens, pas mots ;
- les bizarreries des LLMs (compter les lettres, arithmétique) viennent souvent de là : le modèle ne voit jamais les caractères.
Étape 2 : les tokens en vecteurs — les embeddings
Chaque token est associé à un vecteur dense appris (768 à 4096 dimensions). La propriété magique : la géométrie encode le sens — les mots proches de sens ont des vecteurs proches (cosinus, module 2 !), et des directions capturent des relations (le vieux roi - homme + femme ≈ reine).
Les embeddings de phrases/documents (via des modèles dédiés) sont le moteur de la recherche sémantique : indexe les vecteurs de tes documents, encode la question, cherche les plus proches. C'est la moitié du RAG (leçon 7.3), et pgvector le fait dans ton Postgres.
Pourquoi les API LLM facturent-elles au token ?