इस पेज पर
संक्षिप्त उत्तर
उस कार्य से प्रारंभ करें जिसे आपके उपयोगकर्ताओं को पूरा करना है। यथार्थवादी परीक्षण मामले चुनें और लिखें कि पास का क्या मतलब है। कोड के साथ सटीक नियम जांचें. समीक्षकों से उन उत्तरों का मूल्यांकन करने के लिए कहें जिनके लिए संदर्भ की आवश्यकता है। प्रत्येक परिवर्तन का समान मामलों पर परीक्षण करें, फिर रिलीज़ से पहले गंभीर विफलताओं का निरीक्षण करें।
क्या ले जाना है
- उपयोगकर्ता के अनुरोध से लेकर अंतिम परिणाम तक संपूर्ण वर्कफ़्लो का परीक्षण करें।
- औसत स्कोर में सुधार होने पर भी, गंभीर विफलताओं को स्वयं ट्रैक करें।
- प्रत्येक स्कोर के लिए परीक्षण मामले, सिस्टम सेटिंग्स, उत्तर और कारण सहेजें।
स्रोतों की जाँच की गई . अनुसंधान संश्लेषण और रूब्रेक्स सिफारिशें। उदाहरणों और स्थानीय प्रयोगों को लेबल किया गया है; वे ग्राहक परिणाम नहीं हैं.
मार्गदर्शन क्या कहता है
एंथ्रोपिक की जनवरी 2026 गाइड एजेंट परीक्षणों को कार्यों, बार-बार चलने, स्कोरिंग नियमों और परीक्षण वातावरण में विभाजित करती है। यह एक एजेंट जो कहता है उसे वास्तव में जो करता है उससे अलग भी करता है। उदाहरण के लिए, एक एजेंट कह सकता है कि उसने एक रिकॉर्ड सहेजा है जबकि रिकॉर्ड कभी नहीं बदला। परिणाम के साथ-साथ बातचीत को भी स्कोर करें। यह एक मॉडल विक्रेता की सलाह है, यह इस बात का प्रमाण नहीं है कि हर सिस्टम के लिए एक विधि काम करती है।
वह निर्णय चुनें जिसका आपके परीक्षण को समर्थन करना चाहिए
रिलीज़ प्रश्न को एक वाक्य में लिखें। उदाहरण के लिए: क्या हमारा सहायता सहायक उस रिफंड का वादा किए बिना खाता नीति समझा सकता है जिसे वह स्वीकृत नहीं कर सकता है? यह परीक्षण को स्पष्ट उपयोगकर्ता, कार्य और जोखिम देता है। एक अस्पष्ट लक्ष्य जैसे "अधिक मददगार बनना" गलत उत्तर देने वाले सहज उत्तर को पुरस्कृत कर सकता है।
तय करें कि कितने वर्कफ़्लो का परीक्षण करना है। सारांश उपकरण के लिए एक उत्तर पर्याप्त हो सकता है। एक चैट सहायक को पूरी बातचीत की आवश्यकता हो सकती है। यदि कोई एजेंट किसी रिकॉर्ड को संपादित करता है, तो सहेजे गए रिकॉर्ड की भी जाँच करें। मॉडल संस्करण, प्रॉम्प्ट, खोज सेटिंग्स और टूल अनुमतियाँ सहेजें। इनमें से किसी में भी बदलाव से परिणाम बदल सकता है।
एक छोटा परीक्षण सेट बनाएं जिसकी आप समीक्षा कर सकें
रूब्रेक्स मामलों के तीन समूहों की सिफारिश करता है: सामान्य कार्य, किनारे के मामले और ज्ञात विफलताएँ। प्रत्येक मामले के लिए, अपेक्षित व्यवहार लिखें और परीक्षण में मामला क्यों शामिल है। सिस्टम को ट्यून करते समय कुछ मामलों को रोक कर रखें। लॉन्च का समर्थन करने के लिए स्कोर का उपयोग करने से पहले अस्पष्ट आवश्यकताओं को खोजने के लिए पहले टेस्ट रन का उपयोग करें।
आवश्यक फ़ील्ड या अनुमत रिकॉर्ड आईडी जैसे सटीक नियमों की जांच करने के लिए कोड का उपयोग करें। अर्थ, लुप्त विवरण और ईमानदार अनिश्चितता के लिए स्कोरिंग गाइड का उपयोग करें। समीक्षकों से स्वयं एक छोटा सा साझा सेट स्कोर करने के लिए कहें। अधिक मामलों में स्वचालित न्यायाधीश पर भरोसा करने से पहले चर्चा करें कि वे कहाँ असहमत हैं। उन मामलों को रखें जिन्हें रिपोर्ट में स्कोर नहीं किया जा सकता और कारण बताएं।
- मूल संस्करण और विफल अनुरोधों सहित प्रत्येक उत्तर को सहेजें।
- परिवर्तित संस्करण को समान इनपुट और सीमा पर चलाएँ।
- उन मामलों का निरीक्षण करें जो बेहतर हो गए और जो मामले बदतर हो गए।
- प्रत्येक विफलता दें जो किसी नामित स्वामी को रिलीज़ करने से रोकती है।
उदाहरण: एक सहायक जो नीति समझाता है
मान लीजिए कि एक सहायक को वर्तमान नीति का हवाला देना चाहिए, अपवादों की व्याख्या करनी चाहिए, और अनुमोदन का वादा करने से बचना चाहिए। यह पहले दो नियमों को पूरा कर सकता है लेकिन फिर भी धन वापसी का वादा करके विफल हो जाता है। प्रत्येक नियम को स्कोर करें ताकि टीम समस्या का पता लगा सके। यह भी रिकॉर्ड करें कि क्या उत्तर हर आवश्यक नियम पर खरा उतरा है।
अब मान लीजिए कि एक नया प्रॉम्प्ट उद्धरणों को ठीक करता है लेकिन अधिक असमर्थित वादे करता है। यह एक मिश्रित परिणाम है. वादों के उद्देश्य से किए गए बदलाव का परीक्षण करें, फिर नई विफलताओं की जांच के लिए पहले के मामलों को दोबारा चलाएं। यह एक उदाहरण परीक्षण योजना है, रूब्रेक्स क्लाइंट का परिणाम नहीं।
अगले इंजीनियर को परीक्षण दोबारा चलाने के लिए पर्याप्त समय दें
मामले, स्कोरिंग नियम, सिस्टम संस्करण और मूल उत्तर साझा करें। विफलताओं को कारण के आधार पर समूहित करें और जो अभी भी अज्ञात है उसे स्पष्ट करें। परीक्षण को दोबारा चलाने और लॉन्च के बाद मिली विफलता को जोड़ने के चरण शामिल करें। किसी अन्य इंजीनियर को लेखक के स्लाइड डेक की आवश्यकता के बिना निर्णय की जांच करने में सक्षम होना चाहिए। जब सबूत निर्णय लेने के लिए बहुत कमज़ोर हो, तो गायब डेटा और अगले परीक्षण का नाम बताएं।
रिकॉर्ड करें कि प्रत्येक अंक का क्या अर्थ है
ऐसे उपाय चुनें जो रिलीज़ प्रश्न का उत्तर दें। एक सहायता सहायक के लिए, रुब्रेक्स गलत उत्तरों, असमर्थित दावों, पूर्ण किए गए कार्यों और एक उपयोगी उत्तर की लागत पर नज़र रखने की अनुशंसा करता है। बताएं कि प्रत्येक गिनती में क्या शामिल है। 100 उत्तरों में से दस असफल उत्तरों का मतलब 100 सत्रों में से दस असफल उत्तरों से कुछ अलग है। उन अनुरोधों को शामिल करें जिनका कोई उत्तर नहीं आया।
एक परीक्षण एक आवश्यकता की जाँच करता है। एक परीक्षण सूट कई आवश्यकताओं और तरीकों की जाँच करता है जिनसे सिस्टम विफल हो सकता है। अपने आवेदन परिणामों को सार्वजनिक मॉडल बेंचमार्क स्कोर से अलग रखें। पुराने और नए संस्करणों, परीक्षण किए गए मामलों, स्कोर परिभाषाओं और रिलीज़ को अवरुद्ध करने वाली विफलताओं के साथ एक संक्षिप्त निर्णय रिकॉर्ड लिखें। उस व्यक्ति का नाम बताएं जिसके पास अगला परीक्षण है।
साक्ष्य की सीमाएँ
एक परीक्षण सेट आपके सिस्टम को प्राप्त होने वाले केवल कुछ इनपुट को कवर करता है। इसमें उत्तीर्ण होना यह सिद्ध नहीं करता कि भविष्य का प्रत्येक उत्तर सुरक्षित या सही होगा। यह वर्कफ़्लो रूब्रेक्स का अनुशंसित प्रारंभिक बिंदु है। यह प्रकाशित मार्गदर्शन द्वारा सूचित किया गया है, न कि किसी सार्वभौमिक रिलीज़ मानक द्वारा।
सामान्य प्रश्न
क्या सभी आउटपुट को मानवीय समीक्षा की आवश्यकता है?
नहीं, कोड सटीक नियमों की जांच कर सकता है। लोगों को उन उत्तरों की समीक्षा करनी चाहिए जो अस्पष्ट हैं या जिनके गंभीर परिणाम हो सकते हैं। आपके स्केल बढ़ाने से पहले जांच लें कि समीक्षक स्कोरिंग नियमों पर सहमत हैं या नहीं।
क्या एक अच्छा बेंचमार्क स्कोर किसी एप्लिकेशन को तैयार करता है?
नहीं। एक सार्वजनिक बेंचमार्क आपके डेटा, उपयोगकर्ता वर्कफ़्लो, टूल अनुमतियों, या उत्तीर्ण उत्तर के लिए नियमों का परीक्षण नहीं करता है।
स्रोत और आगे पढ़ना
इस ब्रीफिंग के पीछे प्राथमिक स्रोत। किसी स्रोत के निष्कर्ष उसकी अपनी अध्ययन स्थितियों पर लागू होते हैं; arXiv पर प्रकाशन सहकर्मी समीक्षा स्थापित नहीं करता है।
- एआई एजेंटों के लिए रहस्यों को उजागर करना मानवशास्त्रीय · 2026 · इंजीनियरिंग मार्गदर्शनसमीक्षित: तकनीकी लेख. पहुँच गया 25 सित॰ 2026.
प्रश्न या सुधार? रूब्रेक्स को लिखें. हमारा संपादकीय दृष्टिकोण पढ़ें.