fenêtre de contexte

En profondeur

La fenêtre se mesure en tokens et couvre tout ce qui entre dans un appel : les instructions permanentes, l’historique repris, les documents joints, les résultats d’outils, sans oublier la réponse à produire, qui occupe elle aussi de la place. C’est une caractéristique du modèle, arrêtée lors de son entraînement : on ne l’agrandit pas depuis le produit, on change de modèle. Elle pèse sur le coût et sur le temps de réponse, puisque chaque appel repaie l’intégralité de ce qui est envoyé, et non le seul message nouveau. Une conversation longue coûte donc de plus en plus cher à chaque tour, alors même que l’utilisateur a le sentiment de poursuivre la même discussion.

Une grande fenêtre ne garantit pas une bonne utilisation de son contenu. La qualité de l’attention portée à un élément dépend de sa place : les débuts et les fins sont mieux exploités que les milieux, et un détail décisif noyé au centre d’un très long document peut être ignoré sans que rien ne le signale. Remplir la fenêtre parce qu’elle est grande est donc une mauvaise stratégie : sélectionner les bons extraits reste plus juste et moins cher que tout envoyer. Quand la limite est dépassée, le comportement n’est d’ailleurs pas une erreur franche mais une troncature, le plus souvent silencieuse.

Distinguer la fenêtre du contexte change la manière de résoudre un problème. Si un assistant oublie une consigne donnée dix messages plus tôt, la cause n’est presque jamais la taille de la fenêtre : c’est la stratégie du harnais, qui a résumé, tronqué ou simplement omis de renvoyer cette consigne. Passer à un modèle doté d’une fenêtre plus large coûte cher et ne corrige rien si la sélection reste mauvaise, car on ne perd pas ce qu’on n’a jamais envoyé. La question utile n’est pas de savoir combien le modèle peut voir, mais ce que l’on décide de lui montrer, et selon quelle règle.