Ottimizzare i costi di utilizzo del LLM con Semantic Cache

Ho costruito un sistema di reporting bot di chat di lingua naturale, alimentato da Retrieval Augmented Generation (RAG). Ha fornito un'esperienza ottima per l'utente, sono stati in grado di interrogare i dati e ottenere i rapporti tagliati e tagliati dalle dimensioni che volevano. Era intuitivo e forniva efficienza. Ha trasformato tonnellate di dati in oro liquido. Poi è arrivato il LLM API Bill. Fu allora che mi resi conto che nella mia ricerca per costruire questa intelligenza avevo creato un buco nero finanziario. Poi è arrivato il LLM API Bill. Fu allora che mi resi conto che nella mia ricerca per costruire questa intelligenza avevo creato un buco nero finanziario. Nel mondo IT di oggi, ogni team sta cercando di costruire un sistema Agentic AI. In ogni ambiente, questi sistemi Agentic AI fanno centinaia e migliaia di chiamate LLM, a partire da sviluppo, eval, test di accettazione utente e poi nell'ambiente di produzione. Per generare risposte fondate, implementamo Retrieval Augmented Generation (RAG). Ciò significa che interroghiamo i negozi vettoriali per contenuti simili e trasmettiamo i dati recuperati con le domande degli utenti, i prompt, gli esempi, le istruzioni dei guardrails, lo schema di risposta strutturata ecc. a LLM. Ciò significa per una domanda semplice, aggiungiamo centinaia di token aggiuntivi nel nome del contesto, guardrails e poche prompting ecc. I grandi modelli linguistici (LLM) analizzano questi come token e fanno il loro lavoro per generare la risposta e poi otteniamo la risposta alla nostra domanda. Questa risposta può essere una risposta alla nostra domanda o può essere una risposta strutturata a uno dei passaggi in un flusso di lavoro multi-agente. Questo significa Nel mio sistema, il sistema estrae i dati da Vector DB e Knowledge Graph per fondare la risposta. Ho osservato circa ~2000 token di input nella finestra di contesto. Il LLM quindi genera una risposta ponderata, 500 token. A prima vista, questo è solo un paio di centesimi. Ma con 200.000 richieste al giorno, quei "centesimi" si trasformano in un mostro. Aggiungi solo che l'uso con più utenti durante le fasi di sviluppo e valutazione anche. Attualmente il costo per un milione di token di utilizzo come l'ingresso e l'uscita sembra più economico come siamo nelle fasi iniziali dell'adozione di LLM api e i fornitori di servizi hanno deliberatamente dato un sacco di sconti. In futuro questi prezzi andranno più alti, e poi il costo complessivo Puoi anche fare riferimento a alcuni articoli che citano le sfide intorno al costo del LLM. The LLM Pricing War Is Hurting Education—and Startups Come scalare l'IA aziendale con il LLM sbagliato potrebbe costarti Ho costruito sistemi basati su RAG utilizzando LangGraph, Neo4j, ChromaDB e Redis. Ho portato questo modello di architettura chiamato Semantic Cache e dettagli di implementazione per ridurre la combustione di token nella produzione. Questo modello può ridurre il costo di utilizzo del tuo LLM memorizzando e rispondendo a domande simili invece di invocare LLM ogni volta. Cosa è Cache Cache è stato lì per secoli nella nostra architettura IT System. È iniziato con In-Memory, poi è diventato distribuito. Inizialmente c'erano poche offerte limitate per la distribuzione on-prem o VM-based. Con l'avvento del cloud, molte offerte cloud si sono evolute. Al giorno d'oggi, abbiamo sistemi di caching abbastanza maturi. Tuttavia, l'uso del sistema di caching è stato basato su coppie di valori chiave. Le chiavi sono hashate e memorizzate in una struttura di tipo tabella hash. La caching è sempre stata una ricerca esatta basata sulla chiave. Se la tua chiave è presente, il sistema di cache restituirà i valori per la tua chiave, e se la chiave non lo fa, significa che non è stata memorizzata o è stata espulsa. Che cos'è la cache semantica Anche i vettori con più dimensioni e la ricerca di vettori utilizzando la somiglianza cosina o meccanismi simili esistevano da molto tempo. Tuttavia, con LLM e RAG, le incorporazioni vettoriali e la ricerca di somiglianza sono diventate piuttosto popolari. Vector RAG è una delle principali scelte di soluzione per i sistemi basati su RAG. Questo aiuta a trovare contenuti simili. Questo non è un'esatta chiave, ma aiuta a trovare i vettori incorporati che sono semanticamente simili. Questa capacità è stata inizialmente sviluppata nei database Vector, ma ora questa capacità è disponibile anche nei sistemi di cache come Redis e ora i fornitori di servizi cloud hanno anche introdotto questa capacità nelle loro offerte di cache. Possiamo definire Semantic Cache come una cache che raccoglie le voci di cache in base al significato di un contenuto o di un documento invece del hash della chiave. Possiamo definire Semantic Cache come una cache che raccoglie le voci di cache in base al significato di un contenuto o di un documento invece del hash della chiave. Come la cache semantica è diversa Facciamo una rapida differenziazione tra Cache, Semantic Cache e RAG. Le tabelle seguenti possono aiutare a chiarire le differenze tra Cache tradizionale e Cache semantico. 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. Approccio chiave basata Significato basato Ricerca chiave La partita esatta Match simili Il meglio per Appia LLMs Esempio Key, Value (Student_Id e Student_Obj) 2025081520, StudentObject1 2025091640, StudentObject2 se la chiave utilizzata durante la ricerca è diversa, In ogni caso, non è possibile restituire il risultato Dichiarazioni Dove si è laureato Alex? Da quale università si è laureato Alex? Entrambi riceveranno lo stesso ingresso dalla cache. La tabella seguente può aiutare a chiarire le differenze tra 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 usare Per generare una nuova risposta Per restituire risposte precedentemente generate e cacheate Dati Fonti di dati esterne come database vettoriali Domande e risposte precedentemente generate Costo Media fino ad alta basso Il meglio per Generazione di risposte fondate Domande simili ma ripetute Possiamo vedere che la differenza tra RAG e la cache semantica è semplice, ma l'impatto finanziario è grande. RAG recupera le informazioni crude e genera risposte. Se le tue domande sono ripetitive, la cache vince perché elimina il recupero, l'orchestrazione degli strumenti e la generazione. Architettura RAG basata sulla cache semantica Ho progettato la seguente architettura per la cache semantica sopra l'architettura standard RAG. Componenti dell’architettura Utente: Da qualsiasi client come browser o applicazione mobile, un Q&A api viene richiamato una volta che un utente inserisce qualsiasi domanda in lingua naturale. API Gateway: la richiesta API è autenticata e autorizzata in 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: il motore di ragionamento per l'agente e il generatore per le query Cypher per GraphRAG e risposte di linguaggio naturale. Observability (LangSmith): fornisce tracciamento, monitoraggio e debug per i passaggi di esecuzione dell'agente. Il Knowledge Graph (Neo4j): memorizza relazioni strutturate (ad esempio, (Persona)-[:WORKS_AT]->(Organizzazione)) e viene interrogato tramite Cypher generato dal LLM. Vector Store (ChromaDB): memorizza le incorporazioni vettoriali generate dal documento della conoscenza. Al fine di implementare la cache semantica, è stato aggiunto principalmente il nuovo componente MCP della cache semantica nel standard RAG-based Agent System. 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 il cache hit si verifica, quindi restituisce la risposta senza fare alcuna chiamata RAG, il che significa che né Vector db né la chiamata al grafico della conoscenza né la chiamata LLM. Se la cache manca, esegue la RAG standard e genera la risposta.Si assicura di memorizzare la domanda con la risposta nel server cache, che viene utilizzato per le chiamate successive. Il codice seguente mostra il codice del server MCP per la ricerca della cache. Ho usato la ricerca di somiglianza basata su KNN e ho restituito solo la corrispondenza più vicina 1. uso la distanza come punteggio e (1-punteggio) come somiglianza. Un punto più importante è l'uso del dialetto 2, che è un must per le query vettoriali in Redis, altrimenti la query fallirà. @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)}" }) Il codice seguente mostra il codice del server MCP per il cache store. ho prima calcolato gli embeddings della domanda, che viene memorizzato insieme alla domanda cruda e risposta come valore per la chiave che è lo hash standard md5 della domanda. @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) }) L'immagine seguente mostra la cache di domande e risposte in Redis con incorporazioni. Il seguente snippet mostra il codice client MCP per richiamare il cache_lookup def cache_lookup(self, question: str) -> dict: return _run_async(self._req_with_connection("cache_lookup", question)) Il seguente snippet mostra il codice client MCP per richiamare il cache_store def cache_store(self, question: str, answer: str) -> dict: return _run_async(self._req_with_connection("cache_store", question, answer)) La seguente traccia ci mostra il flusso di esecuzione. Trace è evidenziato alla chiamata cache_lookup, e puoi vedere l'uscita come cache_hit come falso con la ragione no_similar_question. Così in questo flusso, viene eseguita la RAG standard. Puoi vedere il nodo graph_rag_query nella traccia seguita da una chiamata LLM. Ora, è il momento della verità, quando una domanda simile viene chiesta di nuovo. Possiamo vedere nel seguente snapshot, cache_hit è vero. C'è un leggero cambiamento nella formulazione della domanda, ma è simile a quella precedente, quindi il punteggio di similitudine è 0.9866 come mostrato di seguito. Pertanto, la risposta viene recuperata direttamente dalla cache e non vedrete l'esecuzione del flusso RAG. La risposta viene restituita direttamente dalla cache semantica. Risultato Aggiungere la cache semantica a un sistema GraphRAG o VectorRAG ha fornito prestazioni e vantaggi di costo misurabili. In precedenza, il sistema ha richiesto da 5 a 6 secondi per richiesta, che include la ricerca di vettori, la generazione e l'esecuzione di query di cifratura del grafico della conoscenza e la generazione di risposte finali da parte del LLM. Quando il cache ha colpito, le risposte erano sullo schermo dell'utente in 900 ms a 1,2 secondi. Strategia di cache semantica Dove vince la cache semantica Quando un sistema gestisce un traffico di alto volume e prevedibile, un livello di cache aggiunge un vantaggio di prestazione. Guadagna quando la stessa conoscenza viene chiesta da molti utenti, come nel caso di utilizzo "Customer Support & Helpdesks", dove le domande sono come "Come riassetto la mia password?", "Cosa è la tua politica di rimborso?". Nei casi di utilizzo della documentazione del prodotto, dove gli utenti interrogano gli stessi manuali del prodotto. Questo accade anche quando gli sviluppatori interrogano la stessa documentazione tecnica e i documenti API. Nei casi di utilizzo interni HR & Onboarding, dove domande come "Come mi iscrivono all'assicurazione sanitaria?" e "Qual è il calendario delle vacanze?" appaiono da ogni dipendente. Quando evitare il caching semantico Se due utenti chiedono la stessa domanda ma richiedono risposte diverse in base alla loro storia medica o al profilo o al saldo del conto, una cache semantica può fornire risposte errate. Si fallisce anche quando i documenti, la base di conoscenze e i dati sono volatili o è in tempo reale, come quando hai bisogno di risposte sui prezzi delle azioni o sull'inventario dal vivo, una cache è il tuo nemico. Strategia di Invalidazione Semantica Una cache deve essere aggiornata e la cache semantica ha bisogno di ulteriori strategie di invalidazione. Ogni ingresso della cache deve essere etichettato con un timestamp creato per gestire i valori del suo tempo per vivere (TTL). Nella cache semantica dovrebbero anche essere etichettati document_version e embedding_model utilizzati durante la generazione. Questo è fondamentale perché se si aggiorna il modello di incorporazione, il tuo spazio vettoriale cambia. Questo rende le vecchie voci della cache obsolete. Abbiamo bisogno di tracciare queste variabili, in modo da poter attivare l'invalidazione della cache ogni volta che una fonte di documento viene aggiornata o il modello di incorporazione viene modificato o aggiornato. Questo assicura che il nostro sistema non risponda con risposte inesatte. Autorizzazione e considerazioni di sicurezza In qualsiasi sistema di cache, è necessario assicurarsi che autorizza prima di fornire i dati all'utente. Deve anche garantire che i dati in cache siano protetti anche a riposo.L'implementazione della cache semantica deve aderire a questi principi, non dovrebbe essere vista solo come l'aggiunta di uno strato per prestazioni o vantaggi di costo. In un sistema multi-tenant, le chiavi di isolamento del locatario devono essere implementate nella cache. Similmente nel sistema dell'utente iperpersonalizzato, la partizione dello spazio dei nomi a livello utente deve essere effettuata nella cache. Questo garantisce che la ricerca di somiglianza vettoriale sia limitata al bucket specifico appartenente a quell'utente specifico dell'organizzazione corrispondente. Il punto più importante sull'autorizzazione è la creazione di chiavi di cache consapevoli del permesso, dove l'hash della chiave include i ruoli specifici dell'utente o i livelli di accesso. Questo assicura che un utente con meno privilegi non riceva una risposta in cache da un utente più privilegiato. Un cache hit non deve essere un meccanismo di recupero dati non autorizzato. Se un utente non ha il permesso di recuperare un determinato documento o una riga di database tramite un pipeline RAG, allora non deve essere in grado di estrarre la risposta generata dalla cache. Infine, per soddisfare vari requisiti di conformità come HIPPA o SOC2, le risposte devono essere crittografate prima di essere cache. Non è negoziabile affatto. Conclusione Il blueprint architettonico, i snippets di codice e i vari snapshots dimostrano che è possibile cache semanticamente le domande e fare una ricerca di somiglianza basata su embeddings vettoriali per restituire le risposte generate in precedenza per evitare richieste LLM basate su RAG per domande simili. L'esempio mostrato sopra è abbastanza semplice, tuttavia, possiamo estendere questa scelta di architettura a più punti di contatto LLM che accade nel sistema Agentic AI per prendere decisioni non solo per le domande e le risposte degli utenti finali. La cache semantica è un modo semplice per ridurre i costi dei token mantenendo la qualità della risposta. Se il tuo sistema riceve domande simili da rispondere, l'aggiunta di un livello di cache prima dei passaggi di recupero e generazione è un vantaggio.La parte più semplice è che non devi rivedere la tua architettura RAG, ottimizzi semplicemente il flusso gestendo l'intenzione ripetitiva in precedenza nella catena.