Gemini 1.5 : un million de jetons, et le test qui compte
GeminiContexteÉvaluationArchitecture2024-02-1510 min
Une fenêtre d'un million de jetons ne vaut que si le modèle y retrouve ce qu'on y a mis. Le test tient en une demi-journée et change souvent la conclusion.
Le chiffre et ce qu'il recouvre
Gemini 1.5 porte la fenêtre de contexte à un million de jetons, soit environ trois mille pages ou plusieurs heures de vidéo. L'ordre de grandeur dépasse ce que la plupart des organisations ont besoin de traiter en une fois.
À ce niveau, la question cesse d'être « est-ce que mon document tient » pour devenir « est-ce que le modèle exploite réellement ce que je lui donne ». Ce n'est pas la même question, et la réponse n'est pas garantie par l'annonce.
Une fenêtre est une capacité d'entrée. Ce que le modèle en fait, s'il retrouve un fait placé au milieu, s'il relie deux informations distantes de mille pages, relève de la mesure, pas de la spécification.
Le protocole de test, en une demi-journée
Placer un fait vérifiable à différentes profondeurs du contexte, poser une question qui en dépend, et compter les échecs. C'est le seul moyen de connaître la fenêtre réellement exploitable d'un modèle sur vos documents.
La méthode est simple à mettre en œuvre. On constitue un contexte long à partir de documents réels, on y insère une phrase factuelle inventée mais plausible, et on demande cette information. On répète en déplaçant la phrase : au début, au quart, au milieu, aux trois quarts, à la fin.
Le résultat est presque toujours instructif. La performance est excellente aux extrémités et se dégrade au centre, dans des proportions qui varient beaucoup d'un modèle à l'autre et d'un type de contenu à l'autre. Un contexte homogène, mille pages du même contrat, se comporte différemment d'un contexte hétérogène.
Ce protocole doit être rejoué à chaque changement de modèle, au même titre que le reste du jeu de tests décrit dans l'évaluation continue.
Ce qu'une très grande fenêtre rend possible
- Analyser une base de code entière pour en produire une cartographie ou repérer des incohérences, sans découpage préalable.
- Traiter un dossier volumineux d'un seul tenant : un dossier d'appel d'offres, un dossier patient, un dossier contentieux.
- Comparer des versions distantes d'un même document, ce qu'aucun découpage ne permet de faire correctement.
- Réduire la complexité d'architecture sur les corpus de taille moyenne, en remplaçant une chaîne de récupération par un envoi direct. Voir le RAG, la seule architecture qui tienne.
Le coût qu'il faut poser avant de s'enthousiasmer
Une requête qui remplit un million de jetons coûte plusieurs euros, ce qui exclut l'usage interactif à grande échelle. C'est la limite pratique, et elle est structurelle.
Le calcul est immédiat : au tarif courant, remplir la fenêtre représente le coût de plusieurs centaines de requêtes ciblées. Un système consulté cent fois par jour avec la fenêtre pleine coûte davantage qu'un système consulté dix mille fois avec une récupération correcte.
La latence pose la même limite. Traiter un très grand contexte prend des dizaines de secondes, parfois plus. Cela convient à un traitement par lot, à une analyse ponctuelle, à un rapport produit chaque nuit. Cela ne convient pas à une conversation.
La conclusion pratique n'a pas changé depuis les fenêtres de cent mille jetons : la grande fenêtre est un outil d'analyse, pas un mode de fonctionnement par défaut. Le raisonnement complet figure dans une grande fenêtre reste une facture.
La règle qui évite la dérive
Réserver la fenêtre pleine aux traitements par lot, où la latence et le coût sont acceptables parce qu'ils sont amortis sur un résultat durable. Tout ce qui est interactif doit rester sur une récupération ciblée, quelle que soit la fenêtre disponible.
Ce que ça change pour la conception des systèmes
La très grande fenêtre supprime la phase de découpage pour toute une classe de projets, et c'est un gain considérable de simplicité. Il faut savoir reconnaître cette classe.
Elle regroupe les corpus stables de taille moyenne : une documentation produit, un référentiel réglementaire, un manuel technique. Quelques centaines de pages, qui changent rarement. Pour ces corpus, envoyer l'ensemble à chaque requête est plus simple, plus fiable et souvent moins coûteux en temps d'ingénierie que de bâtir une chaîne de récupération.
Le critère de bascule est le rapport entre le coût de la fenêtre pleine et le coût de construction et de maintenance d'une chaîne de récupération. En dessous de quelques centaines de pages et de quelques centaines de requêtes par jour, la fenêtre pleine gagne presque toujours. Au-delà, la récupération redevient nécessaire.
Ce calcul mérite d'être fait explicitement au cadrage, plutôt que de construire une architecture par réflexe.
Questions fréquentes
- Une fenêtre d'un million de jetons est-elle entièrement exploitable ?
Pas nécessairement. La performance se dégrade en général au centre du contexte, dans des proportions variables selon le modèle et le type de contenu. Seul un test sur vos documents donne la fenêtre réellement utilisable.
- Comment tester la fenêtre exploitable ?
En insérant un fait vérifiable à différentes profondeurs d'un contexte long constitué de vos documents réels, puis en le redemandant. Le taux d'échec par position donne directement la réponse.
- Quand la fenêtre pleine est-elle préférable au RAG ?
Sur un corpus stable de quelques centaines de pages consulté quelques centaines de fois par jour. Au-delà, le coût et la latence rendent la récupération ciblée plus économique et plus rapide.
- Peut-on utiliser la fenêtre pleine en conversation ?
Non, en pratique. Plusieurs dizaines de secondes de latence et un coût de plusieurs euros par requête excluent l'usage interactif. La grande fenêtre est un outil de traitement par lot.