एक AGI बनाएंमध्यमपाठ 626 मिनट का पाठ

मॉडल प्रस्ताव रखता है, कंपाइलर फैसला करता है

वह एक वाक्य जो एक अविश्वसनीय टेक्स्ट जनरेटर को एक ऐसे सिस्टम में बदल देता है जिस पर आप असली काम के लिए भरोसा कर सकते हैं।

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

60 सेकंड में

मॉडल प्रस्ताव रखता है, कंपाइलर फैसला करता है

वह एक वाक्य जो एक अविश्वसनीय टेक्स्ट जनरेटर को एक ऐसे सिस्टम में बदल देता है जिस पर आप असली काम के लिए भरोसा कर सकते हैं।

1/6
आसान शब्दों में
कोई भी कह सकता है "यह पुल टिकेगा"। केवल टेस्ट ही आपको सच बताता है। इसलिए हमने मशीन से सही होने की उम्मीद करना बंद कर दिया, और उससे इसे साबित करवाना शुरू कर दिया।
यहाँ पूरा LLM पैटर्न एक लाइन में है, और इसे बिल्कुल ऐसे ही याद रखना फायदेमंद है:
मॉडल प्रस्ताव रखता है। कंपाइलर फैसला करता है। लैंग्वेज मॉडल को कुछ भी सुझाने की पूरी छूट है। साधारण, डिटर्मिनिस्टिक कोड यह तय करता है कि वह सुझाव टिकेगा या नहीं।
ध्यान दें कि यह विश्वसनीयता की समस्या के साथ क्या करता है। अब आप किसी प्रॉबेबिलिस्टिक सिस्टम को डिटर्मिनिस्टिक बनाने की कोशिश नहीं कर रहे हैं — जो कि मुमकिन नहीं है। आप इसके आगे (डाउनस्ट्रीम) एक डिटर्मिनिस्टिक सिस्टम लगा रहे हैं, जहाँ यह मुमकिन है।
GoalModel proposesa guessCheckerplain codepassAnswerfail — with the error, so it can fix itthe loop
वापसी का तीर (रिटर्न एरो) ही पूरा डिज़ाइन है। एक असफल चेक कोई बंद रास्ता नहीं है — यह सिस्टम को मिलने वाला सबसे बेहतरीन क्वालिटी का ट्रेनिंग सिग्नल है, जो तुरंत और मुफ़्त में मिलता है।

चेकर किसे माना जाता है

कोई भी डिटर्मिनिस्टिक चीज़ जो किसी प्रस्ताव पर हाँ या ना कह सके। आप इस पर कितना भरोसा कर सकते हैं, उसके अनुसार रैंक किया गया:
चेकरयह क्या साबित करता हैभरोसा
कोड रन करनायह चलता है और यह आउटपुट देता हैपूरी तरह, जहाँ तक कोड कवर करता है
टेस्ट रन करनायह आपके द्वारा तय की गई शर्तों (properties) को पूरा करता हैपूरी तरह, और सिर्फ उतना ही अच्छा जितने आपके टेस्ट हैं
एक टाइप चेकर या स्कीमाढाँचा (shape) सही हैपूरी तरह, सिर्फ ढाँचे के लिए
एक कन्स्ट्रेंट सॉल्वरजवाब औपचारिक शर्तों (कन्स्ट्रेंट्स) को पूरा करता हैपूरी तरह, समस्या के मॉडल के दायरे में
एक कैलकुलेटर या डेटाबेस लुकअपसंख्या या तथ्य किसी स्रोत से मेल खाता हैपूरी तरह, अगर स्रोत सही है
एक regex या फ़ॉर्मेट चेकयह बनावट में सही दिखता हैआंशिक — बनावट का मतलब सच्चाई नहीं है
किसी दूसरे LLM का फैसलायह दूसरे अंदाज़ा लगाने वाले को सही लगता हैकमज़ोर — यह वेरिफिकेशन नहीं है
ख़तरा
उस आखिरी पंक्ति में ही ज़्यादातर टीमें चुपचाप पूरा फायदा खो देती हैं। एक LLM का दूसरे LLM को चेक करना, दो अंदाज़ा लगाने वालों की आपसी सहमति है। यह लापरवाही को पकड़ लेता है पर पूरे भरोसे के साथ की गई गलती को नहीं पकड़ पाता, क्योंकि जिस सोच ने वह गलती पैदा की, वही उसका समर्थन भी कर देती है। अगर आपका "वेरीफ़ायर" एक प्रॉम्प्ट है, तो आपके पास एक समीक्षक (रिव्यूअर) है, चेकर नहीं।

कोड एग्जीक्यूशन हमारे पास सबसे बेहतरीन चेकर क्यों है

  • यह मुफ़्त है — न कोई इंसान, न कोई एनोटेशन, न कोई इंतज़ार।
  • यह तुरंत होता है — मिलीसेकंड में फीडबैक, इसलिए एक लूप कई बार चल सकता है।
  • यह असीमित है — आप लाखों प्रस्ताव चेक कर सकते हैं।
  • यह ईमानदार है — एक स्टैक ट्रेस से चिकनी-चुपड़ी बातें नहीं की जा सकतीं, उसकी झूठी तारीफ नहीं की जा सकती, न ही प्रॉम्प्ट इंजेक्शन से उसे अपनी बात मनवाई जा सकती है।
यह करें
यह इस सवाल का भी जवाब है कि "एजेंट सबसे पहले कोडिंग में बेहतर क्यों हुए?" (मॉड्यूल 56)। प्रोग्रामिंग अकेला ऐसा आम डोमेन है जो पहले से इंस्टॉल एक बेहतरीन वेरीफ़ायर के साथ आता है। अगर आप अपने डोमेन के लिए कोई चेकर ढूंढ या बना सकते हैं, तो आपको भी यही फायदा मिल सकता है।

ऐसे डोमेन में चेकर ढूंढना जहाँ कोई चेकर नहीं है

  1. 1

    उस चीज़ को देखें जिसे पहले से चेक किया जाता है

    चालान (इनवॉइस) का मिलान बहीखाते से होता है। शेड्यूल में समय का टकराव नहीं होना चाहिए। कॉन्फ़िगरेशन पार्स होनी चाहिए। कानूनी संदर्भ (साइटेशन) किसी असली केस से जुड़े होने चाहिए। वह मौजूदा चेक ही आपका वेरीफ़ायर है।
  2. 2

    एक राय (जजमेंट) को कैलकुलेशन में बदलें

    "क्या यह सारांश भरोसेमंद है?" यह एक राय है। "क्या इस सारांश का हर दावा मूल दस्तावेज़ में मौजूद है?" यह एक कैलकुलेशन है, और LLM की रेटिंग की तुलना में कहीं बेहतर पैमाना है।
  3. 3

    मॉडल से कुछ ऐसा बनवाएँ जिसे चेक किया जा सके

    जब आप कोई क्वेरी, फ़ॉर्मूला, डिफ (diff), या कोई स्ट्रक्चर्ड ऑब्जेक्ट मांग सकते हैं, तो लंबा टेक्स्ट (गद्य) न मांगें। गद्य को रन नहीं किया जा सकता। SQL क्वेरी को रन किया जा सकता है।
  4. 4

    आंशिक वेरिफिकेशन को ईमानदारी से स्वीकार करें

    70% आउटपुट को अपने-आप चेक करना और बाकी को किसी इंसान के पास भेजना एक असली सिस्टम है। यह दिखावा करना कि बाकी 30% को एक LLM जज संभाल लेगा, सही सिस्टम नहीं है।

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

Program-aided language modelsYouTube searchSelf-correcting AI loopsYouTube search

लैब

एक ऐसे डोमेन के लिए वेरीफ़ायर जहाँ माना जाता है कि कोई चेकर नहीं है।

~20 min

समस्या

कोई ऐसा काम चुनें जहाँ सही होना व्यक्तिपरक (subjective) लगता हो। एक ऐसी प्रॉपर्टी खोजें जिसे निष्पक्ष रूप से चेक किया जा सके और उसके लिए एक वेरीफ़ायर बनाएँ। मापें कि यह क्वालिटी की कमी को कितना पूरा करता है।
शुरुआती कोडpython
# "Is this summary faithful?" -> judgement.
# "Does every claim appear in the source?" -> computation.
def unsupported_claims(summary, source):
    return [c for c in extract_claims(summary) if not entailed(c, source)]
Google Colab खोलें ↗इस कोड के लिए आपके अपने सेटअप की ज़रूरत है (एक मॉडल, एक GPU या अतिरिक्त पैकेज)। इसे Google Colab में चलाएं: File → Upload notebook।

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

कठिन सवाल

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

Q1आपका वेरीफ़ायर 70% कवर करता है। एक साथी बाकी हिस्से के लिए LLM जज का सुझाव देता है। इसके पक्ष और विपक्ष में सबसे मजबूत दलीलें दें।दिखाएं
पक्ष में: यह सस्ता है, यह इंसानी सोच से इतना मेल खाता है कि साफ़ दिखने वाली गलतियों को पकड़ सके, और 70% के साथ 30% का अधूरा चेक, 70% के साथ कुछ भी न होने से बेहतर हो सकता है — बशर्ते आप एक सैंपल पर इंसानी रेटिंग के साथ जज को कैलिब्रेट करें और इसकी सहमति दर (agreement rate) की रिपोर्ट दें। विपक्ष में: यह वेरिफिकेशन नहीं है और इसे कभी भी ऐसा नहीं कहा जाना चाहिए, यह मुश्किल और असामान्य इनपुट्स पर सबसे बुरी तरह फ़ेल होता है जहाँ इसकी सबसे ज़्यादा ज़रूरत होती है, और यह एक ऐसा नंबर दिखाता है जो कवरेज जैसा लगता है। इसे केवल एक सिग्नल की तरह इस्तेमाल करें जो काम इंसानों तक पहुँचाए, इसे कभी भी अंतिम गेट न बनाएँ।

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

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

क्या हो अगर मेरे डोमेन में वाकई कोई चेकर न हो?

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

क्या यह सिर्फ एरर आने पर दोबारा कोशिश (रीट्राई) करना है?

रीट्राई में वही रिक्वेस्ट दोबारा दोहराई जाती है। यहाँ खास गलती को संदर्भ (कॉन्टेक्स्ट) के तौर पर वापस भेजा जाता है, ताकि अगली कोशिश को ठीक से पता हो कि क्या गलत हुआ था। ज़्यादातर फ़ायदा इसी अंतर से मिलता है।

मुझे सुधार के कितने राउंड की अनुमति देनी चाहिए?

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

क्या इससे मॉडल ज़्यादा स्मार्ट बन जाता है?

नहीं। मॉडल बिल्कुल वैसा ही रहता है। सिस्टम ज़्यादा भरोसेमंद बन जाता है, और असल में आपसे यही बनाने के लिए कहा गया था।

पाठ का टेस्ट

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

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