Es izveidoju dabisko valodas tērzēšanas bot ziņošanas sistēmu, ko darbina Retrieval Augmented Generation (RAG). Tas nodrošināja lielisku lietotāja pieredzi, viņi varēja vaicāt datus un iegūt ziņojumus, kas tika sagriezti un sagriezti pēc izmēriem, kurus viņi vēlējās. 
 
 
 Tad pienāca LLM API likums. Tas bija tad, kad es sapratu, ka manā meklējumos, lai veidotu šo izlūkošanu, es biju izveidojis finanšu melno caurumu. Tad pienāca LLM API likums. Tas bija tad, kad es sapratu, ka manā meklējumos, lai veidotu šo izlūkošanu, es biju izveidojis finanšu melno caurumu. Šodienas IT pasaulē katra komanda vēlas izveidot Agentic AI sistēmu. Katrā vidē šīs Agentic AI sistēmas veic simtiem un tūkstošiem LLM zvanu, sākot ar izstrādi, eval, lietotāju pieņemšanas testu un pēc tam ražošanas vidē. Lai ģenerētu pamatotas atbildes, mēs īstenojam Retrieval Augmented Generation (RAG). Tas nozīmē, ka mēs vaicājam vectoru veikalos par līdzīgu saturu un nododam iegūtos datus ar lietotāja jautājumiem, ielūgumiem, piemēriem, glabāšanas instrukcijām, strukturētajām atbildes shēmām utt. LLM. Tas nozīmē vienkāršu jautājumu, mēs pievienojam simtiem papildu žetonu konteksta nosaukumā, glabāšanas laukumos un dažiem šāvieniem utt. Lieli valodas modeļi (LLM) tos analizē kā žetoni un veic savu darbu, lai ģenerētu atbildi, un tad mēs saņemam atbildi uz mūsu jautājumu. Šī atbilde var būt atbilde uz mūsu jautājumu vai tā var būt strukturēta atbilde uz vienu no Manā sistēmā sistēma izvelk datus no Vector DB un Knowledge Graph, lai pamatotu atbildi. Es novēroju aptuveni ~2000 ievades žetoni konteksta logā. LLM pēc tam rada pārdomātu, 500 žetonu atbildi. No pirmā acu uzmetiena tas ir tikai daži centi. Bet ar 200 000 pieprasījumiem dienā šie "centi" pārvēršas par monstru. Vienkārši pievienojiet to izmantošanu ar vairākiem lietotājiem attīstības un novērtēšanas fāzēs. Pašlaik izmaksas par miljonu žetonu izmantošanu, jo ievades un izejas izskatās lētākas, jo mēs esam LLM api pieņemšanas agrīnās stadijās un pakalpojumu sniedzēji apzināti ir devuši daudz atlaides. Nākotnē šīs cenas būs augstākas, un tad kopējās izmaks Jūs varat arī atsaukties uz dažiem rakstiem, kas min izaicinājumus, kas saistīti ar LLM izmaksām. LLM cenu karš kaitē izglītībai - un jaunuzņēmumiem Kā uzņēmuma AI skalēšana ar nepareizu LLM varētu jums maksāt Es izveidoju RAG balstītas sistēmas, izmantojot LangGraph, Neo4j, ChromaDB un Redis. Es nesu šo arhitektūras modeli, ko sauc par Semantic Cache un īstenošanas detaļas, lai samazinātu žetonu dedzināšanu ražošanā. Šis modelis var samazināt jūsu LLM lietošanas izmaksas, izmantojot kešatmiņu un atbildot uz līdzīgiem jautājumiem, nevis katru reizi atsaucot LLM. Ļaujiet man jums iepazīstināt ar šo modeli, kuru jūs varat piemērot vairākos lietošanas gadījumos un vairākos pieskārienos jūsu Agentic AI darba plūsmā. Kas ir slēpšana Cache ir bijis mūsu IT sistēmas arhitektūrā jau ilgu laiku. Tas sākās ar In-Memory, tad tas kļuva izplatīts. Sākotnēji bija maz ierobežotu piedāvājumu on-prem vai VM balstītai izvietošanai. Ar mākoņa parādīšanos daudzi mākoņa piedāvājumi attīstījās. Mūsdienās mums ir diezgan nobriedušas kešatmiņas sistēmas. Tomēr kešatmiņas sistēmas izmantošana ir balstīta uz atslēgvārdu pāriem. Atslēgas tiek hashētas un glabātas Hash tabulas veida datu struktūrā. Kešatmiņa vienmēr bija precīza atslēgvārdu balstīta meklēšana. Ja jūsu atslēga ir klāt, kešatmiņas sistēma atgriezīs jūsu atslēgas vērtības, un, ja atslēga nav, tas nozīmē, Kas ir Semantic Cache Vectori ar vairākiem izmēriem un vectoru meklēšana, izmantojot kosīnu līdzību vai līdzīgus mehānismus, arī pastāvēja ilgu laiku. Tomēr ar LLM un RAG vectoru iebūvējumi un līdzības meklēšana ir kļuvuši diezgan populāri. Vektoru RAG ir viena no galvenajām risinājumu izvēlēm RAG balstītajām sistēmām. Tas palīdz atrast līdzīgu saturu. Tas nav precīzs atslēgas meklējums, bet tas palīdz atrast iebūvējamos vectorus, kas ir semantiski līdzīgi. Šī funkcija sākotnēji tika izstrādāta Vector datu bāzēs, bet tagad šī funkcija ir pieejama arī kešatmiņas sistēmās, piemēram, redis, un tagad mākoņpakalpojumu sniedzēji ir ieviesuši šo funkciju arī savā kešatmiņas piedāvājumā. 
 
 Mēs varam definēt semantisko kešatmiņu kā kešatmiņu, kas iegūst kešatmiņas ierakstus, pamatojoties uz satura vai dokumenta nozīmi, nevis atslēgas hash. Mēs varam definēt semantisko kešatmiņu kā kešatmiņu, kas iegūst kešatmiņas ierakstus, pamatojoties uz satura vai dokumenta nozīmi, nevis atslēgas hash. Kā semantiskā kešatmiņa atšķiras Ļaujiet mums ātri atšķirt starp Cache, Semantic Cache un RAG. Sekojošās tabulas var palīdzēt noskaidrot atšķirības starp tradicionālo kešatmiņu un semantisko kešatmiņu. 
 
 
 
 
 
 
 
 
 
 
 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. Pieeja Atslēgvārdi balstās Pamatojoties uz nozīmi Atslēgas meklēšana Precīza spēle Līdzīgas spēles Vislabāk par Apiņi LLMs Piemērs Atslēga, vērtība (Student_Id, Student_Obj) 2025081520, Studentu objekts1 2025091640, Studentu objekts2 ja atslēga, kas tiek izmantota, veicot meklēšanu, ir atšķirīga, tad it won's atgriež jebkādu rezultātu paziņojumi No kurienes Aleksejs mācījās? No kuras universitātes Alekss ir absolvējis? Abi saņems to pašu ievadi no kešatmiņas. Turpmākā tabula var palīdzēt noskaidrot atšķirības starp RAG un 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 izmantot Lai radītu jaunu atbildi Atgriezt iepriekš ģenerētas un kešatmiņas atbildes Dati Ārējie datu avoti, piemēram, Vector datu bāzes Iepriekš radītie jautājumi un atbildes izmaksas Vidēji augsts zemā Vislabāk par Pamatotas atbildes paaudze Atkārtoti, bet līdzīgi jautājumi Mēs varam redzēt, ka atšķirība starp RAG un Semantisko kešatmiņu ir vienkārša, bet finansiālā ietekme ir liela. RAG iegūst neapstrādātu informāciju un rada atbildes. Semantiskā kešatmiņa balstīta RAG arhitektūra Es esmu izstrādājis šādu semantiskās kešatmiņas arhitektūru, kas ir papildus standarta RAG arhitektūrai. Arhitektūras sastāvdaļas 
 
 
 
 
 
 
 
 
 Lietotājs: No jebkura klienta, piemēram, pārlūkprogrammas vai mobilās lietotnes, tiek izsaukts Q&A api, tiklīdz lietotājs ievada jebkuru jautājumu dabiskā valodā. API Gateway: API pieprasījums ir autentificēts un autorizēts 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: argumentācijas dzinējs aģentam un generators Cypher vaicājumiem par GraphRAG un dabiskās valodas atbildēm. novērojamība (LangSmith): nodrošina aģenta izpildes soļu izsekošanu, uzraudzību un labošanu. Zināšanu grafiks (Neo4j): Tas saglabā strukturētas attiecības (piemēram, (persona)-[:WORKS_AT]->(Organizācija)) un tiek vaicāts, izmantojot LLM ģenerēto ciparu. Vektoru krājums (ChromaDB): Tas saglabā vektoru ievietojumus, kas ģenerēti no zināšanu dokumenta. Lai īstenotu semantisko kešatmiņu, galvenokārt jaunā semantiskā kešatmiņas MCP sastāvdaļa ir pievienota standarta RAG balstītajai aģentu sistēmai. 
 
 
 
 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. Ja cache hit notiek, tad tas atgriež atbildi, neveicot RAG zvanu, kas nozīmē ne Vector db, ne zināšanu grafika zvanu, ne LLM zvanu. Ja tas notiek, tas izpilda standarta RAG un ģenerē atbildi. tas nodrošina, ka jautājums ar atbildi tiek saglabāts kešatmiņas serverī, kas tiek izmantots turpmākiem zvanījumiem. Nākamais koda fragments parāda MCP servera kodu kešatmiņas meklēšanai. Esmu izmantojis KNN balstītu līdzības meklēšanu un atdevis tikai 1 tuvāko atbildi. Es izmantoju attālumu kā punktu un (1-score) kā līdzību. Vēl viens svarīgs punkts ir dialekta 2 izmantošana, kas ir obligāta vectoru vaicājumiem Redis, pretējā gadījumā vaicājums neizdosies. @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)}"
 })
 Es vispirms aprēķināju jautājuma iebūvējumus, kas tiek glabāti kopā ar neapstrādāto jautājumu un atbildi kā vērtība atslēgai, kas ir jautājuma standarta 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)
 })
 Nākamais snapshot parāda jautājumu un atbilžu kešatmiņu Redis ar iebūvēm. Nākamais snippet parāda MCP klientu kodu, lai izsauktu cache_lookup def cache_lookup(self, question: str) -> dict:
return _run_async(self._req_with_connection("cache_lookup", question))
 Nākamais snippet parāda MCP klientu kodu, lai izsauktu cache_store def cache_store(self, question: str, answer: str) -> dict:
return _run_async(self._req_with_connection("cache_store", question, answer))
 Nākamais rādītājs parāda izpildes plūsmu. Cache_lookup izsaukumā ir uzsvērts trace, un jūs varat redzēt iznākumu kā cache_hit kā nepatiesu ar iemeslu no_similar_question. Tādējādi šajā plūsmā tiek izpildīts standarta RAG. Tagad, tas ir patiesības brīdis, kad līdzīgs jautājums tiek uzdots vēlreiz. Mēs varam redzēt nākamajā snapshot, cache_hit ir taisnība. Ir nelielas izmaiņas jautājuma formulējumā, bet tas ir līdzīgs iepriekšējam, tāpēc līdzības rezultāts ir 0,9866 kā parādīts zemāk. Tādējādi atbilde tiek iegūta tieši no kešatmiņas un jūs neredzēsiet RAG plūsmas izpildi. Atbilde tiek atgriezta tieši no semantiskās kešatmiņas. Rezultāts Semantiskās kešatmiņas pievienošana GraphRAG vai VectorRAG sistēmai nodrošināja izmērāmu veiktspēju un izmaksu priekšrocības. Iepriekš sistēma ilga 5 līdz 6 sekundes uz pieprasījumu, kas ietvēra Vector meklēšanu, zināšanu grafiku ciparu vaicājumu ģenerēšanu un izpildi, kā arī galīgās atbildes ģenerēšanu ar LLM. Kad notika kešatmiņas hit, atbildes bija lietotāja ekrānā 900 ms līdz 1,2 sekundes. Vidēji tas nodrošināja 24% samazinājumu ikdienas LLM zvanos, kas samazināja LLM API rēķinus. Semantiskā kešatmiņas stratēģija Kur semantiskā kešatmiņa uzvar Kad sistēma apstrādā augstu apjomu, paredzamu datplūsmu, kešatmiņas slānis palielina veiktspējas priekšrocības. Tas uzvar, kad daudzi lietotāji lūdz tādas pašas zināšanas, piemēram, lietojuma lietojumprogrammā "Klientu atbalsts un palīglīdzekļi", kur ir jautājumi, piemēram, "Kā es varu atkārtoti iestatīt savu paroli?", "Kāda ir jūsu atmaksas politika?". Produkta dokumentācijas lietojumprogrammā lietojumprogrammā lietotāji vaicā tās pašas produktu rokasgrāmatas. Tas notiek pat tad, kad izstrādātāji vaicā to pašu tehnisko dokumentāciju un API dokumentus. Iekšējā HR un Onboarding lietojumprogrammā jautājumi, piemēram, "Kā es varu reģistrēties veselības apdrošināšanai?" un Kad izvairīties no semantiskās kešatmiņas Tas neizdodas īpaši tajās sistēmās, kas nodrošina hiperpersonalizāciju. Ja divi lietotāji uzdod vienu un to pašu jautājumu, bet prasa atšķirīgas atbildes, pamatojoties uz viņu medicīnisko vēsturi vai profilu vai konta bilanci, semantiskais kešatmiņa var sniegt nepareizas atbildes. Tas pat neizdodas, kad jūsu dokumenti, zināšanu bāze un dati ir volatili vai tas ir reālā laikā, piemēram, kad jums ir nepieciešamas atbildes par akciju cenām vai dzīvo inventāru, kešatmiņa ir jūsu ienaidnieks. Semantiskās kešatmiņas invalidizācijas stratēģija Kešatmiņa ir jāatjauno un semantiskajai kešatmiņai ir nepieciešama papildu spēkā neesamības stratēģija. Katram kešatmiņas ierakstam ir jābūt marķētam ar created_at timestamp, lai pārvaldītu tās laiku dzīvot(TTL) vērtības. Semantiskajā kešatmiņā papildus jāmarķē arī document_version un embedding_model, ko izmanto ģenerācijas laikā. Tas ir būtiski, jo, ja jūs atjaunojat iebūvējamo modeli, jūsu vektora telpa mainās. Tas padara vecos kešatmiņas ierakstus novecojušus. Mums ir nepieciešams izsekot šiem mainīgajiem, lai mēs varētu izraisīt kešatmiņas spēkā neesamību, kad dokuments tiek atjaunināts vai iebūvējamais modelis tiek mainīts vai atja Atļauja un drošības apsvērumi Jebkurā kešatmiņas sistēmā, jums ir jāpārliecinās, ka tas atļauj, pirms tas sniedz datus lietotājam. tas arī jānodrošina, ka dati kešatmiņa tiek nodrošināta arī atpūtai. semantiskās kešatmiņas ieviešana ir jāievēro šie principi, tas nedrīkst tikt uztverts tikai kā pievienojot slāni sniegumu vai izmaksu priekšrocības. Daudzīpašnieka sistēmā īrnieka izolācijas atslēgas ir jāīsteno kešatmiņā.Tāpat kā hiperpersonalizētā lietotāja sistēmā, lietotāju līmeņa nosaukuma telpas sadalījums ir jāveic kešatmiņā.Tas garantē, ka vektoru līdzības meklēšana ir ierobežota ar konkrēto tvertni, kas pieder šim konkrētajam attiecīgās organizācijas lietotājam. Vissvarīgākais punkts attiecībā uz autorizāciju ir atļauju apzinātu kešatmiņas atslēgu izveidošana, kur atslēgas hash ietver lietotāja konkrētās lomas vai piekļuves līmeņus.Tas nodrošina, ka lietotājs ar mazāk privilēģijām nesaņem kasētu atbildi no vairāk privilēģiju lietotāja.Kāzu hit nedrīkst būt neautorizēts datu uztveršanas mehānisms.Ja lietotājam nav atļaujas iegūt konkrētu dokumentu vai datu bāzes rindu, izmantojot RAG cauruļvadu, tad viņiem nedrīkst būt iespēja izvilkt ģenerēto atbildi no kešatmiņas. Visbeidzot, lai izpildītu dažādas atbilstības prasības, piemēram, HIPPA vai SOC2, jūsu atbildēm jābūt šifrētām, pirms tās tiek cached. Secinājums Arhitektūras plāns, koda izvilkumi un dažādi snapshots pierāda, ka ir iespējams semantiski saglabāt jautājumus un veikt vectoru ievietošanas līdzības meklēšanu, lai atgrieztos iepriekš ģenerētās atbildes, lai izvairītos no RAG balstītiem LLM aicinājumiem uz līdzīgiem jautājumiem. Iepriekš minētais piemērs ir diezgan vienkāršs, tomēr mēs varam paplašināt šo arhitektūras izvēli vairākiem LLM pieskārienu punktiem, kas notiek Agentic AI sistēmā, lai pieņemtu lēmumus ne tikai par gala lietotāja jautājumiem un atbildēm. Semantiskā kešatmiņa ir vienkāršs veids, kā samazināt žetonu izmaksas, vienlaikus saglabājot atbildes kvalitāti.Ja jūsu sistēma saņem līdzīgus vaicājumus, lai atbildētu, pievienojot kešatmiņas slāni pirms atgūšanas un ģenerēšanas soļiem ir priekšrocība.Visvienkāršākā daļa ir tā, ka jums nav jāpārveido jūsu RAG arhitektūra, jūs vienkārši optimizē plūsmu, apstrādājot atkārtotu nodomu agrāk ķēdē.

This story contains new, firsthand information uncovered by the writer.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

Šis audio ir izveidots stāsta oriģinālvalodā!

Optimizējiet LLM lietošanas izmaksas ar Semantic Cache

About Author

KOMENTĀRI

PAKARINĀT TAGUS

ŠIS RAKSTS TIKS PĀRSTRĀDĀTS

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps