भरोसेमंद थर्ड पार्टी इवैल्यूएशन के लिए एक शेयर्ड प्लेबुक

व्यक्तिगत, भरोसेमंद थर्ड पार्टी इवैल्यूएशन सुरक्षा इकोसिस्टम को मज़बूत बनाने में महत्वपूर्ण भूमिका⁠ निभाते हैं. ये इवैल्यूएशन अत्याधुनिक मॉडल पर किए जाते हैं ताकि महत्वपूर्ण क्षमताओं और सुरक्षा उपायों से जुड़े क्लेम के लिए अतिरिक्त सबूत दिए जा सकें. इस पोस्ट में, हम अब तक सीखे गए सबक शेयर करते हैं, और ऐसे इवैल्यूएशन डिज़ाइन करने के तरीकों का सुझाव देते हैं जो अत्याधुनिक मॉडल को मान्य तौर से समझ सकें और जिनसे हमें उम्मीद है कि इस क्षेत्र में उभरते स्टैंडर्ड को दिशा मिलेगी.

पहले, कई इवैल्यूएशन मॉडल को चैटबॉट की तरह मानते थे: इवैल्यूएशन किसी मॉडल को ऐसे प्रॉम्प्ट देता था मानो कोई यूज़र सवाल पूछ रहे हों, मॉडल जवाब देता था, और इवैल्यूएशन करने वाले आउटपुट का निर्णय करने थे. आज के अत्याधुनिक मॉडल इससे कहीं ज़्यादा कर सकते हैं: वे टूल्स का इस्तेमाल कर सकते हैं, कई स्टेप में जानकारी का हिसाब रख सकते हैं, और बड़े वर्कफ़्लो में काम कर सकते हैं. इसका मतलब है कि परफ़ॉर्मेंस सिर्फ़ मॉडल पर ही नहीं, बल्कि उस एनवायरमेंट पर भी निर्भर करता है जिसमें टास्क होता है, और उस सेटअप पर भी जो उसके एक्शन को मुमकिन बनाता है. यह आसपास का सेटअप, जिसे हम “हार्नेस” कहते हैं, सिस्टम के परफ़ॉर्मेंस के मुख्य पहलुओं को बदल सकता है, जिनमें यह शामिल है कि वह टूल्स का इस्तेमाल कैसे करता है, जानकारी का हिसाब कैसे रखता है, या गलतियों से कैसे उबरता है.

इससे यह बदल जाता है कि इवैल्यूएशन कैसे किए जाने चाहिए, और इवैल्यूएशन रिपोर्ट में पढ़ने वालों को किन बातों पर ध्यान देना चाहिए. हमारे विचार में, सबसे उपयोगी रिपोर्ट नतीजों के अलावा दो बातों को स्पष्ट तौर पर बताती हैं: पहला, वे बताती हैं कि इवैल्यूएशन सेटअप किस क्लेम की जाँच के लिए बनाया गया था, और दूसरा, वे उपलब्ध सबूत शेयर करती हैं कि इवैल्यूएशन का नतीजा मान्य है.

इवैल्यूएशन में टेस्ट किए जाने वाले क्लेम आम तौर पर तीन बकेट में से किसी एक के तहत आते हैं¹:

• क्षमता एलिसिटेशन: क्या कोई मॉडल विश्वसनीय तौर से इवैल्यूएशन की जा रही क्षमता बना सकता है? 
• सेफ़गार्ड की परफ़ॉर्मेंस: टेस्ट किए गए सेफ़गार्ड इवैल्यूएशन किए जा रहे व्यवहार या हमले की तुलना में कितने मज़बूत हैं?
• तुलना: समान परिस्थितियों में अलग-अलग मॉडल कैसा परफ़ॉर्म करते हैं?

इवैल्यूएशन रिपोर्ट को यह भी समझाना चाहिए कि इवैल्यूएशन करने वालों ने उन प्रभावों की जाँच कैसे की जो किसी नतीजे की मान्यता पर असर कर सकते हैं. इनमें शामिल हैं:

• रिवॉर्ड हैकिंग: टास्क या स्कोरर में मौजूद शॉर्टकट का फ़ायदा उठाना, ताकि सिस्टम को उस व्यवहार को दिखाए बिना क्रेडिट मिल जाए जिसे इवैल्यूएशन मेजर करना चाहता है.
• इंकार: ऐसे तरीकों से इंकार करना जो टेस्ट किए जा रहे व्यवहार को छिपा दें.
• कंटैमिनेशन: बेहतर परफ़ॉर्म इसलिए हो रहा है, क्योंकि इवैल्यूएशन टास्क, जवाब या उनके मिलते-जुलते वेरिएंट ट्रेनिंग डेटा में मौजूद थे, या इवैल्यूएशन के दौरान उन्हें खोजा जा सकता था, जैसे कि ब्राउज़िंग के ज़रिए.
• टूटी हुई समस्याएँ: इस वजह से कम परफ़ॉर्म करना क्योंकि टास्क अमान्य हैं. कारणों में अनुचित स्कोरिंग शामिल हो सकती है, (जैसे सही जवाब के लिए अनकही इम्प्लीमेंटेशन की जानकारी चाहिए), और ऐसे एनवायरमेंट जो हल नहीं किए जा सकते, (जैसे कि ज़रूरी फ़ाइलों का गायब होना या अविश्वसनीय टूल्स).
• सैंडबैगिंग: जब वे यह जागरूकता दिखाते हैं कि उनका इवैल्यूएशन हो रहा है, तब जानबूझकर कम परफ़ॉर्म करना.

हमने देखा है कि लंबे ट्रैजेक्टरी पर काम करने वाले सिस्टम के लिए हार्नेस की भूमिका ख़ास तौर से ज़रूरी होती है. जब मॉडल टूल्स का इस्तेमाल कर सकते हैं, स्थिति बनाए रख सकते हैं, और कई स्टेप में गलतियों से उबर सकते हैं, तब हार्नेस देखे गए परफ़ॉर्मेंस लेवल को बदल सकता है, और यह भी तय कर सकता है कि अनुमान लगाई जा रही क्षमता इवैल्यूएशन में दिखाई भी देगी या नहीं. उदाहरण के लिए, ऐसा हार्नेस जो स्थिति को सुरक्षित रखता है और असफ़ल एक्शंस को फिर से आज़माता है, किसी मॉडल को मल्टी-स्टेप वाला टास्क पूरा करने दे सकता है, जबकि वही मॉडल सरल हार्नेस में उसे कभी पूरा नहीं कर पाता.

नीचे दिए गए टेबल में, हम उन तीन प्रकार के क्लेम को अलग करते हैं जिन्हें इवैल्यूएशन करने वाले करना चाह सकते हैं, और वह हार्नेस जिसे हम मानते हैं कि हर प्रकार के क्लेम के लिए ज़रूरी है.

क्षमता संबंधी क्लेम उतने ही मज़बूत होते हैं जितना उनके पीछे का एलिसिटेशन: इवैल्यूएशन करने वालों को ऐसा हार्नेस चुनना चाहिए जो टास्क और उस क्षमता के लिए सबसे उपयुक्त हो जिसे इवैल्यूएशन मेजर करना चाहता है. समान परिस्थितियों में सिस्टम की तुलना के लिए स्टैंडर्ड हार्नेस सही हो सकता है, लेकिन अगर वह उन ख़ास हार्नेस फ़ीचर को छोड़ देता है जो मॉडल को टास्क करने में मदद करते हैं, तो वह क्षमता को कम करके दिखा सकता है. उदाहरण के लिए, OpenAI की साइबर रेंज पर GPT‑5.5 का परफ़ॉर्मेंस दिखाता है कि हार्नेस का चुनाव उन टास्क पर मेजर की गई क्षमता को वास्तविक तौर से बदल सकता है जिनमें लंबे, मल्टी-स्टेप टूल इस्तेमाल करने की ज़रुरत होती है: जब हार्नेस कॉम्पैक्शन⁠ का इस्तेमाल करके इंटरैक्शन लंबी होने पर टास्क-संबंधित संदर्भ को सुरक्षित रखता है, तब मॉडल बेहतर परफ़ॉर्म करता है. यह दर्शाता है कि कुछ मॉडल के लिए, ऐसा हार्नेस जो कॉम्पैक्शन को छोड़ दे, परफ़ॉर्मेंस को पर्याप्त तौर से सामने नहीं ला पाएगा.

दूसरे पब्लिश किए गए इवैल्यूएशन² भी दिखाते हैं कि हार्नेस और बजट के विकल्प इवैल्यूएशन नतीजों को बदलते हैं. टेस्ट के समय का कंप्यूट बढ़ाने से यह काफ़ी बदल सकता है कि कोई इवैल्यूएशन किस क्षमता को सामने लाता है, ख़ासकर उन क्षेत्रों में जहाँ सफ़लता को वेरिफ़ाई करना आसान होता है, जैसे कई साइबर टास्क. UK AISI के साइबर रेंज इवैल्यूएशन⁠(एक नई विंडो में खुलेगा) में, बजट को 10 मिलियन से 100 मिलियन टोकन तक बढ़ाने से परफ़ॉर्मेंस में 59% तक सुधार हुआ, और टेस्ट किए गए सबसे ज़्यादा बजट पर भी परफ़ॉर्मेंस बढ़ रहा था. इसकी जानकारी देने से इवैल्यूएशन को समझना आसान हो जाता है: यह पढ़ने वालों को दिखाता है कि नतीजा टेस्ट किए गए एलिसिटेशन सेटअप पर कैसे निर्भर करता है. जब अतिरिक्त बजट के साथ परफ़ॉर्मेंस में अभी भी सुधार हो रहा हो, तो स्कोर को उस हार्नेस और बजट के तहत परफ़ॉर्मेंस के तौर पर बताया जाना चाहिए, न कि मेजर की गई क्षमता की ऊपरी सीमा के तौर पर. क्षमता अक्सर रिसोर्स पर निर्भर होती है, न कि कोई फ़िक्सड मात्रा जिसे एक बार में साफ़-साफ़ मेजर किया जा सके. जहाँ बार-बार प्रयासों में सफ़लता मेजर की जा सकती हो, वहाँ रिपोर्ट को सिर्फ़ फ़िक्सड टोकन बजट पर सफ़लता दर ही नहीं, बल्कि प्रति सफ़ल समाधान उम्मीद किए गए कॉस्ट पर भी विचार करना चाहिए. इससे गंभीरता को समझना आसान हो सकता है: कम सफ़लता दर भी व्यवहारिक तौर से मायने रख सकती है अगर बार-बार प्रयासों की लागत उपयुक्त ख़तरे के मॉडल के अंदर हो. क्षमता संबंधी क्लेम के लिए, टाली जा सकने वाली कम-एलिसिटेशन एक मेजरमेंट संबंधी असफ़लता है: अगर हार्नेस या बजट सिस्टम को ऐसा व्यवहार दिखाने से रोकता है जिसे वह अन्यथा उत्पन्न कर सकता था, तो स्कोर क्लेम की गई क्षमता को नहीं मेजर करता. जहाँ इवैल्यूएशन करने वालों ने एलिसिटेशन को व्यवहार्य सीमा तक आगे बढ़ाया हो और परफ़ॉर्मेंस फिर भी सुधर रहा हो, वहाँ रिपोर्ट को यह स्पष्ट तौर से कहना चाहिए और यह भी स्पष्ट करना चाहिए कि नतीजा सिर्फ़ निचली-सीमा का अनुमान है.

सेफ़गार्ड टेस्टिंग इस बात को कम करके दिखा सकती है कि कोई हमला सफ़ल हो सकता है या नहीं, और वह कितना गंभीर हो सकता है, अगर हमलावरों के लिए उपलब्ध रिसोर्स, जिनमें कस्टम हार्नेस भी शामिल हैं, को ध्यान में न रखा जाए. UK AISI के GPT‑5.5 साइबर इवैल्यूएशन⁠(एक नई विंडो में खुलेगा) में, उनकी एक्सपर्ट रेड टीमिंग ने एक यूनिवर्सल जेलब्रेक पाया जिसने OpenAI द्वारा दी गई नुकसानदेह क्वेरीज़ में, मल्टी-टर्न एजेंटिक सेटिंग्स सहित, उल्लंघन करने वाले साइबर कंटेंट को सामने ला दिया. उन्होंने मॉडल के हमले के परफ़ॉर्मेंस को मज़बूत करने के लिए Codex का इस्तेमाल कर के एक कस्टम हार्नेस बनाया: इसने इंटरैक्शन में एक दोबारा इस्तेमाल हो सकने वाला 'सेफ़गार्ड-बाईपास पैटर्न' डाल दिया, उस पैटर्न को अलग-अलग टर्न और ब्लॉक में बनाए रखा, और OpenAI द्वारा दी गई नुकसानदेह साइबर क्वेरीज़ पर इसे लागू किया. सेफ़गार्ड टेस्टिंग विरोधी के हिसाब से होनी चाहिए. अगर यह क्लेम किया जाता है कि सिस्टम एक्सपर्ट द्वारा किए जाने वाले गलत इस्तेमाल के प्रति मज़बूत है, तो टेस्टिंग में एक तय बजट के अंदर सबसे मज़बूत और विश्वसनीय 'एंड-टू-एंड' हमले की रणनीति का इवैल्यूएशन किया जाना चाहिए; इसमें उस रणनीति को सुरक्षित रखने और दोबारा इस्तेमाल करने के लिए ज़रूरी कोई भी हार्नेस शामिल होना चाहिए. वरना, नतीजों के गलत आकलन का रिस्क रहता है: वे सिर्फ़ आसान प्रॉम्प्टिंग के प्रति रेज़िस्टेंस के बारे में एक हल्के क्लेम को ही सपोर्ट कर सकते हैं; वे इस बात को नज़रअंदाज़ कर सकते हैं कि एलिसिटेशन का तरीका लागू हो जाने पर हमला कितना गंभीर हो जाता है और उसके सफ़ल होने की कितनी संभावना होती है; और अगर बहुत ज़्यादा बजट दिया जाए, तो वे किसी समस्या के होने की संभावना या उसकी गंभीरता को भी बढ़ा-चढ़ाकर बता सकते हैं.

स्टैंडर्ड हार्नेस तुलनाओं का भी सही समय और स्थान होता है, लेकिन इवैल्यूएशन करने वालों को यह स्पष्ट होना चाहिए कि हार्नेस के एक ही सेट का इस्तेमाल करना क्यों उचित है और यह किस क्लेम को सपोर्ट कर सकता है. METR का time-horizon इवैल्यूएशन⁠(एक नई विंडो में खुलेगा) एक व्यापक, उचित तौर से फ़िक्स्ड इवैल्यूएशन सेटअप का उदाहरण है: इसे उन सिस्टम के बीच तुलना वाले नतीजे देने के लिए डिज़ाइन किया गया है जिनका यह इवैल्यूएशन करता है. METR एक सामान्य नतीजे के बारे में बताता है, यानी मानव टास्क की वह सामान्य अवधि जिस पर किसी AI एजेंट के किसी दिए गए विश्वसनीयता लेवल पर सफ़ल होने की भविष्यवाणी की जाती है. यह शेयर्ड टास्क सुइट, स्कोरिंग के तरीके, फ़िटिंग के तरीके, और साथ में रिपोर्ट किए गए हर अनुमान-समूह के अंदर Triframe and ReAct⁠(एक नई विंडो में खुलेगा) जैसे दोबारा इस्तेमाल करने योग्य स्कैफ़ोल्ड्स के एक छोटे सेट को लागू करता है. जब METR ने टास्क सुइट को बढ़ाया और इवैल्यूएशन इंफ़्रास्ट्रक्चर को Vivaria नामक फ़्रेमवर्क से Inspect नामक फ़्रेमवर्क में बदला, तो उसने इस बदलाव की रिपोर्ट की (Time Horizon 1.1 अपडेट⁠(एक नई विंडो में खुलेगा)) और नए इवैल्यूएशन सेटअप के तहत मॉडल का दोबारा इवैल्यूएशन किया. यही स्टैंडर्ड इवैल्यूएशन सेटअप का मूल्य है, जिसमें एक जैसा हार्नेस सेट भी शामिल हो: यह पढ़ने वालों को भरोसा दिला सकता है कि स्कोर में अंतर असल में तुलना किए जा रहे सिस्टम के बीच का अंतर दर्शाता है, न कि मेजरमेंट सेटअप में किसी बदलाव का.

हम सुझाव देते हैं कि थर्ड पार्टी इवैल्यूएशन रिपोर्ट यह बताएं कि उनका इवैल्यूएशन सेटअप किस तरह के क्लेम को सपोर्ट करने के लिए बनाया गया है; यह बताएँ कि जो टेस्ट किया गया था वह उस व्यापक क्लेम को कितनी निकटता से दर्शाता है; उन हार्नेस विकल्पों के बारे में बताएँ जिन्होंने नतीजे को आकार दिया; यह विस्तार से बताएँ कि इवैल्यूएशन के बीच वे विकल्प कब बदलते हैं; और यह दिखाने के लिए सहायक सबूत शामिल करें कि नतीजा कैसे उत्पन्न हुआ और वह क्लेम पर कितनी अच्छी तरह लागू होता है.

जैसे-जैसे मॉडल ज़्यादा काबिल होते जाते हैं, इवैल्यूएशन स्कोर की गलत व्याख्या करना आसान होता जाता है. वास्तविक क्षमताओं की तुलना में, अगर कोई मॉडल यह पहचान ले कि उसका इवैल्यूएशन हो रहा है और रणनीतिक तौर से कम परफ़ॉर्म करे, तो इवैल्यूएशन स्कोर आर्टिफ़िशियल तरीके से कम हो सकते हैं. अगर मॉडल टास्क, प्रॉम्प्ट, स्कोरर, या हार्नेस में किसी शॉर्टकट का फ़ायदा उठाए, तो वे बढ़ भी सकते हैं. वे कंटैमिनेशन से भी ख़राब हो सकते हैं, (जहाँ मॉडल पहले से जवाब जानता हो या टास्क हल किए बिना उसे ढूँढ सकता हो), या “टूटी हुई” समस्याओं से जो अस्पष्ट, गलत स्कोर की गई, हल नहीं होने वाली, या इरादे न किए गए शॉर्टकट्स के प्रति संवेदनशील हों. इसलिए इवैल्यूएशन रिपोर्ट को मुख्य स्कोर के साथ इन ख़तरों पर चर्चा भी जोड़नी चाहिए, ताकि पढ़ने वाले समझ सकें कि स्कोर इरादा किए गए व्यवहार को दर्शाते हैं या नहीं.

हार्नेस, बजट, टूल्स, स्कोरिंग के नियम, मॉनिटर, और रिव्यु की प्रक्रियाएँ सभी इस बात पर असर करती हैं कि कोई एजेंट इरादा किया गया टास्क हल कर रहा है, उससे बच रहा है, उसे याद से दोहरा रहा है, या उसके आसपास कोई रास्ता खोज रहा है. एक भरोसेमंद रिपोर्ट इन जाँच को स्पष्ट तौर से दिखाती है: इवैल्यूएशन करने वालों को हर बार असेसमेंट किए जाने पर, इन व्यवहारों के सैंपल को रिव्यु करना चाहिए.

रिवॉर्ड हैकिंग

रिवॉर्ड हैकिंग का मतलब है ऐसे तरीकों से ज़्यादा इवैल्यूएशन स्कोर पाना जो इरादे वाली क्षमता को नहीं दर्शाते. यहाँ चिंता यह है कि सिस्टम टास्क, स्कोरर, प्रॉम्प्ट, या हार्नेस का फ़ायदा उठाकर क्रेडिट पाता है, न कि वह काम करके जिसे इवैल्यूएशन मेजर करना चाहता था. GPT 5.4 का METR इवैल्यूएशन⁠(एक नई विंडो में खुलेगा) दिखाता है कि यह क्यों मायने रखता है: पहली नज़र में मॉडल उन टास्क पर ऐसी दर से सफ़ल हुआ जो लगभग 13-घंटे के टाइम होराइज़न के तौर पर होती, लेकिन मानव रिव्यु ने दिखाया कि उन सफ़लताओं में से कुछ रिवॉर्ड हैकिंग से आई थीं, और सिर्फ़ बिना रिवॉर्ड हैकिंग वाली घटनाओं को ध्यान में रखकर नतीजे बेहतर करने पर अनुमान लगभग 6 घंटे तक घट गया. इवैल्यूएशन करने वालों को ऐसे एडजस्टमेंट की ज़रुरत को समझना चाहिए और, जब उनकी ज़रूरत हो, उन्हें स्पष्ट तौर से रिपोर्ट करना चाहिए: क्षमता का अनुमान तब कहीं ज़्यादा उपयोगी होता है जब पढ़ने वाले देख सकें कि कौन-सी दिखने वाली सफ़लताएँ अयोग्य ठहराई गईं, क्यों ठहराई गईं, और नतीजा उस निर्णय पर कितना निर्भर करता है.

इंकार

मॉडल सेफ़गार्ड की वजह से क्षमता इवैल्यूएशन में कम परफ़ॉर्म भी कर सकते हैं. कोई मॉडल इवैल्यूएशन टास्क को पूरा करने के बजाय उनसे इंकार करने के कारण अपनी असल क्षमता से कम इवैल्यूएशन परफ़ॉर्मेंस दिखा सकता है. इसलिए रिपोर्ट को यह समझाना चाहिए कि क्या इंकार इवैल्यूएशन नतीजों का हिस्सा थे और अगर हाँ, तो उनकी वजह से कितने सैंपल ख़राब हुए.

कंटैमिनेशन

कंटैमिनेशन सार्वजनिक या दोबारा इस्तेमाल किए गए बेंचमार्क⁠ के लिए सबसे ज़्यादा मायने रखता है. अगर टास्क, जवाब या उनके मिलते-जुलते वेरिएंट ट्रेनिंग डेटा में मौजूद हों या ब्राउज़िंग के ज़रिए एजेंट द्वारा पाए जा सकें, तो परफ़ॉर्मेंस मॉडल की क्षमता के बजाय याददाश्त या वापस पाए जाने को दर्शा सकता है. जहाँ मुमकिन हो, इवैल्यूएशन करने वालों को निजी या नए बनाए गए टास्क को प्राथमिकता देनी चाहिए और यह जाँचना चाहिए कि मॉडल समाधान से पहले टास्क-विशिष्ट जानकारी को दोहरा तो नहीं रहे.

टूटी हुई समस्याएँ

'टूटी हुई समस्याओं' में ऐसी स्थितियाँ शामिल होती हैं, जैसे कि कोई ऐसी समस्या जिसे गलती से हल नहीं किया जा सकता. टूटी हुई समस्याएँ इतनी आम हैं⁠(एक नई विंडो में खुलेगा) कि उन्हें मान्यता के एक स्टैंडर्ड रिस्क के तौर पर माना जाना चाहिए. इनमें गलत ग्राउंड ट्रुथ, अस्पष्ट प्रॉम्प्ट्स, गायब फ़ाइलें, अस्थिर सेवाएँ, अनुचित स्कोरिंग क्राइटेरिया, और ऐसे एनवायरमेंट शामिल हैं जो छिपी हुई जवाब वाली फ़ाइलों या ग्राउंड-ट्रुथ पैच वाले रिपॉज़िटरी हिस्ट्री जैसे शॉर्टकट्स को सामने लाते हैं.

सैंडबैगिंग

किसी मॉडल या सिस्टम द्वारा सैंडबैगिंग का मतलब है रणनीतिक तौर से कम परफ़ॉर्म करना, जब मज़बूत परफ़ॉर्मेंस किसी उद्देश्य से बिल्कुल अलग हो. Apollo के GPT‑5.5 इवैल्यूएशन⁠(एक नई विंडो में खुलेगा) ने इसका टेस्ट ऐसा संदर्भ बनाकर किया जिसमें मॉडल समझता था कि ज़्यादा इवैल्यूएशन स्कोर अन-लर्निंग को ट्रिगर कर सकते हैं या डिप्लॉयमेंट को ब्लॉक कर सकते हैं. GPT‑5.5 ने फिर भी सही जवाब दिए, जो रणनीतिक कम-परफ़ॉर्मेंस के बहुत कम व्यवहारिक सबूत का संकेत देता है³. लेकिन रीज़निंग निशान ने उन के रिव्यु ने ज़रूरी संदर्भ जोड़ा: Apollo को सैंडबैगिंग-कंडीशन के 52% सैंपल में अलाइनमेंट-इवैल्यूएशन जागरूकता के मध्यम या उससे ज़्यादा संकेत मिले, जबकि काउंटरफ़ैक्चुअल्स में यह 0% था. यह सबूत नतीजों को समझना थोड़ा पेचीदा बना देता है, लेकिन आख़िरकार पढ़ने वालों को ज़्यादा स्पष्ट संकेत देता है: पढ़ने वाले एक तरफ़ तो आश्वस्त करने वाले व्यवहारिक नतीजे देख सकते हैं, और दूसरी तरफ़, उस नतीजे की ज़्यादा समझ के प्रति सतर्क रहने की वजह को भी समझ सकते हैं.

मज़बूत क्लेम के लिए व्यवहार को सामने लाने वाला सही हार्नेस और यह दिखाने वाली वैधता-जाँच, दोनों आवश्यक हैं कि परिणाम ठोस है. हमारा यह नज़रिया कि हार्नेस और वैधता-जाँच इवैल्यूएशन नतीजे का हिस्सा हैं, इस बात को आकार देता है कि हम व्यवहार में थर्ड पार्टी इवैल्यूएशन को कैसे सपोर्ट करते हैं: 

• हम इवैल्यूएशन करने वालों के साथ विशिष्ट ज़्यादा से ज़्यादा एलिसिटेशन मार्गदर्शन शेयर कर रहे हैं.
• हम क्षमता इवैल्यूएशन करने वालों से कह रहे हैं कि वे OpenAI मॉडल के लिए Codex को एक सामान्य आधार के तौर पर इस्तेमाल करें: टेस्ट को कम-से-कम उसी एजेंटिक इंटरफ़ेस के ज़रिए एक बेसलाइन चलानी चाहिए जिस पर यूज़र निर्भर होने की संभावना रखते हैं, न कि सिर्फ़ एक सीमित मॉडल इंटरफ़ेस के ज़रिए.
• हम रीज़निंग की पहचान और दूसरे इंटरमीडिएट आर्टिफ़ैक्ट्स भी वहाँ उपलब्ध करा रहे हैं जहाँ धोखे, सैंडबैगिंग, या इवैल्यूएशन की जागरूकता को समझने के लिए उनकी ज़रुरत होती है. METR और Apollo ने GPT‑5 के बाद से OpenAI इवैल्यूएशन में इस एक्सेस का इस्तेमाल किया है. 
• आख़िरकार, हम इस बात को ज़्यादा गहराई से समझने के लिए रिसर्च को प्राथमिकता दे रहे हैं कि हार्नेस के विकल्प कब और कैसे नतीजों को वास्तविक तौर से बदलते हैं, कॉन्टेक्स्ट मैनेजमेंट और टूल एक्सेस से लेकर व्यवहार को दोबारा आज़माने, स्कोरिंग, और रिसोर्स के बजट तक.

इन सुझाव का उद्देश्य सिर्फ़ व्यक्तिगत इवैल्यूएशन रिपोर्ट को बेहतर बनाना नहीं है, बल्कि अत्याधुनिक AI इवैल्यूएशन और रिपोर्टिंग के लिए उभरते राष्ट्रीय ⁠(एक नई विंडो में खुलेगा)और अंतरराष्ट्रीय ⁠(एक नई विंडो में खुलेगा)स्टैंडर्ड को भी दिशा देना है. आगे चलकर, थर्ड पार्टी इवैल्यूएशन स्टैंडर्ड को इतनी जानकारी की ज़रुरत होनी चाहिए कि निर्णय लेने वाले समझ सकें कि ख़ास इवैल्यूएशन किन क्लेम को सपोर्ट करते हैं, किस सिस्टम को टेस्ट किया गया, नतीजा कैसे सामने लाया गया, और इवैल्यूएशन करने वालों ने उसकी मान्यता की जाँच कैसे की. अत्याधुनिक सिस्टम के लिए, जिनका टेस्ट ऐसे टास्क पर हो रहा है जहाँ एजेंटिक क्षमताएँ मायने रखती हैं, जानकारी में यह शामिल होना चाहिए (किसी भी सुरक्षा या गोपनीयता संबंधी चिंताओं के अधीन):

• क्लेम: क्या इवैल्यूएशन सिस्टम की तुलना करता है, क्षमता की ऊपरी सीमा का अनुमान लगाता है, या सेफ़गार्ड को टेस्ट करता है.
• इवैल्यूएशन कंटेंट: टास्क या टास्क-डिस्ट्रीब्यूशन के बारे में इतनी जानकारी की पढ़ने वाले समझ सकें कि इवैल्यूएशन असल में किन स्किल, व्यवहार या असफ़लता मोड की टेस्टिंग कर रहा है.
• टेस्ट किया गया सिस्टम: मॉडल, रीज़निंग सेटिंग, टूल एक्सेस, हार्नेस और सेफ़गार्ड.
• बजट: टर्न, टोकन, प्रयास/दोबारा कोशिश, वास्तविक समय, इन्फ़रेंस कॉस्ट, और जहाँ लागू हो प्रति सफ़ल समाधान उम्मीद किया गया कॉस्ट.
• एलिसिटेशन के तरीके: नतीजे को सामने लाने के लिए इस्तेमाल किए गए हार्नेस विकल्प, और जो टेस्ट किया गया था वह किए जा रहे व्यापक क्लेम को कितने करीब से दर्शाता है.
• मान्यता-जाँच: समझने वालों ने रिवॉर्ड हैकिंग, इवैल्यूएशन की जागरूकता, कंटैमिनेशन, इंकार, सैंडबैगिंग और दूसरे ऐसे व्यवहारों को कैसे खोजा जो नतीजे को कमज़ोर कर सकते थे, जिसमें यह भी शामिल है कि कंफ़र्म किए गए मामलों ने स्कोरिंग या व्याख्या पर कैसे असर किया.

वे स्टैंडर्ड जो हार्नेस विकल्पों या मान्यता जाँच को छोड़ देते हैं, किसी सिस्टम की क्षमता को कम करके दिखा सकते हैं या किसी सुरक्षा क्लेम पर भरोसे को बढ़ा-चढ़ाकर दिखा सकते हैं. मज़बूत हार्नेस और एलिसिटेशन के तरीके बनाना अभी भी एक खुला रिसर्च क्षेत्र है और आगे की जाँच और निवेश का केंद्र होना चाहिए.