Nei sistemi LLM a lunga durata lo stato della conversazione cresce in fretta: a ogni turno si rimanda gran parte della history, inclusi output di tool ormai stantii, retrieval RAG ripetuti e contesto non più rilevante. Il prompt diventa un log append-only di ogni evento passato, che si continua a versare nel modello a ogni turno. Non è solo un problema di storage: come ricorda l’articolo di Emmimal P Alexander su Towards Data Science citando la letteratura, le prestazioni di reasoning degradano all’aumentare della lunghezza dell’input, anche quando il contenuto aggiunto è irrilevante, e i modelli usano peggio le informazioni sepolte a metà di un contesto lungo.
La soluzione proposta è un layer di pruning deterministico che rimuove lo stato ridondante prima che il prompt raggiunga il modello, senza chiamate a LLM, embedding o dipendenze esterne: tutto gira su dataclass, regex e lookup di dizionari, così ogni decisione è riproducibile. La troncatura posizionale (tieni gli ultimi N messaggi) non basta, perché non distingue tra contesto vecchio ed espendibile e contesto vecchio da cui un turno successivo dipende ancora.
Tre passaggi, con una rete di sicurezza
Il pruner esegue tre pass in ordine, ognuno una funzione pura. Expired Context Elimination: se un tool viene chiamato più volte con la stessa chiave, solo il risultato più recente è affidabile e i precedenti vengono rimossi. Duplicate Context Elimination: normalizza spazi e maiuscole nei documenti recuperati e tiene solo la prima occorrenza. Dependency Restoration: se i primi due pass tolgono l’unico messaggio in cui un fatto ancora referenziato era definito, questo pass lo rimette. Il meccanismo usa tag letterali DEFINE: e REF:. L’autrice è onesta sul limite: è matching di identificatori, non comprensione semantica, e non intercetta una parafrasi senza tag corrispondente.
I numeri del benchmark
Dopo aver corretto due bug (tra cui uno che rendeva il terzo pass non testato), la pipeline è stata misurata su tre workload (chat semplice, RAG assistant, tool agent) a cinque dimensioni di conversazione, per 15 configurazioni su due macchine. La riduzione dei token dipende dal workload: circa 2-4% per la chat semplice, 27-32% per il RAG assistant e 33-34% per il tool agent. In tutte le 15 configurazioni il 100% dei fatti etichettati come required è stato preservato, e il sistema raggiunge un punto fisso stabile dopo un solo pass (è idempotente). Anche a 2.000 turni e 131.000 token, il preprocessing è rimasto sotto i 50 millisecondi.
I quattro obiettivi di design chiariscono le scelte: deterministico (stesso input, stesso output), dependency-safe (non elimina mai un fatto ancora necessario), idempotente (rieseguirlo non cambia nulla, quindi è sicuro chiamarlo a ogni turno) e leggero.
In sintesi
- La proprietà più importante non è la percentuale di token risparmiati ma la garanzia di sicurezza: un pruner che salva il 4% senza mai rompere una conversazione batte uno che salva il 40% ma ogni tanto si rompe.
- Tenere il modello fuori dal pruner è una scelta: si scambia una compressione più aggressiva (come quella di LLMLingua) con determinismo e zero dipendenze.
- L’estensione naturale è un approccio ibrido: i tre pass deterministici come primo stadio sicuro, poi una compressione LLM-scored a valle, che opera solo sull’output già ripulito.
Fonte: Long Context Isn’t Free — I Built a Safe Prompt-Pruning Layer That Makes LLM Systems Work — https://towardsdatascience.com/long-context-isnt-free-i-built-a-safe-prompt-pruning-layer-that-makes-llm-systems-work/
Hai qualcosa da aggiungere? Unisciti alla discussione.