Оптимизиране на разходите за използване на LLM с Семантичен кеш

Създадох естествена система за отчитане на ботове за чат на език, задвижвана от Retrieval Augmented Generation (RAG). Тя осигури страхотно преживяване на потребителя, те бяха в състояние да задават заявки към данните и да получават отчети, нарязани и нарязани по желаните от тях размери. След това дойде законопроектът за API на LLM. Тогава осъзнах, че в моето търсене да изградя този интелект, създадох финансова черна дупка. След това дойде законопроектът за API на LLM. That's when I realized that in my quest to build this intelligence, I had created a financial black hole. Във всяка среда тези агентни AI системи правят стотици и хиляди LLM повиквания, започвайки с разработване, eval, тестване на приемането на потребителите и след това в производствената среда. За да генерираме наземни отговори, ние прилагаме Retrieval Augmented Generation (RAG). Това означава, че задаваме заявки на векторни магазини за подобно съдържание и предаваме получените данни с потребителски въпроси, известия, примери, инструкции за предпазители, структурирана схема за отговор и т.н. на LLM. Това означава, че за един прост въпрос добавяме стотици допълнителни токени в името на контекста, предпазители и няколко предупреждения и т.н. Големите езикови модели (LLM) анализират тези като токени и вършат работата си, за да генерират отговора и след това получаваме отговора на нашия въпрос. Този отговор може да бъде отговор на нашия въпрос или може да бъде структуриран отговор на един от стъпките в В моята система системата извлича данни от Vector DB и Knowledge Graph, за да се основава на отговора. Наблюдавах около ~2000 входни токена в контекстния прозорец. LLM след това генерира обмислен, 500 токенен отговор. На пръв поглед, това е само няколко цента. Но с 200 000 заявки на ден, тези "цента" се превръщат в чудовище. Просто добавете това използване с множество потребители по време на фазите на развитие и оценка също. В момента цената на използване на един милион токена, тъй като входът и изходът изглеждат по-евтини, тъй като ние сме в ранните етапи на приемането на LLM API и доставчиците на услуги умишлено са дали много отстъпки. В бъдеще тези цени ще бъдат по-високи, а след Можете също така да се позовете на няколко статии, цитирайки предизвикателствата около разходите за LLM. Ценовата война на LLM уврежда образованието - и стартиращите предприятия Как мащабирането на корпоративния ИИ с грешния LLM може да ви струва Създадох системи, базирани на RAG, използвайки LangGraph, Neo4j, ChromaDB и Redis. Донасям този архитектурен модел, наречен Семантичен кеш и подробности за изпълнението, за да намалим изгарянето на токени в производството. Този модел може да намали разходите за използване на LLM, като кешира и отговаря на подобни въпроси, вместо да се обръща към LLM всеки път. Какво е скриване Кешът е съществувал от векове в нашата архитектура на ИТ системата. Той започна с In-Memory, след това се разпространява. Първоначално имаше малко ограничени оферти за наземно или VM базирано разполагане. С появата на облака, много облачни оферти се развиха. В днешно време имаме доста зрели системи за кеширане. Въпреки това, използването на системата за кеширане се основава на ключови стойности. Ключовете се хашират и съхраняват в структура от тип хаш таблица. Кешът винаги е бил точно търсене на ключове. Ако вашият ключ е наличен, системата за кеширане ще върне стойностите за вашия ключ, а ако ключът не е, това означава, че не е бил съхранен или е бил изгонен Какво е семантичен кеш Векторите с многоизмерни измерения и намирането на векторите, използващи косиново сходство или подобни механизми, също съществуват от дълго време. Въпреки това, с LLM и RAG, векторните вграждания и търсенето на сходство са станали доста популярни. Vector RAG е един от основните решения за решения, базирани на RAG. Това помага при намирането на подобно съдържание. Това не е точен ключ, а вместо това помага при намирането на вграждащите се вектори, които са семантично сходни. Тази способност първоначално е разработена във векторни бази данни, но сега тази способност е налична и в кеширащи системи като redis и сега доставчиците на облачни услуги също са въвели тази способност в своите кеширащи предложения. Можем да дефинираме Семантичен кеш като кеш, който извлича кеш записи въз основа на значението на съдържание или документ, вместо хаша на ключа. Можем да дефинираме Семантичен кеш като кеш, който извлича кеш записи въз основа на значението на съдържание или документ, вместо хаша на ключа. Колко семантичен кеш е различен Нека направим бърза диференциация между кеша, семантичен кеш и RAG. Следните таблици могат да помогнат за изясняване на разликите между традиционния кеш и семантичния кеш. 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 Пример Ключ, стойност (Student_Id, Student_Obj) 2025081520, Студентски обект1 2025091640, Студентски обект2 Ако ключът, използван при търсене, е различен, След това Wend's връща всеки резултат изявленията Къде е завършил Алекс? От кой университет е завършил Алекс? И двамата ще получат същото въвеждане от кеша. Следващата таблица може да помогне за изясняване на разликите между RAG и Семантичен кеш. 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 Използвайте Създаване на нов отговор Връщане на по-рано генерирани и кеширани отговори данните Външни източници на данни, като например векторни бази данни Предишни въпроси и отговори Цената Среден до висок ниско Най-доброто за Генериране на основани реакции Повтарящ се, но подобен въпрос Можем да видим, че разликата между RAG и семантичния кеш е проста, но финансовото въздействие е голямо. RAG извлича сурова информация и генерира отговори. Семантична кеш базирана RAG архитектура Проектирах следната архитектура за семантичен кеш в допълнение към стандартната RAG архитектура. Компоненти на архитектурата Потребител: От всеки клиент като браузър или мобилно приложение се извиква Q&A api, след като потребителят въведе въпрос на естествен език. 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 и естествените езикови отговори. Observability (LangSmith): Осигурява проследяване, мониторинг и дебютиране на стъпките за изпълнение на агента. Графикът на знанието (Neo4j): Той съхранява структурирани взаимоотношения (напр. (Личност)-[:WORKS_AT]->(Организация)) и се запитва чрез Cypher, генериран от LLM. Vector Store (ChromaDB): Съхранява векторните вграждания, генерирани от документа за знания. За да се реализира семантичното кеширане, основно новият семантичен кеш MCP компонент е добавен в стандартната RAG базирана агентна система. 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. If the cache hit happens, then it returns the answer without making any RAG call, which means neither Vector db nor knowledge graph call nor LLM call. The most important LLM call is avoided. Ако липсата на кеш се случи, той изпълнява стандартния RAG и генерира отговора.Той гарантира, че въпросът с отговора се съхранява в кеш сървъра, който се използва за последващи повиквания. Следващият кодов откъс показва кода на MCP сървъра за търсене в кеш. Използвах търсене за сходство на базата на KNN и върнах само 1 най-близко съвпадение. Използвам разстояние като резултат и (1-точка) като сходство. Друг важен момент е използването на диалект 2, който е задължителен за векторни заявки в 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 хаш на въпроса. @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 с вграждания. Following snippet shows MCP client code to invoke 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 като фалшив с причина no_similar_question. По този начин в този поток се изпълнява стандартната RAG. Можете да видите graph_rag_query възел в следа, последван от повикване LLM. Сега, това е моментът на истината, когато отново се задава подобен въпрос. Можем да видим в следващата снимка, cache_hit е вярно. Има малка промяна в формулировката на въпроса, но тя е подобна на предишната, така че резултатът за сходство е 0.9866 както е показано по-долу. Следователно отговорът се извлича директно от кеша и няма да видите изпълнението на потока RAG. Отговорът се връща директно от семантичния кеш. Резултат Добавянето на семантичен кеш към система GraphRAG или VectorRAG осигури измерими ползи за производителността и разходите. По-рано системата отнемаше от 5 до 6 секунди на заявка, което включва търсене на вектор, генериране и изпълнение на заявка за цифра на знанието и окончателно генериране на отговор от LLM. Когато се случи кешът, отговорите бяха на екрана на потребителя в 900 ms до 1,2 секунди. Семантична стратегия за кеш Когато семантичният кеш печели Когато една система се справя с голям обем, предсказуем трафик, кеш слой добавя предимство за производителността. Тя печели, когато същите знания се изискват от много потребители, като в случая на използване на "Клиентска поддръжка и бюра за помощ", където въпросите са като "Как да пренастроя паролата си?", "Каква е вашата политика за възстановяване?". В случаите на използване на документация за продукти, където потребителите задават въпроси за същите ръководства за продукти. Това се случва дори когато разработчиците задават въпроси за същата техническа документация и API документи. В случаите на използване на вътрешни HR & Onboarding, където въпроси като "Как да се регистрирам за здравно осигуряване?" и "Какъв е графикът за почивка?" се поя Кога да избягваме семантичното кеширане Ако двама потребители задават един и същ въпрос, но изискват различни отговори въз основа на тяхната медицинска история или профил или баланс на сметката, семантичният кеш може да даде неправилни отговори. Той дори се проваля, когато вашите документи, базата знания и данни са нестабилни или това е в реално време, като когато имате нужда от отговори за цените на акциите или живия инвентар, кешът е вашият враг. Семантична стратегия за валидиране на кеша Кешът трябва да бъде обновен и семантичният кеш се нуждае от допълнителна стратегия за недействителност. Всеки запис на кеша трябва да бъде маркиран с created_at timestamp, за да управлява стойностите си до live(TTL). В семантичния кеш освен това трябва да се маркират document_version и embedding_model, използвани по време на генерирането. Това е от решаващо значение, защото ако надстроите вградения модел, векторното пространство се променя. Това прави старите вноски в кеша остарели. Трябва да проследяваме тези променливи, така че да можем да задействаме недействителността на кеша всеки път, когато източникът на документ се актуализира или вграждащият модел се променя или актуализира. Това гарантира, Разрешаване и съображения за сигурност Във всяка система за кеширане трябва да се уверите, че тя дава разрешение, преди да предостави данните на потребителя.Тя също така трябва да гарантира, че данните в кеш са защитени и в покой.Имплементацията на семантичния кеш трябва да се придържа към тези принципи, не трябва да се разглежда само като добавяне на слой за производителност или разходи. Подобно на хиперперперсонализираната система на потребителя, разделянето на именното пространство на ниво потребител трябва да се извърши в кеша. Най-важният аспект на разрешаването е създаването на ключове за кеш с разрешение, където хешът на ключа включва конкретните роли или нива на достъп на потребителя. Това гарантира, че потребител с по-малко привилегии не получава кеширан отговор от по-привилегирован потребител. И накрая, за да отговарят на различни изисквания за съответствие като HIPPA или SOC2, отговорите ви трябва да бъдат криптирани, преди да бъдат кеширани. Заключението Архитектурният синоним, кодовите откъси и различните снимки доказват, че е възможно семантично да се кешират въпросите и да се извърши търсене на сходство въз основа на векторни вграждания, за да се върнат по-рано генерираните отговори, за да се избегнат RAG базирани LLM призиви за подобни въпроси. Примерът, показан по-горе, е доста прост, но можем да разширим този избор на архитектура за множество точки на допир на LLM, които се случват в системата на Agentic AI, за да вземем решения не само за въпросите и отговорите на крайните потребители. Семантичното кеширане е прост начин за намаляване на разходите за токени, като същевременно се поддържа качеството на отговора. Ако вашата система получава подобни заявки за отговор, добавянето на кеш слой преди стъпките за извличане и генериране е предимство.