Zoptymalizuj koszty korzystania z LLM za pomocą semantycznej pamięci podręcznej

Zbudowaliśmy system raportowania botów czatu w naturalnym języku, zasilany przez Retrieval Augmented Generation (RAG). Zapewnił on użytkownikowi świetne doświadczenie, byli w stanie przesłać zapytania do danych i uzyskać raporty wyciśnięte i nacięte według potrzebnych wymiarów. Był intuicyjny i zapewniał wydajność. Zamienił ton danych w płynne złoto. Potem przyszedł projekt ustawy LLM API. Wtedy zdałem sobie sprawę, że w moim dążeniu do budowania tej inteligencji stworzyłem czarną dziurę finansową. Potem przyszedł projekt ustawy LLM API. Wtedy zdałem sobie sprawę, że w moim dążeniu do budowania tej inteligencji stworzyłem czarną dziurę finansową. W dzisiejszym świecie IT każdy zespół stara się zbudować system Agentic AI. W każdym środowisku te systemy Agentic AI wykonują setki i tysiące połączeń LLM, począwszy od rozwoju, eval, testowania akceptacji użytkowników, a następnie w środowisku produkcyjnym. Aby generować odpowiedzi uziemione, wdrażamy Retrieval Augmented Generation (RAG). Oznacza to, że zapytamy magazyny wektorowe o podobną treść i przekazujemy pobrane dane z pytaniami użytkowników, prośbami, przykładami, instrukcjami gardrails, strukturalnym schematem odpowiedzi itp. Do LLM. Oznacza to, że dla prostego pytania dodajemy setki dodatkowych tokenów w nazwie kontekstu, gardrails i kilka wskazówek itp. Modele dużego języka (LLM) analizują je jako tokeny i wykonują swoją pracę, aby wygenerować odpowiedź, a następnie otrzymujemy odpowiedź na nasze pytanie. Ta odpowiedź może być odpowiedzią na nasze pytanie lub może być strukturalną odpowiedzią na jeden z kroków w multiagentowym przepływie pracy W moim systemie system pobiera dane z Vector DB i Knowledge Graph, aby uzyskać odpowiedź. Obserwowałem około ~2000 tokenów wejściowych w oknie kontekstowym. LLM następnie generuje przemyślaną, 500 tokenową odpowiedź. Na pierwszy rzut oka, to tylko kilka centów. Ale z 200 000 zapytań dziennie, te "centy" przekształcają się w potwora. Po prostu dodaj to użycie z wieloma użytkownikami podczas fazy rozwoju i oceny. Obecnie koszt na milion użycia tokenów, ponieważ wejście i wyjście wygląda taniej, ponieważ jesteśmy na wczesnych etapach przyjęcia LLM api i dostawcy usług świadomie dali wiele zniżek. W przyszłości ceny te będą wyższe, a następnie ogólny koszt od rozwoju do produkcji do obsługi i konserwacji tych systemów znacznie wzro Możesz również odwołać się do kilku artykułów cytujących wyzwania związane z kosztami LLM. Wojna cenowa LLM rani edukację - i start-upy Jak skalowanie przedsiębiorstwa AI z niewłaściwym LLM może Cię kosztować Zbudowałem systemy oparte na RAG za pomocą LangGraph, Neo4j, ChromaDB i Redis. Przynoszę ten wzorzec architektury o nazwie Semantic Cache i szczegóły wdrożenia, aby zmniejszyć spalanie tokenów w produkcji. Ten wzorzec może zmniejszyć koszty użytkowania LLM poprzez pamięć podręczną i odpowiedzi na podobne pytania zamiast powoływać się na LLM za każdym razem. Pozwól mi przedstawić ci ten wzorzec, który możesz zastosować w wielu przypadkach użytkowania i w wielu punktach dotykowych w Twoim przepływie pracy Agentic AI. Co to jest ukrycie Cache istnieje od wieków w naszej architekturze systemów IT. Zaczęło się od pamięci wewnętrznej, a następnie stało się rozpowszechniane. Początkowo było niewiele ograniczonych ofert dla wdrożenia on-prem lub VM. Wraz z nadejściem chmury wiele ofert w chmurze ewoluowało. W dzisiejszych czasach mamy dość dojrzałe systemy pamięci podręcznej. Jednak użycie systemu pamięci podręcznej opiera się na parach wartości klucza. Klucze są hashowane i przechowywane w strukturze danych typu tabeli hash. Caching był zawsze dokładnym wyszukiwaniem opartym na kluczach. Jeśli twój klucz jest obecny, system pamięci podręcznej zwróci wartości dla twojego klucza, a jeśli klucz nie jest, oznacza to Co to jest cache semantyczny Wektory o wielu wymiarach i znalezienie wektorów przy użyciu podobieństwa kosynowego lub podobnych mechanizmów istniały również przez długi czas. Jednak z LLM i RAG wektorowe osadzenia i wyszukiwanie podobieństw stały się dość popularne. Vector RAG jest jednym z głównych wyborów rozwiązań dla systemów opartych na RAG. To pomaga w znalezieniu podobnej zawartości. To nie jest dokładny klucz, ale pomaga w znalezieniu wektorów osadzonych, które są semantycznie podobne. Ta funkcja została początkowo opracowana w bazach danych Vector, ale teraz jest dostępna również w systemach pamięci podręcznej, takich jak redis, a teraz dostawcy usług chmury wprowadzili tę funkcję również w swoich ofertach pamięci podręcznej. Możemy zdefiniować semantyczną pamięć podręczną jako pamięć podręczną, która pobiera wpisy podręczne w oparciu o znaczenie zawartości lub dokumentu zamiast hash klucza. Możemy zdefiniować semantyczną pamięć podręczną jako pamięć podręczną, która pobiera wpisy podręczne w oparciu o znaczenie zawartości lub dokumentu zamiast hash klucza. Jak różni się semantyczna pamięć podręczna Zróbmy szybką różnicę między Cache, Semantic Cache i RAG. Poniższe tabele mogą pomóc w wyjaśnieniu różnic między tradycyjną pamięcią podręczną a semantyczną pamięcią podręczną. 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. Podejście Klucz oparty Znaczenie oparte Kluczowe wyszukiwanie Dokładny mecz Podobny mecz Najlepiej dla Apię LLMs Przykład Klucz, Wartość (Student_Id, Student_Obj) 2025081520, StudentObject1 2025091640, StudentObject2 jeśli klucz używany podczas wyszukiwania jest inny, Następnie zwraca dowolny wynik Oświadczenia Skąd się wziął Alex? Z jakiego uniwersytetu ukończył studia Alex? Obydwoje otrzymują ten sam wpis z pamięci podręcznej. Poniższa tabela może pomóc w wyjaśnieniu różnic między RAG i Semantic 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 Użyj Aby wygenerować nową odpowiedź Aby zwrócić wcześniej wygenerowane i przechowywane odpowiedzi Dane Zewnętrzne źródła danych, takie jak wektorowe bazy danych Pytania i odpowiedzi wygenerowane wcześniej Koszty Średnie do wysokie niskiej Najlepiej dla Generacja reagująca Powtarzające się, ale podobne pytania Widzimy, że różnica między pamięcią podręczną RAG a pamięcią podręczną Semantic jest prosta, ale wpływ finansowy jest duży. RAG pobiera surowe informacje i generuje odpowiedzi. Architektura RAG oparta na pamięci podręcznej Zaprojektowałem następującą architekturę dla pamięci podręcznej semantycznej nad standardową architekturą RAG. Składniki architektury Użytkownik: Z dowolnego klienta, takiego jak przeglądarka lub aplikacja mobilna, nawołuje się API Q&A, gdy użytkownik wpisze jakiekolwiek pytanie w języku naturalnym. API Gateway: żądanie API jest uwierzytelniane i autoryzowane w 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: silnik rozważania dla agenta i generator dla zapytań Cypher dla GraphRAG i odpowiedzi języka naturalnego. Observability (LangSmith): Zapewnia śledzenie, monitorowanie i debugowanie kroków wykonania agenta. Graf wiedzy (Neo4j): przechowuje strukturalne relacje (np. (osoba)-[:WORKS_AT]->(Organizacja)) i jest kwestionowany za pośrednictwem cyfery generowanej przez LLM. Vector Store (ChromaDB): przechowuje wektorowe osadzenia generowane z dokumentu wiedzy. Aby wdrożyć pamięć podręczną semantyczną, w standardowym systemie agentów opartym na RAG dodano głównie nowy składnik MCP pamięci podręcznej semantycznej. 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. Jeśli zdarzy się uderzenie pamięci podręcznej, zwraca odpowiedź bez wykonywania żadnego połączenia RAG, co oznacza, że nie ma ani wektorowego db, ani połączenia graficznego wiedzy, ani połączenia LLM. Jeśli zdarzy się pominięcie pamięci podręcznej, to wykonuje standardowy RAG i generuje odpowiedź. Zapewnia przechowywanie pytania z odpowiedzią na serwerze pamięci podręcznej, który jest wykorzystywany do kolejnych połączeń. Poniższy fragment kodu pokazuje kod serwera MCP do wyszukiwania pamięci podręcznej. Użyłem wyszukiwania podobieństwa opartego na KNN i zwróciłem tylko 1 najbliższe dopasowanie. Używam odległości jako punktacji i (1-punktacji) jako podobieństwa. Kolejnym ważnym punktem jest użycie dialektu 2, który jest koniecznością dla zapytań wektorowych w Redis, w przeciwnym razie zapytanie zawiedzie. @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)}" }) Najpierw obliczyłem osadzenia pytania, które są przechowywane wraz z surowym pytaniem i odpowiedziami jako wartość dla klucza, który jest standardowym hashem md5 pytania. @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) }) Poniższy zwiastun pokazuje pamięć podręczną pytań i odpowiedzi w Redis z osadami. Następny fragment pokazuje kod klienta MCP w celu wywołania cache_lookup def cache_lookup(self, question: str) -> dict: return _run_async(self._req_with_connection("cache_lookup", question)) Następny fragment pokazuje kod klienta MCP w celu wywołania cache_store def cache_store(self, question: str, answer: str) -> dict: return _run_async(self._req_with_connection("cache_store", question, answer)) Poniższa tabela pokazuje przepływ wykonania. Ślad jest podkreślony podczas połączenia cache_lookup i można zobaczyć wyjście jako cache_hit jako fałszywe z przyczyną no_similar_question. Tak więc w tym przepływie wykonuje się standardowy RAG. Możesz zobaczyć węzeł graph_rag_query w śladzie, a następnie połączenie LLM. Teraz jest to moment prawdy, kiedy podobne pytanie jest ponownie zadawane. Możemy zobaczyć w następującym snapshot, cache_hit jest prawdziwy. Istnieje niewielka zmiana w sformułowaniu pytania, ale jest podobna do poprzedniej, więc wynik podobieństwa wynosi 0,9866 jak pokazano poniżej. Dlatego odpowiedź jest pobierana bezpośrednio z pamięci podręcznej i nie zobaczysz wykonywania przepływu RAG. Odpowiedź jest bezpośrednio zwracana z pamięci podręcznej semantycznej. Wynik Dodawanie pamięci podręcznej semantycznej do systemu GraphRAG lub VectorRAG zapewniło wymierne korzyści wynikające z wydajności i kosztów. Wcześniej system zajmował od 5 do 6 sekund na żądanie, które obejmowało wyszukiwanie wektorowe, generowanie i wykonywanie zapytań dotyczących cyfry graficznej wiedzy oraz ostateczne generowanie odpowiedzi przez LLM. Kiedy doszło do uderzenia pamięci podręcznej, odpowiedzi pojawiły się na ekranie użytkownika w czasie od 900 ms do 1,2 sekundy. Semantyczna strategia cache Gdzie wygrywa cache semantyczne Gdy system obsługuje duży, przewidywalny ruch, warstwa pamięci podręcznej dodaje korzyści wynikających z wydajności. Zwycięży, gdy ta sama wiedza jest poproszona przez wielu użytkowników, jak w przypadku korzystania z „Supportu Klienta i biur pomocniczych”, gdzie pytania są takie jak „Jak zresetować hasło?”, „Jaka jest Twoja polityka zwrotu pieniędzy?” W przypadku korzystania z dokumentacji produktów, gdzie użytkownicy pytają o te same podręczniki produktów. Dzieje się tak nawet wtedy, gdy deweloperzy pytają o tę samą dokumentację techniczną i dokumenty API. W przypadku korzystania z wewnętrznego HR i Onboarding, gdzie pytania takie jak „Jak zarejestrować się w ubezpieczeniu zdrowotnym?” i „Jaki jest harmonogram wakacji?” pojawiają Kiedy unikać semantycznego cache Jeśli dwaj użytkownicy zadają to samo pytanie, ale wymagają różnych odpowiedzi w oparciu o ich historię medyczną lub profil lub saldo konta, pamięć podręczna semantyczna może dostarczyć nieprawidłowe odpowiedzi. To nawet nie uda się, gdy twoje dokumenty, baza wiedzy i dane są niestabilne lub jest to w czasie rzeczywistym, jak gdy potrzebujesz odpowiedzi na temat cen akcji lub zapasów na żywo, pamięć podręczna jest twoim wrogiem. Strategia semantycznej inwalidacji pamięci podręcznej Cache musi zostać odświeżone, a pamięć podręczna semantyczna potrzebuje dodatkowej strategii unieważnienia. Każdy wpis pamięci podręcznej musi być oznaczony etykietą created_at timestamp, aby zarządzać wartościami czasu do życia (TTL). W pamięci podręcznej należy również oznaczyć dokument_wersja i model osadzenia używany podczas generacji. Jest to kluczowe, ponieważ jeśli uaktualnisz model osadzenia, przestrzeń wektorowa zmienia się. To sprawia, że stare wpisy pamięci podręcznej są nieaktualne. Musimy śledzić te zmienne, abyśmy mogli wywołać unieważnienie pamięci podręcznej za każdym razem, gdy źródło dokumentu zostanie zaktualizowane lub model osadzenia zostanie zmieniony lub zaktualizowany. Autoryzacja i uwzględnienie bezpieczeństwa W każdym systemie pamięci podręcznej musisz upewnić się, że udziela uprawnień przed dostarczeniem danych użytkownikowi. musi również upewnić się, że dane w pamięci podręcznej są zabezpieczone w czasie odpoczynku. W systemie wielomiesięcznym klucze izolacji najemcy muszą być wdrażane w pamięci podręcznej. Podobnie w systemie hiper-spersonalizowanego użytkownika, partycjonowanie przestrzeni nazwowej na poziomie użytkownika musi być wykonywane w pamięci podręcznej. Najważniejszym punktem dotyczącym autoryzacji jest tworzenie kluczy pamięci podręcznej świadomych o uprawnieniach, gdzie hash klucza obejmuje określone role użytkownika lub poziomy dostępu. Zapewnia to, że użytkownik o mniejszych uprawnieniach nie otrzymuje odpowiedzi w pamięci podręcznej od bardziej uprzywilejowanego użytkownika. Uderzenie pamięci podręcznej nie musi być mechanizmem pobierania danych nieautoryzowanym. Jeśli użytkownik nie ma uprawnień do pobierania określonego dokumentu lub wiersza bazy danych za pośrednictwem rurociągu RAG, nie musi być w stanie wyciągnąć generowanej odpowiedzi z pamięci podręcznej. Wreszcie, aby spełnić różne wymagania zgodności, takie jak HIPPA lub SOC2, Twoje odpowiedzi muszą być zaszyfrowane, zanim zostaną przechowywane w pamięci podręcznej. konkluzji Projekt architektury, fragmenty kodu i różne snapshots dowodzą, że możliwe jest semantyczne przechowywanie zapasowych pytań i wykonanie wyszukiwania podobieństwa opartego na wektorowych wkładach, aby zwrócić wcześniej wygenerowane odpowiedzi, aby uniknąć wezwań LLM opartych na RAG do podobnych pytań. Powyższy przykład jest dość prosty, jednak możemy rozszerzyć ten wybór architektury na wiele punktów dotykowych LLM, które występują w systemie Agentic AI, aby podejmować decyzje nie tylko dla pytań i odpowiedzi użytkowników końcowych. Caching semantyczny jest prostym sposobem na obniżenie kosztów tokenów przy zachowaniu jakości odpowiedzi. Jeśli twój system otrzymuje podobne zapytania do odpowiedzi, dodanie warstwy pamięci podręcznej przed krokami odzyskiwania i generowania jest zaletą.