Riepilogo Tecnico: Cache-Aware Prompt Compression (CAPC)

Definizione del Problema

Le moderne implementazioni di Large Language Model (LLM) si affidano sempre più a due distinti primitivi di riduzione dei costi: il prompt caching (memorizzazione degli stati KV di un prefisso per applicare tariffe scontate per le letture successive) e la compressione del prompt (riduzione del numero di token dell'input). Storicamente, queste tecniche sono state trattate come ottimizzazioni separate. Tuttavia, la letteratura dominante sulla compressione dei prompt si basa su metodi query-aware (consapevoli della query), che generano un prefisso compresso unico per ogni specifica query.

Questa scelta di progettazione crea un conflitto fondamentale con i meccanismi di caching rigorosi rispetto al prefisso (es. cache_control di Anthropic). Poiché il prefisso compresso cambia con ogni query, la chiave di cache viene invalidata ad ogni chiamata. Di conseguenza, il sistema paga l'intero costo dell'input non scontato per ogni richiesta, annullando di fatto il risparmio derivante sia dalla compressione che dal caching. Sebbene la letteratura esistente spesso assuma un tasso di hit della cache ideale ($\rho = 1.0$), tale assunzione non tiene conto della realtà economica delle API nel mondo reale, dove il comportamento della cache è non banale e la compressione query-aware può risultare in un ritorno sull'investimento (ROI) netto negativo.

Metodologia e Caratterizzazione Empirica

Gli autori affrontano questo gap attraverso una combinazione di misurazione empirica, modellazione dei costi e progettazione algoritmica.

1. Caratterizzazione Empirica di Anthropic Sonnet 4.6

Il documento caratterizza innanzitutto il comportamento del caching dell'API Anthropic Sonnet 4.6 attraverso esperimenti controllati ($n=3$ prove, costo totale $1.91). Le scoperte chiave includono:

• Architettura a due livelli: La cache non è uniforme. Presenta una soglia netta vicino ai 3.500 token.
  • Livello Hot (< 3.5k token): Il tasso di hit ($\rho$) si stabilizza a circa 0,83 (specificamente 0,833 per 2k token) anche dopo 30 chiamate. Non è 1.0.
  • Livello Persistente (> 3.5k token): Il tasso di hit è efficacemente 1.0 dalla seconda chiamata in poi.
• Invalidazione rigorosa del token: L'invalidazione della cache è rigorosa rispetto alla sequenza di token. Anche minime mutazioni (es. un singolo cambiamento di carattere) causano un miss della cache, sebbene gli spazi bianchi iniziali/finali siano normalizzati dal tokenizer.
• Struttura dei prezzi: L'API applica un premio per le scritture in cache ($c_w$) rispetto agli input non in cache ($p_{in}$), e uno sconto significativo per le letture in cache ($c_r$). Su Sonnet 4.6, $c_w \approx 1.25 \times p_{in}$ e $c_r \approx 0.10 \times p_{in}$.

2. Modellazione dei Costi e Analisi del Crossover

Gli autori derivano un modello di costo per chiamata per quattro strategie:

• A (Vanilla): Nessun cache, nessuna compressione.
• B (Solo Cache): Prefisso completo in cache, nessuna compressione.
• C (Compressione Query-aware): Compressa per query, nessun cache (miss della cache ad ogni chiamata).
• D (CAPC): Compressione query-agnostic + caching.

Il modello definisce una soglia di crossover ($\rho_{cross}$) in cui il costo del caching (Strategia B) è uguale al costo della compressione query-aware (Strategia C):
$$\rho_{cross}(r) = \frac{c_w - p_{in}/r}{c_w - c_r}$$
L'analisi rivela che per rapporti di compressione elevati ($r \ge 6$), il tasso di hit richiesto affinché il caching superi la compressione query-aware ecceda il plateau empirico del livello hot di Sonnet 4.6 ($\rho \approx 0,89$). Pertanto, in condizioni realistiche, la compressione query-aware è spesso più economica del caching ingenuo, contraddicendo la convenzione comune.

3. L'Algoritmo CAPC

La soluzione proposta, Cache-Aware Prompt Compression (CAPC), combina tre componenti:

1. Compressione Query-Agnostic: Un documento statico viene compresso una sola volta (es. tramite selezione di frasi) in un prefisso fisso $D'$, garantendo che la chiave di cache rimanga costante tra le query.
2. Limite del Rapporto Preservante il Livello (Tier-Preserving Ratio Bound): Per evitare che la sovra-compressione spinga il prefisso nel "livello hot" (dove $\rho < 1$), il rapporto di compressione $r$ è limitato da $r_{max} = \lfloor |D| / 3500 \rfloor$. Ciò assicura che il prefisso compresso rimanga nel livello persistente ($\rho \approx 1.0$).
3. AdaptiveCacheBoundary: Per documenti in evoluzione, una subroutine classifica le posizioni delle frasi come STATIC, QUASI o DYNAMIC in base ai tassi di mutazione tra le versioni, effettuando il caching solo del prefisso stabile.

Risultati Chiave

1. Benchmark Sintetici LongBench-v2

Su 16 configurazioni (4 dimensioni di documento $\times$ 4 rapporti), CAPC è stata la strategia più economica in 16/16 casi.

• Risparmio: Risparmio medio del 49% rispetto al solo cache, del 64% rispetto alla compressione query-aware e del 90% rispetto alla vanilla.
• Qualità: CAPC ha mantenuto la qualità entro 0,05 rispetto alla baseline non compressa ai rapporti preservanti il livello.
• Validazione del Crossover: Al valore $r=6$, la compressione query-aware era più economica del solo cache in tutte le 4/4 configurazioni, validando la previsione del modello di crossover.

2. Validazione in Produzione: Assistente Enterprise per l'uso di Strumenti (Tool-Using)

Validato su un prefisso statico di 94k token (system prompt + 287 definizioni di tool MCP).

• Riduzione dei Costi: CAPC con $r=3$ ha ottenuto una riduzione dei costi del 51,7% rispetto alla vanilla.
• Qualità: La qualità della selezione dei tool corrisponde a quella del solo cache (0,700 vs 0,703).
• Insight: La compressione query-aware con $r=3$ ha performato peggio (0,603) nella selezione dei tool rispetto alla vanilla, perché scartava le definizioni dei tool rilevanti per la query. L'approccio query-agnostic di CAPC ha preservato l'intero catalogo, dimostrando una superiorità per gli agenti aumentati da tool.
• Caching Implicito: Lo studio ha rivelato che Anthropic esegue il caching implicito di grandi array tools= anche senza marcatori espliciti, riducendo il beneficio marginale del caching esplicito per le strategie vanilla ma non negando i guadagni di compressione di CAPC.

3. Knowledge-Graph RAG (Graphify)

Integrato con graphify per l'indicizzazione di codebase (repository FastAPI e httpx).

• Architettura: Lo strato 1 (cached, query-agnostic) contiene i metadati del grafo; lo strato 2 (per query) recupera il codice sorgente.
• Performance: CAPC ha fornito una riduzione dei costi di 9,3x su FastAPI e 2,4x su httpx rispetto a "cache-all" (scheletro completo del grafo), mantenendo tassi di hit della cache stabili dell'85%+.
• Qualità: CAPC ha superato le query native di graphify e le baseline di embedding-RAG, specialmente su codebase dove il modello aveva una conoscenza pregressa più debole (httpx), fornendo un incremento di qualità del 142% rispetto alla vanilla.

4. Benchmark Pubblico: $\tau$-Bench Retail

Valutato su 50 task deterministici con ricompense basate sullo stato del database (nessun giudice LLM).

• Risultato: CAPC è stata la strategia più economica, risparmiando il 7,9% rispetto alla vanilla pur ottenendo esattamente lo stesso tasso di completamento dei task (36/50) della vanilla ($z=0.00, p=1.00$).
• ROI Negativo di Query-Aware: La compressione query-aware era il 40,1% più costosa della vanilla, fornendo la prima conferma in produzione che i metodi query-aware possono avere un ROI negativo sui benchmark pubblici.

Significato e Rivendicazioni

Il paper sostiene di fornire la prima caratterizzazione sistematica dell'economia del prompt caching, andando oltre l'assunzione idealizzata di $\rho=1.0$. I suoi principali contributi sono:

1. Realtà Empirica: Dimostrare che le cache degli LLM hanno un'architettura a due livelli con un plateau di tasso di hit non banale sotto una specifica soglia di token.
2. Inversione Teorica: Provare che, per alti rapporti di compressione, la compressione query-aware è spesso più economica del caching ingenuo, invertendo la gerarchia di progettazione convenzionale.
3. Algoritmo Pratico: Introdurre CAPC, che unifica la compressione query-agnostic con il caching esplicito e un vincolo di preservazione del livello.
4. Validazione in Produzione: Validare queste scoperte attraverso benchmark sintetici, agenti enterprise per l'uso di tool, pipeline RAG basate su grafi di conoscenza e benchmark pubblici deterministici.

Gli autori sottolineano che CAPC non è un sostituto degli indizzatori (come graphify), ma uno strato complementare di "consegna dell'ultimo miglio" che ottimizza il costo economico della consegna del contesto derivato dall'indice a un LLM. Il costo totale di tutto il lavoro empirico descritto nel paper è stato di $98,96, dimostrando che queste scoperte sono riproducibili con risorse modeste.