Module 3 — La courbe d'attention en U — Context Engineering — le pack Praktik

Objectif

À la fin de ce module, tu sauras où placer l’information critique dans ton contexte pour maximiser sa rétention.

Le phénomène “Lost in the Middle”

Liu et al. (2023) ont démontré que les modèles de langage oublient l’information placée au milieu du contexte. Ce n’est pas une légende — c’est mesurable.

Résultat clé : L’information au milieu subit 10-40% de perte de recall par rapport aux bords.

Recall accuracy
100% ┤╭──────╮
 80% ┤╯      ╰──╮
 60% ┤          ╰────╮
 40% ┤               ╰────╮
 20% ┤                    ╰────╮
  0% ┼────┬────┬────┬────┬────┬
     Début                          Fin
          ↑ Milieu = danger

Pourquoi le milieu est pénalisé

1. Attention sink

Le premier token (souvent BOS — Beginning of Sequence) absorbe une attention disproportionnée. Le budget d’attention restant est réparti sur les autres tokens, mais le milieu en reçoit moins.

2. n² relations

Pour n tokens, le mécanisme d’attention calcule n² relations. À mesure que n augmente, chaque token individuel reçoit moins d’attention relative.

3. Position encoding interpolation

Au-delà des longueurs d’entraînement, l’interpolation des encodages de position réduit la précision positionnelle.

Où placer l’information critique

Type d’info	Position idéale	Pourquoi
Contraintes de sécurité	Début	Jamais négociables
Format de sortie requis	Début ou fin	Doit être suivi
Objectif de la tâche	Début	Oriente tout le raisonnement
Règles métier critiques	Début ou fin	Évite les erreurs coûteuses
Détails techniques	Milieu (avec résumé aux bords)	Acceptable si résumé aux extrémités
Contexte de fond	Milieu	Info supportive, pas directive
Conclusion / prochaines étapes	Fin	Fraîche dans la mémoire

Structure de prompt optimale

# [DÉBUT — Zone haute attention]

## Objectif
Corriger le bug d'authentification JWT sur /api/auth/login

## Contraintes critiques
- Ne jamais logger les tokens en clair
- Toujours valider l'expiration côté serveur
- Format de sortie : code blocks avec types TypeScript

# [MILIEU — Zone basse attention]

## Contexte technique
Stack : Node.js 20, Express, Prisma, PostgreSQL
Le bug apparaît quand l'email contient un caractère +
...

# [FIN — Zone haute attention]

## Points de vigilance
- Vérifier le parsing de l'email (regex trop stricte ?)
- Tester avec des emails contenant +, ., et _
- Ne pas casser la rétrocompatibilité avec les sessions existantes

## Prochaines étapes
1. Identifier la regex de validation
2. Ajouter des cas de test edge cases
3. Déployer en staging

Anti-pattern : l’instruction critique au milieu

# ❌ Mauvais — l'instruction critique est au milieu

## Contexte
Projet de facturation...

## Contraintes
- Ne jamais logger les tokens  ← PERDU AU MILIEU
- Toujours valider l'expiration

## Détails
...

Le modèle va probablement oublier la contrainte de logging si le contexte devient long.

Checklist de validation

Mes contraintes critiques sont au début ou à la fin
J’ai un résumé au début et à la fin pour les longs documents
Je n’ai pas d’instructions de sécurité au milieu
Je structure mes prompts avec des sections claires

Mettre les règles de sécurité au milieu d’un long system prompt. → Dans un contexte de 150K tokens, une règle placée à 75K tokens du début a 30-40% de chances d’être ignorée. Les contraintes de sécurité vont au début, point final.

Prochaine étape

→ Module 4 (Les 5 patterns de dégradation) pour diagnostiquer quand ça va mal