Rakensin luonnollisen kielen chat-bot-raportointijärjestelmän, jota ylläpitää Retrieval Augmented Generation (RAG). Se tarjosi käyttäjälle erinomaisen kokemuksen, he pystyivät kyselemään tietoja ja saamaan raportteja leikata ja leikata haluamiensa ulottuvuuksien mukaan. Se oli intuitiivinen ja tarjosi tehokkuutta. Se muutti tonnia tietoja nestemäiseksi kullaksi. 
 
 
 Sitten tuli LLM API laki. Silloin tajusin, että pyrkiessäni rakentamaan tätä älykkyyttä, olin luonut taloudellisen mustan aukon. Sitten tuli LLM API laki. Silloin tajusin, että pyrkiessäni rakentamaan tätä älykkyyttä, olin luonut taloudellisen mustan aukon. Jokaisessa ympäristössä nämä Agentic AI -järjestelmät tekevät satoja ja tuhansia LLM-puheluita, alkaen kehittämisestä, evalista, käyttäjän hyväksymistestauksesta ja sitten tuotantoympäristössä. Jotta voimme tuottaa maadoitettuja vastauksia, toteutamme Retrieval Augmented Generation (RAG). Tämä tarkoittaa, että kysymme vektorikaupoista samanlaista sisältöä ja välitämme saatuja tietoja käyttäjän kysymyksillä, pyyntöillä, esimerkkeillä, vartijoiden ohjeilla, jäsennellyllä vastausjärjestelmällä jne. LLM: lle. Tämä tarkoittaa yksinkertaista kysymystä, lisäämme satoja ylimääräisiä tokeneja kontekstin nimessä, vartijoita ja muutamia laukauspyyntöjä jne. Suuret kielimallit (LLM) analysoivat näitä tokeneina ja tekevät työtään vastauksen tuottamiseksi ja sitten saamme vastauksen kysymykseemme. Tämä vastaus voi olla vastaus kysymykseemme tai se voi olla jäsennelty vastaus Järjestelmässäni järjestelmä vetää tietoja Vector DB: stä ja Knowledge Graphista saadakseen vastauksen. Olen havainnut kontekstiikkunassa noin 2000 syöttötunnusta. LLM tuottaa sitten harkitun, 500 tunnuksen vastauksen. Ensi silmäyksellä se on vain muutama sentti. Mutta 200 000 kyselyn päivässä nämä "sentit" muuttuvat hirviöksi. Lisää vain sitä käyttöä useiden käyttäjien kanssa kehitys- ja arviointivaiheissa. Tällä hetkellä kustannukset miljoonan tunnuksen käytöstä, koska syöttö ja tuotanto näyttävät halvemmilta, koska olemme LLM API: n hyväksymisen alkuvaiheissa ja palveluntarjoajat ovat tietoisesti antaneet paljon alennuksia. Tulevaisuudessa nämä hinnat nousevat, ja sitten kokonaiskustannukset kehityksestä tuotantoon Voit myös viitata muutamiin artikkeleihin, joissa mainitaan LLM: n kustannuksia koskevat haasteet. LLM-hintojen sota vahingoittaa koulutusta - ja startup-yrityksiä Miten yrityksen AI: n skaalaaminen väärällä LLM: llä voi maksaa sinulle Rakensin RAG-pohjaisia järjestelmiä LangGraphin, Neo4j: n, ChromaDB: n ja Redis: n avulla. Tuon tämän arkkitehtuurimallin nimeltä Semanttinen välimuisti ja toteutuksen yksityiskohdat vähentääkseni token-polttoa tuotannossa. Tämä malli voi vähentää LLM: n käyttökustannuksia välimuistiin tallentamalla ja vastaamalla samankaltaisiin kysymyksiin sen sijaan, että vetoan LLM: hen joka kerta. Mikä on piilopaikka Cache on ollut olemassa jo vuosia IT-järjestelmän arkkitehtuurissamme. Se alkoi In-Memory, sitten se jaettiin. Aluksi on ollut vähän rajoitettuja tarjouksia on-prem- tai VM-pohjaiseen käyttöönottoon. Pilven syntymisen myötä monet pilvipalvelut ovat kehittyneet. Nykyään meillä on melko kypsät välimuistijärjestelmät. Kuitenkin välimuistijärjestelmän käyttö perustuu arvopareihin. Avaimet on hashattu ja tallennettu hash-taulukon tyyppiseen tietorakenteeseen. Välimuisti oli aina tarkka avainpohjainen haku. Jos avain on läsnä, välimuistijärjestelmä palauttaa arvot avaimellesi, ja jos avain ei ole, se tarkoittaa, että sitä ei tallennettu tai se karkotettu. Mikä on semanttinen välimuisti Vektorit, joilla on useita ulottuvuuksia ja jotka löytävät vektorit käyttämällä cosine-yhteensopivuutta tai vastaavia mekanismeja, ovat myös olleet olemassa pitkään. Kuitenkin LLM: n ja RAG: n kanssa vektorin upottaminen ja samankaltaisuuden etsintä ovat tulleet melko suosittuja. Vector RAG on yksi ensisijaisista ratkaisuvaihtoehdoista RAG-pohjaisille järjestelmille. Tämä auttaa löytämään samanlaista sisältöä. Tämä ei ole tarkka avain, vaan se auttaa löytämään semanttisesti samankaltaiset upottamisvektorit. Tämä ominaisuus on alun perin kehitetty Vector-tietokannoissa, mutta nyt tämä ominaisuus on saatavilla myös välimuistijärjestelmissä, kuten redis, ja nyt pilvipalveluntarjoajat ovat myös ottaneet käyttöön tämän ominaisuuden välimuistiin. 
 
 Semanttinen välimuisti on välimuisti, joka kerää välimuistiinpanoja sisällön tai asiakirjan merkityksen perusteella avaimen hashin sijaan. Semanttinen välimuisti on välimuisti, joka kerää välimuistiinpanoja sisällön tai asiakirjan merkityksen perusteella avaimen hashin sijaan. Miten semanttinen välimuisti on erilainen Tehdään nopea erottelu välimuistin, semanttisen välimuistin ja RAG: n välillä. Seuraavat taulukot voivat auttaa selventämään perinteisen välimuistin ja semanttisen välimuistin välisiä eroja. 
 
 
 
 
 
 
 
 
 
 
 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. lähestymistapa Avaimen pohjalta Merkitys perustuu Avaimen etsiminen Täsmällinen ottelu Samankaltainen ottelu Parasta on Apiä LLMs Esimerkki Avain, arvo (Student_Id, Student_Obj) 2025081520, OpiskelijaObject1 2025091640, OpiskelijaObject2 Jos etsimisen aikana käytetty avain on erilainen, Sitten se ei palauta mitään tulosta Ilmoitukset Mistä Alex on valmistunut? Mistä yliopistosta Alex valmistui? Molemmat saavat saman sisääntulon välimuistista. Seuraava taulukko voi auttaa selventämään RAG: n ja semanttisen välimuistin välisiä eroja. 
 
 
 
 
 
 
 
 
 
 
 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 Käytä Uuden vastauksen luominen Palauttaa aiemmin luodut ja välimuistiin tallennetut vastaukset dataa Ulkoiset tietolähteet, kuten Vector-tietokannat Aiemmin syntyneet kysymykset ja vastaukset kustannukset Keskimääräinen korkealle alhainen Parasta on Reagoiva sukupolvi Toistuva, mutta samanlainen kysymys Voimme nähdä, että ero RAG: n ja semanttisen välimuistin välillä on yksinkertainen, mutta taloudellinen vaikutus on suuri. RAG hakee raakaa tietoa ja tuottaa vastauksia. Semanttinen välimuistipohjainen RAG-arkkitehtuuri Olen suunnitellut seuraavan arkkitehtuurin semanttiseen välimuistiin standardin RAG-arkkitehtuurin yläpuolella. Arkkitehtuurin osat 
 
 
 
 
 
 
 
 
 Käyttäjä: Mistä tahansa asiakkaasta, kuten selaimesta tai mobiilisovelluksesta, pyydetään Q&A api, kun käyttäjä kirjoittaa kysymyksen luonnollisella kielellä. API Gateway: API-pyyntö on todennettu ja valtuutettu Gatewayssä 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: Johdanto moottori agentti ja generaattori Cypher kyselyt GraphRAG ja luonnon kielen vastauksia. Observability (LangSmith): Tarjoaa seurannan, seurannan ja vianmäärityksen agentin toteutusvaiheille. Knowledge Graph(Neo4j): Se tallentaa jäsenneltyjä suhteita (esim. (Ihminen)-[:WORKS_AT]->(Organisaatio)) ja kysytään LLM: n tuottaman Cypherin kautta. Vector Store (ChromaDB): Se tallentaa tiedon asiakirjasta luodut vektorin upotukset. Semanttisen välimuistin toteuttamiseksi on lisätty pääasiassa uusi semanttinen välimuisti MCP-komponentti tavanomaiseen RAG-pohjaiseen Agent-järjestelmään. 
 
 
 
 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. Jos välimuisti osuu, niin se palauttaa vastauksen tekemättä mitään RAG-puhelua, mikä tarkoittaa, että ei Vector db eikä tiedon graafinen puhelu eikä LLM-puhelu. Jos välimuisti puuttuu, se suorittaa standardin RAG: n ja tuottaa vastauksen.Se varmistaa, että kysymys ja vastaus tallennetaan välimuistipalvelimeen, jota käytetään myöhempiin puheluihin. Seuraavassa koodin kappaleessa näkyy MCP-palvelimen koodi välimuistihakuun. Olen käyttänyt KNN-pohjaista samankaltaisuuden etsintää ja palauttanut vain 1 lähimmän vastauksen. Käytän etäisyyden pisteenä ja (1-pisteen) samankaltaisuutena. Yksi tärkeä asia on dialektin 2 käyttö, joka on välttämätön vektorin kyselyille Redisissä, muuten kysely epäonnistuu. @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)}"
 })
 Olen ensin laskenut kysymyksen upotukset, jotka tallennetaan yhdessä raaka-kysymyksen ja vastauksen kanssa arvona avaimelle, joka on kysymyksen standardin 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)
 })
 Seuraavassa kuvassa näkyy kysymysten ja vastausten välimuisti Redisissä upotuksilla. Seuraavassa kappaleessa näkyy MCP-asiakaskoodi, joka kutsuu välimuistiin cache_lookup def cache_lookup(self, question: str) -> dict:
return _run_async(self._req_with_connection("cache_lookup", question))
 Seuraavassa kappaleessa näkyy MCP-asiakkaan koodi, joka kutsuu cache_store def cache_store(self, question: str, answer: str) -> dict:
return _run_async(self._req_with_connection("cache_store", question, answer))
 Seuraavassa kuvassa näkyy suorituskyvyn kulku. Trace on korostettu cache_lookup -puhelussa, ja voit nähdä tuloksen cache_hit -tunnisteena vääränä syyllä no_similar_question. Näin ollen tässä virrassa standardin RAG suoritetaan. Näet graph_rag_query -solmun jäljessä, jota seuraa LLM-puhelu. Nyt on totuuden hetki, kun samanlainen kysymys kysytään uudelleen. Näemme seuraavassa pikakuvassa, että välimuisti on totta. Kysymyksen sanamuodossa on pieni muutos, mutta se on samanlainen kuin edellinen, joten samankaltaisuuspiste on 0,9866 kuten alla. Näin ollen vastaus otetaan suoraan välimuistiin ja et näe RAG-virtaustoimintaa. Vastaus palautetaan suoraan semanttisesta välimuistiin. tulos Semanttisen välimuistin lisääminen GraphRAG- tai VectorRAG-järjestelmään tarjosi mitattavissa olevaa suorituskykyä ja kustannustehokkuutta. Aiemmin järjestelmä kesti 5–6 sekuntia per pyyntö, johon kuuluivat Vector-haku, Knowledge Grapher -numerokyselyjen luominen ja suorittaminen sekä LLM: n lopullisen vastauksen tuottaminen. Kun välimuisti osui, vastaukset olivat käyttäjän näytöllä 900 ms–1,2 sekuntia. Semanttinen piilostrategia Missä semanttinen välimuisti voittaa Kun järjestelmä käsittelee suurta määrää, ennustettavaa liikennettä, välimuistin kerros lisää suorituskykyä. Se voittaa, kun useat käyttäjät pyytävät samaa tietoa, kuten "Asiakastuki & Helpdesks" -käyttötapauksessa, jossa kysymykset ovat kuten "Kuinka palautan salasanani?", "Mikä on palautuskäytäntösi?". Tuoteasiakirjojen käyttötapauksissa, joissa käyttäjät kyselevät samoja tuoteoppaita. Tämä tapahtuu jopa silloin, kun kehittäjät kyselevät samaa teknistä dokumentaatiota ja API-asiakirjoja. Sisäisissä HR & Onboarding -käyttötapauksissa, joissa kysymykset kuten "Miten rekisteröidyn sairausvakuutukseen?" ja "Mikä on loma-aikataulu?" ilmestyvät jokaiselle työntekijälle. Milloin välttää semanttinen välimuisti Se epäonnistuu erityisesti niissä järjestelmissä, jotka tarjoavat hyperpersonalisointia. Jos kaksi käyttäjää kysyy samaa kysymystä, mutta vaativat erilaisia vastauksia lääketieteellisen historian tai profiilin tai tilin tasapainon perusteella, semanttinen välimuisti voi antaa virheellisiä vastauksia. Se epäonnistuu jopa silloin, kun asiakirjat, tietopohja ja tiedot ovat epävakaita tai se on reaaliaikaista, kuten kun tarvitset vastauksia osakehintoista tai elävistä varastoista, välimuisti on vihollisesi. Semanttinen välimuistiinpanostrategia Välimuisti on päivitettävä ja semanttinen välimuisti tarvitsee ylimääräistä mitätöintistrategiaa. Jokaisen välimuistiinpanon on oltava merkitty created_at timestampilla, jotta se voi hallita sen live(TTL) -arvoja. Semanttisessa välimuistiinpanossa on myös merkittävä document_version ja embedding_model, joita käytetään sukupolven aikana. Tämä on tärkeää, koska jos päivität upottamismallia, vektorin tila muuttuu. Tämä tekee vanhoista välimuistiinpanoista vanhentuneita. Meidän on seurattava näitä muuttujia, jotta voimme laukaista välimuistiinpanon mitätöinnin aina, kun asiakirjan lähdettä päivitetään tai upottamismallia muutetaan tai päivitetään. Tämä varmistaa, että järjest Valtuutus ja turvallisuusnäkökohdat Kaikissa välimuistijärjestelmissä sinun on varmistettava, että se valtuuttaa ennen tietojen toimittamista käyttäjälle. Sen on myös varmistettava, että välimuistiin tallennetut tiedot on suojattu myös lepoaikana. Semanttisen välimuistin täytäntöönpanon on noudatettava näitä periaatteita, sitä ei pitäisi nähdä pelkästään suorituskyvyn tai kustannustehokkuuden kerroksen lisäämiseksi. Monen vuokralaisen järjestelmässä vuokralaisen eristysavaimet on toteutettava välimuistiin. Vastaavasti hyperpersonoidussa käyttäjän järjestelmässä käyttäjän tason nimipaikan jakaminen on tehtävä välimuistiin. Tärkein tekijä valtuuttamisessa on luominen lupa-tietoisia välimuistiavaimia, joissa avaimen hash sisältää käyttäjän erityisiä rooleja tai käyttöoikeustasoja. Näin varmistetaan, että käyttäjä, jolla on vähemmän etuoikeuksia ei saa välimuistiin vastausta etuoikeutetummalta käyttäjältä. välimuisti ei saa olla luvaton tiedonhankintamekanismi. Jos käyttäjällä ei ole lupaa hakea tiettyä asiakirjaa tai tietokannan riviä RAG-putken kautta, hän ei saa pystyä vetämään syntynyttä vastausta välimuistiin. Lopuksi erilaisten vaatimustenmukaisuusvaatimusten, kuten HIPPA: n tai SOC2: n, täyttämiseksi vastauksesi on salattava ennen välimuistiin tallentamista. Johtopäätös Arkkitehtuurin suunnitelma, koodin kappaleet ja erilaiset pikakuvakkeet osoittavat, että on mahdollista semanttisesti välimuistiin kysymykset ja tehdä vektorin upottamiseen perustuva samankaltaisuus haku palauttaa aiemmin luotuja vastauksia välttää RAG-pohjaisia LLM-pyyntöjä vastaaviin kysymyksiin. Yllä oleva esimerkki on melko yksinkertainen, mutta voimme laajentaa tätä arkkitehtuurivalintaa useisiin LLM-kosketuspisteisiin, jotka tapahtuvat Agentic AI -järjestelmässä tekemään päätöksiä paitsi loppukäyttäjien kysymyksille ja vastauksille. Semanttinen välimuisti on yksinkertainen tapa alentaa tokenikustannuksia säilyttäen vastauslaadun. Jos järjestelmäsi saa vastaamaan samankaltaisiin kyselyihin, välimuistikerroksen lisääminen ennen haku- ja tuotantovaiheita on etu. Helpoin osa on, että sinun ei tarvitse uudistaa RAG-arkkitehtuuria, voit vain optimoida virtauksen käsittelemällä toistuvaa aikomusta aikaisemmin ketjussa.

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

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Optimoi LLM: n käyttökustannukset semanttisella välimuistilla

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

Hurry! Just One Month Left to Win Up to $2,000 in the #blockchain Writing Contest

Tee Q1 markkinointi lasketaan: keskittyä, suorittaa, toimittaa

Dotcom on edelleen uusien yritysten suosituin verkkotunnus, mutta käyttö laskee

Spaghetti

Hurry! Just One Month Left to Win Up to $2,000 in the #blockchain Writing Contest

Tee Q1 markkinointi lasketaan: keskittyä, suorittaa, toimittaa

Dotcom on edelleen uusien yritysten suosituin verkkotunnus, mutta käyttö laskee

Spaghetti

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps