Encore un autre cache, mais pour ChatGPT
ChatGPT est une technologie impressionnante qui permet aux développeurs de créer des applications révolutionnaires. Cependant, les performances et le coût des grands modèles de langage (LLM) sont des problèmes majeurs qui freinent leur application généralisée dans divers domaines. Par exemple, lorsque nous avons développé un chatbot https://osschat.io/ pour la communauté open source, ChatGPT constituait un goulot d'étranglement majeur empêchant notre application de répondre aussi rapidement que prévu. Le coût est également un autre obstacle qui nous empêche de servir davantage de communautés open source.
Lors d’un déjeuner d’équipe, une idée nous est venue à l’esprit : pourquoi ne pas ajouter une autre couche de cache pour les réponses générées par les LLM ? Cette couche de cache serait similaire à la façon dont Redis et Memcache ont été conçus par le passé pour accélérer et réduire le coût de l’accès aux bases de données. Avec ce cache, nous pouvons réduire les dépenses liées à la génération de contenu et fournir des réponses en temps réel plus rapides. De plus, le cache peut être utilisé pour simuler des réponses, ce qui nous aide à vérifier les fonctionnalités de notre application sans engager de dépenses supplémentaires lors de nos tests.
Les caches traditionnels ne récupèrent les données que lorsque la clé est identique. Cette limitation pose un problème important pour les applications AIGC, qui fonctionnent souvent avec le langage naturel et nécessitent des restrictions syntaxiques plus spécifiques ou des mécanismes supplémentaires de nettoyage des données. Pour résoudre ce problème, nous avons créé Yet Another Cache pour les applications natives AIGC, que nous avons nommé GPTCache (https://github.com/zilliztech/GPTCache), car il est conçu nativement pour accélérer ChatGPT et optimisé pour la recherche sémantique.
Avec GPTCache, vous pouvez mettre en cache vos réponses LLM avec seulement quelques lignes de modifications de code, rendant vos applications LLM 100 fois plus rapides. Dans cet article de blog, nous décrirons comment nous avons construit le cache sémantique et certains des choix de conception que nous avons faits.
Pourquoi un cache serait-il utile dans nos cas d’utilisation ?
Notre chatbot permet aux utilisateurs de poser des questions générales sur des projets open source sur GitHub et des questions détaillées sur des dépôts GitHub spécifiques ainsi que sur leurs pages de documentation associées. À mesure que notre service gagne en popularité, les dépenses liées aux appels aux API OpenAI augmentent. Nous avons observé que certains types de contenu, tels que les sujets populaires ou tendance et les dépôts GitHub très consultés, sont accédés plus fréquemment. Les questions de type « Qu’est-ce que » sont les plus couramment consultées, tout comme la liste de questions recommandées sur la page d’accueil du service.
Comme les applications traditionnelles, l’accès des utilisateurs aux applications AIGC présente une localité temporelle et spatiale. Nous pouvons en tirer parti en mettant en œuvre un système de cache qui réduit le nombre d’appels à ChatGPT. Compte tenu du temps de réponse lent et du coût élevé des API OpenAI, ce système de cache est essentiel, celles-ci facturant généralement plusieurs dollars par million de tokens et prenant quelques secondes pour répondre. En effectuant une recherche vectorielle parmi des millions de vecteurs mis en cache et en récupérant le résultat mis en cache depuis une base de données, nous pouvons réduire considérablement le temps de réponse moyen de bout en bout de notre service et diminuer le coût du service OpenAI.
Pourquoi Redis ne fonctionnera-t-il pas dans les scénarios AIGC ?
Je suis un grand fan de Redis en raison de sa flexibilité et de ses performances, qui le rendent adapté à divers cas d’utilisation. Cependant, ce n’est pas mon premier choix pour construire un cache pour ChatGPT. Redis utilise un modèle de données clé-valeur et ne peut pas interroger des clés approximatives.
Par exemple, supposons qu’un utilisateur pose des questions comme « Quels sont les avantages et les inconvénients de tous les frameworks de deep learning ? » ou « Parle-moi de PyTorch vs. TensorFlow vs. JAX ? ». Dans ce cas, il demande la même chose. Cependant, Redis ne parvient pas à faire correspondre la requête, que vous mettiez en cache la question entière ou uniquement les mots-clés générés par un tokenizer. Cet échec s’explique par le fait que des mots différents peuvent avoir le même sens en langage naturel, et les modèles de deep learning sont plus aptes à révéler ces sémantiques que des règles. Par conséquent, nous devrions intégrer la recherche par similarité vectorielle dans un cache sémantique.
Une autre raison pour laquelle Redis peut ne pas être parfaitement adapté à la mise en cache AIGC est son coût élevé. Les clés et les valeurs sont volumineuses en raison du long contexte, donc tout stocker dans Redis peut rapidement devenir coûteux. La mise en cache avec une base de données basée sur disque peut être une meilleure alternative, car les réponses de chatGPT sont lentes, donc peu importe que le cache puisse répondre en moins d’une milliseconde ou en quelques dizaines de millisecondes.
Construire GPTCache à partir de zéro
Nous sommes enthousiasmés par cette idée et en avons discuté toute la nuit. En conséquence, nous avons conçu un diagramme d’architecture utile présenté ci-dessous :
Architecture de haut niveau de GPTCache | Zilliz
Plus tard, nous avons décidé de simplifier l’implémentation en supprimant le gestionnaire de contexte. Malgré ces changements, le système se compose toujours de cinq composants principaux. Nous avons répertorié ci-dessous les fonctionnalités importantes de chacun des composants :
- Adaptateur LLM : Les adaptateurs convertissent les requêtes LLM en protocole de cache et les résultats mis en cache en réponses LLM. Nous visons à rendre ce cache transparent, sans effort supplémentaire pour l’intégrer dans notre système ou dans tout autre système qui dépend de ChatGPT. L’adaptateur doit faciliter l’intégration de tous les LLMs et être extensible pour les futurs modèles multimodaux. Initialement, nous avons implémenté des adaptateurs OpenAI et langchain parce que notre système en dépend fortement. Plusieurs implémentations ont également garanti que notre interface était pertinente pour toutes les APIs LLM, afin que nous puissions étendre davantage l’adaptateur.
- Générateur d’embeddings : Le générateur d’embeddings encode les requêtes en embeddings, permettant des recherches de similarité. Pour répondre aux besoins de différents utilisateurs, nous prenons en charge deux façons de générer des embeddings. La première passe par des services cloud comme OpenAI, Hugging Face et Cohere. La seconde passe par un modèle local servi sur ONNX. De plus, nous prévoyons de prendre en charge les générateurs d’embeddings PyTorch et d’encoder des images, des fichiers audio et d’autres types de données non structurées.
- Gestionnaire de cache : Le gestionnaire de cache est le composant central de GPTCache, remplissant trois fonctions : le stockage du cache, qui stocke les requêtes des utilisateurs et leurs réponses LLM ; le stockage vectoriel, qui stocke les embeddings vectoriels et recherche des résultats similaires ; et la gestion de l’éviction, qui contrôle la capacité du cache et évince les données expirées lorsque le cache est plein, en utilisant soit la politique LRU soit la politique FIFO. Le Gestionnaire de cache utilise une conception enfichable. Initialement, nous l’avons implémenté avec SQLite et FAISS comme backend. Plus tard, nous l’avons étendu pour inclure d’autres implémentations telles que MySQL, PostgreSQL, Milvus, et d’autres bases de données vectorielles, le rendant encore plus évolutif. Le Gestionnaire d’éviction libère de la mémoire en supprimant les anciennes données inutilisées de GPTCache. Il supprime les entrées à la fois du cache et du stockage vectoriel lorsque cela est nécessaire. Cependant, les suppressions fréquentes dans la plupart des systèmes de stockage vectoriel peuvent entraîner une baisse des performances. GPTCache déclenche des opérations asynchrones telles que la construction d’index ou la compaction une fois le seuil de suppression atteint afin d’atténuer ce problème.
- Évaluateur de similarité : Le GPTCache récupère les k meilleures réponses similaires depuis son cache et utilise une fonction d’évaluation de similarité pour déterminer si une réponse mise en cache correspond à la requête d’entrée. GPTCache prend en charge trois fonctions d’évaluation : l’évaluation par correspondance exacte, l’évaluation par distance d’embedding et l’évaluation par modèle ONNX. Le module d’évaluation de similarité est crucial pour l’efficacité de GPTCache. Après investigation, nous avons utilisé une version affinée du modèle ALBERT. Cependant, il est toujours possible de l’améliorer en utilisant d’autres modèles de langage affinés ou d’autres LLMs tels que LLaMa-7b. Toute contribution ou suggestion serait la bienvenue.
- Post-processeurs : Le Post-processeur aide à préparer la réponse finale à l’utilisateur. Il peut retourner la réponse la plus similaire ou ajouter de l’aléatoire en fonction de la température de la requête. Si aucune réponse similaire ne peut être trouvée dans le cache, la requête sera déléguée aux LLMs pour générer et mettre en cache une nouvelle réponse.
Évaluation
Pour illustrer notre idée, nous avons découvert un jeu de données contenant trois paires de phrases : des échantillons positifs avec une sémantique identique, des échantillons négatifs avec une sémantique liée mais non identique, et des phrases entre les échantillons positifs et négatifs avec une sémantique complètement sans rapport. Vous pouvez trouver le jeu de données dans notre repo.
Expérience 1
Pour établir une référence, nous mettons d’abord en cache les clés des 30 000 échantillons positifs. Ensuite, nous sélectionnons aléatoirement 1 000 échantillons et utilisons leurs valeurs homologues comme requêtes. Voici les résultats que nous avons obtenus :
| Cache atteint | Cache manqué | Positif | Négatif | Latence d’atteinte |
|---|---|---|---|---|
| 876 | 124 | 837 | 39 | 0.20s |
Nous avons découvert que le fait de définir le seuil de similarité de GPTCache à 0,7 permet d’obtenir un bon équilibre entre le ratio de hits et le ratio positif. Nous utiliserons donc ce paramètre pour tous les tests ultérieurs.
Pour déterminer si le résultat mis en cache est positif ou négatif par rapport à la requête, nous utilisons le score de similarité généré par ChatGPT et fixons le seuil positif à 0,6. Nous générons ce score de similarité à l’aide du prompt suivant :
Please rate the similarity of the following two questions on a scale from 0 to 1, where 0 means not related and 1 means exactly the same meaning.
The questions "What are some good tips for self-study?" and "What are the smart tips for self-studying?" are very similar, with a similarity score of 1.0.
The questions "What are some essential things for wilderness survival?" and "What are the things you need for survival?" are quite similar, with a similarity score of 0.8.
The questions "What advice would you give to 16-year-old you?" and "Where should I promote my business online?" are completely different, so the similarity score is 0.
So, questions "Which app lets you watch live football for free?" and "How can I watch a football live match on my phone?" The similarity score is
Expérience 2
Nous avons envoyé des requêtes composées de 50 % d’échantillons positifs et de 50 % d’échantillons négatifs (requêtes non liées). En conséquence, après avoir exécuté 1160 requêtes, nous avons obtenu les résultats suivants :
| Hit du cache | Miss du cache | Positif | Négatif | Latence du hit |
|---|---|---|---|---|
| 570 | 590 | 549 | 21 | 0.17s |
Le ratio de hits est presque de 50 %, et le ratio négatif parmi les résultats avec hit est similaire à celui de l’expérience 1, ce qui signifie que GPTCache a fait un travail remarquable pour distinguer les requêtes liées et non liées.
Expérience 3
Nous avons mené une autre expérience, en insérant tous les échantillons négatifs dans le cache et en utilisant leurs valeurs appariées comme requêtes. Bien que certaines paires d’échantillons négatifs aient eu un score de similarité élevé (supérieur à 0,9, selon ChatGPT), à notre grande surprise, aucun des exemples négatifs n’a atteint le cache. Cela est probablement dû au fait que le modèle utilisé dans l’évaluateur de similarité est affiné sur ce jeu de données, et que presque tous les scores de similarité des échantillons négatifs ont été sous-évalués.
Évaluation future
Nous avons intégré GPTCache à notre site web OSSChat et travaillons maintenant à la collecte de statistiques de production. Restez donc à l’écoute pour la publication de notre prochain benchmark, qui inclura des cas d’utilisation réels.
C’est la fin du blog, mais seulement le début pour GPTCache
Nous sommes ravis de la rapidité avec laquelle nous avons pu implémenter et rendre open source un travail aussi remarquable en moins de deux semaines. Bravo ! Nous espérons que vous comprenez maintenant pleinement l’idée de GPTCache, la façon dont il a été implémenté, et que vous avez une multitude d’idées sur la manière de l’intégrer à votre système.
Récapitulons rapidement quelques-uns des points clés concernant GPTCache :
- ChatGPT est impressionnant, mais il peut parfois être coûteux et lent.
- Comme dans d’autres applications, nous pouvons observer de la localité dans les cas d’utilisation de l’AIGC.
- Pour exploiter pleinement cette localité, tout ce dont vous avez besoin est un cache sémantique.
- Pour construire un cache sémantique, intégrez le contexte de votre requête et stockez-le dans une base de données vectorielle. Ensuite, recherchez des requêtes similaires dans le cache avant d’envoyer la requête aux LLMs.
- N’oubliez pas de gérer la capacité du cache !
Nous travaillons actuellement à l’intégration de GPTCache avec davantage de LLMs et de bases de données vectorielles. Bientôt, nous publierons le GPTCache Bootcamp, qui expliquera comment utiliser GPTCache avec LangChain et Hugging Face, ainsi que d’autres idées pour rendre GPTCache multimodal. Nous accueillons volontiers toute contribution ou suggestion et vous encourageons à nous montrer comment GPTCache vous aide dans votre application !
En savoir plus sur GPTCache
Continuer à lire
Build for the Boom: Why AI Agent Startups Should Build Scalable Infrastructure Early
Explore strategies for developing AI agents that can handle rapid growth. Don't let inadequate systems undermine your success during critical breakthrough moments.
Vector Databases vs. Key-Value Databases
Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.