Una semantic cache risponde a "come resetto la password" con la risposta già generata per "ho dimenticato il login", perché le due domande significano la stessa cosa. Invece di confrontare la stringa esatta di una richiesta, la trasforma in embedding e cerca una richiesta salvata il cui embedding è abbastanza vicino, poi restituisce quella risposta in cache senza chiamare il modello. Quando funziona, salti del tutto una chiamata al modello: niente token, niente latenza, niente costo. Quando sbaglia a giudicare cosa vuol dire "abbastanza vicino", serve una risposta sicura a una domanda che l'utente non ha fatto.

Il modo utile di vederla: una cache normale usa l'identità come chiave, una semantic cache usa la similarità come chiave, e la similarità è una soglia che imposti tu, non un fatto oggettivo. Quella soglia è l'intera superficie di rischio. Impostala larga e servi risposte sbagliate, impostala stretta e non salvi quasi nulla in cache. Tutto ciò che riguarda far girare bene una semantic cache è gestire quella manopola.

Come funziona, tolta la magia

Il meccanismo è di tre passi. Trasforma la richiesta in arrivo in un vettore usando un modello di embedding come Amazon Titan Text Embeddings o Cohere su Bedrock. Cerca in un vector store la richiesta precedente più vicina. Se la similarità del coseno del vicino più vicino supera la tua soglia, restituisci la sua risposta in cache, altrimenti chiama il modello, poi salva il nuovo embedding della richiesta e la risposta per la prossima volta.

vec = embed(request)
hit = vector_store.nearest(vec)
if hit and hit.similarity >= THRESHOLD:
    return hit.cached_response      # no model call
answer = model.invoke(request)
vector_store.put(vec, answer)
return answer

Il vector store può essere qualsiasi cosa tu già gestisca: OpenSearch, Aurora con pgvector, o un indice in memoria per un piccolo insieme caldo. La parte difficile non è mai l'archiviazione. È il valore di THRESHOLD e cosa lasci entrare in cache in primo luogo.

Il rischio di falso hit è tutta la partita

Un falso hit è quando due richieste sono vicine nello spazio degli embedding ma dovrebbero avere risposte diverse. "Qual è la nostra politica di rimborso per i clienti UE" e "qual è la nostra politica di rimborso per i clienti USA" possono trovarsi pericolosamente vicine nello spazio vettoriale pur richiedendo risposte diverse. Una soglia larga restituisce la risposta UE a un utente USA e lo fa con totale sicurezza, perché il modello non è mai stato consultato.

Questo è peggio di un normale cache miss, che ti costa solo una chiamata al modello. Un falso hit ti costa una risposta sbagliata che sembra giusta. Quindi la soglia va tarata su traffico reale, non indovinata, e dovrebbe essere sbilanciata verso la strettezza: un miss è economico, un falso hit può diventare un ticket di supporto o un problema di compliance. Misura il tasso di falsi hit su un campione etichettato prima di fidarti della cache per qualsiasi cosa che conti davvero.

Cosa non mettere in cache

Il semantic caching si adatta a conoscenza stabile, generale e condivisa, e non si adatta a nient'altro. Metti in cache la risposta a "come esporto i miei dati", che è uguale per tutti. Non mettere in cache nulla che dipenda da chi sta chiedendo o da quando. Regole pratiche da far rispettare nel codice:

  • Non mettere mai in cache attraverso confini di identità. Fai la chiave della cache per tenant, o escludi tutto ciò che è personalizzato. Una cache condivisa che ignora il chiamante finirà per servire la risposta di un cliente a un altro.
  • Non mettere mai in cache risposte sensibili al tempo. Saldi, stato degli ordini e inventario cambiano sotto i tuoi piedi. Un hit obsoleto qui è un bug fresco.
  • Metti in cache ciò che è senza retrieval, non ciò che è ricco di retrieval. Se la risposta dipende da documenti che cambiano, metti in cache la ricerca di embedding, non la risposta finale.

L'invalidazione è la parte che tutti saltano

La battuta più vecchia dell'informatica è che l'invalidazione della cache è uno dei due problemi difficili, e una semantic cache non ha nessuna esenzione. Quando la verità sottostante cambia, quando una policy viene aggiornata, un prezzo si muove, un documento viene rivisto, ogni risposta in cache che si appoggiava sulla vecchia verità è ora sbagliata e continuerà a essere servita finché non la elimini.

Dai alle voci un time-to-live abbastanza corto da far scadere da sole le risposte obsolete, e aggiungi un percorso di purge esplicito legato agli eventi che cambiano la ground truth: pubblicare una nuova versione della policy dovrebbe invalidare la fetta di cache costruita su quella vecchia. Senza una strategia di invalidazione, una semantic cache non si limita a risparmiare chiamate, blocca silenziosamente il tuo prodotto ai fatti di ieri.

Il punto chiave

Il semantic caching è un vero guadagno su costo e latenza per domande che sono la stessa domanda con parole diverse, ed è una trappola per tutto ciò che è personalizzato, sensibile al tempo, o soggetto a cambiare. Il meccanismo è banale: embed, cerca, soglia. L'ingegneria sta interamente nella soglia, nelle regole di ambito, e nel percorso di invalidazione. Taratura della soglia su traffico etichettato, metti in cache solo conoscenza stabile e condivisa, e invalida sugli eventi che spostano la verità. Fai queste tre cose e la cache si ripaga da sola. Saltale e servirà risposte sbagliate più in fretta di quanto il modello avrebbe servito quelle giuste.

Leggi questo dopo

Per il lato platform di gestire un vector store e la sua evizione sotto carico, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.