लूप इंजीनियरिंग (Loop engineering) का दौर चल रहा है। किसी भी तकनीकी फ़ोरम को देखें और आपको ऐसे लोग मिलेंगे जो तर्क दे रहे हैं कि हमें AI एजेंटों को चालाक प्रॉम्प्ट्स (prompts) के साथ प्रशिक्षित किए जाने वाले चैटबॉट्स की तरह मानना बंद कर देना चाहिए। इसके बजाय, वे कहते हैं कि हमें लूप डिज़ाइन करने चाहिए: स्वायत्त चक्र (autonomous cycles) जो एक एजेंट को योजना बनाने, निष्पादित करने, अपने काम की जाँच करने और हमारे सोते समय दोहराने (iterate) की अनुमति देते हैं। यह प्रस्ताव लुभावना है। यदि लूप अच्छी तरह से बनाया गया है, तो एजेंट निरंतर मानवीय पर्यवेक्षण के बिना सही रास्ते पर रहता है, जिससे कच्चा इरादा (raw intent) रातों-रात तैयार आउटपुट में बदल जाता है।
वह वादा सिद्धांत रूप में बहुत अच्छा काम करता है। व्यवहार में, अधिकांश एजेंट पहले से ही लूप करते हैं। वे कोड जनरेट करते हैं, कंपाइलर एरर या टेस्ट फेलियर की जाँच करते हैं, कोड को पैच करते हैं, और फिर से सूट चलाते हैं। वह बुनियादी फीडबैक चक्र नया नहीं है। समर्थक अब जिस चीज़ की मांग कर रहे हैं वह कुछ अधिक महत्वाकांक्षी है: एक बाहरी लूप (outer loop) जो केवल सिंटैक्स एरर को ही नहीं, बल्कि पूरे कार्य को नियंत्रित करता है। उस बाहरी लूप का निर्माण करना ही कठिन काम है, क्योंकि सॉफ्टवेयर इंजीनियरिंग शायद ही कभी निश्चित नियमों वाला कोई बंद सिस्टम (closed system) होता है।
लूप डिज़ाइन की समस्या
उत्पाद के लक्ष्य अव्यवस्थित होते हैं। आप शायद ही कभी 'काम पूरा होने' (definition of done) की सटीक परिभाषा के साथ शुरुआत करते हैं। अक्सर, आप वास्तविक लक्ष्य की खोज तब करते हैं जब आप निर्माण (build) में पूरी तरह से डूबे होते हैं। एक आवश्यकता जो व्हाइटबोर्ड पर सीधी-सादी लग रही थी, उसके ऐसे एज केस (edge cases) निकल सकते हैं जो समाधान के स्वरूप को पूरी तरह से बदल देते हैं। जब आप एक एजेंट को एक कठोर लूप के भीतर रखते हैं, तो वह कठोरता एक दोष बन जाती है। लूप लगातार एक ऐसे लक्ष्य पर प्रहार करता रहता है जो शायद गलत हो सकता है। इससे भी बुरा यह है कि एक लचीला लूप कभी-कभी लक्ष्य को चुपचाप बदलकर डेडलॉक (deadlock) को हल कर देता है ताकि वह जो भी आउटपुट बना पाया है उससे मेल खा सके। दोनों में से कोई भी परिणाम उपयोगी नहीं है। एक कंप्यूट (compute) बर्बाद करता है; दूसरा आत्मविश्वास के साथ कचरा (garbage) डिलीवर करता है।
गहरा मुद्दा स्पेसिफिकेशन लागत (specification cost) का है। यदि आप चाहते हैं कि लूप बिना किसी पर्यवेक्षण के चले, तो आपको एक ऐसा स्पेसिफिकेशन लिखना होगा जो लगभग हर चीज़ का पूर्वानुमान लगा सके। एजेंट को वास्तव में क्या बदलना चाहिए? कौन सा मौजूदा व्यवहार पवित्र है और उसे सुरक्षित रखा जाना चाहिए? किन सटीक परिस्थितियों में एजेंट को दोहराना (iterating) बंद कर देना चाहिए? कौन से जोखिम स्वीकार्य हैं, और किन साइड इफेक्ट्स (side effects) के कारण तुरंत रोक लग जानी चाहिए? उस दस्तावेज़ को लिखने में एजेंट के साथ बैठकर वास्तविक समय में कार्य को निर्देशित करने की तुलना में अधिक समय लग सकता है। आप ऑटोमेशन के बदले में एक भारी अग्रिम कर (upfront tax) चुका रहे हैं, जिसका लाभ केवल तभी मिलता है जब सत्यापन (verification) करना काम करने की तुलना में बहुत सस्ता हो।
लूप वास्तव में कहाँ सार्थक होते हैं
इसका मतलब यह नहीं है कि लूप इंजीनियरिंग बेकार है। इसका मतलब है कि यह एक विशिष्ट उपकरण है, न कि एक सार्वभौमिक रणनीति। लूप तब चमकते हैं जब सत्यापन की लागत बढ़ती जाती है और सफलता के मानदंड स्पष्ट होते हैं। ऐसे तीन क्षेत्र हैं जहाँ यह बात सच साबित होती है।
नियमित यांत्रिक कार्य (Routine mechanical work)। उन कार्यों के बारे में सोचें जो सीनियर इंजीनियरों को रिटायर होने पर मजबूर कर देते हैं: एक विशिष्ट क्रम में एप्लिकेशन शुरू करना, प्रत्येक चरण की पुष्टि करने के लिए डिप्लॉयमेंट UI पर क्लिक करना, रिलीज़ के बाद ज्ञात एरर स्ट्रिंग्स के लिए लॉग्स को ग्रेप (grep) करना, या यह सत्यापित करना कि कॉन्फ़िगरेशन फ़ाइल सभी सही नोड्स पर लिखी गई है। ये कदम मनुष्यों के लिए उबाऊ हैं लेकिन सत्यापित करना बहुत आसान है। एक लूप इस प्रक्रिया की देखरेख कर सकता है, प्रत्येक रीस्टार्ट के बाद हेल्थ एंडपॉइंट्स (health endpoints) की जाँच कर सकता है और समस्या के पहले संकेत पर रोलबैक (rollback) कर सकता है। इंसान अभी भी रोलआउट योजना को परिभाषित करता है। लूप बस रात के दो बजे मशीन के धैर्य के साथ उसे निष्पादित करता है।
मापने योग्य अनुकूलन लक्ष्य (Measurable optimization goals)। जब सफलता एक संख्या होती है, तो लूप अविश्वसनीय रूप से प्रभावी होते हैं। p99 लेटेंसी को 150 मिलीसेकंड से नीचे लाएं। मेमोरी फुटप्रिंट को बीस प्रतिशत कम करें। एक हॉट पाथ (hot path) को Python से Rust में माइग्रेट करें और सुनिश्चित करें कि सभी मौजूदा यूनिट टेस्ट अभी भी पास हो रहे हैं। लूप एक बदलाव जनरेट कर सकता है, उसका बेंचमार्क कर सकता है, उस वेरिएंट को रख सकता है जिसने परिणाम सुधारा है, और बाकी को हटा सकता है। क्योंकि सत्यापन स्वचालित है और सर्च स्पेस (search space) बड़ा है, इसलिए मैन्युअल समीक्षा की बढ़ती लागत लूप के बिना इस काम को अव्यावहारिक बना देगी। लक्ष्य निश्चित है। रास्ता अज्ञात है। यही इसका सबसे सही उपयोग (sweet spot) है।
ऑपरेशनल प्लेबुक्स (Operational playbooks)। इंसिडेंट रिस्पांस (Incident response) और सपोर्ट टिकट अक्सर उन पैटर्न का पालन करते हैं जिन्हें इंसान पहले ही समझ चुके हैं। प्रोडक्शन एरर का एक विशिष्ट वर्ग हमेशा क्रेडेंशियल बदलने और कैश (cache) साफ़ करने की मांग करता है। सपोर्ट अनुरोध की एक श्रेणी को तब रिफंड के साथ हल किया जा सकता है जब तीन विशिष्ट शर्तें पूरी होती हैं। एक लूप उन ट्रिगर्स पर नज़र रख सकता है और प्लेबुक को निष्पादित कर सकता है, और केवल तभी मामला आगे बढ़ा सकता है (escalating) जब पैटर्न टूट जाए। यह यह तय नहीं करता कि प्लेबुक सही है; यह केवल उस स्तर और गति पर निरंतरता लागू करता है जिसका ऑन-कॉल इंजीनियर मुकाबला नहीं कर सकते।
रेगुलेटर, न कि रेफरेंस-सेटर
वर्तमान बातचीत के एक बड़े हिस्से में एक महत्वपूर्ण अंतर गायब है। लूप्स (Loops) नियामक (regulators) होते हैं। वे एक सिस्टम को पूर्व-निर्धारित लक्ष्य के साथ संरेखित रखते हैं, ठीक वैसे ही जैसे एक थर्मोस्टेट कमरे को बहत्तर डिग्री पर बनाए रखता है। लेकिन थर्मोस्टेट बहत्तर डिग्री का चुनाव नहीं करता। किसी को पहले यह तय करना पड़ा था कि वही सही तापमान है।
सॉफ्टवेयर के संदर्भ में, इसका अर्थ है कि एक लूप के भीतर एक एजेंट पूरे दिन बग्स (bugs) ठीक कर सकता है, फंक्शन्स (functions) को रिफैक्टर (refactor) कर सकता है, या पैरामीटर्स (parameters) को ट्यून कर सकता है। हालाँकि, यह यह तय नहीं कर सकता कि कौन सा फीचर वास्तव में ग्राहक की मदद करता है या अगली रिलीज़ से पहले किसी बग को ठीक करना सार्थक है या नहीं। उन विकल्पों के लिए बिजनेस कॉन्टेक्स्ट (business context), यूजर की समस्याओं (user pain) और रणनीतिक प्राथमिकता (strategic priority) के बारे में निर्णय लेने की आवश्यकता होती है। एजेंट निष्पादित (execute) करते हैं। इंसान निर्णय लेते हैं। इन दोनों के बीच भ्रमित होना ही वह कारण है जिससे टीमें अंततः ऐसे खूबसूरती से ऑप्टिमाइज्ड (optimized) सिस्टम के साथ रह जाती हैं जो गलत समस्या का समाधान करते हैं।
लूप इंजीनियरिंग (Loop engineering) उपयोगी है, लेकिन यह सीमित है। यह आपको अनुशासन और गति के साथ मशीन चलाने में मदद करती है। यह यह तय नहीं करती कि कौन सी मशीन बनानी है, यह किसके लिए है, या मानवीय दृष्टिकोण से सफलता कैसी दिखती है। कौन सा फीचर महत्वपूर्ण है, कौन सा जोखिम स्वीकार्य है, और कब लक्ष्य को ही बदलने की आवश्यकता है—इसका निर्णय आपके पास ही होता है। उन कार्यों के लिए लूप्स बनाएं जिन्हें आप स्वचालित रूप से सत्यापित (verify) करने के लिए पहले से ही पर्याप्त रूप से समझते हैं। बाकी सब कुछ अपने नियंत्रण में रखें।
यह लेख मूल रूप से Isaac Hagoel द्वारा “Loop Engineering Minus The Hype.” में चर्चा किए गए विचारों पर आधारित है। इंजीनियरिंग से जुड़ी अधिक चर्चाओं के लिए, Telegram पर हमारे लर्निंग कम्युनिटी से जुड़ें।