Fenêtre de contexte

Vous collez un gros document dans un assistant, et il vous répond que c'est trop long. Pourtant, vous n'avez rien écrit de compliqué. Ce qui vient de saturer, c'est la fenêtre de contexte.

La fenêtre de contexte, c'est la quantité de texte, comptée en tokens, que le modèle peut prendre en compte en une seule requête. Voyez-la comme un plan de travail : tout ce sur quoi le modèle va travailler doit y tenir en même temps.

Et le plan de travail se remplit plus vite qu'on ne le croit, parce qu'il ne contient pas que votre question. Il y a d'abord le prompt système, ces instructions invisibles qui définissent le comportement de l'assistant. Puis l'historique de la conversation, renvoyé en entier à chaque message. Puis votre question. Puis, s'il y a un RAG, les passages récupérés dans vos documents. Puis les résultats des outils appelés. Et enfin la réponse en cours de génération, qui consomme elle aussi des tokens.

Attention au malentendu le plus fréquent : cette fenêtre n'est ni une mémoire permanente, ni une base documentaire. Rien n'y reste. C'est une table qu'on débarrasse entièrement à la fin de chaque requête, et qu'on redresse en repartant de zéro à la suivante.

Les conséquences sont très concrètes. Une application qui empile cent pages de documentation, deux cents messages d'historique et trente résultats d'outils va remplir la table de choses inutiles, payer chaque token au passage, et répondre plus lentement. Quand la fenêtre déborde, il faut couper quelque part : les systèmes tronquent l'historique, le résument, ou renoncent à des documents. Mal fait, c'est précisément l'information utile qui saute.

On se dit alors qu'il suffit de prendre un modèle à très grande fenêtre et de tout y mettre. C'est tentant, et ça ne suffit pas : une information peut être présente dans le contexte et pourtant mal utilisée. Pourquoi ? C'est le sujet du prochain post.