Ivan Nikitin, generální ředitel a spoluzakladatel Fortytwo – série rozhovorů

Ivan Nikitin je generálním ředitelem a spoluzakladatelem Fortytwo, kde vyvíjí technologii inferování pomocí roje, která propojuje více modelů AI, aby společně uvažovaly a vzájemně hodnotily svou práci. Jeho zkušenosti zahrnují hry, konverzační AI, generativní AI a interaktivní systémy ve společnostech Temporal a Sensorium. V roce 2011 spoluzaložil Temporal s Vladem Larinem, který je nyní spoluzakladatelem a technickým ředitelem Fortytwo. Získali tam zkušenosti s vyvíjejícími se populacemi agentů a systémy, které kombinují specializované modely.

Fortytwo buduje infrastrukturu AI, která modelům umožňuje spolupracovat během inferování. Její Fortytwo Engine využívá Swarm Decoder k usměrňování společného procesu uvažování v průběhu jeho vývoje a snaží se tak zvýšit přesnost a omezit zbytečné generování tokenů při dlouhých úlohách. Společnost nabízí vývojářům API prostřednictvím Fortytwo Engine a možnost lokálního nasazení prostřednictvím Fortytwo Harbor.

Než jste spoluzaložil Fortytwo, strávil jste řadu let vývojem produktů zaměřených na konverzační AI, generativní AI a interaktivní systémy ve společnostech Sensorium a Temporal. Jak tyto zkušenosti ovlivnily váš pohled na limity jednotlivých velkých jazykových modelů a jak vás nakonec přivedly k přístupu založenému na roji, na němž Fortytwo stojí?

Velká část našeho týmu, včetně mě, se k AI dostala přes hry. Hry byly kolébkou osobních počítačů i moderní AI: právě díky nim existují GPU a hraní her bylo prvním seriózním testovacím prostředím pro posilované učení. Herní světy nám poskytly praktické prostředí pro vytváření agentů, kteří se dokázali učit, přizpůsobovat a soutěžit. V Temporal, které jsem v roce 2011 spoluzaložil s Vladem Larinem, nynějším spoluzakladatelem a technickým ředitelem Fortytwo, jsme se nejprve zabývali vyvíjející se inteligencí: populacemi agentů, kteří soutěžili pod selekčním tlakem. Zajímalo nás, jak může populace dosáhnout více než jeden agent, pokud existuje dobrý mechanismus k rozpoznání jejích nejsilnějších příspěvků a navázání na ně. Výběr a hodnocení se staly ústředními prvky našeho přemýšlení o inteligenci.

Když se objevily modely typu transformer, rozšířili jsme své působení do oblasti konverzační AI a vytvořili platformu pro postavy řízené AI, které dokázaly vést otevřené, neskriptované rozhovory a měly paměť i osobnost. Bylo to pár let před ChatGPT a modely, s nimiž jsme pracovali, měly kontextová okna o velikosti pouhých 512 až 1 024 tokenů. Bylo nemyslitelné spoléhat na to, že jeden raný jazykový model spolehlivě zvládne všechny různé požadavky takového prostředí. Museli jsme vytvořit vlastní sestavu specializovaných modelů, z nichž každý měl užší odpovědnost, a logiku pro spojování jejich příspěvků. Pořadí a výběr odpovědí byly pro fungování celého prostředí zásadní. Díky tomu jsme pochopili, kolik schopností lze získat spojením omezených modelů do dobře navrženého systému.

Dalším poučením byla efektivita. Zjistili jsme, že specializované modely lze pro přesně vymezené úlohy trénovat a provozovat efektivněji, a s omezenými výpočetními prostředky tak dosáhnout více. Škálování inferování však zůstávalo výzvou: na jedné straně byly limity využití API, na druhé náklady na vlastní provoz ve velkém měřítku. Protože jsme neměli přístup ke špičkovým výpočetním kapacitám, museli jsme pečlivě zvažovat, jak dostupné zdroje využít co nejlépe. Fortytwo spojilo tato poučení do vize inferování pomocí roje: více modelů, případně více instancí téhož modelu, se podílí na uvažování a zároveň hodnotí práci ostatních. Výsledkem je, že celek je přesnější než kterýkoli z jeho členů.

Fortytwo Engine využívá několik modelů s otevřenými vahami k usměrňování jediného procesu uvažování a ke vzájemné kontrole v průběhu vytváření odpovědi. V čem se tento přístup liší od běžných víceagentních systémů, modelových souborů nebo prostého spuštění několika modelů a následného výběru nejlepší odpovědi?

Klíčový rozdíl spočívá v tom, že inferování pomocí roje je přímo zabudováno do inferenčního enginu, který jsme vyvinuli. Říkáme mu Swarm Decoder: více modelových účastníků průběžně formuje jedinou trajektorii uvažování v okamžiku jejího vzniku. Hodnocení a usměrňování probíhá přímo v tomto procesu, takže modely mohou ovlivnit jeho směr ještě před dokončením odpovědi.

Alternativy fungují jinak. V souboru modelů na úrovni odpovědí vytvářejí modely samostatné odpovědi, které se pak seřadí, vyberou nebo zkombinují. Původní architektura Fortytwo, nasazená v roce 2025, využívala vzájemné hodnocení dokončených odpovědí. Výrazně tím zvýšila přesnost odpovědí, ale za cenu vyšší latence a výpočetní režie. Mnohé běžné víceagentní systémy rozdělují práci mezi agenty a jejich příspěvky řídí pomocí koordinátoru a zpráv v přirozeném jazyce. Taková předávání mohou vyžadovat další inferenční volání, opakování kontextu a rozhodování o tom, které informace předat jednomu agentovi od druhého. Ve Swarm Decoderu k žádnému předávání nedochází: účastníci pracují na jediné trajektorii a vyměňují si pouze úsudky o tom, který směr je lepší.

Swarm Decoder je navržen tak, aby během generování zachytil slabé předpoklady dřív, než se na jejich základě začne vynakládat značné úsilí. Cílem je omezit chyby, vracení se k předchozím krokům a zbytečné generování; přínos pro efektivitu nastává tehdy, když kontrola zabrání většímu množství práce, než kolik sama přidá. Proto také nevzniká žádná penalizace za latenci: běh se ubírá přímější cestou, takže Engine dokončuje úlohy rychleji než tentýž model samostatně a spotřebuje celkově méně tokenů, počítáme-li všechny zúčastněné modely.

Jako zásadní problém jste označil drift modelů při dlouhotrvajících úlohách. Co tento drift vlastně způsobuje a jak se projevuje v praktických aplikacích, jako jsou softwarové inženýrství, výzkum nebo autonomní agenti AI?

K driftu dochází, když se kontext modelu postupně přestane týkat řešené úlohy. Při dlouhém běhu se kontext zaplňuje vlastním výstupem modelu, výsledky nástrojů, obsahem souborů a opakovanými pokusy. Původní instrukce tak tvoří stále menší část toho, čemu model věnuje pozornost, a jeho dřívější chyby se stávají součástí vstupu, z něhož vychází při uvažování. Chyby se proto vrství, místo aby se vzájemně vyrušily. Kromě toho se dnešní modely pro uvažování trénují pomocí posilovaného učení tak, aby dokončovaly úlohy, a učí se zkratkám, které jako dokončení pouze vypadají: vynechat volání nástroje, prohlásit úlohu za splněnou nebo místo ověření nabídnout shrnutí. Říkáme tomu lenost a pokročilé modely se jí dopouštějí stejně jako modely s otevřenými vahami. Základní příčinou je, že jediný model nemá žádnou externí kontrolu. Hodnotí vlastní práci, přitom modely nedokážou dobře a přesně reflektovat vlastní výkon.

V softwarovém inženýrství se to projevuje tak, že agent opraví popsanou chybu, ale poruší omezení uvedené v první zprávě, napíše test, který projde až příliš snadno, nebo čtyřikrát přečte tentýž soubor, protože ztratil přehled o tom, co už zjistil. Ve výzkumu jde o dlouhý běh, který se odkloní od položené otázky k otázce, na niž lze nejsnáze odpovědět, a skončí obecným shrnutím. U autonomních agentů má drift nákladnější podobu: odbočování od tématu, opakované volání nástrojů, vracení se k předchozím krokům a účet za tokeny několikanásobně vyšší, než úloha vyžadovala.

Můžeme to vyjádřit čísly. Model Qwen 3.8 27B jsme nasadili na 450 úlohách DeepSWE, tedy na skutečných úlohách softwarového inženýrství, při nichž se používají nástroje a pracuje s dlouhým kontextem. Jednou běžel samostatně a podruhé prostřednictvím Fortytwo Engine. Samostatně model v průměru spotřeboval 16,3 milionu tokenů na jeden běh, celkem 7,4 miliardy. Prostřednictvím Engine spotřeboval tentýž model v průměru 12,3 milionu tokenů na běh, celkem 5,6 miliardy, tedy o 24,7 % méně, a vyřešil více úloh: 47,8 % oproti 42,2 %. Na modelu se nic nezměnilo. Čtyři miliony tokenů na běh, které odpadly, představovaly drift: opakované čtení, další pokusy a vracení se k předchozím krokům, k nimž se jediný model musí uchylovat, protože nikdo nezachytí jeho chybné odbočky v okamžiku, kdy k nim dochází. Roj je zachytí, takže za ně vůbec nemusí platit.

Dříve Fortytwo nechávalo modely hodnotit odpovědi, které ostatní již dokončily, zatímco současná architektura jim umožňuje ovlivňovat proces uvažování už během jeho vytváření. Co jste se naučili z předchozího přístupu a proč je účinnější řídit proces v reálném čase?

Architektura z roku 2025 prokázala, že můžeme dosáhnout schopností na úrovni nejpokročilejších modelů horizontálním škálováním – zapojením většího počtu modelů namísto snahy překonat ostatní sázkou na ten největší. Roj modelů s otevřenými vahami, které vzájemně řadily své úplné odpovědi, překonal nejlepší samostatný model v roji až o 17 procentních bodů a byl odolný způsobem, jakým jediný model odolný není: vůči zašuměným promptům, vloženým instrukcím i situacím, kdy se většina odpovědí mýlí.

Tato architektura však nedokázala do procesu zasáhnout. Řazení dokončených odpovědí funguje u jediné otázky, ale běhy agentů zahrnují stovky kroků s voláním nástrojů mezi nimi a rozhodující chyby vznikají brzy a dále se násobí. Hodnocení na konci znamená, že každý model už zaplatil plnou cenu za všechny tokeny, a hodnotitel může vybírat pouze mezi postupy, které se již rozešly. Znamenalo to také, že náklady na roj rostly s počtem modelů. To je přijatelné u jedné náročné otázky, ale pro programovacího agenta je to nevhodné.

Řízení v reálném čase řeší oba problémy. Průběžné řazení vytváří tlak na výběr po celou dobu běhu, takže se chybný krok napraví přímo v místě, kde vznikne, ještě než se jeho důsledky rozšíří. Roj se nikdy nespokojí s ledabylým pokusem, protože v pořadí zaostane za pečlivějším. Proto nám nyní stejný mechanismus současně přináší vyšší přesnost i nižší spotřebu tokenů.

Při testování modelu Qwen 3.8 27B společnost Fortytwo uvádí, že v 450 bězích DeepSWE spotřebovala o 24,7 % méně tokenů a zároveň zlepšila výsledky v šesti benchmarkových testech. Co se děje uvnitř roje, že dokáže zlepšit výkon a současně snížit spotřebu tokenů?

Kontrola roje má malé a pevně dané náklady; náklady na nápravu, kterým předchází, rostou s délkou úlohy, protože každý nenapravený chybný krok zatěžuje vše, co na něm vzniká. Čím delší je tedy úloha, tím více lze ušetřit. DeepSWE patří k časově náročnějším úlohám, a proto úspora dosahuje téměř čtvrtiny všech tokenů.

Pokud jde o přesnost, jde o nerovnoměrnou inteligenci. Zlepšení modelů bývají obvykle nerovnoměrná: v jedné oblasti získáte uvažování na úrovni doktorského studia, v jiné naprosté nesmysly. Důvodem je, že dolaďování, posilované učení a další postupy po trénování zlepšují model na datech, na nichž byl trénován, zatímco přínosy se zmenšují, jak se skutečné úlohy od těchto dat vzdalují. Swarm Decoder do modelu nezasahuje. Důsledně zlepšuje samotné uvažování, takže šest benchmarkových testů nepředstavuje šest oblastí, na něž jsme model optimalizovali; jsou to jen šest míst, kde jsme měřili totéž. Celkově je model chytřejší a pozornější. Když jeho každý krok kontrolují ostatní modely, působí to, jako by vašemu úkolu věnoval mnohem větší úsilí. Proto také můžeme cenu Engine stanovit na stejnou sazbu za token jako u základního modelu: zákazník neplatí za větší rozpočet tokenů, ale za kratší cestu ke správné odpovědi.

Vývojáři AI se stále více obávají nákladů na inferenci, protože modely pro uvažování vytvářejí delší řetězce tokenů. Myslíte si, že zvyšování efektivity samotného procesu uvažování by nakonec mohlo být stejně důležité jako zmenšování jednotlivých modelů, zvyšování jejich rychlosti nebo snižování jejich ceny?

Ano, a řekl bych, že jde už teď o významnější páku. Zmenšení, zrychlení a zlevnění modelů snižuje cenu tokenu. Nikdo si ale tokeny nekupuje. Lidé si kupují hotový výsledek úkolu a v éře agentů prudce vzrostl počet tokenů potřebných na jeden úkol: model pro uvažování spotřebuje při řešení skutečného programátorského úkolu miliony tokenů a značnou část z nich při opakovaném vracení se k již probraným krokům. Snížení počtu tokenů na úkol o 25 % má přesně stejnou hodnotu jako zlevnění o 25 %, jenže tento přínos se sčítá s každým zlepšením hardwaru, kvantizace a výpočetních jader a můžeme ho uplatnit na jakýkoli otevřený model dostupný na trhu.

Odvětví má tři páky. Lepší modely, což znamená trénování, které je nákladné. Levnější tokeny, což závisí na hardwaru a provozu modelů; tyto náklady se sbližují, protože všichni používají stejné GPU. A méně tokenů na úkol, což závisí na způsobu provádění inference a zůstává téměř neprozkoumanou oblastí. Dosavadní škálování znamenalo větší modely a delší řetězce myšlenek; v obou případech má jeden model zvládnout všechno v rámci jediné trajektorie. Domníváme se, že další osou škálování je kolektivní přístup: několik modelů uvažuje společně a úsudek se mezi ně rozděluje, takže samotná trajektorie je kratší a spolehlivější. Jde o jiný druh škálování než navyšování počtu parametrů nebo výpočtů při odvozování a právě na ten sázíme. Říkáme tomu přednost spolupráce modelů před větším počtem parametrů.

Fortytwo Engine je kompatibilní s API OpenAI a zároveň využívá modely s otevřenými vahami. Jak důležitá byla kompatibilita se stávajícími vývojářskými nástroji pro AI a jak snadno mohou vývojáři převést aplikaci z běžného API pro jeden model na architekturu typu swarm?

Kompatibilita je zásadní. Ekosystém agentů — programovací agenti, orchestrační prostředí, frameworky i nástroje pro vyhodnocování — je postaven na podobě API OpenAI. Pro vývojáře, kteří využívají Fortytwo Engine, je proto přechod podobný změně poskytovatele inference: u kompatibilní aplikace, agenta, orchestračního prostředí nebo služby obvykle stačí změnit jedinou konfiguraci, konkrétně koncový bod, klíč API a výběr modelu.

Mění se chování, nikoli integrace. Rozdíl se projeví při dlouhých bězích agentů, kde náklady určují spotřeba tokenů a přesnost při prvním pokusu: tentýž model prostřednictvím Engine dokončí úkol rychleji, s menším počtem tokenů a více úkolů vyřeší správně. Doporučuji přistupovat k tomu jako k výměně jakéhokoli jiného modelu: spusťte vyhodnocení, které už pro svého agenta používáte, porovnejte počet tokenů na úkol a úspěšnost a ponechte si variantu s lepším výsledkem.

Děkuji za skvělý rozhovor. Čtenáři, kteří chtějí blíže poznat inferenci typu swarm a zjistit, jak může vzájemné hodnocení zlepšit efektivitu uvažování, mohou navštívit Fortytwo.