Ένας agent που θυμάται επικολλώντας ολόκληρο το ιστορικό του στο επόμενο prompt δεν έχει μνήμη. Έχει έναν αυξανόμενο λογαριασμό, ένα σκληρό όριο tokens, και μια καμπύλη καθυστέρησης που χειροτερεύει με κάθε turn. Η πραγματική μνήμη είναι μια απόφαση αποθήκευσης: τι διατηρείς, πού το βάζεις, και πώς ανακτάς μόνο το σχετικό κομμάτι πίσω κατά τη στιγμή του inference. Αυτό είναι πρόβλημα βάσης δεδομένων, και το να το αντιμετωπίζεις σαν πρόβλημα prompt είναι ο τρόπος με τον οποίο agents που κάνουν καλό demo καταρρέουν τη δεύτερη εβδομάδα.

Το δελεαστικό στο context stuffing είναι ότι δουλεύει στην αρχή. Νωρίς σε μια συνεδρία το ιστορικό είναι σύντομο, όλα χωράνε, και ο agent φαίνεται να θυμάται. Μετά η συνομιλία μεγαλώνει, το prompt μεγαλώνει μαζί της, και τρία πράγματα συμβαίνουν ταυτόχρονα: το κόστος ανεβαίνει γιατί ξαναστέλνεις τα πάντα κάθε turn, η καθυστέρηση ανεβαίνει γιατί το μοντέλο διαβάζει περισσότερα κάθε φορά, και τελικά χτυπάς το παράθυρο context και παλιά γεγονότα πέφτουν σιωπηλά από την αρχή. Η αποτυχία δεν είναι bug που μπορείς να διορθώσεις. Είναι η αρχιτεκτονική.

Δύο είδη μνήμης, δύο είδη αποθήκευσης

Η «μνήμη» είναι στην πραγματικότητα δύο διαφορετικές ανάγκες, και το να τις συγχέεις είναι εκεί που οι σχεδιασμοί πάνε στραβά.

Μνήμη συνεδρίας και εργασίας: ένα key-value store

Τα πρόσφατα turns, η τρέχουσα κατάσταση εργασίας, οι βραχυπρόθεσμες προτιμήσεις του χρήστη, αυτά αναζητούνται με ένα γνωστό κλειδί: ένα session ID, ένα user ID, ένα thread ID. Θέλεις γρήγορες αναγνώσεις και εγγραφές σε αυτό το κλειδί και ένα time-to-live ώστε παλιές συνεδρίες να λήγουν μόνες τους. Αυτό είναι ένας πίνακας DynamoDB, όχι μια vector search. Κάνε partition στη συνεδρία ή τον χρήστη, κράτα την τρέχουσα κατάσταση ως ένα item, όρισε ένα TTL, και διάβασέ το πίσω στην αρχή κάθε turn. Χωρίς embeddings, χωρίς ομοιότητα, μόνο μια γρήγορη αναζήτηση με κλειδί για το «πού είχαμε μείνει».

Μακροπρόθεσμη σημασιολογική μνήμη: ένα vector store

Τα γεγονότα που ένας agent πρέπει να θυμάται ανάμεσα σε συνεδρίες, προηγούμενες αποφάσεις, μαθημένες προτιμήσεις, σχετικές παλιές ανταλλαγές, δεν αναζητούνται με κλειδί. Αναζητούνται με νόημα: «τι ξέρω που είναι σχετικό με αυτό το νέο μήνυμα». Αυτό είναι σημασιολογική αναζήτηση πάνω σε embeddings, που είναι για αυτό υπάρχει ένα vector store. Στο AWS η πρακτική επιλογή είναι το Aurora Serverless v2 με pgvector: τα embeddings σου ζουν δίπλα σε relational δεδομένα, τα κάνεις query με SQL, και δεν στήνεις μια ξεχωριστή εξειδικευμένη βάση δεδομένων για να το κάνεις.

Το pattern: ανάκτηση, όχι συσσώρευση

Μόλις η μνήμη γίνει βάση δεδομένων, κάθε turn σταματά να προσθέτει και αρχίζει να κάνει query. Ο βρόχος γίνεται:

on each turn:
  1. read session state by key      (DynamoDB: where were we)
  2. embed the new user message
  3. semantic search long-term store (pgvector: what is relevant)
  4. assemble a bounded prompt:
       system + tools
       + top-k retrieved memories
       + recent turns from session state
       + new message
  5. call the model
  6. write new facts back to the stores

Το prompt είναι πλέον οριοθετημένο ανεξάρτητα από το πόσο μεγάλη γίνεται η σχέση με τον χρήστη. Μια συνομιλία στο χιλιοστό της turn στέλνει prompt ίδιου μεγέθους με το δέκατο της, γιατί ανακτάς τη σχετική χούφτα μνημών αντί να τις κουβαλάς όλες. Το κόστος και η καθυστέρηση παραμένουν σταθερά αντί να ανεβαίνουν. Αυτή είναι η ίδια πειθαρχία ανάκτησης που κάνει το RAG να δουλεύει, εφαρμοσμένη στο ίδιο το ιστορικό του agent αντί σε ένα corpus εγγράφων.

Τι πρέπει να αποφασίσεις, που ένα prompt κρύβει

Το να μετακινήσεις τη μνήμη σε μια βάση δεδομένων επιβάλλει επιλογές που το context stuffing σου επέτρεπε να αγνοείς, και αυτές οι επιλογές είναι η πραγματική μηχανική:

  • Τι αξίζει να θυμάσαι. Δεν είναι κάθε turn μια μνήμη. Γράψε διαρκή γεγονότα και αποφάσεις, όχι κουβεντούλες, αλλιώς η αποθήκη σου γεμίζει με θόρυβο που η ανάκτηση μετά αναδεικνύει.
  • Πότε να ξεχνάς. TTLs στην κατάσταση συνεδρίας, και μια πολιτική για γήρανση ή αντικατάσταση μακροπρόθεσμων γεγονότων, ώστε μια παλιά προτίμηση να μην υπερισχύει μιας διορθωμένης.
  • Πόσα να ανακτάς. Το top-k είναι ένα κουμπί. Πολύ λίγο και ο agent ξεχνάει, πολύ πολύ και είσαι πίσω σε ένα φουσκωμένο prompt με το βήμα ανάκτησης να μην προσθέτει καμία αξία.
  • Συνέπεια μεταξύ των δύο αποθηκών. Η κατάσταση συνεδρίας και η σημασιολογική μνήμη μπορούν να διαφωνούν. Αποφάσισε ποια κερδίζει όταν συμβεί αυτό.

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

Το context stuffing δεν είναι μνήμη, είναι αναβολή μιας απόφασης αποθήκευσης μέχρι ο λογαριασμός tokens και το όριο context να την πάρουν αντί για σένα. Χώρισε το πρόβλημα: γρήγορη κατάσταση συνεδρίας με κλειδί στο DynamoDB, σημασιολογική μακροπρόθεσμη ανάκληση στο pgvector πάνω στο Aurora, και ένα βήμα ανάκτησης ανά turn που συναρμολογεί ένα οριοθετημένο prompt και από τα δύο. Τη στιγμή που η μνήμη γίνεται βάση δεδομένων με βήμα ανάκτησης αντί για ένα διαρκώς αυξανόμενο prompt, το κόστος και η καθυστέρηση σταματούν να κλιμακώνονται με το μήκος της συνομιλίας, και αποφασίζεις εσύ τι θυμάται ο agent αντί να αφήνεις το παράθυρο να αποφασίσει τι ξεχνά.

Διάβασε επίσης

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