Dal linguaggio naturale a un modello CAD realmente utilizzabile
Descrivere un componente meccanico a parole e ottenere in risposta un modello tridimensionale pronto per essere controllato, modificato ed eventualmente stampato in 3D è uno degli obiettivi più interessanti dell’intelligenza artificiale applicata alla progettazione.
Il problema è che generare un’immagine tridimensionale e generare un modello CAD sono due attività molto diverse.
Un sistema text-to-3D orientato alla grafica può produrre una forma visivamente plausibile senza necessariamente rispettare un diametro di 20 millimetri, la posizione esatta di quattro fori, lo spessore di una parete o la necessità che tutte le parti formino un singolo solido chiuso.
Nel CAD queste caratteristiche non sono dettagli secondari.
Una staffa destinata alla produzione deve possedere dimensioni precise. Un foro deve attraversare realmente il componente. Due elementi che devono essere uniti non possono limitarsi ad apparire collegati nell’immagine. Un modello destinato alla stampa 3D deve inoltre essere geometricamente valido e trasformabile in una mesh utilizzabile dallo slicer.
È in questo contesto che si colloca MAC, acronimo di Multi-Agent CAD, progetto open source sviluppato nell’ambiente dell’Interactive Embodied Intelligence Lab della Tsinghua University.
Gli autori indicati dal progetto sono Guanxing Qu e Xueyan Zou.
MAC affronta il text-to-CAD con un’idea apparentemente semplice: invece di chiedere a un singolo agente AI di comprendere la richiesta, progettare la geometria, ricordare la documentazione CAD, scrivere codice, interpretare gli errori e correggersi più volte, il lavoro viene suddiviso tra componenti specializzati.
Il risultato dichiarato dagli sviluppatori è una riduzione molto marcata del numero di token necessari durante la generazione.
Il problema non è soltanto creare il modello, ma continuare a ragionarci sopra
I sistemi CAD basati su grandi modelli linguistici funzionano spesso attraverso un ciclo iterativo.
L’utente descrive il componente.
Il modello linguistico genera codice CAD.
Il codice viene eseguito.
Se l’esecuzione fallisce, l’errore viene restituito al modello.
Il modello deve leggere nuovamente il problema, capire il messaggio di errore, consultare le istruzioni relative alla libreria utilizzata e generare una correzione.
Il ciclo può ripetersi diverse volte.
Questo approccio funziona, ma presenta una caratteristica costosa: il contesto tende a crescere.
Ad ogni iterazione possono accumularsi la richiesta originale dell’utente, la documentazione della libreria CAD, il codice prodotto precedentemente, i messaggi del sistema, gli stack trace, i tentativi falliti e le correzioni.
Anche quando un’informazione è già stata analizzata, un agente monolitico può essere costretto a rileggerla nelle iterazioni successive.
Il progetto MAC nasce principalmente per eliminare questa ridondanza.
Gli autori descrivono infatti il punto centrale dell’architettura non semplicemente come “multi-agent”, ma come compressione dell’informazione tra uno stadio e il successivo.
Quattro ruoli invece di un unico agente
MAC organizza la generazione attraverso quattro stadi principali.
Il primo è lo Spec Planner.
Questo componente riceve la richiesta dell’utente e la trasforma in una rappresentazione strutturata chiamata CADBrief.
Se l’utente scrive, per esempio, di voler creare una flangia circolare da 80 millimetri di diametro, spessa 10 millimetri e dotata di un foro passante centrale da 30 millimetri, lo Spec Planner estrae le informazioni rilevanti e le organizza in dati che possano essere elaborati dalle fasi successive.
Non deve ancora costruire il componente.
Deve capire cosa deve essere costruito.
Il secondo agente è il Geometric Architect.
Il suo compito consiste nel trasformare il CADBrief in un vero piano geometrico.
Vengono definite le geometrie bidimensionali iniziali, i piani di lavoro, le operazioni di estrusione o rotazione, i fori, le operazioni booleane, gli eventuali pattern, le simmetrie e altre caratteristiche della parte.
L’output di questa fase prende il nome di ArchitectPlan.
A questo punto la descrizione iniziale dell’utente non deve continuare a viaggiare integralmente attraverso tutto il sistema.
Il Geometric Architect riceve soprattutto le informazioni strutturate di cui ha bisogno.
Il terzo stadio trasforma il progetto in Python
Dopo la pianificazione geometrica entra in funzione il Python Coder.
MAC utilizza build123d, una libreria CAD parametrica basata su Python e sul kernel geometrico Open Cascade.
A differenza di un generatore che produce semplicemente una mesh triangolare, build123d permette di costruire geometrie BREP attraverso operazioni tipiche della modellazione solida.
È possibile creare schizzi, estrudere profili, effettuare rivoluzioni, tagliare solidi, realizzare raccordi, smussi, fori e pattern.
Il risultato può quindi essere esportato come STEP e successivamente come STL per la produzione additiva.
Una caratteristica interessante di MAC è che anche in questa fase gli sviluppatori hanno cercato di non affidare necessariamente ogni operazione a un modello linguistico.
Il sistema utilizza prima un traduttore deterministico che prova a trasformare l’ArchitectPlan direttamente in istruzioni build123d.
Operazioni comuni come estrusione, foratura, unione o sottrazione booleana, pattern lineari e circolari, specchiatura, raccordo e smusso possono essere elaborate attraverso questa logica.
Il modello linguistico viene chiamato soprattutto quando il traduttore incontra qualcosa che non è in grado di gestire direttamente.
Questo approccio è importante perché una riga di codice prodotta attraverso una regola deterministica non richiede un’altra inferenza AI.
Aider interviene quando il codice deve essere riparato
Per i passaggi non gestiti direttamente e per la correzione degli errori MAC utilizza anche Aider.
Aider è uno strumento open source per la programmazione assistita da modelli linguistici e può modificare direttamente file di codice.
Nel workflow di MAC riceve informazioni mirate sugli errori da correggere e una documentazione relativa a build123d.
Il principio rimane coerente con il resto dell’architettura: Aider non deve necessariamente rileggere tutta la storia della conversazione per capire che un raccordo non è riuscito.
Può ricevere il codice interessato, il risultato del controllo e le informazioni necessarie alla riparazione.
La differenza sembra piccola, ma ripetuta attraverso decine o centinaia di chiamate può modificare in modo sostanziale il consumo complessivo di token.
Il quarto agente controlla se la geometria è realmente corretta
Generare codice che non produce errori non significa necessariamente aver generato il componente richiesto.
Un programma Python può essere perfettamente eseguibile e produrre comunque una geometria sbagliata.
Per questo motivo MAC contiene un Autonomous Skill Loop dedicato alla verifica e alla riparazione.
Il modello prodotto viene analizzato in due rappresentazioni.
Un primo motore esamina il file STEP e la sua topologia.
Un secondo controllo lavora sulla mesh STL.
Il sistema verifica aspetti come le dimensioni complessive, la presenza di un unico corpo quando richiesta e la chiusura della geometria.
Il workflow include inoltre controlli sulla connettività e strumenti diagnostici destinati a identificare operazioni che non hanno avuto l’effetto previsto.
Se un foro avrebbe dovuto attraversare una parete ma il volume di taglio non ha intersecato correttamente il solido, il sistema può registrare l’anomalia.
Lo stesso principio viene utilizzato per raccordi e smussi che falliscono durante l’esecuzione.
Il modello viene corretto senza ricominciare da zero
Quando il controllo rileva un errore, MAC costruisce una richiesta di riparazione.
Aider riceve il codice insieme alle informazioni ottenute dal controllo geometrico e prova a modificarlo.
Il modello viene quindi generato nuovamente e sottoposto a un altro controllo.
L’Autonomous Skill Loop può effettuare più iterazioni.
La versione documentata dagli sviluppatori prevede fino a cinque cicli esterni di riparazione e ulteriori tentativi per risolvere errori di esecuzione del codice.
L’utente può anche intervenire durante il ciclo.
Nell’interfaccia da terminale esiste un checkpoint che consente di continuare automaticamente, aggiungere una nuova richiesta di modifica oppure interrompere il processo conservando gli artefatti generati fino a quel momento.
Questa caratteristica avvicina MAC a un workflow di progettazione iterativa piuttosto che a un semplice generatore “prompt in, file out”.
Perché il passaggio di stato riduce i token
Il dato che attira maggiormente l’attenzione riguarda il consumo di token.
Per comprenderlo è necessario osservare cosa viene trasmesso tra i diversi agenti.
Lo Spec Planner produce un oggetto strutturato.
Il Geometric Architect riceve quell’oggetto e restituisce un altro piano strutturato.
Il Coder lavora sul piano geometrico.
Il sistema di riparazione riceve principalmente codice, documentazione necessaria e risultati del controllo.
Non esiste quindi l’obbligo di far rileggere ad ogni componente l’intera conversazione accumulata.
LangGraph, sviluppato nell’ecosistema LangChain, viene utilizzato per orchestrare questo flusso a stati.
LangGraph è progettato proprio per costruire workflow nei quali differenti nodi elaborano e modificano uno stato condiviso attraverso percorsi controllabili.
Nel caso di MAC questa caratteristica viene sfruttata per far passare informazioni strutturate da un agente al successivo.
103,95 milioni di token contro 896.340
Gli sviluppatori hanno confrontato MAC con CAD Skills, il progetto open source text-to-CAD di earthtojake utilizzato come baseline.
Il benchmark comprende dieci richieste di generazione CAD e 141 caratteristiche geometriche da verificare.
Per rendere il confronto più significativo, gli autori dichiarano di aver utilizzato lo stesso modello linguistico per entrambi i sistemi: Qwen 3.7-max attraverso DashScope di Alibaba Cloud.
La baseline CAD Skills ha utilizzato complessivamente 103.950.189 token.
MAC ne ha utilizzati 896.340.
Il rapporto è di circa 116 a 1.
Il dato non significa che qualsiasi progetto CAD realizzato con MAC consumerà sempre esattamente 116 volte meno token rispetto a qualsiasi altra soluzione.
Descrive il risultato ottenuto su quello specifico benchmark, con quella configurazione e quel modello linguistico.
La differenza è comunque sufficientemente ampia da mettere in evidenza il peso che l’organizzazione del contesto può avere sui costi di un sistema agentico.
Anche le chiamate API scendono da 1.307 a 50
Il numero di token non è l’unica differenza misurata.
La baseline ha effettuato 1.307 chiamate API complessive.
MAC ne ha effettuate 50.
La riduzione è quindi superiore a 26 volte.
Anche il costo dichiarato dal progetto cambia in modo significativo.
Il benchmark utilizza valori in yuan cinesi: la baseline arriva a 125,69 CNY, mentre MAC si ferma a 9,67 CNY.
Il rapporto è di circa 13 a 1.
La riduzione economica è minore rispetto alla riduzione dei token perché il costo effettivo di un’inferenza non dipende soltanto dal numero totale di token: input, output e token letti dalla cache possono avere prezzi differenti a seconda del servizio utilizzato.
Nel test della baseline, una quota molto elevata dei token deriva proprio dalla rilettura della cache.
L’efficienza non sembra compromettere il risultato del benchmark
La riduzione delle risorse sarebbe poco interessante se comportasse un forte peggioramento della geometria.
Nel test dichiarato dagli sviluppatori, però, questo non è avvenuto.
CAD Skills ha superato 138 delle 141 caratteristiche geometriche prese in esame, corrispondenti al 97,9%.
MAC ne ha superate 140, raggiungendo il 99,3%.
La differenza assoluta è piccola, ed è importante non trasformarla in una dimostrazione generale di superiorità.
Dieci modelli rappresentano un campione limitato.
Il benchmark mostra però che, almeno su quelle prove, la riduzione del contesto non ha prodotto una perdita evidente di accuratezza geometrica.
Gli stessi autori specificano inoltre che la baseline originale di CAD Skills era stata utilizzata in altri contesti con modelli differenti. Per il loro confronto hanno eseguito entrambi i sistemi con Qwen 3.7-max in modo da isolare maggiormente l’effetto dell’architettura.
Da una semplice piastra a un riduttore planetario
Le dieci prove non si limitano a cubi e cilindri.
Il set comprende un blocco rettangolare con quattro fori passanti, una flangia, una staffa a L, un albero a gradini e un contenitore aperto.
I modelli più complessi includono una staffa aerospaziale a forcella, il cilindro di un motore radiale, una girante centrifuga, una scala a chiocciola in miniatura e un assieme con ingranaggi planetari.
Questo permette di verificare operazioni CAD differenti: estrusioni, geometrie ripetute, operazioni booleane, geometrie di rivoluzione, sweep e componenti costituiti da più corpi.
MAC contiene inoltre una galleria separata con modelli pensati per mostrare applicazioni orientate alla stampa 3D.
Tra gli esempi figurano un organizer a struttura honeycomb, un faro, un supporto per smartphone, un meccanismo di Ginevra e un disco freno.
Gli oggetti print-in-place aggiungono il problema delle tolleranze
Uno degli esperimenti più interessanti riguarda i modelli articolati stampabili già assemblati.
Gli sviluppatori hanno realizzato, tra gli altri, una sfera intrappolata in una gabbia e un piccolo giroscopio.
Questi oggetti contengono più corpi separati nello stesso file.
La difficoltà non consiste soltanto nel produrre la forma corretta.
È necessario lasciare una distanza sufficiente tra le parti perché dopo la stampa possano muoversi senza fondersi tra loro.
Nei modelli dimostrativi MAC utilizza giochi nell’ordine di 0,4-1 millimetro.
Per il giroscopio, per esempio, il progetto specifica un gioco radiale di 0,4 millimetri tra l’anello interno e quello esterno.
È un problema tipico della progettazione per additive manufacturing: una geometria può essere corretta dal punto di vista matematico ma non funzionare una volta prodotta se non vengono considerate tolleranze, materiale e caratteristiche della stampante.
Il caso della scala a chiocciola mostra l’utilità del controllo geometrico
Il progetto riporta anche un esempio nel quale la geometria inizialmente pianificata per una scala a chiocciola avrebbe creato una struttura fragile.
Alcune parti si sarebbero toccate essenzialmente in un punto, con una connessione insufficiente per una stampa affidabile.
Il sistema ha corretto l’intersezione aumentando la sovrapposizione tra gli elementi.
È un esempio utile perché evidenzia la differenza tra generazione geometrica e progettazione finalizzata alla produzione.
La seconda richiede la capacità di riconoscere che una forma formalmente costruibile può comunque presentare un problema pratico.
MAC non sostituisce una completa analisi di producibilità, ma il ciclo di controllo crea lo spazio per introdurre progressivamente questo tipo di regole.
STEP e STL rispondono a due esigenze differenti
Alla fine del processo MAC produce sia STEP sia STL.
La presenza dei due formati è importante.
STL descrive la superficie attraverso una mesh triangolare ed è ancora uno dei formati più utilizzati nel passaggio verso gli slicer per la stampa 3D.
STEP conserva invece una rappresentazione CAD molto più ricca e interoperabile.
build123d utilizza una modellazione BREP basata su Open Cascade e permette di esportare geometrie utilizzabili anche in altri ambienti CAD.
Questo significa che il risultato di MAC non deve necessariamente essere considerato un file finale da stampare senza modifiche.
Il codice Python rimane disponibile, il file STEP può essere importato in strumenti CAD compatibili e la geometria può diventare il punto di partenza per ulteriori operazioni ingegneristiche.
Il codice Python rende il processo più trasparente
Un altro elemento interessante è la natura cosiddetta white-box del sistema.
Tra i vari passaggi vengono salvati il CADBrief, l’ArchitectPlan, il codice build123d, le misure geometriche e i report relativi agli errori.
L’utente non riceve soltanto una mesh prodotta da un modello generativo di cui è difficile ricostruire il procedimento.
Può ispezionare il codice e capire quali operazioni hanno costruito la geometria.
Per un impiego tecnico questa caratteristica può avere un valore considerevole.
Se una parte contiene una quota sbagliata, un progettista può modificare il codice oppure intervenire sul piano.
Se una determinata funzione fallisce ripetutamente, il comportamento può essere diagnosticato.
Questo non elimina il rischio di errori prodotti dall’AI, ma rende più semplice individuarli e correggerli.
L’uso di build123d collega AI e CAD-as-code
La scelta di build123d colloca MAC in un filone più ampio chiamato CAD-as-code.
Invece di costruire la geometria esclusivamente attraverso pulsanti, menu e operazioni effettuate nell’interfaccia di un programma CAD, il modello viene descritto con un programma.
Le quote possono diventare variabili Python.
Le ripetizioni possono essere controllate attraverso cicli.
Una famiglia di componenti può essere generata cambiando pochi parametri.
Questo approccio è particolarmente adatto ai modelli linguistici perché un LLM è naturalmente efficace nella manipolazione di testo e codice.
L’AI non deve necessariamente imparare a spostare il mouse in un’interfaccia CAD.
Può produrre una descrizione programmatica delle operazioni geometriche.
MAC non è legato obbligatoriamente a un solo modello AI
Il benchmark pubblicato utilizza Qwen 3.7-max attraverso DashScope di Alibaba Cloud.
L’architettura, tuttavia, comunica con i modelli attraverso endpoint compatibili con l’interfaccia OpenAI.
Questa scelta permette di sostituire il modello utilizzato nelle varie fasi.
In linea di principio lo Spec Planner potrebbe utilizzare un modello più piccolo ed economico perché il suo compito consiste soprattutto nell’estrarre requisiti strutturati.
Il Geometric Architect potrebbe essere affidato a un modello con capacità di ragionamento più elevate.
Per la riparazione del codice si potrebbe scegliere un modello particolarmente efficace nella programmazione.
Il progetto permette anche di utilizzare endpoint locali compatibili.
Questa separazione è interessante perché evita di trattare ogni passaggio come se richiedesse necessariamente il modello più grande disponibile.
Un sistema multi-agent non significa automaticamente maggiore efficienza
MAC permette anche di chiarire un equivoco frequente sull’utilizzo di più agenti.
Dividere un processo tra quattro agenti non riduce necessariamente il costo.
Se ognuno dei quattro riceve ogni volta la conversazione completa, la documentazione completa e tutti gli errori precedenti, il sistema può diventare addirittura più costoso di una soluzione con un unico agente.
Il vantaggio di MAC deriva dalla separazione dei ruoli associata alla riduzione del contesto.
Ogni stadio vede ciò che gli serve.
Questo principio può essere applicato anche fuori dal CAD.
Workflow di programmazione, analisi documentale, automazione industriale e progettazione possono ridurre il consumo di risorse quando il problema viene trasformato in una serie di stati compatti invece di una conversazione che cresce senza controllo.
Il confronto con altri progetti mostra una direzione comune della ricerca
MAC non è il primo progetto ad applicare sistemi multi-agent alla progettazione CAD.
Nel 2025 il lavoro scientifico “From Idea to CAD” ha descritto un sistema nel quale più agenti basati su modelli vision-language assumono ruoli simili a quelli presenti in un gruppo di progettazione industriale.
Nel 2026 CADSmith ha proposto un’altra architettura multi-agent nella quale codice CadQuery, verifiche geometriche basate su Open Cascade e valutazioni visive vengono combinate in cicli di correzione.
Altri progetti stanno lavorando su editing interattivo, interpretazione di disegni tecnici e generazione di assiemi articolati.
La particolarità di MAC risiede quindi meno nell’idea generale di utilizzare più agenti e più nella decisione di misurare e ridurre in modo esplicito il test-time compute necessario per arrivare al risultato.
116 volte meno token non significa 116 volte meno potenza di calcolo
Il dato relativo ai token deve essere interpretato con cautela.
Un token è un’unità di elaborazione del modello linguistico, non una misura diretta dell’energia elettrica consumata o del tempo GPU complessivo.
Differenti modelli possono richiedere quantità molto diverse di calcolo per elaborare lo stesso numero di token.
Anche il caching modifica il rapporto tra token contabilizzati, costo economico e lavoro effettivamente eseguito.
La conclusione corretta è quindi più precisa: nel benchmark pubblicato, MAC ha ridotto di 116 volte i token contabilizzati rispetto alla configurazione CAD Skills usata come riferimento.
Gli autori indicano inoltre un tempo complessivo nell’ordine di dieci volte inferiore, ma specificano che questo valore è una stima osservata durante le prove e non il risultato di un benchmark formale sul wall-clock time.
Questa distinzione è importante quando i numeri vengono trasferiti da un repository di ricerca a una valutazione industriale.
Dieci modelli non bastano per definire l’affidabilità industriale
Anche il 99,3% di feature pass rate richiede cautela.
Le 141 caratteristiche geometriche appartengono a dieci prompt.
Un reparto di progettazione industriale può gestire migliaia di combinazioni di geometrie, standard, tolleranze, file importati, assiemi e vincoli.
Un sistema che supera 140 controlli su 141 in un benchmark non è automaticamente pronto per progettare componenti aeronautici, dispositivi medicali o organi di sicurezza senza supervisione.
Per questi impieghi rimangono indispensabili controlli ingegneristici, verifica delle tolleranze, analisi dei materiali, simulazione quando necessaria e approvazione da parte del personale responsabile.
Il benchmark dimostra soprattutto che l’architettura merita attenzione come metodo per organizzare il processo di generazione.
L’open source permette di studiare ciò che accade tra prompt e STEP
MAC è distribuito con licenza MIT.
Il codice può quindi essere studiato, modificato e integrato in altri progetti nel rispetto dei termini della licenza.
La disponibilità del repository ha un’importanza particolare in questo campo.
Gran parte dei sistemi generativi viene valutata guardando soltanto l’input e l’output.
Con MAC è invece possibile esaminare l’intera catena: interpretazione del requisito, piano geometrico, traduzione in build123d, produzione di STEP e STL, controllo e riparazione.
Per ricercatori e sviluppatori questo rende possibile verificare dove vengono effettivamente consumati i token e quali parti del sistema possono essere sostituite da procedure deterministiche.
Un possibile modello per il CAD assistito dall’AI
Il punto più interessante del progetto potrebbe quindi non essere la generazione completamente automatica di una staffa o di una flangia.
È il modo in cui MAC ridefinisce il ruolo del modello linguistico.
L’LLM non deve svolgere tutto il lavoro.
Può essere impiegato nei punti nei quali interpretazione, ragionamento geometrico e correzione richiedono flessibilità.
Le operazioni prevedibili possono invece essere affidate a codice deterministico.
I controlli dimensionali possono essere effettuati dal kernel geometrico.
La mesh può essere verificata con algoritmi tradizionali.
La produzione del file può essere gestita da build123d e Open Cascade.
Il modello AI diventa quindi un componente di una catena ingegneristica più ampia, anziché essere la catena stessa.
Per la progettazione CAD questa impostazione è particolarmente interessante perché precisione e verificabilità contano quanto la capacità generativa.
MAC suggerisce che uno dei modi per rendere più efficiente l’AI applicata all’ingegneria non consiste necessariamente nell’addestrare un modello ancora più grande.
Può essere più utile decidere con precisione quando il modello deve ragionare, quali informazioni deve ricevere e quali operazioni possono essere eseguite senza interpellarlo.
Se questo approccio continuerà a dimostrarsi efficace su benchmark più ampi, il text-to-CAD potrebbe evolvere da dimostrazione generativa a vero strumento di progettazione assistita: una descrizione in linguaggio naturale produce un primo modello parametrico, il sistema ne controlla la geometria e il progettista interviene soltanto dove sono necessarie decisioni tecniche.
In questa prospettiva, la riduzione dei token non è soltanto una questione di costo delle API.
È un indicatore di una differente architettura del lavoro tra intelligenza artificiale, software CAD e strumenti di verifica.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)
