Fiche concept

Mécanique de la Fenêtre de Contexte

À jour au 2026-07-23

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Mécanique de la Fenêtre de Contexte ?

Doubler la longueur de contexte quadruple le calcul d'attention (O(n²)) et peut pousser le cache KV d'une seule requête sur un modèle 70B à ~42 Go à 128K tokens — avant même les poids du modèle — faisant du contexte long une décision de budget matériel, pas un simple réglage gratuit.

De quoi il s'agit

La fenêtre de contexte est le nombre maximum de tokens qu'un LLM peut traiter simultanément en une seule passe avant. Elle détermine quelle information le modèle peut « voir » lors de la génération de chaque token de sortie et conditionne si une charge de travail peut être traitée en un seul appel ou nécessite des stratégies de découpage comme RAG ou le chevauchement par fenêtre glissante.

Le problème qu'elle adresse est que les documents d'entreprise utiles — fichiers de classes ABAP SAP, contrats d'approvisionnement, rapports annuels — dépassent régulièrement 8 000 tokens, si bien qu'une troncature naïve perd du contexte critique et qu'une concaténation naïve dépasse la capacité du modèle. Pour les consultants SAP analytics, cela a des implications directes : un agent Joule raisonnant sur un historique complet de maintenance d'usine (potentiellement 200+ pages d'ordres de service) ou un pipeline BDC ingérant des tables SAP HANA complètes via Datasphere doit gérer des volumes qui mettent à l'épreuve même les modèles à 128K tokens.

Pourquoi c'est important

FlashAttention-2 est ce qui rend l'inférence à 128K praticable : elle plafonne la mémoire d'activation à O(n) au lieu de O(n²) via un calcul en mosaïque dans le SRAM.
« Lost in the middle » : la précision de récupération chute d'environ 95 % en bord de contexte à ~60 % au milieu à 100K tokens — un contexte long ne garantit pas une qualité d'attention uniforme, un risque réel pour les cas d'usage Joule à forte densité documentaire.
Directement pertinent pour SAP : les historiques complets de maintenance d'usine (200+ pages) ou l'ingestion complète de tables HANA via Datasphere mettent à l'épreuve même les modèles à 128K tokens.

Points clés

Formule mémoire du KV cache : 2 × n_layers × n_kv_heads × d_head × seq_len × batch × dtype_bytes — chaque champ d'entrée est une variable qu'un architecte doit dimensionner pour le modèle cible et la longueur de séquence.
Llama 3.3 70B à 128K tokens, batch=1, BF16 : ~42 GB de KV cache à lui seul, nécessitant au moins deux GPU H100 80 GB avant même de compter les 140 GB de poids du modèle.
« Lost in the middle » (Liu et al. 2023) : la précision de récupération chute de ~95% aux bords du contexte à ~60% pour les éléments situés au milieu d'un contexte de 100K tokens — positionner les faits les plus critiques au début ou à la fin du prompt.
FlashAttention-2 réduit la mémoire d'activation de O(n²) à O(n) en découpant le calcul d'attention en tuiles dans la SRAM — la technologie qui rend possible l'inférence pratique à 128K sur le matériel actuel.
YaRN étend un modèle RoPE entraîné de son contexte d'entraînement vers un contexte d'inférence plus large (Llama 3.1 : 128K → 1M) avec une hausse de perplexité <5% en réajustant les valeurs θ de RoPE par interpolation NTK.
Le θ_base de RoPE contrôle la longueur de contexte effective : θ=10,000 (original) → ~4K effectif ; θ=500,000 (Llama 3.3) → 128K effectif — lors de l'évaluation de la longueur de contexte annoncée d'un modèle, confirmer le θ_base utilisé à l'entraînement.
Pour SAP BDC : le pattern hybride RAG + long contexte est l'architecture standard — le RAG restreint l'ensemble candidat à moins de 32K tokens, le modèle à long contexte raisonne sur l'ensemble réduit pour une cohérence globale.
SAP Joule utilise un modèle à long contexte hébergé via SAP AI Core ; le contexte effectif disponible pour un prompt d'agent Joule est réduit par le system prompt, la charge des appels d'outils et l'historique de conversation — prévoir 30–40% de la fenêtre de contexte annoncée pour du contenu non-utilisateur.
Stratégies de chunking pour les documents dépassant la fenêtre de contexte : chevauchement à taille fixe (la plus simple, perd les entités inter-chunks), chunking sémantique (découpe aux frontières de paragraphe/section), chunking hiérarchique (résumé au niveau supérieur, détail à la récupération) — la bonne stratégie dépend de la présence de sections sémantiques claires dans le document.
Implication de coût : l'inférence à long contexte est nettement plus coûteuse que le contexte court — les appels à 128K tokens coûtent typiquement 8–16× plus par appel que les appels à 8K tokens au même palier de modèle ; concevoir les workflows pour éviter les appels à long contexte inutiles.

Termes employés sur cette page

Context window: Le nombre maximal de tokens qu'un LLM traite en une passe avant ; il détermine l'horizon d'information pour la génération et fixe le choix d'architecture entre appel unique et stratégies de chunking.
KV cache: Matrices de clés et de valeurs stockées de toutes les positions antérieures de la séquence, permettant une génération incrémentale de token en O(1) sans recalculer l'attention passée — le principal coût mémoire de l'inférence en contexte long.
FlashAttention-2: Algorithme d'attention conscient des E/S (Dao 2023) qui tuile le calcul pour rester en SRAM, réduisant les lectures HBM et la mémoire d'activations de O(n²) à O(n) ; la technologie clé de l'inférence 128K en pratique sur A100/H100.
Lost in the middle: Constat empirique (Liu et al. 2023) selon lequel la précision de récupération d'un LLM chute d'environ 95 % aux extrémités d'un contexte long à environ 60 % en son milieu — l'information critique doit être placée au début ou à la fin du prompt.
YaRN: Yet another RoPE extensioN (Peng 2023) : fine-tuning à échelle NTK qui étend la fenêtre de contexte effective d'un modèle RoPE entraîné au-delà de sa longueur d'entraînement, avec moins de 5 % d'augmentation de perplexité.
RoPE θ_base: Paramètre de fréquence de base dans le Rotary Position Embedding contrôlant la vitesse de rotation des vecteurs Q/K ; un θ_base plus élevé (500 000 dans Llama 3.3) permet un contexte effectif plus long avant que l'information de position ne boucle.
Semantic chunking: Stratégie de chunking qui découpe les documents aux frontières sémantiques naturelles (paragraphes, sections, titres) plutôt qu'à un nombre fixe de tokens — préserve la cohérence inter-phrases au prix de tailles de chunks variables.
Hierarchical chunking: Stratégie de chunking qui stocke des résumés de document à un niveau supérieur et des passages détaillés à un niveau enfant ; la récupération trouve d'abord le résumé pertinent, puis récupère le passage de détail associé — réduit les appels superflus en contexte long.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.

Ouvrir dans l'application →