GPTCache, LangChain, Alliance forte
Introduction à GPTCache
ChatGPT et d’autres grands modèles de langage (LLMs) offrent une polyvalence incroyable qui peut être utilisée pour un large éventail de développements d’applications. Cependant, à mesure que la popularité des applications développées avec des LLMs augmente et que les niveaux de trafic croissent, le coût associé aux appels d’API LLM peut devenir prohibitif. De plus, les services LLM peuvent présenter des temps de réponse lents lors du traitement de grands volumes de requêtes.
Pour relever ce défi, nous avons créé le projet GPTCache, dédié à la création d’un cache sémantique pour stocker les réponses des LLM.
Introduction à LangChain
Les grands modèles de langage (LLMs) deviennent une technologie transformatrice qui permet aux développeurs de créer des applications auparavant impossibles. Cependant, s’appuyer uniquement sur un seul LLM rend souvent difficile la création d’une application véritablement puissante. La véritable puissance réside dans leur combinaison avec d’autres sources de calcul ou de connaissances. Par conséquent, la bibliothèque LangChain vise à aider au développement de ces types d’applications.
État actuel du cache LangChain
Avant l’intégration de GPTCache, le cache LangChain était basé sur la correspondance de chaînes. Avec cette approche de correspondance de chaînes, la requête ultérieure peut récupérer les données correspondantes depuis le cache lorsque deux requêtes ont des chaînes identiques. L’implémentation inclut Memory Cache, SQLite Cache et Redis Cache.
L’utilisation est approximativement la suivante :
import langchain
from langchain.cache import InMemoryCache
langchain.llm_cache = InMemoryCache()
llm = OpenAI(model_name="text-davinci-002", n=2, best_of=2)
// CPU times: user 14.2 ms, sys: 4.9 ms, total: 19.1 ms
// Wall time: 1.1 s
llm("Tell me a joke")
// CPU times: user 162 µs, sys: 7 µs, total: 169 µs
// Wall time: 175 µs
llm("Tell me a joke")
Analyse du cache LangChain
Du point de vue du temps d’exécution, il est clair que si une requête atteint le cache, cela réduira considérablement le temps de réponse. Dans le même temps, le coût actuel de l’utilisation des LLM est relativement élevé. L’utilisation de services en ligne tels qu’OpenAI et Cohere entraîne généralement des frais via des tokens, ou le déploiement du modèle LLM correspondant par soi-même, le temps d’inférence ponctuel dépendant du nombre de ressources informatiques, notamment le CPU, la mémoire, le GPU, etc. En même temps, si plusieurs requêtes sont traitées simultanément, les exigences en matière de ressources de calcul sont plus élevées. Si les requêtes atteignent le cache de nombreuses fois, cela peut réduire la pression sur les ressources informatiques et attribuer davantage de ressources de calcul à d’autres tâches.
La condition pour que LangChain atteigne le cache est que deux questions doivent être identiques. Malheureusement, il reste difficile d’atteindre le cache en utilisation réelle, et il existe une grande marge d’amélioration du taux d’utilisation du cache.
Intégration de GPTCache
L’intégration de GPTCache améliorera considérablement les fonctionnalités du module de cache LangChain, augmentera le taux de réussite du cache et réduira ainsi les coûts d’utilisation des LLM et les temps de réponse. En effet, GPTCache effectue d’abord des opérations d’embedding sur l’entrée afin d’obtenir un vecteur, puis réalise une recherche approximative de vecteurs dans le stockage du cache. Après réception des résultats de recherche, il effectue une évaluation de similarité et renvoie le résultat lorsque le seuil défini est atteint. L’ajustement du seuil peut modifier la précision de ses résultats de recherche floue.
Un exemple d’utilisation de GPTCache pour la recherche de similarité dans LangChain :
from gptcache import Cache
from gptcache.adapter.api import init_similar_cache
from langchain.cache import GPTCache
import hashlib
def get_hashed_name(name):
return hashlib.sha256(name.encode()).hexdigest()
def init_gptcache(cache_obj: Cache, llm: str):
hashed_llm = get_hashed_name(llm)
init_similar_cache(cache_obj=cache_obj, data_dir=f"similar_cache_{hashed_llm}")
langchain.llm_cache = GPTCache(init_gptcache)
# La première fois, ce n’est pas encore en cache, donc cela devrait prendre plus de temps
# CPU times: user 1.42 s, sys: 279 ms, total: 1.7 s
# Wall time: 8.44 s
llm("Tell me a joke")
# Il s’agit d’une correspondance exacte, donc il la trouve dans le cache
# CPU times: user 866 ms, sys: 20 ms, total: 886 ms
# Wall time: 226 ms
llm("Tell me a joke")
# Ce n’est pas une correspondance exacte, mais elle est sémantiquement dans la distance, donc c’est un succès !
# CPU times: user 853 ms, sys: 14.8 ms, total: 868 ms
# Wall time: 224 ms
llm("Tell me joke")
Nous continuons à développer les fonctionnalités de GPT-Cache, et si vous avez l’occasion de l’essayer, dites-nous ce que vous en pensez. Nous avons également plusieurs excellentes ressources à vous proposer !
Références :
Continuer à lire
Zilliz Cloud On-Demand Compute: Pay Only for What You Use
The customer case behind Zilliz Cloud On-Demand: how a $10K vector search bill came down to under $500, and the engineering changes that made it possible.
How to Choose the Best Embedding Model for RAG in 2026: 10 Models Benchmarked
We benchmarked 10 embedding models on cross-modal, cross-lingual, long-document, and dimension compression tasks. See which one fits your RAG pipeline.
Milvus WebUI: A Visual Management Tool for Your Vector Database
Explore Milvus WebUI to monitor, manage, and optimize your vector database with real-time insights, performance tracking, and system health monitoring.