CAG ou RAG : lequel vous convient ?

À retenir

• Le RAG consulte des sources externes au moment de la requête, tandis que le CAG essaie de précharger le contexte nécessaire dans le cache du modèle.
• Le CAG peut simplifier le système lorsque la base de connaissances est petite, stable et tient dans la fenêtre de contexte que votre budget permet.
• Le RAG reste important lorsque les données changent souvent, sont trop volumineuses pour être préchargées ou exigent une recherche et un filtrage au niveau des sources.

Si vous utilisez ChatGPT ou d’autres modèles d’IA, vous avez probablement remarqué qu’ils fournissent parfois de l’information incorrecte ou hallucinent. Le RAG aide à résoudre ce problème en consultant des documents externes, mais cette nouvelle méthode adopte une approche complètement différente, et elle pourrait être exactement ce dont vous avez besoin !

Bonjour à tous ! Ici Louis-François, cofondateur et directeur de la technologie de Towards AI. Aujourd’hui, nous allons explorer en profondeur un sujet vraiment passionnant : la génération augmentée par cache, ou CAG.

Aux débuts des LLMs, les fenêtres de contexte, soit la quantité de texte que nous leur envoyons, étaient petites et souvent limitées à seulement 4 000 tokens, ou 3 000 mots. Il était donc impossible de charger tout le contexte pertinent. Cette limite a fait naître des approches comme la génération augmentée par la recherche d’information (RAG) en 2023, qui récupère dynamiquement le contexte nécessaire. À mesure que les LLMs ont commencé à prendre en charge des fenêtres de contexte beaucoup plus grandes, allant jusqu’à 100k ou même des millions de tokens, de nouvelles approches comme la mise en cache, ou CAG, ont émergé et offert une véritable solution de rechange au RAG. Pourquoi cette approche a-t-elle mis autant de temps à émerger ? Le CAG est efficace, mais entraîne des coûts. Au lancement de GPT-4, l’utilisation de ces modèles à grand contexte coûtait jusqu’à 20 fois plus cher que les modèles actuels, et même des centaines de fois plus cher que les mini-modèles d’aujourd’hui. Ces premiers défis ont renforcé la domination du RAG dans de nombreux cas d’utilisation. Nous verrons toutefois pourquoi les récentes améliorations apportées à l’efficacité et aux coûts des modèles ont fait du CAG une solution beaucoup plus viable.

Alors, qu’est-ce que le CAG ? Lorsqu’on utilise des modèles de langage, il faut généralement faire un compromis entre la vitesse et la précision. Le RAG offre une excellente précision, mais a besoin de temps pour chercher et comparer des documents. Et plus vous avez de données, plus la situation empire. Le CAG pose donc cette question : « Et si nous préchargions simplement toutes ces connaissances directement dans la mémoire du modèle ? » Un peu comme les modèles à long contexte tels que Gemini, auxquels vous pouvez envoyer des millions de mots dans une seule requête. Mais le CAG rend cette possibilité encore plus intéressante.

Nous entendons partout parler des LLMs, des prompts et du RAG, mais le CAG devient tout aussi important, particulièrement dans les applications où la vitesse compte vraiment. J’ai récemment parlé avec des développeurs de notre communauté Discord Learn AI Together, et presque tout le monde veut implémenter le CAG dans ses applications.

Clarifions rapidement le fonctionnement du CAG pour mieux comprendre quand l’utiliser. Le CAG emploie ce qu’on appelle un cache clé-valeur, ou KV. Lorsque des LLMs ordinaires traitent du texte, ils créent ces paires KV. Imaginez les clés comme des labels et les valeurs comme l’information elle-même. Le modèle de langage travaille ensuite avec ces clés et ces valeurs pour comprendre le contenu et générer sa réponse. Elles sont généralement temporaires et disparaissent après chaque réponse. Mais le CAG dit : « Hé, pourquoi ne pas les sauvegarder et les réutiliser ? » Oui, le CAG sert à sauvegarder TOUTE votre information dans le cache du modèle. Plus précisément, il sauvegarde les calculs qui transforment le texte en résultats intermédiaires vus par le transformeur. Cela représente tout de même une grande économie de calcul si vous envoyez le même long contexte pour chaque requête. Cette approche évite de retraiter tout le texte pour créer ces paires K-V, mais exige davantage de compute en remplissant la fenêtre de contexte avec tout votre dataset.

Le CAG gagne en popularité pour plusieurs raisons, mais surtout pour ces trois éléments :

1. Il est rapide. Plus besoin de chercher dans des documents.
2. Il est plus fiable. Il n’existe aucun risque d’erreur de recherche d’information, mais l’ajout d’information non pertinente à chaque requête risque de causer des problèmes lorsque les LLMs ne trouvent pas l’information utile dans le contexte.
3. Il est assez simple. Vous n’avez pas besoin d’un pipeline complexe de recherche d’information, seulement d’un LLM et de son cache préchargé.

En termes simples, au lieu de consulter une base de données à chaque fois, comme le fait le RAG, le CAG précharge toute l’information dans la mémoire du modèle. Absolument tout. Voici ce qui se passe dans un système fondé sur le CAG : vous préchargez les connaissances dans le cache KV -> question de l’utilisateur -> accès direct aux connaissances en cache -> réponse instantanée.

Comme vous pouvez le voir, le CAG élimine complètement l’étape de recherche. Les réponses deviennent extrêmement rapides et plus fiables, puisque nous ne dépendons pas d’un algorithme de recherche pour trouver la bonne information. Mais cette approche comporte des inconvénients importants.

1. Vous êtes limité par la fenêtre de contexte de votre modèle, actuellement autour de 128 000 tokens, ou environ 100 000 mots, pour la plupart des modèles. Vous ne pouvez donc pas simplement charger votre immense dataset de millions de lignes et obtenir des réponses instantanées et fiables. Cela ne fonctionne pas comme ça.
2. Le CAG est extrêmement efficace, mais plus coûteux puisque vous envoyez encore beaucoup de contexte au LLM à chaque fois, même pour les requêtes simples, tandis que le RAG envoie seulement les éléments nécessaires.
3. Vous pouvez rencontrer des problèmes en envoyant trop d’information et en ne trouvant pas les éléments pertinents. Le problème de l’information « perdue au milieu » constitue un défi important du CAG : même avec de grandes fenêtres de contexte, les LLMs ont souvent du mal à récupérer du contenu précis réparti dans plusieurs parties de l’input, tandis que le RAG sert à cibler uniquement l’information nécessaire.

Puisque nous parlons de millions de mots, Google offre une fonctionnalité très semblable dans son API Gemini, appelée « context caching ». Le principe est essentiellement identique : vous chargez votre contenu une fois, le placez en cache et le réutilisez pour les requêtes suivantes. Cela augmente l’efficacité puisque vous utilisez moins de tokens. Le CAG n’est pas si nouveau et existe depuis un certain temps !

Si vous êtes plus technique et voulez comprendre tout le processus, voici un petit aperçu : pour construire un système fondé sur le CAG, vous commencez par prétraiter toute votre base de connaissances. Au lieu de créer des embeddings comme dans le RAG, vous générez et sauvegardez les représentations internes de vos données dans le modèle, soit le cache KV. Dans l’article original, cette étape utilise un processus appelé KV-Encode, qui transforme votre texte dans un format auquel le modèle peut accéder instantanément.

Lorsqu’une question arrive, le modèle utilise directement ces connaissances en cache pour y répondre avec précision ! Vous pouvez aussi réinitialiser ou mettre à jour efficacement ce cache au besoin.

Sachez simplement que, dans la plupart des cas, le fournisseur du LLM implémente cette fonctionnalité, sauf si vous hébergez vous-même le modèle. Comme utilisateur, vous réglerez simplement à true une variable liée à l’utilisation du cache, puis le fournisseur gérera le reste.

Comme dans notre discussion sur les embeddings pour le RAG, le CAG possède aussi ses propres techniques d’optimisation. Vous pourriez par exemple devoir gérer le cache, implémenter des stratégies efficaces de troncature ou vous occuper de la réorganisation des identifiants de position.

Pour simplifier un peu les choses, voici des règles claires pour déterminer quand envisager le CAG :

• Lorsque votre base de connaissances entre dans la fenêtre de contexte du modèle
• Lorsque vous avez besoin de réponses extrêmement rapides
• Lorsque votre information ne change pas souvent
• Lorsque des coûts globaux plus élevés sont acceptables pour votre cas d’utilisation
• Lorsque vous n’observez aucune baisse notable de la qualité des outputs par rapport au RAG
• Si vous hébergez le modèle, envisagez le CAG lorsque vous avez assez de mémoire GPU. Oui, ce cache KV doit se trouver quelque part et prend beaucoup d’espace en remplissant la fenêtre de contexte ! Si vous utilisez le modèle via une API, oubliez ce point. Vous pouvez simplement régler la fonctionnalité de cache à True et ne plus y penser !

Vous pourriez par exemple utiliser le CAG pour un chatbot qui doit répondre souvent aux mêmes FAQ afin qu’il sache toujours quoi dire. Vous pourriez aussi répondre rapidement aux questions sur un rapport précis ou l’enregistrement d’une réunion, par exemple en créant pour YouTube une extension qui permet de « discuter avec vos vidéos ».

Si vous voulez une analogie simple pour prendre votre décision, imaginez que vous devez passer un examen et avez un choix à faire. Préférez-vous avoir accès au manuel complet et devoir y chercher l’information à mesure que vous avancez, ou avoir mémorisé parfaitement et à l’avance uniquement les chapitres 6 et 7 ? Les deux approches fonctionnent, mais excellent dans différentes situations ! Le RAG sera préférable si vous avez besoin du livre complet 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 posent la question, oui, vous pourriez combiner le CAG et le RAG dans une approche hybride. Vous pouvez placer dans le CAG l’information la plus souvent consultée pour y accéder instantanément, puis utiliser le RAG pour les détails plus rarement nécessaires. C’est comme posséder à la fois une mémoire parfaite dans votre domaine de spécialisation et une immense bibliothèque à votre disposition pour tous les faits !

À mesure que les LLMs géreront mieux les contextes immenses à moindre coût, une fonctionnalité de mise en cache du contexte bien implémentée pourrait devenir l’option par défaut de la plupart des projets, simplement parce qu’elle est très efficace. Le RAG restera toutefois probablement indispensable dans les cas limites où les bases de connaissances sont exceptionnellement volumineuses ou très dynamiques.

J’espère que cet article vous a aidé à comprendre ce qu’est le CAG, en quoi il diffère du RAG et quand utiliser les deux. Si vous le trouvez utile, partagez-le avec vos amis dans la communauté de l’IA et n’oubliez pas de suivre l’infolettre pour recevoir plus de contenu approfondi sur l’IA !

Merci d’avoir lu !

FAQ

Quelle est la différence entre le CAG et le RAG ?

Le RAG récupère des documents pertinents lorsqu’une question arrive. Le CAG précharge le contexte pour que le modèle réponde à partir de l’information en cache.

Quand devriez-vous utiliser le CAG plutôt que le RAG ?

Le CAG mérite d’être testé lorsque les données sont assez petites et stables pour tenir dans le contexte et qu’il est utile de les garder prêtes.

Quelle est l’erreur courante avec le CAG ?

L’erreur consiste à croire qu’un long contexte élimine le travail de recherche d’information. Les données volumineuses, changeantes ou désordonnées exigent encore une sélection et une évaluation.

Pourquoi la mise en cache du contexte peut-elle être efficace ?

La réutilisation des clés et des valeurs évite de retraiter constamment le même contexte stable, ce qui réduit la latence et les calculs répétés.

Pourquoi le RAG reste-t-il préférable pour les connaissances qui changent ?

La recherche peut consulter des collections mises à jour ou très volumineuses au moment de la requête au lieu de tout placer dans un contexte fixe en cache.