Ivan Nikitin, amministratore delegato e cofondatore di Fortytwo – Serie di interviste

Ivan Nikitin è amministratore delegato e cofondatore di Fortytwo, dove sta sviluppando una tecnologia di inferenza a sciame che riunisce più modelli di IA per ragionare e valutare il lavoro reciproco. La sua esperienza spazia dai videogiochi all’IA conversazionale e generativa, fino ai sistemi interattivi, maturata presso Temporal e Sensorium. Nel 2011 ha cofondato Temporal insieme a Vlad Larin, oggi cofondatore e CTO di Fortytwo, acquisendo esperienza con popolazioni di agenti in evoluzione e sistemi che combinano modelli specializzati.

Fortytwo sviluppa infrastrutture di IA che consentono ai modelli di collaborare durante l’inferenza. Fortytwo Engine utilizza uno Swarm Decoder per guidare un processo di ragionamento condiviso man mano che si sviluppa, con l’obiettivo di migliorare la precisione e ridurre la generazione superflua di token nei compiti di lunga durata. L’azienda offre agli sviluppatori un’API tramite Fortytwo Engine e la possibilità di installare Fortytwo Harbor on-premise.

Prima di cofondare Fortytwo, hai trascorso anni a sviluppare prodotti basati sull’IA conversazionale e generativa e su sistemi interattivi presso Sensorium e Temporal. In che modo queste esperienze hanno influenzato la tua visione dei limiti dei singoli modelli linguistici di grandi dimensioni e ti hanno infine portato all’approccio basato sugli sciami alla base di Fortytwo?

Una parte consistente del nostro team, me compreso, è arrivata all’IA passando dai videogiochi. I videogiochi sono stati la culla dell’informatica personale e dell’IA moderna: è grazie a loro che esistono le GPU e i giochi sono stati il primo banco di prova serio per l’apprendimento per rinforzo. Gli ambienti di gioco ci hanno offerto un contesto concreto in cui creare agenti capaci di apprendere, adattarsi e competere. In Temporal, che ho cofondato nel 2011 con Vlad Larin, oggi cofondatore e CTO di Fortytwo, abbiamo iniziato lavorando sull’intelligenza in evoluzione: popolazioni di agenti in competizione sotto la pressione della selezione. Ci interessava capire come una popolazione potesse ottenere risultati superiori a quelli di un singolo agente, a condizione di disporre di un buon meccanismo per individuare i contributi più efficaci e valorizzarli. La selezione e la valutazione sono diventate elementi centrali del nostro modo di concepire l’intelligenza.

Con l’arrivo dei modelli transformer, ci siamo dedicati anche all’IA conversazionale e abbiamo sviluppato una piattaforma per personaggi basati sull’IA, capaci di sostenere conversazioni aperte e non programmate, dotati di memoria e personalità. È stato un paio d’anni prima di ChatGPT e i modelli su cui lavoravamo avevano finestre di contesto di appena 512-1.024 token. Era impensabile aspettarsi che un singolo modello linguistico dell’epoca gestisse in modo affidabile tutti i diversi requisiti di quell’esperienza. Abbiamo dovuto creare una pipeline personalizzata di modelli specializzati, ciascuno con responsabilità più circoscritte, e la logica necessaria per combinare i loro contributi. Classificare e selezionare le risposte è diventato essenziale per far funzionare l’intera esperienza. Questo ci ha insegnato quanto si potesse ottenere combinando modelli limitati in un sistema ben progettato.

L’altra lezione riguardava l’efficienza. Abbiamo imparato che i modelli specializzati potevano essere addestrati e utilizzati in modo più efficiente per compiti ben definiti, permettendoci di ottenere di più con risorse di calcolo limitate. La scalabilità dell’inferenza restava però una sfida: da un lato c’erano i limiti di utilizzo delle API, dall’altro i costi dell’hosting autonomo su larga scala. Non potendo accedere a una capacità di calcolo di frontiera, dovevamo riflettere attentamente su come sfruttare al meglio le risorse disponibili. Fortytwo ha riunito queste lezioni nella visione dell’inferenza a sciame: più modelli, o più istanze dello stesso modello, contribuiscono al ragionamento e al tempo stesso valutano il lavoro dei propri pari. Il risultato è che il collettivo è più preciso di ciascuno dei suoi componenti.

Fortytwo Engine utilizza diversi modelli open-weight per guidare un unico processo di ragionamento e verificare il lavoro reciproco mentre viene generata la risposta. In che modo questo approccio si differenzia dai tradizionali sistemi multiagente, dagli ensemble di modelli o dal semplice eseguire più modelli e poi selezionare la risposta migliore?

La differenza fondamentale è che l’inferenza a sciame è integrata direttamente nel motore di inferenza che abbiamo sviluppato. Lo chiamiamo Swarm Decoder: più modelli partecipanti plasmano continuamente un’unica traiettoria di ragionamento mentre viene generata. La valutazione e l’orientamento avvengono all’interno di questo processo, consentendo ai modelli di influenzarne la direzione prima che la risposta sia completa.

Le alternative funzionano in modo diverso. Negli ensemble che operano a livello di risposta, i modelli generano risposte separate, che vengono poi classificate, selezionate o combinate. L’architettura originale di Fortytwo, implementata nel 2025, prevedeva la classificazione delle risposte completate da parte dei modelli partecipanti. Ciò ha migliorato notevolmente la precisione delle risposte, ma al costo di una maggiore latenza e di un aumento del carico computazionale. Molti sistemi multiagente tradizionali ripartiscono il lavoro tra gli agenti, utilizzando un orchestratore e messaggi in linguaggio naturale per coordinare i rispettivi contributi. Questi passaggi possono richiedere ulteriori chiamate di inferenza, la ripetizione del contesto e decisioni su quali informazioni trasferire da un agente all’altro. Nello Swarm Decoder non ci sono passaggi di consegne: i partecipanti lavorano su un’unica traiettoria e si scambiano soltanto valutazioni su quale direzione sia migliore.

Lo Swarm Decoder è progettato per individuare le ipotesi deboli durante la generazione, prima che si investano risorse considerevoli per svilupparle. L’obiettivo è ridurre gli errori, i passi indietro e la generazione superflua; il vantaggio in termini di efficienza si ottiene quando questa verifica evita più lavoro di quanto ne aggiunga. Per questo non c’è alcun costo in termini di latenza: l’esecuzione segue un percorso più diretto, così Engine completa i compiti più rapidamente rispetto allo stesso modello eseguito da solo e con un numero complessivo inferiore di token, considerando tutti i modelli partecipanti.

Hai sottolineato che la deriva dei modelli durante le attività prolungate è un problema importante. Da cosa è causata concretamente e come si manifesta in applicazioni pratiche come l’ingegneria del software, la ricerca o gli agenti IA autonomi?

La deriva si verifica quando il contesto di un modello smette gradualmente di riguardare l’attività da svolgere. Nel corso di un’esecuzione prolungata, il contesto si riempie di output del modello, risultati degli strumenti, contenuti dei file e tentativi ripetuti. L’istruzione originale occupa una parte sempre più ridotta di ciò a cui il modello presta attenzione, e i suoi stessi errori precedenti entrano a far parte degli input su cui ragiona: di conseguenza, gli errori si accumulano invece di annullarsi. Inoltre, gli attuali modelli di ragionamento vengono addestrati con l’apprendimento per rinforzo per portare a termine le attività, e imparano scorciatoie che danno l’impressione di concluderle: saltare una chiamata a uno strumento, dichiarare di aver avuto successo, riassumere invece di verificare. La chiamiamo pigrizia, e i modelli di frontiera ne soffrono tanto quanto quelli a pesi aperti. La causa fondamentale è che un singolo modello non dispone di una verifica esterna. Valuta il proprio lavoro, ma i modelli sono poco capaci di riflettere accuratamente su se stessi.

Nell’ingegneria del software, la deriva si manifesta quando l’agente corregge il bug che hai descritto ma viola il vincolo indicato nel primo messaggio, scrive un test che passa senza difficoltà oppure legge lo stesso file quattro volte perché ha perso il conto di ciò che aveva già appreso. Nella ricerca, è un’esecuzione prolungata che si allontana dalla domanda posta e si sposta verso quella a cui è più facile rispondere, per poi restituire un riepilogo generico. Negli agenti autonomi, assume la forma più costosa: divagazioni, chiamate ripetute agli strumenti, passi indietro e un consumo di token parecchie volte superiore a quello necessario per l’attività.

Possiamo quantificarlo. Abbiamo sottoposto Qwen 3.8 27B a 450 attività di DeepSWE, veri compiti di ingegneria del software che richiedono l’uso di strumenti e contesti lunghi, prima senza supporto e poi tramite Fortytwo Engine. Da solo, il modello ha utilizzato in media 16,3 milioni di token per esecuzione, per un totale di 7,4 miliardi. Tramite Engine, lo stesso modello ha utilizzato in media 12,3 milioni di token per esecuzione, per un totale di 5,6 miliardi: il 24,7% in meno, risolvendo al contempo più attività, il 47,8% contro il 42,2%. Il modello non è cambiato. I quattro milioni di token per esecuzione risparmiati erano dovuti alla deriva: riletture, tentativi ripetuti e passi indietro che un singolo modello deve compiere perché nessuno individua le sue deviazioni mentre le fa. Lo sciame le intercetta, quindi il modello non deve mai sprecare token per rimediare.

In precedenza, Fortytwo faceva valutare ai modelli le risposte già completate degli altri, mentre l’architettura attuale consente loro di influenzare il processo di ragionamento mentre è ancora in corso. Cosa avete imparato dall’approccio precedente e perché l’orientamento in tempo reale è più efficace?

L’architettura del 2025 ha dimostrato che possiamo puntare a capacità di livello frontier aumentando la scala in orizzontale, cioè coinvolgendo più modelli invece di inseguire quello più grande. Uno sciame di modelli a pesi aperti che classificava le risposte complete degli altri ha superato il miglior modello individuale dello sciame fino a 17 punti percentuali ed è risultato robusto in situazioni in cui un singolo modello non lo è: prompt rumorosi, istruzioni iniettate e una maggioranza di risposte errate.

Quell’architettura, però, non poteva intervenire. Classificare le risposte complete funziona per una singola domanda, ma le esecuzioni degli agenti comprendono centinaia di passaggi, con chiamate agli strumenti nel mezzo, e gli errori decisivi si verificano all’inizio e si accumulano. Valutare il risultato alla fine significa che ogni modello ha già sostenuto l’intero costo in token, e il valutatore può soltanto scegliere tra traiettorie che si sono già differenziate. Inoltre, il costo dello sciame aumentava con il numero di modelli: un aspetto accettabile per una singola domanda difficile, ma inadatto a un agente di programmazione.

L’orientamento in tempo reale risolve entrambi i problemi. La classificazione continua esercita una pressione selettiva durante tutta l’esecuzione, così una deviazione viene corretta nel punto in cui si verifica, prima che si propaghi. Lo sciame non si accontenta mai di un tentativo sbrigativo, perché nella classifica questo viene superato da uno più accurato. Ecco perché lo stesso meccanismo ci consente ora di ottenere contemporaneamente una maggiore accuratezza e un minor consumo di token.

Nei test con Qwen 3.8 27B, Fortytwo dichiara di aver utilizzato il 24,7% di token in meno in 450 esecuzioni di DeepSWE, migliorando al contempo i risultati in sei benchmark. Cosa accade all’interno dello sciame per migliorare le prestazioni e ridurre allo stesso tempo il consumo di token?

La verifica dello sciame ha un costo contenuto e fisso; il lavoro di recupero che consente di evitare aumenta con la durata dell’attività, perché ogni deviazione non corretta compromette tutto ciò che viene costruito a partire da essa. Più l’attività è lunga, più token si possono risparmiare. DeepSWE si colloca nella fascia delle attività più lunghe, ed è per questo che il risparmio arriva a quasi un quarto del totale dei token.

Per quanto riguarda l’accuratezza, il punto è che l’intelligenza dei modelli è disomogenea. I miglioramenti dei modelli tendono a essere irregolari: si può ottenere un ragionamento di livello dottorale in un ambito e, in un altro, risultati del tutto insensati, perché la messa a punto, l’apprendimento per rinforzo e le altre fasi di post-addestramento migliorano il modello sui dati su cui è stato addestrato, mentre i vantaggi diminuiscono man mano che le attività reali si discostano da quei dati. Swarm Decoder non modifica il modello: migliora il ragionamento in sé, in modo costante. Perciò, i sei benchmark non corrispondono a sei ambiti per i quali abbiamo ottimizzato il sistema, ma sono sei contesti in cui abbiamo misurato lo stesso risultato. Nel complesso, il modello è più intelligente e attento e, con i suoi pari che verificano ogni passaggio, sembra dedicare molta più attenzione alla tua attività. Ecco anche perché possiamo applicare a Engine la stessa tariffa per token del modello di base: il cliente non paga per un budget maggiore, ma per un percorso più breve verso la risposta corretta.

Gli sviluppatori di IA sono sempre più preoccupati per i costi dell’inferenza, man mano che i modelli di ragionamento generano catene di token più lunghe. Pensi che migliorare l’efficienza del processo di ragionamento in sé possa, in definitiva, essere importante quanto rendere i singoli modelli più piccoli, veloci o economici?

Sì, e direi che è già la leva più importante. Rendere i modelli più piccoli, veloci ed economici riduce il prezzo di un token. Ma nessuno compra token: si compra un’attività completata. Nell’era degli agenti, il numero di token per attività è aumentato enormemente: un modello di ragionamento impegnato in un’attività reale di programmazione ne usa milioni, e una grossa parte viene spesa tornando sui propri passi. Ridurre del 25% i token per attività vale esattamente quanto un taglio del 25% del prezzo, con la differenza che il risparmio si somma a ogni miglioramento dell’hardware, della quantizzazione e dei kernel; inoltre, possiamo applicare questo approccio a qualsiasi modello open-weight sul mercato.

L’industria ha tre leve. Modelli migliori, che richiedono addestramento e sono costosi. Token più economici, grazie all’hardware e all’erogazione, un ambito in cui le differenze si stanno appiattendo perché tutti usano le stesse GPU. E meno token per attività, un risultato che dipende da come viene eseguita l’inferenza e che è stato appena esplorato. Finora, scalare ha significato usare modelli più grandi e catene di ragionamento più lunghe, chiedendo a un unico modello di fare tutto in un solo percorso. Crediamo che la prossima dimensione su cui intervenire sia quella collettiva: diversi modelli che ragionano insieme, distribuendo tra loro la capacità di giudizio, così da rendere il percorso stesso più breve e affidabile. È un modo di scalare diverso dall’aumento dei parametri o del calcolo in fase di test, ed è quello su cui puntiamo. La nostra idea è: più pari, meno parametri.

Fortytwo Engine è compatibile con l’API OpenAI e al tempo stesso esegue modelli open-weight. Quanto era importante garantire la compatibilità con gli stack di sviluppo IA esistenti, e quanto è facile per gli sviluppatori trasferire un’applicazione da una normale API basata su un singolo modello a un’architettura a sciame?

La compatibilità è essenziale. L’ecosistema degli agenti — agenti di programmazione, ambienti di orchestrazione, framework e strumenti di valutazione — si basa sulla struttura dell’API OpenAI. Perciò, per gli sviluppatori che accedono a Fortytwo Engine, il passaggio è come spostarsi da un provider di inferenza a un altro: per un’app, un agente, un ambiente di orchestrazione o un servizio compatibile, in genere basta modificare un’unica configurazione: l’endpoint, la chiave API e la selezione del modello.

A cambiare è il comportamento, non l’integrazione. La differenza si nota nelle lunghe esecuzioni agentiche, in cui il consumo di token e la precisione al primo tentativo determinano i costi: con Engine, lo stesso modello completa le attività più velocemente, usando meno token, e ne porta a termine correttamente un numero maggiore. Il mio consiglio è di trattare il passaggio come qualsiasi sostituzione di modello: esegui sul tuo agente le valutazioni che usi già, confronta i token per attività e il tasso di successo, e tieni la soluzione che dà risultati migliori.

Grazie per la splendida intervista. I lettori che desiderano approfondire l’inferenza a sciame e scoprire come la valutazione tra pari possa migliorare l’efficienza del ragionamento possono visitare Fortytwo.