एक विशिष्ट पल होता है जो किसी व्यक्ति को AI का सामान्य उपयोग करने वाले से लेकर उसे एक सिस्टम के रूप में चलाने वाले में अलग करता है।
वह पल वह होता है जब वे गलती पकड़ने वाले व्यक्ति नहीं रह जाते।
अभी, ज़्यादातर लोगों के लिए, लूप कुछ इस तरह दिखता है। Claude से कुछ माँगें। आउटपुट पढ़ें। गौर करें कि कुछ गलत है। उसे इंगित करें। सही संस्करण प्राप्त करें। उसे पढ़ें। कुछ और गौर करें। फिर से इंगित करें। आप सत्यापन लेयर हैं, हर बार मैन्युअली, हर एक कार्य के लिए।
एक स्व-सुधारात्मक लूप आपको उस स्थिति से पूरी तरह हटा देता है। सिस्टम जनरेट करता है, अपने काम को एक वास्तविक मानक के विरुद्ध जाँचता है, जो गलत हुआ उसे पकड़ता है, उसे ठीक करता है, और तभी आपको परिणाम दिखाता है। जब तक आप आउटपुट देखते हैं, स्पष्ट गलतियाँ पहले ही पकड़ी और संभाली जा चुकी होती हैं। आपके लिए जो बचता है वह उन चीज़ों पर निर्णय है जिनमें वास्तव में मानव की आवश्यकता है, किसी मशीन के पहले ड्राफ्ट को प्रूफरीड करना नहीं।
यह संपूर्ण निर्माण है। अंत तक आपके पास सटीक आर्किटेक्चर, सटीक प्रॉम्प्ट, और सटीक विफलता मोड होंगे, जिनका परीक्षण करना है इससे पहले कि आप इसे किसी भी महत्वपूर्ण चीज़ के लिए विश्वसनीय मानें।
यह दो बार पूछने जैसा क्यों नहीं है
सबसे स्पष्ट पहली प्रवृत्ति यह है कि मॉडल से उसी वार्तालाप में अपने काम की जाँच करने के लिए कहें। "आपने अभी जो लिखा है उसकी समीक्षा करें और कोई भी गलती ठीक करें।" इससे थोड़ी मदद मिलती है। यह एक वास्तविक स्व-सुधारात्मक लूप नहीं बनाता है, और यह समझना कि ऐसा क्यों है, आगे की पूरी नींव है।
एक मॉडल जो उसी संदर्भ में अपने आउटपुट की समीक्षा करता है, उसी तर्क के साथ जिसने गलती उत्पन्न की, वह अपने काम का बचाव करता है न कि वास्तव में उसकी जाँच करता है। यह किसी एक मॉडल की खामी नहीं है। यह एक संरचनात्मक समस्या है। वही पास जिसने एक प्रशंसनीय लेकिन गलत उत्तर उत्पन्न किया, वह यह नोटिस करने की स्थिति में नहीं है कि वह गलत है, क्योंकि अंदर से, उत्तर अभी भी प्रशंसनीय लगता है। "क्या आपको यकीन है?" पूछने पर अक्सर पुनः जाँच की तुलना में अधिक आश्वासन मिलता है।
समाधान बेहतर पूछना नहीं है। यह आर्किटेक्चर है। एक वास्तविक स्व-सुधारात्मक लूप उत्तर उत्पन्न करने के काम को उसका निर्णय करने के काम से अलग करता है, एक अलग पास, एक अलग प्रॉम्प्ट, और आदर्श रूप से एक पूरी तरह से अलग संदर्भ का उपयोग करता है, ताकि निर्णय उन्हीं अंध धब्बों से दूषित न हो जिन्होंने गलती पैदा की।
हर स्व-सुधारात्मक लूप को तीन भूमिकाओं की आवश्यकता होती है
हर काम करने वाली स्व-सुधारात्मक प्रणाली, चाहे विशिष्ट कार्य कुछ भी हो, तीन अलग-अलग भूमिकाओं में सिमट जाती है। इन भूमिकाओं को स्पष्ट रूप से समझना नीचे दिए गए किसी भी विशिष्ट प्रॉम्प्ट से अधिक महत्वपूर्ण है, क्योंकि एक बार जब आप उन्हें देख लेते हैं, तो आप विवरण भरकर लगभग किसी भी कार्य के लिए एक लूप बना सकते हैं।
निर्माता (Builder)। वास्तविक आउटपुट उत्पन्न करता है। कोड लिखता है, सामग्री का ड्राफ्ट बनाता है, शोध करता है, कार्य निष्पादित करता है। इस भूमिका को सबसे अधिक रचनात्मक स्वतंत्रता और सबसे कम बाधाएँ दी जानी चाहिए, क्योंकि इसका काम पहला प्रयास उत्पन्न करना है, एक आदर्श नहीं।
निर्णायक (Judge)। कुछ भी निर्माण नहीं करता। इसका एकमात्र काम निर्माता के आउटपुट का एक विशिष्ट, लिखित मानक के विरुद्ध मूल्यांकन करना है, गुणवत्ता की एक अस्पष्ट भावना के विरुद्ध नहीं। क्या कोड अपने परीक्षण पास करता है? क्या ड्राफ्ट ब्रीफ से मेल खाता है? क्या शोध वास्तव में पूछे गए प्रश्न का उत्तर देता है? निर्णायक के पास आदर्श रूप से कुछ ऐसा होना चाहिए जो निर्माता के पास नहीं है: मूल स्रोत सामग्री, परीक्षण सूट, वास्तविक आवश्यकता दस्तावेज़, ताकि उसके पास जाँच करने के लिए स्वतंत्र ग्राउंड ट्रुथ हो, न कि केवल उसी आउटपुट को फिर से पढ़कर एक नई राय बनाना।
प्रबंधक (Manager)। निर्णायक के फैसले को पढ़ता है और तय करता है कि आगे क्या होगा। इसे विशिष्ट फीडबैक के साथ निर्माता को वापस भेजें। किसी मानव को एस्केलेट करें। कार्य को पूर्ण चिह्नित करें। यहीं पर आपकी रोक शर्त (stop condition) भी रहती है, वह नियम जो लूप को हमेशा के लिए चलने से रोकता है जब कोई चीज़ वास्तव में स्वचालित रूप से ठीक नहीं हो सकती।
तीनों भूमिकाओं में महत्वपूर्ण डिज़ाइन सिद्धांत: सत्यापन को निर्माता के अपने तर्क के बाहर किसी चीज़ का संदर्भ लेना चाहिए। एक परीक्षण सूट। एक मूल स्रोत दस्तावेज़। एक लिखित चेकलिस्ट। एक दूसरा AI कॉल जिसमें वास्तव में अलग फ्रेमिंग हो। कुछ भी जो केवल "वही मॉडल, उसी सांस में, फिर से पूछा गया" नहीं है।
हैंडऑफ़ का निर्माण
एक स्व-सुधारात्मक लूप में वास्तविक इंजीनियरिंग कार्य प्रत्येक भूमिका के लिए चतुर प्रॉम्प्ट नहीं है। यह उनके बीच से गुज़रने वाली चीज़ों की संरचना है, और यह वह हिस्सा है जिसे अपना पहला लूप बनाने वाले अधिकांश लोग पूरी तरह से छोड़ देते हैं, फिर आश्चर्य करते हैं कि सिस्टम अप्रत्याशित व्यवहार क्यों करता है।
एक हैंडऑफ़ को विश्वसनीय रूप से काम करने के लिए तीन गुणों की आवश्यकता होती है। एक परिभाषित प्रारूप, ताकि प्राप्त करने वाली भूमिका ढीले गद्य को पार्स न कर रही हो और अनुमान न लगा रही हो कि क्या मायने रखता है। एक परिभाषित ट्रिगर, ताकि निर्माता यह तय न करे कि वह कब समाप्त हुआ है। और एक परिभाषित विफलता पथ, ताकि जब कोई चीज़ साफ-सुथरी न हो, तो एक निर्दिष्ट अगला कदम हो, न कि सिस्टम चुपचाप टूट जाए या हमेशा के लिए लूप करता रहे।
व्यवहार में, इसका मतलब है कि निर्माता को कुछ संरचित आउटपुट देना चाहिए, न कि केवल संवादी पाठ। एक स्पष्ट डिलीवरेबल प्लस यह स्पष्ट बयान कि वह किस बारे में अनिश्चित है। फिर निर्णायक उस संरचित आउटपुट का एक लिखित मानक के विरुद्ध मूल्यांकन करता है और अपना स्वयं का संरचित फैसला लौटाता है: एक स्पष्ट पास, फेल, या पुनरीक्षण आवश्यक, जिसमें विशिष्ट कारण संलग्न हो। प्रबंधक उस संरचित फैसले को पढ़ता है, कच्ची सामग्री को नहीं, और पहले से स्थापित नियमों के आधार पर अगली कार्रवाई तय करता है, न कि पल में एक निर्णय कॉल को सुधार कर।
यहाँ एक टेम्पलेट संरचना है जो अधिकांश कार्यों पर काम करती है, चाहे अंतर्निहित कार्य लेखन, कोड, या शोध हो:
1निर्माता आउटपुट प्रारूप2डिलीवरेबल: [वास्तविक आउटपुट]3आत्मविश्वास: [उच्च / मध्यम / निम्न]4ज्ञात अनिश्चितताएँ: [जिसके बारे में आप अनिश्चित हैं, स्पष्ट रूप से बताया गया]5मान्यताएँ बनाई गईं: [जो कुछ भी आपने बिना बताए मान लिया]67निर्णायक फैसला प्रारूप8फैसला: [पास / फेल / पुनरीक्षण आवश्यक]9जाँच के विरुद्ध: [प्रयुक्त विशिष्ट मानक, जैसे मूल ब्रीफ, परीक्षण सूट, स्रोत दस्तावेज़]10पाए गए विशिष्ट मुद्दे: [सटीक समस्याएँ, सामान्य धारणा नहीं]11इस फैसले में आत्मविश्वास: [उच्च / मध्यम / निम्न]1213प्रबंधक कार्रवाई14यदि पास: पूर्ण चिह्नित करें, उपयोगकर्ता को डिलीवर करें।15यदि फेल या पुनरीक्षण आवश्यक: निर्णायक के विशिष्ट मुद्दों के साथ निर्माता को वापस भेजें। पुनरीक्षण काउंटर बढ़ाएँ।16यदि पुनरीक्षण काउंटर [N] से अधिक हो: लूप करना बंद करें, मानव को एस्केलेट करें, जो कुछ भी प्रयास किया गया और क्यों विफल हुआ, उसका पूरा इतिहास संलग्न करें।
यह एक सामान्य आगे-पीछे की बातचीत की तुलना में अधिक संरचना जैसा लगता है, और यह है। यह अग्रिम लागत वह है जो आपको एक ऐसी प्रणाली खरीदती है जो सौवें रन पर उसी तरह व्यवहार करती है जैसे पहले रन पर, बजाय इसके कि संदर्भ जमा होने पर अप्रत्याशित रूप से बहती रहे।
निर्णायक को ग्राउंड ट्रुथ की आवश्यकता है, सिर्फ एक राय की नहीं
यह पूरी प्रणाली में सबसे महत्वपूर्ण एक सिद्धांत है, और इसका अपना एक खंड होना चाहिए क्योंकि इसे गलत करना चुपचाप बाकी सब कुछ कमजोर कर देता है।
एक निर्णायक जो केवल निर्माता का आउटपुट देखता है, जाँच करने के लिए कोई स्वतंत्र संदर्भ नहीं, केवल आंतरिक स्थिरता का मूल्यांकन कर सकता है: क्या आउटपुट सुसंगत और अच्छी तरह से स्वरूपित लगता है। वह शुद्धता का मूल्यांकन नहीं कर सकता: क्या आउटपुट वास्तव में माँग के अनुसार है या वास्तविक समस्या का समाधान करता है। एक आत्मविश्वास से गलत उत्तर, अच्छी तरह से स्वरूपित और आंतरिक रूप से सुसंगत, बिना ग्राउंड ट्रुथ वाले निर्णायक के पास हर बार निकल जाएगा।
कोडिंग कार्यों के लिए, ग्राउंड ट्रुथ परीक्षण सूट है, कोड चलाने का वास्तविक आउटपुट, लिंट परिणाम, बिल्ड स्थिति। "क्या यह कोड सही दिखता है" नहीं, बल्कि "क्या यह निष्पादित होने पर वास्तव में पास हुआ?"
सामग्री कार्यों के लिए, ग्राउंड ट्रुथ मूल स्रोत सामग्री और मूल ब्रीफ है, ड्राफ्ट के साथ-साथ। "क्या यह अच्छी तरह से पढ़ा जाता है" नहीं, बल्कि "क्या इस ड्राफ्ट में हर विशिष्ट दावा स्रोत में वास्तव में किसी चीज़ पर वापस जाता है, और क्या टुकड़ा वास्तव में ब्रीफ की हर आवश्यकता को पूरा करता है?"
शोध कार्यों के लिए, ग्राउंड ट्रुथ वास्तविक खोज परिणाम और स्रोत दस्तावेज़ हैं जिन पर शोध आधारित होना चाहिए था। "क्या यह सारांश आधिकारिक लगता है" नहीं, बल्कि "क्या हर दावा एक विशिष्ट स्रोत से जोड़ा जा सकता है, और क्या जिन स्रोतों की खोज की गई वे वास्तव में प्रासंगिक थे?"
यदि आप अपने विशिष्ट कार्य के लिए निर्णायक के ग्राउंड ट्रुथ को स्पष्ट नहीं कर सकते, तो अभी तक आपके पास स्व-सुधारात्मक लूप नहीं है। आपके पास एक पुनर्लेखन लूप है, जहाँ निर्माता की आत्मविश्वासपूर्ण गलती को निर्णायक द्वारा आत्मविश्वासपूर्ण ढंग से पुनर्लेखित किया जाता है, बजाय इसके कि वास्तव में पकड़ा जाए।
रोक शर्त वैकल्पिक नहीं है
एक स्व-सुधारात्मक लूप के महंगे, नियंत्रण से बाहर की गड़बड़ी बनने का सबसे आम तरीका एक स्पष्ट, कठोर रोक शर्त का अभाव है। इसके बिना, एक निर्माता और निर्णायक अनिश्चित काल तक चक्र कर सकते हैं, प्रत्येक पुनरीक्षण दूसरे मूल्यांकन को ट्रिगर करता है, प्रत्येक मूल्यांकन दूसरे पुनरीक्षण को ट्रिगर करता है, जबकि लागत बढ़ती है और कोई तब तक नोटिस नहीं करता जब तक बिल नहीं आता।
एक वास्तविक रोक शर्त के तीन घटक होने चाहिए, और तीनों को स्पष्ट तर्क के रूप में लागू किया जाना चाहिए, न कि पल में मॉडल के निर्णय पर छोड़ दिया जाना चाहिए।
एक अधिकतम पुनरावृत्ति गणना। पुनरीक्षण चक्रों पर एक कठोर सीमा, जिसके बाद प्रबंधक को मानव को एस्केलेट करने के लिए मजबूर किया जाता है, भले ही निर्णायक संतुष्ट हो या नहीं।
एक गुणवत्ता सीमा जो वास्तव में मापने योग्य हो, महत्वाकांक्षी नहीं। "काफी अच्छा" एक प्रॉम्प्ट के अंदर एक निर्देश के रूप में रोक शर्त नहीं है, क्योंकि यह एक सुझाव है जिसे मॉडल सही दबाव में अनदेखा कर सकता है और अंततः करेगा। एक विशिष्ट, जाँचने योग्य बार: सभी ग्यारह परीक्षण मामले पास होते हैं, या ड्राफ्ट ब्रीफ की सभी पाँच आवश्यकताओं को पूरा करता है, एक रोक शर्त है, क्योंकि इसे हर बार व्यक्तिपरक रूप से आंकने के बजाय यांत्रिक रूप से सत्यापित किया जा सकता है।
एक लागत या समय सीमा। एक पूर्ण बजट जिसे कार्य पार नहीं कर सकता, चाहे वह किसी भी स्थिति में हो जब वह सीमा टकराती है। यह वह सुरक्षा कवच है जो आपको विशेष रूप से सबसे खराब स्थिति से बचाता है: एक वास्तविक रूप से अनसुलझा कार्य तब तक लूप करता रहता है जब तक कोई चालान नोटिस नहीं करता।
रोक शर्तें
अधिकतम पुनरीक्षण: 3. तीसरे असफल फैसले पर, रुकें और पूर्ण पुनरीक्षण इतिहास के साथ मानव को एस्केलेट करें; चौथा चक्र स्वचालित रूप से प्रयास न करें।
गुणवत्ता सीमा: निर्णायक की चेकलिस्ट पर सभी आइटम पास दिखाने चाहिए, "अधिकतर पास" या "लगभग पर्याप्त" नहीं।
बजट सीमा: यदि इस कार्य ने [X] टोकन या [Y] मिनट से अधिक उपभोग किया है, तो वर्तमान स्थिति की परवाह किए बिना तुरंत रुकें और रिपोर्ट करें कि क्या पूरा हुआ बनाम क्या शेष है।
इन्हें प्रबंधक के वास्तविक तर्क में लिखें, न कि एक लंबे प्रॉम्प्ट के अंदर एक नरम निर्देश के रूप में जिसे मॉडल दबाव में खुद से बाहर निकाल सकता है।
एक काम का उदाहरण: स्व-सुधारात्मक सामग्री उत्पादन
इसे ठोस बनाने के लिए, यहाँ बताया गया है कि कैसे तीन भूमिकाएँ और रोक शर्त एक वास्तविक, सामान्य कार्य के लिए एक साथ आती हैं: एक स्रोत दस्तावेज़ को एक तैयार सामग्री के टुकड़े में बदलना, बिना किसी मानव के हर ड्राफ्ट को मैन्युअली प्रूफरीड किए।
निर्माता को स्रोत सामग्री और ब्रीफ प्राप्त होता है, और एक ड्राफ्ट तैयार करता है। इसके आउटपुट में ड्राफ्ट स्वयं, साथ ही एक स्पष्ट आत्मविश्वास बयान और लिखते समय जिस किसी भी चीज़ के बारे में वह अनिश्चित था उसकी एक सूची शामिल होती है: एक विशिष्ट संख्या जिसके बारे में वह पूरी तरह से सुनिश्चित नहीं था कि स्रोत में है, एक दावा जो उसने सीधे बताए जाने के बजाय अनुमान लगाया।
निर्णायक को ड्राफ्ट और मूल स्रोत एक साथ प्राप्त होते हैं, कभी भी ड्राफ्ट को अलग से नहीं। वह तीन विशिष्ट चीज़ों की जाँच करता है, प्रत्येक का अपना पास या फेल होता है। क्या ड्राफ्ट में हर तथ्यात्मक दावा स्रोत में वास्तव में मौजूद किसी चीज़ पर वापस जाता है? क्या ड्राफ्ट ब्रीफ की हर विशिष्ट आवश्यकता को पूरा करता है: लंबाई, स्वर, आवश्यक अनुभाग? क्या मुख्य तर्क या हुक वास्तव में मौजूद है और भराव से पतला नहीं हुआ है? निर्णायक तीनों जाँचों में से प्रत्येक पर अलग-अलग पास या फेल के साथ एक संरचित फैसला लौटाता है, क्योंकि इसे एक समग्र स्कोर में समेटने से यह छिप जाता है कि वास्तव में कौन सा आयाम विफल हुआ।
प्रबंधक उस संरचित फैसले को पढ़ता है। तीनों पर एक साफ पास ड्राफ्ट को अंतिम आउटपुट कतार में भेजता है। तथ्य-जाँच आयाम पर विफलता इसे सीधे फ़्लैग किए गए अप्रमाणित दावे के साथ निर्माता को वापस भेजती है, न कि "सटीकता की दोबारा जाँच करें" जैसा अस्पष्ट निर्देश। ब्रीफ अनुपालन पर विफलता इसे नामित विशिष्ट लापता आवश्यकता के साथ वापस भेजती है। तीन असफल चक्रों के बाद, उसी विशिष्ट जाँच पर, प्रबंधक लूप करना पूरी तरह से बंद कर देता है और एक मानव को एस्केलेट करता है, जिसमें जो कुछ भी प्रयास किया गया उसका पूरा इतिहास होता है, बजाय इसके कि किसी समस्या को फिर से आज़माना जारी रखे जिसे सिस्टम पहले ही प्रदर्शित कर चुका है कि वह अपने आप हल नहीं कर सकता।
यह एक छोटी प्रणाली है। तीन भूमिकाएँ, एक संरचित हैंडऑफ़ प्रारूप, एक स्पष्ट रोक शर्त। यह एक ऐसी प्रणाली भी है जिसे आप वास्तव में बिना निगरानी के चला सकते हैं और इसके आउटपुट पर भरोसा कर सकते हैं, क्योंकि हर विफलता मोड का एक परिभाषित पथ है, एक अपरिभाषित नहीं।
लूप का परीक्षण करने से पहले उस पर भरोसा न करें
इससे पहले कि आप किसी भी स्व-सुधारात्मक प्रणाली पर किसी वास्तविक महत्वपूर्ण चीज़ के लिए भरोसा करें, इसे जानबूझकर इन विशिष्ट तनाव परीक्षणों से चलाएँ। अधिकांश लूप जो वास्तविक उपयोग में विफल होते हैं, वे इनमें से किसी एक परीक्षण में तुरंत विफल हो जाते, यदि किसी ने पहले जाँच करने की परवाह की होती।
अनसुलझा कार्य परीक्षण। जानबूझकर निर्माता को एक ऐसा कार्य दें जिसे वह निर्णायक के मानक पर पूरा नहीं कर सकता, जानबूझकर। क्या प्रबंधक सही ढंग से पुनरावृत्ति सीमा को हिट करता है और मानव को एस्केलेट करता है, या क्या वह अनिश्चित काल तक घूमता रहता है, एक ऐसे कार्य पर लागत जलाता है जो कभी सफल होने वाला नहीं था?
आत्मविश्वासपूर्ण गलत परीक्षण। निर्णायक को एक ऐसा आउटपुट खिलाएँ जिसे आप पहले से जानते हैं कि सूक्ष्म रूप से गलत है, कुछ ऐसा जो अच्छी तरह से पढ़ता है लेकिन इसमें एक विशिष्ट तथ्यात्मक या तार्किक त्रुटि है। क्या निर्णायक, अपने ग्राउंड ट्रुथ संदर्भ के साथ, इसे सही ढंग से पकड़ता है? यदि निर्णायक कुछ ऐसा पास करता है जिसे आप जानते हैं कि टूटा हुआ है, तो आपका ग्राउंड ट्रुथ संदर्भ वास्तव में जाँचा नहीं जा रहा है, या जाँच बहुत उथली है।
समान-मॉडल अंध स्थान परीक्षण। यदि आपका निर्माता और निर्णायक एक ही अंतर्निहित मॉडल पर चलते हैं, तो यह सीधे जाँचने लायक है। निर्णायक को एक ऐसा आउटपुट खिलाएँ जिसमें उस प्रकार की गलती हो जो वह मॉडल विशेष रूप से करता है। यदि निर्णायक इसे हाथ से जाने देता है, तो आपने एक ऐसा लूप बनाया है जो भूमिकाओं के बीच अपने अंधे धब्बे साझा करता है, जो उन्हें अलग करने के पूरे उद्देश्य को विफल कर देता है। निर्णायक भूमिका के लिए एक वास्तविक रूप से भिन्न मॉडल, या कम से कम एक सार्थक रूप से भिन्न प्रॉम्प्ट फ्रेमिंग का उपयोग करने पर विचार करें।
लागत भगोड़ा परीक्षण। अपनी प्रणाली के माध्यम से सबसे खराब स्थिति वाले पथ की गणना करें: अधिकतम पुनरीक्षण, सबसे महंगे मॉडल कॉल शामिल, सबसे लंबी उचित सामग्री लंबाई, और पता लगाएँ कि वास्तविक डॉलर और वास्तविक समय में इसकी वास्तविक लागत क्या है। यदि वह संख्या आपको वास्तविक चालान पर दिखाई देने पर चिंतित करेगी, तो आपकी रोक शर्तें अभी तक पर्याप्त कड़ी नहीं हैं।
एक स्व-सुधारात्मक लूप को किसी वास्तविक चीज़ के साथ भरोसा करने से पहले इन चार परीक्षणों को चलाने से विफलताओं का भारी बहुमत पकड़ा जाता है जो अन्यथा पहली बार किसी ग्राहक, बॉस, या आपके स्वयं के बैंक स्टेटमेंट के सामने दिखाई देते।
सामान्य गलतियाँ जो चुपचाप एक अन्यथा अच्छे डिज़ाइन को तोड़ देती हैं
सही तीन-भूमिका आर्किटेक्चर के बावजूद, कुछ विशिष्ट कार्यान्वयन गलतियाँ पूरी तरह से अलग-अलग डोमेन में बार-बार दिखाई देती हैं, और उन्हें पहले से जानना आपको प्रत्येक को कठिन तरीके से फिर से खोजने से बचाता है।
निर्णायक को केवल निर्माता का आउटपुट देखने देना, बिना किसी स्वतंत्र संदर्भ के। यह सबसे आम गलती है, और यह चुपचाप आपकी प्रणाली को शुद्धता की जाँच से सुसंगति की जाँच में बदल देती है। एक निर्णायक जिसके पास तुलना करने के लिए कुछ नहीं है, वह केवल आपको बता सकता है कि आउटपुट आंतरिक रूप से सुसंगत दिखता है, कभी नहीं कि क्या वह वास्तव में सही है।
हर भूमिका को एक ही मॉडल देना जिसमें केवल एक पतला निर्देश अंतर लगाया गया हो। यदि निर्णायक निर्माता के समान अंतर्निहित मॉडल चला रहा है, बस एक अलग प्रॉम्प्ट के साथ जो उसे "आलोचनात्मक होने" के लिए कहता है, तो यह अक्सर निर्माता के समान अंधे धब्बे प्राप्त करता है, क्योंकि यह मूल रूप से एक ही तर्क प्रक्रिया है जो एक अलग टोपी पहन रही है। जहाँ बजट अनुमति देता है, निर्णायक भूमिका के लिए एक वास्तविक रूप से भिन्न मॉडल वास्तविक स्वतंत्रता उत्पन्न करता है, न कि नाटकीय स्वतंत्रता।
प्रबंधक को एक साधारण पास-थ्रू के रूप में मानना, बजाय इसके कि उसे पिछले प्रयासों की वास्तविक स्मृति दी जाए। एक प्रबंधक जिसके पास इस विशिष्ट कार्य पर पहले से क्या प्रयास किया गया था, इसकी कोई दृश्यता नहीं है, वह खुशी-खुशी उसी असफल फीडबैक को निर्माता को दूसरी और तीसरी बार वापस भेजेगा, हर बार समान असफल परिणाम उत्पन्न करेगा, क्योंकि सिस्टम में कुछ भी याद नहीं है कि यह सटीक दृष्टिकोण पहले ही एक बार विफल हो चुका है।
चार तनाव परीक्षणों को छोड़ना क्योंकि सिस्टम ने एक डेमो रन में ठीक काम किया जिसे सभी ने ध्यान से देखा। एक सिस्टम जो सही व्यवहार करता है जब आप उसे ध्यान से देख रहे होते हैं और एक सिस्टम जो बिना निगरानी के चलते हुए सही व्यवहार करता है, अलग-अलग दावे हैं। केवल दूसरा वाला ही पहली जगह में एक स्व-सुधारात्मक लूप बनाने का वास्तविक बिंदु है। यदि आपने विफलता मोड का जानबूझकर परीक्षण नहीं किया है, तो आप वास्तव में नहीं जानते कि इनमें से कौन सा दावा आपकी प्रणाली के बारे में सच है।
रोक शर्त को कठोर तर्क के बजाय एक नरम निर्देश के रूप में लिखना। एक प्रॉम्प्ट के अंदर "जब यह काफी अच्छा हो तो रुकें" एक रोक शर्त नहीं है, यह एक सुझाव है जिसे मॉडल सही दबाव में खुद से बाहर निकाल सकता है और अंततः करेगा। एक कठोर पुनरावृत्ति काउंटर जिसे प्रबंधक दूसरे चक्र की अनुमति देने से पहले यांत्रिक रूप से जाँचता है, एक रोक शर्त है। इन दोनों के बीच का अंतर पहली बार जब कोई कार्य वास्तव में अनसुलझा हो जाता है, तो बहुत मायने रखता है।
दूसरा काम का उदाहरण: स्व-सुधारात्मक कोड
वही कंकाल अलग दिखता है लेकिन समान तर्क का पालन करता है जब कार्य सामग्री के बजाय कोड होता है, और दोनों को साथ-साथ देखने से यह स्पष्ट होता है कि डोमेन के बीच वास्तव में कितना कम बदलता है।
यहाँ निर्माता एक कोडिंग एजेंट है जो एक परिभाषित कार्य पर काम कर रहा है: एक बग फिक्स, एक फीचर, एक रिफैक्टर। इसका संरचित आउटपुट केवल कोड डिफ़ नहीं है, बल्कि इसे चलाने के प्रयास से वास्तविक कमांड आउटपुट, परीक्षण परिणाम, लिंट आउटपुट, बिल्ड स्थिति, हैंडऑफ़ में बंडल किया गया है। एक निर्माता जो कोड उत्पन्न करता है लेकिन उसे कभी निष्पादित नहीं करता, वह वास्तव में निर्माता भूमिका को सही ढंग से नहीं भर रहा है, क्योंकि सिंटैक्टिक रूप से प्रशंसनीय कोड जो अपने स्वयं के परीक्षण सूट में विफल होता है, वह बिल्कुल कोड न होने से भी बदतर है, क्योंकि यह समाप्त हुए बिना समाप्त दिखता है।
निर्णायक तीन विशिष्ट, सत्यापन योग्य चीज़ों की जाँच करता है। क्या परिवर्तन ने मौजूदा परीक्षण सूट को पास किया, बिना परीक्षणों को स्वयं संशोधित किए, क्योंकि निर्माता द्वारा चुपचाप एक परीक्षण को पास करने के लिए संपादित करना एक विशिष्ट और आश्चर्यजनक रूप से सामान्य विफलता है जिसकी सीधे जाँच करना उचित है। क्या स्थैतिक विश्लेषण और लिंटिंग साफ आया? क्या डिफ़ वास्तव में उस कार्य को संबोधित करता है जो सौंपा गया था, न कि एक संबंधित लेकिन अलग समस्या जिसे निर्माता ने रास्ते में हल करने के लिए अधिक दिलचस्प पाया? इनमें से प्रत्येक को संरचित फैसले में अपना स्वयं का स्पष्ट पास या फेल मिलता है।
प्रबंधक इस आधार पर रूट करता है कि कौन सी विशिष्ट जाँच विफल हुई। एक असफल परीक्षण सूट सटीक असफल परीक्षण आउटपुट के साथ निर्माता को वापस जाता है, न कि "परीक्षण ठीक करें" जैसा सामान्य निर्देश। एक दायरा बेमेल, जहाँ डिफ़ ने सौंपे गए कार्य के बजाय एक अलग समस्या हल की, तुरंत एक मानव को एस्केलेट करता है, लूप करने के बजाय, क्योंकि यह इस बारे में एक निर्णय विफलता है कि कार्य वास्तव में क्या था, न कि एक यांत्रिक दोष जिसे निर्माता अपने आप दोहरा सकता है।
ध्यान दें कि यहाँ अंतर्निहित कंकाल: निर्माता साक्ष्य के साथ उत्पादन और सबमिट करता है, निर्णायक प्रति-जाँच फैसले के साथ विशिष्ट नामित मानदंडों के विरुद्ध जाँच करता है, प्रबंधक इस आधार पर रूट करता है कि वास्तव में कौन सी जाँच विफल हुई, ऊपर दिए गए सामग्री उत्पादन उदाहरण के समान है। यह वास्तविक सबक है जो दो अलग-अलग डोमेन को एक साथ देखने से आगे ले जाने योग्य है। एक बार जब आपके पास कंकाल सही हो जाता है, तो इसे एक नए प्रकार के कार्य पर लागू करना ज्यादातर निर्णायक के लिए एक नई, विशिष्ट चेकलिस्ट लिखने का मामला है, न कि हर बार शुरुआती सिद्धांतों से पूरे आर्किटेक्चर को फिर से डिज़ाइन करना।
एक साथ कई लूप को स्केल करना
एक बार जब एक एकल स्व-सुधारात्मक लूप वास्तव में विश्वसनीय हो जाता है, तो अगला वास्तविक प्रश्न यह है कि एक साथ कई कैसे चलाएँ बिना सिस्टम के अप्रबंधनीय हुए, क्योंकि यह ठीक वही जगह है जहाँ अधिकांश लोगों का इसे स्केल करने का दूसरा प्रयास गलत हो जाता है।
लालच यह है कि जैसे ही पहला काम करता है, एक साथ कई लूप चालू कर दें, पाँच अलग-अलग कार्यों को समानांतर में निपटाएँ क्योंकि आर्किटेक्चर तकनीकी रूप से इसका समर्थन करता है। आवश्यकता से अधिक समय तक इसका विरोध करें। प्रत्येक अतिरिक्त समवर्ती लूप एक और जगह है जहाँ एक रोक शर्त चुपचाप विफल हो सकती है, एक और जगह जहाँ लागत बिना ध्यान दिए भाग सकती है, एक और जगह जहाँ निर्णायक का ग्राउंड ट्रुथ संदर्भ सूक्ष्म रूप से गलत हो सकता है जो केवल वास्तविक मात्रा के तहत दिखाई देता है, न कि एकल परीक्षण रन में।
सुरक्षित स्केलिंग पथ प्रत्येक चरण पर एक वास्तविक विश्वास सीमा के साथ अनुक्रमिक विस्तार है। एक लूप को इतना विश्वसनीय रूप से चलाने के लिए प्राप्त करें कि आपने इसके आउटपुट की बारीकी से जाँच करना बंद कर दिया है, जिसका अर्थ है कि यह वास्तविक समय की अवधि में लगातार आपकी अपनी मैन्युअल स्पॉट-चेक पास करता है, न कि केवल एक सफल डेमो रन। तभी एक अलग कार्य के लिए दूसरा लूप जोड़ें। समय के साथ प्रत्येक लूप की वास्तविक विफलता दर को ट्रैक करें, न कि केवल यह कि क्या वह उन रनों पर काम करता दिखाई दिया जिन्हें आपने देखा।
जब आप एक साथ कई लूप चलाते हैं, तो सभी लूपों में एक साझा लागत डैशबोर्ड पर गंभीरता से विचार करें, न कि अलग-अलग प्रति-लूप ट्रैकिंग। एक उचित प्रति-कार्य बजट वाला एक एकल लूप अलगाव में पूरी तरह से ठीक दिखता है। दस लूप प्रत्येक व्यक्तिगत रूप से बजट के भीतर अभी भी एक वास्तविक रूप से चिंताजनक कुल में जुड़ सकते हैं जिसे कोई तब तक नोटिस नहीं करता जब तक कुल बिल नहीं आता, ठीक इसलिए क्योंकि प्रत्येक व्यक्तिगत लूप की ट्रैकिंग अपने आप में ठीक दिखती थी।
एक आदत जो स्केलिंग समस्याओं को शुरू होने से पहले रोकती है: हर लूप में हर रोक शर्त ट्रिगर को लॉग करें, न कि केवल सफल समापन। एक लूप जो अपनी अधिकतम पुनरावृत्ति सीमा को हिट करता है और मानव को एस्केलेट करता है, वह बिल्कुल वही कर रहा है जो उसे करना चाहिए, लेकिन यदि एक विशिष्ट लूप लगातार उस सीमा को हिट कर रहा है जबकि अन्य शायद ही कभी करते हैं, तो यह एक संकेत है कि उस विशेष कार्य के लिए निर्णायक का मानक या तो गलत अंशांकित है, वास्तव में कभी पास होने के लिए बहुत सख्त है, या पूरी तरह से गलत ग्राउंड ट्रुथ के विरुद्ध जाँच कर रहा है। वह पैटर्न अदृश्य है यदि आप केवल सफलताओं को ट्रैक कर रहे हैं और हर एस्केलेशन को एक अलग, अविशिष्ट घटना के रूप में मान रहे हैं, न कि उस विशिष्ट लूप के डिज़ाइन के बारे में एक डेटा बिंदु।
इस सप्ताह कहाँ से शुरू करें
अपने पहले प्रयास में पूरी तरह से सामान्य स्व-सुधारात्मक प्रणाली बनाने का प्रयास न करें। एक विशिष्ट, संकीर्ण, अच्छी तरह से परिभाषित कार्य चुनें जो आप पहले से नियमित रूप से करते हैं, कुछ ऐसा जिसमें एक स्पष्ट मानक हो जिसे आप पूछे जाने पर लिख सकते हैं, और पहले उस एकल कार्य के आसपास तीन-भूमिका लूप बनाएँ।
निर्माता के प्रॉम्प्ट की एक भी पंक्ति लिखने से पहले निर्णायक की चेकलिस्ट को स्पष्ट रूप से लिखें। जिस मानक के विरुद्ध आप जाँच कर रहे हैं, उसे आकार देना चाहिए कि आप निर्माता से क्या उत्पादन करने के लिए कहते हैं, न कि इसके विपरीत। यदि आप अभी तक चेकलिस्ट नहीं लिख सकते, तो आप अभी तक यह नहीं जानते कि इस कार्य के लिए "सही" का क्या अर्थ है, जाँच को स्वचालित करने के लिए पर्याप्त रूप से, और यह कुछ भी बनाने से पहले खोजने लायक है।
लूप को किसी भी वास्तविक महत्वपूर्ण चीज़ के साथ भरोसा करने से पहले ऊपर दिए गए चार तनाव परीक्षण चलाएँ, न कि किसी के सामने कुछ गलत होने के बाद। पहले संस्करण से ही रोक शर्त को वास्तविक, कठोर तर्क के रूप में जोड़ें, न कि एक बार जब आप पहले ही एक भगोड़ा लूप से जल चुके हों, तो एक बाद का विचार।
एक बार जब एक लूप वास्तव में विश्वसनीय है, बिना निगरानी के चल रहा है, वास्तविक गलतियों को पकड़ रहा है, जब चाहिए तब साफ-सुथरा रुक रहा है, तो दूसरा बहुत तेजी से जाता है। इसलिए नहीं कि प्रॉम्प्ट सीधे स्थानांतरित होते हैं, उन्हें आमतौर पर नए कार्य के लिए फिर से लिखने की आवश्यकता होती है, बल्कि इसलिए कि आप पहले से ही समस्या के वास्तविक आकार को समझते हैं। निर्माण को निर्णय से अलग करें। निर्णय को जाँचने के लिए कुछ वास्तविक दें। रोक शर्त को तर्क के रूप में लिखें, आशा के रूप में नहीं।
वह आकार पूरी अनुशासन है। बाकी सब कुछ बस इसे आपके सामने वाले कार्य पर लागू करना है।
इस लेख में हर चीज़ के पीछे सटीक लूप टेम्पलेट्स और Builder-Judge-Manager सेटअप के लिए @cyrilXBT को फ़ॉलो करें।
