La guerre de la fenêtre de contexte : Pourquoi les LLMs géants menacent le RAG

J’ai passé la dernière année à regarder des développeurs s’arracher les cheveux en essayant de bâtir des pipelines de Retrieval-Augmented Generation (RAG). On prend la documentation de l’entreprise, on la découpe en morceaux arbitraires, on la passe dans un modèle d’embedding, on pousse tout ça dans une base de données vectorielle, et on prie pour que la recherche sémantique trouve le bon paragraphe quand un utilisateur pose une question. C’est une architecture fragile, tenue par du ruban adhésif. Aujourd’hui, Google et Anthropic offrent une alternative brutalement simple : garrocher le disque dur au complet dans le prompt.

Before you read: Nous avons déjà discuté de la façon dont les développeurs sortent l’IA du cloud pour la rouler en local dans L’essor des LLMs locaux : Délaisser l’IA cloud pour Ollama et Llama 3. Cet article explore l’extrême inverse : des modèles massifs, cloués au cloud, qui exigent des quantités astronomiques de VRAM juste pour garder votre prompt en mémoire.

Table des matières

• La machine de Rube Goldberg du RAG
• La force brute contre la bibliothèque
• La physique de la facture
• Faits amusants à voler
• Sources

La machine de Rube Goldberg du RAG

Pour comprendre pourquoi ces fenêtres de contexte géantes changent la donne, il faut regarder le bordel qu’elles remplacent. Le RAG est né d’une nécessité. En 2023, les LLMs étaient amnésiques. GPT-3.5 ne pouvait retenir qu’environ 4 000 tokens (à peu près 3 000 mots). Si vous vouliez que l’IA réponde à des questions sur un PDF de 500 pages, vous ne pouviez pas juste lui donner le livre.

À la place, il fallait bâtir un index. Vous coupiez le PDF en paragraphes. Quand l’utilisateur posait une question, votre système cherchait dans la base de données vectorielle le paragraphe le plus similaire mathématiquement, le sortait, et donnait uniquement ce petit bout à l’IA.

Ça a l’air élégant, jusqu’à ce que vous essayiez de le mettre en production. La recherche sémantique est notoirement pourrie pour raisonner à travers de multiples documents. Si un utilisateur demande : “Quel est le thème global de ces dix rapports financiers ?”, le RAG échoue lamentablement. Il se contente de ramener quelques paragraphes aléatoires contenant le mot “thème”. Essayer d’ajuster les paramètres de chevauchement de chunks est l’équivalent moderne de configurer une imprimante réseau.

La force brute contre la bibliothèque

Puis Anthropic a lancé Claude 3 avec une fenêtre de contexte de 200 000 tokens. Peu de temps après, Google a sorti Gemini 1.5 Pro, repoussant la limite à un absurde 2 millions de tokens.

Le paradigme a basculé du jour au lendemain. Vous n’avez plus besoin de bâtir un index pour trouver l’aiguille dans la botte de foin. Vous donnez directement la botte de foin au complet à l’IA et vous lui demandez où est l’aiguille.

Ce n’est pas juste une amélioration quantitative ; ça débloque des workflows complètement nouveaux. J’ai récemment vu un développeur balancer une base de code Python legacy de 50 000 lignes dans Gemini, avec un manuel d’API de 200 pages, et simplement demander : “Migre ce code vers la nouvelle API.” Le modèle l’a fait. Il a compris le contexte global, les cas limites et les définitions de variables éparpillées dans trente fichiers différents. Une base de données vectorielle ne pourrait jamais faire ça, car elle fragmente fondamentalement le contexte en pièces isolées.

La physique de la facture

Voici la dose de réalité : le RAG n’est pas encore mort, et la physique en est la raison.

Traiter 2 millions de tokens est une violence computationnelle. Ça demande des quantités massives de VRAM juste pour stocker le cache clé-valeur de votre prompt. Bien que Google et Anthropic aient réussi un miracle d’ingénierie avec le Ring Attention et des architectures clairsemées, ils ne peuvent pas plier les lois de l’économie.

Garrocher 2 millions de tokens dans Gemini 1.5 Pro coûte environ 2,50 $ par requête. Si vous bâtissez un chatbot de service client qui lit l’historique complet de votre entreprise chaque fois qu’un utilisateur dit “Bonjour”, vous allez mettre votre startup en faillite d’ici mardi.

De plus, il y a le Time To First Token (TTFT). Lire un prompt de 2 millions de tokens prend du temps. Vous pourriez attendre 30 à 45 secondes juste pour que l’IA commence à taper sa réponse. Pour du traitement de données en arrière-plan, c’est correct. Pour une interface web réactive, c’est inacceptable.

Honnêtement, le futur n’est pas l’un ou l’autre. C’est le prompt caching. Les fournisseurs permettent maintenant aux développeurs de mettre en cache des contextes massifs sur le serveur pour une fraction du prix, éliminant le besoin de retraiter les données à chaque tour de conversation. Le RAG survivra pour interroger des pétaoctets de données, mais pour tout ce qui fait moins de quelques millions de mots, on s’apprête à utiliser la force brute pour obtenir une meilleure IA.

Faits amusants à voler

• Deux millions de tokens, c’est environ 1,5 million de mots. Ça veut dire que vous pouvez coller la trilogie complète du Seigneur des Anneaux dans Gemini 1.5 Pro trois fois de suite dans un seul prompt.
• Le concept de test “Needle In A Haystack” (l’aiguille dans la botte de foin) a été littéralement inventé par des développeurs juste pour voir si ces modèles massifs lisaient réellement le milieu du prompt, ou s’ils se contentaient de survoler le début et la fin comme un étudiant paresseux.

Sources

• Google DeepMind Gemini 1.5 Pro Technical Report (2024)
• Anthropic Claude 3 Model Card and Prompt Caching Documentation
• “Needle In A Haystack” LLM Benchmark Methodology
• Pinecone Vector Database Architecture Guidelines