Claude 2 : cent mille jetons, ce que ça déverrouille vraiment
ClaudeContexteArchitectureRAG2023-07-1110 min
Un contrat entier tient désormais dans une seule requête. C'est une rupture d'usage réelle, et ce n'est toujours pas la fin de la récupération documentaire.
Le saut est d'un ordre de grandeur
Claude 2 porte la fenêtre de contexte à cent mille jetons, soit environ trois cents pages, contre une quinzaine il y a quatre mois. Ce n'est pas une amélioration incrémentale : c'est un changement de catégorie d'usage.
À quinze pages, la seule architecture viable consistait à découper le corpus et à ne récupérer que les extraits pertinents. À trois cents pages, un document entier tient dans la requête. Un contrat cadre, un rapport annuel, une procédure qualité complète, un cahier des charges : tous ces objets deviennent analysables d'un seul tenant, sans découpage préalable.
La différence pratique est considérable. Découper un contrat détruit les renvois internes, une clause qui dit « sauf disposition contraire de l'article 12 » perd son sens si l'article 12 n'est pas dans le même extrait. La fenêtre longue supprime ce problème d'un coup.

Ce que ça rend possible dès maintenant
Trois familles d'usage deviennent accessibles sans architecture particulière, et ce sont celles qui bloquaient le plus. L'analyse contractuelle complète, la revue de cohérence documentaire, et la synthèse de dossier volumineux.
L'analyse contractuelle en profite le plus. Il devient possible de demander à un modèle de relever toutes les clauses qui engagent une partie au-delà d'un certain seuil, en lui donnant le contrat complet, sans craindre qu'une clause tombe entre deux extraits.
La revue de cohérence est le second gain. Comparer deux versions d'une procédure, ou vérifier qu'un ensemble de documents ne se contredit pas, exige de tout voir en même temps. Aucun découpage ne permet de repérer une contradiction entre la page 12 et la page 240.
La synthèse de dossier, enfin, s'améliore nettement : une synthèse produite à partir de vingt extraits sélectionnés est toujours moins fidèle qu'une synthèse produite à partir du dossier entier.
Ce que la fenêtre longue ne règle pas
- Le corpus reste plus grand que la fenêtre. Trois cents pages ne sont pas trois cents mille pages. La récupération documentaire reste nécessaire, comme expliqué dans le RAG, la seule architecture qui tienne.
- Ce qui est envoyé est facturé. Remplir cent mille jetons à chaque question coûte plus de dix fois une requête ciblée. Le calcul est développé dans le coût réel d'un système IA en production.
- La latence augmente avec le contexte. Une requête pleine met plusieurs dizaines de secondes, ce qui exclut l'usage conversationnel interactif.
- L'attention n'est pas uniforme. L'information placée au milieu d'un très long contexte est moins bien exploitée que celle placée au début ou à la fin, un effet mesuré et reproductible.
Le réglage qui en découle : hybride, pas exclusif
La bonne architecture combine récupération et fenêtre longue au lieu de choisir entre les deux. C'est le réglage que j'applique depuis, et il est plus simple qu'il n'y paraît.
La récupération sert à identifier les documents pertinents dans un corpus de plusieurs milliers de pièces. La fenêtre longue sert ensuite à donner ces documents en entier, plutôt que par fragments. On passe de « vingt extraits de mille caractères » à « trois documents complets », et la qualité de réponse s'améliore sensiblement.
Ce réglage change aussi le découpage. Puisqu'on ne cherche plus le passage exact mais le document pertinent, on peut découper à la maille du document ou de la section, ce qui préserve le contexte. Le sujet est traité dans découper un document.
Le test à faire avant de généraliser
Placer volontairement une information critique au milieu d'un contexte plein, puis poser une question qui en dépend. Si le modèle ne la retrouve pas, la fenêtre annoncée n'est pas la fenêtre exploitable, et ce constat doit être fait sur vos documents, pas sur un jeu de test générique.
Ce que ça implique pour les équipes qui construisent
Une fenêtre longue rend certains prototypes trompeusement faciles, et c'est le risque principal. Un prototype qui fonctionne parce qu'on lui donne tout le corpus ne dit rien du système en production, où le corpus aura décuplé.
Je recommande donc de fixer dès le départ le budget de contexte que le système aura en régime établi, et de développer sous cette contrainte. Un système conçu avec dix mille jetons de budget fonctionnera avec cent mille ; l'inverse n'est pas vrai.
Cette discipline évite le scénario le plus fréquent que je rencontre en reprise de projet : un prototype convaincant, une mise en production catastrophique, et personne capable d'expliquer l'écart. C'est le premier des verrous décrits dans sortir du prototype.
Questions fréquentes
- Une fenêtre de cent mille jetons remplace-t-elle le RAG ?
Non. Elle change la maille de la récupération, on récupère des documents entiers au lieu d'extraits, mais un corpus d'entreprise reste beaucoup plus grand que la fenêtre, et envoyer la fenêtre pleine à chaque question coûte dix fois plus cher.
- Faut-il remplir la fenêtre au maximum ?
Non. Le coût croît avec ce qui est envoyé, la latence aussi, et l'information utile se dilue. En pratique, remplir un dixième de la fenêtre avec les bons documents donne de meilleures réponses que la remplir entièrement.
- L'attention est-elle uniforme sur tout le contexte ?
Non. L'information placée au milieu d'un long contexte est moins bien exploitée que celle placée en début ou en fin. C'est un effet mesuré, qu'il faut vérifier sur ses propres documents avant de s'appuyer sur la fenêtre pleine.
- Comment choisir entre découpage fin et documents entiers ?
Par la nature des questions. Une question factuelle ponctuelle se satisfait d'extraits ; une question de cohérence ou d'analyse contractuelle exige le document entier, parce que les renvois internes ne survivent pas au découpage.