AGI की ओरएडवांस्डपाठ 576 मिनट का पाठ

वे सिस्टम जो खुद में सुधार करते हैं

लूप पूरा कीजिए और सिस्टम अपने आप बेहतर होने लगता है। यह इस गाइड का सबसे रोमांचक आर्किटेक्चर है और इसी पर ब्रेक लगाने के लिए सबसे ज़्यादा ध्यान देने की ज़रूरत है।

✦ ट्यूटर से पूछें🧪 लैब · 25 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

वे सिस्टम जो खुद में सुधार करते हैं

लूप पूरा कीजिए और सिस्टम अपने आप बेहतर होने लगता है। यह इस गाइड का सबसे रोमांचक आर्किटेक्चर है और इसी पर ब्रेक लगाने के लिए सबसे ज़्यादा ध्यान देने की ज़रूरत है।

1/6
आसान शब्दों में
एक ऐसे छात्र की कल्पना कीजिए जो अपने होमवर्क की खुद चेकिंग करता है, और फिर अपने नंबरों के आधार पर टेक्स्टबुक को दोबारा लिखता है। अगर उसकी चेकिंग अच्छी है, तो वह बहुत जल्दी बहुत अच्छा बन जाता है। अगर उसकी चेकिंग गलत है, तो वह पूरे आत्मविश्वास के साथ और खराब होता जाता है और उसे कभी पता भी नहीं चलता।
Self-improvement का मतलब है कि सिस्टम का आउटपुट ही उसका अपना ट्रेनिंग सिग्नल बन जाता है। इसके चार पायदान हैं, और वे ताकत और जोखिम दोनों के मामले में एक-दूसरे से बहुत अलग हैं।
  1. 1

    पायदान 1 · एक रन के भीतर self-correction

    ड्राफ्ट बनाना, समीक्षा करना, सुधारना। कोई स्थायी बदलाव नहीं; सेशन खत्म होने के साथ ही यह सुधार भी खत्म हो जाता है। सुरक्षित है, और आज के समय में काम का भी।
  2. 2

    पायदान 2 · जाँचे-परखे नतीजों से सीखना

    जो चीज़ साबित तौर पर काम कर गई — पास हुए टेस्ट, सही जवाब — उसे रखें और उस पर ट्रेन करें। यह Module 51 है, और verifier ही वह चीज़ है जो इसे ईमानदार बनाए रखती है।
  3. 3

    पायदान 3 · अपनी खुद की scaffolding को बेहतर बनाना

    सिस्टम अपने prompts, अपने टूल विवरण, अपनी retrieval स्ट्रेटेजी या अपने खुद के वर्कफ़्लो को फिर से लिखता है। असली फायदे मिलते हैं, और अब यह उस चीज़ को बदल रहा है जिसका आपने ऑडिट किया था।
  4. 4

    पायदान 4 · मॉडल को खुद बेहतर बनाना

    ट्रेनिंग डेटा तैयार करना, अपनी खुद की fine-tuning चलाना, नतीजों का मूल्यांकन करना। किसी बड़े पैमाने पर यह काफ़ी हद तक काल्पनिक है — और यह वही परिदृश्य है जिसके बारे में Module 33 है।

वह एक बात जिससे तय होता है कि यह काम करेगा या नहीं

सब कुछ verifier पर टिका है। Self-improvement एक फीडबैक लूप है, और गलत माप वाला फीडबैक लूप उस खामी को और बढ़ा देता है।
The loop, with the failure written into itpython
def self_improve(system, tasks, rounds=10):
    for r in range(rounds):
        results = [system.attempt(t) for t in tasks]

        # EVERYTHING depends on this line being honest
        good = [x for x in results if verify(x)]

        system.train_on(good)
        score = evaluate(system, held_out_tasks)
        print(f"round {r}  kept {len(good)}/{len(results)}  score {score:.3f}")

        # If verify() can be satisfied without solving the task, this loop
        # optimises for satisfying verify() -- efficiently, and forever.
        # It will look like rapid improvement on your dashboard.
ख़तरा
यह Module 32 ही है, बस कई गुना बढ़कर। Self-improvement लूप के अंदर specification gaming सिर्फ एक गलत जवाब ही नहीं देती — यह गलत व्यवहार को ट्रेनिंग में पक्का कर देती है, और फिर उसी सुधरे हुए गलत व्यवहार का इस्तेमाल करके और ज़्यादा ट्रेनिंग डेटा बनाती है। इस पूरे समय डैशबोर्ड एक शानदार कर्व दिखाता रहता है।

नाकामी के तीन मुख्य तरीके

नाकामीक्या होता हैचेतावनी का संकेत
Verifier hackingयह काम को नहीं, बल्कि चेकर को ऑप्टिमाइज़ करता हैस्कोर तो बढ़ते हैं, लेकिन रैंडम चेक करने पर असली क्वालिटी नहीं बढ़ती
Model collapseअपने ही आउटपुट पर ट्रेन करने से विविधता कम हो जाती हैआउटपुट की स्टाइल एक जैसी होने लगती है; दुर्लभ मामले और खराब हो जाते हैं
मकसद से भटकनाहर राउंड के साथ छोटे-छोटे स्वीकार्य बदलाव मिलकर बड़े हो जाते हैंराउंड 10 का व्यवहार राउंड 1 पर मंज़ूर नहीं किया गया होता
Scaffolding erosionयह अपनी ही पाबंदियों को "अक्षमता" मानकर हटा देता हैPrompt या टूल कॉन्फ़िगरेशन उससे अलग होता है जिसे आपने रिव्यू किया था

इसे सुरक्षित तरीके से कैसे चलाएं

  • एक ऐसा verifier अलग रखें जिसे सिस्टम कभी न देख सके। अगर वह चेकर को देख सकता है, तो वह चेकर के हिसाब से ही खुद को ऑप्टिमाइज़ कर लेगा।
  • राउंड ज़ीरो से इंसानों द्वारा जाँचा गया एक निश्चित सैंपल रखें और हर राउंड में उसे फिर से स्कोर करें। उसके और आपके ऑटोमैटिक मीट्रिक के बीच का अंतर ही आपकी खतरे की घंटी है।
  • भटकाव पर रोक लगाएं। राउंड N की तुलना सीधे राउंड 0 से करें, न कि सिर्फ राउंड N−1 से। छोटे-छोटे स्वीकार्य कदम मिलकर बड़े अस्वीकार्य बदलाव बन जाते हैं।
  • Scaffolding का वर्ज़न बनाएं और उसे फ़्रीज़ करें। अगर सिस्टम अपने खुद के prompts या टूल्स में बदलाव का सुझाव दे सकता है, तो उन सुझावों को किसी भी दूसरे कोड बदलाव की तरह रिव्यू से गुज़रना चाहिए।
  • विविधता के मीट्रिक्स बनाए रखें। आउटपुट की entropy पर नज़र रखें; कोई बड़ा नुकसान होने से पहले ही collapse दिखाई दे जाता है।
  • इसे कभी भी अपनी परमिशन को छूने न दें। न इसके क्रेडेंशियल्स, न इसकी टूल लिस्ट, और न ही इसके अप्रूवल थ्रेशोल्ड। यह एक सख्त लक्ष्मण रेखा है, कोई लचीला नियम नहीं।
  • स्टॉप बटन बाहर होना चाहिए। इंफ्रास्ट्रक्चर के स्तर पर, ऐसा टूल नहीं जो सिस्टम के पास हो — Module 33।
यह करें
पायदान 1 और पायदान 2 वास्तव में उपयोगी हैं और अभी उपलब्ध हैं, और जब verifier निष्पक्ष और बाहरी हो तो दोनों सुरक्षित हैं। पायदान 3 के लिए रिव्यू गेट्स की ज़रूरत होती है। पायदान 4 को किसी को भी यूँ ही नहीं चलाना चाहिए। यह कोई बढ़ा-चढ़ाकर कही गई बात नहीं है — यह वही तर्क है जो आपको किसी डिप्लॉय पाइपलाइन को उसके अपने ही अप्रूवल नियमों को बदलने का अधिकार देने से रोकता है।

और देखें और पढ़ें

Self-improving AI systemsYouTube searchModel collapse from synthetic dataYouTube search

लैब

एक ऐसा self-improvement लूप जो जानबूझकर मापने योग्य तरीके से और खराब होता जाता है।

~25 min

समस्या

Module 57 से लूप को एक जानबूझकर आसानी से चकमा खा जाने वाले verifier के साथ बनाएं। दस राउंड चलाएं। Verifier के स्कोर और अलग से रखे गए इंसानी स्कोर को एक ही अक्ष पर प्लॉट करें। देखें कि वे कैसे एक-दूसरे से अलग होते जाते हैं।
शुरुआती कोडpython
for r in range(10):
    results = [system.attempt(t) for t in tasks]
    good = [x for x in results if verify(x)]        # gameable
    system.train_on(good)
    print(f"round {r}  verifier {score(verify)}  held-out {human_score()}")
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1आपका डैशबोर्ड दस राउंड तक एक शानदार कर्व दिखाता है। उन तीन पैमानों के नाम बताइए जो आपको सच बता सकते थे।दिखाएं
पहला: राउंड ज़ीरो से इंसानों द्वारा जाँचा गया एक तय सैंपल, जिसे हर राउंड में फिर से स्कोर किया जाए — ऑटोमैटिक मीट्रिक से इसका भटकना ही खतरे की घंटी है। दूसरा: आउटपुट की विविधता या entropy, जो सिस्टम द्वारा किसी एक ट्रिक पर सिमटते ही खत्म हो जाती है। तीसरा: एक अलग रखा गया verifier जिसके हिसाब से सिस्टम को कभी ऑप्टिमाइज़ नहीं किया गया, जो कि अकेला ऐसा माप है जो उस लूप के अंदर नहीं है जिसे सिस्टम चकमा दे रहा है।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या recursive self-improvement सचमुच संभव है?

पायदान 1 और 2 आज प्रोडक्शन में इस्तेमाल हो रहे हैं। पायदान 3 रिसर्च सिस्टम में मौजूद है। किसी बड़े पैमाने पर पायदान 4 काल्पनिक है — इसके लिए एक ऐसे मॉडल की ज़रूरत है जो अपने जितने ही सक्षम मॉडल की ट्रेनिंग में सार्थक सुधार कर सके, जो कि अभी तक किसी ने नहीं दिखाया है।

क्या model collapse सचमुच एक समस्या है?

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

क्या मैं इसे किसी सामान्य प्रोडक्ट में इस्तेमाल कर सकता हूँ?

हाँ, पायदान 1 और 2 पर। एजेंट से कहें कि वह असली चेक्स के ज़रिए अपने काम की पुष्टि करे, जो पास हो जाए उसे रखे, और उसका इस्तेमाल prompts और उदाहरणों को बेहतर बनाने के लिए करे। यह एक स्पष्ट ऑडिट ट्रेल के साथ सामान्य, उपयोगी इंजीनियरिंग है।

अपनी खुद की परमिशन में बदलाव न करने देना एक सख्त लक्ष्मण रेखा क्यों है?

क्योंकि इस गाइड का हर दूसरा कंट्रोल यह मानकर चलता है कि परमिशन सेट आपके द्वारा तय किया गया है। एक ऐसा सिस्टम जो अपनी परमिशन खुद बढ़ा सकता है, वह समझदारी भरे लगने वाले छोटे-छोटे कदमों से आपके बनाए हर सुरक्षा कवच को तोड़ सकता है।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें