La matematica della compressione dei Prompt per LLM

Stavo facendo revisione degli esercizi per il mio libro sugli OKR. Varie run di esercizi da validare, ognuno con un prompt che descriveva contesto, obiettivi di apprendimento, vincoli, formato output. Prompt tra i 1.800 e 2.500 caratteri. Dopo la cinquantesima iterazione, Claude mi ha gentilmente informato che avevo finito i token della giornata.

Fastidioso? Sì. Ma soprattutto: era un segnale.

La sera stessa, mentre cercavo soluzioni, mi sono imbattuto in TOON (Tokens Optimization Oriented Notation). L’idea era brillante: un formato ottimizzato per gestire strutture dati ripetute nei prompt. Tipo quando devi passare liste di prodotti, cataloghi, database rows. TOON comprimeva questi pattern ripetitivi in modo sistematico, mantenendo la semantica intatta.

Nel mio caso, la situazione era ibrida: avevo le carte degli esercizi in JSON (strutture dati ripetute, perfette per TOON), più una serie di agenti che simulavano giocatori in diverse partite. Ogni partita generava un report, che veniva dato a un altro agente per analizzare cosa non funzionava.

TOON risolveva elegantemente il problema delle carte JSON. Ma gli agenti? Quelli avevano bisogno di istruzioni semantiche ripetute: “Simula un giocatore con esperienza X”, “Analizza il report cercando pattern Y”, “Genera feedback strutturato in formato Z”. Centinaia di caratteri di istruzioni che si ripetevano identiche (o quasi) ad ogni run.

Ma il principio era valido: se esiste un pattern replicabile, deve esistere un formato più efficiente.

La domanda diventa: quanto di questa prosa è effettivamente necessaria? E soprattutto: esiste un formato che mantenga la stessa qualità di output usando meno token?

Prima di buttarmi nell’esperimento, però, ho fatto i compiti a casa. Microsoft Research aveva pubblicato LLMLingua nel 2023, seguito da LLMLingua-2 nel 2024. Entrambi promettevano compressioni fino a 20× mantenendo performance. Il paper originale mostrava risultati impressionanti: compression ratios di 5-14× con degradazione minima su GPT-3.5 e Claude 1.3.

Il problema con LLMLingua? Richiedeva un piccolo modello ausiliario per la compressione, setup complessi, dipendenze Python, e – diciamocelo – chi ha tempo di integrare un’intera pipeline quando hai prompt da shippare domani? Serviva qualcosa di più immediato, manuale, pratico.

Quello che mi serviva era capire empiricamente dove stava il limite, senza algoritmi black-box. Esperimento diretto, vecchia scuola. Tre varianti dello stesso prompt, metriche chiare, e vedere dove crollava la qualità.

L’esperimento: tre livelli di compressione

Per rispondere in modo riproducibile, ho creato tre versioni dello stesso prompt. Task: scrivere un articolo di 1.000 parole sul libro “OKR The Right Way”. Non un task banale – doveva mantenere tono specifico, struttura narrativa, framework tecnici, e riferimenti bibliografici precisi. Il tipo di roba che faccio per i miei corsi, quindi sapevo esattamente cosa aspettarmi.

Variante 1: Natural Verbose (baseline)

Il prompt verbose seguiva le best practices di Anthropic: frasi complete, spiegazioni dettagliate, esempi inline, XML tags ben strutturati. Quello che trovi nella documentazione ufficiale.

Lunghezza: 2.100 caratteri
Output prodotto: 1.083 parole
Qualità: 9/10 secondo una scorecard che valutava completezza, tono, struttura e fedeltà alle istruzioni

Variante 2: Structured Optimal

Il prompt strutturato usava una notazione gerarchica con convenzioni sintattiche chiare:

SECTION:value|modifier|context per la struttura
Operatori simbolici (: assign, | separate, + AND, - exclude, ! negate)
Parole inglesi complete per migliore tokenizzazione (ci torniamo dopo)
Target quantitativi espliciti

Lunghezza: 800 caratteri (-62%)
Output: 1.013 parole
Qualità: 8.5/10

Il decremento di qualità era minimo: descrizioni leggermente meno elaborate, una citazione in meno (Sharon Bowman omessa ma il concetto “Training from the Back of the Room” preservato). Niente di critico.

Variante 3: Ultra-Minimal

Il prompt ultra-compresso spingeva l’abbreviazione al limite: acronimi aggressivi (PT:patient, DX:diagnosis), simboli matematici, rimozione di contesto esplicativo. Lunghezza: 380 caratteri (-82%).

Output: 578 parole
Problema critico: il prompt aveva richiesto esplicitamente “non meno di 1.000 parole”, ma l’output era del 42% più corto.

Ecco il cliff.

Il pattern: quando la compressione diventa lossy

I dati rivelano qualcosa che i paper accademici non enfatizzano abbastanza:

Da V1 a V2: -62% dimensione prompt, -6% qualità output = ROI eccellente
Da V2 a V3: -52% dimensione ulteriore, -40% qualità output = ROI pessimo

Esiste una soglia critica sotto la quale il modello inizia a interpretare male i requisiti. Per prompt complessi, questa soglia si colloca tra 500-600 caratteri. Sotto questo limite:

I requisiti quantitativi vengono fraintesi o ignorati
L’output diventa telegrafico invece che discorsivo
La comprensibilità del prompt stesso crolla (anche per te, quando lo rileggi dopo tre settimane)

Il punto di diminishing returns è chiaro: la compressione ottimale si attesta al 60-70% della lunghezza originale.

Questo dato è coerente con quanto trovato dal research paper su prompt compression methods, che su dataset come LongBench e GSM8K ha mostrato compression ratios ottimali tra 2× e 5× (50-80% di riduzione). Sopra il 10×, anche LLMLingua-2 con tutta la sua sofisticazione inizia a soffrire.

Anatomia del formato ottimale

Analizzando cosa funziona nella Variante 2, emerge un pattern replicabile:

CATEGORY:value|modifier|context

La struttura gerarchica usa:

Maiuscolo per sezioni (TONE, STRUCTURE, OUTPUT)
Minuscolo per proprietà (conversational, expert)
Operatori consistenti:
- : per assegnazione
- | per alternative o modificatori
- + per operazioni AND
- - per esclusioni
- ! per negazioni
- ? per trasformazioni

Esempio pratico (perché un esempio vale più di mille spiegazioni):

Verbose (247 caratteri):

You are a social media manager. Write engaging posts for LinkedIn. 
Keep them professional but not boring. Use emojis sparingly. 
Each post should be 100-150 words. Focus on B2B tech industry.
Avoid jargon and corporate speak.

Structured Optimal (97 caratteri, -61%):

SOCIAL_MEDIA:LinkedIn|B2B_tech
TONE:professional+engaging-boring|emojis_sparse
LENGTH:100-150_words|EXPLICIT_TARGET
AVOID:jargon|corporate_speak

La semantica è identica, la compressione del 61% rientra perfettamente nel sweet spot, e il formato resta “at a glance” leggibile. Non serve un dottorato per capire cosa fa.

Il prompt converter: quando il meta diventa pratico

Se il formato ottimale è replicabile, può essere automatizzato? La risposta è stata creare un “prompt converter”: un meta-prompt che trasforma prompt verbose in formato strutturato ottimale.

Il converter iniziale era lungo 1.470 caratteri e conteneva:

Regole di conversione dettagliate
Esempi di convenzioni sintattiche
Lista di cosa preservare e cosa rimuovere
Formato output atteso

Poi mi sono chiesto: e se applico il converter a se stesso? Un sistema di ottimizzazione che si auto-ottimizza dovrebbe convergere a un punto fisso o divergere caoticamente. Tipo il barber paradox, ma con più token e meno filosofia.

Risultati dell’auto-applicazione (o: scoprire i punti fissi empiricamente)

Iterazione 0 (verbose): 1.470 caratteri
Iterazione 1 (compressione manuale): 485 caratteri (-67.0%)
Iterazione 2 (auto-compressione): 478 caratteri (-67.5%)
Iterazione 3 (stimata): 475 caratteri (-67.7%)

Il sistema converge. Ogni iterazione produce miglioramento decrescente:

Iter 1?2: -7 chars (-1.4%)
Iter 2?3: -3 chars (-0.6% stimato)
Iter 3?4: -1 char (-0.2% stimato)

Il punto fisso si trova intorno ai 475 caratteri. Ulteriori iterazioni producono miglioramenti inferiori all’1%.

L’auto-applicazione non ha solo compresso, ma ha fatto refactoring intelligente:

Eliminazione ridondanze non evidenti al designer umano
Riorganizzazione logica delle sezioni
Esplicitazione di impliciti (risk_notes ? risk_notes|if_semantic_ambiguity)

Il converter ha dimostrato di “capire” le proprie regole e applicarle coerentemente anche a se stesso. Questo è un indicatore forte di design auto-consistente. E anche, ammetto, piuttosto soddisfacente da vedere.

Perché funziona: tokenizzazione e prior (la parte nerd ma importante)

Il formato structured optimal funziona meglio del previsto per due ragioni tecniche che vale la pena capire:

1. Tokenizzazione efficiente

I tokenizer basati su Byte Pair Encoding (BPE), che è quello che usano GPT, Claude, e praticamente tutti i modelli transformer moderni, sono ottimizzati per parole inglesi comuni. Le abbreviazioni ultra-compresse possono paradossalmente consumare più token:

"TONE:conv+exp-acad" ? ["TONE", ":", "conv", "+", "exp", "-", "ac", "ad"] = 8 tokens
"TONE:conversational+expert-academic" ? ["TONE", ":", "conversational", "expert", "academic"] = 5 tokens

L’uso di parole complete è controintuitivamente più efficiente. Questo è documentato anche nella ricerca di Anthropic sul prompt engineering, dove suggeriscono di evitare abbreviazioni eccessive proprio per questo motivo.

2. Prior nel training

I Large Language Models hanno visto durante il training:

File di configurazione (YAML, TOML, JSON)
Code annotations e docstrings
Notazioni matematiche e linguistiche
Markup languages strutturati

Questo significa che Claude (e GPT) hanno un prior forte per notazioni strutturate gerarchiche. Il formato non è “alieno”, è familiare al modello da milioni di esempi di training. È come parlare a qualcuno nella sua lingua madre invece che con gesti.

Applicazioni pratiche

Use case 1: Template library aziendale

Un’azienda con 50+ prompt standardizzati per vari task (code review, documentazione tecnica, customer support, content creation) può:

Convertire tutti i prompt in formato strutturato
Ridurre costi API del 60-70% per ogni chiamata
Rendere i prompt più facili da versioning (diff più chiari)
Facilitare modifiche parametriche (cambiare un valore in una struttura è più semplice che riscrivere frasi)

ROI reale: se un’azienda fa 10.000 chiamate API/mese con prompt da 2.000 caratteri, la riduzione del 65% porta a ~1.3M caratteri risparmiati/mese. In token (stima ~4 char/token) sono ~325k token/mese. A $0.003/1k tokens (input Claude Sonnet), il risparmio è ~$1/mese per prompt. Con 50 prompt diversi: ~$50/mese, $600/anno.

Il breakeven è quasi immediato se i prompt sono usati frequentemente. Non diventerete ricchi, ma neanche è aria fritta.

Use case 2: Rapid prototyping

Durante lo sviluppo di nuove applicazioni AI, i prompt vengono iterati decine di volte. Il formato strutturato permette modifiche chirurgiche:

TONE:formal ? TONE:casual
LENGTH:500_words ? LENGTH:200_words
INCLUDE:examples ? INCLUDE:examples|code_snippets

Invece di riscrivere paragrafi interi, si modificano valori precisi. Questo accelera sperimentazione e A/B testing. Ho risparmiato ore durante lo sviluppo del converter stesso proprio per questo.

Use case 3: Chain-of-thought compression

Per applicazioni che usano chain-of-thought o multi-step reasoning, ogni step ha il suo prompt. Se una pipeline ha 5 step con prompt da 1.500 caratteri ciascuno (7.500 totali), la compressione al 35% porta a 2.625 caratteri totali.

In contesti dove il budget token è limitato – tipo quando lavori con context window pieni o devi stare sotto certi limiti di latency – questo può fare la differenza tra una pipeline che funziona e una che esplode i limiti.

Il paper di ricerca su prompt compression ha dimostrato che LLMLingua-2 riduce inference time del 3-6× proprio grazie a prompt più corti. Il principio è lo stesso, solo che qui lo facciamo manualmente con risultati più prevedibili.

Use case 4: Embedded systems

Per applicazioni edge o embedded che comunicano con LLM, la dimensione del prompt trasmesso su rete conta. Un device IoT che manda telemetria con prompt di istruzioni, o un’app mobile che deve minimizzare payload, beneficia direttamente dalla compressione senza perdita qualitativa.

Non è il caso d’uso più comune, ma quando serve, serve davvero.

Limiti e controindicazioni (perché l’onestà paga sempre)

Il formato strutturato non è universalmente superiore. Ci sono casi dove NON dovresti usarlo:

Quando NON usarlo

Documenti legali o medici: La precisione assoluta richiede linguaggio naturale completo e non ambiguo. Ogni parola può avere peso legale. Il risparmio di token non vale il rischio di ambiguità semantica. Seriamente, non fatelo.

First-time learning: Se un team sta imparando a usare prompt engineering, il formato verbose con spiegazioni estese è didatticamente superiore. Il formato strutturato richiede comprensione delle convenzioni. Insegna con il verbose, ottimizza con lo structured.

Prompt one-shot rarissimi: Se un prompt viene usato una volta sola, il tempo di conversione (10-15 minuti) non vale il risparmio di token di una singola chiamata. Economics 101.

Task creativi molto aperti: Quando serve massima espressività e sfumature emotive/tonali complesse, il linguaggio naturale offre più granularità. Il formato strutturato eccelle per task tecnici con requisiti chiari, non per scrivere poesia.

Il trade-off documentazione

Un prompt strutturato da 500 caratteri è meno auto-documentante di uno verbose da 1.500. Per sistemi condivisi tra team, serve:

Documentazione separata che spiega le convenzioni
Changelog delle modifiche
Esempi di utilizzo

Questo overhead organizzativo va considerato nel ROI totale. Non è gratis, anche se i token lo sono di più.

Il caso particolare: image generation prompts

Mentre preparavo l’immagine di copertina per questo articolo, ho fatto una scoperta meta-ironica: i principi di compressione ottimale per text LLM non si applicano agli image generators.

Ho testato tre versioni del prompt per generare una cover in stile Commodore 64 pixel art:

Structured Optimal (1.456 chars): notazione gerarchica come nell’articolo
Natural Efficient (589 chars): linguaggio naturale scorrevole
Ultra-Minimal (187 chars): abbreviazioni aggressive

Risultato? La Version 2 (natural efficient) ha prodotto i risultati migliori con DALL-E e Midjourney. La notazione strutturata ultra-ottimizzata confondeva i modelli – probabilmente perché il loro training set include principalmente descrizioni in linguaggio naturale, non notazioni tecniche strutturate.

STRUCTURED: "COMPOSITION:split_screen|before_after LEFT_SIDE:verbose_text_wall|..."
? Confuso, interpretazione literale delle pipe e dei due punti

NATURAL: "Split screen composition: left side shows verbose text..."
? Perfetto, interpreta correttamente la scena

Takeaway: I principi di compressione sono domain-specific. Per text instruction prompts (Claude, GPT), la notazione strutturata è ottimale. Per image generation prompts, il linguaggio naturale scorrevole ma conciso rimane superiore.

Questo ha senso: i text LLM devono processare istruzioni complesse e lunghe chain-of-thought, dove la struttura aiuta. Gli image generators devono tradurre descrizioni visive, dove la fluidità narrativa è più importante della compressione estrema.

Una lezione nell’umiltà: non esiste un formato universalmente ottimale. Il contesto conta sempre.

Convergenza e punti fissi

L’esperimento di auto-applicazione ha rivelato una proprietà interessante: il sistema converge a un punto fisso. Non è magia, è information theory.

Per un task generico di “prompt optimization” con regole complete, il punto fisso è ~475 caratteri. Questo non è arbitrario: rappresenta il minimo informazionale necessario per codificare:

Ruolo e obiettivo (50 char)
Regole di trasformazione (150 char)
Convenzioni sintattiche (100 char)
Output atteso (75 char)
Constraints (100 char)

Sotto questa soglia, la perdita semantica inizia. Sopra questa soglia, c’è ridondanza estraibile.

La velocità di convergenza segue una legge esponenziale decrescente: ogni iterazione riduce il miglioramento del ~60%. Questo suggerisce che 2-3 iterazioni sono sufficienti per raggiungere il 95% dell’ottimizzazione possibile.

Questo pattern è consistente con quanto Claude Shannon aveva già teorizzato negli anni ’40 sulla compressione ottimale: esiste un limite teorico oltre il quale stai comprimendo rumore invece che ridondanza. Un ottimo articolo sul tema collega Shannon information theory ai modern LLM prompts in modo molto chiaro.

Pattern replicabili

Dall’esperimento emergono pattern generalizzabili che puoi usare da domani:

Pattern 1: Gerarchia esplicita

TOP_LEVEL:
  sub_property:value
  another_property:value|modifier

Meglio di strutture piatte o implicite. I modelli “capiscono” la gerarchia.

Pattern 2: Operatori consistenti

Non inventare sintassi custom ogni volta. Usa convenzioni riconoscibili:

: per “è”
| per “oppure/o anche”
+ per “e”
- per “ma non”
! per “negazione/assenza”
? per “diventa/trasforma in”

La consistenza conta più della perfezione teorica.

Pattern 3: Target espliciti

BAD:  OUTPUT:long_article
GOOD: OUTPUT:1500-2000_words|EXPLICIT_TARGET

I numeri non vanno mai compressi o approssimati. Questo l’ho imparato nel modo difficile con la Variante 3.

Pattern 4: Liste brackettate

CHECKS:[SQL_injection|XSS|CSRF|authentication|authorization]

Invece di elenchi puntati in prosa. Più compatto, più chiaro.

Pattern 5: Negazioni su antipattern

AVOID:!input_validation|!error_handling|hardcoded_credentials

Il ! davanti indica “mancanza da evitare” vs “presenza da evitare”. Subtle ma importante.

Direzioni future

Questo esperimento apre diverse direzioni che mi piacerebbe esplorare:

1. Domain-specific compression dictionaries

Per domini specifici (medical, legal, finance), creare dizionari di abbreviazioni standard. Esempio medicina:

PT:patient|SX:symptoms|DX:diagnosis|TX:treatment

Con glossario condiviso, la compressione può raggiungere 80% mantenendo precisione. Servirebbero però esperti del dominio per validare.

2. Hybrid prompting

Sezioni critiche verbose + sezioni tecniche strutturate:

CONTEXT: [prosa naturale con sfumature importanti]

TECHNICAL_SPECS:
  format:JSON
  fields:[name|age|diagnosis|treatment_plan]
  validation:strict_schema

Best of both worlds. Sto testando questo approccio su alcuni progetti e sembra promettente.

3. Prompt compilation

Tool che prendono prompt verbose con annotazioni e compilano automaticamente in formato ottimale, simile a compilatori per linguaggi di programmazione:

# @target: structured-optimal
# @compression: 65%
# @preserve: examples, tone_markers

You are a code reviewer...
[resto del prompt verbose]

Output compilato automaticamente con metriche e warning. Tipo TypeScript per prompts.

4. Adaptive compression

Sistema che monitora quality metrics degli output e adatta dinamicamente il livello di compressione:

Se quality score > 0.95: aumenta compressione del 5%
Se quality score < 0.85: riduci compressione del 5%

Trova automaticamente il punto ottimale per ogni task. Questo richiederebbe però un feedback loop robusto, che non è banale da implementare.

Conclusioni empiriche

I dati raccolti permettono conclusioni quantitative:

Esiste un sweet spot: 60-70% di compressione con <10% perdita qualitativa
Il cliff è reale: Sotto il 30% della lunghezza originale, la qualità crolla >40%
Convergenza prevedibile: Auto-ottimizzazione converge in 2-3 iterazioni
ROI immediato: Per prompt usati >10 volte, il breakeven è garantito
Formato stabile: Structured English Notation è ottimale per tokenizer BPE

Il linguaggio naturale verbose ha circa 65% di ridondanza quando usato per istruzioni tecniche a LLM. Quella ridondanza è utile per umani (chiarezza, documentazione, insegnamento) ma costosa per macchine.

Il formato strutturato ottimale non è un metalinguaggio esoterico, ma una notazione familiare ai modelli dal training. È leggibile dagli umani “at a glance” e processabile efficientemente dalle macchine.

La compressione non è solo risparmio economico, ma design migliore: prompt più chiari, modificabili, versioning più facile, meno ambiguità. Il constraint di spazio forza precisione. Come diceva Antoine de Saint-Exupéry: “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”

Solo che lui parlava di aerei e io di prompt. Ma il principio regge.

Riferimenti e letture consigliate

Per approfondire il tema della prompt compression e le tecniche correlate:

LLMLingua & LLMLingua-2 (Microsoft Research): Paper originale su compression methods e articolo tecnico su LLMLingua-2
Anthropic Prompt Engineering Guide: Documentazione ufficiale con best practices e prompt improver
Claude Shannon e information theory applicata a LLM: Ottimo articolo divulgativo
PromptHub research: Analisi pratica su risparmio costi

Materiali e riproducibilità

L’esperimento completo include:

Tre varianti di prompt con metriche comparative
Output generati da ciascuna variante
Scorecard di valutazione qualitativa
Prompt converter auto-applicato con traccia di convergenza
Test su prompt reali (code review, social media, technical writing)

Il formato structured optimal proposto non è proprietario o brevettato – è una convenzione aperta che chiunque può adottare e adattare.

Il converter è disponibile su GitHub per sperimentazione.

Chi volesse replicare può iniziare con un singolo prompt ad alto utilizzo, convertirlo manualmente seguendo i pattern descritti, testare side-by-side con la versione verbose, e misurare il delta qualitativo e il risparmio token.

La matematica della compressione, in questo caso, non mente: c’è un punto di equilibrio reale, misurabile, replicabile. E quel punto si trova molto più in là di quanto la maggior parte dei praticanti attualmente utilizzi.

Note: Questo articolo è basato su test empirici condotti con Claude Sonnet 4.5 nel novembre 2025. I risultati specifici (percentuali, punti fissi) possono variare con altri modelli o versioni future, ma i principi generali (esistenza di un sweet spot, legge dei diminishing returns, convergenza) dovrebbero mantenersi validi per architetture transformer-based con tokenizer BPE