Fortytwo’nun CEO’su ve Kurucu Ortağı Ivan Nikitin – Röportaj Dizisi

Ivan Nikitin, birden fazla yapay zekâ modelini bir araya getirerek akıl yürütmelerini ve birbirlerinin çalışmalarını değerlendirmelerini sağlayan sürü çıkarımı teknolojisini geliştirdiği Fortytwo’nun CEO’su ve kurucu ortağıdır. Oyunlar, konuşmaya dayalı yapay zekâ, üretken yapay zekâ ve Temporal ile Sensorium’daki etkileşimli sistemler alanlarında deneyim sahibidir. 2011’de Vlad Larin ile birlikte Temporal’ı kurdu. Bugün Fortytwo’nun kurucu ortağı ve CTO’su olan Larin’le birlikte, gelişen ajan toplulukları ve uzmanlaşmış modelleri bir araya getiren sistemler konusunda deneyim kazandı.

Fortytwo, modellerin çıkarım sırasında iş birliği yapmasını sağlayan yapay zekâ altyapısı geliştiriyor. Fortytwo Engine, uzun görevlerde doğruluğu artırmayı ve gereksiz token üretimini azaltmayı amaçlayarak, ortak bir akıl yürütme sürecini ilerledikçe yönlendirmek için Swarm Decoder’ı kullanıyor. Şirket, geliştiricilere Fortytwo Engine üzerinden API, şirket içinde kurulum içinse Fortytwo Harbor sunuyor.

Fortytwo’yu kurmadan önce Sensorium ve Temporal’da konuşmaya dayalı yapay zekâ, üretken yapay zekâ ve etkileşimli sistemler üzerine ürünler geliştirmek için yıllarca çalıştınız. Bu deneyimler, büyük dil modellerinin tek başlarına hangi noktalarda yetersiz kaldığına ilişkin görüşünüzü nasıl şekillendirdi ve sonunda Fortytwo’nun temelindeki sürü yaklaşımına nasıl yönelmenizi sağladı?

Ben de dâhil olmak üzere ekibimizin önemli bir bölümü yapay zekâ alanına oyunlar üzerinden adım attı. Oyunlar, kişisel bilgisayarların ve modern yapay zekânın beşiği oldu: GPU’nun var olma nedeni oyunlardır ve oyunlar, pekiştirmeli öğrenmenin ilk ciddi sınama ortamıydı. Oyun dünyaları; öğrenebilen, uyum sağlayabilen ve rekabet edebilen ajanlar geliştirmek için bize uygulamalı bir ortam sundu. 2011’de Vlad Larin ile birlikte kurduğum Temporal’da, bugün Fortytwo’nun kurucu ortağı ve CTO’su olan Larin’le beraber, evrilen zekâ fikriyle yola çıktık: seçilim baskısı altında rekabet eden ajan toplulukları. İyi katkıları belirleyip bunların üzerine inşa etmeyi sağlayan bir mekanizma olduğu takdirde, bir topluluğun tek bir ajandan daha fazlasını nasıl başarabileceğini merak ediyorduk. Seçilim ve değerlendirme, zekâya bakışımızın merkezine yerleşti.

Transformer modeller ortaya çıktığında konuşmaya dayalı yapay zekâ alanına yöneldik ve bellek ile kişilik özelliklerine sahip, açık uçlu ve senaryosuz sohbetler yürütebilen yapay zekâ destekli karakterler için bir platform geliştirdik. Bu, ChatGPT’den birkaç yıl önceydi ve üzerinde çalıştığımız modellerin bağlam pencereleri yalnızca 512 ila 1.024 token uzunluğundaydı. O dönemin ilk dil modellerinden birinin bu deneyimin tüm farklı gereksinimlerini güvenilir biçimde karşılamasını beklemek söz konusu bile değildi. Daha dar kapsamlı sorumlulukları olan uzmanlaşmış modellerden ve bunların katkılarını bir araya getiren mantıktan oluşan özel bir işlem hattı kurmamız gerekti. Yanıtları sıralamak ve seçmek, deneyimin bütününün işlemesi için vazgeçilmez hâle geldi. Bu süreç, sınırlı yeteneklere sahip modelleri iyi tasarlanmış bir sistemde birleştirerek ne kadar çok kapasite elde edilebileceğini gösterdi.

Bir diğer ders de verimlilikti. Uzmanlaşmış modellerin iyi tanımlanmış görevler için daha verimli biçimde eğitilip sunulabildiğini ve böylece sınırlı işlem gücüyle daha fazlasını başarabileceğimizi öğrendik. Ancak çıkarımı ölçeklendirmek hâlâ zordu: Bir yanda API kullanım sınırları, diğer yanda büyük ölçekte kendi altyapısında barındırmanın maliyeti vardı. En ileri düzey işlem kapasitesine erişimimiz olmadığından, mevcut kaynaklardan nasıl daha fazla yararlanabileceğimizi dikkatle düşünmemiz gerekiyordu. Fortytwo, bu dersleri sürü çıkarımı vizyonunda bir araya getirdi: Akıl yürütmeye katkıda bulunurken akranlarının çalışmalarını da değerlendiren birden fazla model ya da aynı modelin birden fazla örneği. Sonuçta kolektif, üyelerinin her birinden daha isabetli oluyor.

Fortytwo Engine, tek bir akıl yürütme sürecini yönlendirmek ve yanıt oluşturulurken modellerin birbirini denetlemesini sağlamak için açık ağırlıklı birkaç model kullanıyor. Bu yaklaşım; geleneksel çok ajanlı sistemlerden, model topluluklarından ya da birkaç modeli çalıştırıp sonradan en iyi yanıtı seçmekten nasıl farklılaşıyor?

Temel fark, sürü çıkarımının geliştirdiğimiz çıkarım motoruna doğrudan entegre edilmiş olmasıdır. Buna Swarm Decoder adını veriyoruz: Birden fazla model katılımcısı, oluşturulurken tek bir akıl yürütme çizgisini sürekli olarak biçimlendiriyor. Değerlendirme ve yönlendirme bu sürecin içinde gerçekleşiyor; böylece modeller, yanıt tamamlanmadan önce sürecin yönünü etkileyebiliyor.

Alternatif yöntemler farklı işliyor. Yanıt düzeyinde topluluk yaklaşımında modeller birbirinden ayrı yanıtlar oluşturuyor; ardından bu yanıtlar sıralanıyor, seçiliyor ya da birleştiriliyor. 2025’te hayata geçirilen Fortytwo’nun ilk mimarisi, tamamlanmış yanıtların akranlar tarafından sıralanmasını kullanıyordu. Bu, yanıt doğruluğunu önemli ölçüde artırdı ancak gecikme süresini ve hesaplama yükünü de beraberinde getirdi. Geleneksel çok ajanlı sistemlerin çoğunda işler ajanlar arasında paylaştırılıyor; katkıları yönetmek için bir orkestratör ve doğal dilde mesajlar kullanılıyor. Bu aktarımlar ek çıkarım çağrıları, bağlamın tekrarlanması ve bir ajandan diğerine hangi bilgilerin iletileceğine ilişkin kararlar gerektirebiliyor. Swarm Decoder’da ise aktarım yok: Katılımcılar tek bir akıl yürütme çizgisi üzerinde çalışıyor ve yalnızca hangi yönün daha iyi olduğuna dair değerlendirmelerini paylaşıyor.

Swarm Decoder, zayıf varsayımları, bunların üzerine önemli ölçüde emek harcanmadan önce, üretim sırasında tespit edecek şekilde tasarlandı. Amaç; hataları, geri dönüp yeniden çalışma ihtiyacını ve gereksiz üretimi azaltmak. Verimlilik kazanımı, bu denetim eklediği işten daha fazlasını önlediğinde ortaya çıkıyor. Gecikme cezası olmamasının nedeni de bu: İşlem daha doğrudan bir yol izliyor. Böylece Engine görevleri, aynı modelin tek başına çalışmasına kıyasla daha hızlı ve katılan tüm modeller hesaba katıldığında toplamda daha az token kullanarak tamamlıyor.

Uzun süre devam eden görevlerde model kaymasının önemli bir sorun olduğuna dikkat çekmiştiniz. Bu kaymaya gerçekte ne yol açıyor ve yazılım mühendisliği, araştırma ya da otonom yapay zekâ ajanları gibi pratik uygulamalarda nasıl ortaya çıkıyor?

Kayma, modelin bağlamının zamanla görevle ilgisini yitirmesiyle ortaya çıkar. Uzun süren bir çalışmada bağlam; modelin kendi çıktıları, araç sonuçları, dosya içerikleri ve yeniden denemelerle dolar. Modelin dikkate aldığı içerikte ilk talimatın payı giderek küçülür; ayrıca model, daha önce yaptığı hataları da akıl yürütürken kullandığı girdinin bir parçası hâline getirir. Böylece hatalar birbirini götürmek yerine birikir. Üstelik günümüzün akıl yürütme modelleri, görevleri tamamlamaları için pekiştirmeli öğrenmeyle eğitiliyor ve tamamlamış gibi görünen kestirme yollar öğreniyor: araç çağrısını atlamak, başarıya ulaştığını ilan etmek, kontrol etmek yerine özetlemek. Biz buna tembellik diyoruz; en gelişmiş modeller de açık ağırlıklı modeller kadar bunu yapıyor. Temel neden, tek bir modeli dışarıdan denetleyen bir kontrol mekanizmasının olmaması. Model kendi çalışmasını değerlendiriyor, oysa modeller kendi performanslarını doğru biçimde değerlendirmekte başarılı değil.

Yazılım mühendisliğinde bu durum, tarif ettiğiniz hatayı düzeltirken ilk mesajınızda belirttiğiniz kısıtı ihlal eden, kolayca geçiveren bir test yazan ya da daha önce ne öğrendiğini unuttuğu için aynı dosyayı dört kez okuyan ajan olarak karşınıza çıkar. Araştırmada ise uzun süren çalışma, sorduğunuz sorudan yanıtlaması en kolay soruya doğru kayar ve sonunda genel geçer bir özet sunar. Otonom ajanlarda bunun maliyeti yüksektir: konu dışına sapmalar, yinelenen araç çağrıları, geri adımlar ve görevin gerektirdiğinin birkaç katına çıkan token maliyeti.

Bunu sayısal olarak da ortaya koyabiliriz. Qwen 3.8 27B’yi, uzun bağlamlarda araç kullanımı gerektiren gerçek yazılım mühendisliği çalışmaları olan 450 DeepSWE görevi üzerinde, bir kez tek başına ve bir kez de Fortytwo Engine aracılığıyla çalıştırdık. Model tek başına çalışırken, çalışma başına ortalama 16,3 milyon token, toplamda 7,4 milyar token kullandı. Engine aracılığıyla çalıştığında ise aynı model, çalışma başına ortalama 12,3 milyon token, toplamda 5,6 milyar token kullandı; bu, %24,7 daha az token demekti. Üstelik görevlerin daha fazlasını çözdü: %42,2’ye karşı %47,8. Modelde hiçbir şey değişmedi. Çalışma başına ortadan kalkan dört milyon token, kaymanın maliyetiydi: modelin yanlış yola saptığını fark eden olmadığı için tekrar okuması, yeniden denemesi ve geri adım atması. Sürü bu yanlışları yakalıyor; böylece model bunların bedelini ödemek zorunda kalmıyor.

Fortytwo daha önce modellerin birbirlerinin tamamlanmış yanıtlarını değerlendirmesini sağlıyordu; mevcut mimarideyse modeller, akıl yürütme süreci henüz üretilirken bu süreci etkileyebiliyor. Önceki yaklaşımdan neler öğrendiniz ve gerçek zamanlı yönlendirme neden daha etkili?

2025 mimarisi, en büyük modelin peşinden koşmak yerine yatay ölçekleme, yani sürece daha fazla model katma yoluyla en gelişmiş modeller düzeyinde yeteneklere ulaşabileceğimizi kanıtladı. Birbirlerinin tamamlanmış yanıtlarını sıralayan açık ağırlıklı modellerden oluşan bir sürü, sürüdeki en iyi tekil modeli 17 yüzde puana kadar geride bıraktı. Ayrıca tek bir modelin baş edemediği koşullarda da sağlam sonuç verdi: gürültülü istemler, enjekte edilmiş talimatlar ve yanlış yanıtların çoğunlukta olması gibi durumlarda.

Ancak bu mimari müdahale edemiyordu. Tamamlanmış yanıtları sıralamak tek bir soru için işe yarıyor; fakat ajanların çalışması, aralarında araç çağrılarının bulunduğu yüzlerce adımdan oluşuyor ve belirleyici hatalar erken aşamalarda gerçekleşip birikiyor. Sürecin sonunda değerlendirme yapmak, her modelin token maliyetinin tamamını zaten ödemiş olması demek; değerlendirici de yalnızca çoktan farklı yönlere sapmış süreçler arasından seçim yapabiliyor. Ayrıca sürünün maliyeti, model sayısıyla birlikte artıyordu. Bu, tek bir zor soru için kabul edilebilir; kodlama ajanı içinse uygun değil.

Gerçek zamanlı yönlendirme bu iki sorunu da çözüyor. Sürekli sıralama, süreç boyunca uygulanan bir seçilim baskısıdır; böylece yanlış bir yöne sapıldığında bu sapma yayılmadan, ortaya çıktığı yerde düzeltilir. Sürü, daha temkinli bir girişim sıralamada üstün geldiği için tembelce bir girişimle yetinmez. Aynı mekanizmanın artık hem doğruluğu artırıp hem de token sayısını azaltabilmesinin nedeni bu.

Qwen 3.8 27B ile yaptığınız testlerde Fortytwo, 450 DeepSWE çalışması boyunca altı kıyaslamadaki sonuçları iyileştirirken %24,7 daha az token kullandığını bildiriyor. Sürünün içinde, performansı artırırken token tüketimini aynı anda azaltmasını sağlayan ne oluyor?

Sürünün denetiminin maliyeti küçük ve sabittir; önlediği telafi maliyeti ise görevin uzunluğuyla birlikte artar, çünkü düzeltilmeyen her yanlış adımın üzerine kurulan her şey de maliyet yaratır. Dolayısıyla görev uzadıkça tasarruf edilebilecek miktar artar. DeepSWE de bu yelpazenin uzun görevlerin bulunduğu ucunda yer alıyor; tasarrufun toplam tokenların neredeyse dörtte birine ulaşmasının nedeni bu.

Doğruluk artışı, zekânın alanlara göre dengesiz dağılmasıyla ilgili. Modellerdeki iyileşmeler genellikle eşit dağılmaz: Bir alanda doktora düzeyinde akıl yürütme görülürken başka bir alanda tamamen anlamsız sonuçlar alınabilir. Bunun nedeni ince ayar, RL ve diğer eğitim sonrası yöntemlerin modeli, eğitildiği veriler üzerinde geliştirmesi; gerçek görevler bu verilerden uzaklaştıkça kazanımların da azalmasıdır. Swarm Decoder modele dokunmaz. Akıl yürütme sürecini tutarlı biçimde iyileştirir; dolayısıyla altı kıyaslama, optimize ettiğimiz altı ayrı alan değil, aynı şeyi ölçtüğümüz altı noktadır. Genel olarak model daha akıllı ve dikkatli hâle gelir. Her adımı denetleyen eş modeller sayesinde, görev için çok daha fazla çaba gösteriyormuş gibi görünür. Engine’i temel modelin token başına ücretiyle fiyatlandırabilmemizin nedeni de budur: Müşteri daha büyük bir bütçe için değil, doğru yanıta daha kısa yoldan ulaşmak için ödeme yapar.

Akıl yürütme modelleri daha uzun token dizileri oluşturdukça, yapay zekâ geliştiricileri çıkarım maliyetlerinden giderek daha fazla endişe duyuyor. Sizce akıl yürütme sürecinin verimliliğini artırmak, zamanla tek tek modelleri küçültmek, hızlandırmak veya ucuzlatmak kadar önemli hâle gelebilir mi?

Evet; hatta bunun şimdiden daha etkili bir kaldıraç olduğunu söyleyebilirim. Modelleri küçültmek, hızlandırmak ve ucuzlatmak token başına fiyatı düşürür. Ancak kimse token satın almıyor. İnsanlar tamamlanmış bir iş satın alıyor ve ajan çağında iş başına token sayısı büyük ölçüde arttı: Gerçek bir kodlama görevinde çalışan bir akıl yürütme modeli milyonlarca token harcıyor ve bunların önemli bir kısmı önceki adımlara geri dönüp aynı şeyleri tekrarlamak için kullanılıyor. İş başına token sayısını %25 azaltmak, %25 fiyat indirimiyle tam olarak aynı değere sahip; üstelik donanım, kuantizasyon ve çekirdeklerdeki her iyileşmenin üzerine ekleniyor ve bunu piyasadaki tüm açık ağırlıklı modellere uygulayabiliyoruz.

Sektörün kullanabileceği üç kaldıraç var. Daha iyi modeller; bunun yolu eğitimden geçiyor ve maliyetli. Daha ucuz tokenlar; bunun yolu donanım ve sunum altyapısından geçiyor, ancak herkes aynı GPU’lara sahip olduğundan bu alandaki fark giderek kapanıyor. İş başına daha az token; bu da çıkarımın nasıl yürütüldüğüyle ilgili ve neredeyse hiç keşfedilmemiş bir alan. Şimdiye dek ölçeklendirme, daha büyük modeller ve daha uzun düşünce zincirleri anlamına geldi; her iki yaklaşımda da tek bir modelden tek bir akış içinde her şeyi yapması bekleniyor. Bir sonraki gelişim ekseninin kolektif akıl yürütme olduğuna inanıyoruz: Birden fazla model birlikte akıl yürütüyor, yargı yetisi aralarında dağıtılıyor; böylece akıl yürütme akışının kendisi daha kısa ve daha güvenilir hâle geliyor. Bu, parametreleri ya da test zamanı hesaplamasını artırmaktan farklı bir ölçeklendirme türü ve yatırım yaptığımız yaklaşım da bu. Bunu, parametrelerden çok akranlara öncelik vermek olarak tanımlıyoruz.

Fortytwo Engine, açık ağırlıklı modeller çalıştırırken OpenAI API’siyle uyumlu. Mevcut yapay zekâ geliştirme ekosistemleriyle uyumluluk ne kadar önemliydi ve geliştiriciler bir uygulamayı geleneksel, tek modelli bir API’den sürü mimarisine ne kadar kolay taşıyabilir?

Uyumluluk şart. Ajan ekosistemi; kodlama ajanları, çalışma düzenekleri, çerçeveler ve değerlendirme araçları, OpenAI API’sinin yapısı üzerine kurulu. Dolayısıyla Fortytwo Engine’e erişen geliştiriciler için geçiş, bir çıkarım sağlayıcısından diğerine geçmek gibi: Uyumlu bir uygulama, ajan, çalışma düzeneği veya hizmet için genellikle tek bir yapılandırma değişikliği yeterli; uç nokta, API anahtarı ve model seçimi.

Değişen entegrasyon değil, davranış. Fark, token tüketiminin ve ilk denemedeki doğruluğun maliyeti belirlediği uzun ajanlı çalıştırmalarda ortaya çıkıyor: Aynı model Engine üzerinden daha hızlı tamamlanıyor, daha az token kullanıyor ve görevlerin daha fazlasını doğru sonuçlandırıyor. Önerim, bunu diğer model geçişleri gibi ele almanız: Ajanınızda zaten kullandığınız değerlendirmeyi çalıştırın, iş başına token sayısını ve başarı oranını karşılaştırın, ardından hangisi daha iyi sonuç veriyorsa onu kullanmaya devam edin.

Harika röportaj için teşekkürler. Sürü çıkarımını ve akran değerlendirmesinin akıl yürütme verimliliğini nasıl artırabileceğini keşfetmek isteyen okuyucular Fortytwo‘yu ziyaret edebilir.