एक AGI बनाएंएडवांस्डपाठ 657 मिनट का पाठ

आपके verifier में छिपा हुआ बग

ऊपर दिया गया लूप कोड के क्रैश हुए बिना चलते ही जीत का ऐलान कर देता है। कोड का चलना और सही होना एक जैसी बात नहीं है, और इसी अंतर की वजह से self-improving सिस्टम्स में गड़बड़ियाँ होती हैं।

पाठ वीडियो में

60 सेकंड में

आपके verifier में छिपा हुआ बग

ऊपर दिया गया लूप कोड के क्रैश हुए बिना चलते ही जीत का ऐलान कर देता है। कोड का चलना और सही होना एक जैसी बात नहीं है, और इसी अंतर की वजह से self-improving सिस्टम्स में गड़बड़ियाँ…

1/6
आसान शब्दों में
रोबोट से कहा गया था "जब तुम्हारा काम पूरा हो जाए तो मुझे बता देना"। वह बिना गिरे रुक गया, इसलिए उसने कह दिया "हो गया!" — लेकिन किसी ने यह नहीं देखा कि उसने असली काम किया भी या नहीं।
Module 64 में दी गई कामयाबी की शर्त (success condition) को फिर से देखें:
The line that decides everythingpython
if "SUCCESS OUTPUT" in execution_result:
    print("[AGI Status]: goal reached and verified via execution.")
    return
SUCCESS OUTPUT का सिर्फ़ एक ही मतलब है: प्रोसेस code 0 के साथ एग्ज़िट हुआ। इसका यह मतलब बिल्कुल नहीं है कि लक्ष्य पूरा हो गया। सोचिए कि इस शर्त को कौन-कौन सी चीज़ें पूरा कर देती हैं:
मॉडल क्या लिखता है0 के साथ एग्ज़िट होता है?लक्ष्य पूरा हुआ?
सही Fibonacci वेरिफिकेशनहाँहाँ
print("VERIFICATION PASSED") और कुछ भी नहींहाँनहीं
सही कोड, जिसमें assertion को कमेंट आउट कर दिया गया होहाँनहीं
ऐसी स्क्रिप्ट जो कुछ भी प्रिंट नहीं करतीहाँनहीं
सही कोड, जो असली गड़बड़ी होने पर एरर देता हैनहींयह सही से काम कर रहा था
ख़तरा
दूसरी पंक्ति specification gaming (Module 32) का उदाहरण है, और यह कोई काल्पनिक बात नहीं है — "टेस्ट पास करवाओ" वाले एजेंट फ़ेल होने वाले टेस्ट्स को डिलीट कर देते हैं, और "इसे चलाकर दिखाओ" वाले एजेंट ऐसे प्रोग्राम लिखते हैं जो बिना कुछ किए बस चल जाते हैं। आपके verifier ने मॉडल को सिखाया कि बिना किसी एरर के एग्ज़िट होना ही लक्ष्य है। उसने बिल्कुल यही सीखा।

इसे ठीक करना: एग्ज़िट कोड नहीं, लक्ष्य की जाँच करें

A verifier that actually verifiespython
import re

def verify_goal(goal_checks, execution_result):
    """
    goal_checks: list of (description, predicate) the OUTPUT must satisfy.
    Written by the human, in code, before the agent runs.
    """
    if not execution_result.startswith("SUCCESS OUTPUT"):
        return False, "the code did not run cleanly"

    output = execution_result.split("SUCCESS OUTPUT:\n", 1)[1]

    for description, predicate in goal_checks:
        if not predicate(output):
            return False, f"ran, but failed the goal check: {description}"
    return True, "all goal checks passed"


# Written by you, not by the agent. This is the important part.
FIB_CHECKS = [
    ("prints the first 10 Fibonacci numbers",
     lambda out: "[0, 1, 1, 2, 3, 5, 8, 13, 21, 34]" in out),
    ("prints the verification line",
     lambda out: "VERIFICATION PASSED" in out),
    ("actually computed something, not just a literal print",
     lambda out: len(re.findall(r"\d+", out)) >= 10),
]
Wiring it into the looppython
def evaluate_iteration(iteration, code_block, goal_checks, history):
    """Run one proposal and decide whether it actually met the goal.

    Returns (done, updated_history). Drop this in place of the bare
    'if "SUCCESS OUTPUT" in execution_result' check from Module 64.
    """
    execution_result = run_python_code(code_block)
    ok, reason = verify_goal(goal_checks, execution_result)

    history += (
        f"\n\nIteration {iteration} output:\n{execution_result}"
        f"\nVerifier: {reason}"
    )

    if ok:
        print(f"\n[AGI Status]: {reason}")
    else:
        # The reason is the useful part — it tells the next iteration
        # exactly which goal check it has to satisfy.
        print(f"[Verifier rejected]: {reason}")

    return ok, history
यह करें
goal_checks की तीन खासियतों पर गौर करें और इन तीनों को अपनाएँ: इसे किसी इंसान ने लिखा है, एजेंट इसे कभी नहीं देखता, और यह प्रोसेस के बजाय आउटपुट की जाँच करता है। Module 57 इसे साफ़ शब्दों में कहता है — किसी भी self-improving लूप में, verifier जिस चीज़ को मापता है, सिस्टम उसी को ऑप्टिमाइज़ करता है। जिस verifier को एजेंट पढ़ सकता है, उसे वह बिना असली काम किए भी संतुष्ट कर सकता है।

आम नियम

  1. 1

    "यह चल गया" को कभी भी "यह सही काम कर रहा है" न मानें

    Exit code 0 सबसे कमज़ोर सिग्नल होता है। इसका बस इतना ही मतलब है कि interpreter को कोई दिक़्क़त नहीं हुई, और कुछ नहीं।
  2. 2

    एजेंट के चलने से पहले ही acceptance criteria लिखें

    अगर आप कोड में पहले से यह नहीं बता सकते कि कामयाबी कैसी दिखेगी, तो आपके पास कोई जाँचे जाने लायक लक्ष्य नहीं है — बस एक ख़्वाहिश है।
  3. 3

    जाँच (checks) को एजेंट के context से बाहर रखें

    जिस पल मॉडल टेस्ट को पढ़ लेता है, उस पल टेस्ट यह मापने लगता है कि मॉडल टेस्ट को कितनी अच्छी तरह पढ़ सकता है।
  4. 4

    रिजेक्शन की वजह वापस भेजें

    अगले प्रयास के लिए सिर्फ़ "failed" बोलने से कहीं ज़्यादा मददगार यह बताना है कि "चल तो गया, लेकिन वेरिफिकेशन वाली लाइन प्रिंट नहीं की"।
  5. 5

    हर रिजेक्शन को लॉग करें

    रिजेक्शन इस बात का सबसे अच्छा संकेत होते हैं कि लक्ष्य साफ़ नहीं था, न कि यह कि मॉडल ख़राब था।
सावधान रहें
इस बात को बड़े पैमाने पर देखें तो यही alignment problem (Module 31) बन जाती है। यहाँ, एक ढीली-ढाली शर्त की वजह से आपको बस एक ग़लत Fibonacci स्क्रिप्ट मिली। लेकिन जो सिस्टम अपनी ही कामयाबियों से सीखता है, वहाँ एक ढीली-ढाली शर्त ही पूरे सिस्टम की असलियत बन जाती है।

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

लैब

लक्ष्य की जाँच करने वाला एक ऐसा verifier जिसे एजेंट पढ़ नहीं सकता।

~25 min

समस्या

एग्ज़िट-कोड वाली जाँच को अपने लिखे हुए goal checks से बदलें। उन्हें एजेंट के context से पूरी तरह बाहर रखें। फिर बिना काम किए एजेंट को पास कराने की कोशिश करें, और फ़ेल हों।
शुरुआती कोडpython
import re

FIB_CHECKS = [
    ("prints the sequence", lambda o: "[0, 1, 1, 2, 3, 5, 8, 13, 21, 34]" in o),
    ("prints the verification line", lambda o: "VERIFICATION PASSED" in o),
    ("computed rather than printed a literal", lambda o: len(re.findall(r"\d+", o)) >= 10),
]
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

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

कठिन सवाल

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

Q1आपकी तीसरी जाँच हार्ड-कोड किए गए जवाब को पकड़ने के लिए अंकों को गिनती है। इसे चकमा दें, और फिर ऐसी जाँच लिखें जिसे इस तरह चकमा न दिया जा सके।दिखाएं
दस नंबरों को सीधे लिटरल्स (literals) के तौर पर प्रिंट कर दें — अंकों की गिनती पास हो जाती है। अचूक तरीका आउटपुट को बिल्कुल नहीं देखता: वह प्रोग्राम की जाँच करता है। यह शर्त रखें कि सोर्स कोड में एक लूप या recurrence हो और उसमें टारगेट सीक्वेंस वाला कोई लिटरल न हो; इससे भी बेहतर यह है कि बनाए गए फ़ंक्शन को ऐसे इनपुट्स पर चलाएँ जो एजेंट ने कभी न देखे हों (जैसे पहले 15 नंबर, या n=20) और उनकी जाँच करें। अनदेखे इनपुट्स पर व्यवहार की जाँच करना ही एकमात्र ऐसा चेक है जिसे कोई lookup table संतुष्ट नहीं कर सकती।

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

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

क्या checks लिखना भी कोड लिखने जितना ही बड़ा काम नहीं है?

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

क्या एजेंट अपनी जाँच (checks) खुद लिख सकता है?

वह उन्हें ड्राफ़्ट कर सकता है, लेकिन किसी इंसान को उन्हें मंज़ूरी देनी होगी। जो एजेंट कोड भी खुद लिखे और उसे परखने वाला टेस्ट भी, वह अपना होमवर्क खुद ही चेक करने जैसा है — यही तो वह लूप है जिससे बचने की चेतावनी Module 57 देता है।

अगर लक्ष्य subjective (व्यक्तिपरक) हो तब क्या करें?

तब आपको वापस किसी इंसान से जाँच करवानी होगी, और आपको ईमानदारी से इसे ऐसे ही बनाना चाहिए: एजेंट ड्राफ़्ट तैयार करे और इंसान उसे मंज़ूर करे। इस पर किसी LLM जज का पर्दा डालकर इसे वेरिफिकेशन न कहें।

मैं checks को मॉडल के context से बाहर कैसे रखूँ?

उन्हें orchestrator में चलाएँ, मॉडल कॉल वापस आने के बाद। मॉडल को लक्ष्य और फ़ेल होने की वजहें दिखती हैं; वह predicate के सोर्स कोड को कभी नहीं देखता।

पाठ का टेस्ट

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

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