VELC-Bench: Vérification sur le benchmark de contexte long
La capacité du modèle à localiser une métrique spécifique dans le contexte, à comparer sa valeur à une affirmation, et à la confirmer ou la rejeter. Cela teste la correspondance fine des valeurs dans des conditions de contexte long. Le modèle doit à la fois récupérer la valeur et effectuer une comparaison précise.
Résultats
Les modèles sont testés dans les fenêtres de contexte suivantes :
- anthropic/claude-fable-5 : 850 000 tokens testés
- openai/gpt-5.5 : 1 000 000 tokens
- google/gemini-3.1-pro-preview : 1 000 000 tokens
- google/gemini-3.5-flash : 1 000 000 tokens
- anthropic/claude-sonnet-4.6 : 1 000 000 tokens
- qwen/qwen3.6-plus : 1 000 000 tokens
- moonshotai/kimi-k2.6 : 200 000 tokens
- z-ai/glm-5.1 : 200 000 tokens
- minimax/minimax-m2.7 : 150 000 tokens
- openai/gpt-5.4-mini : 250 000 tokens
claude-fable-5 obtient 90.0 % sur verify YES et 94.0 % sur verify NO. L'écart correspond à l'asymétrie décrite ci-dessous : confirmer une valeur nécessite de la trouver, tandis que la rejeter ne demande que de repérer une discordance.
Question formats
Verify YES (la valeur de l'affirmation est correcte) :
Affirmation : Le chiffre d'affaires pour le T1 2026 d'Adobe (ADBE) est de $6.40 milliards.
Attendu : YES
Verify NO (la valeur de l'affirmation est incorrecte) :
Affirmation : Le chiffre d'affaires pour le T1 2026 d'Adobe (ADBE) est de $7.92 milliards.
Attendu : NO
Source des données
Mêmes métriques extraites de TAKEAWAYS que le rappel direct. Pour chaque métrique choisie :
- Verify YES éléments utilisent la valeur réelle de la transcription
- Verify NO éléments utilisent une valeur perturbée de manière programmatique (écart de 8–25 %, dans un sens ou dans l'autre, avec précision et unités correspondantes)
Règle de notation
Détection à trois états sur la réponse du modèle :
- Si la réponse contient une phrase NON MENTIONNÉE (par exemple, « not mentioned », « not discussed ») → predicted =
not_mentioned - Sinon, si elle contient « yes » → predicted =
yes - Sinon, si elle contient « no » → predicted =
no
Score = 1.0 si predicted == expected, sinon 0.0.
La priorité de détection est NON MENTIONNÉ > NO > YES pour éviter que « not mentioned » ne corresponde accidentellement à « no » via la sous-chaîne « not ».
claude-fable-5 est testé via Claude Code : il reçoit le haystack de 850 000 tokens sous forme de fichier et le recherche avec des outils de récupération au lieu de le lire depuis sa fenêtre de contexte, de sorte que ses scores mesurent le modèle conjointement avec le harnais de Claude Code.
Claude Sonnet 5 a été lancé le 30 juin 2026 avec une fenêtre native de 1M tokens à tarification standard, et Claude Opus 4.8 a la même fenêtre de 1M ; tous deux font désormais partie de cet ensemble de test.1
Deux modèles open-weight intégralement entraînés sur du matériel non-Nvidia sont également entrés dans le domaine du contexte long la même semaine : LongCat-2.0 de Meituan, un modèle MoE de 1.6T paramètres avec une fenêtre native de 1M tokens construit sur des accélérateurs IA chinois, et openPangu-2.0-Flash de Huawei, un modèle MoE de 92B paramètres avec une fenêtre de 512K entraîné sur des puces Ascend.2
Interprétation phase par phase
L'asymétrie entre YES et NO est informative : YES exige une identification positive d'une valeur (plus difficile lorsque la cible est plus profonde), tandis que NO ne nécessite que de repérer une discordance (plus facile lorsqu'elle a été lue récemment).
Les phases sont 0.1, 0.5 et 0.9 de la fenêtre de contexte, pour voir la différence de précision à différentes positions dans le haystack.
Qu'est-ce qu'une bonne performance ?
Phase 2 YES ≥ 80 % et NO ≥ 80 % indique que le modèle peut à la fois confirmer et rejeter à travers un haystack.
Un modèle qui obtient un score très élevé en NO mais faible en YES est biaisé vers le rejet. Un modèle qui obtient un score très élevé en YES mais faible en NO fait trop confiance aux affirmations.
Nombre d'éléments
50 verify_yes + 50 verify_no = 100 éléments de vérification.
Qu'est-ce qu'une fenêtre de contexte ?
Anthropic’s documentation technique propose la définition canonique : la fenêtre de contexte est « tout le texte auquel un modèle de langage peut se référer lorsqu'il génère une réponse, y compris la réponse elle-même », la distinguant du corpus d'entraînement plus vaste et proxy plutôt une « mémoire de travail » pour le modèle.3 IBM la définit en termes quasi identiques comme la quantité de texte, en tokens, que le modèle peut prendre en compte ou « mémoriser » à tout moment.4 McKinsey présente le concept comme comparable à la mémoire à court terme humaine, notant que le modèle ne peut « regarder » qu'une quantité fixe d'informations à la fois avant de les combiner avec des paramètres pré-entraînés pour produire une réponse.5
L'unité de mesure est le token. La documentation développeur d'OpenAI indique qu'un token correspond à environ 4 caractères ou 0.75 mot pour le texte anglais, bien que le ratio varie selon la langue et le contenu.6 IBM décrit un token comme la plus petite unité utilisée par les modèles d'IA linguistique, une représentation lisible par machine d'un mot, d'une partie de mot ou d'une ponctuation.4
La fenêtre couvre l'invite système, chaque message y compris les résultats d'outils et les documents, et la sortie générée combinés. Anthropic’s documentation indique explicitement que « la sortie que Claude génère pour le tour, y compris sa réflexion étendue, compte également ».3 OpenAI confirme que pour les modèles de génération de texte, l'invite et la sortie générée combinées ne doivent pas dépasser la longueur maximale de contexte.6
La taille de la fenêtre de contexte est une propriété architecturale fixe définie au moment de l'entraînement, pas un paramètre réglable par l'utilisateur. La documentation du cours LLM de Hugging Face note que les architectures Transformer de base sans modifications pour contexte étendu sont limitées à une longueur de séquence maximale fixe et planteront ou tronqueront l'entrée lorsque cette longueur est dépassée, bien que des techniques spécialisées permettent désormais à certains modèles déployés de gérer des séquences beaucoup plus longues.7 Un modèle ne peut pas recevoir une fenêtre de contexte plus grande après le déploiement sans réentraînement ou techniques d'extension spécialisées.
Fenêtre de contexte vs termes apparentés
« Context length » fonctionne comme un synonyme direct de « context window », et non comme un concept distinct. IBM présente les deux termes ensemble, indiquant que la « context window (ou « context length ») » est la quantité de texte que le modèle peut prendre en compte à tout moment.4 OpenAI utilise « maximum context length » pour décrire le même plafond combiné invite-plus-sortie.6
La limite de tokens de sortie est un terme distinct et plus étroit. OpenAI l'expose comme un paramètre distinct (comme `max_tokens`) qui ne plafonne que la partie générée de la réponse, tandis que la fenêtre de contexte contraint le total de l'entrée plus la sortie.6
La fenêtre de contexte est distincte de la mémoire persistante ou agentique entre sessions. Anthropic’s documentation pour son outil de mémoire précise que la fenêtre de contexte est éphémère et liée à la session : « Votre fenêtre de contexte peut être réinitialisée à tout moment, vous risquez donc de perdre toute progression qui n'est pas enregistrée dans votre répertoire mémoire. »8 La mémoire persistante, en revanche, stocke des informations dans des fichiers externes qui survivent entre les sessions.8
Enfin, la fenêtre de contexte n'est pas le corpus de données sur lequel le modèle a été entraîné. Anthropic’s documentation trace cette ligne explicitement : la fenêtre de contexte « est différente du vaste corpus de données sur lequel le modèle de langage a été entraîné, et représente plutôt une « mémoire de travail » pour le modèle. »3
Comment fonctionne une fenêtre de contexte ?
Avant le traitement, le texte brut est converti en tokens par tokenisation. La méthode dominante est le byte pair encoding (BPE), à l'origine un algorithme de compression de données de 1994 adapté à la traduction automatique neuronale en 2016, qui construit un vocabulaire en fusionnant itérativement les séquences de caractères co-occurrentes les plus fréquentes.9 BPE alimente les tokenizers de GPT-2, GPT-3, GPT-4 et LLaMA, entre autres.9 OpenAI note que la tokenisation est sensible au contexte ; le même mot peut correspondre à différents tokens selon la capitalisation ou les espaces environnants.10
Une fois tokenisé, chaque token est converti en vecteur et traité via l'architecture transformer introduite dans l'article de 2017 « Attention Is All You Need ».11 Le mécanisme central, l'auto-attention, calcule les vecteurs Query, Key et Value pour chaque token, puis utilise l'attention à produit scalaire mis à l'échelle de sorte que chaque token prête attention à tous les autres tokens de la séquence, y compris lui-même.11 Cette comparaison parallèle de toutes les paires de tokens permet aux transformers de remplacer le traitement séquentiel des architectures récurrentes antérieures.
Lors de la génération autorégressive, le modèle produit un token à la fois. Chaque étape d'auto-attention d'un nouveau token nécessite les vecteurs Key et Value de tous les tokens précédents. Plutôt que de les recalculer à partir de zéro à chaque étape, les LLMs de production les stockent après le premier calcul et les réutilisent ; cet ensemble stocké est appelé le cache KV.12 En réutilisant les matrices Key et Value mises en cache, la complexité de l'inférence par étape diminue, bien que l'empreinte mémoire du cache croisse linéairement avec la longueur du contexte et doive résider dans la mémoire GPU pendant toute la durée de la requête.12
Les tokens en dehors de la fenêtre sont architecturalement invisibles. Parce que l'auto-attention ne calcule que les relations entre les tokens présents dans le tenseur d'entrée actuel, et que le cache KV ne stocke que les vecteurs des tokens qui ont été fournis au modèle, un token jamais inclus dans la requête n'a aucune représentation à laquelle le modèle peut se référer.11 C'est pourquoi le dépassement de la fenêtre de contexte déclenche une défaillance API dure ; l'API d'Anthropic renvoie un code 400 `invalid_request_error` si l'entrée seule dépasse la limite, et la génération s'arrête avec une raison d'arrêt `model_context_window_exceeded` si la sortie pousserait le total au-delà du plafond.3
Tailles de fenêtre de contexte des principaux modèles d'IA
À la mi-2026, la valeur par défaut des API de pointe s'est stabilisée à environ 1 million de tokens, bien que la limite effective varie selon la surface d'accès.
La famille GPT-5.6 d'OpenAI (Sol, Terra et Luna) offre une fenêtre de contexte de 1.05 million de tokens et une sortie maximale de 128 000 tokens via l'API.13 Cependant, l'interface grand public ChatGPT offre moins : lorsque l'utilisateur sélectionne manuellement le mode « Thinking », la fenêtre combinée est de 256 000 tokens (128 000 en entrée plus 128 000 en sortie maximale).14
Les modèles Claude Opus 5 et Sonnet 5 d'Anthropic offrent une fenêtre de 1 million de tokens via l'API Claude et sur Amazon Bedrock, Google Cloud et Microsoft Foundry.3
Le Gemini 3.5 Flash de Google prend en charge une fenêtre de contexte d'entrée de 1 million de tokens avec jusqu'à 65 536 tokens de sortie.15 Les affirmations selon lesquelles le Gemini 3.5 Pro plus récent atteint 2 millions de tokens n'ont pas pu être vérifiées par rapport à la documentation principale de Google au moment de la rédaction.
Le Grok 4.3 de xAI, lancé le 30 avril 2026, possède une fenêtre de contexte de 1 million de tokens.16 Le Llama 4 Scout de Meta annonce une fenêtre de contexte de 10 millions de tokens atteinte via une architecture iRoPE, bien que le modèle n'ait été pré-entraîné que jusqu'à 256 000 tokens, ce qui signifie que le chiffre de 10 millions représente une capacité extrapolée.17
Mistral Large 3 reste plafonné à 256 000 tokens, une exception parmi les modèles de pointe.18 DeepSeek-V4 est livré en deux variantes prenant en charge 1 million de tokens, obtenues grâce à un mécanisme d'attention efficace.19
Ajouter comme source préféréeFenêtres de contexte longues vs génération augmentée par récupération
Le choix entre empiler des tokens dans une fenêtre de contexte longue plutôt que d'utiliser la génération augmentée par récupération (RAG) dépend de la taille du corpus et de la fréquence de mise à jour. Les conseils d'ingénierie d'Anthropic indiquent que si une base de connaissances est inférieure à 200 000 tokens (environ 500 pages), l'intégralité du corpus peut être incluse dans l'invite, ce qui, avec la mise en cache des invites, devient « significativement plus rapide et plus rentable ». Une fois que le corpus dépasse ce seuil, une solution plus évolutive est nécessaire.20
IA agentique et tâches de longue durée
Les agents de codage et de recherche comptent sur la taille de la fenêtre de contexte pour conserver les résultats d'outils accumulés et l'historique des conversations. L'équipe d'ingénierie d'Anthropic documente la gestion du contexte comme la contrainte centrale pour les tâches à long horizon, recommandant un contexte « just-in-time » où les agents conservent des références légères et chargent dynamiquement les données à l'exécution plutôt que de tout charger d'avance.21
Claude Code implémente cela via des sous-agents. Dans un exemple documenté, un sous-agent chargé de rechercher une base de code a lu 6 100 tokens de contenu de fichier et a renvoyé un résumé de 420 tokens à la session parente, gardant environ 5 700 tokens de contenu de fichier entièrement hors de la fenêtre de contexte de l'agent principal.22 La fenêtre de contexte par défaut de Claude Code pour Sonnet 5 est de 1 million de tokens sur l'API d'Anthropic, avec compactage automatique par défaut à environ 967 000 tokens, soit environ 96.7 % de cette limite, à moins qu'une configuration ne plafonne la fenêtre à 200 000 tokens.23
Analyse de documents et de bases de code
La documentation de l'API Gemini de Google indique que sa fenêtre de contexte de 1 million de tokens équivaut à environ 50 000 lignes de code, illustrant l'échelle d'une seule fenêtre de contexte plutôt que décrivant un cas d'utilisation dédié à la revue de base de code.24
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Alper, Şevval},
title = {{VELC-Bench: Vérification sur le benchmark de contexte long}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/ai-context-window}},
note = {AIMultiple. Consulté le 4 Août 2026}
}Liens de référence
Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes, Washington Post, des entreprises mondiales comme Deloitte, HPE et des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne.
Tout au long de sa carrière, Cem a exercé en tant que consultant tech, acheteur tech et entrepreneur tech. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus d'une décennie. Il a également publié un rapport McKinsey sur la numérisation.
Il a dirigé la stratégie technologique et les achats d'un opérateur télécom tout en rendant compte au PDG. Il a également mené la croissance commerciale de l'entreprise deep tech Hypatos qui a atteint un chiffre d'affaires récurrent annuel à 7 chiffres et une valorisation à 9 chiffres à partir de 0 en 2 ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.
Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de la Bogazici University en tant qu'ingénieur informatique et détient un MBA de la Columbia Business School.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.