गूगल की AI और इंफ्रास्ट्रक्चर टीम ने एक ब्लॉग पोस्ट में कुछ ऐसा प्रकाशित किया जो चुपचाप उल्लेखनीय था, जिसे उद्योग के अधिकांश लोगों ने नज़रअंदाज़ कर दिया: प्रोडक्शन मशीन लर्निंग मॉडल को TensorFlow से JAX में माइग्रेट करने में छह गुना तेजी, जिसमें हज़ारों लाइनों का कोड, सैकड़ों लेयर और कई फाइलों में गहराई तक फैली निर्भरताएँ शामिल थीं। सुंदर पिचाई ने Google Cloud Next के मंच पर इसका उल्लेख किया। यह आंकड़ा सुर्खियों में रहा। लेकिन इसके पीछे की वास्तुकला ही असली कहानी है, और यह वही वास्तुकला है जो हर विश्वसनीय बड़े पैमाने के एजेंट माइग्रेशन के पीछे काम कर रही है, चाहे वह 8 एजेंटों का झुंड हो या 800 का।
यहाँ सबसे महत्वपूर्ण विवरण है: उन्होंने पहले कोडबेस पर एक एकल AI एजेंट को लगाने की कोशिश की। यह विफल रहा। आंशिक रूप से नहीं। इसने संदर्भ खो दिया, ऐसे API की कल्पना की जो मौजूद नहीं थे, और ऐसा कोड तैयार किया जो कंपाइल नहीं होता था। समाधान कोई समझदार मॉडल नहीं था। यह पूरी तरह से एक अलग वास्तुकला थी, जिसका अब एक नाम है: "डार्क फैक्ट्री" पैटर्न, एक कोडबेस जहाँ एजेंट बिना किसी मानवीय समीक्षा के योजना बनाते हैं, लागू करते हैं, परीक्षण करते हैं और कोड शिप करते हैं, ठीक उसी तरह जैसे एक पूरी तरह से स्वचालित फैक्ट्री अंधेरे में मशीनें चलाती है क्योंकि वहाँ कोई नहीं बचा है जो लाइट चालू कर सके।
यह लेख उस पैटर्न का पूरा विश्लेषण है। मार्केटिंग वाला संस्करण नहीं। असली तंत्र कि कैसे सैकड़ों एजेंट बिना किसी मानव के प्रत्येक बदलाव की जाँच किए एक वास्तविक कोडबेस को माइग्रेट करते हैं, और क्यों इसे सुरक्षित बनाने वाली चीज़ मॉडल पर भरोसा नहीं है, बल्कि एक ऐसी वास्तुकला है जिसे विशेष रूप से उस भरोसे की कभी आवश्यकता न होने के लिए डिज़ाइन किया गया है।
एकल एजेंट बड़े पैमाने पर क्यों विफल होता है
वास्तुकला से पहले, यह समझें कि सरल दृष्टिकोण वास्तव में क्यों टूटता है, क्योंकि काम करने वाले पैटर्न का हर डिज़ाइन निर्णय विशेष रूप से इनमें से किसी एक विफलता को ठीक करने के लिए मौजूद है।
एक बड़े कोडबेस पर लगाया गया एक एकल एजेंट पहले एक संदर्भ समस्या का सामना करता है। एक उदार संदर्भ विंडो के साथ भी, सैकड़ों अन्योन्याश्रित फाइलों, गहरी कॉल चेन और मॉड्यूल में विरासत में मिली मान्यताओं वाला कोडबेस, किसी भी एक सत्र की सुसंगत धारण क्षमता से अधिक होता है। एजेंट पहली कुछ फाइलों पर मजबूत शुरुआत करता है और फिर काम करने का संदर्भ संचित, आधी-अधूरी प्रासंगिकता वाले इतिहास से भर जाने पर गिरावट आती है।
फिर यह एक अनुक्रमण समस्या का सामना करता है। कोड माइग्रेशन डिफ़ॉल्ट रूप से एक समानांतर कार्य नहीं है। फाइल B अक्सर फाइल A के पहले से माइग्रेट होने पर निर्भर करती है, क्योंकि फंक्शन सिग्नेचर बदल गए हैं, इम्पोर्ट स्थानांतरित हो गए हैं, या डेटा संरचनाओं का आकार बदल गया है। एक स्पष्ट निर्भरता मानचित्र के बिना एक एजेंट या तो क्रम का अनुमान लगाता है, जो टूटी हुई मध्यवर्ती अवस्थाएँ उत्पन्न करता है, या फाइलों को उसी क्रम में संसाधित करता है जिसमें वे सूचीबद्ध हैं, जो कार्यात्मक रूप से अनुमान लगाने के समान है।
फिर यह एक सत्यापन समस्या का सामना करता है, और यह वह है जो वास्तव में सबसे अधिक मायने रखती है। एक एजेंट जो कोड माइग्रेट कर रहा है और फिर अपने स्वयं के माइग्रेशन का मूल्यांकन कर रहा है, वह अपने स्वयं के होमवर्क की जाँच उन्हीं अंध धब्बों के साथ कर रहा है जिन्होंने पहली बार में कोई भी गलती उत्पन्न की थी। यदि एजेंट यह नहीं समझता है कि कोई विशेष API नए संस्करण के तहत अलग व्यवहार करता है, तो वह अपने स्वयं के आउटपुट की समीक्षा करते समय उस गलतफहमी को नहीं पकड़ पाएगा, क्योंकि समझ में वही अंतर दोनों पासों में मौजूद है।
गूगल की टीम को यह सीधे पता चला। एकल-एजेंट सेटअप माइग्रेशन के संरचनात्मक नियमों को एक साथ लाइन-दर-लाइन निष्पादन विवरणों के साथ संतुलित नहीं कर सका। इन दो चिंताओं को अलग-अलग भूमिकाओं में विभाजित करना ही वास्तविक समाधान है, और यह वही समाधान है जो OpenAI के प्रकाशित माइग्रेशन कुकबुक में, मल्टी-एजेंट माइग्रेशन लूप पर अकादमिक शोध में, और हर प्रोडक्शन सिस्टम में स्वतंत्र रूप से दिखाई देता है जो वास्तव में इस पैमाने पर चल रहा है।
वास्तुकला: तीन भूमिकाएँ, एक सामान्यवादी नहीं
काम करने वाला पैटर्न काम को वास्तव में अलग-अलग कामों वाली भूमिकाओं में विभाजित करता है, न कि केवल एक ही सामान्यवादी एजेंट पर लक्षित अलग-अलग प्रॉम्प्ट।
एक योजनाकार जो काम को अनुक्रमित करने के लिए LLM अनुमान के बजाय नियतात्मक उपकरण का उपयोग करता है। यह वह विवरण है जो एक ऐसी प्रणाली को अलग करता है जो वास्तव में स्केल करती है, उससे जो डेमो में प्रभावशाली दिखती है और प्रोडक्शन में बिखर जाती है। गूगल का योजनाकार माइग्रेशन ऑर्डर का पता लगाने के लिए LLM से तर्क करने के लिए नहीं कहता है। यह कंपाइलर-आधारित स्थैतिक विश्लेषण का उपयोग करता है, वही श्रेणी का नियतात्मक उपकरण जो दशकों से एंटरप्राइज़ सॉफ़्टवेयर को रेखांकित कर रहा है, वास्तविक निर्भरता ट्री बनाने और एक निष्पादन योजना को परिभाषित करने के लिए जो लीफ नोड्स (ऐसी फाइलें जिन पर और कुछ निर्भर नहीं है) से शुरू होती है और उन फाइलों की ओर बढ़ती है जिन पर बाकी सब कुछ निर्भर करता है।
यह मायने रखता है क्योंकि निर्भरता क्रम एक रचनात्मक समस्या नहीं है। यह एक यांत्रिक समस्या है जिसका एक सही उत्तर है, और एक ऐसी समस्या को हल करने के लिए LLM का उपयोग करना जिसका पहले से ही एक नियतात्मक समाधान है, बस एक नया त्रुटि स्रोत पेश करता है जहाँ किसी की आवश्यकता नहीं है। इसके नीचे का नियम: जहाँ कहीं भी किसी समस्या का एल्गोरिथमिक उत्तर है, वहाँ एल्गोरिथम का उपयोग करें। भाषा मॉडल को कार्य के उस हिस्से के लिए आरक्षित रखें जिसके लिए वास्तव में निर्णय की आवश्यकता होती है, जो कि वास्तविक कोड रूपांतरण है, न कि यह अनुक्रमण कि कौन सी फाइल पहले जाएगी।
एक माइग्रेशन एजेंट (या, बड़ी प्रणालियों में, उनमें से सैकड़ों एक ही भूमिका के पृथक, संकीर्ण-दायरे वाले उदाहरणों में समानांतर चल रहे हैं) जो वास्तविक कोड रूपांतरण करता है। प्रत्येक उदाहरण को एक सीमित कार्य मिलता है, आदर्श रूप से एक फाइल या एक कसकर बंधा हुआ मॉड्यूल, एक एकल चेकआउट, और एक स्पष्ट माइग्रेशन ब्रीफ जो वर्णन करता है कि वास्तव में क्या बदलने की आवश्यकता है और क्यों। यह प्रासंगिक कोड का निरीक्षण करता है, संपादन करता है, और एक पैच तैयार करता है। यह यह तय नहीं करता है कि इसका अपना पैच सही है या नहीं। यह उसका काम नहीं है, और वास्तुकला विशेष रूप से इस तरह से डिज़ाइन की गई है कि यह गलती से वह काम नहीं ले सकता है।
एक पर्यावरण और सत्यापन परत जो कुछ भी स्वीकार किए जाने से पहले एक पृथक वातावरण में माइग्रेट किए गए कोड का निर्माण, संचालन और परीक्षण करती है। यह वह जगह है जहाँ "हो गया है हो गया" एक राय के बजाय एक यांत्रिक तथ्य बन जाता है। गूगल का इसका ढाँचा सटीक है: उद्योग ने ऐतिहासिक रूप से यह तय करने के लिए दो बुरे विकल्प पेश किए हैं कि AI का काम वास्तव में कब समाप्त हुआ है, मानव समीक्षा जो सैकड़ों फाइलों तक स्केल नहीं होती है, या AI स्व-मूल्यांकन जिसका ऑडिट नहीं किया जा सकता क्योंकि इसका कोई रिकॉर्ड नहीं है कि वास्तव में क्या जाँचा गया था। उनका उत्तर गणितीय सत्यापन है, नियतात्मक कोड जो पुष्टि करता है कि संकलन सफल होता है, परीक्षण पास होते हैं, और व्यवहार एक परिभाषित स्पेक से मेल खाता है, दोनों बुरे विकल्पों को एक तीसरे से बदल देता है जो वास्तव में निरीक्षण योग्य है।
ध्यान दें कि इस सूची से क्या गायब है: एक मानव जो मर्ज होने से पहले हर अलग-अलग डिफ़ को पढ़ता है। यह डार्क फैक्ट्री पैटर्न का पूरा बिंदु है, और यह ठीक वही जगह है जहाँ अधिकांश लोगों की सुरक्षा के बारे में सहज ज्ञान गलत हो जाता है, क्योंकि ऐसा लगता है कि सिस्टम एजेंटों पर अधिक भरोसा कर रहा है। यह इसके विपरीत है। यह संरचनात्मक रूप से एजेंटों पर कम भरोसा कर रहा है, निर्णय के एकल बिंदु, "क्या एजेंट ने कहा कि यह काम कर गया," को एक सत्यापन परत से बदलकर जिसे एजेंट प्रभावित या अपने तरीके से बात नहीं कर सकता है।
पृथक्करण परत: प्रत्येक एजेंट को अपना स्वयं का सैंडबॉक्स क्यों मिलता है
एक ही कोडबेस के खिलाफ सैकड़ों एजेंटों को एक साथ चलाने से एक स्पष्ट जोखिम पैदा होता है: क्या होता है जब एजेंट 47 एक फाइल पर मिड-एडिट है जिस पर एजेंट 12 का बदलाव निर्भर करता है, और एजेंट 12 के संपादन ने अभी-अभी संकलन तोड़ दिया है।
इसका उत्तर, OpenAI की प्रकाशित माइग्रेशन वास्तुकला और गूगल की प्रोडक्शन प्रणाली दोनों में सुसंगत, डिफ़ॉल्ट रूप से पृथक्करण है। प्रत्येक माइग्रेशन कार्य अपने स्वयं के सैंडबॉक्स वातावरण में चलता है, अक्सर अपना स्वयं का git वर्कट्री, उस एक कार्य के लिए प्रासंगिक रिपॉजिटरी का एक पूर्ण, स्वतंत्र चेकआउट। यदि उस सैंडबॉक्स में कोई एजेंट कुछ तोड़ता है, तो वह एक पृथक प्रतिलिपि को तोड़ता है, साझा कोडबेस को नहीं, और निश्चित रूप से किसी अन्य एजेंट के चल रहे काम को नहीं।
यह पृथक्करण टकराव को रोकने के अलावा और भी कुछ करता है। यह पूरे सिस्टम को तुच्छ रूप से समानांतर करने योग्य बनाता है, क्योंकि सैकड़ों एक साथ एजेंटों के लिए कोई साझा परिवर्तनीय स्थिति नहीं है जिस पर वे कदम रख सकें। एजेंट 1 से लेकर एजेंट 800 तक वास्तव में एक ही समय में चल सकते हैं, प्रत्येक अपने विशिष्ट कार्य के लिए प्रासंगिक केवल फाइलों और संदर्भ वाले एक साफ वातावरण में, एक एजेंट के मतिभ्रम के दूसरे के सही काम को दूषित करने के शून्य जोखिम के साथ।
हार्नेस, ऑर्केस्ट्रेशन परत जो तय करती है कि कौन सा कार्य किस सैंडबॉक्स में जाता है और परिणामी पैच का क्या होता है, प्रत्येक व्यक्तिगत सैंडबॉक्स के बाहर रहता है। यह एक विशिष्ट और महत्वपूर्ण वास्तुशिल्प विकल्प है: रहस्यों, बाहरी उपकरणों और वास्तविक रिपॉजिटरी तक पहुँच वाली विश्वसनीय प्रक्रिया, अविश्वसनीय निष्पादन वातावरण से अलग रहती है जहाँ AI-जनरेटेड कोड वास्तव में चलता है। सैंडबॉक्स को अपने एक कार्य के लिए आवश्यक चीज़ें ही मिलती हैं, इससे अधिक कुछ नहीं। होस्ट प्रक्रिया कभी भी अपनी स्वयं की उन्नत अनुमतियों के साथ सीधे जनरेटेड कोड नहीं चलाती है। यह पृथक्करण ही है जो एजेंट के कोड को बिल्कुल भी निष्पादित करना सुरक्षित बनाता है, क्योंकि सैंडबॉक्स के अंदर एक गलती या यहाँ तक कि एक प्रतिकूल प्रॉम्प्ट इंजेक्शन का इसके बाहर किसी भी चीज़ तक कोई रास्ता नहीं है।
लूप ही: योजना बनाएँ, निष्पादित करें, सत्यापित करें, परिष्कृत करें
पैमाने और विशिष्ट उपकरणों को हटा दें, और इस सबके नीचे चलने वाले वास्तविक लूप के चार चरण हैं, प्रति कार्य तब तक दोहराते हैं जब तक कि वह कार्य पास नहीं हो जाता या अपने पुनः प्रयास बजट को समाप्त नहीं कर देता।
चरण एक: माइग्रेशन योजना। माइग्रेशन एजेंट को अपना सीमित कार्य, एक फाइल या मॉड्यूल, विशिष्ट लक्ष्य स्पेक (भाषा संस्करण, फ्रेमवर्क परिवर्तन, API संगतता आवश्यकताएँ) प्राप्त होता है, और एक उम्मीदवार रूपांतरण तैयार करता है। यह एकमात्र चरण है जहाँ रचनात्मक, निर्णय-आधारित भाषा मॉडल तर्क प्राथमिक कार्य कर रहा है, क्योंकि यह तय करना कि एक विशिष्ट पैटर्न को एक नए फ्रेमवर्क में उसके समकक्ष में सही ढंग से कैसे अनुवादित किया जाए, वास्तव में समझ की आवश्यकता होती है, न कि केवल यांत्रिक देखो।
चरण दो: स्वचालित वातावरण सेटअप। एक अलग घटक, जिसे कभी-कभी इस पैटर्न पर अकादमिक साहित्य में पर्यावरण एजेंट कहा जाता है, स्वायत्त रूप से माइग्रेट किए गए कोड के लिए एक बिल्ड और रनटाइम वातावरण का निर्माण करता है, निर्भरता समाधान और कॉन्फ़िगरेशन को संभालता है ताकि उम्मीदवार पैच को वास्तविक रूप से संकलित और चलाया जा सके, न कि अमूर्त रूप से मूल्यांकन किया जा सके।
चरण तीन: परीक्षण सत्यापन। माइग्रेट किया गया कोड वास्तविक परीक्षण सूट के विरुद्ध चलता है, या यदि उस विशिष्ट मॉड्यूल के लिए कोई परीक्षण सूट मौजूद नहीं है तो एक उत्पन्न समकक्ष के विरुद्ध चलता है। यह यांत्रिक सत्यापन चरण है, जो एक छाप के बजाय एक उद्देश्यपूर्ण पास या फेल उत्पन्न करता है। या तो परीक्षण पास होते हैं या नहीं होते हैं, और एजेंट के अपने तरीके से बात करने के लिए कोई अस्पष्टता नहीं है।
चरण चार: फीडबैक परिशोधन। विफलता पर, विशिष्ट परीक्षण विफलताओं और डायग्नोस्टिक लॉग को लक्षित सुधार इनपुट के रूप में माइग्रेशन एजेंट को वापस भेज दिया जाता है, न कि एक अस्पष्ट "यह काम नहीं किया, फिर से प्रयास करें।" पैच का मालिक एजेंट वास्तविक सबूतों के आधार पर अपने विशिष्ट तर्क और निर्भरता मैपिंग को परिष्कृत करता है कि क्या टूटा, न कि शुरू से एक सामान्य पुनः प्रयास।
यह चार-चरणीय चक्र प्रति कार्य दोहराता है, एक परिभाषित सीमा के साथ। इस सटीक लूप पैटर्न का एक दस्तावेजीकृत, काम करने वाला संस्करण "कोई फाइलें पुराने पैटर्न से मेल नहीं खाती हैं" जैसी स्टॉप स्थिति के साथ-साथ एक कठोर अधिकतम पुनरावृत्ति गणना निर्दिष्ट करता है, एक प्रकाशित उदाहरण में, 200 पुनरावृत्तियाँ, जिसके बाद सिस्टम एक ऐसे कार्य पर अनिश्चित काल तक चलने के बजाय स्वचालित रूप से बंद हो जाता है जो अभिसरण नहीं कर रहा है।
वह सीमा बड़े पैमाने पर बहुत मायने रखती है। इसके बिना, एक कार्य जो संरचनात्मक रूप से पूरा करना असंभव है, क्योंकि स्पेक स्वयं अस्पष्ट है या लक्ष्य पैटर्न का वास्तव में कोई साफ समकक्ष नहीं है, हमेशा के लिए संसाधनों को जलाएगा, बजाय इसके कि एक विशिष्ट, सीमित विफलता के रूप में सामने आए जिसे एक मानव वास्तव में देख और हल कर सकता है।
मानव समीक्षा क्यों स्केल नहीं करती है, और इसे क्या बदलता है
यह सटीक होने लायक है कि क्यों "प्रत्येक की समीक्षा करने वाला कोई मानव नहीं" यहाँ वास्तव में सुरक्षित डिज़ाइन है, न कि कोई कटा हुआ कोना।
AI एजेंट कोड समीक्षा की तुलना मानव कोड समीक्षा से करने वाले शोध में कुछ विशिष्ट और उपयोगी पाया गया: AI-जनरेटेड समीक्षा टिप्पणियाँ कोड की प्रति पंक्ति मानव समीक्षाओं की तुलना में लगभग सात गुना अधिक लंबी चलती हैं, और लगभग पूरी तरह से कोड सुधार और दोष का पता लगाने पर केंद्रित होती हैं, जबकि मानव समीक्षा स्वाभाविक रूप से पूरी तरह से अन्य चीजों में फैलती है, साझा समझ का निर्माण, ज्ञान का हस्तांतरण, टीम के साथियों के बीच सामाजिक संचार। मानव समीक्षा आगे-पीछे फीडबैक के प्रकार के आधार पर बहुत भिन्न होती है। AI-से-AI समीक्षा बातचीत इस बात की परवाह किए बिना कि क्या फ्लैग किया जा रहा है, कहीं अधिक समान और यांत्रिक है।
इसे सही ढंग से पढ़ें और यह कुछ महत्वपूर्ण कहता है: मानव समीक्षा और AI सत्यापन संरचनात्मक रूप से अलग-अलग चीजों में अच्छे हैं। एक मानव को एजेंट झुंड द्वारा उत्पादित गति और मात्रा पर 800 अलग-अलग डिफ़ की समीक्षा करने के लिए कहना एक सुरक्षा उन्नयन नहीं है, यह एक अड़चन है जो रबर-स्टैम्प अनुमोदन उत्पन्न करती है, क्योंकि कोई भी मानव उस मात्रा में वास्तविक जाँच बनाए नहीं रख सकता है। डार्क फैक्ट्री पैटर्न में वास्तविक सुरक्षा सत्यापन को हटाने से नहीं आती है। यह एक प्रकार के सत्यापन को बदलने से आती है, धीमी, थकाऊ, असंगत मानव ध्यान जो सैकड़ों दोहराए जाने वाले डिफ़ में फैला हुआ है, एक अलग प्रकार से जो स्केल करता है: नियतात्मक बिल्ड और टेस्ट सत्यापन जो डिफ़ 1 और डिफ़ 800 पर बिल्कुल समान कठोरता उत्पन्न करता है, शून्य ध्यान थकान के साथ।
यह भी ठीक वही कारण है कि योजनाकार चरण अनुक्रमण के लिए LLM निर्णय के बजाय कंपाइलर-आधारित स्थैतिक विश्लेषण का उपयोग करता है। सिस्टम में कहीं भी एक नियतात्मक जाँच एक निर्णय कॉल को बदल सकती है, उसे ऐसा करना चाहिए, क्योंकि नियतात्मक जाँचें इस वास्तुकला का एकमात्र हिस्सा हैं जो बाद में वास्तव में ऑडिट करने योग्य हैं। आप ठीक से दोबारा चला सकते हैं कि एक स्थैतिक विश्लेषक ने क्या पाया। आप पूरी तरह से दोबारा नहीं चला सकते कि एक भाषा मॉडल ने एक विशेष माइग्रेशन ऑर्डर को सही क्यों "महसूस" किया।
अभी भी किस चीज़ को एक मानव की आवश्यकता है, और रेखा वास्तव में कहाँ है
यह पैटर्न "मनुष्यों को पूरी तरह से हटा दें और आशा करें" नहीं है। इसका हर विश्वसनीय प्रकाशित संस्करण, गूगल की प्रोडक्शन प्रणाली, अकादमिक एनवायरनमेंट-इन-द-लूप शोध, OpenAI का अपना कुकबुक, एक स्पष्ट रेखा खींचता है कि मानव निर्णय कहाँ अनिवार्य रहता है।
एजेंट-संचालित लाइब्रेरी माइग्रेशन के एक मात्रात्मक अध्ययन में लगातार निष्कर्ष: एजेंट विश्वसनीय रूप से उच्च माइग्रेशन कवरेज प्राप्त करते हैं, सही ढंग से पहचानते हैं कि कौन से API परिवर्तन आवश्यक हैं, लेकिन विशेष रूप से अधिक जटिल मामलों में समग्र एप्लिकेशन व्यवहार को संरक्षित करने में संघर्ष करते हैं, जहाँ एक सफल माइग्रेशन के लिए इरादे को समझने की आवश्यकता होती है, न कि केवल पैटर्न-मिलान सिंटैक्स की। उस निष्कर्ष के बाद सीधे आने वाली सिफारिश पूरे बैच के लिए नहीं, बल्कि फाइलों के उस सबसेट के लिए एक मानव-इन-द-लूप चेकपॉइंट है जिसे नियतात्मक सत्यापन उच्च-जोखिम या कम-विश्वास के रूप में फ्लैग करता है।
व्यवहार में, यह एक स्तरीय प्रणाली उत्पन्न करता है। जिन फाइलों को स्थैतिक निर्भरता विश्लेषण छोटा, अच्छी तरह से पृथक और संरचनात्मक रूप से सरल के रूप में वर्गीकृत करता है, किसी भी वास्तविक माइग्रेशन का बड़ा हिस्सा, नियतात्मक बिल्ड और टेस्ट गेट से परे शून्य मानव स्पर्श के साथ पूरी तरह से स्वचालित लूप के माध्यम से प्रवाहित होती हैं। जिन फाइलों को जटिल, गहराई से अन्योन्याश्रित, या व्यावसायिक-महत्वपूर्ण तर्क को छूने वाली के रूप में फ्लैग किया जाता है, वे मर्ज करने से पहले वास्तविक मानव समीक्षा के लिए एक कतार में रूट होती हैं, भले ही अन्यथा पूरी तरह से स्वचालित प्रणाली के अंदर हों।
यह स्तरीय दृष्टिकोण "800 एजेंट, प्रत्येक की समीक्षा करने वाला शून्य मानव" का यथार्थवादी संस्करण है। ऐसा नहीं है कि कोई मानव कभी कुछ नहीं देखता है। यह है कि सिस्टम विशेष रूप से यांत्रिक, कम जोखिम वाले काम के 95% को पूर्ण स्वचालन के माध्यम से रूट करने के लिए डिज़ाइन किया गया है, जबकि दुर्लभ संसाधन, वास्तविक मानव निर्णय, को विशेष रूप से उन मामलों के छोटे अंश पर केंद्रित करता है जहाँ यह वास्तव में मूल्य जोड़ता है जिसे नियतात्मक सत्यापन दोहरा नहीं सकता है।
अपने स्वयं के कोडबेस के लिए इसे बनाना
पैटर्न उतनी ही सफाई से नीचे की ओर स्केल करता है जितना ऊपर की ओर। वही चार भूमिकाएँ लागू होती हैं चाहे आप एक विशाल प्रोडक्शन कोडबेस के खिलाफ 800 समानांतर एजेंट चला रहे हों या एक एकल रिपॉजिटरी के खिलाफ मुट्ठी भर अनुक्रमिक माइग्रेशन कार्य।
योजनाकार से शुरू करें, और इसे LLM बनाने के आग्रह का विरोध करें। यदि आपके माइग्रेशन में किसी भी प्रकार की निर्भरता संरचना है, फ़ाइल इम्पोर्ट, साझा इंटरफ़ेस, बिल्ड ऑर्डर, तो उस निर्भरता ग्राफ को यांत्रिक रूप से बनाने के लिए अपनी भाषा के लिए उपयुक्त वास्तविक स्थैतिक विश्लेषण उपकरण का उपयोग करें। यह एकल निर्णय पूरे सिस्टम में सबसे अधिक लीवरेज वाला है, क्योंकि हर डाउनस्ट्रीम चरण को योजनाकार द्वारा किए गए किसी भी ऑर्डरिंग गलतियाँ विरासत में मिलती हैं।
प्रत्येक व्यक्तिगत कार्य को उतना ही संकीर्ण रूप से स्कोप करें जितना निर्भरता ग्राफ अनुमति देता है। एक फाइल, एक मॉड्यूल, एक स्पष्ट रूप से बंधी हुई परिवर्तन इकाई, एक स्पष्ट ब्रीफ के साथ जो वर्णन करता है कि वास्तव में क्या होने की आवश्यकता है और क्यों। केवल दक्षता के लिए कई असंबंधित परिवर्तनों को एक कार्य में संयोजित करने का विरोध करें, क्योंकि संकीर्ण दायरा ही वह चीज़ है जो सत्यापन चरण के पास-या-फेल निर्णय को स्पष्ट बनाता है।
प्रत्येक कार्य के निष्पादन को पृथक करें। न्यूनतम प्रति कार्य एक ताजा git वर्कट्री, यदि आप इसे किसी भी वास्तविक पैमाने पर चला रहे हैं तो एक पूर्ण सैंडबॉक्स वातावरण। यह वैकल्पिक बुनियादी ढाँचा ओवरहेड नहीं है। यह वह चीज़ है जो समानांतरीकरण को सुरक्षित बनाती है और एक एकल एजेंट की गलती को समाहित करती है न कि संक्रामक।
बाकी सब कुछ बनाने से पहले नियतात्मक सत्यापन बनाएँ। संकलन सफलता, परीक्षण सूट पास दर, व्यवहारिक समतुल्यता जाँच जहाँ आप उनका निर्माण कर सकते हैं। यह वह घटक है जो "क्या एजेंट ने कहा कि यह काम कर गया" को "क्या यह वास्तव में काम कर गया" से बदल देता है, और यह एकमात्र ऐसा घटक है जिसे अधिकांश घरेलू माइग्रेशन प्रयास पूरी तरह से छोड़ देते हैं, यही कारण है कि वे प्रयास किसी भी सार्थक पैमाने पर विफल होते हैं।
पुनः प्रयास लूप को स्पष्ट रूप से सीमित करें, एक संख्या के साथ, भावना से नहीं। कुछ भी चलाने से पहले परिभाषित करें कि "यह कार्य अटक गया है" कैसा दिखता है, और अटके हुए कार्यों को स्वचालित रूप से एक मानव कतार में रूट करें, बजाय इसके कि उन्हें अनिश्चित काल तक संसाधनों का उपभोग करने दें या, इससे भी बदतर, चुपचाप झूठी सफलता की रिपोर्ट करें।
सुर्खियों के आंकड़े के नीचे का वास्तविक सबक
किसी भी विशिष्ट बड़े पैमाने के माइग्रेशन में चलने वाली वास्तविक संख्या जो भी हो, 800 एजेंट या 80 या 8,000, सुर्खियों का आंकड़ा कहानी का सबसे कम दिलचस्प हिस्सा है। दिलचस्प हिस्सा यह है कि उनमें से कोई भी एजेंट व्यक्तिगत रूप से यह तय करने के लिए भरोसेमंद नहीं है कि उनका अपना काम सही है या नहीं, और पूरी सिस्टम उस अविश्वास के आसपास डिज़ाइन की गई है, न कि इसके बावजूद।
एक डार्क फैक्ट्री अंधेरे में इसलिए नहीं चलती है क्योंकि कोई नहीं देख रहा है। यह अंधेरे में इसलिए चलती है क्योंकि देखना पूरी तरह से मशीनरी में ही स्थानांतरित कर दिया गया है, कंपाइलर जाँचों और परीक्षण सूटों और निर्भरता ग्राफों में जो हर बार एक ही कठोर उत्तर उत्पन्न करते हैं, फाइल एक और फाइल आठ सौ पर, बिना थकान के और उस असंगति के बिना जो एक मानव को एक ही दोहराए जाने वाले निर्णय कॉल को हजारों बार लगातार करने के लिए कहने से आती है।
यही वास्तविक पैटर्न है जो अभी प्रोडक्शन में काम कर रहे इसके हर संस्करण के पीछे है। बड़े मॉडलों में अधिक साहसी भरोसा नहीं। किसी भी एकल घटक, मानव या AI, को अपने स्वयं के काम का एकमात्र न्यायाधीश होने से रोकने के लिए एक अधिक अनुशासित इनकार।
अधिक AI सामग्री के लिए @cyrilxbt को फॉलो करें
