आपने सब कुछ आज़मा लिया, सिवाय एक चीज़ के
आपने क्या किया, इसका एक संक्षिप्त विवरण:
आपने प्रॉम्प्ट को फिर से लिखा, तीन बार, चार बार। आपने उदाहरण जोड़े, एक व्यक्तित्व जोड़ा, एक "मत करो" सूची जोड़ी जो एक मील लंबी थी।
आपने फ्रंटियर मॉडल पर अपग्रेड किया, प्रति टोकन 5x भुगतान किया, और आउटपुट अधिक आत्मविश्वासी हो गया, लेकिन उतना ही सामान्य रहा।
आपने मेमोरी चालू की, एक कॉन्टेक्स्ट फ़ाइल बनाई, उसमें अपनी ब्रांड वॉइस, अपना पिछला काम, अपनी स्टाइल गाइड डाली।
और इनमें से हर एक कदम ने आपको कुछ अच्छे जनरेशन दिए, फिर घटिया आउटपुट वापस आ गया।
ये सभी इनपुट-साइड फिक्स हैं। आप उस चीज़ को तेज़ करते रहते हैं जो जनरेट करती है, जबकि उस चीज़ को नज़रअंदाज़ करते हैं जिसे पकड़ना चाहिए। एक बेहतर बंदूक जो अंधेरे में चलाई जाए, फिर भी कुछ नहीं मारती।
घटिया आउटपुट एक आउटपुट-साइड समस्या है। ऐसा नहीं है कि मॉडल अच्छा काम नहीं कर सकता, बल्कि यह है कि आपके पास अच्छे काम को बुरे काम से अलग करने का कोई तरीका नहीं है, इससे पहले कि वह किसी ऐसे व्यक्ति तक पहुंचे जो मायने रखता है।
यहाँ कोई eval लूप नहीं है, कोई गुणवत्ता बेंचमार्क नहीं है, कोई स्कोरबोर्ड नहीं है। इसलिए आप आँख बंद करके ट्यूनिंग कर रहे हैं। आप एक प्रॉम्प्ट बदलते हैं और आपको लगता है कि यह बेहतर हो गया, लेकिन भावना माप नहीं है, और एक भावना अगले 50 जनरेशनों में छिपे बुरे रन को नहीं पकड़ती।
तो आप खुद को दोषी मानते हैं, या अपने प्रॉम्प्ट को, या अपने एजेंट सेटअप को, या अपनी कॉन्टेक्स्ट इंजीनियरिंग को, जबकि गायब टुकड़ा AI के साथ काम करने की एक पूरी परत है जो आपको कभी नहीं दिखाई गई, और इस लेख के अंत तक वह परत आपकी अपनी मशीन पर हर्मीस के अंदर चल रही होगी।
क्यों बेहतर प्रॉम्प्ट इसे ठीक नहीं कर सकते (और क्यों हर कोई फिर भी कोशिश करता रहता है)
एक प्रॉम्प्ट एक परिकल्पना है, आउटपुट परिणाम है, और एक eval ही एकमात्र चीज़ है जो उनके बीच के लूप को बंद करती है।
उस लूप के बिना आप हमेशा अनुमान लगाते रहते हैं। आप परिकल्पना को ट्वीक करते हैं, एक परिणाम को देखते हैं, जीत की घोषणा करते हैं, और आपको कभी पता नहीं चलता कि वही प्रॉम्प्ट 30% समय कचरा पैदा करता है, क्योंकि आपने केवल अपने सामने वाले एक आउटपुट को देखा।
मॉडल नॉन-डिटरमिनिस्टिक है। एक ही प्रॉम्प्ट को दो बार चलाने पर दो अलग-अलग जवाब मिलते हैं। इसका मतलब है कि एक परफेक्ट प्रॉम्प्ट भी कुछ रनों पर घटिया आउटपुट पैदा करता है, और आपको नहीं पता कि कौन से रन हैं, जब तक कि कोई क्लाइंट या उपयोगकर्ता उसे देख नहीं रहा हो।
तो एक परफेक्ट प्रॉम्प्ट गुणवत्ता की गारंटी नहीं है, यह थोड़ा बेहतर सिक्का उछालना है, और आप हर उछाल को शिप कर रहे हैं।
हर कोई फिर भी प्रॉम्प्ट तक क्यों पहुंचता है, इसका कारण सरल है: प्रॉम्प्ट ही एकमात्र लीवर है जिसे आप वास्तव में देख सकते हैं। आप इसे संपादित कर सकते हैं, और इसे संपादित करना नियंत्रण जैसा लगता है।
माप अदृश्य है। कोई आपको इस पर कोर्स नहीं बेचता, कोई वायरल थ्रेड पोस्ट नहीं करता जिसका शीर्षक हो "वह eval सूट जिसने मेरे आउटपुट को 10x कर दिया।" इसलिए पूरी बातचीत उस एक लीवर पर अटकी रहती है जो अपने आप समस्या को हल नहीं कर सकता।
जिन लोगों का AI आउटपुट लगातार साफ है, वे प्रॉम्प्टिंग में आपसे बेहतर नहीं हैं। उनके पास बस एक दूसरा लीवर है जो आपके पास नहीं है: वे शिप करने से पहले हर आउटपुट को एक मानक के खिलाफ मापते हैं, और यह माप ही है जो उनकी प्रॉम्प्टिंग को जादू जैसा बनाता है।
दो जगहें जहाँ घटिया आउटपुट रहता है
घटिया आउटपुट बिल्कुल दो जगहों पर छिपता है, और लगभग हर कोई उनमें से केवल एक को देख रहा है।
जगह 1, आपका कंटेंट आउटपुट
ट्वीट, लेख, ईमेल, लैंडिंग पेज, पोस्ट, वह सब कुछ जो आप AI से जनरेट करते हैं और अपने नाम से प्रकाशित करते हैं।
यहाँ घटिया आउटपुट ऐसे काम जैसा दिखता है जो तकनीकी रूप से ठीक है और पूरी तरह से खोखला है। और यह टाइमलाइन पर हर दूसरे AI अकाउंट जैसा लगता है: बाहर से सही, अंदर से खाली।
यह सार्वजनिक रूप से मर जाता है और आप यह नहीं बता सकते कि क्यों, क्योंकि जब आपने सेंड दबाया था तब हर व्यक्तिगत टुकड़ा ठीक लग रहा था।
जगह 2, आपका प्रोडक्ट आउटपुट
AI फीचर जो आपने शिप किया, एजेंट, चैटबॉट, सपोर्ट रिस्पॉन्डर, एक्सट्रैक्शन पाइपलाइन, वह चीज़ जिसे आपके उपयोगकर्ता वास्तव में छूते हैं।
यहाँ घटिया आउटपुट पूर्ण आत्मविश्वास के साथ दिए गए गलत उत्तर जैसा दिखता है: एक भ्रमित संख्या, एक टूटा हुआ JSON पेलोड, एक स्वर जो ब्रांड के लिए ऑफ है, एक आउटपुट जो डेमो में शानदार था और तीन डिप्लॉय बाद चुपचाप खराब हो गया।
यह सार्वजनिक रूप से नहीं मरता, यह चुपचाप स्केल करता है। हर उपयोगकर्ता को थोड़ा खराब अनुभव मिलता है और उनमें से अधिकांश आपको कभी नहीं बताते, वे बस चले जाते हैं।
ये एक ही बीमारी हैं, एक ही इलाज के साथ।
कंटेंट का घटिया आउटपुट और प्रोडक्ट का घटिया आउटपुट दोनों ही बिना मापे गए AI आउटपुट हैं जो बीच में किसी गेट के बिना सीधे दर्शकों तक जा रहे हैं।
एकमात्र अंतर दांव और दृश्यता का है। कंटेंट का घटिया आउटपुट आपको जोर से शर्मिंदा करता है, प्रोडक्ट का घटिया आउटपुट आपको चुपचाप खून बहाता है। और हर्मीस में हम जो लूप बनाते हैं, वह दोनों को एक ही कौशल से ग्रेड करता है, ताकि आप अपने द्वारा जनरेट की गई हर चीज़ पर दो के बजाय एक गुणवत्ता प्रणाली चला सकें।
eval लूप वास्तव में क्या है
एक eval लूप एक दोहराए जाने योग्य परीक्षण है जो आपके AI आउटपुट को एक मानक के खिलाफ स्कोर करता है, स्वचालित रूप से, हर बार, शिप करने से पहले और शिप करने के बाद।
बस इतना ही, पूरी बात। और यह वह परत है जो लगभग किसी के पास नहीं है जो AI के साथ बना रहा है।
आउटपुट जनरेट करें
इसे आपके द्वारा परिभाषित बेंचमार्क के खिलाफ स्कोर करें
उन रनों को पकड़ें जो रेखा से नीचे आते हैं
जो विफल हो रहा है उसे ठीक करें
फिर से स्कोर करें, और केवल पासिंग आउटपुट को ही जाने दें
सॉफ्टवेयर इंजीनियरों के पास यह हमेशा से रहा है, इसे टेस्टिंग कहते हैं। आप बिना किसी परीक्षण के कोड कभी शिप नहीं करेंगे और बस उम्मीद करेंगे कि यह प्रोडक्शन में काम करेगा। लेकिन ठीक इसी तरह से पूरा उद्योग अभी AI आउटपुट शिप कर रहा है, सीधे मॉडल से उपयोगकर्ता तक, एक वाइब और एक प्रार्थना पर।
लगभग किसी के पास eval लूप न होने का कारण जनसांख्यिकीय है। आज AI के साथ बनाने वाले लोग कंटेंट, सेल्स, प्रोडक्ट, फाउंडिंग से आए हैं, इंजीनियरिंग से नहीं। इसलिए "अपने आउटपुट के लिए टेस्ट लिखें" कभी उनके टूलकिट में नहीं था। Eval को "असली" इंजीनियरों के लिए बुनियादी ढांचे के रूप में देखा जाता है, और जिन लोगों को उनकी सबसे अधिक आवश्यकता है, वे मान लेते हैं कि उन्हें एक चाहने की अनुमति नहीं है।
इसे नॉन-डिटरमिनिस्टिक के लिए यूनिट टेस्टिंग समझें। आप यह परीक्षण नहीं कर रहे हैं कि कोड चलता है या नहीं, आप यह परीक्षण कर रहे हैं कि आउटपुट अच्छा है या नहीं, और आप इसे पर्याप्त मामलों में परीक्षण कर रहे हैं ताकि एक बुरा रन छिप न सके।
एक eval लूप तीन जगहों पर चलता है, और आगे का बिल्ड इसे तीनों में डालता है:
- शिप करने से पहले, अपने नए प्रॉम्प्ट या मॉडल को सहेजे गए मामलों के एक सेट के खिलाफ चलाएं और पुष्टि करें कि यह खराब नहीं हुआ। यह रिग्रेशन टेस्टिंग है, यह कैसे आप एक ऐसे बदलाव को रोकते हैं जो एक चीज़ को ठीक करता है और चुपचाप तीन अन्य को तोड़ देता है।
- रनटाइम पर, आउटपुट को उत्पन्न होने पर स्कोर करें और कंडीशनल लॉजिक को विफलताओं को उपयोगकर्ता तक पहुंचने से पहले पकड़ने दें। यह गार्डरेल है।
- प्रोडक्शन में, वास्तविक निष्पादन के एक नमूने को लगातार स्कोर करें ताकि आप गुणवत्ता को उस दिन गिरते हुए देख सकें जब वह शुरू होती है, उस सप्ताह नहीं जब कोई क्लाइंट शिकायत करता है।
आप पहले वाले को एक स्प्रेडशीट में खड़ा कर सकते हैं, लेकिन तीनों को लगातार चलाना, बिना इसे दूसरी नौकरी में बदले, यही पूरा कारण है कि हम इसे एक एजेंट के अंदर डाल रहे हैं।
जिस क्षण गुणवत्ता एक संख्या बन जाती है, घटिया आउटपुट एक भावना नहीं रह जाता जो आपको बार-बार आती है, और एक बग बन जाता है जिसे आप ठीक कर सकते हैं। आप एक वाइब को डीबग नहीं कर सकते, आप एक ऐसे स्कोर को डीबग कर सकते हैं जो 0.82 से गिरकर 0.61 हो गया।
बेंचमार्क, तीन भाग जिन्हें आप बनाने वाले हैं
एक बेंचमार्क के तीन भाग होते हैं, और वे तीनों एक जैसे हैं चाहे आप कंटेंट को ग्रेड कर रहे हों या प्रोडक्ट को:
टेस्ट केस, वास्तविक इनपुट जोड़े गए कि अच्छा आउटपुट कैसा दिखता है (आपकी ग्राउंड ट्रुथ)
मीट्रिक, आप आउटपुट को एक स्कोर में कैसे बदलते हैं, आदर्श रूप से 0 से 1
एक थ्रेशोल्ड, वह रेखा जिसके नीचे कुछ भी शिप नहीं होता
इन तीनों को बनाएं और आपके पास एक गुणवत्ता गेट है। किसी एक को छोड़ें और आपके पास एक इच्छा है। बाकी यह सेक्शन है कि प्रत्येक भाग के अंदर क्या जाता है, फिर हम तीनों को हर्मीस में वायर करते हैं।
कंटेंट के लिए, आपके टेस्ट केस आपका गोल्ड स्टैंडर्ड हैं
अपने 20 से 50 सबसे अच्छे टुकड़े निकालें। वे बैंगर्स, वे पोस्ट जो बुकमार्क हुए, वे लेख जिनके पीछे आप अपना पूरा नाम रखेंगे। यह "अच्छा" कैसा दिखता है। आप एक मानक का आविष्कार नहीं कर रहे हैं, आप उसे निकाल रहे हैं जिसे आप अपने सबसे अच्छे दिनों में पहले ही हिट कर चुके हैं।
कंटेंट के लिए, आपका मीट्रिक एक रूब्रिक है
एक स्कोर केवल उतना ही अच्छा है जितना उसके पीछे का रूब्रिक। इसलिए एन्कोड करें कि आप वास्तव में क्या मानते हैं जो काम को अच्छा बनाता है। कंटेंट के लिए, मैं हर टुकड़े को चार मानदंडों पर ग्रेड करता हूं:
- यह बताता है कि कुछ विशिष्ट कैसे करना है, एक वाइब नहीं, एक कार्य जिसे पाठक कल ले जा सकता है
- दर्शकों में कोई भी इसे समझ सकता है, कोई शब्दजाल की दीवार नहीं, कोई इनसाइड-बेसबॉल नहीं
- यह संरचित, दोहराने योग्य, कदम दर कदम है, केवल प्रेरणादायक नहीं
- यह उपन्यास है, पाठक को नहीं पता था कि आप ऐसा कर सकते हैं
इन चारों के ऊपर बैठा मेटा-मानदंड: क्या कोई इसे बुकमार्क करेगा और बाद में लागू करने के लिए वापस आएगा? यदि उत्तर नहीं है तो यह घटिया आउटपुट है, चाहे गद्य कितना भी साफ क्यों न पढ़े।
चाल रूब्रिक है। एक अस्पष्ट रूब्रिक ("क्या यह अच्छा और आकर्षक है") एक अस्पष्ट स्कोर पैदा करता है। एक विशिष्ट रूब्रिक ("क्या इसमें कम से कम एक कॉपी-पेस्ट करने योग्य टेम्पलेट या प्लेबुक है") एक स्कोर पैदा करता है जिस पर आप भरोसा कर सकते हैं। न्यायाधीश आपके स्वाद को तभी विरासत में लेता है जब आप वास्तव में अपने स्वाद को लिखते हैं।
प्रोडक्ट के लिए, आपके टेस्ट केस आपके लॉग से आते हैं
अपने फीचर द्वारा देखे गए वास्तविक इनपुट निकालें। अपने लॉग से, वास्तविक उपयोगकर्ता सत्रों से, लॉन्च के दिन आपके द्वारा परीक्षण किए गए तीन हैप्पी-पाथ उदाहरणों से नहीं। जो मामले आपको तोड़ते हैं वे अजीब हैं, और अजीब आपके लॉग में रहते हैं।
प्रोडक्ट के लिए, आपका मीट्रिक कार्य से मेल खाता है
प्रत्येक इनपुट के लिए, परिभाषित करें कि एक सही आउटपुट कैसा दिखता है। फिर मीट्रिक को कार्य से मिलाएं: सटीक मिलान जब एक सही लेबल हो, एक वैलिडेटर जब संरचना को पकड़ना हो, सिमेंटिक समानता प्लस एक जज जब आउटपुट ओपन-एंडेड हो। मीट्रिक को बस एक संख्या वापस करनी है, क्योंकि एक संख्या ही एकमात्र चीज़ है जिस पर आप थ्रेशोल्ड लगा सकते हैं।
दोनों के लिए, थ्रेशोल्ड वह रेखा है जिसे आप पकड़ते हैं
0.7 शुरू करने के लिए एक उचित स्थान है। 0.7 से नीचे की कोई भी चीज़ शिप करने से पहले फिर से काम की जाती है या मार दी जाती है, कोई अपवाद नहीं। थ्रेशोल्ड तभी काम करता है जब आप कभी 0.6 को इसलिए नहीं जाने देते क्योंकि आपको यह पसंद आया। पूरी बात यह है कि देर रात के अहंकार को निर्णय से बाहर निकालना है।
यह बेंचमार्क है। अब हम इसे अपने आप चलाते हैं।
हर्मीस के अंदर लूप का निर्माण
हर्मीस कोई eval बटन नहीं भेजता है। "गुणवत्ता" नाम का कोई डैशबोर्ड नहीं है जहाँ आप "स्लॉप प्रोटेक्शन चालू करें" क्लिक करते हैं।
इसके बजाय हर्मीस आपको जो देता है वह बेहतर है: एक eval लूप के कच्चे टुकड़े प्रिमिटिव के रूप में जिन्हें आप एक बार असेंबल करते हैं और फिर अपने पास रखते हैं।
कौशल जो यह अपने लिए लिखता है और पुन: उपयोग करता है, लगातार मेमोरी जो सत्रों में बढ़ती है, बिल्ट-इन क्रॉन जो किसी भी प्लेटफॉर्म पर डिलीवर करता है, स्लैक में अनुमोदन बटन, और कोर में बेक की गई एक सेल्फ-इम्प्रूवमेंट आदत।
हर्मीस खुद को "वह एजेंट कहता है जो आपके साथ बढ़ता है" और वह वृद्धि बिल्कुल वही लूप है जिसे हम बना रहे हैं।
तो चलिए इसे वायर करते हैं, छह चालें।
चाल 1, हर्मीस को वहाँ खड़ा करें जहाँ वह आप तक पहुँच सके
इसे इंस्टॉल करें और इसे टेलीग्राम से कनेक्ट करें। यह जितना लगता है उससे कहीं अधिक मायने रखता है, क्योंकि गेट तभी काम करता है जब यह आपको रोक सके। हर्मीस 20+ चैनलों पर चलता है और स्लैक और टेलीग्राम में देशी अनुमोदन बटन भेजता है, ताकि एजेंट पृष्ठभूमि में काम कर सके और जब निर्णय आपका हो तो आपके कंधे पर थपकी दे सके।
चाल 2, अपने गोल्ड स्टैंडर्ड को मेमोरी में लोड करें
हर्मीस के पास लगातार मेमोरी है जो पूर्ण क्रॉस-सेशन रिकॉल के साथ सत्रों में बढ़ती है। इसलिए आपके बेंचमार्क के 20 से 50 सबसे अच्छे टुकड़े एक बार वहाँ जाते हैं और रहते हैं। यह वह हिस्सा है जो सामान्यतः स्क्रीनशॉट और पुराने ड्राफ्ट में बिखरा होता है। यहाँ यह एजेंट की दीर्घकालिक मेमोरी है, क्वेरी करने योग्य, वह ग्राउंड ट्रुथ जिसके खिलाफ आपके स्कोर मापे जाते हैं।
चाल 3, अपने रूब्रिक को एक जज स्किल में बदलें
यह इसका दिल है। आप हर्मीस को एक बार, सादी अंग्रेजी में बताते हैं, एक ऐसा कौशल बनाने के लिए जो एक आउटपुट और आपके रूब्रिक को लेता है और प्रति मानदंड एक 0 से 1 स्कोर एक-पंक्ति के कारण के साथ लौटाता है। यह llm-as-a-judge है, एक एजेंट जो आपके llm को ग्रेड कर रहा है, और एक तेज रूब्रिक वाला मॉडल आपसे एक अधिक सुसंगत आलोचक है क्योंकि इसमें टुकड़े में कोई अहंकार नहीं है और उस एक वाक्य से कोई लगाव नहीं है जिस पर आपको गुप्त रूप से गर्व है।
यह एक कौशल के रूप में रहता है, न कि एक बार के प्रॉम्प्ट के रूप में, इसका कारण यह है कि हर्मीस के कौशल प्रक्रियात्मक मेमोरी हैं। एजेंट उन्हें लिखता है, रखता है, और पुन: उपयोग करता है। आप अपने स्वाद को एक बार एनकोड करते हैं और यह हर आउटपुट को हमेशा के लिए ग्रेड करता है। और कौशल चक्रवृद्धि करते हैं। Nous ने पाया कि 20+ स्व-निर्मित कौशल वाले एजेंट समान कार्यों को 40% तेजी से पूरा करते हैं क्योंकि वे प्रक्रिया को फिर से खोजना बंद कर देते हैं। आपका न्यायाधीश जितना अधिक चलता है उतना ही तेज होता जाता है।
चाल 4, सूट को एक स्प्रेडशीट नहीं, एक कौशल बनाएं
आपके टेस्ट केस और मीट्रिक फ़ंक्शन एक कौशल बन जाते हैं जिसे हर्मीस रखता है और संस्करणित करता है। मीट्रिक लाइब्रेरी वह है जो कार्य को चाहिए: वर्गीकरण के लिए सटीक मिलान, निष्कर्षण के लिए regex, संरचना के लिए JSON और की-एंड-वैल्यू वैलिडेटर, जनरेटिव आउटपुट के लिए सिमेंटिक समानता।
खुले-आखिरी सामान के लिए आपका जज कौशल। हर्मीस स्वयं स्कोरिंग कोड लिखता है। आप कार्य का वर्णन करते हैं और यह मीट्रिक बनाता है। यह सब एक जगह बैठता है जिसका एजेंट मालिक है, एक शीट के बजाय जिसे आप खो देंगे।
चाल 5, शिप को रिग्रेशन टेस्टिंग और एक अनुमोदन बटन के साथ गेट करें
यह पूरे सिस्टम में सबसे अधिक लीवरेज वाली आदत है और जिसे कोई भी हाथ से नहीं करता रहता। इसलिए हम इसे एजेंट को सौंपते हैं। इसे वायर करें ताकि कोई भी बदलाव, एक नया प्रॉम्प्ट, एक स्वैप किया गया मॉडल, एक ट्वीक की गई पाइपलाइन, सूट को ट्रिगर करता है। हर्मीस हर केस को फिर से चलाता है, बेसलाइन के खिलाफ स्कोर डेल्टा की गणना करता है, और चुपचाप शिप करने के बजाय आपको स्लैक में पिंग करता है: "स्कोर 0.81 से 0.74 हो गए, दो मामले रिग्रेस हुए, अनुमोदन?", और यह तभी आगे बढ़ता है जब आप बटन दबाते हैं।
आप इसे /goal के साथ उस काम पर लॉक रख सकते हैं, जो एजेंट को टर्न के पार एक लक्ष्य के खिलाफ रखता है, और किसी भी बड़ी चीज़ के लिए इसका मल्टी-एजेंट कानबो रन को विघटित कर सकता है, समानांतर में स्कोर कर सकता है, और इसे शेड्यूल कर सकता है। तो गेट एक स्थायी प्रक्रिया है, कोई ऐसी चीज़ नहीं जिसे आप चलाना याद रखते हैं।
चाल 6, प्रोडक्शन को क्रॉन पर देखें और लूप को बंद करें
हर्मीस के पास बिल्ट-इन क्रॉन है जो किसी भी प्लेटफॉर्म पर डिलीवर करता है। इसलिए आप एक ऐसा काम शेड्यूल करते हैं जो वास्तविक निष्पादन का नमूना लेता है, उन्हें उसी जज कौशल से स्कोर करता है, और जिस क्षण रेखा गिरती है आपको डीएम करता है। आप गिरावट को उस दिन पकड़ते हैं जब वह शुरू होती है, उस सप्ताह नहीं जब कोई क्लाइंट शिकायत करता है। "eval स्कोर गिर गया" एक ऐसी समस्या है जिस पर आप कार्य कर सकते हैं, "एक ग्राहक नाराज लग रहा था" नहीं है।
फिर वह हिस्सा जो पूरी चीज़ को चक्रवृद्धि बनाता है: जब आप स्लैक में थम्ब्स-डाउन के साथ एक खराब आउटपुट को फ्लैग करते हैं, तो हर्मीस इसे एक नए टेस्ट केस के रूप में सूट कौशल में वापस लिखता है। वह विफल रन एक स्थायी जांच बन जाता है। और क्योंकि सेल्फ-इम्प्रूवमेंट वह है जो हर्मीस है, न कि एक फीचर जो किनारे पर बोल्ट किया गया है, सूट हर हफ्ते अपने आप सख्त होता जाता है। जब आप सोते हैं तब फर्श ऊपर उठता है।
एक बार यह चलने के बाद अच्छा कैसा दिखता है, ठोस रूप से:
- एक कंटेंट का टुकड़ा जो आपके रूब्रिक पर 0.7 से नीचे है, कभी शिप नहीं होता।
- एक प्रोडक्ट बदलाव जो किसी भी मीट्रिक को बेसलाइन से नीचे गिराता है, डिप्लॉय को तब तक ब्लॉक करता है जब तक आप अनुमोदन नहीं करते।
- और प्रोडक्शन स्कोर लाइन स्थिर रहती है या चढ़ती है। जिस दिन यह गिरती है, वह दिन हर्मीस आपको पिंग करता है, उस सप्ताह नहीं जब चर्न दिखता है।
वह हिस्सा जो कोई सुनना नहीं चाहता
आपके AI आउटपुट के असंगत होने का कारण यह नहीं है कि आप प्रॉम्प्टिंग में बुरे हैं। और यह नहीं है कि मॉडल अभी तक पर्याप्त स्मार्ट नहीं है।
यह है कि आप एक जनरेशन स्टेप चला रहे हैं जिसमें कोई गुणवत्ता वाला कदम नहीं है। आपने आधा सिस्टम बनाया है और आप उस आधे को दोष दे रहे हैं जो काम करता है।
फिक्स एक बेहतर प्रॉम्प्ट नहीं है, यह एक गायब परत है:
- परिभाषित करें कि अच्छा कैसा दिखता है।
- इसे एक संख्या में बदलें।
- हर आउटपुट को इसके खिलाफ स्कोर करें।
- रेखा से नीचे आने वाली हर चीज़ को गेट करें।
- और लूप को बंद करें ताकि फर्श हर हफ्ते ऊपर उठे।
और अब वह परत कोई "किसी दिन" प्रोजेक्ट नहीं है। यह एक एजेंट के अंदर छह चालें हैं जो आपकी अपनी मशीन पर चलता है।
ऐसा करें और घटिया आउटपुट एक ऐसी चीज़ नहीं रह जाती जो बेतरतीब ढंग से आपके साथ होती है, और एक ऐसी चीज़ बन जाती है जिसे आप दरवाजे से बाहर जाते समय पकड़ते हैं, हर बार। उसी तरह जैसे एक असली फैक्ट्री किसी ग्राहक तक पहुंचने से पहले एक दोष को पकड़ लेती है।
प्रॉम्प्ट कभी सिस्टम नहीं था।
eval लूप सिस्टम है। हर्मीस वह जगह है जहाँ यह चलता है।
और अब यह आपके पास है।
