Optimiza os custos de uso do LLM con Semantic Cache

Construín un sistema de informes de bot de chat de lingua natural, alimentado por Retrieval Augmented Generation (RAG). Proporcionou unha gran experiencia ao usuario, puideron consultar os datos e obter informes cortados e cortados polas dimensións que querían. Foi intuitivo e proporcionou eficiencia. Entón, a lei de API LLM chegou. Foi entón cando me dei conta de que na miña procura de construír esta intelixencia, eu creara un buraco negro financeiro. Entón, a lei de API LLM chegou. Foi entón cando me dei conta de que na miña procura de construír esta intelixencia, eu creara un buraco negro financeiro. En cada ambiente, estes sistemas de IA de Axencia realizan centos e miles de chamadas LLM, comezando co desenvolvemento, eval, probas de aceptación do usuario e despois no ambiente de produción. Para xerar respostas baseadas, implementamos Retrieval Augmented Generation (RAG). Isto significa que consultamos tendas vector para contido similar e pasamos os datos recuperados coas preguntas do usuario, prompts, exemplos, instrucións de gardrails, esquema de resposta estruturada, etc. a LLM. Isto significa para unha pregunta simple, engadimos centos de tokens adicionais no nome do contexto, gardrails e algúns prompts de disparo, etc. Grandes modelos de linguaxe (LLM) analizan estes como tokens e fan o seu traballo para xerar a resposta e entón obtemos a resposta á nosa pregunta. Esta resposta pode ser unha resposta á nosa pregunta ou pode ser unha resposta estruturada a un dos pasos nun fluxo de traballo multi-axente. Isto significa que para executar un fluxo de traballo con varios axentes que invocan No meu sistema, o sistema extrae datos de Vector DB e Knowledge Graph para fundamentar a resposta. Observei arredor de ~2000 tokens de entrada na xanela de contexto. O LLM xera entón unha reflexiva resposta de 500 tokens. A primeira vista, iso é só uns poucos céntimos. Pero con 200.000 consultas ao día, eses "céntimos" transfórmanse nun monstro. Basta engadir que uso con varios usuarios durante as fases de desenvolvemento e avaliación tamén. Actualmente, o custo por millón de tokens de uso como a entrada e saída parece máis barato como estamos nas etapas iniciais da adopción de LLM api e os provedores de servizos deliberadamente deron moitos descontos. No futuro estes prezos irán máis altos, e entón o custo global desde o desenvolvemento ata a produción ata o soporte e mantemento destes sistemas aumentará dr Tamén pode referirse a algúns artigos citando os retos en torno ao custo do LLM. A guerra de prezos de LLM está a prexudicar a educación - e as startups Como a escalación da IA empresarial co LLM incorrecto podería custarte Construín sistemas baseados en RAG usando LangGraph, Neo4j, ChromaDB e Redis. Traio este patrón de arquitectura chamado Semantic Cache e detalles de implementación para reducir a queima de tokens na produción. Este patrón pode reducir o custo de uso do seu LLM mediante a caché e a resposta a preguntas similares en lugar de invocar o LLM cada vez. Déixeme presentar este patrón que pode aplicar en múltiples casos de uso e en múltiples puntos de contacto no seu fluxo de traballo de AI axente. O que é caché O cache estivo alí durante séculos na nosa arquitectura de sistemas de TI. Comezou con In-Memory, entón fíxose distribuído. Inicialmente houbo poucas ofertas limitadas para a implantación on-prem ou baseada en VM. Coa chegada da nube, moitas ofertas de nube evolucionaron. Na actualidade, temos sistemas de cache bastante maduros. Con todo, o uso do sistema de cache foi baseado en pares de valores clave. As chaves son hashadas e almacenadas nunha estrutura de datos tipo táboa hash. O cache sempre foi unha busca baseada en chaves exacta. Se a túa chave está presente, o sistema de cache devolverá os valores para a túa clave, e se a clave non, iso significa que non foi almacenada ou que foi expulsada. Con todo, nunca O que é o caché semántico Os vectores con múltiples dimensións e a busca de vectores usando semellanza cosina ou mecanismos similares tamén existiron durante moito tempo. Con todo, con LLM e RAG, as incorporacións de vectores e a busca de semellanza fixéronse bastante populares. O Vector RAG é unha das principais opcións de solución para sistemas baseados en RAG. Isto axuda a atopar contido similar. Isto non é unha ollada clave exacta, senón que axuda a atopar os vectores de incorporación que son semánticamente similares. Esta capacidade foi desenvolvida inicialmente en bases de datos Vector, pero agora esta capacidade tamén está dispoñible en sistemas de caché como redis e agora os provedores de servizos de nube tamén introduciron esta capacidade nas súas ofertas de caché. Podemos definir a caché semántica como unha caché que obtén entradas de caché baseadas no significado dun contido ou documento en vez do hash da clave. Podemos definir a caché semántica como unha caché que obtén entradas de caché baseadas no significado dun contido ou documento en vez do hash da clave. Como o caché semántico é diferente Facemos unha rápida diferenciación entre Cache, Semantic Cache e RAG. As seguintes táboas poden axudar a aclarar as diferenzas entre a caché tradicional e 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óns baseado na clave Significado baseado Busca clave Xogo exacto Xogos semellantes O mellor para APIs LLMs Exemplos Key, Valor (Estudante_Id, Estudante_Obj) 2025081520, StudentObject1 2025091640, StudentObject2 se a clave usada durante a busca é diferente, Entón Wend's devolve calquera resultado Declaracións ¿De onde saíu Alex? De que universidade se graduou Alex? Ambos obterán a mesma entrada da caché. A seguinte táboa pode axudar a aclarar as diferenzas entre RAG e 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 Utilización Para xerar unha nova resposta Para devolver unha resposta xerada anteriormente e cached datos Fontes de datos externas como bases de datos vector Preguntas e respostas xeradas anteriormente Custo Medio a alto Baixa O mellor para Xeración de resposta baseada Unha pregunta repetida pero semellante Podemos ver que a diferenza entre RAG e a caché semántica é simple, pero o impacto financeiro é grande. RAG recupera información crúa e xera respostas. Se as súas preguntas son repetitivas, a caché gaña as respostas porque elude a recuperación, a orquestración de ferramentas e a xeración. Arquitectura RAG baseada en caché semántico Deseñei a seguinte arquitectura para a caché semántica enriba da arquitectura RAG estándar. Compoñentes da arquitectura Usuario: Desde calquera cliente como navegador ou aplicación móbil, invócase unha API de Q&A unha vez que un usuario introduza calquera pregunta en linguaxe natural. API Gateway: A solicitude de API está autenticada e 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. O motor de razoamento para o axente e o xerador para as consultas de Cypher para as respostas de GraphRAG e linguaxe natural. Observabilidade (LangSmith): Proporciona seguimento, seguimento e depuración para as etapas de execución do axente. O Gráfico do Coñecemento (Neo4j): Almacena relacións estruturadas (por exemplo, (Persoa)-[:WORKS_AT]->(Organización)) e é consultado a través de Cypher xerado polo LLM. Vector Store (ChromaDB): almacena as incorporacións de vectores xeradas a partir do documento de coñecemento. Para implementar a caché semántica, principalmente o novo compoñente de caché semántico MCP foi engadido ao sistema de axentes baseado en RAG estándar. 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. Se ocorre o golpe de caché, entón devolve a resposta sen facer ningunha chamada RAG, o que significa que nin Vector db nin coñecemento gráfico chamada nin LLM chamada. Se ocorre a falta de caché, entón executa o RAG estándar e xera a resposta. O seguinte fragmento de código mostra o código do servidor MCP para a busca de caché. Utilicei a busca de semellanza baseada en KNN e devolvín só 1 correspondencia máis próxima. Utilice a distancia como puntuación e (1-puntuación) como semellanza. Un punto máis importante é o uso do dialecto 2, que é unha obriga para as consultas vectoriales en Redis, se non, a consulta fallará. @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)}" }) Primeiro calculei as incorporacións da pregunta, que se almacena xunto coa pregunta en bruto e responde como valor para a clave que é o hash estándar md5 da 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) }) A seguinte imaxe mostra a caché de preguntas e respostas en Redis con incorporacións. O seguinte fragmento mostra o código do cliente MCP para invocar o cache_lookup def cache_lookup(self, question: str) -> dict: return _run_async(self._req_with_connection("cache_lookup", question)) O seguinte fragmento mostra o código do cliente MCP para invocar o cache_store def cache_store(self, question: str, answer: str) -> dict: return _run_async(self._req_with_connection("cache_store", question, answer)) O seguinte rastro amósanos o fluxo de execución. Trace é destacado na chamada cache_lookup, e pode ver a saída como cache_hit como falso coa razón no_similar_question. Así, neste fluxo, execútase o RAG estándar. Pode ver o nodo graph_rag_query na pista seguida dunha chamada LLM. Agora, é o momento da verdade, cando unha pregunta similar é preguntada de novo. Podemos ver na seguinte imaxe instantánea, cache_hit é certo. Hai un pequeno cambio na formulación da pregunta, pero é similar á anterior, polo que a puntuación de semellanza é 0.9866 como se mostra a continuación. Polo tanto, a resposta é recuperada directamente da caché e non verás a execución do fluxo RAG. A resposta é devolta directamente da caché semántica. Resultado A adición de caché semántico a un sistema GraphRAG ou VectorRAG proporcionou un rendemento e beneficios de custo mensurables. Anteriormente, o sistema levou de 5 a 6 segundos por solicitude, que inclúe a busca de vectores, a xeración e execución de consultas de cifrado de gráficos de coñecemento e a xeración de respostas finais polo LLM. Cando ocorreu o golpe de caché, as respostas estaban na pantalla do usuario en 900 ms a 1,2 segundos. En media, isto proporcionou unha redución do 24% nas chamadas diarias LLM, o que reduciu as facturas da API do LLM. Estratexia de caché semántico Onde gaña o caché semántico Cando un sistema xestiona un tráfico de alto volume, previsible, unha capa de caché engade un beneficio de rendemento. Gaña cando o mesmo coñecemento é solicitado por moitos usuarios, como no caso de uso de "Suporte ao Cliente e Helpdesks", onde as preguntas son como "Como reseto o meu contrasinal?", "Cal é a súa política de reembolso?". En casos de uso de Documentación de Produtos, onde os usuarios están consultando os mesmos manuais de produtos. Isto mesmo ocorre cando os desenvolvedores consultan a mesma documentación técnica e documentos de API. En casos de uso internos de HR e Onboarding, onde preguntas como "Como podo rexistrarme no seguro de saúde?" e "Cal é o horario de vacacións?" aparecen por cada empregado. En Compliance & Policy Q&A, onde o seu Cando evitar o caché semántico Se dous usuarios fan a mesma pregunta pero requiren respostas diferentes baseadas no seu historial médico ou perfil ou saldo de conta, un caché semántico pode proporcionar respostas incorrectas. Incluso falla cando os seus documentos, a base de coñecementos e os datos son volátiles ou é en tempo real, como cando precisa de respostas sobre prezos de accións ou inventario en directo, un caché é o seu inimigo. Estratexia de invalidación semántica Unha caché debe ser actualizada e a caché semántica necesita unha estratexia de invalidación adicional. Cada entrada de caché debe ser etiquetada cun timestamp creado para xestionar os seus valores de tempo de vida (TTL). Na caché semántica tamén debe etiquetarse o document_version e o embedding_model usado durante a xeración. Isto é crucial porque se actualiza o modelo de embedding, o seu espazo vector cambia. Isto fai que as entradas de caché antigas sexan obsoletas. Debemos rastrexar estas variables, para que poidamos desencadear a invalidación de caché cada vez que se actualiza unha fonte de documento ou o modelo de embedding se cambia ou actualiza. Isto asegura que o noso sistema non responda con respostas inexactas. Autorización e consideracións de seguridade En calquera sistema de caché, debes asegurarte de que autoriza antes de proporcionar os datos ao usuario.Tamén debe asegurarse de que os datos caché tamén están seguros en repouso.A implementación do caché semántico debe cumprir estes principios, non debe ser visto só como engadindo unha capa para beneficios de rendemento ou custo. Nun sistema multi-tenente, as claves de illamento do inquilino deben ser implementadas en caché. Do mesmo xeito no sistema do usuario hiper personalizado, a partición do espazo de nomes a nivel de usuario debe realizarse na caché. Isto garante que a busca de semellanza vector está limitada ao bucket específico pertencente a ese usuario específico da organización correspondente. O punto máis importante sobre a autorización é a creación de chaves de caché conscientes de permisos, onde o hash da clave inclúe os roles específicos do usuario ou niveis de acceso. Isto asegura que un usuario con menos privilexios non reciba unha resposta caché dun usuario máis privilexiado. Un hit de caché non debe ser un mecanismo de captura de datos non autorizado. Se un usuario non ten permiso para capturar un documento ou liña de base de datos particular a través dunha tubería RAG, entón non debe ser capaz de sacar a resposta xerada da caché. Finalmente, para cumprir varios requisitos de conformidade como HIPPA ou SOC2, as súas respostas deben ser cifradas antes de que se cache. Non é negociable en absoluto. Conclusión O plan arquitectónico, os fragmentos de código e os diversos instantáneos demostran que é posible caché semánticamente as preguntas e facer unha busca de semellanza baseada en incorporacións vectoriales para devolver as respostas xeradas anteriormente para evitar as chamadas de LLM baseadas en RAG para preguntas similares. O exemplo mostrado anteriormente é bastante sinxelo, pero podemos estender esta elección de arquitectura a varios puntos de contacto LLM que ocorren no sistema de AI de Agentic para tomar decisións non só para as preguntas e respostas do usuario final. O caché semántico é unha forma sinxela de reducir os custos de token mentres se mantén a calidade da resposta. Se o seu sistema recibe consultas similares para responder, engadir unha capa de caché antes dos pasos de recuperación e xeración é unha vantaxe. A parte máis sinxela é que non ten que revisar a súa arquitectura RAG, simplemente optimiza o fluxo ao manexar a intención repetitiva máis cedo na cadea.