Riepilogo Tecnico: Grounded Cache Routing per la Generazione Aumentata dal Recupero

Enunciato del Problema

I moderni sistemi di Generazione Aumentata dal Recupero (RAG) utilizzano sempre più la memorizzazione nella cache (caching) per ridurre i costi dei token e il Tempo al Primo Token (TTFT). Sebbene il riutilizzo a livello di prefisso delle Chiavi-Valore (KV) e la memorizzazione nella cache dei risultati del recupero offrano forti garanzie di correttezza per costruzione, la memorizzazione nella cache semantica a livello di output rimane fragile. Le cache semantiche naive soffrono di tre principali modalità di fallimento:

1. Spostamento del Riferimento: Query semanticamente simili possono mappare su risposte corrette diverse a seconda del contesto.
2. Deriva del Recupero: Man mano che il corpus sottostante viene aggiornato, le prove precedentemente memorizzate nella cache possono diventare invalide o cambiare.
3. Collisione Adversariale: Input malevoli possono dirottare le risposte memorizzate nella cache, con tassi di dirottamento riportati fino all'86% negli scenari valutati.

I sistemi attuali spesso danno priorità a come riutilizzare le risposte più velocemente, trascurando la domanda critica di quando il riutilizzo sia sicuro. Questo documento sostiene che, senza una validazione rigorosa, la memorizzazione nella cache semantica introduce un significativo "tasso di servizio non sicuro" (USR), in cui gli utenti ricevono risposte errate dalla cache.

Metodologia: GroundedCache

Gli autori propongono GroundedCache, un router di cache validato dalle prove che agisce come un livello di policy sopra gli stack di servizio esistenti (ad esempio, vLLM, RAGCache). Invece di restituire ciecamente una risposta memorizzata nella cache per una query semanticamente simile, GroundedCache ammette una risposta memorizzata nella cache solo quando quattro specifici "cancelli" sono soddisfatti simultaneamente.

I Quattro Cancelli di Validazione

Data una voce memorizzata nella cache $(q_c, a_c, \sigma_c)$ e una query fresca $(q, \sigma, C)$, il router ammette $a_c$ se e solo se:

1. Somiglianza della Query (G1): La similarità coseno tra l'embedding della nuova query e l'embedding della query memorizzata nella cache supera una soglia ($\tau_q$).
2. Sovrapposizione delle Prove (G2): La similarità di Jaccard tra la nuova firma delle prove (insieme degli hash dei chunk) e la firma memorizzata nella cache supera una soglia ($\tau_e$).
3. Validità della Versione della Fonte (G3): I chunk condivisi tra le nuove prove e quelle memorizzate nella cache portano lo stesso tag di versione della fonte, garantendo che il corpus non sia stato mutato.
4. Supporto delle Prove (G4): I token di contenuto della risposta memorizzata nella cache sono coperti dalle prove appena recuperate. Questo è calcolato tramite un punteggio deterministico di sovrapposizione lessicale (predefinito) o opzionalmente tramite un LLM giudice leggero.

Se un qualsiasi cancello fallisce, il sistema ricade su una pipeline RAG standard: compressione condizionata alla query dei chunk recuperati seguita dalla generazione.

Carico di Lavoro e Metriche

Per stressare la sicurezza della cache piuttosto che solo i tassi di hit, gli autori hanno sintetizzato un carico di lavoro a sei regimi:

• Ripetizione esatta e Parafrasi: Scenari di riutilizzo benigni.
• Quasi-sbagliato: Query lessicalmente simili con documenti gold disgiunti.
• Deriva del documento: Query in cui i token numerici nei documenti gold sono mutati per invalidare le risposte memorizzate nella cache.
• Documento condiviso lungo e CAG KB delimitata: Scenari che favoriscono la deduplicazione e la generazione in contesto.

La metrica di valutazione primaria è il Tasso di Servizio Non Sicuro (USR), definito come la frazione di tutte le query che hanno ricevuto una risposta errata dalla cache. Questo è completato dal Tasso di Hit della Cache delle Risposte (aHR) e dal Tasso di Falso Hit Condizionale (FH).

Risultati Chiave

Gli esperimenti sono stati condotti sui dataset HotpotQA e mtRAG utilizzando 12.000 generazioni (Qwen2.5-7B-Instruct servito da vLLM).

Miglioramenti della Sicurezza

• HotpotQA: GroundedCache ha ridotto l'USR allo 0,0% in tutti i regimi in cui la memorizzazione nella cache naive aveva errori non nulli. Ad esempio, sul regime "deriva del documento", la memorizzazione nella cache naive aveva un USR del 35,0%, mentre GroundedCache ha raggiunto lo 0,0%.
• mtRAG (Multi-turn): La memorizzazione nella cache naive ha mostrato un fallimento catastrofico con un USR compreso tra il 26,0% e il 51,5% a causa degli spostamenti del riferimento. GroundedCache ha ridotto l'USR di oltre un ordine di grandezza, raggiungendo l'1,5% sul regime di deriva del documento (una riduzione di 34 volte delle risposte errate memorizzate nella cache).
• Studi di Ablazione: Il cancello di supporto lessicale (G4) è stato identificato come il meccanismo di sicurezza "portante". La sua rimozione ha aumentato l'USR di circa 0,125 su HotpotQA e di circa 0,118 su mtRAG. Gli altri cancelli (G1–G3) hanno fornito una difesa a più livelli a costo quasi nullo ma erano in gran parte ridondanti quando G4 era attivo.

Prestazioni e Latenza

• Latenza: La latenza p50 end-to-end sotto GroundedCache è rimasta entro 1,04–1,07× di una baseline RAG senza cache.
• Compromessi: Una variante "senza supporto" (disabilitando G4) ha offerto un aumento di velocità di 1,4–1,5 volte ma ha comportato un USR non nullo (0,125–0,182), dimostrando il compromesso regolabile tra sicurezza e velocità.
• Tassi di Hit: Sebbene GroundedCache abbia ridotto il tasso di hit grezzo della cache delle risposte (ad esempio, da 0,41 a 0,04 su HotpotQA per la ripetizione esatta) per garantire la sicurezza, ha mantenuto risparmi significativi nel recupero utilizzando il percorso della cache di recupero.

Significato e Affermazioni

Il documento afferma che la corretta impostazione per il riutilizzo delle risposte memorizzate nella cache non è massimizzare la velocità, ma quantificare e minimizzare il tasso di servizio non sicuro.

• Policy sopra Kernel: GroundedCache è presentato come un livello di policy che si compone con l'infrastruttura esistente (vLLM APC, LMCache, ecc.) senza richiedere modifiche al server del modello, al recuperatore o ai modelli di embedding.
• Metriche per Operatori: Gli autori sostengono che riportare l'USR insieme al tasso di hit e alla latenza è essenziale affinché i professionisti possano prendere decisioni informate sui loro compromessi sicurezza/velocità.
• Robustezza: Validando contro prove fresche e tag di versione, il sistema neutralizza efficacemente le collisioni adversariali e la deriva del corpus, che le cache semantiche naive non possono gestire.

Gli autori concludono che, sebbene le cache di risposte semantiche scambino intrinsecamente la correttezza per la velocità, il cancello di supporto lessicale fornisce un meccanismo economico e deterministico per garantire che il riutilizzo sia sicuro, portando il tasso di servizio non sicuro a quasi zero mantenendo al contempo i benefici di latenza della memorizzazione nella cache.