Otra caché más, pero para ChatGPT
ChatGPT es una tecnología impresionante que permite a los desarrolladores crear aplicaciones revolucionarias. Sin embargo, el rendimiento y el costo de los modelos de lenguaje (LLMs) son problemas significativos que obstaculizan su aplicación generalizada en diversos campos. Por ejemplo, mientras desarrollábamos un chatbot https://osschat.io/ para la comunidad de código abierto, ChatGPT era un importante cuello de botella que impedía que nuestra aplicación respondiera tan rápido como se esperaba. El costo también es otro obstáculo que nos impide servir a más comunidades de código abierto.
En un almuerzo de equipo, surgió una idea: ¿Por qué no añadir otra capa de caché para las respuestas generadas por LLM? Esta capa de caché sería similar a cómo se crearon Redis y Memcache en el pasado para acelerar y reducir el costo de acceder a bases de datos. Con esta caché, podemos disminuir los gastos de generación de contenido y proporcionar respuestas en tiempo real más rápidas. Además, la caché puede utilizarse para simular respuestas, lo que nos ayuda a verificar las funciones de nuestra aplicación sin incurrir en gastos adicionales en nuestras pruebas.
Las cachés tradicionales solo recuperan datos cuando la clave es idéntica. Esta limitación presenta un problema significativo para las aplicaciones AIGC que a menudo trabajan con lenguaje natural y necesitan restricciones de sintaxis más específicas o mecanismos adicionales de limpieza de datos. Para abordar este problema, creamos Yet Another Cache para aplicaciones nativas de AIGC, que llamamos GPTCache (https://github.com/zilliztech/GPTCache) ya que está construido de forma nativa para acelerar ChatGPT y optimizado para la búsqueda semántica.
Con GPTCache, puedes almacenar en caché tus respuestas de LLM con solo unas pocas líneas de cambios en el código, acelerando tus aplicaciones LLM 100 veces. En esta entrada del blog, describiremos cómo construimos la caché semántica y algunas de las decisiones de diseño que tomamos.
¿Por qué una caché ayudaría en nuestros casos de uso?
Nuestro chatbot permite a los usuarios hacer preguntas generales sobre proyectos de código abierto en GitHub y preguntas detalladas sobre repositorios específicos de GitHub y sus páginas de documentación asociadas. A medida que nuestro servicio gana popularidad, aumentan los gastos asociados con llamar a las APIs de OpenAI. Hemos observado que ciertos tipos de contenido, como temas populares o en tendencia y repositorios populares de GitHub, se acceden con más frecuencia. Las preguntas de "Qué es" son las más comúnmente accedidas, junto con la lista de preguntas recomendadas en la página principal del servicio.
Al igual que las aplicaciones tradicionales, el acceso de los usuarios para aplicaciones AIGC tiene localidad temporal y espacial. Podemos aprovechar esto implementando un sistema de caché que reduzca el número de llamadas a ChatGPT. Dado el tiempo de respuesta lento y el alto costo de las APIs de OpenAI, este sistema de caché es esencial, ya que normalmente cobra varios dólares por 1 millón de tokens y tarda unos segundos en responder. Al realizar una búsqueda vectorial entre millones de vectores almacenados en caché y recuperar el resultado almacenado en caché de una base de datos, podemos reducir significativamente el tiempo promedio de respuesta de extremo a extremo de nuestro servicio y disminuir el costo del servicio de OpenAI.
¿Por qué Redis no funcionará en escenarios AIGC?
Soy un gran admirador de Redis por su flexibilidad y rendimiento, lo que lo hace adecuado para varios casos de uso. Sin embargo, no es mi primera opción para construir una caché para ChatGPT. Redis utiliza un modelo de datos clave-valor y no puede consultar claves aproximadas.
Por ejemplo, supongamos que un usuario hace preguntas como "¿Cuáles son las ventajas y desventajas de todos los frameworks de aprendizaje profundo?" o "Háblame de PyTorch vs. TensorFlow vs. JAX?". En ese caso, está preguntando lo mismo. Sin embargo, Redis no logra acertar la consulta, ya sea que almacenes en caché la pregunta completa o solo almacenes en caché las palabras clave generadas por un tokenizer. Este fallo se debe a que diferentes palabras pueden tener el mismo significado en lenguaje natural, y los modelos de aprendizaje profundo son mejores para revelar estas semánticas que las reglas. Por lo tanto, deberíamos incorporar la búsqueda de similitud vectorial como parte de una caché semántica.
Otra razón por la que Redis puede no ser la opción perfecta para el almacenamiento en caché de AIGC es su alto costo. Las claves y los valores son grandes debido al contexto extenso, por lo que almacenar todo en Redis puede volverse costoso rápidamente. El almacenamiento en caché con una base de datos basada en disco puede ser una mejor alternativa porque las respuestas de chatGPT son lentas, así que no importa si la caché puede responder en submilisegundos o en decenas de milisegundos.
Crear GPTCache desde cero
Estamos entusiasmados con esta idea y la discutimos durante la noche. Como resultado, se nos ocurrió un diagrama de arquitectura útil que se muestra a continuación:
Arquitectura de alto nivel de GPTCache | Zilliz
Más tarde, decidimos simplificar la implementación omitiendo el administrador de contexto. A pesar de estos cambios, el sistema sigue constando de cinco componentes principales. A continuación, enumeramos las funcionalidades significativas de cada uno de los componentes:
- Adaptador LLM: Los adaptadores convierten las solicitudes LLM en protocolo de caché y los resultados almacenados en caché en respuestas LLM. Nuestro objetivo es hacer que esta caché sea transparente, sin requerir ningún esfuerzo adicional para integrarla en nuestro sistema o en cualquier otro sistema que dependa de ChatGPT. El adaptador debe facilitar la integración sencilla de todos los LLM y ser extensible para futuros modelos multimodales. Inicialmente, implementamos adaptadores de OpenAI y langchain porque nuestro sistema depende en gran medida de ellos. Múltiples implementaciones también garantizaron que nuestra interfaz tuviera sentido para todas las API de LLM, de modo que pudiéramos ampliar aún más el adaptador.
- Generador de embeddings: El generador de embeddings codifica consultas en embeddings, lo que permite búsquedas por similitud. Para satisfacer las necesidades de diferentes usuarios, admitimos dos formas de generar embeddings. La primera es a través de servicios en la nube como OpenAI, Hugging Face y Cohere. La segunda es a través de un modelo local servido en ONNX. Además, planeamos admitir generadores de embeddings de PyTorch y codificar imágenes, archivos de audio y otros tipos de datos no estructurados.
- Gestor de caché: El gestor de caché es el componente central de GPTCache, y cumple tres funciones: almacenamiento de caché, que almacena las solicitudes de los usuarios y sus respuestas LLM; almacenamiento vectorial, que almacena embeddings vectoriales y busca resultados similares; y gestión de expulsión, que controla la capacidad de la caché y expulsa datos caducados cuando la caché está llena, utilizando la política LRU o FIFO. El Gestor de caché utiliza un diseño conectable. Inicialmente, lo implementamos con SQLite y FAISS como backend. Más tarde, lo ampliamos para incluir otras implementaciones como MySQL, PostgreSQL, Milvus, y otras bases de datos vectoriales, lo que lo hace aún más escalable. El Gestor de expulsión libera memoria eliminando datos antiguos y no utilizados de GPTCache. Elimina entradas tanto de la caché como del almacenamiento vectorial cuando es necesario. Sin embargo, las eliminaciones frecuentes en la mayoría de los sistemas de almacenamiento vectorial pueden causar una caída en el rendimiento. GPTCache activa operaciones asíncronas como la construcción de índices o la compactación una vez que se alcanza el umbral de eliminación para mitigar este problema.
- Evaluador de similitud: GPTCache recupera las k respuestas similares principales de su caché y utiliza una función de evaluación de similitud para determinar si una respuesta almacenada en caché coincide con la consulta de entrada. GPTCache admite tres funciones de evaluación: evaluación de coincidencia exacta, evaluación de distancia de embeddings y evaluación de modelo ONNX. El módulo de evaluación de similitud es crucial para la efectividad de GPTCache. Tras la investigación, utilizamos una versión ajustada del modelo ALBERT. Sin embargo, siempre hay margen de mejora utilizando otros modelos de lenguaje ajustados u otros LLM como LLaMa-7b. Cualquier contribución o sugerencia será muy bienvenida.
- Postprocesadores: El Postprocesador ayuda a preparar la respuesta final para el usuario. Puede devolver la respuesta más similar o añadir aleatoriedad según la temperatura de la solicitud. Si no se puede encontrar una respuesta similar en la caché, la solicitud se delegará a los LLM para generar y almacenar en caché una nueva respuesta.
Evaluación
Para ilustrar nuestra idea, hemos descubierto un conjunto de datos que contiene tres pares de oraciones: muestras positivas con semántica idéntica, muestras negativas con semántica relacionada pero no idéntica, y oraciones entre muestras positivas y negativas con semántica completamente no relacionada. Puedes encontrar el conjunto de datos en nuestro repo.
Experimento 1
Para establecer una línea base, primero almacenamos en caché las claves de las 30.000 muestras positivas. A continuación, seleccionamos aleatoriamente 1.000 muestras y usamos sus valores pares como consultas. Estos son los resultados que obtuvimos:
| Acierto de caché | Fallo de caché | Positivo | Negativo | Latencia de acierto |
|---|---|---|---|---|
| 876 | 124 | 837 | 39 | 0.20s |
Hemos descubierto que establecer el umbral de similitud de GPTCache en 0.7 logra un buen equilibrio entre las ratios de aciertos y positivos. Por lo tanto, usaremos esta configuración para todas las pruebas posteriores.
Para determinar si el resultado en caché es positivo o negativo con respecto a la consulta, usamos la puntuación de similitud generada por ChatGPT y establecemos el umbral positivo en 0.6. Generamos esta puntuación de similitud usando el siguiente prompt:
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
Experimento 2
Emitimos consultas compuestas por un 50% de muestras positivas y un 50% de muestras negativas (consultas no relacionadas). Como resultado, después de ejecutar 1160 solicitudes, obtuvimos los siguientes resultados:
| Acierto de caché | Fallo de caché | Positivo | Negativo | Latencia de acierto |
|---|---|---|---|---|
| 570 | 590 | 549 | 21 | 0.17s |
La ratio de aciertos es casi del 50%, y la ratio negativa entre los resultados con acierto es similar a la del experimento 1, lo que significa que GPTCache hizo un trabajo increíble al distinguir consultas relacionadas y no relacionadas.
Experimento 3
Realizamos otro experimento, insertando todas las muestras negativas en la caché y usando sus valores pares como consultas. Aunque algunos pares de muestras negativas tenían una puntuación de similitud alta (mayor que 0.9, según ChatGPT), para nuestra sorpresa, ninguno de los ejemplos negativos llegó a la caché. Esto probablemente se debe a que el modelo usado en el evaluador de similitud está ajustado con este conjunto de datos, y casi todas las puntuaciones de similitud de las muestras negativas han sido infravaloradas.
Evaluación futura
Hemos integrado GPTCache en nuestro sitio web OSSChat y ahora estamos trabajando en recopilar estadísticas de producción. Así que mantente atento al lanzamiento de nuestro próximo benchmark, que incluirá casos de uso del mundo real.
Es el final del blog, pero solo el comienzo para GPTCache
Estamos satisfechos con la rapidez con la que pudimos implementar y hacer open-source una pieza de trabajo tan increíble en menos de dos semanas. ¡Bravo! Con suerte, ahora entiendes completamente la idea de GPTCache, cómo se implementó, y tienes una gran cantidad de ideas sobre cómo puede integrarse en tu sistema.
Recapitulemos rápidamente algunas de las notas clave sobre GPTCache:
- ChatGPT es impresionante, pero puede ser caro y lento a veces.
- Al igual que en otras aplicaciones, podemos ver localidad en casos de uso de AIGC.
- Para utilizar plenamente esta localidad, todo lo que necesitas es una caché semántica.
- Para construir una caché semántica, incrusta el contexto de tu consulta y almacénalo en una base de datos vectorial. Luego, busca consultas similares en la caché antes de enviar la solicitud a los LLMs.
- ¡Recuerda gestionar la capacidad de la caché!
Actualmente estamos trabajando en integrar GPTCache con más LLMs y bases de datos vectoriales. Pronto, lanzaremos el GPTCache Bootcamp, que explicará cómo usar GPTCache junto con LangChain y Hugging Face, así como otras ideas para hacer que GPTCache sea multi-modal. ¡Damos la bienvenida a cualquier contribución o sugerencia y te animamos a mostrarnos cómo GPTCache te ayuda en tu aplicación!
Obtén más información sobre GPTCache
Sigue leyendo
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.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.
DeepSeek Always Busy? Deploy It Locally with Milvus in Just 10 Minutes—No More Waiting!
Learn how to set up DeepSeek-R1 on your local machine using Ollama, AnythingLLM, and Milvus in just 10 minutes. Bypass busy servers and enhance AI responses with custom data.