हर कोई सतत सीखने (Continual Learning) की बात इस तरह करता है जैसे इसका मतलब सिर्फ एक ही चीज़ है: मॉडल के वज़न को अपडेट करना। लेकिन एजेंट इकोसिस्टम के बारे में एक असुविधाजनक सच्चाई है — आज प्रोडक्शन में मौजूद अधिकांश एजेंट बंद फ्रंटियर मॉडल (closed frontier models) का लाभ उठाते हैं। जब आपके पास वज़न नहीं हैं, तो आप निश्चित रूप से उन्हें फ़ाइन-ट्यून नहीं कर सकते। अधिकांश एजेंट निर्माताओं के लिए, वज़न-स्तर पर सतत सीखना संभव नहीं है, खासकर जब क्षमताओं की सबसे आगे काम कर रहे हों (जैसे Fable 5 या GPT 5.6)।
इसका मतलब यह नहीं है कि एजेंट सीख नहीं सकते। एजेंटिक सिस्टम तीन स्तरों पर सुधार कर सकते हैं — मॉडल, हार्नेस और संदर्भ [0] — और अंतिम दो पूरी तरह से आपके नियंत्रण में हैं। यहीं पर एक बड़ा (लेकिन अक्सर अनदेखा) अवसर छिपा है: हार्नेस-स्तर की सीखने से आप अपने एजेंट के हर इंस्टेंस को संचालित करने वाले कोड, टूल्स और निर्देशों को व्यवस्थित रूप से बेहतर बनाने के लिए प्रोडक्शन ट्रेस का खनन कर सकते हैं, जबकि संदर्भ-स्तर की सीखने से आप एजेंट, उपयोगकर्ता और संगठन स्तर पर वैयक्तिकृत कर सकते हैं, ताकि आपका उत्पाद हर इंटरैक्शन के साथ बेहतर होता जाए। उपरोक्त सभी करें, और आप ऐसे सुधारों को संचित करेंगे जिन्हें आप प्रतिदिन शिप कर सकते हैं।
इस लेख के बाकी हिस्से में, मैं बताऊंगा कि कैसे हम पिछले एक साल से Replit Agent पर सतत सीखने को लागू कर रहे हैं, और इस दौरान हमने जो भी सबक सीखे हैं, उन्हें साझा करूंगा।
Replit Agent का बड़े पैमाने पर मूल्यांकन और सुधार
अधिकांश Replit Agent उपयोगकर्ता एक विचार से शुरुआत करते हैं। वे लक्ष्य को प्राकृतिक भाषा में बताते हैं — बिना किसी रेपो, टेस्ट सूट या चुने हुए फ्रेमवर्क के — और उम्मीद करते हैं कि एजेंट इसे एक काम करने वाले ऐप में बदल देगा। परिणाम एक वेबसाइट, स्लाइड डेक, मोबाइल ऐप, कई जुड़े हुए आर्टिफैक्ट या कुछ और हो सकता है।
Vibe coder आमतौर पर डिफ़ या टेस्ट आउटपुट की जाँच नहीं कर रहे होते हैं। Replit Agent के लिए सफलता भ्रामक रूप से सरल है: जब उपयोगकर्ता क्लिक करें तो ऐप को काम करना चाहिए।
यह मूल्यांकन के काम को बदल देता है। एक एकल स्कोर एक विशिष्ट शिपिंग निर्णय में मदद कर सकता है, लेकिन यह हमें सप्ताह दर सप्ताह यह नहीं बता सकता कि क्या Replit Agent उपयोगकर्ताओं के लिए बेहतर हो रहा है। इस प्रश्न का उत्तर देने के लिए, मूल्यांकन को सुधार लूप का हिस्सा बनना होगा।
NASA Lewis Research Center, इंजन रिसर्च बिल्डिंग में सेंट्रल कंट्रोल रूम, 1968 — माप तब मायने रखता है जब वह यह बदलता है कि क्या शिप होता है।
मूल्यांकन को अब और अधिक करना होगा
एजेंट मूल्यांकन एकतरफा प्रक्रिया की तरह हुआ करता था: eval चलाएं, एक स्कोर तैयार करें और शिपिंग कॉल करें। यह तब काम करता है जब रिलीज़ धीमी हों और जिस चीज़ को मापा जा रहा है वह शायद ही कभी बदलती हो। यह तब टूट जाता है जब मॉडल, प्रॉम्प्ट, टूल्स और उत्पाद सतहें सभी तेज़ी से बदल रहे हों।
पुराने लूप ने मूल्यांकन को सीमित बना दिया। लेकिन Replit Agent इतनी तेज़ी से बदलता है कि एक एकल स्कोर पूरे निर्णय को नहीं ले जा सकता। एक स्कोर कार्यों के एक स्लाइस पर दो उम्मीदवारों की तुलना कर सकता है। यह यह नहीं समझा सकता कि उपयोगकर्ता किस बारे में परवाह करते हैं, प्रोडक्शन कहाँ टूट रहा है, या आगे क्या सुधार करना है।
मूल्यांकन को लॉन्च चेक से सुधार लूप में जाना था।
पुराना मूल्यांकन कार्य एक मानव शिपिंग निर्णय पर समाप्त होता है; नया एक सतत प्रणाली को फीड करता है जो प्रोडक्शन से सीखती है और बेहतर एजेंट शिप करती है।
सिस्टम में दो माप स्तंभ और एक अनुकूलन लूप है। ऑफ़लाइन बेंचमार्क हमें बताते हैं कि क्या उम्मीदवार बदलाव उन्हें शिप करने से पहले सिम्युलेटेड ऐप-बिल्डिंग कार्यों को पूरा कर सकते हैं। ऑनलाइन A/B परीक्षण और प्रोडक्शन ट्रेस दिखाते हैं कि बदलाव शिप होने के बाद वास्तविक उपयोगकर्ता कैसे प्रभावित होते हैं। वे सिग्नल फिर evals और शिपिंग निर्णयों में वापस प्रवाहित होते हैं।
कोई भी स्तर अपने आप में पर्याप्त नहीं है। बेंचमार्क रिलीज़ से पहले प्रतिगमन को पकड़ते हैं। A/B परीक्षण दिखाते हैं कि क्या प्रोडक्शन व्यवहार बदल गया। ट्रेस क्लस्टर समग्र मेट्रिक्स के तहत विफलताओं की व्याख्या करते हैं। मानव निर्णय सुधार लूप को सही उत्पाद और इंजीनियरिंग परिणामों की ओर इंगित रखता है। यह आकार सुरक्षा इंजीनियरिंग में स्विस चीज़ मॉडल के समान है: प्रत्येक परत में छेद होते हैं, लेकिन साथ में वे किसी एक परत की तुलना में अधिक पकड़ते हैं।
मौजूदा बेंचमार्क उपयोगकर्ता तक पहुँचने से पहले रुक जाते हैं
एजेंटिक कोडिंग बेंचमार्क जैसे SWE-bench [1] और Terminal-Bench [2] सीमित, दोहराए जाने योग्य वातावरण में कोड को ग्रेड करते हैं। ये बेंचमार्क मूल्यवान और व्यापक रूप से अपनाए गए हैं, लेकिन वे उस सिग्नल को याद करते हैं जिसकी एक vibe coder परवाह करता है।
Replit Agent अक्सर स्क्रैच से कोडबेस बनाता है। उपयोगकर्ता निश्चित रूट, फंक्शन सिग्नेचर, सेलेक्टर या टेस्ट नहीं लाते; वे एक उत्पाद अनुरोध लाते हैं। एजेंट स्टैक, स्कीमा, रूट, कम्पोनेंट और इंटरैक्शन फ्लो चुनता है।
यह एक कार्यात्मक शुद्धता अंतर पैदा करता है। एक एजेंट कोडिंग बेंचमार्क की स्थानीय बाधाओं को संतुष्ट कर सकता है और फिर भी उसमें विफल हो सकता है जो उपयोगकर्ता देखता है: क्या तैयार ऐप वही करता है जो पूछा गया था। Vibe कोडिंग के लिए, मूल्यांकन लक्ष्य आर्टिफैक्ट ही है: क्या यह लोड होता है, क्या मुख्य वर्कफ़्लो काम करता है, और क्या परिणाम अनुरोध से मेल खाता है?
ViBench का परिचय
इस प्रकार के एंड-टू-एंड मूल्यांकन की आवश्यकता ही है कि हमने ViBench [3] क्यों बनाया, जो हमारा सार्वजनिक बेंचमार्क है जो vibe कोडिंग को मापता है, एक सरल लेकिन महत्वपूर्ण सिग्नल: क्या एजेंट द्वारा बनाया गया एप्लिकेशन स्पेक को पूरा करता है?
ViBench एक सादे-अंग्रेज़ी उत्पाद आवश्यकता दस्तावेज़ (PRD) से शुरू होता है जो अनामित Replit प्रोडक्शन ट्रेस से लिया गया है। वहाँ से, एजेंट PRD प्राप्त करता है और स्क्रैच से एक चलने वाला ऐप बनाता है, बिना उस मचान, रूट या संदर्भों तक सीमित हुए जो पारंपरिक कोडिंग बेंचमार्क की आवश्यकता होती है।
हालाँकि, वही लचीलापन जो ViBench को यथार्थवादी बनाता है, एक समान रूप से लचीले eval एजेंट की मांग करता है, जो PRD में आधारित रहे। SWE-bench-शैली के बेंचमार्क में, प्रोजेक्ट पहले से मौजूद है, इसलिए मूल्यांकन सतह निश्चित है। Vibe कोडिंग में, एजेंट स्टैक, रूट, कम्पोनेंट और फ्लो चुनता है। मूल्यांकन को यह पता लगाना होगा कि उसने जो कुछ भी आविष्कार किया है।
इसके लिए, प्रत्येक ViBench कार्य PRD को प्राकृतिक-भाषा परीक्षण योजनाओं के एक सेट के साथ जोड़ता है जो फीचर-स्तरीय इंटरैक्शन और अभिकथन का वर्णन करता है जिसे तैयार ऐप को संतुष्ट करना होगा। eval एजेंट एक लचीली बैकबोन के रूप में Playwright का उपयोग करता है, जो इसे ऑफ़लाइन सिमुलेशन, फ़ाइल हेरफेर और मल्टी-टेनेंसी जैसी जटिल सुविधाओं का उपयोग करने देता है। क्योंकि यह ऐप के लोकेटर या संरचना को a priori नहीं जानता है, यह एक नोटबुक वातावरण में काम करता है, धीरे-धीरे यह खोजता है कि ऐप कैसे बनाया गया है और चरण दर चरण इसके साथ बातचीत करता है, यह दृष्टिकोण Replit के स्वचालित स्व-परीक्षण पर पहले के शोध से लिया गया है [4]।
Replit पैमाने पर ViBench और सामान्य रूप से हमारे evals को चलाने के लिए मजबूत बुनियादी ढाँचे के समर्थन की भी आवश्यकता होती है [5]। आंतरिक रूप से, हम उसी प्रोडक्शन बुनियादी ढाँचे पर निर्भर करते हैं जो हमें ऐप बनाने और अपने एजेंट चलाने के लिए पृथक, अच्छी तरह से संसाधनयुक्त सैंडबॉक्स स्पिन करने देता है। क्योंकि हम उन सैंडबॉक्स को जल्दी से फोर्क कर सकते हैं [6], हम क्रॉस-मूल्यांकन संदूषण के जोखिम के बिना, अधिकांश मूल्यांकन समानांतर में चलाते हैं।
स्क्रैच से ऐप बनाने के अलावा, वही ViBench नींव, एक प्राकृतिक-भाषा PRD जिसे प्राकृतिक-भाषा परीक्षण योजनाओं द्वारा ग्रेड किया जाता है, vibe-कोडिंग परिदृश्यों की एक श्रृंखला के लिए अनुकूलित होती है। यह मूल्यांकन करने के लिए कि एक एजेंट मौजूदा ऐप के भीतर कैसे काम करता है, Replit के मध्य-प्रक्षेपवक्र वर्कलोड के करीब, हम इसे मौजूदा कोडबेस पर शुरू करते हैं और मापते हैं कि यह एक फीचर PRD से फीचर एक्सटेंशन को कितनी अच्छी तरह शिप करता है। वह कोडबेस हमारे अपने संदर्भ कार्यान्वयन या उन ऐप्स से आ सकता है जिन्हें एजेंट ने स्वयं vibe-कोड किया था, जिसे हम अपने प्रकाशन में Vibe-to-ref और Vibe-on-Vibe कहते हैं। जब हम नई उत्पाद सतहें शिप करते हैं, तो वही बैकबोन हमें नए इंटरैक्शन पैटर्न का मूल्यांकन करने के लिए जल्दी से नई समस्याएं प्राप्त करने देता है, जैसा कि हमने Agent 4 के समानांतर-और-मर्ज और सबएजेंट डीकंपोज़िशन के लिए किया था।
ViBench व्यवहार मूल्यांकनकर्ता को स्थिर रखता है जबकि इनपुट और निर्माण रणनीति को अलग-अलग करता है।
प्रारंभिक ViBench परिणामों ने हमें दो उपयोगी सबक दिए। पहला, फ्रंटियर कोडिंग-बेंचमार्क स्कोर हमेशा पूर्ण ऐप बिल्डिंग में स्थानांतरित नहीं होते, खासकर ओपन-वेट मॉडल के लिए। दूसरा, अधिकांश मॉडल अपने स्वयं के कोड का विस्तार करते समय खराब हो जाते हैं, क्योंकि त्रुटियाँ अक्सर बढ़ जाती हैं। साथ में, वे सबक हमें चढ़ने के लिए एक बेहतर पहाड़ी देते हैं: केवल कोड लिखना जो परीक्षण पास करता है, बल्कि ऐप बनाना जो अगले उपयोगकर्ता अनुरोध से बच सकता है।
A/B हमें ईमानदार रखने का तरीका है
हम ऑफ़लाइन evals पर गहरा भरोसा करते हैं, लेकिन वे एकमात्र न्यायाधीश नहीं हैं। हमने पर्याप्त एजेंट अपडेट देखे हैं जो नियंत्रित सेटिंग्स में अच्छे दिखते हैं, केवल वास्तविक उपयोगकर्ता व्यवहार को पीछे धकेलने के लिए, यह जानने के लिए कि प्रोडक्शन को माप की अपनी परत की आवश्यकता है।
उपयोगकर्ता अलिखित, हमेशा चालू रहने वाले और ऐसे पैमाने पर काम करने वाले होते हैं जिसे कोई ऑफ़लाइन बेंचमार्क पूरी तरह से पुन: पेश नहीं कर सकता। वे प्रोजेक्ट छोड़ देते हैं, अपना मन बदल लेते हैं, सुविधाओं को आश्चर्यजनक तरीकों से जोड़ते हैं और विफलता मोड की खोज करते हैं जिनके बारे में हम परीक्षण करना नहीं जानते थे।
इसलिए हम अधिकांश एजेंट-प्रभावित अपडेट का A/B परीक्षण करते हैं: प्रॉम्प्ट, टूल्स, हार्नेस संशोधन, मॉडल स्वैप और बड़े व्यवहार परिवर्तन। कई प्रयोग अक्सर एक साथ चलते हैं — इंटरैक्शन प्रभावों को छिपाने से बचने के लिए एट्रिब्यूशन स्पष्ट रखा जाता है। A/B परीक्षण उपयोगकर्ता व्यवहार, भावना और सफलता को सतह पर लाते हैं: क्या उपयोगकर्ता चलते रहे, क्या लागत अप्रत्याशित रूप से व्यवहार करती है, क्या भावना बदल गई, और क्या उपयोगकर्ताओं ने कुछ शिप किया?
A/B परीक्षण हमें प्रोडक्शन व्यवहार पर एक नियंत्रित रीडिंग देते हैं, लेकिन समग्र मेट्रिक्स स्वयं की व्याख्या नहीं करते हैं। क्या यह एक जीत है? मूल व्यवहार परिवर्तन क्या है?
A/B परीक्षण के साथ एक चुनौती यह है कि परिणामों की व्याख्या करना कठिन है। यदि रन अवधि बढ़ जाती है, तो क्या एजेंट ने अधिक उपयोगी काम किया, या क्या वह अटक गया? यदि लागत कम हो जाती है, तो क्या हमने दक्षता में सुधार किया, या क्या एजेंट ने चुपचाप कुछ मूल्यवान करना बंद कर दिया? यदि भावना गिरती है, तो कौन से उपयोग के मामले पीछे हट गए, कौन से विफलता मोड नए हैं, और किन उपयोगकर्ताओं ने हार मान ली?
Telescope: क्या टूट रहा है
A/B परीक्षण हमें बताता है कि प्रोडक्शन व्यवहार कब बदला। Telescope — ट्रेस विश्लेषण और क्लस्टरिंग के लिए हमारी प्रणाली — यह समझाने में मदद करती है कि क्यों।
प्रोडक्शन पैमाने पर, कोई भी इंजीनियर हर ट्रेस नहीं पढ़ सकता। Telescope दोहराए गए पैटर्न को इश्यू क्लस्टर में व्यवस्थित करता है जिस पर इंजीनियर और एजेंट कार्रवाई कर सकते हैं। यह विफलता प्रक्षेपवक्र को सारांशित करता है, उन्हें एम्बेड करता है, समान मामलों को क्लस्टर करता है, और वितरण बदलने पर नए सत्रों को वर्गीकृत करता है। लक्ष्य केवल विफलताओं को गिनना नहीं है, बल्कि उन लोगों की खोज करना है जो सादे दृश्य में छिपे हुए हैं।
GIF
जिस चीज़ की हम तलाश करना नहीं जानते थे, उसे क्लस्टर करना।
Telescope Clio [7] के समान बॉटम-अप दृष्टिकोण से प्रेरित छोटे, साक्ष्य-आधारित पहलुओं का उपयोग करता है। ट्रेस के लिए, यह उपयोगकर्ता संदेशों, दृश्यमान एजेंट उत्तरों, टूल कॉल, त्रुटियों, मेटाडेटा और अन्य संदर्भ से सत्र का पुनर्निर्माण करता है। वहाँ से, Telescope सारांशित करता है कि क्या गलत हुआ, उन सारांशों को एम्बेड करता है, और उभरते हुए इश्यू समूह बनाने के लिए घनत्व-आधारित क्लस्टरिंग [8] का उपयोग करता है।
पहलू जाँच को तेज़ बनाते हैं, खासकर जब अकेले क्लस्टरिंग पर्याप्त नहीं है। जब सहायता रिपोर्ट एक व्यापक मुद्दे की ओर इशारा करती है, जैसे कि पोर्ट विफलताएँ, इंजीनियर और एजेंट पहले कॉम्पैक्ट परत खोज सकते हैं, प्रासंगिक पहलुओं का पता लगा सकते हैं, और फिर इसकी व्याख्या करने के लिए आवश्यक लॉग और अवलोकनीयता संदर्भ के साथ प्रतिनिधि सत्रों में ड्रिल कर सकते हैं।
कुल मिलाकर, वही संरचना बिखरी हुई विफलताओं को उत्पाद प्रश्नों में बदल देती है: कौन से वर्कफ़्लो हावी हैं, कौन से छोड़ दिए जाते हैं, क्या बार-बार टूटता है, और क्या कोई शमन इच्छित क्लस्टर को सिकोड़ रहा है।
इस अंतर्निहित वास्तुकला के बारे में अधिक जानकारी के लिए, Braintrust [9] में हमारे सहयोगियों से Topics पर गहन पोस्ट देखें।
लूप: साक्ष्य से एजेंट सुधार तक
एक बार माप मौजूद होने के बाद, अड़चन चलती है। ViBench, A/B परीक्षण और Telescope हमें बता सकते हैं कि क्या विफल हुआ, कहाँ विफल हुआ और यह कितनी बार हो रहा है। हमें अभी भी उस साक्ष्य को प्रशंसनीय सुधारों में बदलना है।
हम इस समस्या के समाधान के लिए एक स्व-सुधार लूप की ओर रुख करते हैं। संचालन सिद्धांत सरल है: यदि एजेंट सॉफ़्टवेयर बनाने के लिए उपयोगी हैं, तो उन्हें एजेंट को बेहतर बनाने के लिए भी उपयोगी होना चाहिए। प्रत्येक पास प्रोडक्शन लॉग, ट्रेस क्लस्टर और हाल की विफलताओं को पढ़कर शुरू होता है ताकि एक परिकल्पना मिल सके जो पीछा करने लायक हो। फिर यह एक उम्मीदवार बनाता है, संलग्न तर्क के साथ एक ड्राफ्ट PR खोलता है, ViBench, A/B परिणामों, प्रक्षेपवक्र डेटा और हाल के आधार रेखाओं के विरुद्ध परिणाम को मापता है, और सिफारिश करता है कि इसे शिप करना है, पुनरावृत्त करना है या छोड़ना है।
अनुकूलन लूप समस्याओं की खोज करता है, एजेंट परिवर्तन प्रस्तावित करता है, उनका मूल्यांकन करता है, और तय करता है कि शिप करना है, पुनरावृत्त करना है या छोड़ना है।
शिपिंग स्वचालित नहीं हो जाती। लूप साक्ष्य और पहले-पास कार्यान्वयन तैयार कर सकता है; इंजीनियर अभी भी परिणाम की समीक्षा करते हैं और लॉन्च निर्णय के मालिक होते हैं।
प्रत्येक रन रिकॉर्ड करता है कि उसने क्या प्रयास किया और क्या हुआ, जिसमें विफलताएँ भी शामिल हैं। वह रिकॉर्ड समय के साथ लूप में सुधार करता है: भविष्य के रन उस चीज़ का पुन: उपयोग कर सकते हैं जो काम कर गया, ज्ञात मृत सिरों से बच सकते हैं, और ऐसे परिवर्तन प्रस्तावित कर सकते हैं जो सामान्यीकृत होते हैं।
एजेंट पुनरावृत्ति इंजीनियरिंग नियंत्रण छोड़े बिना तेज़ हो जाती है। एक नया मॉडल, उत्पाद सतह या विश्वसनीयता लक्ष्य दिए जाने पर, लूप सक्रिय रूप से प्रॉम्प्ट एडिट, स्किल प्रस्ताव, टूल फिक्स और हार्नेस परिवर्तन पा सकता है, जबकि इंजीनियर सिस्टम को बड़े उत्पाद इष्टतम की ओर इंगित रखते हैं।
एक ठोस उदाहरण
एक हालिया रन एक छोटे लेकिन बढ़ते Telescope क्लस्टर के साथ शुरू हुआ। पर्यावरण सेटअप चुपचाप कोल्ड-स्टार्ट परिदृश्यों की एक लंबी पूंछ में खराब हो रहा था। ये सत्र समग्र मेट्रिक्स से स्पष्ट नहीं थे, लेकिन क्लस्टर ने एक पैटर्न दिखाया जो जाँच के लायक था।
पैटर्न को सतह पर लाने के बाद, लूप ने प्रभावित प्रक्षेपवक्रों को पढ़ा, एक पैच प्रस्तावित किया, एक प्रतिगमन परीक्षण जोड़ा, और यह पुष्टि करने के लिए उम्मीदवार को ViBench के विरुद्ध चलाया कि हैप्पी पाथ पीछे नहीं हटा। इंजीनियरों ने साक्ष्य की समीक्षा की, परिवर्तन को मंजूरी दी, और उसी दिन इसे प्रोडक्शन में धकेल दिया।
पैच शिप होने के बाद, भावना में सुधार हुआ और प्रभावित उपयोगकर्ता अनब्लॉक हो गए। यह वह आकार है जो हम चाहते हैं — एक लूप जो एक वास्तविक विफलता पैटर्न ढूंढता है, इसे प्रभावित उपयोगकर्ताओं से जोड़ता है, सही स्तर का फिक्स प्रस्तावित करता है, और यह तय करने के लिए पर्याप्त साक्ष्य वापस लाता है कि किसी इंसान को शिप करना है या नहीं।
जहाँ मानव स्वाद अभी भी सबसे ज्यादा मायने रखता है
इसमें से अधिकांश स्वायत्त रूप से चल सकता है: विफलताओं को क्लस्टर करना, परिकल्पनाएँ प्रस्तावित करना, उम्मीदवार बनाना, evals चलाना और साक्ष्य इकट्ठा करना। मनुष्य अभी भी दिशा निर्धारित करते हैं और अधिकांश निकास द्वारों की रक्षा करते हैं, जिनमें शामिल हैं:
- परिकल्पना चयन। एक प्रणाली हजारों विफलताओं को सतह पर ला सकती है, लेकिन मनुष्य तय करते हैं कि कौन से प्रश्न लूप के रात भर के बजट के लायक हैं। हर क्लस्टर समान रूप से महत्वपूर्ण नहीं है, और हर प्रतिगमन सही उत्पाद समस्या की ओर इशारा नहीं करता है।
- कार्यान्वयन वास्तुकला। ट्रेस दिखा सकते हैं कि उपयोगकर्ता एक वर्कफ़्लो छोड़ रहे हैं, लेकिन यह तय करना कि उस पथ को सुचारू करना है, एजेंट के व्यवहार को बदलना है या सतह को फिर से डिज़ाइन करना है, एक इंजीनियरिंग और उत्पाद निर्णय है।
- Eval क्यूरेशन। यह प्रशासनिक कार्य नहीं है; यह उस पहाड़ी को आकार देता है जिस पर एजेंट चढ़ता है। यदि eval गलत व्यवहार को पुरस्कृत करता है, तो अनुकूलन लूप ईमानदारी से गलत चीज़ की ओर अनुकूलन करेगा।
- लॉन्च अनुमोदन। एजेंट परिवर्तन शिप करना केवल एक संख्या पढ़ना नहीं है। लॉन्च अनुमोदन का अर्थ है साक्ष्य पढ़ना, ब्लास्ट रेडियस को समझना, यह तय करना कि क्या जोखिम स्वीकार्य है, और रोलआउट का स्वामित्व लेना।
वह संतुलन मायने रखता है: लूप खोज, माप और संश्लेषण का अधिक काम कर सकता है। इंजीनियर अभी भी दिशा चुनते हैं, उत्पाद कॉल करते हैं और तय करते हैं कि क्या शिप होता है।
लूप को बंद करना
मूल्यांकन अब लॉन्च से पहले सिर्फ एक गेट नहीं है। यह तय करने में मदद करता है कि क्या ठीक करना है, क्या परीक्षण करना है और क्या जारी करना है।
काम एक बेहतर संख्या उत्पन्न करना नहीं है। यह उपयोगकर्ता की विफलताओं को बेहतर रिलीज़ में बदलना है, ताकि अधिक विचार ऐसे ऐप बन सकें जिन्हें लोग प्रकाशित करने पर गर्व करें।
हम स्वायत्त एजेंटों की सीमा को आगे बढ़ाने के लिए उत्साहित हैं, सबसे जटिल कोडिंग कार्यों के लिए विश्वसनीयता पर ध्यान केंद्रित करते हुए। यदि आप स्वायत्त कोडिंग एजेंटों पर काम करने में रुचि रखते हैं, तो मैं हमेशा Replit AI टीम में भर्ती कर रहा हूँ — मुझसे [email protected] पर संपर्क करें
लेखक: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
संदर्भ
[0] AI एजेंटों के लिए सतत सीखना
[1] SWE-bench: क्या भाषा मॉडल वास्तविक दुनिया की GitHub समस्याओं का समाधान कर सकते हैं?
[2] Terminal-Bench: कमांड लाइन इंटरफेस में कठिन, यथार्थवादी कार्यों पर एजेंटों का बेंचमार्किंग
[3] ViBench: Vibe कोडिंग पर एक बेंचमार्क
[4] REPL-आधारित सत्यापन के साथ Agent 3 को बड़े पैमाने पर स्व-परीक्षण करने में सक्षम बनाना
[5] एजेंटिक कोडिंग evals में बुनियादी ढाँचे के शोर की मात्रा निर्धारित करना
[6] Replit के स्नैपशॉट इंजन के अंदर: AI एजेंटों को सुरक्षित बनाने वाली तकनीक
[7] Clio: वास्तविक दुनिया के AI उपयोग में गोपनीयता-संरक्षण अंतर्दृष्टि
[8] डेटा क्लस्टरिंग, विज़ुअलाइज़ेशन और आउटलायर डिटेक्शन के लिए पदानुक्रमित घनत्व अनुमान
[9] हमने बड़े पैमाने पर निरंतर ट्रेस इंटेलिजेंस को कैसे संभव बनाया
