Fenêtre de contexte, température et hallucinations

La fenêtre de contexte est la quantité de texte, mesurée en tokens, que le modèle prend en compte à chaque génération : les consignes, l'historique de la conversation, les documents fournis et la réponse en cours. La température règle la part de hasard dans le choix de chaque token. Ces deux réglages expliquent une bonne part des hallucinations, ces réponses fausses données avec assurance. Ce chapitre te montre comment elles naissent et comment les limiter.

La fenêtre de contexte

À chaque requête, le modèle reçoit un seul long texte, découpé en tokens. Ce texte contient, dans l'ordre :

1. le prompt système : les consignes de l'application (« Tu es l'assistant du support de Sorbier Logistique… ») ;
2. l'historique : tous les messages précédents de la conversation, les tiens et les siens ;
3. les documents et les résultats d'outils : un fichier joint, des pages trouvées sur le Web, le résultat d'une commande ;
4. ta nouvelle question ;
5. la réponse qu'il est en train d'écrire, qui doit tenir dans la place qui reste.

La taille maximale de ce texte est la fenêtre de contexte. Elle est d'un million de tokens pour les modèles Claude actuels, de 128 000 tokens pour Llama 3.2. Attention au piège d'Ollama : la taille du contexte par défaut dépend de la mémoire de la carte graphique, pas de la capacité du modèle. Elle est de 4 096 tokens sous 24 Go de mémoire graphique (un PC portable, ou un serveur sans GPU comme srv-ia), d'environ 32 000 entre 24 et 48 Go, et d'environ 256 000 au-delà. Tu la règles avec l'option num_ctx ou la variable OLLAMA_CONTEXT_LENGTH.

Quand l'historique devient trop long, l'application doit faire un choix : retirer les messages les plus anciens, ou les remplacer par un résumé. C'est pour cela qu'un assistant « oublie » les consignes que tu lui as données au début d'une très longue conversation.

Une grande fenêtre ne règle pas tout. Des chercheurs ont montré en 2023 (étude Lost in the Middle, Liu et al.) que les modèles exploitent moins bien une information placée au milieu d'un très long contexte qu'au début ou à la fin. Envoie les passages utiles plutôt que tout un manuel, et place la question à la fin.

La mémoire d'un assistant

Les assistants grand public proposent une « mémoire » : ils retiennent ton prénom, ton option ou tes préférences d'une conversation à l'autre. Ce n'est pas le modèle qui apprend : l'application stocke des notes et les ajoute à la fenêtre de contexte de tes nouvelles conversations. Ces notes sont des données qui te concernent : tu peux les consulter et les effacer dans les réglages.

Température et échantillonnage

Le modèle calcule pour chaque token un score brut, appelé logit. Pour passer des scores aux probabilités, on divise chaque score par la température T, puis on applique la fonction softmax :

p(token i) = e^(zᵢ / T) / Σⱼ e^(zⱼ / T)

zᵢ : le score brut du token i      T : la température (T > 0)

Reprends l'exemple du DHCP, avec des scores de 5 pour DHCP, 3 pour DNS, 2 pour ARP et 1 pour NAT :

• Température basse (vers 0) : le modèle choisit presque toujours le token le plus probable. Réponses plus prévisibles, adaptées à l'extraction de données, au classement ou au code.
• Température haute (au-dessus de 1) : les tokens moins probables passent plus souvent. Réponses plus variées, utiles pour chercher des idées, mais plus de risques de dérailler.

Un second réglage, top-p, ne garde que les tokens les plus probables dont le total atteint p (par exemple 90 %) et tire au sort parmi eux. Les fournisseurs conseillent de régler l'un ou l'autre, pas les deux.

Les modèles qui raisonnent

Les modèles dits « de raisonnement » écrivent d'abord une réflexion, une suite de tokens où ils décomposent le problème, testent une piste, se corrigent, avant de produire la réponse finale. Sur un problème en plusieurs étapes (un calcul de sous-réseaux, un bug qui demande de suivre trois fichiers), la réponse est nettement meilleure. Le prix à payer : plus de tokens générés, donc plus de temps et plus de coût.

Les API exposent un réglage pour doser cet effort. Chez Anthropic, le paramètre effort va de low à max ; Claude Opus 5.5 réfléchit toujours, avec un effort medium par défaut. Avec Ollama, l'option think active ou coupe la réflexion des modèles qui la proposent. Pour une question simple, un effort bas suffit et coûte moins cher.

Pourquoi l'IA hallucine

Une hallucination est une réponse fausse ou inventée, présentée avec la même assurance qu'une réponse juste : une option de commande qui n'existe pas, une référence d'article de loi inventée, un numéro de version faux. Ce n'est pas un bug qu'un correctif fera disparaître, c'est une conséquence du fonctionnement :

1. Le modèle produit du plausible. Son objectif d'entraînement est de prédire une suite vraisemblable. Si la bonne réponse était rare dans ses données, il assemble une réponse qui ressemble à une bonne réponse.
2. L'entraînement récompense la réponse plutôt que le doute. Dans un article de septembre 2025, Why language models hallucinate, des chercheurs d'OpenAI expliquent que la plupart des évaluations notent seulement l'exactitude : comme à un QCM sans points négatifs, deviner rapporte plus que dire « je ne sais pas ».
3. La date de coupure. Pour un fait postérieur à ses données, il n'a rien de fiable et complète quand même.
4. La demande l'y pousse. Une question ambiguë, ou qui contient une prémisse fausse (« Quelle option de ping chiffre les paquets ? »), l'entraîne à répondre dans le sens de la question. Les modèles ont tendance à aller dans le sens de leur interlocuteur : on parle de complaisance.
5. Le contexte est trop long ou mal rempli. L'information utile était sortie de la fenêtre, ou noyée au milieu.

Les hallucinations les plus fréquentes en informatique :

Réduire les hallucinations

Tu ne les supprimeras pas, mais tu peux en réduire le nombre et surtout les attraper.

1. Donne la source. Colle la documentation, le message d'erreur complet, le fichier concerné. Un modèle qui travaille sur un texte fourni invente beaucoup moins qu'un modèle qui répond de mémoire.
2. Autorise le doute. Écris : « Si tu n'es pas sûr, dis-le. Si l'information n'est pas dans le document, réponds que tu ne la trouves pas. »
3. Demande où est l'information. « Cite la section du document d'où vient chaque point. » Tu vérifies ensuite en trente secondes.
4. Évite les prémisses. Demande « Est-ce que ping sait chiffrer les paquets ? » plutôt que « Quelle option de ping chiffre les paquets ? ».
5. Découpe. Une tâche courte et précise à la fois.
6. Fais exécuter. Un code se teste, une commande se lance dans une VM de test ; un assistant qui exécute du code calcule juste là où il aurait estimé de tête.
7. Vérifie toujours ce qui compte, avec la méthode du chapitre 5.

Les biais de l'IA

Un biais est une erreur systématique, toujours dans le même sens. Un modèle reproduit les régularités de ses données d'entraînement, y compris leurs biais, et il les applique avec la même assurance que le reste :

• des stéréotypes de genre, d'âge ou d'origine : dans un brouillon d'évaluation ou de lettre, les qualités attribuées à une personne peuvent varier avec son prénom ;
• la surreprésentation de l'anglais et des usages américains : il répond moins bien en français, et une question de droit du travail peut recevoir une réponse valable aux États-Unis, pas en France ;
• la solution la plus fréquente dans ses données plutôt que la plus adaptée à ton contexte : la bibliothèque la plus populaire, la configuration la plus répandue, même quand ton infrastructure en appelle une autre.

Pour un outil qui trie des CV ou rédige l'évaluation d'un salarié, un biais devient une discrimination, interdite par le Code du travail (article L1132-1). C'est une des raisons pour lesquelles l'AI Act classe ces usages en haut risque et exige des données examinées et un contrôle humain (chapitre 10). Les parades : ne jamais laisser le modèle seul décider sur une personne, relire ses textes en cherchant ce qu'il suppose, et tester un outil avec des cas identiques qui ne diffèrent que par le prénom, le genre ou l'âge.

Exercices