Fenêtre de contexte

Une mémoire de travail

La fenêtre de contexte est ce que le modèle voit au moment où il répond. Tout ce qui se trouve hors de cette limite n'existe pas pour lui : ni la conversation d'hier, ni le document laissé dans un autre dossier, ni la consigne donnée la semaine dernière. Un assistant ne se souvient donc pas spontanément de vos échanges ; il les relit seulement si l'application les lui renvoie dans la requête. Cette distinction entre mémoire affichée et mémoire réelle explique beaucoup de malentendus.

À chaque question, l'application renvoie généralement l'historique complet, la consigne système et les documents joints. Plus la conversation s'allonge, plus la requête est lourde : le coût augmente, la latence aussi, et le modèle peut perdre de vue le début de l'échange. Les interfaces qui tronquent l'historique sans le dire produisent des réponses qui semblent incohérentes alors qu'elles sont simplement amputées. Un résumé périodique de l'échange est souvent plus efficace qu'un historique intégral.

Ce que la taille change

Une fenêtre large permet de traiter un dossier entier, un contrat de plusieurs dizaines de pages ou un compte rendu de réunion complet. C'est un vrai progrès pour l'analyse documentaire. Mais la capacité théorique n'est pas la capacité pratique : l'attention portée à chaque passage diminue quand le texte s'allonge, et les informations situées au milieu d'un long contexte sont souvent moins bien exploitées que celles du début ou de la fin. Il faut donc tester, pas supposer.

Chercher les passages utiles plutôt que tout verser dans la fenêtre reste souvent la meilleure stratégie. Une recherche documentaire qui extrait les trois extraits pertinents donne fréquemment de meilleurs résultats qu'un dossier complet envoyé en vrac, pour un coût bien inférieur. La fenêtre large sert alors de secours pour les cas où le découpage échoue, pas de méthode par défaut. C'est le principe des architectures de recherche augmentée, plus faciles à maintenir qu'un contexte géant.

Le prix du texte

Les fournisseurs facturent les jetons envoyés et les jetons produits. Un long contexte coûte donc à chaque appel, même si la réponse est courte. Renvoyer vingt pages pour obtenir une phrase de synthèse revient à payer vingt fois le même texte. Certains services proposent une mise en cache du préambule, qui réduit la facture quand la même consigne revient souvent, mais elle ne supprime pas la limite de taille. Il faut lire la grille tarifaire avant de concevoir l'interface.

La troncature intelligente est un art discret. On garde la consigne, les derniers échanges, les extraits sélectionnés, et l'on résume le reste. Mal fait, ce résumé efface précisément le détail qui comptait. Bien fait, il conserve les décisions, les noms, les chiffres et les dates, en abandonnant les politesses. Ce travail d'élagage gagne à être testé sur des conversations réelles, longues et désordonnées. C'est souvent là que se joue la qualité perçue d'un assistant, bien plus que dans le choix du modèle.

Régler la fenêtre dans un projet

Trois questions suffisent à cadrer le sujet. Quel est le document le plus long que l'outil devra traiter ? Combien d'échanges simultanés doit-il supporter ? Que doit-il retenir d'une session à l'autre ? Les réponses déterminent le découpage, le choix du modèle et la nécessité d'une mémoire externe. Un projet qui ignore ces questions découvre les limites en production, au pire moment. Les demandes les plus longues sont rarement celles que l'on avait imaginées.

Il faut enfin distinguer la fenêtre du modèle et la mémoire de l'application. Une base de données, un index documentaire ou un fichier de suivi peuvent conserver des informations bien au-delà de la fenêtre, à condition qu'un mécanisme les réinjecte au bon moment. Cette mémoire externe est plus fragile qu'elle n'y paraît : elle doit être mise à jour, purgée et contrôlée, sous peine de réinjecter des informations périmées. Un assistant qui cite une vieille version d'un tarif est plus dangereux qu'un assistant muet.