Résumé technique : RCWT – Mesurer le déplacement du budget de tâche par le contenu de coordination dans les appels LLM

1. Énoncé du problème

Les systèmes modernes de modèles de langage de grande taille (LLM) multi-agents et augmentés par la mémoire consolident fréquemment divers types d'informations — incluant les instructions de tâche, les documents récupérés, les résumés de mémoire, les messages précédents des agents, les sorties d'outils et les définitions de rôles — en un seul prompt. Cela crée un problème critique d'allocation de ressources : pour une fenêtre de contexte fixe ($W$), chaque jeton (token) alloué au « contenu de coordination » ($c$) réduit physiquement les jetons disponibles pour le « bloc de tâche » ($W - c$).

La question centrale n'est pas seulement de savoir si un modèle supporte une grande fenêtre de contexte, mais de savoir quelle part de cette fenêtre reste disponible pour l'évidence spécifique à la tâche requise pour résoudre le problème. Des recherches antérieures indiquent que les modèles n'utilisent pas tous les positions de manière uniforme et que les performances peuvent se dégrader à mesure que la longueur de l'entrée augmente, même lorsque l'information pertinente est présente. Ce document isole l'effet opérationnel spécifique du déplacement du budget de tâche : le phénomène où l'augmentation du contenu de coordination sous un budget fixe tronque ou réduit l'évidence résiduelle de la tâche, provoquant potentiellement des chutes de performance brutales (performance cliffs).

2. Méthodologie : Le Roundtable Context Window Test (RCWT)

Les auteurs introduisent le RCWT, un protocole de test de référence contrôlé à appel unique, conçu pour mesurer l'effet de déplacement tout en excluant les variables confondantes de la dynamique multi-agents (ex. : planification des tours, politiques de récupération ou topologie des agents).

2.1 Conception expérimentale

• Expérience à budget fixe : L'expérience principale utilise une fenêtre de contexte fixe ($W = 4096$). Le prompt est construit à partir de trois blocs déterministes :
  • $u$ : Bloc d'instruction de tâche fixe (337 jetons).
  • $c$ : Bloc de coordination (synthétique, structuré comme un contexte partagé multi-agents).
  • $r$ : Bloc de référence technique (tronqué pour s'insérer dans le budget restant).
  • Contrainte : $c + u + r = W$.
• Variables : Le protocole fait varier le ratio de coordination $q = c / (W - u)$ selon des valeurs cibles de 0 % à 98 %. Cela génère des parts de coordination réelles sur le budget total ($p = c/W$) allant de 0 % à environ 90 %.
• Tâche : Une tâche de rappel dépendante du contexte exigeant au modèle d'extraire 8 faits techniques spécifiques d'un bloc de référence concernant des spécifications logicielles (ex. : options de chiffrement, latence Redis, temps de montée en charge CRDT).
• Modèles testés : GPT-4.1-mini, Claude Haiku 4.5, et Gemini 2.0 Flash (remplacé plus tard par Gemini 2.5 Flash lors des runs d'ablation).
• Évaluation : Vérification binaire des faits sur 10 éléments (8 éléments effectifs utilisés pour le score).

2.2 Études d'ablation

Pour distinguer la troncation (perte d'évidence) de l'interférence sémantique (le contenu de coordination confondant le modèle même lorsque l'évidence est intacte), les auteurs ont mené deux tests supplémentaires :

1. Ablation de la tâche intacte : Le bloc tâche/référence complet ($t$) est maintenu intact. Les jetons de coordination sont ajoutés autour de ce bloc, augmentant la longueur totale du prompt au-delà de $W$ fixe. Cela teste si de gros volumes de coordination causent une dégradation sans perte d'évidence.
2. Tâches limites (Boundary Tasks) :
   • Tâche algorithmique autonome : Ne nécessite aucune référence externe ; la coordination est non pertinente.
   • Packs de benchmarks externes : GSM8K, MMLU-Pro et DROP regroupés en packs de 10 éléments pour tester la sensibilité sous budgets fixes.

3. Résultats clés

3.1 Déplacement à budget fixe (Tâche principale)

• Performance stable avec un overhead modéré : Les trois modèles ont maintenu une précision proche de la ligne de base lorsque le contenu de coordination était modéré.
• Chute de performance brutale : La précision a chuté de manière significative uniquement lorsque le bloc de tâche/référence résiduel ($r$) était réduit à quelques centaines de jetons.
  • À un ratio de coordination cible de 90 % (réalisé $p \approx 82,6 \%$), le bloc de référence était réduit à environ 376 jetons.
  • Les chutes de performance ont été significatives : Gemini (-34,1 points), Haiku (-30,6 points) et GPT (-14,7 points).
• Interprétation : Le « cliff » est piloté par la réduction physique de l'évidence de la tâche, et non simplement par la présence de texte de coordination.

3.2 Mise à l'échelle de la fenêtre (Window Scaling)

• Le point de transition (où la performance chute) ne s'est pas produit à un pourcentage fixe de la fenêtre de contexte à travers différentes tailles de fenêtre ($W=4096$ vs $W=8192$ vs $W=16384$).
• Au lieu de cela, la chute était corrélée au budget de tâche résiduel (le nombre absolu de jetons restants pour la tâche). Par exemple, $W=8192$ pouvait supporter une part de coordination plus élevée ($p=86,3 \%$) tout en laissant plus de jetons de référence (786) que $W=4096$ à une part inférieure, entraînant moins de dégradation.
• Cela soutient une interprétation par le « budget de tâche résiduel » plutôt que par un seuil de pourcentage fixe.

3.3 Ablation de la tâche intacte

• Lorsque le bloc tâche/référence complet était maintenu intact et que la longueur totale du prompt était autorisée à croître (supprimant l'effet de troncation), aucune dégradation de type « cliff » n'a été observée sur l'ensemble des modèles et ratios de coordination testés (jusqu'à 95 % de coordination).
• Tous les modèles ont atteint 100 % de réussite dans l'extraction de champs dans cette configuration.
• Implication : Le « cliff » principal du RCWT est mieux interprété comme un déplacement du budget de tâche (troncation de l'évidence) plutôt que comme une preuve d'une interférence sémantique majeure dans les tâches d'extraction.

3.4 Tâches limites

• Les tâches autonomes sont restées stables quel que soit l'overhead de coordination, confirmant que l'ajout de texte seul ne dégrade pas la performance dans la plage testée.
• Les packs externes ont montré une sensibilité à la troncation, bien qu'une exception (Claude Haiku 4.5 sur GSM8K) ait montré une dégradation même avant la troncation complète, suggérant des nuances propres à chaque tâche.

4. Contributions et affirmations

Le papier apporte les contributions et affirmations spécifiques suivantes :

1. Un protocole contrôlé : Le RCWT fournit une méthode pour isoler et mesurer le coût en jetons de la coordination dans les appels LLM, en séparant cela des dynamiques complexes multi-agents.
2. Déplacement vs Interférence : La conclusion principale est que les chutes de performance dans les environnements à budget fixe sont largement dues à la troncation physique de l'évidence de la tâche. Le papier stipule explicitement que l'ablation de la tâche intacte fournit des preuves contre un effet d'interférence sémantique important dans les tâches de type extraction, affinant ainsi la thèse selon laquelle « la coordination nuit au raisonnement ».
3. Interprétation du budget résiduel : Le point de transition de la dégradation de performance est mieux décrit par la taille absolue du budget de tâche résiduel ($\theta$) plutôt que par un pourcentage fixe de la fenêtre de contexte totale.
4. Implication d'ingénierie : Le papier soutient que les systèmes pratiques devraient budgéter le contenu de coordination par rapport aux besoins résiduels spécifiques à la tâche. Les ingénieurs ne doivent pas se fier uniquement aux tailles nominales de fenêtre de contexte ou à la longueur totale du prompt, mais doivent s'assurer que le bloc de tâche conserve suffisamment de jetons.
5. Limitation de portée : Les auteurs précisent explicitement que le RCWT mesure le côté coût de la coordination (déplacement de jetons) et ne mesure pas le bénéfice net (ex. : amélioration de la qualité via la décomposition ou la vérification). Le papier ne prétend pas que la coordination est intrinsèquement mauvaise, mais qu'elle consomme une ressource finie qui doit être prise en compte.

5. Limites et mises en garde

• Spécificité de la tâche : Les principaux résultats découlent d'une tâche de rappel de spécifications techniques. Bien que les packs limites élargissent la couverture, les courbes ajustées sont des résumés descriptifs et non des lois universelles.
• Ordre de troncation : Dans la tâche principale, les faits sont supprimés selon un ordre fixe (troncation par le préfixe), ce qui signifie que le point milieu ajusté reflète en partie la disposition de la référence plutôt qu'une constante intrinsèque à la tâche.
• Variance de l'évaluation : La tâche principale utilise un juge LLM, ce qui introduit un biais potentiel de sévérité, bien que l'ablation de la tâche intacte ait utilisé un scoring JSON déterministe pour atténuer cela.
• Hétérogénéité de la coordination : Le contenu de coordination était synthétique et structuré. La coordination réelle (sorties d'outils denses, affirmations contradictoires, transcriptions verbeuses) pourrait se comporter différemment.
• Comptabilité des jetons : L'étude a utilisé un tokenizer standard ($cl100\_base$) pour la construction, mais s'est appuyée sur les comptes rapportés par les fournisseurs pour la vérification finale, reconnaissant les écarts potentiels de tokenisation native.

6. Conclusion

Le RCWT établit que dans les systèmes multi-agents et augmentés par la mémoire, le contenu de coordination n'est pas gratuit sous des budgets de contexte fixes. Le risque principal est le déplacement du budget de tâche, où les jetons de coordination tronquent physiquement l'évidence requise pour la tâche, entraînant une chute brutale de performance dès que le bloc de tâche résiduel tombe sous un seuil critique. Le papier conclut que le « cliff » observé dans les expériences à budget fixe est le résultat d'une perte d'évidence plutôt que d'une loi générale d'interférence sémantique. La conception de systèmes pratiques doit donc donner la priorité au suivi et à la préservation du budget de tâche résiduel plutôt qu'à la seule longueur totale du prompt ou à la taille nominale de la fenêtre de contexte.