Fortytwo के CEO और सह-संस्थापक Ivan Nikitin – साक्षात्कार शृंखला

Ivan Nikitin Fortytwo के CEO और सह-संस्थापक हैं। वहाँ वे स्वॉर्म इन्फरेंस तकनीक विकसित कर रहे हैं, जो कई एआई मॉडलों को साथ लाती है ताकि वे तर्क कर सकें और एक-दूसरे के काम का मूल्यांकन कर सकें। उनका अनुभव Temporal और Sensorium में गेम्स, संवादात्मक एआई, जनरेटिव एआई और इंटरैक्टिव प्रणालियों तक फैला है। उन्होंने 2011 में Vlad Larin के साथ Temporal की सह-स्थापना की। Vlad अब Fortytwo के सह-संस्थापक और CTO हैं। वहाँ उन्होंने एजेंटों की बदलती आबादी और विशेषीकृत मॉडलों को मिलाने वाली प्रणालियों के साथ काम करने का अनुभव हासिल किया।

Fortytwo ऐसा एआई इन्फ्रास्ट्रक्चर बनाता है, जो इन्फरेंस के दौरान मॉडलों को आपस में सहयोग करने में सक्षम बनाता है। इसका Fortytwo Engine, Swarm Decoder का इस्तेमाल करके साझा तर्क-प्रक्रिया को आगे बढ़ने के दौरान दिशा देता है। इसका लक्ष्य सटीकता बढ़ाना और लंबे कार्यों में अनावश्यक टोकन जनरेशन घटाना है। कंपनी, Fortytwo Engine के ज़रिए डेवलपरों को एपीआई और Fortytwo Harbor के ज़रिए ऑन-प्रिमाइसेस डिप्लॉयमेंट उपलब्ध कराती है।

Fortytwo की सह-स्थापना करने से पहले, आपने Sensorium और Temporal में संवादात्मक एआई, जनरेटिव एआई और इंटरैक्टिव प्रणालियों पर आधारित उत्पाद बनाने में कई साल बिताए। उन अनुभवों ने इस बारे में आपकी सोच को कैसे आकार दिया कि अलग-अलग बड़े भाषा मॉडल कहाँ कम पड़ते हैं, और आखिरकार उन्होंने आपको Fortytwo के पीछे के स्वॉर्म-आधारित तरीके तक कैसे पहुँचाया?

हमारी टीम के कई लोग, जिनमें मैं भी शामिल हूँ, गेम्स के ज़रिए एआई के क्षेत्र में आए। गेम्स व्यक्तिगत कंप्यूटिंग और आधुनिक एआई की जन्मस्थली रहे हैं: GPU के अस्तित्व का कारण गेम्स ही हैं, और गेम खेलना रीइन्फोर्समेंट लर्निंग की पहली गंभीर परीक्षण-भूमि थी। गेम की दुनिया ने ऐसे एजेंट बनाने के लिए व्यावहारिक माहौल दिया, जो सीख सकते थे, बदलती परिस्थितियों के अनुरूप ढल सकते थे और प्रतिस्पर्धा कर सकते थे। Temporal में, जिसकी सह-स्थापना मैंने 2011 में Vlad Larin के साथ की थी—Vlad अब Fortytwo के सह-संस्थापक और CTO हैं—हमने विकसित होती बुद्धिमत्ता पर काम शुरू किया: एजेंटों के ऐसे समूह, जो चयन के दबाव में प्रतिस्पर्धा करते थे। हमारी दिलचस्पी इस बात में थी कि कोई समूह किसी अकेले एजेंट से बेहतर नतीजे कैसे हासिल कर सकता है, बशर्ते उसके सबसे मज़बूत योगदानों को पहचानने और आगे बढ़ाने का अच्छा तरीका हो। बुद्धिमत्ता के बारे में हमारी सोच में चयन और मूल्यांकन केंद्रीय बन गए।

ट्रांसफॉर्मर मॉडल आने पर हमने संवादात्मक एआई के क्षेत्र में विस्तार किया और एआई-आधारित पात्रों के लिए एक मंच बनाया। ये पात्र स्मृति और व्यक्तित्व के साथ खुली, बिना पूर्व-निर्धारित पटकथा वाली बातचीत कर सकते थे। यह ChatGPT से कुछ साल पहले की बात है, और हम जिन मॉडलों के साथ काम कर रहे थे, उनकी कॉन्टेक्स्ट विंडो केवल 512 से 1,024 टोकन की थी। उस शुरुआती दौर के किसी एक भाषा मॉडल से इस अनुभव की सभी अलग-अलग ज़रूरतों को भरोसेमंद ढंग से पूरा करने की अपेक्षा करना मुमकिन नहीं था। हमें विशेषीकृत मॉडलों की एक कस्टम पाइपलाइन बनानी पड़ी, जिसमें हर मॉडल की ज़िम्मेदारी सीमित थी, साथ ही उनके योगदानों को मिलाने वाला तर्क भी तैयार करना पड़ा। पूरे अनुभव को कारगर बनाने के लिए जवाबों की रैंकिंग करना और उनका चयन करना ज़रूरी हो गया। इससे हमें समझ आया कि सीमित क्षमताओं वाले मॉडलों को अच्छी तरह डिज़ाइन की गई प्रणाली में मिलाकर कितनी क्षमता हासिल की जा सकती है।

दूसरी सीख दक्षता से जुड़ी थी। हमने जाना कि स्पष्ट रूप से परिभाषित कार्यों के लिए विशेषीकृत मॉडलों को अधिक कुशलता से प्रशिक्षित और सर्व किया जा सकता है, जिससे सीमित कंप्यूट संसाधनों में भी हम ज़्यादा हासिल कर सकते हैं। लेकिन इन्फरेंस को बड़े पैमाने पर चलाना अब भी चुनौती बना रहा: एक ओर एपीआई के उपयोग पर सीमाएँ थीं, तो दूसरी ओर बड़े पैमाने पर स्वयं होस्ट करने की लागत। अत्याधुनिक कंप्यूट क्षमता तक पहुँच न होने के कारण हमें सावधानी से सोचना पड़ा कि उपलब्ध संसाधनों का बेहतर इस्तेमाल कैसे किया जाए। Fortytwo ने इन सीखों को स्वॉर्म इन्फरेंस की परिकल्पना में एक साथ जोड़ा: कई मॉडल, या एक ही मॉडल के कई उदाहरण, तर्क-प्रक्रिया में योगदान देते हैं और साथ ही अपने साथियों के काम का आकलन भी करते हैं। नतीजतन, यह सामूहिक प्रणाली अपने किसी भी सदस्य से अधिक सटीक होती है।

Fortytwo Engine कई ओपन-वेट मॉडलों का इस्तेमाल करके एक ही तर्क-प्रक्रिया को दिशा देता है और जवाब तैयार होते समय वे एक-दूसरे के काम की जाँच करते हैं। यह तरीका पारंपरिक मल्टी-एजेंट प्रणालियों, मॉडल एन्सेम्बल या कई मॉडल चलाकर बाद में सबसे अच्छा जवाब चुनने के तरीकों से किस तरह अलग है?

मुख्य अंतर यह है कि स्वॉर्म इन्फरेंस को सीधे हमारे विकसित किए गए इन्फरेंस इंजन में शामिल किया गया है। हम इसे Swarm Decoder कहते हैं: जवाब तैयार होते समय कई मॉडल प्रतिभागी लगातार एक ही तर्क-प्रवाह को आकार देते हैं। इसी प्रक्रिया के दौरान मूल्यांकन और दिशा-निर्देशन होता है, जिससे जवाब पूरा होने से पहले ही मॉडल उसकी दिशा को प्रभावित कर सकते हैं।

वैकल्पिक तरीके अलग तरह से काम करते हैं। जवाब-स्तरीय एन्सेम्बल में मॉडल अलग-अलग जवाब तैयार करते हैं, जिन्हें फिर रैंक किया जाता है, चुना जाता है या मिलाया जाता है। 2025 में लागू किए गए Fortytwo के मूल आर्किटेक्चर में पूरे हो चुके जवाबों की सहकर्मी-रैंकिंग का इस्तेमाल किया गया था। इससे जवाबों की सटीकता में काफ़ी सुधार हुआ, लेकिन विलंबता और कंप्यूट का अतिरिक्त बोझ भी बढ़ा। कई पारंपरिक मल्टी-एजेंट प्रणालियाँ एजेंटों के बीच काम बाँटती हैं और उनके योगदानों को व्यवस्थित करने के लिए एक ऑर्केस्ट्रेटर तथा प्राकृतिक भाषा के संदेशों का इस्तेमाल करती हैं। इन हस्तांतरणों के लिए अतिरिक्त इन्फरेंस कॉल, संदर्भ को दोहराना और यह तय करना पड़ सकता है कि एक एजेंट से दूसरे तक कौन-सी जानकारी पहुँचाई जाए। Swarm Decoder में ऐसे कोई हस्तांतरण नहीं होते: सभी प्रतिभागी एक ही तर्क-प्रवाह पर काम करते हैं और उनके बीच केवल इस बारे में निर्णय साझा होता है कि कौन-सी दिशा बेहतर है।

Swarm Decoder को इस तरह बनाया गया है कि वह जवाब तैयार होते समय कमज़ोर धारणाओं को पकड़ सके, इससे पहले कि उन पर आगे काम करने में काफ़ी मेहनत लग जाए। इसका लक्ष्य गलतियाँ, पीछे लौटकर दोबारा काम करना और अनावश्यक जनरेशन घटाना है; दक्षता का लाभ तब मिलता है जब जाँच से बचा हुआ काम, जाँच में जोड़े गए काम से अधिक हो। इसीलिए विलंबता पर कोई दंड नहीं पड़ता: प्रक्रिया अधिक सीधे रास्ते से आगे बढ़ती है, इसलिए Engine अकेले उसी मॉडल की तुलना में कार्य तेज़ी से और कुल मिलाकर कम टोकन में पूरा करता है—इस गणना में हर प्रतिभागी मॉडल के टोकन शामिल हैं।

आपने लंबे समय तक चलने वाले कार्यों के दौरान मॉडल के भटकाव को एक बड़ी समस्या बताया है। इस भटकाव की असल वजह क्या है, और सॉफ़्टवेयर इंजीनियरिंग, शोध या स्वायत्त एआई एजेंट जैसे व्यावहारिक अनुप्रयोगों में यह किस तरह दिखता है?

मॉडल का भटकाव तब होता है, जब उसका संदर्भ धीरे-धीरे मूल कार्य से हटने लगता है। लंबे समय तक चलने वाले कार्य में संदर्भ मॉडल के अपने आउटपुट, टूल के नतीजों, फ़ाइलों की सामग्री और दोबारा किए गए प्रयासों से भर जाता है। मॉडल जिस बात पर ध्यान दे रहा होता है, उसमें मूल निर्देश का हिस्सा लगातार छोटा होता जाता है। साथ ही, उसकी पहले की गलतियाँ भी उस इनपुट का हिस्सा बन जाती हैं जिसके आधार पर वह तर्क करता है; इस तरह गलतियाँ एक-दूसरे को निरस्त करने के बजाय बढ़ती जाती हैं। इसके अलावा, आज के तर्क करने वाले मॉडलों को कार्य पूरा करने के लिए रीइन्फ़ोर्समेंट लर्निंग से प्रशिक्षित किया जाता है, और वे ऐसे शॉर्टकट सीख लेते हैं जो काम पूरा करने जैसे दिखते हैं: टूल कॉल छोड़ देना, सफलता घोषित कर देना या जाँचने के बजाय सारांश दे देना। हम इसे आलस्य कहते हैं, और अग्रणी मॉडल भी ऐसा उतनी ही बार करते हैं जितने ओपन-वेट मॉडल। इसकी मूल वजह यह है कि किसी एक मॉडल की जाँच करने वाला कोई बाहरी तंत्र नहीं होता। वह अपने ही काम का मूल्यांकन करता है, जबकि मॉडल अपने काम का सटीक आत्म-मूल्यांकन करने में कमज़ोर होते हैं।

सॉफ़्टवेयर इंजीनियरिंग में यह तब दिखता है, जब एजेंट बताई गई गड़बड़ी तो ठीक कर देता है, लेकिन पहले संदेश में बताई गई शर्त तोड़ देता है; ऐसा परीक्षण लिखता है जो बिना किसी कठिनाई के सफल हो जाए; या एक ही फ़ाइल को चार बार पढ़ता है, क्योंकि उसे याद नहीं रहता कि वह पहले क्या जान चुका है। शोध में ऐसा तब होता है, जब लंबे समय तक चलने वाला काम आपके पूछे गए सवाल से खिसककर उस सवाल पर आ जाता है जिसका जवाब देना सबसे आसान हो, और अंत में एक सामान्य-सा सारांश लौटाता है। स्वायत्त एजेंटों में इसका महँगा रूप दिखता है: विषय से भटकना, बार-बार टूल कॉल करना, पीछे लौटना और टोकन का ऐसा खर्च, जो कार्य की ज़रूरत से कई गुना अधिक हो।

हम इसका आँकड़ा दे सकते हैं। हमने Qwen 3.8 27B को 450 DeepSWE कार्यों पर चलाया—ये लंबे संदर्भों में टूल के इस्तेमाल वाले वास्तविक सॉफ़्टवेयर इंजीनियरिंग कार्य थे—एक बार अकेले और एक बार Fortytwo Engine के ज़रिए। अकेले चलाने पर, मॉडल ने हर बार औसतन 16.3 मिलियन टोकन इस्तेमाल किए, यानी कुल 7.4 बिलियन। Engine के ज़रिए उसी मॉडल ने हर बार औसतन 12.3 मिलियन टोकन इस्तेमाल किए, यानी कुल 5.6 बिलियन—24.7% कम—और उसने अधिक कार्य हल किए: 42.2% की तुलना में 47.8%। मॉडल में कुछ भी नहीं बदला था। हर बार इस्तेमाल हुए चार मिलियन टोकन की बचत भटकाव के कारण हुई: दोबारा पढ़ना, फिर से प्रयास करना और पीछे लौटना—ये सब एक मॉडल को इसलिए करना पड़ता है, क्योंकि उसके गलत रास्ते पर जाने के दौरान कोई उसे रोकता नहीं। स्वॉर्म उन गलतियों को पकड़ लेता है, इसलिए उन पर टोकन खर्च ही नहीं करने पड़ते।

पहले Fortytwo में मॉडल एक-दूसरे के पूरे हो चुके जवाबों का मूल्यांकन करते थे, जबकि मौजूदा संरचना उन्हें तर्क-प्रक्रिया तैयार होते समय ही उसमें दखल देने देती है। पहले के तरीके से आपने क्या सीखा, और वास्तविक समय में दिशा देना अधिक प्रभावी क्यों है?

2025 की संरचना ने साबित किया कि हम सबसे बड़े मॉडल के पीछे भागने के बजाय क्षैतिज विस्तार—यानी अधिक मॉडल शामिल करने—से अग्रणी मॉडलों के स्तर की क्षमताएँ हासिल कर सकते हैं। एक-दूसरे के पूरे जवाबों की रैंकिंग करने वाले ओपन-वेट मॉडलों के स्वॉर्म ने उसमें शामिल सर्वश्रेष्ठ अकेले मॉडल को 17 प्रतिशत अंकों तक पीछे छोड़ दिया। यह उन स्थितियों में भी मज़बूत रहा, जिनमें एक अकेला मॉडल ऐसा नहीं कर पाता: शोर वाले प्रॉम्प्ट, डाली गई निर्देशात्मक सामग्री और गलत जवाबों का बहुमत।

उस संरचना की कमी यह थी कि वह बीच में दखल नहीं दे सकती थी। पूरे हो चुके जवाबों की रैंकिंग एक सवाल के लिए कारगर है, लेकिन एजेंट के कार्यों में टूल कॉल के बीच सैकड़ों चरण होते हैं, और निर्णायक गलतियाँ शुरुआत में होती हैं और फिर बढ़ती जाती हैं। अंत में मूल्यांकन करने का मतलब है कि हर मॉडल पहले ही टोकन की पूरी लागत चुका चुका होता है, और मूल्यांकनकर्ता केवल उन कार्य-प्रवाहों में से चुन सकता है जो पहले ही अलग-अलग दिशाओं में जा चुके हैं। इसका यह भी मतलब था कि स्वॉर्म की लागत मॉडलों की संख्या के साथ बढ़ती थी—एक कठिन सवाल के लिए यह ठीक है, लेकिन कोडिंग एजेंट के लिए सही तरीका नहीं।

वास्तविक समय में दिशा देना इन दोनों समस्याओं को हल करता है। लगातार रैंकिंग करना पूरे कार्य के दौरान चयन-दबाव लागू करने जैसा है, इसलिए गलत दिशा में उठाया गया कदम जहाँ आता है, वहीं सुधारा जा सकता है—उसके आगे फैलने से पहले। स्वॉर्म कभी आलसी कोशिश को स्वीकार नहीं करता, क्योंकि रैंकिंग में वह अधिक सावधानी से की गई कोशिश से पीछे रह जाती है। इसी वजह से अब यही तंत्र हमें एक साथ अधिक सटीकता और कम टोकन देता है।

Qwen 3.8 27B के साथ अपने परीक्षणों में Fortytwo ने छह बेंचमार्क पर नतीजे बेहतर करते हुए 450 DeepSWE रन में 24.7% कम टोकन इस्तेमाल करने की जानकारी दी है। स्वॉर्म के भीतर ऐसा क्या होता है जिससे प्रदर्शन बेहतर होने के साथ-साथ टोकन की खपत भी घटती है?

स्वॉर्म की जाँच की लागत कम और तय होती है; लेकिन वह जितनी दोबारा की जाने वाली मेहनत बचाता है, वह कार्य की अवधि के साथ बढ़ती जाती है, क्योंकि बिना सुधारी गई हर गलत दिशा में उठाए गए कदम पर उसके बाद की पूरी मेहनत भी खर्च होती है। इसलिए कार्य जितना लंबा होगा, बचत की गुंजाइश उतनी ही अधिक होगी। DeepSWE इस पैमाने के लंबे कार्यों में आता है, इसी वजह से कुल टोकनों में लगभग एक चौथाई की बचत होती है।

सटीकता में सुधार का संबंध बुद्धिमत्ता के असमान विकास से है। मॉडलों में सुधार आम तौर पर हर क्षेत्र में एक-जैसा नहीं होता: किसी एक क्षेत्र में पीएचडी स्तर का तर्क मिलता है, तो दूसरे में पूरी तरह बेतुकी बातें, क्योंकि फ़ाइन-ट्यूनिंग, RL और प्रशिक्षण के बाद की अन्य प्रक्रियाएँ मॉडल को उसी डेटा पर बेहतर बनाती हैं जिस पर उसे प्रशिक्षित किया गया था, और वास्तविक कार्य उस डेटा से जितने दूर जाते हैं, ये फ़ायदे उतने ही घटते जाते हैं। Swarm Decoder मॉडल में कोई बदलाव नहीं करता। यह तर्क-प्रक्रिया को लगातार बेहतर बनाता है, इसलिए छह बेंचमार्क उन छह क्षेत्रों का नाम नहीं हैं जिनके लिए हमने अनुकूलन किया हो; वे छह जगहें हैं जहाँ हमने एक ही चीज़ को मापा। कुल मिलाकर, मॉडल अधिक बुद्धिमान और अधिक ध्यान देने वाला बनता है, और हर कदम पर उसके साथी मॉडल जाँच करते हैं, इसलिए ऐसा लगता है कि वह आपके कार्य पर कहीं अधिक मेहनत कर रहा है। इसी वजह से हम Engine की कीमत आधार मॉडल की प्रति-टोकन दर पर रख सकते हैं: ग्राहक किसी बड़े बजट के लिए भुगतान नहीं कर रहा, बल्कि सही जवाब तक पहुँचने के छोटे रास्ते के लिए कर रहा है।

तर्क-आधारित मॉडल टोकन की लंबी शृंखलाएँ तैयार कर रहे हैं, इसलिए एआई डेवलपर अनुमान-चालन की लागत को लेकर लगातार चिंतित हो रहे हैं। क्या आपको लगता है कि तर्क-प्रक्रिया को अधिक कुशल बनाना अंततः उतना ही महत्वपूर्ण हो सकता है जितना कि अलग-अलग मॉडलों को छोटा, तेज़ या सस्ता बनाना?

हाँ, और मेरा तर्क है कि यह पहले से ही अधिक प्रभावशाली उपाय है। मॉडलों को छोटा, तेज़ और सस्ता बनाने से प्रति टोकन कीमत घटती है। लेकिन कोई टोकन नहीं खरीदता। लोग काम पूरा करवाते हैं, और एजेंटों के दौर में हर काम के लिए इस्तेमाल होने वाले टोकन की संख्या बहुत बढ़ गई है: वास्तविक कोडिंग के किसी काम पर तर्क-आधारित मॉडल लाखों टोकन खर्च करता है, जिनमें से एक बड़ा हिस्सा बार-बार पीछे लौटने में लगता है। हर काम के लिए टोकन की संख्या में 25% की कमी का मूल्य, 25% मूल्य-कटौती के ठीक बराबर है; फ़र्क़ सिर्फ़ इतना है कि इसका लाभ हार्डवेयर, क्वांटाइज़ेशन और कर्नेल में होने वाले हर सुधार के साथ जुड़ता जाता है। साथ ही, हम इसे बाज़ार में उपलब्ध किसी भी ओपन-वेट मॉडल पर लागू कर सकते हैं।

उद्योग के पास तीन उपाय हैं। बेहतर मॉडल—यानी प्रशिक्षण, जो महँगा है। सस्ते टोकन—यानी हार्डवेयर और सर्विंग, जिसमें सबके पास एक जैसे जीपीयू होने के कारण अंतर लगातार कम हो रहा है। और हर काम के लिए कम टोकन—यानी अनुमान-चालन किस तरह किया जाता है, जिसका लगभग कोई अन्वेषण नहीं हुआ है। अब तक विस्तार का मतलब बड़े मॉडल और विचार-शृंखला को लंबा करना रहा है, और दोनों ही इस अपेक्षा पर टिके हैं कि एक मॉडल एक ही प्रक्रिया में सब कुछ करे। हमारा मानना है कि अगला विस्तार सामूहिक होगा: कई मॉडल मिलकर तर्क करेंगे और उनके बीच निर्णय-विवेक बाँटा जाएगा, जिससे प्रक्रिया अपने आप में छोटी और अधिक भरोसेमंद होगी। यह पैरामीटर बढ़ाने या परीक्षण के समय गणना बढ़ाने से अलग तरह का विस्तार है, और हम इसी पर दांव लगा रहे हैं। हम इसे ‘पैरामीटर से बढ़कर सहकर्मी मॉडल’ के रूप में देखते हैं।

Fortytwo Engine ओपन-वेट मॉडल चलाते हुए OpenAI API के साथ संगत है। मौजूदा AI विकास स्टैक के साथ संगतता कितनी महत्वपूर्ण थी, और डेवलपर किसी ऐप्लिकेशन को पारंपरिक सिंगल-मॉडल API से स्वार्म आर्किटेक्चर में कितनी आसानी से ले जा सकते हैं?

संगतता अनिवार्य है। एजेंट इकोसिस्टम—कोडिंग एजेंट, हार्नेस, फ़्रेमवर्क और मूल्यांकन टूल—OpenAI API के स्वरूप पर बना है। इसलिए Fortytwo Engine का इस्तेमाल करने वाले डेवलपर के लिए स्विच करना, एक अनुमान-सेवा प्रदाता से दूसरे पर जाने जैसा है: संगत ऐप, एजेंट, हार्नेस या सेवा के लिए आम तौर पर कॉन्फ़िगरेशन में बस एक बदलाव करना होता है—एंडपॉइंट, एपीआई कुंजी और मॉडल का चयन।

बदलाव व्यवहार में होता है, एकीकरण में नहीं। इसका फ़र्क़ एजेंट के लंबे कार्य-सत्रों में दिखता है, जहाँ टोकन की खपत और पहली कोशिश में सही परिणाम देने की क्षमता लागत तय करती हैं: Engine के ज़रिए वही मॉडल काम तेज़ी से पूरा करता है, कम टोकन इस्तेमाल करता है और अधिक काम सही ढंग से करता है। मेरी सलाह है कि इसे किसी भी मॉडल को बदलने की तरह लें: अपने एजेंट पर पहले से इस्तेमाल किए जा रहे मूल्यांकन चलाएँ, हर काम के लिए टोकन की संख्या और सफलता-दर की तुलना करें, और जो बेहतर नतीजा दे, उसे रखें।

इस शानदार साक्षात्कार के लिए धन्यवाद। जो पाठक स्वॉर्म अनुमान-चालन और यह जानना चाहते हैं कि सहकर्मी मूल्यांकन तर्क-प्रक्रिया की दक्षता कैसे बेहतर कर सकता है, वे Fortytwo पर जाएँ।