Comment les modèles gèrent-ils aujourd’hui un très long contexte?

Le contexte d’un modèle, c’est tout ce qu’il peut voir d’un coup : vos instructions, la conversation jusqu’ici et tous les documents que vous collez, le tout mesuré en jetons, les petits morceaux de texte que lisent les modèles. Les bancs d’essai de l’article sur FlashAttention, en 2022, utilisaient encore des entrées de 512 ou de 1 000 jetons. Les systèmes de recherche en gèrent maintenant des millions, assez pour une pile de contrats ou une base de code entière en une seule requête.

Cette croissance n’est pas venue d’un nouveau type de modèle. Elle est venue d’un travail d’ingénierie qui a permis à la même opération centrale, l’attention, de fonctionner sur du vrai matériel. Comprendre ce travail vous aide à juger ce qu’une grande fenêtre de contexte peut faire pour vous, et ce qu’elle ne peut pas faire.

Pourquoi les longues entrées sont difficiles

Dans un Transformer, l’architecture derrière les modèles de langage d’aujourd’hui, l’auto-attention (self-attention) permet à chaque jeton de regarder tous les autres jetons pour décider de ce qui compte. C’est ce qui permet à un modèle de relier un pronom à la page 40 à un nom à la page 2. Le prix à payer, c’est que le nombre de comparaisons croît avec le carré de la longueur de l’entrée. L’article sur FlashAttention le dit clairement : le temps et la mémoire nécessaires à l’auto-attention sont quadratiques par rapport à la longueur de la séquence.

Un petit tableau montre ce que veut dire « quadratique ». Les chiffres sont de la simple arithmétique, pas des mesures d’un modèle.

Dix fois plus de texte veut dire cent fois plus de paires. Les premières tentatives pour régler ce problème utilisaient l’attention approximative, qui saute certaines comparaisons. Les auteurs de FlashAttention notent que ces méthodes sacrifiaient une part de qualité et, souvent, ne s’exécutaient pas plus vite en pratique.

Technique 1 : calculer l’attention exacte plus astucieusement

FlashAttention, publié en 2022 par Tri Dao et ses collègues, a gardé l’attention exacte et s’est attaqué à un autre goulot d’étranglement : le déplacement des données. Un GPU a une mémoire principale vaste mais relativement lente, et une toute petite mémoire très rapide sur la puce elle-même. L’attention standard transfère sans cesse de grands tableaux entre les deux. FlashAttention divise le travail en tuiles, de petits blocs qui tiennent dans la mémoire rapide, et en termine le plus possible là avant de réécrire quoi que ce soit.

Pensez à un cuisinier qui va au garde-manger pour chaque ingrédient, comparé à un autre qui apporte d’abord sur le comptoir tout ce qu’il faut pour un plat. La recette est la même; les allers-retours, non. L’article rapporte que cette méthode a rendu l’entraînement plusieurs fois plus rapide pour certaines tâches, par exemple environ trois fois plus rapide pour GPT-2 avec des entrées de 1 000 jetons, et que le contexte plus long qu’elle permettait a amélioré la qualité du modèle.

Technique 2 : répartir une entrée sur de nombreuses puces

Même une attention efficace finit par manquer de mémoire sur une seule puce. Ring Attention, publié en 2023 par Hao Liu, Matei Zaharia et Pieter Abbeel, divise une longue séquence en blocs et confie chaque bloc à un appareil différent. Les appareils sont disposés en anneau. Chacun calcule l’attention pour son propre bloc tout en passant à son voisin des morceaux de ses données, les clés et valeurs auxquelles les autres jetons se comparent, de sorte que l’envoi et le calcul se font en même temps.

Résultat : la taille maximale de l’entrée croît avec le nombre d’appareils. Les auteurs rapportent avoir travaillé avec des contextes de millions de jetons, sans approximation de l’attention. Combinées au calcul par tuiles, des techniques comme celle-ci expliquent comment une fenêtre de contexte peut dépasser de loin ce que contient un seul GPU.

Un test de rappel concret

Une grande fenêtre vous dit combien un modèle accepte, pas s’il s’en sert bien. L’étude Lost in the Middle, publiée en 2023 par Nelson Liu et ses collègues, a constaté que les modèles répondaient le mieux quand l’information nécessaire se trouvait près du début ou de la fin de l’entrée, et le moins bien quand elle était au milieu, même pour des modèles conçus pour les longs contextes.

Vous pouvez le vérifier avec le modèle que vous utilisez. Prenez un long document que vous connaissez bien, comme un rapport de 60 pages, et cachez-y trois petits faits inventés : un à la page 2, un à la page 30, un à la page 58. Envoyez ensuite :

Réponds seulement à partir du document. Si la réponse ne s’y trouve pas, dis-le.
1. De quelle couleur est la camionnette de livraison mentionnée dans le rapport?
2. Quel est le nom de la coordonnatrice des bénévoles?
3. Quel jour de la semaine l’entrepôt est-il fermé?
Pour chaque réponse, cite la phrase que tu as utilisée.

Notez les résultats dans une grille comme celle-ci. Les entrées ci-dessous sont des exemples, pour montrer le format.

Recommencez en plaçant les faits à d’autres endroits. Demander une citation est important : cela vous permet de voir si le modèle a vraiment trouvé la phrase ou s’il a deviné.

Quels sont les compromis d’un long contexte?

Coût et vitesse. Vous payez pour chaque jeton envoyé, à chaque requête. Même avec une attention efficace, une très longue entrée prend plus de temps à traiter : un téléversement de 500 pages est donc plus lent et plus coûteux que les trois pages qui répondent vraiment à votre question.

Une attention inégale. Comme l’a montré l’étude Lost in the Middle, plus de contexte ne veut pas dire une attention égale à tout ce contexte. Un détail enfoui au milieu d’une énorme entrée est celui qui a le plus de chances d’être manqué, et le modèle ne vous dira peut-être pas qu’il l’a manqué.

La dilution. Le contenu hors sujet fait concurrence aux parties qui comptent. Une entrée ciblée donne souvent une réponse plus précise qu’une entrée complète.

En pratique, le long contexte fonctionne le mieux pour les tâches qui exigent vraiment une vue d’ensemble, comme trouver des contradictions dans un long contrat ou suivre l’utilisation d’une fonction dans une base de code. Pour les questions qui ont une réponse précise, il vaut généralement mieux chercher d’abord et n’envoyer que les passages pertinents, puis demander au modèle de citer ses preuves pour que vous puissiez les vérifier.