> Hogyan használják újra a szemantikus cache-ek az LLM-válaszokat hasonló kérdésekre, miben mások, mint a prompt caching, és hogyan kerüld el a téves találatokat.
>
> Web page: https://balazscsorba.com/hu/blog/semantic-caching-llm-responses · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/semantic-caching-llm-responses.md) · [Deutsch](https://balazscsorba.com/de/blog/semantic-caching-llm-responses.md)
> Author: Balázs Csorba · Published: 2026-10-16 · Keywords: semantic caching llm, semantic cache, llm response cache, gptcache, semantic cache similarity threshold, prompt caching vs semantic caching, reduce llm api cost, cache llm answers redis, semantic cache false positive, llm cache invalidation

[Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés

# Szemantikus gyorsítótár LLM-alkalmazásokhoz: mikor biztonságos újrahasznosítani a válaszokat, és mikor nem

Hogyan használják újra a szemantikus cache-ek az LLM-válaszokat hasonló kérdésekre, miben mások, mint a prompt caching, és hogyan kerüld el a téves találatokat.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 16.·6 perc olvasás

-   Semantic cache
-   LLM cost
-   Latency
-   Embeddings
-   Redis

![Egy új kérdést embeddelünk és a tárolt kérdésekkel vetünk össze; egy hasonlósági küszöb felett a tárolt választ kapjuk, alatta a modellt hívjuk.](https://balazscsorba.com/images/blog/semantic-caching-llm-responses/cover.webp?v=c4ac35bd49)

## A lényeg röviden

-   A prompt caching a szolgáltatónál egy azonos előtagot használ újra, és sosem változtatja meg a választ; a szemantikus cache egy hasonló kérdésre tárolt választ ad vissza.
-   Egy közzétett, ügyfélszolgálati jellegű teszten a szemantikus cache akár 68,8%-kal csökkentette az API-hívásokat, 97% feletti helyes találati aránnyal.
-   A hasonlósági küszöb termékdöntés: olyan címkézett kérdéspárokból állítsd be, amelyeknek ugyanazt a választ kell kapniuk, illetve nem kaphatják.
-   A cache-kulcsokat bérlő, felhasználó, nyelv és adatverzió szerint válaszd szét, különben egy ügyfél egy másik ügyfél válaszát kaphatja.
-   Csak olyan válaszokat cache-elj, amelyek nem függnek friss adattól vagy személyes kontextustól, és minden bejegyzésnek legyen TTL-je és érvénytelenítési útja.

Ezen az oldalon

1.  [Miben különbözik a szemantikus cache a prompt cachingtől?](https://balazscsorba.com/#prompt-vs-semantic-caching)
2.  [Hogyan működik a szemantikus cache?](https://balazscsorba.com/#how-it-works)
3.  [Mennyit spórol a szemantikus cache?](https://balazscsorba.com/#how-much-it-saves)
4.  [Hogyan válaszd ki a hasonlósági küszöböt?](https://balazscsorba.com/#choosing-the-threshold)
5.  [Hogyan akadályozd meg, hogy a szemantikus cache adatot szivárogtasson?](https://balazscsorba.com/#scope-and-privacy)
6.  [Hogyan járjanak le és érvénytelenedjenek a tárolt válaszok?](https://balazscsorba.com/#invalidation)
7.  [Mit kell monitorozni?](https://balazscsorba.com/#measure-it)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

Az ügyfélszolgálati asszisztensek és a GYIK-botok újra és újra ugyanazokra a kérdésekre válaszolnak: hogyan állítom vissza a jelszavam, hol a számlám, mennyi a szállítási idő. Mindegyik kérdés egy modellhívásba kerül. A szemantikus cache az első alkalommal eltárolja a választ, és visszaadja, ha egy későbbi kérdés ugyanazt jelenti, még ha másképp is fogalmazták. Jól megcsinálva a hívások nagy része elmarad, és a válasz ezredmásodpercek alatt megérkezik. Hanyagul megcsinálva magabiztos válaszokat ad olyan kérdésekre, amelyeket senki sem tett fel.

A cikk szétválasztja a szemantikus cache-t a szolgáltatói prompt cachingtől, bemutatja az architektúrát, és idejének nagy részét azokra a részekre szánja, amelyeken a biztonság múlik: a küszöbre, a cache hatókörére, arra, mit ne cache-elj, és az érvénytelenítésre.

## Miben különbözik a szemantikus cache a prompt cachingtől?

Szempont

Prompt caching (szolgáltató)

Szemantikus cache (saját)

Egyezés

Pontosan azonos előtag

Hasonló jelentés egy küszöb felett

Mit használ újra

Feldolgozott bemeneti tokenek

A teljes tárolt válasz

Fut-e a modell

Igen, a válasz újonnan generálódik

Találatnál nem

Rossz válasz kockázata

A cache miatt nincs

Igen, téves találatnál

A Claude [prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) dokumentációja egyértelmű: a találathoz 100%-ban azonos promptszakaszok kellenek, és a cache nincs hatással a kimenet generálására. Ez eleve biztonságos, és ezt érdemes először bekapcsolni; erről a [prompt caching és modellirányítás](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing) cikkben írtam. A szemantikus cache a modell előtt ül, és más jellegű döntés, mert azt változtatja meg, mit kap a felhasználó.

## Hogyan működik a szemantikus cache?

Találat hiányában a modell válaszol, az eredmény visszaíródik, így a cache valós forgalomból töltődik fel.

Az olyan könyvtárak, mint a [GPTCache](https://github.com/zilliztech/GPTCache), ezt embedding-generátorra, a válaszok tárolójára, a kérdések vektortárára és egy hasonlóság-értékelőre bontják, amely eldönti, hogy egy jelölt egyezik-e. Könyvtár nem feltétlenül kell hozzá: egy embedding-tábla vektorindexszel Postgresben, például [pgvector](https://balazscsorba.com/hu/tools/pgvector), és húsz sor kód elég.

```
# Illustrative semantic cache on Postgres + pgvector
def cached_answer(question: str, scope: dict) -> str:
    q = normalize(question)
    vec = embed(q)                                       # same model for writes and reads
    row = db.fetchone("""
        SELECT answer, 1 - (embedding <=> %(v)s) AS sim
        FROM answer_cache
        WHERE tenant = %(tenant)s AND lang = %(lang)s AND data_version = %(ver)s
          AND expires_at > now()
        ORDER BY embedding <=> %(v)s LIMIT 1""", {"v": vec, **scope})
    if row and row.sim >= THRESHOLD:
        metrics.hit(row.sim)
        return row.answer
    answer = call_model(question, scope)
    if cacheable(question, answer):
        db.execute("INSERT INTO answer_cache (...) VALUES (...)")   # with expires_at = now() + ttl
    return answer
```

## Mennyit spórol a szemantikus cache?

A [GPT Semantic Cache tanulmány](https://arxiv.org/abs/2411.05276) Redisben tárolta a lekérdezések embeddingjeit, és ismétlődő, ügyfélszolgálati jellegű kérdéseken tesztelt. Akár 68,8%-kal kevesebb API-hívásról, kategóriától függően 61,6% és 68,8% közötti találati arányról és 97% feletti helyes találatról – azaz helyes választ adó találatról – számol be. Ezek a számok szándékosan ismétlődő forgalomból származnak. Egy termék-GYIK ilyen; egy nyílt végű asszisztens vagy egy kódolóeszköz nem, és a találatok töredékét fogja látni.

Mielőtt bármit építenél, mérd meg: naplózz egy hétnyi kérdést, embeddeld őket, és számold meg, hánynak van olyan közeli szomszédja, amelyet egy ember ugyanannak a kérdésnek fogadna el. Ez a szám a plafon.

## Hogyan válaszd ki a hasonlósági küszöböt?

Az embedding-hasonlóság a témát méri, nem a szándékot. A _Hogyan mondhatom le a rendelésemet?_ és a _Hogyan mondhatom le az előfizetésemet?_ a vektortérben nagyon közel van, mégis más választ igényel. A _Visszaküldhetem a kibontott terméket?_ és a _Visszaküldhetem a bontatlan terméket?_ egyetlen szóelemben tér el, és ellentétes a válaszuk. Egy átlagos hasonlóságra hangolt küszöb boldogan kiszolgálja az egyiket a másik helyett.

1.  Gyűjts néhány száz valódi kérdéspárt, és mindegyiket címkézd: azonos vagy eltérő válasz. A trükkös negatív példákat szándékosan vedd fel.
2.  Számold ki minden pár hasonlóságát azzal az embedding-modellel, amelyet élesben használsz.
3.  Válaszd azt a legalacsonyabb küszöböt, amelynél a téves találatok nullán vagy a közelében maradnak, és fogadd el az ebből adódó találati arányt.
4.  Ismételd meg az ellenőrzést, valahányszor embedding-modellt váltasz, mert a hasonlósági skálák modellenként eltérnek.

A határsávban egy második ellenőrzés segít: a küszöb felett éppen csak átjutó találatoknál kérdezz meg egy kis, olcsó modellt, hogy a két kérdésre ugyanaz-e a válasz. Ez sokkal olcsóbb, mint a válasz generálása, és kiszűri a közeli tévedések többségét.

## Hogyan akadályozd meg, hogy a szemantikus cache adatot szivárogtasson?

A cache a felhasználók közös memóriája. Ha a _Mekkora a jelenlegi kedvezményem?_ kérdésre adott választ az ügyfélazonosító nélkül cache-eled, a következő kérdező ügyfél az első kedvezményét kapja. Minden keresést válassz szét mindazok szerint, amitől a válasz függ:

-   **Bérlő, személyes válaszoknál a felhasználó is.** Vagy zárd ki teljesen a személyes válaszokat a cache-ből.
-   **Nyelv**, hogy egy német kérdés ne kapjon tárolt angol választ.
-   **Szerepkör vagy jogosultsági szint**, ha a belső munkatársak többet látnak, mint az ügyfelek.
-   **Adat- és promptverzió:** egy új árlista, szabályzatszöveg vagy rendszerprompt új cache-névteret indítson.

A személyes adatot tartalmazó tárolt válaszok tárolt személyes adatok, a megfelelő megőrzési kötelezettségekkel; lásd a [PII-kitakarás LLM-pipeline-okban](https://balazscsorba.com/hu/blog/pii-redaction-llm-pipelines) cikket. A cache ráadásul írási útvonal is: ha a felhasználók tetszőleges modellkimenetet eltárolhatnak, amelyet aztán másoknak szolgálunk ki, egy prompt injectionnel manipulált válasz elterjedhet. Csak megbízható folyamatokból származó válaszokat tárolj, a guardrailek által megjelölt munkamenetekből soha.

**Soha ne cache-elj élő adattól függő választ**

A készletszint, az árak, a rendelési állapot és minden, ami eszközhívás mögött van, gyorsabban változik bármilyen ésszerű TTL-nél. A stabil részeket cache-eld, például a visszakeresett szabályzat-részleteket vagy a saját lejárattal rendelkező eszközeredményeket, a végső választ pedig a modell állítsa össze.

## Hogyan járjanak le és érvénytelenedjenek a tárolt válaszok?

Három mechanizmust használj együtt. Minden bejegyzésnek legyen TTL-je, inkább órákban vagy napokban, mint hónapokban mérve. A cache-kulcsban legyen verzió arra az adatra és promptra, amelyből a válasz született, így egy tartalomfrissítés új névtérre vált, ahelyett hogy egyenként törölnéd a sorokat. Végül kézi törlés dokumentumonként: ha valaki módosítja a visszaküldési szabályzatot, törölj minden bejegyzést, amelynek válasza ezt a dokumentumot idézte. Ehhez minden tárolt válasz mellé el kell menteni a forrásazonosítókat, ami a hivatkozások miatt amúgy is megéri, ahogy a [grounding és hivatkozások](https://balazscsorba.com/hu/blog/llm-hallucination-grounding-citations) cikkben.

## Mit kell monitorozni?

Metrika

Miért

Találati arány hatókörönként

Megmutatja, hol térül meg a cache

A találatok hasonlóság-eloszlása

A küszöb közeli sok találat kockázatot jelez

Negatív visszajelzés aránya tárolt és friss válaszokra

A téves találatok közvetlen jele

Találatok mintavételes emberi átnézése

Elkapja a felhasználók által nem jelzett téves találatokat

A cache-találatokat ugyanúgy trace-eld, mint bármely más lépést, a hasonlósági értékkel és a tárolt bejegyzés azonosítójával, hogy egy rossz válasz visszakövethető legyen ahhoz a kérdéshez, amelyre eredetileg generálták; lásd az [LLM-ágensek megfigyelhetősége](https://balazscsorba.com/hu/blog/agent-observability-opentelemetry) cikket.

## Források

1.  [Regmi and Pun: GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching (2024)](https://arxiv.org/abs/2411.05276)
2.  [Zilliz: GPTCache README (modules, similarity evaluation, eviction)](https://github.com/zilliztech/GPTCache)
3.  [Claude Platform Docs: Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)
4.  [pgvector README: vector types and indexes](https://github.com/pgvector/pgvector)

## Gyakori kérdések

Mi a különbség a prompt caching és a szemantikus cache között?

A prompt caching szolgáltatói funkció, amely a prompt feldolgozott előtagját használja újra, ha az pontosan azonos; a modell ettől még új választ generál. A szemantikus cache saját réteg, amely egy korábban generált választ ad vissza, ha az új kérdés elég hasonló egy tárolthoz, és így teljesen megspórolja a modellhívást.

Mennyit spórolhat egy szemantikus cache?

Attól függ, mennyire ismétlődő a forgalom. A GPT Semantic Cache tanulmány ismétlődő, ügyfélszolgálati jellegű kérdéseknél akár 68,8%-kal kevesebb API-hívásról, 61,6–68,8%-os találati arányról és 97% feletti helyes találatról számol be. A nyílt végű chat sokkal kevesebb találatot hoz.

Milyen hasonlósági küszöböt használjak?

Nincs univerzális szám; az embedding-modelltől és a szakterülettől függ. Gyűjts valódi kérdéspárokat, címkézd őket azonos vagy eltérő válaszként, és azt a küszöböt válaszd, amelynél ezen a készleten a téves találatok közel nullák maradnak.

Biztonságos a szemantikus cache személyes adatokkal?

Csak ha a bejegyzések ahhoz a felhasználóhoz vagy bérlőhöz vannak kötve, akié, és a személyes adatot tartalmazó válaszokat kizárod vagy felhasználónként cache-eled. Egy elválasztás nélküli közös cache kiszivárogtathatja az egyik felhasználó válaszát a másiknak.

Mikor ne használjak szemantikus cache-t?

Ha a válasz élő adattól függ, például készlettől, áraktól vagy rendelési állapottól, az eddigi beszélgetéstől vagy a felhasználó jogosultságaitól. Ilyenkor a drága részeket cache-eld, például a visszakeresési eredményeket vagy az eszközkimeneteket, ne a végső választ.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Strukturált kimenet JSON Schemával: mit fed le a garancia, és mit nem](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm)
-   [MI-ügynökök értékelése: trajektóriák, eredmények és megbízhatóság pontozása](https://balazscsorba.com/hu/blog/evaluating-ai-agents-trajectories)
-   [LLM-modellmigráció regresszió nélkül: elavulás, evalok, árnyékforgalom](https://balazscsorba.com/hu/blog/llm-model-migration-regression-testing)
-   [Saját LLM-üzemeltetés a GDPR miatt: mikor kell és mibe kerül](https://balazscsorba.com/hu/blog/self-hosted-llm-gdpr-cost)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)