Un modello da 800 mila parametri risolve Sudoku difficili: cosa insegna Lattice Deduction Transformer
LDT combina ricorrenza e vincoli logici per risolvere benchmark di Sudoku. Il risultato è forte, ma non è una prova che i modelli piccoli sostituiscano gli LLM generali.
Scritto da Daniel Vedovato · Revisionato il 22 luglio 2026
Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.
Un benchmark stretto, un risultato molto netto
Il paper Lattice Deduction Transformers presenta un transformer ricorrente progettato per problemi a vincoli. La variante da circa 800 mila parametri raggiunge, secondo gli autori, il 100% su Sudoku-Extreme e Snowflake Sudoku. Una variante da 1,8 milioni arriva al 99,9% su Maze-Hard. Nello stesso esperimento, i frontier LLM citati dagli autori ottengono zero sui tre benchmark. È un confronto che merita attenzione proprio perché non premia la scala generica: premia un’architettura costruita per mantenere deduzioni coerenti.
Il modello, chiamato LDT, non risolve il puzzle come un chatbot che produce una spiegazione persuasiva. Applica più passaggi ricorrenti e proietta lo stato latente attraverso una struttura a reticolo. L’obiettivo dichiarato è avvicinarsi a una deduzione logicamente corretta: il sistema dovrebbe restituire una soluzione valida oppure astenersi. Addestramento e supervisione imitano un solver a ricerca, usando un’approssimazione basata su interpretazione astratta dell’insieme delle soluzioni candidate.
Perché il Sudoku non è un test banale
Un Sudoku difficile richiede di mantenere vincoli globali. Una cifra scelta in una cella restringe righe, colonne e regioni; una decisione locale errata può invalidare l’intera griglia. Questo rende il problema utile per osservare coerenza e capacità di astensione. Non lo rende però una copia in miniatura del ragionamento umano, della programmazione o della pianificazione nel mondo reale. Il dominio è chiuso, le regole sono fisse e la risposta corretta è verificabile automaticamente.
La lezione non è quindi “un modello piccolo batte sempre un LLM”. È che un modello generico può essere valutato su un compito dove non possiede la rappresentazione o il ciclo di verifica adeguato. Se un prodotto ha vincoli espliciti e un verificatore disponibile, vale la pena confrontare un sistema specializzato con una richiesta in linguaggio naturale a un modello enorme. Il costo, la latenza e la prevedibilità potrebbero favorire il primo.
Cosa controllare prima di generalizzare il risultato
Un benchmark va letto insieme al protocollo. Bisogna chiedersi come sono costruiti train e test, se le istanze sono indipendenti, quanta ricerca esterna viene incorporata nell’addestramento e in quali condizioni il modello si astiene. L’accuratezza del 100% è impressionante, ma non dice da sola quanto sia robusto il sistema a regole leggermente diverse, input malformati o vincoli aggiunti dopo il training.
Per un team tecnico, un test responsabile può usare un problema interno con soluzione controllabile: assegnazione di risorse, configurazione di compatibilità, pianificazione con vincoli o validazione di formule. Si definiscono prima esempi facili e casi limite, un verificatore indipendente e una soglia per l’astensione. La comparazione utile include un solver tradizionale, una pipeline LLM con tool e il modello specializzato. Senza questa baseline, un punteggio isolato rischia di guidare una scelta architetturale sbagliata.
Dove il risultato può essere utile
LDT suggerisce una direzione interessante per sistemi che devono rispettare proprietà formali, non soltanto produrre testo plausibile. Un componente ricorrente e piccolo può affiancare un LLM: il modello linguistico interpreta la richiesta, il componente vincolato controlla o cerca soluzioni, e un verificatore decide se l’output è accettabile. Questo schema separa linguaggio, calcolo e responsabilità. Non richiede di attribuire al chatbot una sicurezza che non può dimostrare.
Resta essenziale evitare un salto narrativo. Il paper non dimostra capacità generale, coscienza, né superiorità su tutti i task di reasoning. Dimostra risultati in benchmark definiti dagli autori. È già abbastanza per una domanda concreta: invece di aumentare sempre la dimensione del modello, quali parti del problema possiamo rendere esplicite, verificabili e specializzate? In molte applicazioni quella domanda produce più valore di una gara di parametri.
Un criterio di adozione più utile dei parametri
Prima di scegliere una soluzione, un team può formulare quattro domande. Il problema ha regole stabili? Esiste un modo indipendente per verificare l’output? L’errore è recuperabile? Il costo di progettare un componente specializzato è inferiore al costo di correggere risposte generiche? Quando le risposte sono in gran parte sì, un approccio come LDT merita un prototipo. Quando il contesto cambia continuamente e le regole non sono esprimibili, un componente vincolato può invece essere troppo rigido.
Questa distinzione aiuta anche la comunicazione verso gli utenti. Un sistema può dichiarare: “ho verificato questi vincoli” invece di suggerire una confidenza indifferenziata. L’astensione è allora un risultato utile, non un difetto da nascondere. È una proprietà importante per trasformare un buon benchmark in una funzione affidabile.
È una lezione di progettazione concreta, non soltanto un risultato da riportare come record tecnico.