On vous a peut-être déjà sorti la métaphore du perroquet stochastique. Ou du moteur de prédiction. Ce sont de bonnes métaphores, mais elles restent abstraites. Voici comment ça marche vraiment, assez précisément pour prendre des décisions utiles, sans une seule équation.
Le token : l’unité de base
Un LLM ne lit pas des mots. Il lit des tokens. Un token est un fragment de texte, parfois un mot entier, parfois une partie de mot, parfois juste un espace ou un signe de ponctuation. En anglais, un token correspond en moyenne à 3/4 d’un mot. En français, un peu moins, les mots étant plus longs en moyenne.
Pourquoi ça compte ? Parce que la longueur des textes que vous envoyez à un modèle est mesurée en tokens, pas en mots. Et les prix des API sont facturés par token. 1 000 tokens, c’est à peu près 750 mots en anglais, ou 650 en français.
Quand vous envoyez « Bonjour, pouvez-vous analyser ce contrat ? », le modèle ne reçoit pas une phrase. Il reçoit une séquence de tokens : [«Bon», «jour», «,», «pou», «vez», «-vous», «anal», «yser», «ce», «contra», «t», «?»] (approximativement, le découpage exact dépend du tokenizer du modèle).
Le contexte : la mémoire à court terme
Un LLM n’a pas de mémoire persistante. Ce qu’il « sait » de votre conversation, c’est ce qui est dans la fenêtre de contexte, la séquence de tokens qu’il reçoit à chaque appel.
La fenêtre de contexte a une taille maximale. GPT-4 Turbo peut traiter jusqu’à 128 000 tokens. Claude 3.5 Sonnet, 200 000. C’est beaucoup. Ça ne signifie pas que le modèle utilise tout avec la même efficacité. Des recherches montrent que les modèles ont tendance à mieux retenir ce qui est au début et à la fin de la fenêtre que ce qui est au milieu. Ce biais est documenté, il n’est pas systématique.
La température : le curseur de créativité/fiabilité
Quand le modèle prédit le prochain token, il ne choisit pas toujours le plus probable. Il y a un paramètre appelé température qui règle le degré d’aléatoire dans le choix.
Température basse (proche de 0) : le modèle choisit presque toujours le token le plus probable. Sortie déterministe, répétitive, fiable pour les tâches factuelles.
Température haute (proche de 1 ou au-delà) : le modèle diversifie ses choix, explore des tokens moins probables. Sortie plus créative, plus variée, mais aussi plus susceptible de partir dans des directions inattendues.
Pour un cas d’usage factuel (extraction d’information, vérification de format, classement) : température basse. Pour de la rédaction créative : température plus haute. La plupart des utilisateurs n’y touchent pas, les interfaces par défaut utilisent une température intermédiaire.
Pourquoi ça hallucine, mécaniquement
Vous connaissez maintenant les pièces. La prédiction de token, le contexte, la température. Assemblez-les et l’hallucination devient inévitable.
Le modèle prédit le token suivant le plus vraisemblable. Quand il parle d’une chose sur laquelle il a été peu entraîné (un événement récent, une personne peu connue, une réglementation spécifique), il n’a pas de signal fort. Il prédit quand même, parce qu’il ne peut pas ne pas prédire. Et le token qu’il prédit peut être vraisemblable formellement (c’est un chiffre plausible pour une date, c’est un nom plausible pour une personne) mais faux factuellement.
Le modèle ne sait pas qu’il ne sait pas. Il n’a pas de métacognition sur ses lacunes. Il génère avec le même degré de fluidité une vérité et une invention.
Les modèles entraînés avec RLHF (Reinforcement Learning from Human Feedback) peuvent être plus enclins à produire des réponses fluides et confiantes, même sur des sujets incertains, parce que les annotateurs humains ont tendance à préférer les réponses assurées aux réponses hésitantes.
Ce point est crucial. Le fine-tuning par retour humain (RLHF), qui rend les modèles plus agréables à utiliser, peut aggraver l’hallucination en termes de confiance affichée. Les annotateurs humains récompensent les réponses qui semblent assurées. Le modèle apprend à paraître sûr, même quand il ne l’est pas.
Le RAG : une béquille utile, pas un remède
RAG signifie Retrieval-Augmented Generation. L’idée : au lieu de tout mettre dans le contexte ou de tout demander au modèle de « mémoriser » pendant l’entraînement, on récupère des documents pertinents à la volée et on les injecte dans le contexte avant de poser la question.
Exemple : vous avez une base de 10 000 contrats. À chaque question, on cherche les 5 contrats les plus proches sémantiquement de la question, on les met dans le contexte, et le modèle répond en s’appuyant sur ces documents.
Le RAG réduit les hallucinations sur le domaine couvert. Si la réponse est dans les documents, le modèle la trouvera. Si elle n’y est pas, il peut encore halluciner. Et si les documents eux-mêmes contiennent des erreurs, le modèle les répercutera.
Ce que vous pouvez en déduire pour vos cas d’usage
Ces mécanismes ont des implications directes :
Tâches adaptées à un LLM : transformation de format, résumé, classification sur des catégories bien définies, génération de code sur des patterns communs, première ébauche de rédaction.
Tâches à risque sans précautions : extraction d’information factuelle précise (dates, chiffres, noms propres), vérification juridique ou médicale, tout ce qui dépend de connaissances récentes non présentes dans les données d’entraînement.
Tâches inadaptées sans architecture spécifique : tout ce qui nécessite une mémoire longue terme, tout ce qui requiert un raisonnement formel garanti, tout ce qui ne tolère pas les erreurs non détectées.
La règle pratique : plus le coût d’une erreur est élevé dans votre contexte, plus vous avez besoin d’un mécanisme de validation humaine ou automatisée des sorties du modèle. Ce mécanisme a un coût. Ce coût fait partie du coût total de votre projet IA.