Optimice los costos de uso de LLM con Semantic Cache

Construí un sistema de informes de chat bot de lengua natural, alimentado por Retrieval Augmented Generation (RAG). Proporcionó una gran experiencia al usuario, pudieron consultar los datos y obtener informes decidos y cortados por las dimensiones que querían. Fue intuitivo y proporcionó eficiencia. Luego, llegó la ley de API LLM. Fue entonces cuando me di cuenta de que en mi búsqueda de construir esta inteligencia, había creado un agujero negro financiero. Luego, llegó la ley de API LLM. Fue entonces cuando me di cuenta de que en mi búsqueda de construir esta inteligencia, había creado un agujero negro financiero. En cada entorno, estos sistemas de IA de la Agencia realizan cientos y miles de llamadas LLM, comenzando con el desarrollo, eval, las pruebas de aceptación del usuario y luego en el entorno de producción. Para generar respuestas fundamentadas, implementamos Retrieval Augmented Generation (RAG). Esto significa que consultamos las tiendas vectoriales para contenidos similares y pasamos los datos recuperados con las preguntas del usuario, prompts, ejemplos, instrucciones de guardrails, esquema de respuesta estructurada, etc. a LLM. Esto significa que para una pregunta simple, agregamos cientos de tokens adicionales en el nombre del contexto, guardrails y algunos prompts de disparo, etc. Los modelos de idiomas grandes (LLM) analizan estos como tokens y hacen su trabajo para generar la respuesta y luego obtenemos la respuesta a nuestra pregunta. Esta respuesta puede ser una respuesta a nuestra pregunta o puede ser una respuesta estructurada a uno de los pasos en un flujo de trabajo multiagente. Esto significa que para ejecutar un flujo de trabajo con varios ag En mi sistema, el sistema extrae datos de Vector DB y Knowledge Graph para fundamentar la respuesta. Observé alrededor de ~2000 tokens de entrada en la ventana de contexto. El LLM luego genera una reflexiva respuesta de 500 tokens. A primera vista, eso es solo unos pocos centavos. Pero con 200.000 consultas al día, esos "centavos" se transforman en un monstruo. Solo añade ese uso con múltiples usuarios durante las fases de desarrollo y evaluación también. Actualmente el coste por millón de tokens de uso como la entrada y la salida parece más barato ya que estamos en las primeras etapas de la adopción de LLM api y los proveedores de servicios han dado deliberadamente muchos descuentos. En el futuro estos precios van a subir, y entonces el coste general desde el desarrollo hasta la producción hasta el soporte y mantenimiento de estos sistemas También puede referirse a un par de artículos citando los desafíos en torno al coste del LLM. La guerra de precios de LLM está dañando la educación - y las startups Cómo escalar la IA empresarial con el LLM equivocado podría costarte He construido sistemas basados en RAG usando LangGraph, Neo4j, ChromaDB y Redis. Llevo este patrón de arquitectura llamado Semantic Cache y detalles de implementación para reducir la quema de token en la producción. Este patrón puede reducir el coste de uso de su LLM mediante el caché y la respuesta a preguntas similares en lugar de invocar el LLM cada vez. Déjame presentarle este patrón que puede aplicar en múltiples casos de uso y en múltiples puntos de contacto en su flujo de trabajo de la Agentic AI. Qué es el escondite Cache ha existido durante siglos en nuestra arquitectura de sistema de TI. Comenzó con In-Memory, luego se distribuyó. Inicialmente hubo pocas ofertas limitadas para la implementación on-prem o basada en VM. Con el advenimiento de la nube, muchas ofertas de nube evolucionaron. En la actualidad, tenemos sistemas de cache bastante maduros. Sin embargo, el uso del sistema de cache se ha basado en pares de valores clave. Las llaves se hashan y se almacenan en un tipo de estructura de datos de tabla hash. El cache siempre fue una búsqueda basada en la clave exacta. Si su clave está presente, el sistema de cache devolverá los valores para su clave, y si la clave no lo es, eso significa que no se almacenó o se expulsó. Sin embargo, Qué es el cache semántico Vectores con múltiples dimensiones y encontrar vectores utilizando similitud cosina o mecanismos similares también existieron durante mucho tiempo. Sin embargo, con LLM y RAG, las incorporaciones de vectores y la búsqueda de similitud se han vuelto bastante populares. Vector RAG es una de las principales opciones de solución para sistemas basados en RAG. Esto ayuda a encontrar contenido similar. Esto no es una mirada clave exacta, sino que ayuda a encontrar los vectores de incorporación que son semánticamente similares. Esta capacidad se desarrolló inicialmente en bases de datos Vector, pero ahora esta capacidad también está disponible en sistemas de caché como redis y ahora los proveedores de servicios de nube también han introducido esta capacidad en sus ofertas de caché. Podemos definir la caché semántica como una caché que recoge entradas de caché basadas en el significado de un contenido o documento en lugar del hash de la clave. Podemos definir la caché semántica como una caché que recoge entradas de caché basadas en el significado de un contenido o documento en lugar del hash de la clave. Cómo es diferente la caché semántica Hacemos una rápida diferenciación entre Cache, Semantic Cache y RAG. Las siguientes tablas pueden ayudar a aclarar las diferencias entre la Cache tradicional y la Cache semántica. Factors Traditional Cache Semantic Cache Approach Key based Meaning based Key Search Exact match Similar match Best For APIs LLMs Example Key, Value (Student_Id, Student_Obj) 2025081520, StudentObject1 2025091640, StudentObject2 if key used while doing look up is different, then it wont's return any result Statements Where did Alex graduate from? Which university did Alex graduate from? both will fetch the same entry from cache. Aproximación Basado en clave Significado Basado Búsqueda clave Juego exacto Juegos similares Mejor para APIS LLMs Ejemplo Key, Valor (Student_Id y Student_Obj) 2025081520, Objeto estudiantil1 2025091640, Objeto estudiantil2 si la clave utilizada durante la búsqueda es diferente, Entonces se devuelve cualquier resultado Declaraciones ¿De dónde se graduó Alex? ¿De qué universidad se graduó Alex? Ambos obtendrán la misma entrada de la caché. La siguiente tabla puede ayudar a aclarar las diferencias entre RAG y Semantic Cache. Factors RAG Semantic Cache Use To generate new response To return previously generated and cached answer Data External data sources like Vector databases Previously generated Questions and Answer Cost Medium to High Low Best For Grounded response generation Repeated but similar question Uso Para generar una nueva respuesta Para devolver respuestas previamente generadas y caché Datos Fuentes de datos externas como bases de datos vectoriales Preguntas y respuestas generadas anteriormente costos Mediano a alto Bajo Mejor para Generación de respuestas fundamentadas Preguntas repetidas pero similares Podemos ver que la diferencia entre RAG y la caché semántica es simple, pero el impacto financiero es grande. RAG recupera información cruda y genera respuestas. Si sus preguntas son repetitivas, las respuestas en caché ganan porque elimina la búsqueda, la orquestación de herramientas y la generación. Arquitectura RAG basada en caché semántico He diseñado la siguiente arquitectura para la caché semántica sobre la arquitectura RAG estándar. Componentes de la arquitectura Usuario: Desde cualquier cliente como el navegador o la aplicación móvil, se invoca una API de Q&A una vez que un usuario introduzca cualquier pregunta en lenguaje natural. API Gateway: la solicitud de API está autenticada y autorizada en Gateway GraphRAG + VectorRAG Agent System(FastAPI) A LangGraph ReAct agent, this orchestrates the workflow. It decides whether to check the cache, query the graph store or vector store, or respond to the user. Guardrails: Implemented via system prompts and specific instruction sets to ensure safe and accurate responses. MCP (Model Context Protocol): Semantic Cache MCP Client: Connects to the cache server using Server-Sent Events (SSE). Semantic Cache MCP Server: A FastMCP server that exposes tools (cache_lookup, cache_store) and manages cache server(Redis) interactions. Semantic Cache Server(Redis): Acts as a Semantic Cache. It stores vector embeddings of questions and corresponding answers to provide fast retrieval for similar queries. LLM: el motor de razonamiento para el agente y el generador para las consultas de Cypher para las respuestas de GraphRAG y el lenguaje natural. Observabilidad (LangSmith): Proporciona seguimiento, seguimiento y depuración para los pasos de ejecución del agente. El Gráfico del Conocimiento (Neo4j): Almacena relaciones estructuradas (por ejemplo, (Persona)-[:WORKS_AT]->(Organización)) y se consulta a través de Cypher generado por el LLM. Vector Store (ChromaDB): Almacena las incorporaciones vectoriales generadas a partir del documento de conocimiento. Con el fin de implementar el caché semántico, se ha añadido principalmente el nuevo componente MCP de caché semántico en el sistema de agentes estándar basado en RAG. The agent first does a cache look up. Semantic Cache MCP client uses cache_lookup tool to check if the question is already answered and cached Semantic Cache MCP Server uses CACHE_SIMILARITY_THRESHOLD of >95% to decide whether a similar question is cached in the server. I tested similarity thresholds ranging from 80% to 99%. Below 90%, false positives increased and I started getting incorrect cached answers for loosely similar phrases. Above 97%, cache hit rates were significantly bad. In my use case, finally 95% provided the best trade off between precision and reuse. The right balance, however, depends on your specific use case and data distribution. Si el golpe de caché ocurre, entonces devuelve la respuesta sin hacer ninguna llamada RAG, lo que significa que ni Vector db ni la llamada del gráfico del conocimiento ni la llamada LLM. Si ocurre la falta de caché, entonces ejecuta el RAG estándar y genera la respuesta. Se asegura de almacenar la pregunta con la respuesta en el servidor de caché, que se utiliza para llamadas posteriores. El siguiente fragmento de código muestra el código del servidor MCP para la búsqueda de caché. He utilizado la búsqueda de similitud basada en KNN y he devuelto solo 1 coincidencia más cercana. Yo uso la distancia como puntuación y (1-punto) como similitud. Un punto más importante es el uso de dialecto 2, que es una necesidad para las consultas vectoriales en Redis, de lo contrario la consulta fracasará. @mcp.tool() def cache_lookup(question: str) -> str: """ Look up a semantically similar question in the cache. Args: question: The question to look up Returns: JSON with cached answer if found (similarity >= 95%), or cache miss indication """ global _hits, _misses client = get_redis_client() ensure_index_exists(client) # Compute embedding for the query query_embedding = compute_embedding(question) query_vector = np.array(query_embedding, dtype=np.float32).tobytes() # Vector similarity search try: q = ( Query(f"*=>[KNN 1 @embedding $vec AS score]") .return_fields("question", "answer", "expires_at", "score") .sort_by("score") .dialect(2) ) results = client.ft(INDEX_NAME).search( q, query_params={"vec": query_vector} ) if results.total > 0: doc = results.docs[0] score = float(doc.score) similarity = 1 - score # Convert distance to similarity expires_at = float(doc.expires_at) # Check expiration if time.time() > expires_at: logger.info(f"Cache entry expired for: '{question[:50]}...'") # Delete expired entry client.delete(doc.id) _misses += 1 return json.dumps({ "found": False, "reason": "expired" }) # Check similarity threshold if similarity >= CACHE_SIMILARITY_THRESHOLD: _hits += 1 logger.info(f"Cache HIT: similarity={similarity:.4f} for '{question[:50]}...'") return json.dumps({ "found": True, "answer": doc.answer.decode() if isinstance(doc.answer, bytes) else doc.answer, "similarity": round(similarity, 4), "original_question": doc.question.decode() if isinstance(doc.question, bytes) else doc.question }) _misses += 1 logger.info(f"Cache MISS for: '{question[:50]}...'") return json.dumps({ "found": False, "reason": "no_similar_question" }) except Exception as e: logger.error(f"Cache lookup error: {e}") _misses += 1 return json.dumps({ "found": False, "reason": f"error: {str(e)}" }) Primero he calculado las incorporaciones de la pregunta, que se almacena junto con la pregunta cruda y la respuesta como valor para la clave que es el hash estándar md5 de la pregunta. @mcp.tool() def cache_store(question: str, answer: str) -> str: """ Store a question-answer pair in the semantic cache. Args: question: The original question answer: The answer to cache Returns: JSON confirmation of storage """ client = get_redis_client() ensure_index_exists(client) try: # Compute embedding embedding = compute_embedding(question) embedding_bytes = np.array(embedding, dtype=np.float32).tobytes() # Generate unique key key_hash = hashlib.md5(question.encode()).hexdigest()[:12] cache_key = f"cache:{key_hash}" current_time = time.time() # Store in Redis hash client.hset(cache_key, mapping={ "question": question, "answer": answer, "embedding": embedding_bytes, "created_at": current_time, "expires_at": current_time + CACHE_TTL_SECONDS }) # Set TTL on the key client.expire(cache_key, CACHE_TTL_SECONDS) logger.info(f"Cached answer for: '{question[:50]}...' (TTL: {CACHE_TTL_SECONDS}s)") return json.dumps({ "stored": True, "key": cache_key, "ttl_seconds": CACHE_TTL_SECONDS }) except Exception as e: logger.error(f"Cache store error: {e}") return json.dumps({ "stored": False, "error": str(e) }) La siguiente imagen muestra el almacenamiento en caché de preguntas y respuestas en Redis con incorporaciones. El siguiente fragmento muestra el código del cliente MCP para invocar cache_lookup def cache_lookup(self, question: str) -> dict: return _run_async(self._req_with_connection("cache_lookup", question)) El siguiente fragmento muestra el código del cliente MCP para invocar el cache_store def cache_store(self, question: str, answer: str) -> dict: return _run_async(self._req_with_connection("cache_store", question, answer)) El siguiente rastro nos muestra el flujo de ejecución. Trace se destaca en la llamada cache_lookup, y puede ver la salida como cache_hit como falso con razón no_similar_question. Así, en este flujo, se ejecuta el RAG estándar. Puede ver el nodo graph_rag_query en la pista seguida de una llamada LLM. Ahora, es el momento de la verdad, cuando se hace otra vez una pregunta similar. Podemos ver en el siguiente instantáneo, cache_hit es cierto. Hay un pequeño cambio en la formulación de la pregunta, pero es similar a la anterior, por lo tanto la puntuación de similitud es 0.9866 como se muestra a continuación. Por lo tanto, la respuesta se recupera directamente de la caché y no verá la ejecución del flujo RAG. La respuesta se devuelve directamente de la caché semántica. Resultado La adición de caché semántico a un sistema GraphRAG o VectorRAG proporcionó un rendimiento y beneficios de costo mensurables. Anteriormente, el sistema tomó de 5 a 6 segundos por solicitud, que incluye la búsqueda de vectores, la generación y ejecución de consultas de cifrado de gráficos de conocimiento, y la generación de respuestas finales por el LLM. Cuando ocurrió el golpe de caché, las respuestas estaban en la pantalla del usuario en 900 ms a 1,2 segundos. En promedio, esto proporcionó una reducción del 24% en las llamadas diarias LLM, lo que redujo las facturas de la API de LLM. Estrategia de cache semántico Dónde gana el cache semántico Cuando un sistema maneja un alto volumen de tráfico previsible, una capa de caché agrega un beneficio de rendimiento. Gana cuando se solicita el mismo conocimiento por muchos usuarios, como en el caso de uso de "Suporte al Cliente y Helpdesks", donde las preguntas son como "¿Cómo reseto mi contraseña?", "¿Cuál es tu política de reembolso?". En los casos de uso de Documentación de Producto, donde los usuarios están consultando los mismos manuales de producto. Esto incluso ocurre cuando los desarrolladores consultan la misma documentación técnica y documentos de API. En los casos de uso de HR y Onboarding internos, donde preguntas como "¿Cómo me inscribo en el seguro de salud?" y "¿Cuál es el horario de vacaciones?" aparecen por cada empleado. En Compliance & Policy Q&A, donde tu sistema Cuándo evitar el caching semántico Fracasa específicamente en aquellos sistemas que proporcionan hiper personalización. Si dos usuarios hacen la misma pregunta pero requieren respuestas diferentes basadas en su historial médico o perfil o saldo de cuenta, un caché semántico puede proporcionar respuestas incorrectas. Incluso falla cuando sus documentos, base de conocimientos y datos son volátiles o es en tiempo real, como cuando necesita respuestas sobre precios de acciones o inventario en vivo, un caché es su enemigo. Estrategia de Invalidación Semántica Una caché necesita ser refrescada y la caché semántica necesita una estrategia de invalidación adicional. Cada entrada de caché debe ser etiquetada con un timestamp creado para gestionar sus valores de tiempo de vida (TTL). En la caché semántica también debe etiquetarse el document_version y el embedding_model utilizados durante la generación. Esto es crucial porque si actualiza el modelo de incorporación, su espacio vectorial cambia. Esto hace que las entradas de caché antiguas sean obsoletas. Necesitamos rastrear estas variables, para que podamos desencadenar la invalidación de la caché cada vez que se actualiza una fuente de documento o el modelo de incorporación se cambia o actualiza. Esto asegura que nuestro sistema no responda con respuestas inexactas. Autorización y consideraciones de seguridad En cualquier sistema de caché, debe asegurarse de que autoriza antes de proporcionar los datos al usuario.También debe asegurarse de que los datos cachetados están protegidos en reposo también.La implementación de la caché semántica debe adherirse a estos principios, no debe considerarse simplemente como la adición de una capa para el rendimiento o los beneficios de costo. En un sistema multi-teniente, las claves de aislamiento del inquilino deben implementarse en la caché. De manera similar en el sistema de usuario hiper personalizado, la partición del espacio de nombres a nivel de usuario debe realizarse en la caché. Esto garantiza que la búsqueda de similitud vectorial se limite al bucket específico perteneciente a ese usuario específico de la organización correspondiente. El punto más importante sobre la autorización es la creación de claves de caché conscientes de permisos, donde el hash de la clave incluye los roles específicos del usuario o los niveles de acceso. Esto garantiza que un usuario con menos privilegios no reciba una respuesta en caché de un usuario más privilegiado. Un hit de caché no debe ser un mecanismo de recuperación de datos no autorizado. Si un usuario no tiene permiso para recuperar un documento o línea de base específica a través de una tubería RAG, entonces no debe ser capaz de sacar la respuesta generada de la caché. Por último, para cumplir con varios requisitos de conformidad como HIPPA o SOC2, sus respuestas deben ser cifradas antes de ser almacenadas en caché. No es negociable en absoluto. Conclusión El plan arquitectónico, los fragmentos de código y los diferentes instantáneos demuestran que es posible almacenar semánticamente las preguntas y realizar una búsqueda de similitud basada en las incorporaciones vectoriales para devolver las respuestas generadas previamente para evitar las llamadas de LLM basadas en RAG para preguntas similares. El ejemplo mostrado anteriormente es bastante simple, sin embargo, podemos extender esta elección de arquitectura para múltiples puntos de contacto de LLM que suceden en el sistema Agentic AI para tomar decisiones no solo para las preguntas y respuestas del usuario final. El caché semántico es una forma sencilla de reducir los costos de token mientras se mantiene la calidad de la respuesta.Si su sistema recibe consultas similares para responder, agregar una capa de caché antes de los pasos de recuperación y generación es una ventaja.La parte más fácil es que no tiene que revisar su arquitectura RAG, simplemente optimiza el flujo al manejar la intención repetitiva más temprano en la cadena.