Révolutionnez vos modèles IA : Quand le CAG prend le pas sur le RAG
Regardez la vidéo!
Si vous utilisez ChatGPT ou d'autres modèles d'IA, vous avez probablement remarqué qu'ils fournissent parfois des informations incorrectes ou "hallucinent". Le RAG (ou génération augmentée par récupération) aide à résoudre ce problème en recherchant dans des documents externes, mais il y a une nouvelle approche qui adopte une stratégie complètement différente – et cela pourrait être exactement ce qu'il vous faut !
Aux débuts des grands modèles de langues (nos LLMs), les fenêtres contextuelles, c’est à dire ce qu’on peut leur envoyer comme quantité de texte, étaient plutôt petites, souvent limitées à seulement 4 000 tokens ou 3 000 mots, ce qui rendait impossible de charger tout le contexte pertinent. Cette limitation a donné naissance à des approches comme le RAG en 2023, qui récupère dynamiquement le contexte nécessaire. À mesure que les LLMs ont évolué pour prendre en charge des fenêtres contextuelles beaucoup plus grandes – jusqu'à 100 000 ou même des millions de tokens – de nouvelles approches comme le caching, ou CAG, ont commencé à émerger, offrant une véritable alternative au RAG.
Pourquoi cela a-t-il pris autant de temps ? Bien que le CAG soit efficace, ça vient avec des coûts. Lorsque GPT-4 a été lancé, utiliser ces modèles à grand contexte était jusqu'à 20 fois plus cher par rapport aux modèles actuels, voire des centaines de fois plus cher avec les mini-modèles actuels comme GPT-4o-mini. Ces limitations initiales ont renforcé la domination du RAG pour de nombreux cas d'utilisation. Cependant, nous verrons pourquoi les récentes améliorations en efficacité et en coût des modèles ont rendu le CAG une alternative beaucoup plus viable.
Alors, qu'est-ce que le CAG ? Lors de l'utilisation de modèles de langage, il y a souvent un compromis entre vitesse et précision. Le RAG est excellent pour la précision, mais il nécessite du temps pour rechercher et comparer des documents. Et c’est pire plus il y a de données. C'est là que le CAG intervient en disant : "Et si nous préchargions directement toutes ces connaissances dans la mémoire du modèle ?" Un peu comme dans les modèles à long contexte comme Gemini, où on peut envoyer des millions de mots dans une seule requête. Le CAG rend cela encore plus intéressant.
On entend parler partout des LLMs, des prompts et du RAG, mais le CAG devient tout aussi important, en particulier pour les applications où la vitesse est essentielle. J'ai récemment discuté avec des développeurs dans notre communauté Discord Learn AI Together, et presque tout le monde veut implémenter le CAG dans leurs applications.
Clarifions rapidement comment fonctionne le CAG pour mieux comprendre quand l'utiliser. Le CAG utilise quelque chose appelé un cache Key-Value (ou KV). Dans les LLMs classiques, lorsqu'ils traitent du texte, ils créent ces paires KV – pensez aux Keys (ou clés) comme des étiquettes et aux Values (ou valeurs) comme nos informations réelles. Le modèle de langage utilise ensuite ces clés et valeurs pour comprendre le contenu et générer sa réponse. Habituellement, ces données sont temporaires et disparaissent après chaque réponse. Mais le CAG dit : "Pourquoi ne pas les sauvegarder et les réutiliser ?"
Oui, le CAG est utilisé pour enregistrer TOUTES vos informations dans le cache du modèle. Plus précisément, il sauvegarde vos calculs du texte vers les résultats intermédiaires que le modèle voit, ce qui représente tout de même beaucoup de calculs économisés si vous envoyez le même long contexte pour chaque requête.
Bien que cela économise du temps en traitant tout le texte en ces deux paires K et V, cela augmente la puissance de calcul nécessaire en remplissant la fenêtre contextuelle avec l'ensemble des données disponibles.
Le CAG gagne en popularité principalement pour trois raisons :
C'est rapide – plus besoin de rechercher dans des documents.
C'est plus fiable – pas de risque d'erreurs de récupération, mais il existe un risque d'ajouter des informations non pertinentes à chaque requête, souvent problématique pour les LLMs qui peuvent ne pas trouver les informations précieuses.
C'est simple – Pas besoin d'un pipeline complexe de recherche et récupération – juste le LLM et son cache préchargé.
En résumé : au lieu de rechercher dans une base de données à chaque fois (comme le fait le RAG), le CAG précharge toutes les informations dans la mémoire du modèle. Tout. Voici ce qui se passe dans un système basé sur le CAG : vous préchargez les connaissances dans le cache KV -> question de l'utilisateur -> accès direct aux connaissances mises en cache -> réponse instantanée.
Comme vous pouvez le voir, avec le CAG, nous éliminons complètement l'étape de recherche. Cela rend les réponses extrêmement rapides et plus fiables puisque nous ne dépendons pas d'un algorithme de recherche pour trouver les bonnes informations. Mais il y a des inconvénients importants :
Vous êtes limité par la fenêtre contextuelle de votre modèle – actuellement environ 128 000 tokens (environ 100 000 mots) pour la plupart.
C'est super efficace, mais plus coûteux, car vous envoyez toujours beaucoup de contexte au modèle, même pour des requêtes simples, tandis que le RAG envoie uniquement les éléments nécessaires.
Vous pouvez rencontrer des problèmes en envoyant trop d'informations et en ne trouvant pas les éléments pertinents.
Un défi important à considérer avec le CAG est le problème de « l'information perdue au milieu » : même avec de grandes fenêtres contextuelles, les LLMs ont souvent du mal à récupérer des contenus spécifiques dispersés dans plusieurs parties de l'entrée, tandis que le RAG se concentre uniquement sur les informations nécessaires.
Pour donner un exemple, Google propose quelque chose de très similaire dans son API Gemini – ils appellent cela le "context caching". Le principe est essentiellement le même : vous chargez votre contenu une fois, vous le mettez en cache et vous le réutilisez pour des requêtes ultérieures. Cela le rend plus efficace, car vous consommez moins de tokens.
Le CAG n'est pas si nouveau et existe depuis un certain temps !
Pour les spectateurs plus techniques qui souhaitent comprendre tout le processus, voici un petit aperçu pour vous : Pour construire un système basé sur le CAG, on commence par prétraiter toute notre base de connaissances. Au lieu de créer des embeddings comme dans le RAG, on génère et sauvegarde les représentations internes du modèle (le cache KV) de nos données. Cela se fait via un processus appelé KV-Encode dans le papier original, qui transforme le texte en un format que le modèle peut accéder instantanément.
Ensuite, lorsqu'une question arrive, le modèle utilise directement ces connaissances mises en cache pour répondre à la question avec précision ! Vous pouvez également réinitialiser ou mettre à jour ce cache efficacement quand c'est nécessaire.
À noter que dans la plupart des cas, cela est implémenté par le fournisseur de LLM, sauf si vous l'hébergez vous-même. En tant qu'utilisateur, vous n'aurez qu'à définir une variable liée à l'utilisation du cache sur "Vrai", et ils géreront le reste.
Tout comme dans notre discussion sur le RAG à propos des embeddings, le CAG a aussi ses propres techniques d'optimisation. Par exemple, vous pourriez avoir besoin de gérer la gestion du cache, d'implémenter des stratégies de troncature efficaces ou de gérer le réarrangement des identifiants de position.
Pour simplifier, voici des règles claires pour savoir quand considérer l’utilisation de ce système de cache :
Lorsque votre base de connaissances entre dans la fenêtre contextuelle du modèle.
Lorsque vous avez besoin de réponses extrêmement rapides.
Lorsque vos informations ne changent pas fréquemment.
Lorsque des coûts globaux plus élevés sont acceptables pour votre cas d'utilisation.
Lorsque vous ne voyez pas de baisse significative de qualité de sortie par rapport au RAG.
Si vous hébergez le modèle, envisagez le CAG si vous disposez de suffisamment de mémoire GPU (oui, ce cache KV doit vivre quelque part et prend beaucoup de place, remplissant la fenêtre contextuelle !). Si vous utilisez le modèle via une API, oubliez ce point ; il vous suffit d'activer la fonctionnalité de cache et de ne plus y penser !
Par exemple, vous pourriez vouloir utiliser le CAG lorsque vous avez un chatbot qui doit répondre souvent aux mêmes FAQ afin que le bot sache toujours comment répondre. Ou pour répondre rapidement à des questions sur un rapport spécifique ou un enregistrement de réunion, comme créer un add-on dans le style de "discuter avec vos vidéos" pour YouTube.
Si vous voulez une analogie facile pour prendre votre prochaine décision, imaginez que vous devez passer un examen et avez un choix à faire: Voulez-vous avoir accès à tout le manuel et devoir trouver les informations au fur et à mesure, ou avoir parfaitement mémorisé seulement les chapitres 6 et 7 à l'avance ? Les deux approches fonctionnent, mais elles sont puissantes dans des situations différentes ! Le RAG sera meilleur lorsque vous avez besoin de tout le manuel pour réussir l'examen, tandis que le CAG sera idéal si l'examen porte uniquement sur le chapitre 7 !
Avant que certains d'entre vous ne demandent – oui, vous pouvez combiner le CAG avec le RAG dans une approche hybride. Vous pouvez avoir vos informations les plus fréquemment consultées dans le CAG pour un accès instantané tout en utilisant le RAG pour les détails plus rarement nécessaires. C'est comme avoir à la fois une mémoire parfaite pour votre spécialité et une énorme bibliothèque à votre disposition pour tous les faits !
À mesure que les LLMs deviennent encore meilleurs pour gérer des contextes vastes à moindre coût, une fonction de mise en cache de contexte bien implémentée pourrait devenir la norme pour la plupart des projets, simplement parce qu'elle est si efficace. Néanmoins, le RAG restera probablement indispensable pour les cas extrêmes où les bases de connaissances sont exceptionnellement grandes ou très dynamiques.
J'espère que ce blogue vous a aidé à comprendre ce qu'est le CAG, en quoi il diffère du RAG et quand utiliser les deux. Si vous l'avez trouvée utile, partagez-la avec vos amis de la communauté IA et n'oubliez pas de vous abonner pour plus de contenu approfondi sur l'IA !
Merci d'avoir lu !
