LLM : petites fenêtres, budget strict et fenêtre glissante

Dans les usages concrets des modèles de langage, des approches sobres de contexte visent à réduire coûts et latence sans noyer l’invite. Deux leviers émergent : un découpage strict du budget de tokens, adossé à la récupération de documents, et la suppression contrôlée des tours les plus anciens. Des exemples en Python illustrent ces mécanismes et leurs paramètres.

Allouer 20 % au système, 20 % à l’historique, 60 % aux données

Une méthode consiste à répartir la fenêtre de contexte en zones dotées de plafonds explicites. Un exemple prévoit jusqu’à 20 % pour les instructions système, 20 % pour l’historique de chat incluant la dernière requête, et les 60 % restants pour les contenus récupérés. Ce découpage impose l’arrêt de l’insertion quand une zone atteint sa borne, ce qui évite qu’un document massif ne consomme l’invite et contribue à limiter l’effet « perdu au milieu ». Un exemple Python montre la construction d’une invite sous contrainte de mots : il calcule un coût de base pour le message système et la requête, parcourt les morceaux récupérés, ne les ajoute que si le plafond n’est pas dépassé, puis interrompt dès que le budget est atteint. Les éléments retenus sont assemblés dans un contexte unique avant d’être combinés au message système et à la requête. Un test fixe un budget très petit à 30 mots pour forcer la coupure, avec comme objectif d’inclure la phrase « Madrid est la capitale de l’Espagne. » parmi des documents qui mentionnent aussi Séville, la situation géographique du pays et une population d’environ 47 millions. Cette logique s’inscrit dans la génération augmentée par récupération, qui enrichit l’invite avec des documents externes pertinents.

Supprimer les tours anciens fixe la latence et l’usage de tokens

La fenêtre glissante traite l’historique comme une file FIFO : à chaque nouveau message, les plus anciens sont supprimés. Le paramètre de taille de fenêtre sert de curseur entre conservation de contexte et maîtrise de la charge, avec, en contrepartie, une mémoire limitée mais prévisible. L’intérêt avancé tient au contrôle strict des tokens et de la charge de calcul, le nombre d’échanges considérés restant fixe, ce qui stabilise la latence. Dans l’exemple Python, une classe maintient un historique borné par un max_turns initialisé à 3 par défaut. À l’ajout, si la longueur dépasse la limite, l’historique est tronqué aux derniers tours. La construction d’invite réunit un rappel système sur la concision fondée sur le contexte récent et recompose les paires utilisateur–IA encore présentes. Un test avec max_turns=2 montre que seules les interactions les plus récentes sont prises en compte, réduisant l’invite au strict nécessaire.

Limiter la fenêtre vise coûts, latence et bruit contextuel

Dans les déploiements concrets, étendre massivement la fenêtre de contexte expose à des coûts d’API élevés et à des temps de réponse jugés inacceptables. S’y ajoute le risque que le modèle ignore des éléments enfouis au milieu d’une longue invite. À l’inverse, restreindre la fenêtre, si elle est gérée avec des règles claires, peut réduire la latence et les coûts tout en aidant le modèle à se concentrer sur les informations utiles à la réponse. Ces gains attendus reposent sur des choix de gestion explicites : bornes par zone, fin d’insertion dès le dépassement, ou encore suppression contrôlée des tours trop anciens. Ils répondent aux mêmes objectifs : éviter l’épuisement du budget de contexte et contenir le bruit qui dilue la pertinence.

Paramètres et heuristique utiles côté implémentation

Les exemples suggèrent des réglages concrets. Pour la budgétisation, la fonction de construction d’invite prend un plafond de mots, avec un défaut illustratif à 50, et s’appuie sur un simple décompte de mots comme proxy des tokens. Pour améliorer l’adéquation au coût réel, une heuristique propose qu’un mot corresponde en moyenne à 1,3 token. Côté fenêtre glissante, la classe d’exemple fixe max_turns à 3 par défaut et montre l’effet d’un seuil plus serré avec max_turns=2. Le jeu d’interactions simulées va d’une découverte de Python à des questions sur les listes et leurs types, puis prouve que seules les plus récentes demeurent dans l’invite, conformément à la limite imposée.