À quoi sert une fenêtre de contexte d’un million de jetons?

La fenêtre de contexte d’un modèle, c’est la quantité de texte qu’il peut garder en vue d’un coup : vos consignes, les documents que vous collez, la conversation jusqu’ici et sa propre réponse. Elle se mesure en jetons, les petits morceaux de texte (ou d’images, d’audio et de code) que le modèle traite réellement. La semaine dernière, Google a annoncé Gemini 1.5 Pro, avec une fenêtre standard de 128 000 jetons. Certains développeurs et clients d’affaires peuvent maintenant essayer une fenêtre allant jusqu’à un million de jetons dans un aperçu privé. À titre de comparaison, Claude 2.1, d’Anthropic, contient 200 000 jetons, environ 500 pages.

Ce qui tient dans un million de jetons

Google donne ces équivalences approximatives pour un million de jetons :

Les démonstrations de Google montrent ce que cette taille rend possible : poser des questions sur les 402 pages de transcriptions de la mission Apollo 11, repérer des éléments de l’intrigue et de petits détails dans un film muet de Buster Keaton de 44 minutes, et raisonner sur plus de 100 000 lignes de code. En recherche, Google a testé des fenêtres allant jusqu’à dix millions de jetons.

Le gain pratique, c’est que vous n’avez plus à découper votre contenu en morceaux et à décider d’avance quels morceaux comptent. Parmi les bons usages :

• Contrats et rapports : comparer chaque clause dans une pile d’ententes, ou trouver où deux documents de politique se contredisent.
• Bases de code : demander comment fonctionne une fonction quand la réponse s’étend sur des dizaines de fichiers.
• Enregistrements : chercher dans des heures de réunions ou de cours le moment où un sujet a été abordé.
• Apprendre à partir d’un manuel : Google rapporte que, devant un livre de grammaire du kalamang, une langue parlée par moins de 200 personnes, le modèle a appris à traduire l’anglais vers cette langue à peu près aussi bien qu’une personne qui étudie le même livre.

Un test de l’« aiguille dans une botte de foin » complet

La façon habituelle de vérifier si un modèle utilise vraiment toute sa fenêtre est le test de l’aiguille dans une botte de foin : on cache une phrase incongrue quelque part dans un très long document et on demande au modèle de la trouver. Google rapporte que Gemini 1.5 Pro a repéré le texte caché dans 99 % des essais, même entouré d’un million de jetons.

Vous pouvez en faire une petite version vous-même avec n’importe quel modèle à long contexte auquel vous avez accès :

1. Prenez un long texte du domaine public, comme un roman du Projet Gutenberg.
2. Insérez une phrase qui n’a pas sa place, aux deux tiers environ : « L’ingrédient secret de la soupe de grand-maman Lucie est le paprika fumé. »
3. Collez le texte entier avec cette question :

Voici un long document. Réponds à la question en utilisant seulement le document. Si tu trouves la réponse, cite la phrase d’où elle vient.

<document>
[colle le texte complet ici]
</document>

Question : Quel est l’ingrédient secret de la soupe de grand-maman Lucie?

1. Recommencez avec la phrase près du début, au milieu et à la fin, et notez où, le cas échéant, le modèle échoue.

La façon de demander compte. Quand un testeur indépendant a fait ce genre de test avec Claude 2.1, le modèle répondait souvent que le document ne le disait pas, parce que la phrase cachée semblait déplacée. Anthropic a constaté que commencer la réponse de Claude par « Voici la phrase la plus pertinente du contexte : » faisait passer son score à ce test de 27 % à 98 %. Demander une citation, comme dans le prompt ci-dessus, pousse les modèles dans la même direction.

Un long contexte remplace-t-il la recherche documentaire?

Pas pour la plupart des travaux continus, même si cela change le moment où vous en avez besoin. La génération augmentée par la recherche (retrieval-augmented generation, ou RAG) est l’approche décrite dans un article de 2020 de Lewis et ses collègues : au lieu de tout donner au modèle, une étape de recherche extrait d’une grande collection les quelques passages les plus pertinents pour chaque question et ne transmet que ceux-là au modèle. Les auteurs de l’article soulignaient que les modèles stockent des faits dans leurs paramètres, mais ont du mal à y accéder avec précision, à montrer d’où vient une réponse ou à mettre à jour ce qu’ils savent. La recherche documentaire règle ces trois problèmes.

Une longue fenêtre change l’équilibre de quelques façons. Pour un seul ensemble de documents autonome que vous allez interroger à fond une seule fois, comme un dossier de vérification diligente ou une base de code, tout charger évite le risque que l’étape de recherche rate le passage dont vous aviez besoin. La mise en place est aussi plus simple : aucun index à bâtir.

Mais le coût et la vitesse favorisent la recherche documentaire pour un usage répété. Les modèles traitent chaque jeton que vous envoyez, chaque fois que vous posez une question. Envoyer un million de jetons pour répondre à chaque question, c’est lire une bibliothèque pour vérifier un seul fait. Google elle-même dit aux premiers testeurs de s’attendre à des attentes plus longues avec la fenêtre d’un million de jetons, affirme qu’elle travaille encore à réduire la latence et les besoins en calcul, et prévoit des niveaux de prix qui montent à partir de la fenêtre standard de 128 000 jetons. La recherche documentaire peut aussi dépasser n’importe quelle fenêtre : un wiki d’entreprise ou des années de courriels peuvent être bien plus gros qu’un million de jetons, et ils changent tous les jours.

Le scénario le plus probable est un mélange. Utilisez la recherche documentaire pour réduire une collection immense ou changeante aux documents pertinents, puis utilisez un long contexte pour lire ces documents en entier plutôt qu’en fragments. Et quelle que soit l’approche, demandez des citations pour pouvoir vérifier la réponse à partir de la source.