Ivan Nikitin, dyrektor generalny i współzałożyciel Fortytwo – cykl wywiadów

Ivan Nikitin jest dyrektorem generalnym i współzałożycielem Fortytwo, gdzie rozwija technologię wnioskowania roju, która łączy wiele modeli AI, aby mogły wspólnie rozumować i oceniać nawzajem swoją pracę. Jego doświadczenie obejmuje gry, konwersacyjną AI, generatywną AI oraz systemy interaktywne tworzone w Temporal i Sensorium. W 2011 roku wraz z Vladem Larinem założył Temporal. Larin jest obecnie współzałożycielem i dyrektorem technicznym Fortytwo. Praca nad Temporal pozwoliła mu zdobyć doświadczenie w rozwijaniu populacji agentów i systemów łączących wyspecjalizowane modele.

Fortytwo tworzy infrastrukturę AI, która umożliwia modelom współpracę podczas wnioskowania. Fortytwo Engine wykorzystuje Swarm Decoder do kierowania wspólnym procesem rozumowania w miarę jego przebiegu, dążąc do zwiększenia dokładności i ograniczenia zbędnego generowania tokenów w przypadku długich zadań. Firma udostępnia programistom API za pośrednictwem Fortytwo Engine, a także oferuje wdrożenie lokalne za pośrednictwem Fortytwo Harbor.

Zanim współzałożył Pan Fortytwo, przez lata tworzył Pan w Sensorium i Temporal produkty oparte na konwersacyjnej AI, generatywnej AI i systemach interaktywnych. Jak te doświadczenia ukształtowały Pana pogląd na ograniczenia pojedynczych dużych modeli językowych i ostatecznie doprowadziły do opracowania podejścia opartego na roju, które stoi za Fortytwo?

Znaczna część naszego zespołu, w tym ja, trafiła do świata AI przez gry. Gry były kolebką komputerów osobistych i nowoczesnej AI: to im zawdzięczamy powstanie GPU, a rozgrywka była pierwszym poważnym poligonem doświadczalnym dla uczenia ze wzmocnieniem. Światy gier zapewniły nam praktyczne środowisko do tworzenia agentów zdolnych do uczenia się, adaptacji i rywalizacji. W Temporal, które założyłem w 2011 roku wraz z Vladem Larinem, obecnie współzałożycielem i dyrektorem technicznym Fortytwo, zaczęliśmy od rozwijającej się inteligencji: populacji agentów rywalizujących pod presją selekcyjną. Interesowało nas, jak populacja może osiągnąć więcej niż pojedynczy agent, o ile istnieje dobry mechanizm pozwalający rozpoznawać jej najcenniejszy wkład i rozwijać go. Selekcja i ocena stały się kluczowe dla naszego sposobu myślenia o inteligencji.

Gdy pojawiły się modele oparte na transformerach, rozszerzyliśmy działalność o konwersacyjną AI i stworzyliśmy platformę dla postaci sterowanych przez AI, które mogły prowadzić otwarte, niescenariuszowe rozmowy, dysponując pamięcią i osobowością. Było to kilka lat przed ChatGPT, a modele, nad którymi pracowaliśmy, miały okna kontekstowe obejmujące zaledwie od 512 do 1024 tokenów. Nie mogliśmy oczekiwać, że jeden wczesny model językowy będzie niezawodnie spełniał wszystkie różnorodne wymagania takiego rozwiązania. Musieliśmy zbudować własny potok wyspecjalizowanych modeli, z których każdy odpowiadał za węższy zakres zadań, oraz mechanizm łączący ich wkład. Ocenianie i wybieranie odpowiedzi stało się niezbędne, by całe rozwiązanie działało. Dzięki temu zrozumieliśmy, jak wiele możliwości można uzyskać, łącząc ograniczone modele w dobrze zaprojektowany system.

Drugą ważną lekcją była wydajność. Przekonaliśmy się, że wyspecjalizowane modele można efektywniej trenować i udostępniać do jasno określonych zadań, dzięki czemu przy ograniczonych zasobach obliczeniowych można osiągnąć więcej. Skalowanie wnioskowania nadal jednak stanowiło wyzwanie: z jednej strony ograniczały nas limity użycia API, a z drugiej — koszty samodzielnego hostowania na dużą skalę. Nie mając dostępu do mocy obliczeniowej czołowych modeli, musieliśmy starannie przemyśleć, jak lepiej wykorzystać dostępne zasoby. W Fortytwo połączyliśmy te doświadczenia w koncepcji wnioskowania roju: wiele modeli albo wiele instancji tego samego modelu wspólnie uczestniczy w rozumowaniu, oceniając przy tym pracę pozostałych. Dzięki temu całość osiąga większą dokładność niż każdy z jej elementów.

Fortytwo Engine wykorzystuje kilka modeli o otwartych wagach, aby kierować pojedynczym procesem rozumowania i wzajemnie sprawdzać ich działanie w trakcie generowania odpowiedzi. Czym to podejście różni się od tradycyjnych systemów wieloagentowych, zespołów modeli lub po prostu uruchomienia kilku modeli i wybrania później najlepszej odpowiedzi?

Kluczowa różnica polega na tym, że wnioskowanie roju jest bezpośrednio wbudowane w opracowany przez nas silnik wnioskowania. Nazywamy to rozwiązanie Swarm Decoder: wielu uczestników-modeli nieustannie kształtuje jeden tok rozumowania w trakcie jego generowania. Ocena i ukierunkowywanie odbywają się w ramach tego procesu, dzięki czemu modele mogą wpływać na jego przebieg, zanim odpowiedź będzie gotowa.

Inne rozwiązania działają inaczej. W przypadku zespołu modeli na poziomie odpowiedzi modele generują osobne odpowiedzi, które są następnie oceniane, wybierane lub łączone. Pierwotna architektura Fortytwo, wdrożona w 2025 roku, wykorzystywała wzajemne ocenianie gotowych odpowiedzi. Znacząco poprawiło to ich dokładność, ale zwiększyło opóźnienia i obciążenie obliczeniowe. Wiele tradycyjnych systemów wieloagentowych dzieli pracę między agentów, wykorzystując orkiestratora i komunikaty w języku naturalnym do koordynowania ich wkładu. Takie przekazywanie zadań może wymagać dodatkowych wywołań modelu, ponownego przekazywania kontekstu oraz decydowania, które informacje przekazać kolejnemu agentowi. W Swarm Decoder nie ma przekazywania zadań: uczestnicy pracują nad jednym tokiem rozumowania, a jedyne, co sobie przekazują, to ocena, który kierunek jest lepszy.

Swarm Decoder ma wykrywać słabe założenia w trakcie generowania, zanim zostanie włożony znaczny wysiłek w rozwijanie ich konsekwencji. Celem jest ograniczenie błędów, konieczności cofania się i zbędnego generowania; korzyść pod względem wydajności pojawia się wtedy, gdy dzięki sprawdzaniu można uniknąć większej ilości pracy, niż samo sprawdzanie jej wymaga. Dlatego nie ma też kary w postaci opóźnień: przebieg zadania jest bardziej bezpośredni, więc Engine wykonuje je szybciej niż samodzielnie działający ten sam model i zużywa łącznie mniej tokenów, przy czym uwzględnia się tokeny wszystkich uczestniczących modeli.

Wskazałeś dryf modeli podczas długotrwałych zadań jako poważny problem. Co właściwie go powoduje i jak przejawia się w praktycznych zastosowaniach, takich jak inżynieria oprogramowania, badania naukowe czy autonomiczni agenci AI?

Dryf występuje wtedy, gdy kontekst modelu stopniowo przestaje dotyczyć wykonywanego zadania. Podczas długiego przebiegu kontekst wypełnia się własnymi odpowiedziami modelu, wynikami działania narzędzi, zawartością plików i ponawianymi próbami. Pierwotna instrukcja stanowi coraz mniejszą część tego, na czym skupia się model, a jego wcześniejsze błędy stają się częścią danych wejściowych, na których opiera swoje rozumowanie. W rezultacie błędy się nawarstwiają, zamiast wzajemnie znosić. Ponadto współczesne modele rozumujące są trenowane z użyciem uczenia ze wzmocnieniem, aby kończyły zadania, i uczą się na skróty, które tylko sprawiają wrażenie ich ukończenia: pomijają wywołanie narzędzia, ogłaszają sukces, podsumowują zamiast weryfikować. Nazywamy to lenistwem, a modele czołowe przejawiają je równie często co modele z otwartymi wagami. U podstaw problemu leży brak zewnętrznej kontroli nad pojedynczym modelem. Sam ocenia swoją pracę, a modele słabo radzą sobie z jej rzetelną samooceną.

W inżynierii oprogramowania widać to, gdy agent naprawia opisany przez ciebie błąd, ale narusza ograniczenie podane w pierwszej wiadomości, pisze test, który przechodzi bez trudu, albo cztery razy odczytuje ten sam plik, bo nie pamięta, czego już się z niego dowiedział. W badaniach naukowych przejawia się to w długim przebiegu, który stopniowo odchodzi od zadanego pytania w stronę pytania, na które najłatwiej odpowiedzieć, i kończy się ogólnikowym podsumowaniem. W przypadku autonomicznych agentów oznacza to kosztowną wersję problemu: dygresje, wielokrotne wywoływanie narzędzi, cofanie się i rachunek za tokeny wynoszący kilkakrotność tego, czego wymagało zadanie.

Możemy to zmierzyć. Uruchomiliśmy Qwen 3.8 27B w ramach 450 zadań DeepSWE — rzeczywistych zadań z zakresu inżynierii oprogramowania, wymagających użycia narzędzi przy długim kontekście — raz samodzielnie, a raz za pośrednictwem Fortytwo Engine. Samodzielnie model zużywał średnio 16,3 miliona tokenów na przebieg, łącznie 7,4 miliarda. Za pośrednictwem Engine ten sam model zużywał średnio 12,3 miliona tokenów na przebieg, łącznie 5,6 miliarda, czyli o 24,7% mniej, a przy tym rozwiązał więcej zadań: 47,8% wobec 42,2%. Sam model się nie zmienił. Cztery miliony tokenów na przebieg, których udało się uniknąć, to koszt dryfu: ponownego czytania, kolejnych prób i cofania się, do których musi uciekać się pojedynczy model, bo nikt nie wychwytuje jego błędnych posunięć na bieżąco. Rój je wychwytuje, więc nie trzeba ponosić związanych z nimi kosztów.

Wcześniej Fortytwo wykorzystywało modele do wzajemnej oceny ukończonych odpowiedzi, natomiast obecna architektura pozwala im wpływać na proces rozumowania już w trakcie jego generowania. Czego nauczyliście się dzięki wcześniejszemu podejściu i dlaczego sterowanie w czasie rzeczywistym jest skuteczniejsze?

Architektura z 2025 roku dowiodła, że możemy osiągnąć możliwości na poziomie modeli czołowych dzięki skalowaniu horyzontalnemu — angażując więcej modeli zamiast koncentrować się na największym. Rój modeli z otwartymi wagami, które oceniały kompletne odpowiedzi innych modeli, przewyższył najlepszy pojedynczy model w roju nawet o 17 punktów procentowych. Był też odporny na czynniki, którym pojedynczy model nie potrafi się przeciwstawić: chaotyczne prompty, wstrzyknięte instrukcje i większość błędnych odpowiedzi.

Ta architektura nie pozwalała jednak na interwencję. Ocenianie ukończonych odpowiedzi sprawdza się w przypadku pojedynczego pytania, ale przebiegi pracy agentów obejmują setki kroków, pomiędzy którymi następują wywołania narzędzi, a decydujące błędy pojawiają się na wczesnym etapie i się nawarstwiają. Ocena na końcu oznacza, że każdy model poniósł już pełny koszt tokenów, a oceniający może jedynie wybrać spośród przebiegów, które zdążyły się już rozejść. Oznaczało to również, że koszt działania roju rósł wraz z liczbą modeli — co sprawdza się w przypadku jednego trudnego pytania, ale nie jest właściwym rozwiązaniem dla agenta programistycznego.

Sterowanie w czasie rzeczywistym rozwiązuje oba problemy. Ciągłe ocenianie oznacza wywieranie presji selekcyjnej przez cały przebieg, dzięki czemu błędny krok można skorygować w miejscu, w którym się pojawił, zanim jego skutki się rozprzestrzenią. Rój nie zadowala się leniwą próbą, ponieważ w rankingu przegrywa ona ze staranniejszą. Dlatego ten sam mechanizm zapewnia nam teraz jednocześnie większą dokładność i mniejsze zużycie tokenów.

W testach z użyciem Qwen 3.8 27B Fortytwo odnotowuje zużycie o 24,7% mniejszej liczby tokenów w 450 przebiegach DeepSWE oraz lepsze wyniki w sześciu testach porównawczych. Co dzieje się wewnątrz roju, że pozwala poprawiać wyniki, a jednocześnie ograniczać zużycie tokenów?

Weryfikacja prowadzona przez rój wiąże się z niewielkim, stałym kosztem; koszty naprawiania błędów, którym zapobiega, rosną wraz z długością zadania, ponieważ każdy nieskorygowany błędny krok pociąga za sobą koszt całej pracy zbudowanej na jego podstawie. Im dłuższe zadanie, tym więcej można więc zaoszczędzić, a DeepSWE znajduje się na długim końcu tego spektrum. Dlatego oszczędność wynosi niemal jedną czwartą wszystkich tokenów.

Jeśli chodzi o dokładność, problemem jest nierównomierność zdolności modelu. Ulepszenia modeli są zazwyczaj nierówne: w jednej dziedzinie model rozumuje na poziomie doktoratu, a w innej generuje kompletne bzdury, ponieważ dostrajanie, uczenie ze wzmocnieniem (RL) i inne metody trenowania po etapie wstępnym poprawiają model w zakresie danych, na których był trenowany, a korzyści maleją, gdy rzeczywiste zadania coraz bardziej odbiegają od tych danych. Swarm Decoder nie ingeruje w model. Systematycznie usprawnia samo rozumowanie, dlatego sześć testów porównawczych nie oznacza sześciu dziedzin, pod kątem których prowadziliśmy optymalizację — to sześć sposobów pomiaru tego samego. Ogólnie model jest inteligentniejszy i uważniejszy, a dzięki temu, że pozostałe modele sprawdzają każdy jego krok, wydaje się, że poświęca twojemu zadaniu znacznie więcej wysiłku. Dlatego możemy ustalić cenę Engine na poziomie stawki za token modelu bazowego: klient nie płaci za większy budżet, lecz za krótszą drogę do właściwej odpowiedzi.

Deweloperzy AI coraz bardziej niepokoją się kosztami wnioskowania, ponieważ modele rozumujące generują coraz dłuższe ciągi tokenów. Czy sądzisz, że poprawa efektywności samego procesu rozumowania może ostatecznie być równie ważna jak tworzenie mniejszych, szybszych lub tańszych modeli?

Tak. Uważam nawet, że to już ważniejsza dźwignia. Zmniejszanie modeli, przyspieszanie ich i obniżanie kosztów ich działania obniża cenę tokena. Ale nikt nie kupuje tokenów. Kupuje się gotowe rozwiązanie zadania, a w erze agentów liczba tokenów przypadających na zadanie gwałtownie wzrosła: model rozumujący wykonujący rzeczywiste zadanie programistyczne zużywa miliony tokenów, a znaczna ich część przypada na powracanie do wcześniejszych etapów. Ograniczenie liczby tokenów na zadanie o 25% daje dokładnie taką samą korzyść jak obniżenie ceny o 25%, a ponadto kumuluje się z każdą poprawą sprzętu, kwantyzacji i jąder obliczeniowych. Możemy zastosować tę metodę do każdego dostępnego na rynku modelu o otwartych wagach.

Branża ma do dyspozycji trzy dźwignie. Lepsze modele, co wymaga kosztownego treningu. Tańsze tokeny, co zależy od sprzętu i obsługi modeli, a w tym obszarze sytuacja się wyrównuje, bo wszyscy mają te same GPU. Oraz mniej tokenów na zadanie, co zależy od sposobu realizacji wnioskowania i pozostaje niemal niezbadanym obszarem. Dotychczas skalowanie oznaczało większe modele i dłuższe ciągi rozumowania, a w obu przypadkach jeden model ma zrobić wszystko w ramach jednego przebiegu. Uważamy, że kolejnym kierunkiem jest podejście kolektywne: kilka modeli rozumuje wspólnie, a ocena jest rozłożona między nie, dzięki czemu sam przebieg jest krótszy i bardziej niezawodny. To inny rodzaj skalowania niż zwiększanie liczby parametrów czy obliczeń w czasie testowania — i właśnie na niego stawiamy. Myślimy o tym jako o współpracy modeli zamiast zwiększania liczby parametrów.

Fortytwo Engine jest zgodny z OpenAI API i działa w oparciu o modele o otwartych wagach. Jak ważna była zgodność z istniejącymi stosami technologicznymi do rozwoju AI i jak łatwo deweloperzy mogą przenieść aplikację ze standardowego API obsługującego jeden model do architektury roju?

Zgodność jest niezbędna. Ekosystem agentów — obejmujący agentów programistycznych, środowiska wykonawcze, frameworki i narzędzia do ewaluacji — opiera się na formacie OpenAI API. Dlatego dla deweloperów korzystających z Fortytwo Engine zmiana przypomina przejście od jednego dostawcy usług wnioskowania do drugiego: w przypadku zgodnej aplikacji, agenta, środowiska wykonawczego lub usługi zwykle wystarczy zmienić jedną konfigurację: punkt końcowy, klucz API i wybrany model.

Zmienia się zachowanie, a nie sposób integracji. Różnica staje się widoczna podczas długich procesów agentowych, w których zużycie tokenów i skuteczność za pierwszym podejściem decydują o kosztach: ten sam model, uruchomiony przez Engine, kończy zadanie szybciej, zużywa mniej tokenów i poprawnie wykonuje więcej zadań. Radzę potraktować to jak każdą zmianę modelu: przeprowadzić ewaluację, której już używasz dla swojego agenta, porównać liczbę tokenów na zadanie i wskaźnik skuteczności, a następnie wybrać rozwiązanie, które wypada lepiej.

Dziękuję za świetny wywiad. Czytelnicy, którzy chcą dowiedzieć się więcej o wnioskowaniu roju i o tym, jak wzajemna ocena może poprawić efektywność rozumowania, powinni odwiedzić Fortytwo.