Votre conversation avec Claude atteint 80 000 tokens. Le modèle commence à se répéter. GPT-4o oublie soudainement le contexte des cinq messages précédents. Mistral 7B sur votre machine locale commence à halluciner des détails qui avaient été mentionnés précédemment.
Ce ne sont pas des échecs aléatoires. Ils sont symptomatiques d’une mauvaise gestion de la fenêtre de contexte — l’écart entre ce qu’un modèle peut théoriquement contenir et ce qu’il utilise réellement efficacement.
Comprendre les limites de la fenêtre de contexte (Et ce qu’elles signifient réellement)
Une fenêtre de contexte est la quantité de texte — mesurée en tokens — qu’un modèle peut prendre en compte lors de la génération d’une réponse. Claude 3.5 Sonnet prend en charge 200 000 tokens. GPT-4o prend en charge 128 000. Llama 3 70B prend en charge 8 000 dans sa version de base.
Mais avoir une fenêtre de 200 000 tokens ne signifie pas que vous devriez utiliser les 200 000 tokens pour votre conversation.
Les modèles performent moins bien sur les tâches lorsque la fenêtre se remplit — en particulier sur les tâches de récupération où ils doivent trouver des informations spécifiques enfouies dans le contexte antérieur. Les tests internes d’Anthropic montrent que la précision de Claude sur les tâches de récupération de type « aiguille dans une botte de foin » (trouver un fait spécifique dans un long document) diminue d’environ 5 à 7 % pour chaque 25 % de la fenêtre que vous remplissez. À 80 % de capacité, vous constatez une dégradation des performances en matière de rappel d’informations, même si les tokens rentrent encore.
La fenêtre pratique — où le modèle fonctionne de manière fiable — est généralement de 60 à 70 % du maximum théorique. Au-delà, la précision diminue sensiblement.
Les trois stratégies qui fonctionnent réellement
1. Résumé avant compression
Ne vous contentez pas de tronquer les anciens messages. Résumez-les.
Lorsque la conversation dépasse 40 000 tokens (pour Claude Sonnet) ou 30 000 tokens (pour GPT-4o), arrêtez-vous et créez un résumé de tout ce qui a été discuté jusqu’à présent. Cela sert deux objectifs : il préserve le sens sémantique sans l’encombrement des tokens, et il oblige le modèle à consolider sa propre compréhension.
# Mauvaise approche : ajouter simplement des messages
Utilisateur : [Message 1]
Assistant : [Réponse 1]
Utilisateur : [Message 2]
Assistant : [Réponse 2]
... répéter 50 fois ...
Utilisateur : [Message 51 - dépasse la fenêtre de contexte]
# Meilleure approche : résumer aux points de contrôle
Utilisateur : [Messages 1-10]
Assistant : [Réponse]
Utilisateur : Veuillez résumer notre conversation jusqu'à présent
Assistant : [Résumé de la discussion, décisions clés, contexte]
# Ajoutez maintenant de nouveaux messages au résumé, pas à l'historique complet
Contexte : [Résumé ci-dessus]
Utilisateur : [Message 11]
Assistant : [Réponse utilisant à la fois le résumé et le nouveau message]Le résumé devient la nouvelle « base de contexte » pour les messages suivants. Vous avez compressé 10 messages en 200 à 400 tokens tout en conservant 95 % ou plus de la valeur sémantique.
2. Fenêtre glissante avec injection de contexte explicite
Pour les applications où vous ne pouvez pas faire de pause et résumer — comme un chatbot qui doit répondre en temps réel — utilisez une approche de fenêtre glissante. Gardez uniquement les N derniers messages dans le contexte actif, plus une instruction système fixe qui définit le style d’interaction.
# Instruction système (toujours incluse, compte comme contexte)
Vous êtes un conseiller technique. Lorsque l'utilisateur pose des questions sur le déploiement,
n'oubliez pas : nous utilisons AWS. Lorsque vous discutez des tests, faites référence à la
suite de tests existante dans la base de code.
# Fenêtre glissante : garder uniquement les 5 derniers messages
[Messages précédents supprimés]
Utilisateur : [Message N-4]
Assistant : [Réponse]
Utilisateur : [Message N-3]
Assistant : [Réponse]
Utilisateur : [Message N-2]
Assistant : [Réponse]
Utilisateur : [Message N-1]
Assistant : [Réponse]
Utilisateur : [Message N] <- entrant
# Utilisation des tokens : instruction système + 5 derniers messages
# Résultat : environ 4 000 à 6 000 tokens selon la longueur des messagesLe compromis est clair : vous perdez le contexte historique au-delà des 5 derniers messages, mais vous maintenez des performances constantes. Pour les cas d'utilisation où les utilisateurs ne font pas référence à des choses dites il y a 20 messages — support client, revue de code, conception itérative — cela fonctionne bien.
3. Contexte augmenté par récupération (Modèle RAG)
Si vous avez besoin d'accéder à l'ancien contexte sans tout garder dans la conversation, intégrez et indexez les messages ou documents précédents, puis récupérez uniquement ceux qui sont pertinents.
Au lieu de passer les 40 000 tokens complets de la conversation au modèle, vous :
- Convertissez chaque message ou section en un embedding
- Stockez les embeddings dans une base de données vectorielle (Pinecone, Weaviate, même SQLite avec extension vectorielle)
- Lorsque l'utilisateur envoie un nouveau message, récupérez les 3 à 5 messages précédents les plus similaires
- Injectez-les dans le contexte, avec le message actuel
Cela maintient votre fenêtre de contexte active à 5 000 à 8 000 tokens tout en donnant accès à un historique de conversation virtuellement illimité. Le modèle ne voit que ce qui est pertinent pour la requête actuelle.
# Pseudocode pour la gestion du contexte basé sur RAG
import anthropic
from embedding_service import embed_and_store, retrieve_similar
def chat_with_rag_context(user_message, conversation_id):
# Récupérer les messages passés similaires
similar_messages = retrieve_similar(
query=user_message,
conversation_id=conversation_id,
limit=4
)
# Construire la fenêtre de contexte
context =
