Prompt caching σε AI agents: χαμηλότερο latency χωρίς stale ή προσωπικά δεδομένα
Ένας AI agent μπορεί να στέλνει σε κάθε κλήση τις ίδιες οδηγίες, definitions εργαλείων, παραδείγματα και μεγάλο εταιρικό context. Αν αυτό το σταθερό τμήμα επεξεργάζεται από την αρχή κάθε φορά, αυξάνονται το κόστος input tokens και ο χρόνος μέχρι την πρώτη απάντηση. Το prompt caching επιτρέπει στον provider να επαναχρησιμοποιήσει ένα ήδη επεξεργασμένο prefix.
Η τεχνική είναι πολύ χρήσιμη, αλλά δεν είναι ένα γενικό cache απαντήσεων. Δεν θυμάται αυθαίρετα τι είπε ο agent και δεν κάνει τα δεδομένα μόνιμα φρέσκα. Για να αποδώσει χρειάζεται σωστή δομή prompt, σαφή απομόνωση δεδομένων και μετρήσεις πραγματικών cache hits.
Prompt caching και semantic caching δεν είναι το ίδιο
Στο prompt caching αποθηκεύεται εσωτερικά η υπολογιστική αναπαράσταση ενός ακριβώς ίδιου αρχικού τμήματος του prompt. Το μοντέλο συνεχίζει να παράγει νέα απάντηση για το μεταβλητό μέρος. Η επίσημη τεκμηρίωση της Anthropic αναφέρει ότι τα cache hits απαιτούν 100% ταύτιση του prefix και ότι η παραγωγή output tokens δεν αλλάζει.
Στο semantic response cache, αντίθετα, η εφαρμογή αναζητά παρόμοια προηγούμενη ερώτηση και μπορεί να επιστρέψει έτοιμη απάντηση. Αυτό έχει διαφορετικούς κινδύνους ορθότητας, freshness και permissions. Ένας agent μπορεί να χρησιμοποιεί και τα δύο, αλλά πρέπει να παρακολουθούνται ως ξεχωριστοί μηχανισμοί.
Πώς πρέπει να δομηθεί το prompt
Η βασική αρχή είναι: σταθερά στοιχεία πρώτα, μεταβλητά στοιχεία μετά. Στην αρχή τοποθετούνται οι system instructions, τα tool definitions, σταθερά παραδείγματα και κοινό background context. Μετά το cache breakpoint μπαίνουν το μήνυμα του χρήστη, ο τρέχων χρόνος, τα αποτελέσματα αναζήτησης και άλλα request-specific δεδομένα.
Αν ένα timestamp ή user ID μπει μέσα στο prefix, κάθε αίτημα γίνεται διαφορετικό και το cache δεν χτυπά. Ακόμη και μικρή αλλαγή σε tool schema ή system prompt δημιουργεί νέο prefix. Σε agentic εφαρμογές αυτό σημαίνει ότι η σειρά των tools και η σειριοποίηση των JSON schemas πρέπει να είναι σταθερές και ντετερμινιστικές.
Ένα πρακτικό layout είναι:
- έκδοση πολιτικής και σταθερές οδηγίες
- tool definitions σε σταθερή σειρά
- κοινά παραδείγματα και μεγάλο reusable context
- cache breakpoint
- tenant και user context που επιτρέπεται για το αίτημα
- πρόσφατα δεδομένα από CRM ή knowledge base
- τρέχον μήνυμα και tool results
Τι εξοικονομεί και τι όχι
Το κέρδος εμφανίζεται όταν το κοινό prefix είναι μεγάλο και επαναχρησιμοποιείται αρκετές φορές μέσα στο TTL. Υπάρχει συνήθως κόστος cache write στην πρώτη κλήση και χαμηλότερο κόστος ανάγνωσης στις επόμενες. Αν το prefix χρησιμοποιηθεί μόνο μία φορά ή αλλάζει συνέχεια, το caching μπορεί να μην έχει οικονομικό όφελος.
Το prompt caching μειώνει την επεξεργασία input, όχι το μήκος ή το κόστος της παραγόμενης απάντησης. Δεν κάνει τα tools ταχύτερα και δεν μειώνει τον χρόνο μιας αργής βάσης δεδομένων. Επίσης δεν αντικαθιστά τη συμπίεση context: ένα agent loop που συσσωρεύει αδιάκριτα tool results εξακολουθεί να χρειάζεται σωστή διαχείριση ιστορικού.
Στην Anthropic, για παράδειγμα, το προεπιλεγμένο TTL είναι πέντε λεπτά και υπάρχει επιλογή μίας ώρας με διαφορετική χρέωση. Αυτά είναι χαρακτηριστικά συγκεκριμένου provider και μπορούν να αλλάξουν, άρα η εφαρμογή πρέπει να διαβάζει την τρέχουσα τεκμηρίωση και να μην ενσωματώνει αυθαίρετες παραδοχές.
Cache invalidation και εκδόσεις
Η invalidation δεν πρέπει να βασίζεται μόνο στον χρόνο. Όταν αλλάζει η πολιτική του agent, ένα tool schema, το μοντέλο ή το κοινό knowledge pack, χρειάζεται νέα έκδοση. Ένα λογικό cache identity μπορεί να περιλαμβάνει model ID, prompt version, tools version και knowledge version.
Στο provider-managed exact-prefix cache η αλλαγή περιεχομένου προκαλεί φυσικά cache miss. Η ρητή versioning παραμένει χρήσιμη για observability: εξηγεί γιατί έπεσε το hit rate και ποια έκδοση απάντησε σε ένα περιστατικό.
Δεν πρέπει να επιχειρείται τεχνητή διατήρηση cache hit με παλιά εργαλεία ή οδηγίες. Η ορθότητα και η ασφάλεια είναι σημαντικότερες από μερικά cached tokens.
Προσωπικά δεδομένα και tenant isolation
Το πιο κρίσιμο ερώτημα είναι ποια δεδομένα βρίσκονται μέσα στο κοινό prefix. Company-wide πολιτικές και δημόσια εγχειρίδια μπορεί να είναι κατάλληλα. Προσωπικά στοιχεία πελάτη, ιδιωτικές συνομιλίες και αποτελέσματα CRM δεν πρέπει να μοιράζονται ανάμεσα σε tenants ή χρήστες μόνο και μόνο για υψηλότερο hit rate.
Οι providers εφαρμόζουν δικούς τους μηχανισμούς απομόνωσης. Η τεκμηρίωση της Anthropic αναφέρει organization ή workspace isolation ανά πλατφόρμα. Η εφαρμογή όμως παραμένει υπεύθυνη για authorization πριν δημιουργήσει το prompt. Ένα cached prefix δεν πρέπει να περιλαμβάνει έγγραφο που ο επόμενος χρήστης δεν δικαιούται να δει.
Σε custom cache ή semantic cache χρειάζεται tenant ID στο key, έλεγχος δικαιωμάτων κατά την ανάγνωση, περιορισμένο TTL και πολιτική διαγραφής. Τα logs δεν πρέπει να αποθηκεύουν ολόκληρο prompt ή PII όταν αρκούν hashes, versions και token counts.
RAG, freshness και stale context
Τα έγγραφα ενός RAG συστήματος αλλάζουν με διαφορετική συχνότητα. Ένα σταθερό εγχειρίδιο προϊόντος μπορεί να μπει σε cached prefix, ενώ η σημερινή διαθεσιμότητα ή η κατάσταση παραγγελίας πρέπει να ανακτάται κάθε φορά από την πηγή.
Χρήσιμη πρακτική είναι ο διαχωρισμός knowledge layers:
- σταθερές οδηγίες και definitions με μεγαλύτερη επαναχρησιμοποίηση
- versioned εταιρικά έγγραφα με invalidation όταν αλλάζουν
- δυναμικά operational δεδομένα μετά το breakpoint
- permissions και user context σε κάθε request
Αν η απάντηση εξαρτάται από τρέχουσα τιμή ή status, ο agent πρέπει να χρησιμοποιεί tool ακόμη κι αν σχετικό παλιό κείμενο υπάρχει στο cache. Το caching δεν είναι απόδειξη επικαιρότητας.
Παρακολούθηση που δείχνει αν λειτουργεί
Το βασικό metric είναι το cache hit rate, αλλά δεν αρκεί. Χρειάζονται cache creation tokens, cache read tokens, uncached input tokens, time to first token, συνολικό latency και πραγματικό κόστος ανά επιτυχημένη εργασία. Η Anthropic, για παράδειγμα, επιστρέφει πεδία cache_creation_input_tokens και cache_read_input_tokens για να μετρηθεί η συμπεριφορά.
Τα metrics πρέπει να αναλύονται ανά agent, prompt version και model. Ένα συνολικό υψηλό hit rate μπορεί να κρύβει ότι ο πιο ακριβός agent δεν έχει hits. Παράλληλα παρακολουθούνται correctness και tool success rate, επειδή μια φθηνότερη κλήση δεν έχει αξία αν χρησιμοποιεί λάθος context.
Χρήσιμα alerts είναι η απότομη πτώση hit rate μετά από deployment, η αύξηση cache writes, το prefix που έγινε υπερβολικά μεγάλο και η εμφάνιση ευαίσθητων πεδίων σε telemetry.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry αντιμετωπίζουμε το prompt caching ως μέρος της αρχιτεκτονικής ενός production AI agent, όχι ως μεμονωμένη ρύθμιση API. Χαρτογραφούμε ποιο context είναι πραγματικά σταθερό, ποιο αλλάζει ανά tenant και ποιο πρέπει να ανακτάται live. Στη συνέχεια οργανώνουμε prompts και tools με versioning, σταθερή σειριοποίηση και σαφή cache boundaries.
Στις υλοποιήσεις μας μετράμε cache reads και writes μαζί με latency, κόστος και ποιότητα αποτελέσματος. Εφαρμόζουμε tenant-aware authorization πριν συντεθεί το prompt, redaction στα logs και controlled invalidation όταν αλλάζουν policies, tools ή knowledge. Έτσι η βελτιστοποίηση δεν θυσιάζει την ιδιωτικότητα ούτε αφήνει τον agent να βασίζεται σε ξεπερασμένες πληροφορίες.
Checklist πριν μπει σε production
- Είναι σαφές ποιο ακριβώς prefix παραμένει ίδιο;
- Βρίσκονται timestamps και δυναμικά IDs μετά το breakpoint;
- Υπάρχει versioning για prompt, tools, model και knowledge;
- Απομονώνονται tenant και user-specific δεδομένα;
- Ελέγχεται authorization πριν μπει έγγραφο στο prompt;
- Μετρώνται cache writes, reads, latency και κόστος;
- Υπάρχει σχέδιο για αλλαγές provider και TTL;
- Παραμένει η ορθότητα σημαντικότερη από το hit rate;
Το prompt caching αποδίδει όταν επαναχρησιμοποιεί μεγάλο, σταθερό και εξουσιοδοτημένο context. Με τη σωστή δομή μπορεί να κάνει έναν agent οικονομικότερο και πιο γρήγορο, χωρίς να μετατρέψει την προσωρινή βελτιστοποίηση σε πηγή παλιών ή λάθος δεδομένων.