Ivan Nikitin, director general și cofondator al Fortytwo – serie de interviuri

Ivan Nikitin este director general și cofondator al Fortytwo, unde dezvoltă o tehnologie de inferență în roi, care reunește mai multe modele de IA pentru ca acestea să raționeze și să evalueze reciproc munca depusă. Experiența sa cuprinde jocuri, IA conversațională, IA generativă și sisteme interactive, la Temporal și Sensorium. A cofondat Temporal în 2011 împreună cu Vlad Larin, în prezent cofondator și director tehnic al Fortytwo, acumulând experiență în lucrul cu populații de agenți aflate în evoluție și cu sisteme care combină modele specializate.

Fortytwo dezvoltă infrastructură de IA care le permite modelelor să colaboreze în timpul inferenței. Fortytwo Engine folosește un Swarm Decoder pentru a ghida un proces comun de raționare pe măsură ce acesta se desfășoară, cu scopul de a îmbunătăți acuratețea și de a reduce generarea inutilă de tokenuri în sarcinile de durată. Compania le oferă dezvoltatorilor un API prin Fortytwo Engine și posibilitatea de implementare locală, prin Fortytwo Harbor.

Înainte de a cofonda Fortytwo, ați petrecut ani întregi dezvoltând produse bazate pe IA conversațională, IA generativă și sisteme interactive, la Sensorium și Temporal. Cum v-au influențat aceste experiențe perspectiva asupra limitelor modelelor lingvistice mari individuale și cum v-au condus, în cele din urmă, la abordarea bazată pe roiuri din spatele Fortytwo?

O mare parte din echipa noastră, inclusiv eu, a ajuns la IA prin intermediul jocurilor. Jocurile au fost leagănul informaticii personale și al IA moderne: datorită lor există GPU-ul, iar jocurile au reprezentat primul teren de testare serios pentru învățarea prin recompensă. Lumile jocurilor ne-au oferit un mediu practic în care să dezvoltăm agenți capabili să învețe, să se adapteze și să concureze. La Temporal, pe care am cofondat-o în 2011 împreună cu Vlad Larin, în prezent cofondator și director tehnic al Fortytwo, am pornit de la ideea unei inteligențe în evoluție: populații de agenți care concurează sub presiunea selecției. Ne interesa cum ar putea o populație să obțină rezultate mai bune decât un agent individual, dacă ar exista un mecanism eficient pentru a identifica și valorifica cele mai puternice contribuții ale membrilor săi. Selecția și evaluarea au devenit elemente centrale în felul în care priveam inteligența.

Odată cu apariția modelelor bazate pe transformere, ne-am extins activitatea în domeniul IA conversaționale și am creat o platformă pentru personaje bazate pe IA, capabile să poarte conversații libere, nescrise, având memorie și personalitate. Asta se întâmpla cu câțiva ani înainte de ChatGPT, iar modelele cu care lucram aveau ferestre de context de doar 512 până la 1.024 de tokenuri. Era exclus să ne așteptăm ca un singur model lingvistic aflat la început de dezvoltare să gestioneze în mod fiabil toate cerințele diferite ale acestei experiențe. A trebuit să construim o conductă personalizată de modele specializate, fiecare cu responsabilități mai restrânse, precum și logica necesară pentru a le combina contribuțiile. Clasificarea și selectarea răspunsurilor au devenit esențiale pentru buna funcționare a întregii experiențe. Astfel am înțeles cât de multă capacitate putea rezulta din combinarea unor modele cu posibilități limitate într-un sistem bine conceput.

Cealaltă lecție a fost eficiența. Am învățat că modelele specializate puteau fi antrenate și furnizate mai eficient pentru sarcini bine definite, ceea ce ne permitea să obținem mai mult cu resurse de calcul limitate. Totuși, extinderea inferenței a rămas o provocare: pe de o parte, existau limite de utilizare a API-urilor, iar pe de altă parte, costurile găzduirii proprii la scară largă. Fără acces la capacitatea de calcul de ultimă generație, a trebuit să ne gândim cu atenție cum să valorificăm mai bine resursele disponibile. Fortytwo reunește aceste lecții în viziunea inferenței în roi: mai multe modele sau mai multe instanțe ale aceluiași model contribuie la raționare, evaluând în același timp munca celorlalte. Astfel, colectivul este mai precis decât oricare dintre membrii săi.

Fortytwo Engine folosește mai multe modele cu ponderi deschise pentru a ghida un singur proces de raționare și pentru a le permite să se verifice reciproc pe măsură ce este generat răspunsul. Prin ce se deosebește această abordare de sistemele multiagent convenționale, de ansamblurile de modele sau de simpla rulare a mai multor modele, urmată de selectarea celui mai bun răspuns?

Principala diferență este că inferența în roi este integrată direct în motorul de inferență pe care l-am dezvoltat. Îl numim Swarm Decoder: mai mulți participanți bazați pe modele influențează continuu o singură traiectorie de raționare pe măsură ce aceasta este generată. Evaluarea și ghidarea au loc în cadrul acestui proces, permițând modelelor să-i influențeze direcția înainte ca răspunsul să fie complet.

Alternativele funcționează diferit. Într-un ansamblu de răspunsuri, modelele generează răspunsuri separate, care sunt apoi clasificate, selectate sau combinate. Arhitectura inițială a Fortytwo, implementată în 2025, folosea clasificarea răspunsurilor finalizate de către modele partenere. Aceasta a îmbunătățit considerabil acuratețea răspunsurilor, dar a sporit latența și cheltuielile de calcul. Multe sisteme multiagent convenționale împart munca între agenți, folosind un orchestrator și mesaje în limbaj natural pentru a le coordona contribuțiile. Aceste transferuri pot necesita apeluri suplimentare de inferență, repetarea contextului și decizii privind informațiile care trebuie transmise de la un agent la altul. În Swarm Decoder nu există transferuri: participanții lucrează la aceeași traiectorie, iar singurul lucru pe care îl comunică este o evaluare a direcției mai bune.

Swarm Decoder este conceput să detecteze ipotezele nefondate în timpul generării, înainte să se investească un efort considerabil în dezvoltarea lor. Scopul este reducerea greșelilor, a revenirilor asupra pașilor anteriori și a generării inutile; avantajul de eficiență apare atunci când verificarea previne mai multă muncă decât adaugă. De aceea nu există o penalizare de latență: execuția urmează un traseu mai direct, astfel că Engine finalizează sarcinile mai repede decât același model folosit individual și cu un număr total mai mic de tokenuri, luându-se în calcul fiecare model participant.

Ai evidențiat devierea modelelor în timpul sarcinilor de lungă durată ca fiind o problemă majoră. Ce cauzează, de fapt, această deviere și cum se manifestă în aplicații concrete, precum ingineria software, cercetarea sau agenții IA autonomi?

Devierea apare atunci când contextul unui model încetează treptat să mai fie centrat pe sarcină. Într-o execuție de lungă durată, contextul se umple cu propriile răspunsuri ale modelului, rezultatele instrumentelor, conținutul fișierelor și încercările repetate. Instrucțiunea inițială ajunge să reprezinte o parte din ce în ce mai mică din ceea ce urmărește modelul, iar greșelile făcute anterior devin parte din datele pe baza cărora raționează. Astfel, erorile se acumulează în loc să se anuleze reciproc. În plus, modelele de raționament de astăzi sunt antrenate prin învățare prin recompensă să ducă sarcinile la bun sfârșit și deprind scurtături care doar dau impresia că le finalizează: omit apelul unui instrument, declară că au reușit sau rezumă în loc să verifice. Numim asta lene, iar modelele de vârf se comportă la fel de des astfel ca modelele cu ponderi deschise. Cauza fundamentală este că un model nu dispune de o verificare externă. Își evaluează singur munca, iar modelele nu se pricep să se autoevalueze cu exactitate.

În ingineria software, observi acest lucru când agentul remediază eroarea descrisă, dar încalcă o constrângere menționată în primul mesaj, scrie un test care trece fără nicio dificultate sau citește același fișier de patru ori pentru că a pierdut șirul informațiilor pe care le-a aflat deja. În cercetare, se manifestă printr-o execuție de lungă durată care se îndepărtează de întrebarea ta și se concentrează pe cea la care e mai ușor să răspundă, apoi revine cu un rezumat generic. În cazul agenților autonomi, forma aceasta este costisitoare: divagații, apeluri repetate ale instrumentelor, reluarea unor pași și un consum de tokenuri de câteva ori mai mare decât ar fi necesitat sarcina.

Putem cuantifica fenomenul. Am rulat Qwen 3.8 27B pe 450 de sarcini DeepSWE — activități reale de inginerie software, cu utilizarea instrumentelor și contexte de lungă durată — o dată fără ajutor și o dată prin Fortytwo Engine. Rulat fără ajutor, modelul a folosit în medie 16,3 milioane de tokenuri per execuție, adică 7,4 miliarde în total. Prin Engine, același model a folosit în medie 12,3 milioane de tokenuri per execuție, adică 5,6 miliarde în total: cu 24,7% mai puține. În plus, a rezolvat mai multe sarcini: 47,8%, față de 42,2%. Modelul nu s-a schimbat. Cele patru milioane de tokenuri per execuție care nu au mai fost folosite reprezentau devierea: recitirea, încercările repetate și revenirea asupra pașilor făcuți, la care un model individual trebuie să recurgă pentru că nimeni nu-i corectează abaterile pe măsură ce apar. Roiul le detectează, astfel că nu mai este nevoie să se consume tokenuri pentru ele.

Anterior, Fortytwo punea modelele să evalueze răspunsurile finalizate ale celorlalte, pe când arhitectura actuală le permite să influențeze procesul de raționament în timp ce acesta se desfășoară. Ce ați învățat din abordarea anterioară și de ce este mai eficientă orientarea în timp real?

Arhitectura din 2025 a demonstrat că putem atinge capacități de nivelul celor mai avansate modele prin scalare orizontală — implicând mai multe modele, în loc să urmărim modelul cel mai mare. Un roi de modele cu ponderi deschise, care își ierarhizau reciproc răspunsurile complete, a depășit cel mai bun model individual din roi cu până la 17 puncte procentuale și a fost robust în situații în care un singur model nu este: prompturi cu zgomot, instrucțiuni injectate și o majoritate de răspunsuri greșite.

Ceea ce arhitectura respectivă nu putea face era să intervină. Ierarhizarea răspunsurilor finalizate funcționează pentru o singură întrebare, dar execuțiile agenților cuprind sute de pași, cu apeluri de instrumente între aceștia, iar greșelile decisive apar devreme și se acumulează. Dacă evaluarea are loc la final, fiecare model a suportat deja costul integral al tokenurilor, iar evaluatorul poate alege doar dintre trasee care au deviat deja unele de altele. În plus, costul roiului creștea proporțional cu numărul de modele — acceptabil pentru o întrebare dificilă, dar nepotrivit pentru un agent de programare.

Orientarea în timp real rezolvă ambele probleme. Ierarhizarea continuă exercită presiune de selecție pe tot parcursul execuției, astfel încât o abatere greșită este corectată chiar în momentul în care apare, înainte să se propage. Roiul nu se mulțumește niciodată cu o încercare superficială, deoarece aceasta pierde în fața uneia mai atente în ierarhizare. De aceea, același mecanism ne oferă acum simultan o precizie mai mare și un consum mai mic de tokenuri.

În testele efectuate cu Qwen 3.8 27B, Fortytwo raportează că a folosit cu 24,7% mai puține tokenuri în 450 de execuții DeepSWE, îmbunătățind totodată rezultatele pe șase benchmarkuri. Ce se întâmplă în interiorul roiului, astfel încât acesta să îmbunătățească performanța și, în același timp, să reducă numărul de tokenuri consumate?

Verificările roiului au un cost mic și fix; resursele economisite prin prevenirea remedierilor cresc odată cu durata sarcinii, deoarece fiecare abatere greșită necorectată compromite tot ce se construiește ulterior pe baza ei. Prin urmare, cu cât sarcina este mai lungă, cu atât se pot economisi mai multe resurse, iar DeepSWE se situează la capătul superior al acestui spectru. De aceea, economia ajunge la aproape un sfert din totalul tokenurilor.

În ceea ce privește precizia, totul ține de caracterul inegal al inteligenței. Îmbunătățirile aduse modelelor sunt, de regulă, inegale: acestea pot raționa la nivel de doctorat într-un domeniu și pot produce nonsensuri complete în altul, deoarece ajustarea fină, învățarea prin recompensă și alte etape de antrenare ulterioară îmbunătățesc un model pe baza datelor cu care a fost antrenat, iar progresele se diminuează pe măsură ce sarcinile reale se îndepărtează de acele date. Swarm Decoder nu modifică modelul. Îmbunătățește în mod consecvent procesul de raționare, așa că cele șase benchmarkuri nu reprezintă șase domenii pentru care am optimizat, ci șase locuri în care am măsurat același lucru. Per ansamblu, modelul este mai inteligent și mai atent, iar verificarea fiecărui pas de către celelalte modele îl face să pară mult mai implicat în sarcina ta. Acesta este și motivul pentru care putem tarifa Engine la același preț per token ca modelul de bază: clientul nu plătește pentru un buget mai mare, ci pentru un traseu mai scurt până la răspunsul corect.

Dezvoltatorii de inteligență artificială sunt tot mai preocupați de costurile inferenței, pe măsură ce modelele de raționament generează lanțuri de tokenuri tot mai lungi. Credeți că îmbunătățirea eficienței procesului de raționament în sine ar putea ajunge să fie la fel de importantă ca dezvoltarea unor modele individuale mai mici, mai rapide sau mai ieftine?

Da, și aș susține că este deja pârghia mai importantă. Modelele mai mici, mai rapide și mai ieftine reduc prețul unui token. Dar nimeni nu cumpără tokenuri. Oamenii cumpără o sarcină finalizată, iar în era agenților numărul de tokenuri per sarcină a explodat: un model de raționament folosește milioane de tokenuri pentru o sarcină reală de programare, iar o mare parte dintre ele sunt consumate revenind asupra pașilor deja parcurși. O reducere cu 25% a numărului de tokenuri per sarcină valorează exact cât o reducere de preț cu 25%, dar se cumulează cu fiecare îmbunătățire a hardware-ului, a cuantizării și a nucleelor de calcul; în plus, o putem aplica oricărui model cu ponderi deschise disponibil pe piață.

Industria dispune de trei pârghii. Modele mai bune, ceea ce înseamnă antrenare și costuri ridicate. Tokenuri mai ieftine, ceea ce ține de hardware și de servirea modelelor; aici lucrurile converg, pentru că toată lumea folosește aceleași GPU-uri. Și mai puține tokenuri per sarcină, ceea ce ține de modul în care se desfășoară inferența și este o direcție aproape neexplorată. Până acum, extinderea a însemnat modele mai mari și lanțuri de raționament mai lungi, iar în ambele cazuri un singur model trebuie să facă totul într-o singură secvență. Noi credem că următoarea direcție este cea colectivă: mai multe modele raționează împreună, judecata fiind distribuită între ele, astfel încât secvența în sine să fie mai scurtă și mai fiabilă. Acesta este un alt tip de extindere, diferit de cel bazat pe parametri sau pe calculul la momentul testării, și pe acesta mizăm. Noi îl numim „colegi în loc de parametri”.

Fortytwo Engine este compatibil cu API-ul OpenAI și rulează modele cu ponderi deschise. Cât de importantă a fost compatibilitatea cu instrumentele de dezvoltare IA existente și cât de ușor pot dezvoltatorii să treacă o aplicație de la un API convențional, bazat pe un singur model, la o arhitectură de tip roi?

Compatibilitatea este esențială. Ecosistemul agenților — agenți de programare, medii de orchestrare, cadre de lucru și instrumente de evaluare — este construit în jurul structurii API-ului OpenAI. Prin urmare, pentru dezvoltatorii care folosesc Fortytwo Engine, trecerea este ca mutarea de la un furnizor de inferență la altul: pentru o aplicație, un agent, un mediu de orchestrare sau un serviciu compatibil, de obicei este suficientă o singură modificare de configurare: endpointul, cheia API și selectarea modelului.

Se schimbă comportamentul, nu integrarea. Diferența se vede în rulările agentice de durată, în care consumul de tokenuri și acuratețea de la prima încercare determină costul: același model, folosit prin Engine, finalizează sarcinile mai repede, cu mai puține tokenuri, și rezolvă corect mai multe dintre ele. Recomandarea mea este să tratați schimbarea ca pe înlocuirea oricărui model: rulați evaluarea pe care o folosiți deja pentru agentul vostru, comparați numărul de tokenuri per sarcină și rata de succes, apoi păstrați varianta care se descurcă mai bine.

Vă mulțumim pentru interviul excelent. Cititorii care doresc să afle mai multe despre inferența de tip roi și despre modul în care evaluarea între modele similare poate îmbunătăți eficiența raționamentului pot vizita Fortytwo.