Ένα semantic cache απαντά στο "πώς επαναφέρω τον κωδικό μου" με την απόκριση που έχει ήδη παράγει για το "ξέχασα τα στοιχεία σύνδεσής μου", επειδή τα δύο σημαίνουν το ίδιο πράγμα. Αντί να ταιριάζει το ακριβές string ενός αιτήματος, ενσωματώνει (embeds) το αίτημα και ψάχνει για ένα αποθηκευμένο αίτημα του οποίου το embedding είναι αρκετά κοντά, και μετά επιστρέφει αυτή την cached απάντηση χωρίς να καλέσει το μοντέλο. Όταν δουλεύει, παρακάμπτεις εντελώς μια κλήση μοντέλου: καθόλου tokens, καθόλου latency, καθόλου κόστος. Όταν κρίνει λάθος το "αρκετά κοντά", δίνει μια σίγουρη απάντηση σε μια ερώτηση που ο χρήστης δεν έκανε.

Το βασικό reframing: μια κανονική cache κλειδώνει στην ταυτότητα, μια semantic cache κλειδώνει στην ομοιότητα, και η ομοιότητα είναι ένα threshold που ορίζεις εσύ, όχι ένα γεγονός. Αυτό το threshold είναι ολόκληρη η επιφάνεια κινδύνου. Ρύθμισέ το χαλαρά και δίνεις λάθος απαντήσεις, ρύθμισέ το αυστηρά και δεν κάνεις σχεδόν καθόλου caching. Όλη η τέχνη του να τρέχεις καλά ένα semantic cache είναι η διαχείριση αυτού του καντράν.

Πώς δουλεύει, χωρίς τη μαγεία

Ο μηχανισμός είναι τρία βήματα. Ενσωμάτωσε το εισερχόμενο αίτημα σε ένα vector χρησιμοποιώντας ένα μοντέλο embeddings όπως το Amazon Titan Text Embeddings ή το Cohere στο Bedrock. Ψάξε σε ένα vector store για το πλησιέστερο προηγουμένως δει αίτημα. Αν η ομοιότητα συνημιτόνου (cosine similarity) του πλησιέστερου γείτονα είναι πάνω από το threshold σου, επίστρεψε την cached απόκρισή του, διαφορετικά κάλεσε το μοντέλο, μετά αποθήκευσε το νέο embedding αιτήματος και την απόκριση για την επόμενη φορά.

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

Το vector store μπορεί να είναι οτιδήποτε ήδη τρέχεις: OpenSearch, Aurora με pgvector, ή ένα in-memory index για ένα μικρό hot set. Το δύσκολο κομμάτι δεν είναι ποτέ η αποθήκευση. Είναι η τιμή του THRESHOLD και τι επιτρέπεις να μπει στην cache εξαρχής.

Ο κίνδυνος false-hit είναι όλο το παιχνίδι

Ένα false hit είναι όταν δύο αιτήματα βρίσκονται κοντά στον χώρο embedding αλλά θα έπρεπε να έχουν διαφορετικές απαντήσεις. "Ποια είναι η πολιτική επιστροφών μας για πελάτες στην ΕΕ" και "ποια είναι η πολιτική επιστροφών μας για πελάτες στις ΗΠΑ" μπορούν να κάτσουν επικίνδυνα κοντά η μία στην άλλη στον χώρο vector ενώ απαιτούν διαφορετικές απαντήσεις. Ένα χαλαρό threshold επιστρέφει την απάντηση της ΕΕ σε έναν χρήστη από τις ΗΠΑ και το κάνει με απόλυτη σιγουριά, γιατί το μοντέλο δεν συμβουλεύτηκε ποτέ.

Αυτό είναι χειρότερο από ένα κανονικό cache miss, που απλά σου κοστίζει μια κλήση μοντέλου. Ένα false hit σου κοστίζει μια λάθος απάντηση που φαίνεται σωστή. Οπότε το threshold πρέπει να συντονίζεται απέναντι σε πραγματική κίνηση, όχι να μαντεύεται, και πρέπει να είναι προκατειλημμένο προς την αυστηρότητα: ένα miss είναι φθηνό, ένα false hit μπορεί να είναι ένα ticket υποστήριξης ή ένα πρόβλημα συμμόρφωσης. Μέτρησε το ποσοστό false-hit σε ένα επισημασμένο δείγμα πριν εμπιστευτείς την cache με οτιδήποτε έχει σημασία.

Τι να μην κάνεις cache

Το semantic caching ταιριάζει σε σταθερή, γενική, κοινόχρηστη γνώση και δεν ταιριάζει σε τίποτα άλλο. Κάνε cache την απάντηση στο "πώς εξάγω τα δεδομένα μου", που είναι η ίδια για όλους. Μην κάνεις cache τίποτα που εξαρτάται από το ποιος ρωτά ή πότε. Κανόνες που αξίζει να επιβάλεις στον κώδικα:

  • Ποτέ μην κάνεις cache πέρα από όρια ταυτότητας. Κλείδωσε την cache ανά tenant, ή απέκλεισε οτιδήποτε είναι εξατομικευμένο. Μια κοινόχρηστη cache που αγνοεί τον καλούντα τελικά θα δώσει την απάντηση ενός πελάτη σε άλλον.
  • Ποτέ μην κάνεις cache ευαίσθητες στον χρόνο απαντήσεις. Υπόλοιπα, κατάσταση παραγγελίας και απόθεμα αλλάζουν κάτω από τα πόδια σου. Ένα μπαγιάτικο hit εδώ είναι ένα φρέσκο bug.
  • Κάνε cache το χωρίς ανάκτηση, όχι το βαρύ σε ανάκτηση. Αν η απάντηση εξαρτάται από έγγραφα που αλλάζουν, κάνε cache την αναζήτηση embedding, όχι την τελική απόκριση.

Η ακύρωση είναι το κομμάτι που όλοι παραλείπουν

Το παλαιότερο αστείο στην πληροφορική είναι ότι η ακύρωση cache είναι ένα από τα δύο δύσκολα προβλήματα, και ένα semantic cache δεν παίρνει εξαίρεση. Όταν η υποκείμενη αλήθεια αλλάζει, όταν μια πολιτική ενημερώνεται, μια τιμή αλλάζει, ένα έγγραφο αναθεωρείται, κάθε cached απάντηση που στηριζόταν στην παλιά αλήθεια είναι τώρα λάθος και θα συνεχίσει να δίνεται μέχρι να την αφαιρέσεις.

Δώσε στις εγγραφές ένα time-to-live αρκετά μικρό ώστε οι μπαγιάτικες απαντήσεις να λήγουν μόνες τους, και πρόσθεσε μια ρητή διαδρομή καθαρισμού συνδεδεμένη με τα γεγονότα που αλλάζουν τη θεμελιώδη αλήθεια: η δημοσίευση μιας νέας έκδοσης πολιτικής θα πρέπει να ακυρώνει το κομμάτι της cache που χτίστηκε πάνω στην παλιά. Χωρίς μια ιστορία ακύρωσης, ένα semantic cache δεν εξοικονομεί απλώς κλήσεις, καρφώνει σιωπηλά το προϊόν σου στα γεγονότα του χθες.

Το συμπέρασμα

Το semantic caching είναι μια πραγματική νίκη σε κόστος και latency για ερωτήσεις που είναι η ίδια ερώτηση με διαφορετικά λόγια, και είναι μια παγίδα για οτιδήποτε είναι εξατομικευμένο, ευαίσθητο στον χρόνο ή υπόκειται σε αλλαγή. Ο μηχανισμός είναι τετριμμένος: ενσωμάτωση, αναζήτηση, threshold. Η μηχανική είναι εξολοκλήρου στο threshold, στους κανόνες εύρους και στη διαδρομή ακύρωσης. Συντόνισε το threshold απέναντι σε επισημασμένη κίνηση, κάνε cache μόνο σταθερή κοινόχρηστη γνώση, και ακύρωσε στα γεγονότα που μετακινούν την αλήθεια. Κάνε αυτά τα τρία πράγματα και η cache πληρώνει τον εαυτό της. Παράλειψέ τα και θα δίνει λάθος απαντήσεις πιο γρήγορα από ό,τι το μοντέλο θα μπορούσε να δώσει σωστές.

Διάβασε αυτό στη συνέχεια

Για την πλευρά πλατφόρμας της λειτουργίας ενός vector store και της αφαίρεσής του υπό φόρτο, οι σημειώσεις πεδίου cloud βρίσκονται στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.