Vous collez une centaine de pages de documentation dans le prompt et posez une question simple. La réponse est fausse. Ou alors, elle ignore la règle de formatage que vous avez donnée au début. Vous lui avez tout donné. Cela aurait dû fonctionner. Mais ça n'a pas marché.
C'est le piège du contexte. La plupart des développeurs supposent que fournir plus d'informations à une IA produit automatiquement de meilleurs résultats. C'est souvent le contraire qui se produit. La construction d'applications d'IA fiables nécessite de comprendre trois mécanismes fondamentaux : la façon dont les modèles comptent le texte, la quantité d'informations qu'ils peuvent contenir à la fois, et ce qu'il advient des informations une fois la conversation terminée.
Les tokens : la véritable monnaie
Un token est la plus petite unité traitée par un modèle de langage. Il peut s'agir d'un seul caractère, d'un fragment de mot ou d'un mot courant dans son intégralité. Le mot « purchase » se divise souvent en deux tokens, tandis qu'un mot court comme « cat » reste entier. La ponctuation et les espaces consomment également des tokens. Le code est particulièrement gourmand. Un bloc de Python avec des indentations imbriquées et des caractères spéciaux peut gonfler pour atteindre trois ou quatre fois le nombre de tokens que vous auriez estimé à première vue.
Pourquoi les concepteurs devraient-ils s'en soucier ? Le prix de l'API se calcule par token. Il en va de même pour le temps de traitement. Un prompt qui semble faire deux pages de texte peut coûter quelques centimes ou plusieurs dollars selon son contenu. Pire encore, les tokens s'accumulent des deux côtés de l'échange. Vous payez pour chaque token de votre prompt, et vous payez pour chaque token généré par le modèle. Une croissance incontrôlée du contexte érode silencieusement les marges.
La fenêtre de contexte est un tableau blanc
La fenêtre de contexte définit la limite supérieure de ce qu'un modèle peut voir en une seule fois. Imaginez un tableau blanc accroché dans une petite pièce. Vous pouvez le remplir d'instructions système, de questions d'utilisateurs, de documents récupérés et de conversations précédentes. Mais le tableau ne grandit jamais. Lorsque du nouveau texte arrive, l'ancien texte tombe du bord.
Cela est important car les modèles ne vous avertissent pas lorsqu'ils commencent à perdre du contenu. Si votre instruction système se trouve en haut d'une longue conversation et que vous continuez à ajouter des messages, cette instruction finit par sortir du champ de vision. Le modèle peut alors revenir à son comportement par défaut, ignorer vos règles de formatage ou contredire les instructions précédentes. Différents modèles offrent des limites différentes, certains gérant quelques milliers de tokens et d'autres des centaines de milliers, mais les mécanismes restent identiques. L'entrée et la sortie partagent le même budget. Un modèle qui génère une réponse de deux mille tokens dispose de deux mille tokens de moins pour se souvenir de ce que vous lui avez dit.
La mémoire est une astuce, pas une fonctionnalité
Il n'y a pas de mémoire persistante à l'intérieur des poids du modèle pendant l'inférence. Aucune. Lorsque vous fermez l'onglet et revenez le lendemain, le modèle ne vous reconnaît pas. Chaque appel d'API est un démarrage à froid.
Ce qui ressemble à de la mémoire n'est qu'une gestion comptable astucieuse effectuée par la couche applicative. Le frontend stocke vos messages dans une base de données. Lorsque vous envoyez une nouvelle requête, le logiciel récupère l'historique pertinent, l'intègre dans un nouveau prompt et envoie l'ensemble du paquet au modèle. Le modèle lui-même n'en a aucune idée.
Cette distinction est cruciale pour les équipes produit. Si vous comptez sur le modèle pour « se souvenir » d'une préférence utilisateur, vous construisez sur du sable. Vous devez gérer l'état vous-même. Décidez quoi mettre en cache. Décidez comment le rafraîchir. Et reconnaissez que chaque octet d'historique que vous renvoyez consomme l'espace de votre tableau blanc.
Quand le contexte devient du bruit
Inonder le prompt produit l'effet inverse de manière prévisible.
Le bruit tue le signal. Si vous déversez l'intégralité d'une base de code pour poser une question sur un seul bug, le modèle est confronté au problème de « l'aiguille dans une botte de foin ». Il pourrait faire référence au mauvais fichier, suggérer des modifications sur du code mort ou produire une réponse générique parce qu'il ne peut pas