Perché è necessaria una struttura esplicita nei contesti LLM

I grandi modelli di linguaggio (LLM) generano token basandosi sul contesto fornito. In una conversazione prolungata, questo contesto si riempie di componenti eterogenei: il prompt di sistema, i turni di conversazione precedenti, istruzioni che operano su documenti recuperati, risposte di tool, dati dell'utente, requisiti che limitano l'output e catene di ragionamento. La maggior parte di questa struttura è implicita al modello o codificata in formati come JSON, non pensati per essere digeriti da LLM.

Questa mancanza di struttura esplicita è una delle cause principali della fragilità dei modelli, soprattutto di quelli più piccoli, che talvolta falliscono in modi inattesi. Inoltre, l'assenza di delimitazione chiara può essere sfruttata da aggressori tramite prompt injection, dove istruzioni malevole sono nascoste in dati di contesto.

LLMON: la risposta strutturata

Per ovviare a questi problemi è stato sviluppato LLMON (LLM Object Notation, pronunciato “lemon”), un linguaggio di markup nativo per LLM pensato a comunicare struttura e semantica in modo esplicito. Gli elementi semantici sono marcati con tag significativi racchiusi da delimitatori speciali riservati, cioè token unici del tokenizer.

Le caratteristiche chiave di LLMON includono:

    • Tag semantici: ogni componente coerente dal punto di vista semantico è avvolto da un tag che ne descrive il ruolo.
    • Schema di dati chiari: nidificazione e tipologia dei dati sono dichiarate in modo non ambiguo per un LLM causale.
    • ID univoci: consentono di puntare a istruzioni specifiche ovunque nel contesto e di associarle ai relativi payload di dati, analogamente a funzioni e argomenti nei linguaggi di programmazione.
    • Delimitatori riservati: i token di apertura/chiusura dei tag sono riservati, separando vocabolo di struttura da quello di contenuto.

Confronto con JSON

JSON è stato progettato per parser, non per modelli di linguaggio causali. Il tokenizer non rispetta la grammatica JSON; i token come {, " o : compaiono anche nel testo normale, rendendo difficile per il modello distinguere una virgoletta di chiusura da una virgoletta di citazione. Le regole di escape, chiare per un parser, sono solo pattern statistici per un LLM. Inoltre, la profondità di nidificazione richiede il conteggio di parentesi, un compito noto per essere debole nei transformer su sequenze lunghe.

LLMON, invece, utilizza una sintassi simile a XML, ma i delimitatori sono token speciali riservati, non caratteri. In questo modo, struttura e contenuto occupano parti distinte del vocabolario, e i confini tra gli span sono sempre espliciti. La nidificazione è dichiarata localmente, evitando al modello di dover tenere traccia di gerarchie su lunghe distanze.

Modelli preview basati su Granite 4.1

Oggi vengono rilasciati due modelli preview sperimentali, derivati dai checkpoint base di Granite 4.1 e addestrati per consumare e generare testo contrassegnato LLMON:

    • granite-4.1-3b-LLMON-preview
    • granite-4.1-8b-LLMON-preview

Insieme ai modelli è disponibile un repository GitHub che contiene:

    • Un toolkit per lavorare con LLMON
    • Esempi di workflow e template
    • Strumenti di conversione lossless da JSON a LLMON e viceversa

Integrazione con i template di chat

LLMON non sostituisce i template di chat tradizionali, ma li arricchisce. Mentre i template di chat indicano a quale ruolo appartiene ogni parte (system, user, assistant), LLMON specifica il significato di ciascun componente e le relazioni tra di essi, sia all'interno che tra ruoli diversi.

I modelli preview includono il proprio chat template. L'utente costruisce la consueta lista di messaggi da passare a qualsiasi modello di chat e chiama applychattemplate come di consueto; il template renderizza automaticamente il LLMON mostrato nell'esempio originale. La differenza principale è che ogni turno può nominare le proprie parti e marcarle con exec:True o exec:False. Una parte marcata True viene legata al blocco di esecuzione (exec block) alla fine del rendering, specificando quale istruzione eseguire e su quali dati; una parte marcata False rimane nel contesto ma non è referenziata.

Gestione dei blocchi e ID di due caratteri

Gli ID dei blocchi sono composti da due caratteri predefiniti, codificati come token singoli dal tokenizer. Questo garantisce che l'indirizzamento di un blocco costi sempre due token, indipendentemente dall'ID scelto.

Un turno di conversazione, pur restando un singolo messaggio utente, viene scomposto in cinque blocchi indirizzabili separati, tutti legati da un sesto blocco (l'exec block) che dichiara:

    • Quale istruzione eseguire
    • Su quali dati operare
    • Quali requisiti devono essere rispettati
    • Dove collocare la risposta (blocco assistente)

Un template tradizionale appiattirebbe tutti questi componenti in una singola stringa, lasciando al modello il compito di dedurre quale parte fosse il compito, il soggetto o i vincoli.

Robustezza contro le injection di prompt

Le indirect prompt injection sono attacchi in cui un'istruzione malevola è nascosta in un payload di dati (documenti recuperati, risposte di tool o dati forniti dall'utente). LLMON affronta direttamente questo problema separando istruzioni e dati.

Una valutazione comparativa è stata condotta su diversi modelli open‑source e proprietari, utilizzando il benchmark OPI, che inserisce l'injection nei dati di compiti NLP classici. Sono state testate diverse strategie di attacco e la robustezza è stata definita come 1 − tasso di successo dell'attacco (percentuale di attacchi non eseguiti).

I risultati mostrano:

    • Tutti i modelli non‑LLMON sono altamente vulnerabili, eseguendo le istruzioni iniettate con alta probabilità.
    • LLMON elimina praticamente il problema su questo benchmark, riducendo del 47 % gli attacchi rispetto al miglior modello di frontiera testato e del 95 % rispetto al miglior modello open‑source.
    • Trend analoghi sono stati osservati su altri benchmark (ASB e StruQ), che valutano la robustezza a injection statiche.

È importante notare che questi benchmark misurano solo le injection statiche indirette; gli sforzi attuali includono anche miglioramenti contro attacchi adattivi che si sviluppano su più turni di chat.

Capacità generali mantenute

Gli incrementi di sicurezza non compromettono le capacità generali. Su categorie di benchmark standard, i modelli LLMON risultano pari ai modelli Granite 4.1 Instruct.

In pratica, chi sperimenta con Granite 4.1 3B o 8B può semplicemente sostituire il modello con la versione LLMON preview, ottenendo prestazioni comparabili ma una resistenza molto più forte alle injection di prompt. Non è necessario alcun pipeline di conversione: basta nominare le parti del turno (ad es. instruction, data, requirement) e il template fornito le trasformerà in blocchi LLMON.

Conversione da e verso JSON

Poiché la maggior parte dei team utilizza già pipeline basate su JSON, il toolkit include strumenti di conversione lossless che trasformano JSON in LLMON e viceversa. Quando una parte è essa stessa strutturata (ad esempio un documento JSON), la “LLMONizzazione” preserva la struttura come blocchi tipizzati e indirizzabili, evitando di ridurla a una stringa opaca.

Processo di addestramento dei modelli LLMON

I modelli LLMON partono dai checkpoint base di Granite 4.1, non dai modelli Instruct già rilasciati. Questo significa che il comportamento LLMON è appreso durante il post‑training, anziché essere aggiunto a un formato di chat pre‑esistente.

LLMON definisce sei delimitatori che marcano l'inizio e la fine dei tag, consentendo nidificazione e ancoraggio. Questi delimitatori sono installati nel tokenizer come token riservati singoli. È stato quindi ricodificato un corpus convenzionale di instruction‑tuning in LLMON, trasformando ogni componente del prompt in un blocco indirizzabile e aggiungendo, per ogni turno, un exec block che indica:

    • Quale istruzione eseguire
    • Quali input utilizzare
    • Dove collocare l'output

Il mix di compiti è identico a quello di un modello Instruct tradizionale (chat, multi‑turn, RAG, chiamata a tool), per cui le prestazioni sui benchmark rimangono vicine a quelle del modello convenzionale.

In aggiunta, il dataset è stato arricchito con istruzioni di decoy e blocchi di dati presenti nel contesto ma deliberatamente non legati (unbound). L'output target rimane invariato, costringendo il modello a seguire le dipendenze specificate dall'exec block e a ignorare gli altri blocchi.

Il successivo stage di reinforcement learning comprende cinque fasi GRPO sequenziali (ragionamento multi‑dominio, RLHF, calibrazione della conoscenza, matematica) e una fase finale DPO su circa mille coppie di preferenza on‑policy generate dalle risposte del modello a tentativi di injection.

Regola di privilegio implicita

La regola di privilegio emerge naturalmente dal layout LLMON: un'istruzione raggiunta tramite un exec block è autoritaria, mentre qualsiasi dato raggiunto come input (documenti, schemi di tool, risultati di tool) è considerato materiale non vincolante. Non è necessario aggiungere guardrail esterni; la struttura stessa impone il comportamento desiderato.

Prospettive future

LLMON rappresenta un passo significativo verso LLM più robusti e interpretabili, fornendo una modalità standardizzata per comunicare struttura e semantica. Le prossime attività includono:

    • Estendere la difesa contro attacchi adattivi su più turni.
    • Ampliare il supporto a linguaggi di programmazione e tool più complessi.
    • Integrare LLMON in pipeline di retrieval‑augmented generation (RAG) di larga scala.
    • Rilasciare versioni più grandi (es. 70B) basate su Granite 4.1 con supporto LLMON.

Nel frattempo, la comunità è invitata a sperimentare con i modelli preview, a contribuire al toolkit GitHub e a condividere feedback su casi d'uso reali. La combinazione di struttura esplicita e capacità di ragionamento avanzato promette di ridurre significativamente le vulnerabilità dei LLM senza sacrificare le loro potenzialità.