Un’IA locale che scrive programmi CNC, e sa dire di no

L’idea

Scrivo e adatto programmi PAF ogni giorno: barre e piastre, profili, slot, stock e priorità. È un formato con regole precise, e molte di queste regole le conosco per esperienza più che per documentazione. L’obiettivo di PAC AI è partire da un PAF grezzo, con la geometria del pezzo, e da un’istruzione breve, come crea M4 ciechi profondità 9, e ottenere il programma finito. Tutto in locale, senza connessione.

Il formato con cui lavoro comprende P/L/C, PF, STCK, SP/FP, SLOT e SET, oltre alle priorità E e alle regole sui profili. Un vincolo preciso è che il PF associato allo STCK non va mai eliminato. È una delle regole che l’assistente deve rispettare.

Tre principi guidano il progetto:

1. La strategia la decide l’operatore. L’IA esegue e propone; ogni programma va controllato da una persona prima di andare in macchina.
2. Meglio fermarsi che indovinare. Un programma plausibile e sbagliato è peggio di un rifiuto: PACW lo apre senza lamentarsi, e il pezzo esce storto.
3. O tutto o niente. Se un’istruzione chiede tre lavorazioni e se ne sanno fare due, non se ne fa nessuna.

Il precursore: Qwen

Il progetto è partito da Qwen. La prima idea era specializzare un modello esistente con un dataset di coppie disegno → PAF e un fine-tuning LoRA/QLoRA di Qwen2.5-Coder-7B con Unsloth sulla RTX 5080.

Il limite era nel modello stesso. Qwen2.5-Coder è fatto per scrivere programmi per computer, non programmi CNC: è un modello generalista, che sa un po’ di tutto, e buona parte della sua capacità e dei suoi token se ne va in conoscenze che al PAF non servono. Per un formato così specifico conveniva un modello piccolo, addestrato solo su quello.

Accanto c’era un assistente desktop, a giugno 2026: un modello generico, Qwen2.5-Coder-14B in formato GGUF, traduceva la richiesta in una “ricetta”, cioè un blocco di righe con dei segnaposto. L’app mostrava le differenze e scriveva il file solo dopo conferma.

Ho archiviato l’assistente per due motivi. Un modello da 14 miliardi di parametri non gira a una velocità accettabile sui PC d’officina, che lavorano solo in CPU. E le ricette sapevano solo aggiungere righe in fondo al file, mentre buona parte del lavoro vero è modificare quote che ci sono già. Dell’idea ho tenuto la parte migliore: la regola per gli M4, che è diventata codice.

Un modello addestrato da zero

Da Qwen il progetto si è evoluto in PAC AI, con un modello mio, piccolo e specializzato: un transformer da circa 10 milioni di parametri, addestrato da zero sulla RTX 5080 da 16 GB. L’istruzione e il programma grezzo entrano nella stessa sequenza, così un solo modello impara a fare lavori diversi sullo stesso pezzo:

<ISTR>istruzione</ISTR><IN>programma grezzo</IN>

All’inizio il tokenizer lavorava a caratteri, circa 80 simboli. Da settembre usa un vocabolario BPE di oltre 2000 token.

Alcune cose le ho imparate a mie spese:

• Niente dati sintetici. Nei primi tentativi con coppie generate il modello ignorava l’istruzione. Ora si addestra solo su coppie reali validate.
• La loss non è il giudizio. Anche con una loss di validazione bassa, i programmi generati non sempre coincidevano con quelli attesi. Basta un carattere sbagliato e la generazione deriva. Il metro è il confronto con il programma validato.
• Un input, tanti comandi. Interrogare a fondo pochi disegni, con molte istruzioni diverse, insegna più di tanti pezzi con un solo comando.
• La cache delle chiavi e dei valori ha cambiato tutto. Senza, ogni nuovo carattere costringeva a rielaborare l’intero testo già scritto. Con la cache, un programma da 2500 caratteri si genera in pochi secondi anche in CPU, dove prima servivano minuti.

Nelle prove sui casi già visti, il modello è riuscito a riprodurre i programmi attesi. Questo però non dimostra che sappia affrontare pezzi nuovi. Con il nuovo tokenizer, le famiglie di pezzi ben rappresentate davano risultati migliori dei pezzi isolati, e a volte il modello rispondeva con il programma di un altro pezzo. Memorizza, non legge il grezzo. La generalizzazione non è dimostrata.

Il motore a regole

Da qui è nata la parte che oggi conta di più: un motore deterministico. Nessun modello e nessun LLM: le regole che ho validato diventano codice, e quello che il motore non sa fare lo dichiara, invece di inventarlo.

• Il lettore e scrittore PAF rilegge un file e lo riscrive identico byte per byte, finché non si modifica nulla. Conosce linee, archi, punti, profili, superfici, stock, righe di tecnologia, direttive e commenti; quello che non riconosce lo conserva com’è.
• Le operazioni: spostare le quote in Z o in XY, creare gli M4, spostare gli zeri pezzo, riordinare il programma, ricavare il grezzo dal disegno, le lamature.
• I conti si fanno in decimale, non in virgola mobile. Al primo giro il motore scriveva 0.010000000000000787 invece di 0.01: su un programma macchina è inaccettabile, e l’ha scoperto solo il confronto byte per byte.
• Il rifiuto funziona. Nelle prove di spostamento in Z il motore ha rifiutato un programma parametrico, dove la quota vera sta in una variabile. Spostare solo le quote scritte in chiaro avrebbe dato un programma plausibile e sbagliato.

Sulla stessa coppia, il motore produce il programma corretto in 1 ms in CPU, il modello in circa 1,5 secondi su GPU. Il motore non ripiega mai sul modello: il modello resta la risposta per le istruzioni che il motore ancora non riconosce.

Il dataset

Il dataset di PAC AI viene costruito passo passo, a partire dai programmi creati in officina e inoltrati dai cammisti. Ogni esempio mette insieme il PAF grezzo, il PAF finito e l’istruzione, scritta sempre con le stesse parole.

Per aggiungere una coppia nuova la passo a Claude, che la inserisce nel dataset con gli script del progetto e controlla che non ci siano ambiguità: due coppie con lo stesso ingresso e la stessa istruzione non possono avere risultati diversi.

L’app in officina

PAC AI è un’app WPF con tema scuro: si trascina un PAF, si scrive l’istruzione e si preme Ctrl+Invio. Dietro, un processo Python carica il modello una volta sola e risponde in JSON.

Dopo ogni elaborazione l’app apre il risultato con PACW e lo verifica in automatico, con tre esiti: corretto, errore, oppure un problema di PACW (licenza, chiave, periferica), che non è mai colpa del modello. I casi tornano indietro come feedback e diventano training solo dopo la mia revisione: per un errore entra il programma corretto, mai quello sbagliato.

Le postazioni d’officina lavorano solo in CPU: le loro schede video sono troppo vecchie per le versioni attuali di PyTorch con CUDA. Il modello addestrato sul PC fisso viene pubblicato in una cartella di rete con un numero di versione, e le postazioni si aggiornano da sole.

Aladino

Aladino porta tutto questo nel menu del tasto destro di Windows 11. Su un file .paf, .cnc o .stl compare la voce Aladino, con le azioni per generare la cartella CNC e per lanciare l’IA. È un’estensione del menu contestuale in .NET, distribuita come pacchetto MSIX, con un’app residente che controlla da sola se in rete c’è una versione più nuova.

Quando il progetto ha cambiato posizione, Aladino andava riagganciato. Ora la posizione si indica con una sola variabile d’ambiente, letta da Aladino, da PAC AI e dalla configurazione del modello.

Dopo lo spostamento Aladino funziona regolarmente su tutte le postazioni.

Prossimi passi

Sulle postazioni d’officina, in CPU, i tempi di generazione sono molto variabili: da 1 a 5 minuti per programma. Sono più lunghi dei secondi misurati sul PC fisso, e ridurli è una delle prossime cose da fare.