Semantic Caching pre LLM 2026: GPTCache, Redis a bezpečné threshold pre produkciu

Aktualizované: 20. augusta 2026

Semantic caching pre LLM je aplikačná vrstva medzi vašou službou a modelom, ktorá vráti uloženú odpoveď na sémanticky podobný dopyt bez ďalšieho volania LLM. Namiesto porovnávania reťazcov porovnáva vektorové embeddingy pomocou kosínusovej podobnosti. V produkcii dokáže znížiť náklady o 30 až 70 %, ale zle nastavený prah podobnosti alebo chýbajúca izolácia medzi nájomníkmi vedú k tomu, že zákazník A dostane odpoveď určenú zákazníkovi B. V tomto sprievodcovi ukážem, ako som zaviedol semantic cache na dvoch produkčných SaaS systémoch, čo išlo dobre a kde som sa spálil.

• Semantic cache nahrádza LLM volanie úplne, keď je nový dopyt sémanticky podobný uloženému. Prompt caching stále volá model, len znižuje prefill cenu.
• Priemyselný štandard pre prah kosínusovej podobnosti v roku 2026 je 0,92 až 0,95. Pod 0,88 dostávate falošné pozitíva, nad 0,98 je hit rate zanedbateľný.
• GPTCache je knižničný prístup s pluggable komponentmi, Redis Stack + RedisVL je infraštruktúrny prístup a Redis LangCache je manažovaná služba.
• Namespace izolácia podľa tenant_id nie je voliteľná. Bez nej riskujete leak dát medzi zákazníkmi, čo blokuje SOC 2 a GDPR audit.
• Očakávaný hit rate v produkcii: FAQ chatboty 40 až 70 %, doménovo špecifické podporné boty 60 až 80 %, kreatívne generovanie takmer 0 %.
• Kvalita embedding modelu ovplyvňuje presnosť cache viac než akékoľvek iné rozhodnutie. Lacné embeddingy mapujú rôzne dopyty do blízkych vektorov.

Čo je semantic caching pre LLM

Semantic caching je vrstva pred LLM API, ktorá pre každý prichádzajúci dopyt vypočíta vektorový embedding, spustí similarity search voči už uloženým embeddingom a ak výsledok prekročí definovaný prah kosínusovej podobnosti, vráti uloženú odpoveď bez volania modelu. Rozdiel oproti klasickému key-value cache je v tom, že dva textovo odlišné dopyty (napríklad "Ako obnovím heslo?" a "Nemôžem sa prihlásiť, ako zmením heslo?") majú takmer identický embedding a produkujú cache hit, hoci ich žiaden hash mechanizmus nespojí.

Typický flow vyzerá takto. Klient odošle prompt, gateway ho pošle embedding modelu (najčastejšie text-embedding-3-small od OpenAI alebo bge-small-en-v1.5 lokálne), výsledný 1536-dimenzionálny vektor sa hľadá v Redis Stack alebo pgvector cez FT.SEARCH s HNSW indexom. Ak najbližší sused má cosine similarity ≥ 0,93, vráti sa uložená odpoveď za 3 až 8 ms; inak sa volá LLM a nová dvojica (embedding, odpoveď) sa uloží. Celá vrstva žije v aplikačnej rovine alebo v LLM gateway ako LiteLLM či Portkey, nie v modeli.

Ekonomicky je matematika jednoduchá. Volanie gpt-4o na 500 vstupných a 300 výstupných tokenov stojí v roku 2026 zhruba 0,006 USD; embedding tej istej otázky cez text-embedding-3-small stojí 0,00001 USD. Pri hit rate 50 % ušetríte 3 000 USD z každých 6 000 USD mesačného LLM účtu, pričom prídavné náklady na Redis Stack sú rádovo 60 USD mesačne za inštanciu s 1 miliónom cached záznamov. Nie zlé.

Semantic caching vs prompt caching: v čom sa líšia

Toto je najčastejšia otázka, ktorú v konzultáciách dostávam, a väčšina tímov obidva pojmy zamieňa. Rozdiel je zásadný, pretože riešia úplne iný problém a v produkcii sa navzájom dopĺňajú.

Prompt caching je vlastnosť samotného modelu. OpenAI Prompt Caching a Anthropic Prompt Caching ho ponúkajú natívne. Model si pamätá výsledok prefill výpočtu pre dlhý spoločný prefix (systémový prompt, dokumenty v RAG) a pri ďalšom volaní ho preskočí. Stále však prebieha inferencia a stále platíte za výstupné tokeny. Iba prvá latencia je nižšia a cena vstupných tokenov klesá o 50 až 90 %. Detaily som pokryl v článku Prompt Caching pre LLM 2026.

Semantic caching žije v aplikačnej vrstve a LLM volanie preskočí úplne. Ak nový dopyt má cosine similarity 0,95 s už uloženým, vrátite hotovú odpoveď za 5 ms a neplatíte nič okrem embeddingu. Kompromisom je riziko. Keďže rozhodovanie robí embedding model a nie deterministické hashovanie, môžete vrátiť zlú odpoveď na jemne odlišnú otázku.

Vlastnosť	Prompt Caching	Semantic Caching
Vrstva	Model / inference	Aplikácia alebo gateway
Matching	Presný prefix (SHA)	Cosine similarity nad embeddingom
Volá LLM?	Áno (znižuje TTFT)	Nie pri hit
Riziko chybnej odpovede	Žiadne	Vysoké bez tuningu
Vhodné pre	Dlhé stabilné system prompty, RAG	FAQ, opakované user queries
Úspora nákladov	50 až 90 % input tokenov	100 % pri hit (celé volanie)
Typický hit rate	90 %+ pre stabilný prefix	30 až 70 % pre FAQ workload
Nastavenie	Provider-natívne	Vlastná infra (Redis, pgvector)

V praxi ich kombinujem. Prompt caching zapínam vždy, keď mám systémový prompt nad 1 024 tokenov, semantic caching pridávam iba pri workloadoch s jasným opakovaním otázok (helpdesk, produktové FAQ, dokumentačné boty). Pre generatívne úlohy, napríklad písanie e-mailov či sumarizáciu unikátnych dokumentov, semantic cache nepoužívam vôbec, pretože hit rate klesá pod 5 % a hyzdí latency profil.

GPTCache, Redis Stack a LangCache: ktorá voľba pre produkciu

V roku 2026 sú v hre tri hlavné prístupy k semantic caching a rozdiel medzi nimi nie je akademický. Každý sa hodí na iný organizačný kontext.

GPTCache

GPTCache od Zillizu je open-source Python knižnica, ktorú vložíte priamo do aplikácie. Má modulárnu architektúru, kde môžete nezávisle vymeniť embedding model, vektorový store (Milvus, Faiss, Redis, Qdrant), similarity evaluator aj cache storage. Integruje sa s LangChain a LlamaIndex. Nevýhoda? Default konfigurácia používa SQLite ako cache backend, čo je pre produkciu nesprávna voľba. Pri viac ako 500 tisíc záznamoch výkon dramaticky klesá. Ak volíte GPTCache, prepnite backend na Redis a vector store na Qdrant hneď na začiatku.

Redis Stack + RedisVL

Toto je variant, ktorý najčastejšie odporúčam európskym SaaS klientom, ktorí už Redis prevádzkujú. Redis Stack pridáva vector similarity search cez FT.SEARCH s HNSW alebo FLAT indexom a knižnica RedisVL poskytuje SemanticCache triedu s TTL a distance threshold tuningom. Latencia lookupu ostáva pod 5 ms aj pri 10 miliónoch záznamov, škáluje horizontálne a integruje sa s existujúcim monitoringom (Prometheus exporter je natívny). Prevádzkovo najjednoduchšia voľba, ak už máte Redis.

Redis LangCache a iné manažované služby

Redis LangCache je plne manažovaná služba s vstavaným embeddingom, konfigurovateľnou similarity kontrolou a hit rate dashboardom. Podobný model ponúkajú aj gateway-native riešenia ako Portkey a TrueFoundry Bifrost, kde cache je integrovaná s routingom a fallback logikou. Pre tímy bez SRE kapacity ide o rozumné riešenie, ale máte menšiu kontrolu nad embedding modelom a data residency (kritické pre GDPR, pýtajte sa, kde konkrétne vektory ležia).

pgvector alebo Databricks Lakebase

Ak už máte PostgreSQL s pgvectorom pre vektorové databázy vo vašom RAG stacku, môžete tam semantic cache pridať bez novej infraštruktúry. Latencia je vyššia než pri Redis (typicky 15 až 25 ms na lookup pri milión záznamoch), ale prevádzková jednoduchosť za to stojí, ak už PostgreSQL ladíte.

Implementácia s Redis Stack a RedisVL krok za krokom

Ukážem minimálnu produkčnú implementáciu, ktorú som nasadil pre B2B FinTech klienta v Berlíne. Predpokladám Redis Stack 7.4+ (pre HNSW indexy) a Python 3.11+.

pip install redisvl==0.6.0 openai==1.51.0 redis==5.2.0

Definícia cache s namespace izoláciou podľa tenanta a TTL 24 hodín:

from redisvl.extensions.llmcache import SemanticCache
from redisvl.utils.vectorize import OpenAITextVectorizer
import os

vectorizer = OpenAITextVectorizer(
    model="text-embedding-3-small",
    api_config={"api_key": os.environ["OPENAI_API_KEY"]},
)

def get_cache_for_tenant(tenant_id: str) -> SemanticCache:
    return SemanticCache(
        name=f"llmcache:{tenant_id}",     # kriticke: namespace per tenant
        prefix=f"llmcache:{tenant_id}",
        redis_url=os.environ["REDIS_URL"],
        distance_threshold=0.07,           # cosine distance = 1 - similarity -> 0.93 sim
        ttl=86400,                          # 24h
        vectorizer=vectorizer,
    )

Wrapper okolo LLM volania so záznamom metadát pre observabilitu:

import time
from openai import OpenAI
import logging

client = OpenAI()
log = logging.getLogger("llm.cache")

def ask_llm(tenant_id: str, question: str, model: str = "gpt-4o") -> str:
    cache = get_cache_for_tenant(tenant_id)
    t0 = time.perf_counter()
    hit = cache.check(prompt=question, num_results=1)

    if hit:
        latency_ms = (time.perf_counter() - t0) * 1000
        log.info(
            "cache.hit",
            extra={
                "tenant_id": tenant_id,
                "cache_layer": "semantic",
                "cache_similarity": 1 - hit[0]["vector_distance"],
                "cache_age_seconds": hit[0].get("age_seconds"),
                "latency_ms": latency_ms,
            },
        )
        return hit[0]["response"]

    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": question}],
    )
    answer = resp.choices[0].message.content
    cache.store(prompt=question, response=answer, metadata={"model": model})
    log.info(
        "cache.miss",
        extra={"tenant_id": tenant_id, "cache_layer": "miss",
               "tokens": resp.usage.total_tokens},
    )
    return answer

Zaraďte cache za rate limiter, nie pred neho. Inak útočník môže spôsobiť cache stuffing zaslaním tisícov drahých promptov a vyplniť pamäť. Nastavte maxmemory-policy allkeys-lru na Redis, aby najstaršie záznamy vypadli automaticky.

Ako nastaviť similarity threshold a nespáliť sa

Threshold je jediný parameter, ktorý rozhoduje medzi ušetrenými nákladmi a chybnými odpoveďami. Nie je to teoretická úloha, treba merať vlastný workload. Tu je postup, ktorý som prevzal z niekoľkých nasadení a ktorý funguje:

1. Začnite konzervatívne pri 0,95. Prvé dva dni sledujte hit rate. Ak je pod 5 %, cache nemá zmysel a klesajte po 0,01 dole.
2. Vytvorte evaluačný set 100 až 300 dvojíc. Každá dvojica je (dopyt A, dopyt B, mala by byť rovnaká odpoveď: ÁNO/NIE). Zdroj: reálne logy alebo doménovo generované cez GPT-4o. Toto je best practice zo štandardu MeanCache research paperu, ktorý potvrdzuje, že bez ground-truth setu ladíte naslepo.
3. Prehrajte set cez svoj embedding model a vypočítajte F1 skóre pre thresholdy 0,88 až 0,98. Zvoľte threshold, kde F1 je maximálny. U FAQ workloadov to býva okolo 0,93, u technicky presných otázok skôr 0,96.
4. Používajte adaptívne thresholdy podľa dĺžky dopytu. Krátke faktické otázky (do 10 slov) tolerujú vyšší threshold, dlhé nuansované dopyty potrebujú prísnejší. V produkcii som to riešil tak, že pre prompty pod 50 znakov threshold zvyšujem o 0,02.
5. Zapnite false-positive sampling. Náhodne pri 1 % cache hitov aj tak zavolajte LLM a porovnajte odpovede offline. Ak > 2 % divergujú, threshold zvýšte.

Multi-tenant izolácia a GDPR

Toto je časť, na ktorej som osobne najviac zákazníkov videl spadnúť. Semantic cache totiž z definície uchováva prompt v čitateľnej forme (potrebujete ho pre re-embedding a debug) plus vektor, ktorý je matematicky odvoditeľný na blízke prompty. Ak vaša aplikácia spracúva osobné údaje, napríklad mená klientov, adresy či číslo účtu, cache je z pohľadu GDPR spracovanie osobných údajov a musí byť rovnako chránená ako produkčná DB.

Tri pravidlá, ktoré som si vypracoval po jednom leak incidente v roku 2024:

1. Namespace per tenant je povinný. Redis prefix, Qdrant collection alebo pgvector partition. Nikdy zdieľaná tabuľka bez WHERE filtra na aplikačnej vrstve. Aplikačný filter je krehký; audit chce fyzickú separáciu.
2. PII detekcia pred store. Používam Microsoft Presidio na anonymizáciu promptu pred embedovaním. Číslo IBAN alebo e-mail nahradím tokenom <IBAN>. Cache tak zostane užitočná pre podobné otázky, ale nedrží raw PII.
3. TTL nie viac ako 24 až 72 hodín pre user-facing cache. GDPR nemá explicitnú lehotu, ale pri incidentnom prípade sa audítor pýta „prečo držíte odpoveď zákazníka mesiac?" a odpoveď „lebo to zlepšuje hit rate" nestačí.

Pre EÚ zákazníkov navyše kontrolujte, kde vektory fyzicky ležia. Manažované služby ako Redis LangCache alebo Pinecone majú v roku 2026 EÚ regióny, ale niektoré defaultne routeujú embedding volania cez US endpointy. Overiť sa to dá cez SNI inšpekciu odchádzajúceho traffic v testovacom prostredí.

Observabilita a monitoring falošných pozitívov

Bez správnej observability je semantic cache čierna skrinka, ktorá ticho generuje zlé odpovede. Metriky, ktoré emitujem na každé volanie:

• cache_layer: hodnoty hit, miss, disabled. Základné rozloženie.
• cache_similarity: konkrétne cosine podobnosti hitu. Histogram odhalí drift thresholdu.
• cache_age_seconds: koľko sekúnd stará bola vrátená odpoveď. Pomáha ladiť TTL.
• cache_cost_saved_usd: rozdiel medzi cenou LLM volania a embedding volania.
• false_positive_flag: príznak z 1 % samplingu, kde sme cache a LLM porovnali.
• tenant_id: povinné pre debug a per-tenant cost accounting.

Metriky exportujem cez OpenTelemetry do Langfuse alebo Grafana Loki. Detailný setup pre LLM observabilitu s Langfuse a LangSmith som rozobral v samostatnom článku. Kľúčový dashboard obsahuje tri panely: hit rate za 24h (target 40 až 60 %), P95 similarity distribúciu (mala by byť bimodálna, hity blízko 1, ostatné pod thresholdom) a false positive rate zo samplingu (target pod 1 %).

Kedy semantic caching nepoužiť

Semantic cache nie je univerzálna optimalizácia. V týchto scenároch ju vypnite alebo vôbec nezavádzajte:

• Kreatívne generovanie, napríklad písanie e-mailov, marketingové texty, unikátne sumarizácie. Používateľ očakáva rôznorodosť; cache by tú istú odpoveď servírovala každému.
• Časovo citlivé odpovede ako ceny, počasie, stav objednávky. Aj 5-minútový TTL môže vrátiť neplatné dáta.
• Tool-using agenti. Ak volanie mení stav (funkcia send_email, create_ticket), cache nesmie preskočiť vykonanie. Function calling a semantic cache miešajte iba v read-only vetvách.
• Regulované obsahy, teda právne, medicínske či finančné poradenstvo, kde jemný rozdiel v otázke znamená kompletne iné odporúčanie. Riziko regresného sporu prevažuje úsporu.
• Nízky volume. Pod 10 000 volaní mesačne infra Redis Stack alebo pgvector cache stojí viac než LLM účet.
• Streaming odpovede. Technicky to funguje, ale UX pre používateľa je čudné: cache hit vráti celý blok naraz, cache miss streamuje. Buď streamujte aj cache (znovu-simulácia), alebo cache úplne vypnite pre streamovaný endpoint.

Recentný výskum pripomína, že semantic cache je aj bezpečnostný povrch. CacheAttack paper ukázal, že útočník s prístupom k embedding modelu vie generovať adversárne dopyty, ktoré vyvolajú false-positive cache hit a vrátia mu odpoveď iného používateľa. V multi-tenant nasadení je toto reálna hrozba, nie akademická. Osobne som na to prišiel pri red-team teste, ktorý sme robili minulý rok. Nepríjemný večer.

Časté otázky

Aký je rozdiel medzi semantic caching a KV cache v LLM?

KV cache je optimalizácia vo vnútri modelu, ukladá vypočítané key/value tenzory attention vrstvy počas generovania jednej odpovede a je automatická. Semantic caching je vrstva v aplikácii, ktorá porovnáva embeddingy medzi rôznymi požiadavkami a vracia hotové odpovede. KV cache znižuje latenciu jedného generovania, semantic cache eliminuje volanie modelu úplne.

Aký hit rate môžem realisticky očakávať v produkcii?

Pre FAQ a customer support workloady s doménovým vokabulárom sa hit rate pohybuje medzi 40 % a 70 %, pre technickú dokumentáciu 60 až 80 %. Pre kreatívne generovanie klesá pod 5 % a cache nemá zmysel. Prvé dva týždne po nasadení hit rate rastie, ako sa napĺňa cache; ustálený stav dosiahne po zhruba 4 až 6 týždňoch.

Ako predchádzať falošným pozitívnym cache hitom?

Používajte vysokokvalitný embedding model (text-embedding-3-small alebo lokálne bge-large-en-v1.5), threshold minimálne 0,93 pre FAQ, 0,96 pre faktické dopyty, a zapnite náhodný sampling 1 % hitov s LLM verifikáciou. Nikdy nepoužívajte jeden globálny cache namespace pre viacero doménových kontextov, separujte podľa kategórie dopytu.

Je semantic caching GDPR compliant?

Áno, ak dodržíte tri podmienky: namespace izolácia podľa tenanta (fyzická, nie iba aplikačný filter), PII redakcia pred embedovaním (napr. cez Microsoft Presidio) a TTL do 72 hodín pre user-facing cache. Manažované služby ako Redis LangCache alebo Pinecone majú EÚ regióny, ale overte, kadiaľ konkrétne prebiehajú embedding volania.

Môžem semantic caching a prompt caching kombinovať naraz?

Áno a odporúčam to. Semantic cache riešite v aplikácii pre celé dvojice dopyt-odpoveď, prompt caching zapnite v OpenAI alebo Anthropic API pre dlhé systémové prompty a RAG kontext. Semantic cache miss stále profituje z prompt caching pre nižšie TTFT a lacnejšie vstupné tokeny. Tretia vrstva, KV cache, je automatická v modeli.