Ivan Nikitin, Fortytwon toimitusjohtaja ja toinen perustaja – haastattelusarja

Ivan Nikitin on Fortytwon toimitusjohtaja ja toinen perustaja. Yhtiössä hän kehittää parvi-inferenssiteknologiaa, jossa useat tekoälymallit yhdistävät voimansa päättelyä varten ja arvioivat toistensa työtä. Hänellä on kokemusta peleistä, keskustelevaan tekoälyyn perustuvista sovelluksista, generatiivisesta tekoälystä ja interaktiivisista järjestelmistä Temporalissa ja Sensoriumissa. Hän perusti Temporalin vuonna 2011 yhdessä Vlad Larinin kanssa. Larin on nykyään Fortytwon toinen perustaja ja teknologiajohtaja. Temporalissa hän sai kokemusta kehittyvistä agenttipopulaatioista ja erikoistuneita malleja yhdistävistä järjestelmistä.

Fortytwo rakentaa tekoälyinfrastruktuuria, jonka avulla mallit voivat tehdä yhteistyötä inferenssin aikana. Sen Fortytwo Engine hyödyntää Swarm Decoderia ohjaamaan yhteistä päättelyprosessia sen edetessä. Tavoitteena on parantaa tarkkuutta ja vähentää tarpeetonta tokenien tuottamista pitkissä tehtävissä. Yhtiö tarjoaa kehittäjille API-rajapinnan Fortytwo Enginen kautta sekä mahdollisuuden ottaa Fortytwo Harbor käyttöön omissa tiloissa.

Ennen Fortytwon perustamista käytit vuosia keskustelevaan tekoälyyn, generatiiviseen tekoälyyn ja interaktiivisiin järjestelmiin liittyvien tuotteiden rakentamiseen Sensoriumissa ja Temporalissa. Miten nämä kokemukset vaikuttivat näkemykseesi siitä, missä yksittäisten suurten kielimallien kyvyt eivät riitä, ja johtivat lopulta Fortytwon taustalla olevaan parvipohjaiseen lähestymistapaan?

Suuri osa tiimistämme, minä mukaan lukien, päätyi tekoälyn pariin pelien kautta. Pelit ovat olleet henkilökohtaisen tietojenkäsittelyn ja modernin tekoälyn kehto: niiden ansiosta grafiikkasuoritin (GPU) on olemassa, ja pelien pelaaminen oli ensimmäinen vakava testialusta vahvistusoppimiselle. Pelimaailmat tarjosivat käytännöllisen ympäristön sellaisten agenttien rakentamiseen, jotka pystyivät oppimaan, mukautumaan ja kilpailemaan. Temporalissa, jonka perustimme vuonna 2011 yhdessä Vlad Larinin kanssa – hän on nykyään Fortytwon toinen perustaja ja teknologiajohtaja – keskityimme aluksi kehittyvään älykkyyteen: agenttipopulaatioihin, jotka kilpailivat valintapaineen alla. Halusimme selvittää, miten populaatio voisi saavuttaa enemmän kuin yksittäinen agentti, kunhan käytössä olisi hyvä mekanismi vahvimpien panosten tunnistamiseen ja niiden pohjalta jatkamiseen. Valinta ja arviointi nousivat keskeisiksi tekijöiksi siinä, miten ajattelimme älykkyydestä.

Kun muuntajamallit tulivat käyttöön, laajensimme toimintaamme keskustelevaan tekoälyyn ja rakensimme alustan tekoälyohjatuille hahmoille, jotka pystyivät käymään avoimia, käsikirjoittamattomia keskusteluja muistin ja persoonallisuuden varassa. Tämä tapahtui pari vuotta ennen ChatGPT:tä, ja käyttämillämme malleilla oli vain 512–1 024 tokenin konteksti-ikkuna. Ei tullut kuuloonkaan, että yksi varhainen kielimalli olisi pystynyt hoitamaan luotettavasti kaikki tällaisen kokemuksen vaatimukset. Meidän oli rakennettava oma erikoistuneiden mallien putki, jossa jokaisella mallilla oli rajatumpi tehtävä, sekä logiikka niiden panosten yhdistämiseen. Vastausten järjestämisestä ja valitsemisesta tuli olennaista koko kokemuksen toimivuuden kannalta. Opimme, kuinka paljon kyvykkyyttä voitiin saada aikaan yhdistämällä rajallisia malleja hyvin suunnitelluksi järjestelmäksi.

Toinen oppi liittyi tehokkuuteen. Huomasimme, että erikoistuneita malleja voitiin kouluttaa ja käyttää tehokkaammin tarkasti määritellyissä tehtävissä, jolloin rajallisilla laskentaresursseilla saatiin enemmän aikaan. Inferenssin skaalaaminen oli silti haaste: toisella puolella olivat API-käytön rajoitukset ja toisella laajamittaisen itse ylläpidetyn palvelun kustannukset. Koska meillä ei ollut käytössämme huipputason laskentakapasiteettia, meidän oli tarkkaan mietittävä, miten saatavilla olevista resursseista saataisiin enemmän irti. Fortytwo kokoaa nämä opit parvi-inferenssin visioksi: useat mallit tai saman mallin useat instanssit osallistuvat päättelyyn ja arvioivat samalla toistensa työtä. Näin muodostuva kokonaisuus on tarkempi kuin yksikään sen jäsenistä.

Fortytwo Engine käyttää useita avoimilla painoilla varustettuja malleja ohjaamaan yhtä päättelyprosessia ja tarkistamaan toistensa työtä vastauksen muodostuessa. Miten tämä lähestymistapa eroaa perinteisistä moniagenttijärjestelmistä, mallien yhdistelmistä tai siitä, että ajetaan useita malleja ja valitaan paras vastaus vasta jälkikäteen?

Keskeinen ero on siinä, että parvi-inferenssi on rakennettu suoraan kehittämäämme inferenssimoottoriin. Kutsumme sitä Swarm Decoderiksi: useat malliosallistujat muovaavat jatkuvasti yhtä päättelypolkua sen muodostuessa. Arviointi ja ohjaus tapahtuvat osana tätä prosessia, joten mallit voivat vaikuttaa sen suuntaan ennen kuin vastaus on valmis.

Vaihtoehdot toimivat eri tavoin. Vastaustason yhdistelmässä mallit tuottavat erilliset vastaukset, jotka sitten asetetaan paremmuusjärjestykseen, valitaan tai yhdistetään. Fortytwon alkuperäisessä arkkitehtuurissa, joka otettiin käyttöön vuonna 2025, valmiit vastaukset järjestettiin vertailemalla niitä keskenään. Tämä paransi vastausten tarkkuutta huomattavasti, mutta lisäsi viivettä ja laskennan kuormitusta. Monissa perinteisissä moniagenttijärjestelmissä työt jaetaan agenttien kesken, ja niiden panoksia hallitaan orkestroijalla sekä luonnollisen kielen viesteillä. Tällaiset siirrot voivat edellyttää uusia inferenssikutsuja ja saman kontekstin toistamista sekä päätöksiä siitä, mitä tietoa yhdeltä agentilta välitetään toiselle. Swarm Decoderissa ei ole siirtoja: osallistujat työskentelevät saman päättelypolun parissa, ja ainoa asia, jonka he vaihtavat keskenään, on arvio siitä, mikä suunta on parempi.

Swarm Decoder on suunniteltu havaitsemaan heikot oletukset jo vastauksen muodostamisen aikana, ennen kuin niiden pohjalta ehditään tehdä paljon työtä. Tavoitteena on vähentää virheitä, paluuta aiempiin vaiheisiin ja tarpeetonta sisällön tuottamista. Tehokkuushyöty syntyy silloin, kun tarkistaminen estää enemmän työtä kuin mitä se lisää. Siksi viive ei myöskään kasva: suoritus etenee suorempaa reittiä, joten Engine suorittaa tehtävät nopeammin kuin sama malli yksinään ja käyttää yhteensä vähemmän tokeneita, kun kaikkien osallistuvien mallien tokenit lasketaan mukaan.

Olet nostanut esiin mallin ajautumisen pitkäkestoisissa tehtävissä merkittävänä ongelmana. Mistä tämä ajautuminen oikeastaan johtuu, ja miten se näkyy käytännössä esimerkiksi ohjelmistokehityksessä, tutkimuksessa tai autonomisissa tekoälyagenteissa?

Ajautumisella tarkoitetaan sitä, että mallin konteksti alkaa vähitellen etääntyä tehtävästä. Pitkän suorituksen aikana konteksti täyttyy mallin omista tuotoksista, työkalujen tuloksista, tiedostojen sisällöistä ja uusintayrityksistä. Alkuperäisen ohjeen osuus siitä, mihin malli kiinnittää huomiota, pienenee koko ajan, ja mallin aiemmat virheet ovat nyt osa sen päättelyn lähtöaineistoa. Näin virheet kasaantuvat sen sijaan, että ne kumoaisivat toisensa. Lisäksi nykyisiä päättelymalleja koulutetaan vahvistusoppimisella suorittamaan tehtäviä loppuun, ja ne oppivat oikopolkuja, jotka näyttävät tehtävän loppuun saattamiselta: työkalukutsun ohittamisen, onnistumisen julistamisen tai tarkistamisen sijaan tiivistelmän tekemisen. Kutsumme tätä laiskuudeksi, ja huipputason mallit tekevät niin yhtä lailla kuin avoimilla painoilla julkaistut mallit. Perimmäinen syy on se, ettei yksittäisellä mallilla ole ulkopuolista tarkistajaa. Se arvioi omaa työtään, mutta mallit eivät osaa arvioida itseään tarkasti.

Ohjelmistokehityksessä tämä näkyy esimerkiksi niin, että agentti korjaa kuvaamasi virheen mutta rikkoo ensimmäisessä viestissä mainitsemasi rajoitteen, kirjoittaa testin, joka menee triviaalisti läpi, tai lukee saman tiedoston neljä kertaa, koska se on unohtanut, mitä jo oppi. Tutkimuksessa kyse on pitkästä suorituksesta, joka ajautuu esittämästäsi kysymyksestä kysymykseen, johon on helpointa vastata, ja päätyy tuottamaan yleisluontoisen yhteenvedon. Autonomisissa agenteissa ajautuminen näkyy kalliina versiona: sivupolkuina, toistuvina työkalukutsuina, edestakaisena palaamisena ja tokenilaskuna, joka on moninkertainen siihen nähden, mitä tehtävä olisi vaatinut.

Voimme mitata tämän. Ajoimme Qwen 3.8 27B -mallilla 450 DeepSWE-tehtävää eli todellisia ohjelmistokehitystehtäviä, joissa käytettiin työkaluja pitkissä konteksteissa. Kokeilimme mallia kerran itsenäisesti ja kerran Fortytwo Enginen kautta. Itsenäisesti mallin keskiarvo oli 16,3 miljoonaa tokenia suoritusta kohden eli yhteensä 7,4 miljardia tokenia. Enginen kautta sama malli käytti keskimäärin 12,3 miljoonaa tokenia suoritusta kohden eli yhteensä 5,6 miljardia tokenia, 24,7 % vähemmän, ja ratkaisi samalla useampia tehtäviä: 47,8 % verrattuna 42,2 prosenttiin. Mallissa ei muuttunut mikään. Suoritusta kohden säästyneet neljä miljoonaa tokenia johtuivat ajautumisesta: uudelleenlukemisesta, uusintayrityksistä ja edestakaisesta palaamisesta, joihin yksittäinen malli joutuu, koska kukaan ei huomaa sen harha-askelia niiden tapahtuessa. Parvi huomaa ne, joten niistä ei koskaan tarvitse maksaa.

Aiemmin Fortytwo antoi mallien arvioida toistensa valmiita vastauksia, kun taas nykyisessä arkkitehtuurissa ne voivat vaikuttaa päättelyprosessiin jo sen aikana, kun sitä tuotetaan. Mitä opitte aiemmasta lähestymistavasta, ja miksi reaaliaikainen ohjaus toimii paremmin?

Vuoden 2025 arkkitehtuuri osoitti, että huipputason mallien kyvykkyyksiin voidaan päästä vaakasuuntaisella skaalauksella: osallistuvia malleja lisäämällä sen sijaan, että tavoiteltaisiin mahdollisimman suurta yksittäistä mallia. Toistensa valmiita vastauksia arvioiva avoimilla painoilla toimivien mallien parvi päihitti parven parhaan yksittäisen mallin jopa 17 prosenttiyksiköllä. Se oli myös toimintavarma tavoilla, joihin yksittäinen malli ei pysty: se kesti kohinaisia kehotteita, syötettyjä ohjeita ja tilanteita, joissa enemmistö vastauksista oli vääriä.

Arkkitehtuuri ei kuitenkaan pystynyt puuttumaan tilanteeseen. Valmiiden vastausten arviointi toimii yksittäisessä kysymyksessä, mutta agentin suoritukseen kuuluu satoja vaiheita ja niiden välissä tehtäviä työkalukutsuja, ja ratkaisevat virheet tapahtuvat varhain ja kasaantuvat. Lopussa tehtävä arviointi tarkoittaa, että jokainen malli on jo maksanut kaikki tokenikulut, ja arvioija voi valita vain jo toisistaan erkaantuneiden etenemispolkujen välillä. Lisäksi parven kustannukset kasvoivat mallien määrän mukana. Se sopii yhteen vaikeaan kysymykseen, mutta ei koodausagentille.

Reaaliaikainen ohjaus ratkaisee molemmat ongelmat. Jatkuva järjestäminen asettaa valintapaineen koko suorituksen ajaksi, joten huono suunta korjataan heti, ennen kuin se ehtii levitä. Parvi ei tyydy laiskaan yritykseen, sillä huolellisempi yritys sijoittuu arvioinnissa sitä paremmin. Siksi sama mekanismi tuottaa nyt sekä paremman tarkkuuden että pienemmän tokenimäärän.

Qwen 3.8 27B -mallilla tekemissänne testeissä Fortytwo kertoo käyttäneensä 24,7 % vähemmän tokeneita 450 DeepSWE-suorituksessa ja parantaneensa samalla tuloksia kuudessa vertailutestissä. Mitä parven sisällä tapahtuu, kun sen avulla voidaan parantaa suorituskykyä ja samalla vähentää tokenien kulutusta?

Parven tekemillä tarkistuksilla on pieni, kiinteä kustannus. Niillä estettyjen virheiden korjaamisesta syntyvät säästöt kasvavat tehtävän pituuden myötä, sillä jokainen korjaamatta jäänyt harha-askel maksaa kaiken sen, mitä sen varaan rakennetaan. Mitä pidempi tehtävä siis on, sitä enemmän voidaan säästää. DeepSWE sijoittuu tämän vaihteluvälin pitkään päähän, minkä vuoksi säästö on lähes neljännes kaikista tokeneista.

Tarkkuuden paraneminen liittyy älykkyyden epätasaisuuteen. Mallien kehitys on tavallisesti epätasaista: yhdellä osa-alueella malli voi päättellä tohtoritasoisesti ja toisella tuottaa täyttä hölynpölyä, sillä hienosäätö, vahvistusoppiminen ja muu jälkikoulutus parantavat mallia sen koulutusdatan pohjalta, ja hyödyt pienenevät, kun todelliset tehtävät etääntyvät tästä datasta. Swarm Decoder ei muuta mallia. Se parantaa itse päättelyä johdonmukaisesti, joten kuusi vertailutestiä eivät ole kuusi osa-aluetta, joita varten optimoimme, vaan kuusi paikkaa, joissa mittasimme samaa asiaa. Kaiken kaikkiaan malli on älykkäämpi ja tarkkaavaisempi, ja kun vertaiset tarkistavat jokaisen vaiheen, vaikuttaa siltä, että se panostaa tehtävääsi paljon enemmän. Siksi voimme myös hinnoitella Enginen mallin tokenikohtaisen hinnan mukaan: asiakas ei maksa suuremmasta budjetista vaan lyhyemmästä reitistä oikeaan vastaukseen.

Tekoälykehittäjät ovat yhä huolestuneempia inferenssin kustannuksista, kun päättelymallit tuottavat yhä pidempiä tokenketjuja. Voisiko itse päättelyprosessin tehostaminen mielestäsi lopulta olla yhtä tärkeää kuin yksittäisten mallien pienentäminen, nopeuttaminen tai halventaminen?

Kyllä, ja väittäisin, että se on jo nyt suurempi vaikutuskeino. Mallien pienentäminen, nopeuttaminen ja halventaminen laskee tokenin hintaa. Mutta kukaan ei osta tokeneita. Ihmiset ostavat valmiin tehtävän, ja agenttien aikakaudella tehtävää kohti tarvittavien tokenien määrä on räjähtänyt: tosielämän koodaustehtävää suorittava päättelymalli käyttää miljoonia tokeneita, joista suuri osa kuluu samoihin asioihin palaamiseen. Tokenien vähentäminen 25 prosentilla tehtävää kohti vastaa täsmälleen 25 prosentin hinnanalennusta, mutta sen lisäksi hyöty kasautuu jokaisen laitteistoa, kvantisointia ja kerneleitä koskevan parannuksen kanssa. Voimme soveltaa tätä mihin tahansa markkinoilla olevaan avoimilla painoilla julkaistuun malliin.

Alalla on kolme vaikutuskeinoa. Paremmat mallit, eli kouluttaminen, joka on kallista. Halvemmat tokenit, mikä edellyttää laitteistoa ja mallien tarjoamista, ja jonka osalta tilanne tasoittuu, koska kaikilla on samat näytönohjaimet. Sekä pienempi tokenimäärä tehtävää kohti, mikä riippuu inferenssin toteutustavasta ja on jäänyt lähes tutkimatta. Tähänastinen skaalaaminen on tarkoittanut suurempia malleja ja pidempiä ajatusketjuja, ja molemmissa yhden mallin odotetaan hoitavan kaiken yhden päättelypolun aikana. Uskomme, että seuraava kehityssuunta on kollektiivinen: useat mallit päättelevät yhdessä ja jakavat harkintakyvyn keskenään, jolloin itse päättelypolusta tulee lyhyempi ja luotettavampi. Se on erilaista skaalaamista kuin parametrien lisääminen tai laskennan kasvattaminen testiaikana, ja siihen me panostamme. Ajattelemme sitä vertaisina parametrien sijaan.

Fortytwo Engine on yhteensopiva OpenAI API:n kanssa ja käyttää avoimilla painoilla julkaistuja malleja. Kuinka tärkeää yhteensopivuus olemassa olevien tekoälykehityspinojen kanssa oli, ja kuinka helposti kehittäjät voivat siirtää sovelluksen tavanomaisesta yhden mallin rajapinnasta parviarkkitehtuuriin?

Yhteensopivuus on välttämätöntä. Agenttiekosysteemi – koodausagentit, agenttien ajoympäristöt, kehykset ja arviointityökalut – perustuu OpenAI API:n rakenteeseen. Siksi Fortytwo Engineä käyttäville kehittäjille vaihtaminen on kuin siirtyminen inferenssipalveluntarjoajalta toiselle: yhteensopivassa sovelluksessa, agentissa, ajoympäristössä tai palvelussa riittää yleensä yksi määritysmuutos: päätepisteen, API-avaimen ja mallivalinnan vaihtaminen.

Muuttuu toiminta, ei integraatio. Ero näkyy pitkissä agenttimaisissa ajoissa, joissa tokenien kulutus ja tarkkuus ensimmäisellä yrityksellä ratkaisevat kustannukset: sama malli suorittaa tehtävän Engine-palvelun kautta nopeammin ja pienemmällä tokenimäärällä sekä ratkaisee useamman tehtävän oikein. Neuvon suhtautumaan tähän kuten mihin tahansa mallin vaihtoon: suorita agentillasi jo käyttämäsi arviointi, vertaa tehtävää kohti tarvittavien tokenien määrää ja onnistumisastetta ja pidä käytössä se, joka toimii paremmin.

Kiitos hienosta haastattelusta. Lukijoiden, jotka haluavat tutustua parvi-inferenssiin ja siihen, miten vertaisarviointi voi tehostaa päättelyä, kannattaa käydä osoitteessa Fortytwo.