Qu'est-ce qu'une fenêtre de contexte de modèle, en pratique

Outils et infrastructure3 min de lecture

Une fenêtre de contexte est la quantité maximale de texte, mesurée en tokens, qu'un modèle peut lire et sur laquelle il peut raisonner lors d'un seul appel. Tout ce que le modèle connaît au cours de cet appel, invites, historique, documents récupérés, sorties d'outils, doit tenir dans cette fenêtre.

Des tokens, pas des mots

Les modèles ne traitent pas directement des caractères ou des mots. Ils traitent des tokens, qui sont des fragments de texte produits par un tokeniseur. Une règle générale est qu'un token équivaut à environ trois ou quatre caractères en anglais, soit approximativement 0,75 mot. Une fenêtre de contexte de 128 000 tokens contient de l'ordre de 90 000 à 100 000 mots, bien que les chiffres exacts dépendent du modèle et du tokeniseur qu'il utilise.

Le code se tokenise différemment de la prose. Les noms de variables, la syntaxe riche en ponctuation et les caractères non latins peuvent consommer des tokens plus rapidement que du texte en anglais courant.

Ce qui se trouve à l'intérieur de la fenêtre

Chaque token d'un appel de modèle unique est en compétition pour le même espace :

  • Invite système
  • Historique de conversation
  • Documents ou fragments récupérés (voir qu'est-ce que RAG)
  • Définitions d'outils et résultats des appels d'outils
  • Le message actuel de l'utilisateur
  • L'espace réservé à la réponse du modèle

Dans une boucle agentique, les sorties d'outils reviennent dans le contexte à chaque itération. Une tâche en plusieurs étapes peut remplir une grande fenêtre plus rapidement que les ingénieurs ne s'y attendent.

Pourquoi la taille ne suffit pas

Des fenêtres de contexte plus grandes ne résolvent pas tout, pour plusieurs raisons.

Premièrement, le coût. La plupart des fournisseurs facturent par token, en entrée comme en sortie. Envoyer 100 000 tokens à chaque appel est coûteux à grande échelle.

Deuxièmement, la latence. Des charges utiles plus importantes prennent plus de temps à traiter, ce qui est important dans les applications interactives ou en temps réel.

Troisièmement, la qualité de la récupération. La recherche et l'expérience en ingénierie suggèrent que les modèles peuvent perdre le fil des informations enfouies au milieu d'un contexte très long. Placer les éléments les plus pertinents au début ou à la fin de l'invite tend à produire de meilleurs résultats.

Quatrièmement, la fenêtre de contexte est éphémère. Rien en son sein ne persiste entre les appels, sauf si l'application le gère explicitement. La mémoire entre les sessions doit être prise en charge au niveau de la couche applicative, et ne peut pas être supposée du côté du modèle.

Conséquences pratiques pour les ingénieurs

Les ingénieurs travaillant au niveau de la couche applicative doivent régulièrement prendre des décisions concernant la gestion du contexte :

  • Quelles parties d'une conversation conserver et lesquelles résumer ou ignorer
  • Combien de fragments récupérés transmettre, et comment les classer
  • S'il convient de diviser un document volumineux ou de router les requêtes vers des appels plus ciblés et de moindre taille
  • Comment gérer les tâches agentiques faisant appel à de nombreux outils sans atteindre les limites de tokens en cours d'exécution

Ce ne sont pas des choix de configuration. Ils nécessitent de comprendre ce que le modèle fait réellement avec les informations qu'il reçoit. Un ingénieur qui considère la fenêtre de contexte comme un simple contenant plus grand tend à produire des systèmes lents, coûteux ou peu fiables dans des conditions d'utilisation réelles.

L'ingénierie de contexte est la discipline qui consiste à prendre des décisions délibérées et raisonnées sur ce qu'il convient de placer dans une fenêtre de contexte, comment le structurer, et ce qu'il faut en exclure.

Relation avec les autres composants

Une base de données vectorielle existe en partie parce que les fenêtres de contexte sont finies. Plutôt que de charger l'intégralité d'une base de connaissances dans une invite, les systèmes de récupération trouvent les fragments les plus pertinents et ne transmettent que ceux-ci. La qualité de cette récupération détermine directement sur quoi le modèle peut raisonner.

Dans les configurations de codage agentique, la fenêtre de contexte détermine également quelle portion d'une base de code un modèle peut avoir en vue simultanément. Les ingénieurs travaillant sur des dépôts volumineux doivent souvent être attentifs aux fichiers, fonctions ou diffs qu'ils incluent.

Ce que nous évaluons

Bien gérer une fenêtre de contexte est quelque chose que nous observons directement dans notre façon d'évaluer les ingénieurs. Dans l'évaluation AI-native de comment nous sélectionnons, nous notons la conception des prompts et du contexte sur exactement ce point : est-ce que l'ingénieur configure le contexte de la tâche de manière à ce que l'outil produise un résultat utilisable, plutôt que de tout transmettre et de relancer des prompts en cas d'échec. Nous examinons également le développement piloté par les spécifications, car un ingénieur qui découpe un ticket vague en éléments bien délimités prend le même type de décision : choisir ce dont le modèle a besoin et écarter ce qui ne lui est pas nécessaire.

Réponses courtes

Une fenêtre de contexte plus grande signifie-t-elle de meilleurs résultats ?

Pas automatiquement. Des fenêtres plus grandes augmentent les coûts et la latence, et les modèles peuvent perdre le fil des informations enfouies loin dans des invites longues. La sélection rigoureuse de ce qui entre dans le contexte est souvent plus importante que la taille brute de la fenêtre.

Que se passe-t-il lorsque vous dépassez la fenêtre de contexte ?

L'API renvoie une erreur, ou le fournisseur tronque silencieusement l'entrée, selon l'implémentation. Dans les deux cas, du contenu est perdu. Les ingénieurs doivent gérer ce cas explicitement dans les systèmes en production, et non le traiter comme un cas limite.

La taille de la fenêtre de contexte est-elle identique pour tous les modèles ?

Non. Elle varie significativement selon le modèle et la version, de quelques milliers de tokens à plus d'un million dans certains cas. La limite pertinente pour votre système est celle du modèle que vous appelez réellement, et non le nombre le plus élevé que vous avez pu voir cité.

Parlons-en

Recevez une shortlist en cinq jours ouvrés

Vous nous indiquez les postes et la stack dans un court formulaire ou lors d'un appel de trente minutes. Sous cinq jours ouvrés, vous recevez des profils d'ingénieurs seniors identifiés par leur nom, chacun avec ses deux scorecards.

Avis surClutch4.9 sur 5 d'après 36 avis
ISO 27001
Certifié

Réserver trente minutes avec Dale

Le calendrier est fourni par HubSpot, qui dépose ses propres cookies. Chargez-le ici, ou réservez sur la page HubSpot.

Ouvrir la page de réservation