आपके verifier में छिपा हुआ बग
ऊपर दिया गया लूप कोड के क्रैश हुए बिना चलते ही जीत का ऐलान कर देता है। कोड का चलना और सही होना एक जैसी बात नहीं है, और इसी अंतर की वजह से self-improving सिस्टम्स में गड़बड़ियाँ होती हैं।
60 सेकंड में
आपके verifier में छिपा हुआ बग
ऊपर दिया गया लूप कोड के क्रैश हुए बिना चलते ही जीत का ऐलान कर देता है। कोड का चलना और सही होना एक जैसी बात नहीं है, और इसी अंतर की वजह से self-improving सिस्टम्स में गड़बड़ियाँ…
if "SUCCESS OUTPUT" in execution_result:
print("[AGI Status]: goal reached and verified via execution.")
returnSUCCESS OUTPUT का सिर्फ़ एक ही मतलब है: प्रोसेस code 0 के साथ एग्ज़िट हुआ। इसका यह मतलब बिल्कुल नहीं है कि लक्ष्य पूरा हो गया। सोचिए कि इस शर्त को कौन-कौन सी चीज़ें पूरा कर देती हैं:| मॉडल क्या लिखता है | 0 के साथ एग्ज़िट होता है? | लक्ष्य पूरा हुआ? |
|---|---|---|
| सही Fibonacci वेरिफिकेशन | हाँ | हाँ |
print("VERIFICATION PASSED") और कुछ भी नहीं | हाँ | नहीं |
| सही कोड, जिसमें assertion को कमेंट आउट कर दिया गया हो | हाँ | नहीं |
| ऐसी स्क्रिप्ट जो कुछ भी प्रिंट नहीं करती | हाँ | नहीं |
| सही कोड, जो असली गड़बड़ी होने पर एरर देता है | नहीं | यह सही से काम कर रहा था |
इसे ठीक करना: एग्ज़िट कोड नहीं, लक्ष्य की जाँच करें
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),
]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, historygoal_checks की तीन खासियतों पर गौर करें और इन तीनों को अपनाएँ: इसे किसी इंसान ने लिखा है, एजेंट इसे कभी नहीं देखता, और यह प्रोसेस के बजाय आउटपुट की जाँच करता है। Module 57 इसे साफ़ शब्दों में कहता है — किसी भी self-improving लूप में, verifier जिस चीज़ को मापता है, सिस्टम उसी को ऑप्टिमाइज़ करता है। जिस verifier को एजेंट पढ़ सकता है, उसे वह बिना असली काम किए भी संतुष्ट कर सकता है।आम नियम
- 1
"यह चल गया" को कभी भी "यह सही काम कर रहा है" न मानें
Exit code 0 सबसे कमज़ोर सिग्नल होता है। इसका बस इतना ही मतलब है कि interpreter को कोई दिक़्क़त नहीं हुई, और कुछ नहीं। - 2
एजेंट के चलने से पहले ही acceptance criteria लिखें
अगर आप कोड में पहले से यह नहीं बता सकते कि कामयाबी कैसी दिखेगी, तो आपके पास कोई जाँचे जाने लायक लक्ष्य नहीं है — बस एक ख़्वाहिश है। - 3
जाँच (checks) को एजेंट के context से बाहर रखें
जिस पल मॉडल टेस्ट को पढ़ लेता है, उस पल टेस्ट यह मापने लगता है कि मॉडल टेस्ट को कितनी अच्छी तरह पढ़ सकता है। - 4
रिजेक्शन की वजह वापस भेजें
अगले प्रयास के लिए सिर्फ़ "failed" बोलने से कहीं ज़्यादा मददगार यह बताना है कि "चल तो गया, लेकिन वेरिफिकेशन वाली लाइन प्रिंट नहीं की"। - 5
हर रिजेक्शन को लॉग करें
रिजेक्शन इस बात का सबसे अच्छा संकेत होते हैं कि लक्ष्य साफ़ नहीं था, न कि यह कि मॉडल ख़राब था।
और देखें और पढ़ें
लैब
लक्ष्य की जाँच करने वाला एक ऐसा verifier जिसे एजेंट पढ़ नहीं सकता।
समस्या
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),
]आपका काम तब पूरा होगा जब
कठिन सवाल
उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।
Q1आपकी तीसरी जाँच हार्ड-कोड किए गए जवाब को पकड़ने के लिए अंकों को गिनती है। इसे चकमा दें, और फिर ऐसी जाँच लिखें जिसे इस तरह चकमा न दिया जा सके।दिखाएं
अक्सर पूछे जाने वाले सवाल
क्या checks लिखना भी कोड लिखने जितना ही बड़ा काम नहीं है?
अक्सर यह उससे कम काम होता है, और यह हमेशा ज़्यादा टिकाऊ होता है। "आउटपुट में ये दस नंबर मौजूद हैं" यह सिर्फ़ एक लाइन है; जबकि इन्हें सही ढंग से तैयार करने वाला प्रोग्राम कई लाइनों का होता है। और कोड बदलने के बाद भी यह जाँच काम करती रहती है।
क्या एजेंट अपनी जाँच (checks) खुद लिख सकता है?
वह उन्हें ड्राफ़्ट कर सकता है, लेकिन किसी इंसान को उन्हें मंज़ूरी देनी होगी। जो एजेंट कोड भी खुद लिखे और उसे परखने वाला टेस्ट भी, वह अपना होमवर्क खुद ही चेक करने जैसा है — यही तो वह लूप है जिससे बचने की चेतावनी Module 57 देता है।
अगर लक्ष्य subjective (व्यक्तिपरक) हो तब क्या करें?
तब आपको वापस किसी इंसान से जाँच करवानी होगी, और आपको ईमानदारी से इसे ऐसे ही बनाना चाहिए: एजेंट ड्राफ़्ट तैयार करे और इंसान उसे मंज़ूर करे। इस पर किसी LLM जज का पर्दा डालकर इसे वेरिफिकेशन न कहें।
मैं checks को मॉडल के context से बाहर कैसे रखूँ?
उन्हें orchestrator में चलाएँ, मॉडल कॉल वापस आने के बाद। मॉडल को लक्ष्य और फ़ेल होने की वजहें दिखती हैं; वह predicate के सोर्स कोड को कभी नहीं देखता।
पाठ का टेस्ट
5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।