Mesurer un long contexte¶

Pokee annonce 93,3 sur RULER à 10 M de tokens. Pour savoir ce que ce chiffre vaut, il faut savoir ce que RULER mesure — et ce qu'il ne mesure pas.

L'aiguille dans la botte de foin¶

Le test historique du contexte long : on insère une phrase artificielle (l'« aiguille ») dans un long texte de remplissage (la « botte de foin »), puis on pose une question dont la réponse est cette phrase.

Erreur fréquente

Ce test est beaucoup trop facile. L'aiguille est sémantiquement étrangère au reste : le modèle n'a pas besoin de comprendre, il lui suffit de repérer la seule phrase qui détonne. Un score de 100 % à ce test ne dit presque rien.

Ce n'est pas une critique théorique : c'est la seule preuve que Meta a publiée pour justifier les 10 M de tokens de Llama 4 Scout — un modèle qui obtiendra ensuite 15,6 % sur un test de compréhension à 128 K. Voir chapitre 05.

RULER¶

RULER (NVIDIA, 2024) répond à cette critique en généralisant le test à plusieurs catégories de difficulté croissante :

Catégorie	Ce qui est demandé
Retrieval	Retrouver 1 aiguille
Multi-key / multi-value	Plusieurs aiguilles, plusieurs distracteurs
Multi-hop tracing	Suivre une chaîne de variables (`a = b`, `b = c`, …) sur toute la longueur
Aggregation	Compter, extraire les mots les plus fréquents sur tout le contexte
Question answering	Répondre à une vraie question noyée dans du bruit

Le score est un pourcentage moyen sur les tâches, à une longueur donnée. L'usage est de reporter la longueur à laquelle le modèle passe encore sous un seuil (souvent 85 %) — la « longueur effective ».

Ce que RULER apporte : les catégories tracing et aggregation exigent de traverser réellement le contexte, ce qu'une fenêtre glissante ne peut pas faire. Un modèle purement local échoue.

Ce que RULER ne fait pas :

Trois limites décisives à 10 M

RULER n'est pas défini à 10 M de tokens. Les configurations publiées s'arrêtent bien plus bas. Aller à 10 M suppose de fabriquer soi-même la botte de foin — et la nature du remplissage change tout. Un remplissage répétitif ou synthétique rend la tâche beaucoup plus facile qu'un remplissage de documents naturels variés.
Le contenu reste synthétique. Retrouver une clé UUID n'a pas la même difficulté que raisonner sur des faits contradictoires disséminés.
La densité d'information est faible. Dans une botte de foin, presque tout est ignorable. Dans un vrai code source de 10 M de tokens, presque rien ne l'est.

Le score de 93,3 à 10 M est donc crédible techniquement et peu informatif pratiquement, tant que le protocole exact n'est pas publié.

MRCR¶

MRCR (Multi-Round Co-reference Resolution, Google DeepMind) est nettement plus dur : une longue conversation contient plusieurs demandes très similaires (« écris un poème sur les licornes », puis plus loin « écris un poème sur les dragons », etc.), et on demande de restituer la \(i\)-ème occurrence d'un type de réponse. Le modèle doit distinguer des éléments quasi identiques, ce que la similarité sémantique ne permet pas.

Le score d'Isaac est révélateur :

Benchmark	Longueur	Score
RULER	512 K	96,7
MRCR v2	512 K	74,3

À retenir

Un écart de plus de 22 points à longueur identique. Ce n'est pas une anomalie : c'est la différence normale entre « retrouver une aiguille » et « distinguer des aiguilles presque identiques ». Toujours regarder le benchmark le plus dur.

Les benchmarks agentiques¶

Isaac est vendu comme un modèle d'agent, d'où trois autres familles de mesures.

Benchmark	Ce qui est mesuré
BFCL v4 (Berkeley Function-Calling Leaderboard)	Justesse de l'appel d'outils : bonne fonction, bons arguments, bons types
τ³-bench	Conversations multi-tours avec outils, dans plusieurs domaines simulés
Terminal-Bench 2.1	Tâches réelles dans un terminal Linux, vérifiées par exécution
MCP-Atlas	Usage d'outils via le protocole MCP
DTAP	Résistance aux attaques : plus le score est bas, mieux c'est

Terminal-Bench est le plus significatif : il est vérifié par exécution, donc non « devinable ». Isaac y obtient 65,1 %, deuxième de son panel — un bon score pour un modèle de 28 milliards de paramètres, sans être une domination.

Comment lire un tableau de benchmarks de constructeur¶

Cinq réflexes, applicables ici comme partout :

Qui a mesuré ? Ici : Pokee, pour tous les chiffres, y compris ceux des concurrents. Un constructeur mesure toujours mieux son propre modèle, ne serait-ce que parce qu'il connaît ses réglages optimaux.
Quel panel ? Isaac est comparé à GPT-5.6 Luna, Gemini 3.5 Flash Lite, Claude Haiku 4.5, Nemotron 3 Super, Qwen 3.5 122B — c'est-à-dire à la classe économique, pas aux modèles phares.
Qu'est-ce qui manque ? Chez Isaac : connaissances générales, mathématiques, multilingue, suivi d'instructions, multimodal. Aucune donnée. BenchLM note d'ailleurs qu'il « ne se qualifie pas pour un classement général public » faute de couverture.
Un zéro est-il un échec ou un refus ? Voir évaluations/02 : les « 0,0 au-delà de 2 M » des concurrents sont, pour l'essentiel, des modèles qui n'acceptent pas l'entrée.
Est-ce reproductible ? Sans poids ouverts, sans protocole publié et sans accès aux mêmes conditions, non.

Résumé des fondations

Vous savez maintenant : ce qu'est une fenêtre de contexte, que son coût se décompose en mémoire (linéaire, mur absolu) et calcul (quadratique pour l'attention, linéaire pour le reste), quelles cinq familles d'architectures attaquent ces murs et à quel prix, et comment lire un score de contexte long.

La partie Architecture applique tout cela aux trois chiffres publiés par Pokee.