Βελτιστοποιήστε το κόστος χρήσης του LLM με το Semantic Cache

Δημιούργησα ένα σύστημα αναφοράς ρομπότ φυσικής γλώσσας, που τροφοδοτείται από την Retrieval Augmented Generation (RAG). Παρέδωσε μια μεγάλη εμπειρία στον χρήστη, ήταν σε θέση να αναζητήσουν τα δεδομένα και να πάρουν αναφορές διακοσμημένες και κομμένες από τις διαστάσεις που ήθελαν. Ήταν διαισθητική και παρείχε αποτελεσματικότητα. Μετατράπηκε τόνους δεδομένων σε υγρό χρυσό. Στη συνέχεια, ο νόμος LLM API ήρθε. Τότε συνειδητοποίησα ότι στην προσπάθειά μου να οικοδομήσω αυτή την νοημοσύνη, είχα δημιουργήσει μια οικονομική μαύρη τρύπα. Στη συνέχεια, ο νόμος LLM API ήρθε. Τότε συνειδητοποίησα ότι στην προσπάθειά μου να οικοδομήσω αυτή την νοημοσύνη, είχα δημιουργήσει μια οικονομική μαύρη τρύπα. Σε κάθε περιβάλλον, αυτά τα συστήματα Agentic AI κάνουν εκατοντάδες και χιλιάδες κλήσεις LLM, ξεκινώντας με την ανάπτυξη, eval, δοκιμές αποδοχής των χρηστών και στη συνέχεια στο περιβάλλον παραγωγής. Για να δημιουργήσουμε γειωμένες απαντήσεις, εφαρμόζουμε Retrieval Augmented Generation (RAG). Αυτό σημαίνει ότι κάνουμε ερωτήσεις σε καταστήματα φορέων για παρόμοιο περιεχόμενο και μεταφέρουμε τα δεδομένα που ανακτήθηκαν με τις ερωτήσεις των χρηστών, τις προειδοποιήσεις, τα παραδείγματα, τις οδηγίες φυλακής, το σχήμα δομημένης απάντησης κ.λπ. στο LLM. Αυτό σημαίνει ότι για μια απλή ερώτηση προσθέτουμε εκατοντάδες επιπλέον tokens στο όνομα του πλαισίου, φυλακές και λίγες προειδοποιήσεις κ.λπ. Τα μοντέλα μεγάλων γλωσσών (LLM) τα αναλύουν ως tokens και κάνουν τη δουλειά τους για να δημιουργήσουν την απάντηση και στη συνέχεια παίρνουμε την απάντηση στην ερώτησή Στο σύστημά μου, το σύστημα τραβά δεδομένα από το Vector DB και το Knowledge Graph για να θεμελιώσει την απάντηση. Παρατήρησα περίπου ~2000 tokens εισόδου στο παράθυρο πλαισίου. Το LLM στη συνέχεια δημιουργεί μια σκεπτόμενη, 500 token απάντηση. Με την πρώτη ματιά, αυτό είναι μόνο μερικά σεντς. Αλλά με 200.000 ερωτήσεις την ημέρα, αυτά τα "σεντς" μετατρέπονται σε ένα τέρας. Απλά προσθέστε ότι η χρήση με πολλούς χρήστες κατά τη διάρκεια των φάσεων ανάπτυξης και αξιολόγησης επίσης. Επί του παρόντος το κόστος ανά εκατομμύριο χρήση token καθώς η είσοδος και η έξοδος φαίνεται φθηνότερη καθώς είμαστε στα πρώτα στάδια της υιοθέτησης LLM api και οι πάροχοι υπηρεσιών έχουν σκόπιμα Μπορείτε επίσης να ανατρέξετε σε μερικά άρθρα που αναφέρουν τις προκλήσεις γύρω από το κόστος του LLM. Ο πόλεμος των τιμών LLM βλάπτει την εκπαίδευση - και τις νεοσύστατες επιχειρήσεις How scaling enterprise AI with the wrong LLM could cost you Έχω κατασκευάσει συστήματα με βάση το RAG χρησιμοποιώντας το LangGraph, το Neo4j, το ChromaDB και το Redis. Φέρνω αυτό το σχέδιο αρχιτεκτονικής που ονομάζεται Σημαντική Cache και λεπτομέρειες εφαρμογής για να μειώσετε την καύση token στην παραγωγή. Αυτό το σχέδιο μπορεί να μειώσει το κόστος χρήσης του LLM σας με την προσωρινή αποθήκευση και την απάντηση σε παρόμοιες ερωτήσεις αντί να επικαλείται το LLM κάθε φορά. Τι είναι η Κρυψώνα Cache has been there for ages in our IT System architecture. It started with In-Memory, then it became distributed. Initially there were few limited offerings for on-prem or VM based deployment. With the advent of cloud, many cloud offerings evolved. In today’s time, we have quite matured caching systems. However, usage of the caching system has been based on key value pairs. Keys are hashed and stored in a Hash table kind of data structure. Caching was always an exact key based lookup. If your key is present, the cache system will return the values for your key, and if the key does not, that means it was not stored or it was evicted. However, it was never meant for similarity based lookup. Τι είναι το Semantic Cache Οι φορείς με πολλαπλές διαστάσεις και η εύρεση φορέων χρησιμοποιώντας ομοιότητες cosine ή παρόμοιους μηχανισμούς υπήρχαν επίσης για μεγάλο χρονικό διάστημα. Ωστόσο, με το LLM και το RAG, οι ενσωματώσεις φορέων και η αναζήτηση ομοιότητας έχουν γίνει αρκετά δημοφιλείς. Το Vector RAG είναι μία από τις κύριες επιλογές λύσης για συστήματα που βασίζονται στο RAG. Αυτό βοηθά στην εύρεση παρόμοιου περιεχομένου. Αυτό δεν είναι ένα ακριβές κλειδί, αλλά βοηθά στην εύρεση των φορέων ενσωμάτωσης που είναι σημασιολογικά παρόμοιες. Αυτή η δυνατότητα αναπτύχθηκε αρχικά σε βάσεις δεδομένων Vector. αλλά τώρα, αυτή η δυνατότητα είναι επίσης διαθέσιμη σε συστήματα προσωρινής αποθήκευσης όπως το redis και τώρα οι πάροχοι υπηρεσιών cloud έχουν εισαγάγει επίσης αυτή τη δυνατότητα στις προσφορές προσωρινής αποθήκευσης. Μπορούμε να ορίσουμε τη σημασιολογική προσωρινή μνήμη ως μια προσωρινή μνήμη που συλλέγει καταχωρήσεις προσωρινής μνήμης με βάση το νόημα ενός περιεχομένου ή ενός εγγράφου αντί για το hash του κλειδιού. Μπορούμε να ορίσουμε τη σημασιολογική προσωρινή μνήμη ως μια προσωρινή μνήμη που συλλέγει καταχωρήσεις προσωρινής μνήμης με βάση το νόημα ενός περιεχομένου ή ενός εγγράφου αντί για το hash του κλειδιού. Πώς η σημασιολογική προσωρινή μνήμη είναι διαφορετική Ας κάνουμε μια γρήγορη διάκριση μεταξύ Cache, Semantic Cache και RAG. Οι παρακάτω πίνακες μπορούν να βοηθήσουν στην αποσαφήνιση των διαφορών μεταξύ της Παραδοσιακής Cache και της Σημαντικής Cache. 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. προσέγγιση Βασισμένο στο κλειδί Σημασία με βάση Κλειδί αναζήτησης Ακριβής αγώνας Παρόμοιος αγώνας Καλύτερα για ΑΠΙ LLMs Παράδειγμα Key, Value (Student_Id, Student_Obj) 2025081520, Φοιτητικό αντικείμενο1 2025091640, Φοιτητικό αντικείμενο2 Εάν το κλειδί που χρησιμοποιείται κατά την αναζήτηση είναι διαφορετικό, then it wont's return any result δηλώσεις Από πού αποφοίτησε ο Αλεξ; Από ποιο πανεπιστήμιο αποφοίτησε ο Αλεξ; Και οι δύο θα ανακτήσουν την ίδια είσοδο από την κρυφή μνήμη. Ο παρακάτω πίνακας μπορεί να βοηθήσει στην αποσαφήνιση των διαφορών μεταξύ του RAG και του Σημαντικού 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 Χρησιμοποιήστε To generate new response Για να επιστρέψετε προηγουμένως δημιουργημένες και προσωρινές απαντήσεις Δεδομένα Εξωτερικές πηγές δεδομένων όπως οι βάσεις δεδομένων vector Προηγούμενες ερωτήσεις και απαντήσεις Κόστος Μέσος έως υψηλός Χαμηλή Καλύτερα για ΓΕΝΙΟΠΟΙΗΣΗ ΑΠΑΝΤΗΣΕΩΝ Επαναλαμβανόμενη αλλά παρόμοια ερώτηση Μπορούμε να δούμε ότι η διαφορά μεταξύ της RAG και της σημασιολογικής προσωρινής αποθήκευσης είναι απλή, αλλά ο οικονομικός αντίκτυπος είναι μεγάλος. η RAG ανακτά πρώτες πληροφορίες και παράγει απαντήσεις. Εάν οι ερωτήσεις σας είναι επαναλαμβανόμενες, η προσωρινή αποθήκευση κερδίζει επειδή παρακάμπτει την ανάκτηση, την ορχήστρα εργαλείων και τη δημιουργία. Αρχιτεκτονική RAG βασισμένη σε σημασιολογικό cache Έχω σχεδιάσει την ακόλουθη αρχιτεκτονική για τη σημασιολογική προσωρινή αποθήκευση πάνω από την τυπική αρχιτεκτονική RAG. Στοιχεία της αρχιτεκτονικής Χρήστης: Από οποιονδήποτε πελάτη, όπως το πρόγραμμα περιήγησης ή την εφαρμογή για κινητές συσκευές, ένας API Q&A καλείται μόλις ένας χρήστης εισαγάγει οποιαδήποτε ερώτηση σε φυσική γλώσσα. API Gateway: Το αίτημα API είναι αυθεντικό και εξουσιοδοτημένο στο 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: Η μηχανή συλλογισμού για τον παράγοντα και η γεννήτρια για τα ερωτήματα Cypher για τις απαντήσεις GraphRAG και φυσικής γλώσσας. Παρατηρησιμότητα (LangSmith): Παρέχει παρακολούθηση, παρακολούθηση και χειραγώγηση για τα βήματα εκτέλεσης του πράκτορα. Το Γράφημα Γνώσης (Neo4j): Αποθηκεύει δομημένες σχέσεις (π.χ., (Άτομο)-[:WORKS_AT]->(Οργανισμός)) και αναζητείται μέσω του Cypher που δημιουργείται από το LLM. Vector Store (ChromaDB): Αποθηκεύει τις ενσωματώσεις vector που δημιουργούνται από το έγγραφο γνώσης. Για την εφαρμογή της σημασιολογικής προσωρινής αποθήκευσης, κυρίως το νέο στοιχείο σημασιολογικής προσωρινής αποθήκευσης MCP έχει προστεθεί στο πρότυπο 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. Εάν συμβεί το χτύπημα της μνήμης cache, τότε επιστρέφει την απάντηση χωρίς να κάνει καμία κλήση RAG, πράγμα που σημαίνει ότι ούτε η κλήση Vector db ούτε η κλήση γραφήματος γνώσης ούτε η κλήση LLM. Εάν η χαμένη προσωρινή μνήμη συμβεί, τότε εκτελεί το πρότυπο RAG και δημιουργεί την απάντηση. Το παρακάτω κομμάτι κώδικα δείχνει τον κώδικα του διακομιστή MCP για την αναζήτηση προσωρινής αποθήκευσης. Χρησιμοποίησα την αναζήτηση ομοιότητας με βάση το KNN και επέστρεψα μόνο 1 πλησιέστερη αντιστοιχία. Χρησιμοποιώ την απόσταση ως βαθμολογία και (1 βαθμολογία) ως ομοιότητα. Ένα άλλο σημαντικό σημείο είναι η χρήση της διαλέκτου 2, η οποία είναι απαραίτητη για τα ερωτήματα vector στο Redis, διαφορετικά το ερώτημα θα αποτύχει. @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)}" }) Πρώτα έχω υπολογίσει τις ενσωματώσεις της ερώτησης, η οποία αποθηκεύεται μαζί με την ακατέργαστη ερώτηση και την απάντηση ως τιμή για το κλειδί που είναι το πρότυπο md5 hash της ερώτησης. @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) }) Το παρακάτω στιγμιότυπο δείχνει την προσωρινή αποθήκευση ερωτήσεων και απαντήσεων στο Redis με ενσωματώσεις. Το ακόλουθο κομμάτι δείχνει τον κώδικα του πελάτη MCP για να καλέσει cache_lookup def cache_lookup(self, question: str) -> dict: return _run_async(self._req_with_connection("cache_lookup", question)) Το ακόλουθο κομμάτι δείχνει τον κώδικα του πελάτη MCP για να καλέσει το cache_store def cache_store(self, question: str, answer: str) -> dict: return _run_async(self._req_with_connection("cache_store", question, answer)) Το παρακάτω ίχνος μας δείχνει τη ροή της εκτέλεσης. Το trace επισημαίνεται κατά την κλήση cache_lookup και μπορείτε να δείτε την έξοδο ως cache_hit ως false με λόγο no_similar_question. Έτσι, σε αυτή τη ροή, εκτελείται το πρότυπο RAG. Μπορείτε να δείτε τον κόμβο graph_rag_query στο ίχνος ακολουθούμενο από μια κλήση LLM. Τώρα, είναι η στιγμή της αλήθειας, όταν μια παρόμοια ερώτηση τίθεται ξανά. Μπορούμε να δούμε στην παρακάτω στιγμιότυπο, η cache_hit είναι αληθινή. Υπάρχει μια μικρή αλλαγή στη διατύπωση της ερώτησης, αλλά είναι παρόμοια με την προηγούμενη, επομένως ο βαθμός ομοιότητας είναι 0.9866 όπως φαίνεται παρακάτω. Ως εκ τούτου, η απάντηση ανακτάται απευθείας από την προσωρινή μνήμη και δεν θα δείτε την εκτέλεση ροής RAG. Η απάντηση επιστρέφεται απευθείας από τη σημασιολογική προσωρινή μνήμη. Αποτέλεσμα Η προσθήκη σημασιολογικής κρυπτογράφησης σε ένα σύστημα GraphRAG ή VectorRAG παρείχε μετρήσιμη απόδοση και οφέλη κόστους. Προηγουμένως, το σύστημα χρειάστηκε 5 έως 6 δευτερόλεπτα ανά αίτημα, το οποίο περιλαμβάνει αναζήτηση Vector, δημιουργία και εκτέλεση ερωτήματος κρυπτογράφησης Γνώσης και τελική παραγωγή απαντήσεων από το LLM. Όταν συνέβη το χτύπημα κρυπτογράφησης, οι απαντήσεις ήταν στην οθόνη του χρήστη σε 900 ms έως 1,2 δευτερόλεπτα. Στρατηγική Semantic Cache Πού κερδίζει το Semantic Cache Όταν ένα σύστημα χειρίζεται υψηλό όγκο, προβλέψιμη κυκλοφορία, ένα στρώμα προσωρινής αποθήκευσης προσθέτει ένα όφελος απόδοσης. κερδίζει όταν η ίδια γνώση ζητείται από πολλούς χρήστες, όπως στην περίπτωση χρήσης "Εξυπηρέτηση πελατών & Helpdesks", όπου οι ερωτήσεις είναι όπως "Πώς επαναφέρω τον κωδικό μου;", "Ποια είναι η πολιτική επιστροφής χρημάτων σας;" Σε περιπτώσεις χρήσης Τεκμηρίωσης προϊόντων, όπου οι χρήστες αναζητούν τα ίδια εγχειρίδια προϊόντων. Αυτό συμβαίνει ακόμη και όταν οι προγραμματιστές αναζητούν την ίδια τεχνική τεκμηρίωση και έγγραφα API. Σε εσωτερικές περιπτώσεις χρήσης HR & Onboarding, όπου ερωτήσεις όπως "Πώς μπορώ να εγγραφώ στην Πότε να αποφύγετε τη σημασιολογική προσωρινή μνήμη Αποτυγχάνει ειδικά σε εκείνα τα συστήματα που παρέχουν υπερ εξατομίκευση. Εάν δύο χρήστες ρωτήσουν την ίδια ερώτηση αλλά απαιτούν διαφορετικές απαντήσεις με βάση το ιατρικό τους ιστορικό ή το προφίλ ή το υπόλοιπο του λογαριασμού τους, μια σημασιολογική προσωρινή μνήμη μπορεί να παρέχει λανθασμένες απαντήσεις. Αποτυγχάνει ακόμη και όταν τα έγγραφα, η βάση γνώσεων και τα δεδομένα σας είναι ευμετάβλητα ή είναι σε πραγματικό χρόνο, όπως όταν χρειάζεστε απαντήσεις σχετικά με τις τιμές των μετοχών ή το ζωντανό απόθεμα, μια προσωρινή μνήμη είναι ο εχθρός σας. χρειάζεστε το RAG για να δείτε την τρέχουσα κατάσταση του κόσμου. Στρατηγική Semantic Cache Invalidation Μια προσωρινή μνήμη πρέπει να ανανεωθεί και η σημασιολογική προσωρινή μνήμη χρειάζεται πρόσθετη στρατηγική ακυρότητας. Κάθε καταχώρηση προσωρινής μνήμης πρέπει να επισημαίνεται με ένα created_at timestamp για να διαχειριστεί τις τιμές του live(TTL). Στην σημασιολογική προσωρινή μνήμη πρέπει επίσης να επισημαίνεται το document_version και το embedding_model που χρησιμοποιούνται κατά τη διάρκεια της παραγωγής. Αυτό είναι κρίσιμο επειδή αν αναβαθμίσετε το μοντέλο ενσωμάτωσης, το χώρο του φορέα σας μετατοπίζεται. Αυτό καθιστά τις παλιές καταχωρήσεις προσωρινής μνήμης ξεπερασμένες. Πρέπει να παρακολουθούμε αυτές τις μεταβλητές, ώστε να μπορούμε να προκαλέσουμε ακυρότητα προσωρινής μ Αδειοδότηση και θέματα ασφαλείας Σε οποιοδήποτε σύστημα προσωρινής αποθήκευσης, πρέπει να βεβαιωθείτε ότι επιτρέπει πριν παράσχει τα δεδομένα στον χρήστη. πρέπει επίσης να βεβαιωθείτε ότι τα δεδομένα προσωρινής αποθήκευσης είναι ασφαλή κατά την ανάπαυση επίσης. Σε ένα σύστημα πολλαπλών ενοικιαστών, τα κλειδιά απομόνωσης ενοικιαστών πρέπει να εφαρμοστούν στην προσωρινή μνήμη. Παρόμοια με το σύστημα του υπερπροσωπικού χρήστη, ο διαχωρισμός χώρου ονομάτων σε επίπεδο χρήστη πρέπει να γίνει στην προσωρινή μνήμη. Το πιο σημαντικό σημείο σχετικά με την εξουσιοδότηση είναι η δημιουργία κλειδιών προσωρινής αποθήκευσης με γνώση δικαιωμάτων, όπου το hash του κλειδιού περιλαμβάνει τους συγκεκριμένους ρόλους ή τα επίπεδα πρόσβασης του χρήστη. Αυτό εξασφαλίζει ότι ένας χρήστης με λιγότερα προνόμια δεν λαμβάνει μια προσωρινή απάντηση από έναν πιο προνομιούχο χρήστη. Ένα χτύπημα προσωρινής αποθήκευσης δεν πρέπει να είναι ένας μη εξουσιοδοτημένος μηχανισμός ανάκτησης δεδομένων. Τέλος, για να ικανοποιήσετε διάφορες απαιτήσεις συμμόρφωσης όπως το HIPPA ή το SOC2, οι απαντήσεις σας πρέπει να είναι κρυπτογραφημένες πριν από την προσωρινή αποθήκευση. Συμπέρασμα Το αρχιτεκτονικό σχέδιο, τα αποσπάσματα κώδικα και τα διάφορα στιγμιότυπα αποδεικνύουν ότι είναι δυνατόν να αποθηκευτούν σημασιολογικά οι ερωτήσεις και να πραγματοποιηθεί μια αναζήτηση ομοιότητας με βάση τις ενσωματώσεις φορέων για να επιστραφούν οι απαντήσεις που δημιουργήθηκαν προηγουμένως για να αποφευχθούν οι κλήσεις LLM με βάση το RAG για παρόμοιες ερωτήσεις. Το παραπάνω παράδειγμα είναι αρκετά απλό, ωστόσο μπορούμε να επεκτείνουμε αυτή την επιλογή αρχιτεκτονικής για πολλαπλά σημεία επαφής LLM που συμβαίνουν στο σύστημα Agentic AI για να κάνουν αποφάσεις όχι μόνο για τις ερωτήσεις και τις απαντήσεις των τελικών χρηστών. Η σημασιολογική προσωρινή αποθήκευση είναι ένας απλός τρόπος για να μειώσετε το κόστος των token διατηρώντας παράλληλα την ποιότητα της ανταπόκρισης. Εάν το σύστημά σας λαμβάνει παρόμοια ερωτήματα για να απαντήσει, η προσθήκη ενός επιπέδου προσωρινής αποθήκευσης πριν από τα βήματα ανάκτησης και παραγωγής είναι ένα πλεονέκτημα. το ευκολότερο μέρος είναι ότι δεν χρειάζεται να αναθεωρήσετε την αρχιτεκτονική RAG σας, απλά βελτιστοποιείτε τη ροή χειριζόμενος επαναλαμβανόμενη πρόθεση νωρίτερα στην αλυσίδα.