Semantic caching a devenit una dintre metodele preferate pentru a reduce costurile și latența în aplicațiile AI care folosesc RAG. Ideea este simplă: dacă două întrebări sunt suficient de apropiate ca sens, sistemul poate returna un răspuns deja calculat, fără să mai refacă tot traseul de căutare și generare. În practică, însă, adevărata problemă nu este cache-ul în sine, ci momentul în care informația din spate se schimbă. Dacă documentele sursă au fost actualizate, un cache semantic prost administrat poate servi răspunsuri vechi, deși întrebarea utilizatorului este formulată perfect.
Documentația RedisVL arată clar că semantic cache-ul funcționează pe bază de similaritate semantică și prag de distanță, tocmai pentru a reutiliza răspunsuri la prompturi apropiate. Tot acolo apare și un detaliu important: un prag mai strict reduce riscul de potriviri greșite, dar nu rezolvă singur problema prospețimii datelor. Cu alte cuvinte, chiar dacă găsești bine întrebări similare, poți returna un răspuns depășit dacă baza documentară s-a schimbat între timp.
Primul pas corect este să nu tratezi cache-ul ca pe o simplă pereche între întrebare și răspuns. Într-un sistem RAG sănătos, fiecare intrare din cache ar trebui legată și de contextul documentar din care a rezultat răspunsul. Asta înseamnă, minim, ID-urile documentelor folosite, o versiune sau un hash al documentelor, modelul de embedding folosit și o versiune internă a schemei de cache. Dacă nu stochezi aceste metadate, nu vei ști ce trebuie invalidat când apare o modificare.
Al doilea pas este să separi două niveluri de prospețime. Pe de o parte ai indexul sau baza ta de cunoștințe, care trebuie menținută actualizată. Microsoft explică în documentația Azure AI Search că, în scenariile clasice RAG, incremental indexing este una dintre metodele prin care conținutul rămâne proaspăt. Pe de altă parte ai cache-ul semantic, care trebuie sincronizat cu acele schimbări. Faptul că indexul s-a actualizat nu înseamnă automat că și răspunsurile cache-uite au devenit sigure.
Cea mai sigură strategie este invalidarea țintită. Când un document se modifică, identifici ce intrări din cache depind de acel document sau de acea versiune de corpus și le ștergi. RedisVL arată că un cache semantic gestionat prin LangCache poate folosi atribute pentru căutare și ștergere, inclusiv prin delete_by_attributes. În practică, asta îți permite să atașezi metadate precum source_doc_id, source_set sau corpus_version și să elimini doar intrările afectate, nu întregul cache.
Dacă modificările sunt frecvente, merită să introduci un câmp de tip corpus_version sau snapshot_version. La fiecare val important de update-uri, crești această versiune și o incluzi în cheia logică sau în metadatele cache-ului. Astfel, întrebările noi nu mai citesc răspunsurile generate pe o versiune veche a documentelor. Este o abordare mai curată decât golirea completă a cache-ului și mai sigură decât un TTL arbitrar.
TTL-ul rămâne util, dar doar ca plasă de siguranță, nu ca mecanism principal de invalidare. Documentația RedisVL pentru LangCacheSemanticCache și EmbeddingsCache arată că poți seta TTL implicit sau per intrare. Asta ajută la limitarea duratei de viață a unui răspuns, însă nu garantează corectitudinea imediată după o schimbare critică. Dacă actualizezi o politică internă sau o documentație tehnică, să aștepți expirarea naturală a cache-ului poate fi prea mult.
Mai este un detaliu important: nu toate backend-urile de semantic cache suportă update pe intrare. RedisVL notează explicit că, în cazul LangCacheSemanticCache, operațiile de update nu sunt suportate și trebuie să ștergi intrarea sau să o stochezi din nou. Tocmai de aceea, fluxul corect este acesta: detectezi schimbarea documentului, marchezi versiunea nouă, ștergi intrările afectate după atribute, apoi permiți repopularea cache-ului la următoarele interogări.
Pentru echipele care vor și mai mult control, o variantă matură este folosirea unor snapshot-uri sau backup-uri de index când faci schimbări structurale. Ghidul RedisVL pentru migrarea indexurilor insistă pe plan, backup și reluare sigură, tocmai pentru a evita inconsistențele în perioadele de tranziție. Nu este obligatoriu pentru orice proiect, dar devine relevant când schimbi schema vectorilor, modelul de embedding sau logica de indexare.
Concluzia practică este simplă: semantic caching merită doar dacă îl legi de versiunea reală a cunoștințelor. Nu cache-ui doar răspunsul, ci și proveniența lui. Nu te baza doar pe similaritate sau pe TTL. Și, mai ales, tratează modificarea documentelor ca pe un eveniment care trebuie să declanșeze invalidare controlată. Acolo se vede diferența dintre un demo rapid și un sistem RAG care rămâne util după ce conținutul începe să se miște.
Surse
- https://github.com/redis/redis-vl-python/blob/main/docs/user_guide/03_llmcache.ipynb
- https://github.com/redis/redis-vl-python/blob/main/docs/user_guide/13_langcache_semantic_cache.ipynb
- https://github.com/redis/redis-vl-python/blob/main/docs/user_guide/10_embeddings_cache.ipynb
- https://github.com/redis/redis-vl-python/blob/main/docs/user_guide/14_index_migration.ipynb
- https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
- https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-how-to-configure-freshness
