Long-context strategies (1 M tokens — Opus 5 / Sonnet 5)

Pourquoi ce module

Claude Opus 5 (défaut Opus depuis le 24 juillet 2026, 1M de contexte au tarif inchangé de 5 $/25 $) — et depuis le 30 juin 2026 Claude Sonnet 5, contexte 1M natif à 2 $/10 $ par Mtok en promo — offrent un plafond de contexte de 1 million de tokens au tarif standard (sans premium long-contexte). Pour la première fois, vous pouvez analyser un dossier juridique complet, scanner une codebase entière, ou extraire de l'information d'une centaine d'articles en une seule requête — et Sonnet 5 divise par ~2,5 le ticket d'entrée du long-contexte. Mais cette puissance a un prix : coût par requête (~5–25 USD selon le ratio entrée/sortie), latence initiale (30–90 secondes pour le premier token), et un phénomène redoutable appelé lost-in-the-middle où le modèle prête moins d'attention aux sections centrales.

Pour les équipes documents, legal, recherche, ou analyse de code à grande échelle, 1 million de tokens transforme le ROI. Ce module vous enseigne quand et comment utiliser ce contexte sans exploser le budget, et comment calibrer l'équilibre critique entre grand contexte et RAG (Retrieval-Augmented Generation).

Prérequis : maîtriser la console API Anthropic, avoir une clé API avec les droits Claude Opus (5 ou 4.8 — tarif et fenêtre de contexte identiques), et avoir suivi les modules J1–J2 sur l'optimisation des coûts.

Objectifs pédagogiques

À l'issue de ce module, vous serez capable de :

1. Calculer le coût exact et la latence d'une requête saturant 1 M tokens, et décider si c'est rentable vs RAG
2. Implémenter les trois stratégies de mitigation contre lost-in-the-middle : structuration du contexte, résumés multi-passe, et découpage itératif
3. Coder un pipeline hybride : déterminer automatiquement si un document doit être traité en contexte long ou décomposé en chunks et indexé
4. Analyser 500 pages de PDF (juridique, code, recherche) en une passe et extraire des faits structurés fiables
5. Mesurer la qualité des synthèses long-contexte et comprendre les pièges (hallucinations positionnelles, omissions en milieu de document)

Plan détaillé

1. Coût et latence à 1 M tokens — règle de trois
2. Position bias : lost-in-the-middle et mitigation
3. Stratégies hybrides : grand contexte vs RAG
4. Arbre de décision : quand charger tout
5. Chunking sémantique vs sliding window
6. Hierarchical summarization en 3 passes
7. Cas pratique : 500 pages PDF juridique
8. Outil : vérifier les token counts réels
9. Atelier : pipeline de classification document
10. Pièges courants et comment les éviter

Coût et latence à 1 M tokens

La facturation Anthropic pour Opus (5 comme 4.8, même grille) est simple :

Input tokens   : 5 USD / 1 M tokens
Output tokens  : 25 USD / 1 M tokens

Exemple concret : vous chargez un dossier juridique de 800 K tokens en entrée et recevez 10 K tokens de réponse.

Coût input   = (800 000 / 1 000 000) × 5  = 4,00 USD
Coût output  = (10 000 / 1 000 000) × 25 = 0,25 USD
Coût total   = 4,25 USD par requête

Latence : la première completion token arrive typiquement en 30–90 secondes pour une requête long-contexte. Le débit est ensuite normal (~40–60 tokens/sec). Cela signifie :

• Une analyse synchrone bloque votre utilisateur 1–2 minutes
• Les appels parallel sub-agents deviennent critiques
• Le caching de réponses devient un ROI énorme

Règle d'or : si vous comptez faire la même analyse >3 fois, le RAG est plus rentable. Si vous l'appliquez 1–2 fois ou si le contexte change tout le temps, long-contexte gagne.

Position bias : lost-in-the-middle

Les transformers prêtent plus d'attention aux extrémités d'une séquence qu'au milieu. Dans un contexte de 1 M tokens, cet effet est mesuré et significatif.

Ordre de grandeur observé (les transformers prêtent davantage attention aux extrémités ; effet documenté par Liu et al., 2023, Lost in the Middle) :

• Information en début de contexte : précision d'extraction élevée
• Information au milieu : précision sensiblement dégradée
• Information en fin : précision élevée

Les chiffres exacts dépendent du modèle, de la longueur et de la tâche — mesurez sur vos propres données plutôt que de vous fier à des pourcentages génériques.

🌫️ « Context rot » : remplir ≠ aider. Au-delà du lost-in-the-middle, la précision et le rappel se dégradent à mesure que la fenêtre se remplit, même bien en-dessous de la limite (Anthropic nomme ce phénomène context rot). Conséquence pratique : entasser « 50 fichiers » ou une conversation interminable rend Claude moins performant, pas plus intelligent — ce qui compte est le volume de tokens pertinents, pas leur nombre. En Claude Code, le réflexe est de garder le contexte propre : @fichier ciblé plutôt que dossier entier, /compact pour résumer sans tout perdre, /clear pour repartir net entre deux tâches sans rapport. La compaction automatique aide, mais arrive après que la dégradation a commencé.

Mitigation n°1 : structure du contexte

Placez toujours les données les plus critiques au début ET à la fin. Exemple avec un dossier juridique :

[En-tête explicite]
# Analyse du contrat ACME-2025

## EXÉCUTIVE SUMMARY (à lire d'abord)
- Risque principal : clause de non-concurrence invalide en Suisse
- Recommandation : redéfinir la clause avant signature

## CONTENU : 400 pages

## CONCLUSIONS ET RECOMMANDATIONS (répétition de summary)
- Même format que en-tête

Mitigation n°2 : hierarchical summarization

Au lieu de charger 800 K tokens en une passe, décomposez en 3 passes :

1. Passe 1 : Charger sections 1–5 (200 K tokens) → générer résumé exécutif (2 K tokens)
2. Passe 2 : Charger sections 6–10 + résumé passe 1 (220 K tokens) → résumé (2 K tokens)
3. Passe 3 : Charger résumés passe 1 + 2 (4 K tokens) → synthèse finale (1 K tokens)

Coût réel : 200 K + 220 K + 4 K = 424 K input tokens = 2,12 USD vs 1 × (800 K) = 4,00 USD. Économie + meilleure qualité car le modèle se concentre sur les résumés clés plutôt que de sursaturer. (La simplification « 3 × 220K ≈ 3,30 USD » était une approximation dépassée.)

Mitigation n°3 : requête avec instruction positionnelle

Dites explicitement au modèle qu'il y a lost-in-the-middle :

You are analyzing a 800K-token document where the middle sections
(pages 200–400) are frequently forgotten by LLMs. Pay special
attention to those sections and reference them explicitly.

Compaction & context editing : tenir dans la fenêtre sans tout recharger

Le grand contexte concerne le volume d'une requête. Pour une session longue (agent, multi-tour) qui frôle le 1M au fil des tours, deux mécanismes serveur évitent de repayer plein pot à chaque échange :

• Compaction (beta, header compact-2026-01-12) : l'API résume automatiquement l'historique ancien quand on approche du seuil (par défaut ~150K tokens). Crucial : réinjectez response.content (blocs de compaction inclus), pas seulement le texte — sinon l'état est perdu.
• Context editing : purge les vieux tool_result / blocs de thinking au-delà de seuils configurables — allège le transcript sans le résumer.

Trois axes distincts à ne pas confondre : grand contexte (ce module) gère le volume d'une requête ; compaction/context editing gèrent la durée d'une session ; RAG (ci-dessous) gère le volume d'un corpus. Les agents long-running combinent souvent les trois + le prompt caching (préfixe stable à 0,1×).

Stratégies hybrides : grand contexte vs RAG

La décision n'est pas binaire. Voici comment choisir entre contexte long et RAG :

        Documents accessibles ?
            ↙           ↘
          OUI           NON
           ↓              ↓
     Changent souvent ?   → Contexte long obligatoire
        ↙        ↘
       OUI       NON
        ↓         ↓
       RAG     Contexte
              long ou cache

Cas 1 : Contexte long

• Dossier juridique annuel immuable
• Codebase complète d'un projet fermé
• Jurisprudence pour une affaire (données récapitulées à chaque analyse)
• PDF de recherche qui demande une analyse exhaustive une seule fois

Cas 2 : RAG

• Base de connaissances vivante (CRM, wiki, logs en temps réel)
• Multi-tenant (chaque client a sa doc, pas économique de tout charger)
• Questions variées sur un même corpus
• Données trop volumineuses pour tout charger économiquement

Cas 3 : Hybride

• Index de petits chunks (~2 K tokens) + contexte long pour les chunks pertinents
• Caching prompt pour les sections stables + contexte frais pour les déltas
• Exemple : Contrôleur de gestion accédant à 5 ans d'audits (cache) + données du trimestre courant (contexte)

Arbre de décision : quand charger tout

Avant de chargé 500 pages, répondez à ces questions :

Chunking sémantique vs sliding window

Quand vous décomposez un grand document (même pour RAG), deux stratégies :

Strategy A : Sliding Window (bête)

chunks = []
window_size = 2000  # 2K tokens
overlap = 200       # 200 tokens chevauchement

for i in range(0, total_tokens, window_size - overlap):
    chunk = doc[i : i + window_size]
    chunks.append(chunk)

✅ Garanti pas de perte d'information
❌ Crée des chunks peu cohérents (milieu de phrase, contexte fragmenté)

Strategy B : Sémantique (intelligent)

Utiliser Claude Sonnet pour découper selon les thèmes, sections logiques :

Prompt → Claude : "Split this 800K doc into max 15 chapters,
each <= 10K tokens, preserving semantic coherence.
Respond with chapter boundaries (page numbers) only."

✅ Chunks thématiques, cohérents
❌ Risque micro-omission entre chapitres
✅ RAG récupère mieux

Hierarchical summarization en 3 passes

Voici le code TypeScript complet pour l'approche 3 passes :

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function hierarchicalSummarize(fullDocument: string) {
  const sections = splitIntoSections(fullDocument, 3); // 3 sections égales

  // Passe 1 : Résumer chaque section
  const summaries: string[] = [];
  for (const section of sections) {
    const response = await client.messages.create({
      model: "claude-opus-4-8",
      max_tokens: 2000,
      messages: [
        {
          role: "user",
          content: `Résume cette section en 1500 caractères max, en extrayant les faits clés.\n\n${section}`,
        },
      ],
    });
    summaries.push(
      response.content[0].type === "text" ? response.content[0].text : ""
    );
  }

  // Passe 2 : Fusionner les résumés
  const combinedSummaries = summaries.join("\n\n---\n\n");
  const finalResponse = await client.messages.create({
    model: "claude-opus-4-8",
    max_tokens: 2000,
    messages: [
      {
        role: "user",
        content: `Tu as 3 résumés de sections d'un long document. Fusionne-les en un résumé exécutif unique, 3000 caractères max, qui met en avant les 5 recommandations principales.\n\n${combinedSummaries}`,
      },
    ],
  });

  return finalResponse.content[0].type === "text"
    ? finalResponse.content[0].text
    : "";
}

function splitIntoSections(doc: string, numSections: number): string[] {
  const charsPerSection = Math.ceil(doc.length / numSections);
  const sections = [];
  for (let i = 0; i < numSections; i++) {
    sections.push(
      doc.slice(i * charsPerSection, (i + 1) * charsPerSection)
    );
  }
  return sections;
}

Cas pratique : 500 pages PDF juridique

Scénario : Vous avez reçu un dossier de 500 pages (800 K tokens) contenant :

• Contrat principal (100 pages)
• Jurisprudence applicables (200 pages)
• Audit de conformité (100 pages)
• Échanges email (100 pages)

Objectif : Extraire en 30 min les 5 risques critiques, recommandations, et calendrier de réaction.

Approche : Contexte long (une passe) avec structure mitigation.

# INSTRUCTION SPÉCIALE

Vous analyserez ce dossier de 800K tokens. Le middle (pages 200–400)
contient la jurisprudence — lisez-le avec soin.

Répondez en JSON structuré :
{
  "executive_summary": "1 paragraphe max",
  "top_5_risks": [
    {"risk": "...", "source_page": "...", "severity": "critical|high|medium"}
  ],
  "recommendations": [...],
  "timeline": "..."
}

[CONTRAT 100 pages]
[JURISPRUDENCE 200 pages — ATTENTION, SECTION CRITIQUE]
[AUDIT 100 pages]
[EMAILS 100 pages]

Résultat attendu : JSON structuré en ~90 secondes pour ~4 USD.

Alternative RAG : Indexer le dossier, puis poser 5 requêtes ciblées (une par risque) → coût ~3 USD, latence ~5 sec/requête. Choix optimal : une vraie analyse exhaustive ? Contexte long. Questions répétitives sur le même dossier ? RAG.

Outil : vérifier les token counts réels

Avant de lancer une requête 1M, compter les tokens exactement :

# Via la CLI Anthropic (bêta 2025)
ant messages count-tokens --model claude-opus-4-8 --message '{role: user, content: "Hello, Claude"}'

# Via API (token counting gratuit)
curl -X POST https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-8",
    "system": "Tu es un analyste.",
    "messages": [{"role": "user", "content": "...document ici..."}]
  }'

La réponse inclut input_tokens exact. À partir de là, coût = (input_tokens / 1_000_000) * 5.

Atelier : pipeline de classification document (90 min)

Vous construisez un système qui décide automatiquement si un document doit être traité en contexte long ou RAG. Voici les étapes :

Livrable :

1. Script Node.js qui charge un PDF arbitraire
2. Compter les tokens
3. Appliquer l'arbre de décision (volume, change fréquence, type d'analyse)
4. Proposer une stratégie (contexte long vs RAG)
5. Afficher le coût estimé
6. Exécuter la stratégie recommandée
7. Mesurer la latence et la qualité

Critères de succès :

• ✅ Token count exact affiché
• ✅ Recommandation cohérente avec l'arbre
• ✅ Réponse en < 2 min pour contexte long
• ✅ JSON structuré en sortie
• ✅ Coût réel vs coût estimé (< 10 % d'erreur)

Pièges courants et comment les éviter

Pour aller plus loin

• 📖 Anthropic — 1M context release notes
• 📖 "Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., 2023)
• 📖 Anthropic Blog — Effective context engineering for AI agents
• 🛠 Anthropic Token Counting API
• 📘 LangChain — Summarization chains
• 🎯 Modules complémentaires : M2 Cost optimization, M12 Multimodal avancé