Les lois d'échelle inverses de l'attention & Mesurer son contexte

Les lois d’échelle inverses de l’attention

L’idée en une phrase

Les LLM ne s’améliorent pas quand on leur donne plus de contexte : passé un remplissage modéré, leur performance décroît à mesure que la fenêtre se remplit — c’est la loi d’échelle inverse de l’attention (souvent nommée context rot). Ce phénomène est le pourquoi de Reduce : on limite ce qui entre dans la fenêtre principale non pour économiser, mais parce que chaque token de bruit dilue l’attention disponible pour les tokens qui comptent.

Analogie : une conversation dans un café. À deux, chaque mot porte. À mesure que les tables voisines se remplissent et haussent le ton, la même attention se répartit sur un brouhaha croissant, et l’on finit par manquer une phrase pourtant dite juste à côté. Le bruit n’a pas effacé la phrase — il a dilué la capacité à l’entendre. Une fenêtre de contexte saturée, c’est le café bondé : l’information y est encore, mais l’agent ne l’entend plus.

Points clés

• Loi d’échelle inverse : au-delà d’un remplissage modéré, ajouter du contexte dégrade la sortie plutôt que de l’améliorer. L’étude Context Rot (Chroma, 2025) a mesuré 18 modèles de pointe — dont Claude Opus 4 — et tous perdent en précision à mesure que l’entrée s’allonge, y compris sur des tâches simples.
• Perte au milieu (lost in the middle) : l’attention suit une courbe en U — forte au début et à la fin de la fenêtre, faible au milieu. Une information enfouie au centre d’un long contexte peut voir la précision chuter de 30 % ou plus.
• Dilution de l’attention : le mécanisme d’attention compare chaque nouveau token à tous les précédents. Plus la fenêtre s’allonge, plus l’attention se répartit — et plus le coût de calcul par token grimpe (croissance quadratique).
• Le mirage des benchmarks : les scores quasi parfaits au Needle in a Haystack (retrouver une phrase connue dans un long texte) mesurent une simple correspondance lexicale ; ils ne prédisent pas la tenue sur des tâches réelles, sémantiques et multi-étapes, où la dégradation est bien visible.
• Conséquence directe sur l’axe R&D : Reduce garde la fenêtre basse pour maintenir l’attention dense — c’est la condition d’une exécution réussie du premier coup, comme posé au chapitre 1.

Exemple concret

Une étude de Stanford (2023, Lost in the Middle) chiffre le mécanisme : un modèle à qui l’on fournit 20 documents récupérés (~4 000 tokens) pour répondre à une question voit sa précision tomber de ~70-75 % à ~55-60 % quand le document utile est enfoui au milieu du lot plutôt qu’en tête. Rapporté à une fenêtre de 200 000 tokens : charger « par sécurité » 30 fichiers pour une tâche qui n’en exige que 3, c’est passer de ~6 000 tokens ciblés à ~60 000 tokens (~30 % de la fenêtre) de bruit — et noyer la réponse utile dans une masse où l’attention se dilue. Le modèle n’a pas changé ; le taux de réussite, si.

Placement de l’information et attention

Commande — estimer le bruit avant de le charger

# Heuristique ~4 caracteres = 1 token : chiffrer le cout d'un lot AVANT de l'ouvrir.
# Ici, tous les .md de src/ — pour decider s'il faut vraiment tout charger.
find src -name '*.md' | xargs wc -c | tail -1 \
  | awk '{print int($1/4) " tokens estimes (~" int($1/4*100/200000) "% d une fenetre 200k)"}'

Piège courant : « les modèles à grande fenêtre (200k, 1M tokens) ont réglé le problème » est inexact. Une fenêtre plus grande relève la capacité maximale, pas la qualité de l’attention à remplissage égal. La loi d’échelle inverse s’observe sur tous les modèles testés, quelle que soit la taille nominale : disposer d’1M de tokens n’autorise pas à en gaspiller 700 000.

Mesurer son contexte et son budget de tokens

L’idée en une phrase

On ne réduit bien que ce qu’on a d’abord mesuré : la commande intégrée /context de Claude Code affiche la répartition vivante de la fenêtre par poste, et le buffer d’auto-compaction signale l’approche de la saturation. Mesurer est le premier geste de Reduce — sans chiffre, « alléger le contexte » reste un vœu pieux.

Analogie : un budget mensuel. Tant qu’on ne relève pas ses dépenses poste par poste, « faire des économies » est une intention floue ; le relevé détaillé — loyer, courses, abonnements — révèle où part vraiment l’argent et quel poste tailler en premier. /context est ce relevé : il ventile les tokens par catégorie pour qu’on sache précisément quoi couper.

Points clés

• /context (intégrée depuis Claude Code v1.0.86) ventile la fenêtre par poste : prompt système, outils système, outils MCP, fichiers mémoire (CLAUDE.md), sous-agents, messages, espace libre, plus le buffer d’auto-compaction. C’est une commande cliente : on la tape soi-même dans le REPL — l’agent ne peut pas l’invoquer.
• La fenêtre standard vaut ~200 000 tokens (extensible à 1M sur certains plans). Le buffer d’auto-compaction (~33 000 tokens début 2026) est réservé d’avance : l’espace réellement utilisable est inférieur à la taille nominale.
• Heuristique de poche : ~1 token pour 4 caractères (un peu plus dense en français). Elle suffit à budgéter un fichier avant de le charger — un CLAUDE.md de 8 000 caractères pèse ≈ 2 000 tokens.
• Déport automatique des MCP : quand les définitions d’outils MCP dépassent un certain pourcentage de la fenêtre, Claude Code les défère et les charge à la demande — un Reduce natif que l’on retrouvera au chapitre sur l’hygiène des serveurs MCP.
• Le relevé n’est pas une fin : il désigne le poste à réduire en premier, puis sert à vérifier l’effet en re-mesurant.

Exemple concret

Un /context en début de session, sur un projet mal rangé, peut afficher : prompt système et outils ~15 000 tokens, quatre serveurs MCP ~38 000, un CLAUDE.md fourre-tout ~9 000, deux sous-agents ~4 000 — soit ~66 000 tokens (~33 % de 200k) avant la première question, buffer d’auto-compaction non compris. Le relevé désigne le coupable : les MCP pèsent plus lourd que tout le reste réuni. Retirer les deux serveurs inutiles à la tâche (via --strict-mcp-config, prochain chapitre) rend ~19 000 tokens et ramène l’occupation sous 24 %. Sans le /context préalable, on aurait « optimisé » au hasard — peut-être en taillant le CLAUDE.md, qui ne pesait presque rien.

Postes typiques d’une fenêtre de 200k

Commande — mesurer, décider, re-mesurer

# 1. Mesurer la repartition de la fenetre (commande CLIENTE, tapee dans le REPL) :
/context
# 2. Reperer le poste le plus lourd (souvent les serveurs MCP ou un CLAUDE.md fourre-tout).
# 3. Reduire ce poste precis, puis re-mesurer pour verifier l'effet :
/context
# On ne reduit bien que ce qu'on a mesure — et on confirme le gain en re-mesurant.

Piège courant : confondre espace libre et espace utilisable. /context réserve d’avance le buffer d’auto-compaction (~33k tokens) : sur une fenêtre de 200k, il reste en pratique ~167k avant que l’auto-compaction ne se déclenche. Se croire assis sur 200k pleins fait saturer plus tôt que prévu — et l’auto-compaction, comme /compact (chapitre 1), résume avec perte.

Fil rouge — Reduce ou Delegate ?

Ce chapitre est le socle du levier Reduce. Les lois d’échelle inverses expliquent pourquoi réduire : l’attention est un budget fini que le bruit dilue, et un token de trop au mauvais endroit coûte de la précision. /context fournit l’instrument pour le faire : mesurer avant de tailler, plutôt que d’optimiser à l’aveugle. L’impact se chiffre — ramener une fenêtre de ~33 % à ~16 % d’occupation, c’est rendre ~34 000 tokens de bruit à l’attention utile, sans changer ni le modèle ni le prompt. Delegate viendra plus tard déporter ce qui reste incompressible ; ici, on mesure et on réduit à la source.

Travaux pratiques

À chaque leçon, un petit artefact à déposer dans ton .claude/ — commande, sous-agent, hook, mémo… — pour te bâtir, au fil du livre, une boîte à outils de context engineering réutilisable.

Une commande maison — /context-audit

Ce chapitre porte sur la mesure : autant en faire une habitude outillée. Cette commande slash, à déposer dans .claude/commands/context-audit.md, estime le coût en tokens d’un lot de fichiers avant de les charger et recommande de réduire (résumer, écarter) ou de déléguer (confier à un sous-agent) ce qui est trop lourd — un instrument de Reduce qui complète le /context natif.

# /context-audit — budgeter le contexte avant de charger

## Purpose
Estimer le cout en tokens d'un lot de fichiers avant de les charger dans la fenetre,
pour n'amener que l'essentiel et garder l'attention dense.

## Read
- Les fichiers candidats passes en argument (chemins ou glob), par ex. src/**/*.md.

## Run
- Pour chaque fichier : compter les caracteres, diviser par 4 (~1 token pour 4 caracteres).
- Additionner, puis rapporter le total a la fenetre (~200 000 tokens).

## Report
Un tableau par fichier — tokens estimes, % de la fenetre — puis un verdict :
garder (leger et utile), Reduce (resumer ou ecarter), ou Delegate (confier le
fichier lourd a un sous-agent qui n'en renverra qu'un resume).

Invoque-la par /context-audit src/**/*.md au début d’une session. Un fichier de 40 000 caractères (~10 000 tokens, ~5 % de la fenêtre) est ainsi signalé avant d’entrer, pas découvert après coup dans un /context déjà lourd : moins de bruit chargé au hasard, une attention préservée pour la vraie tâche.