“दूसरा उत्तर पढ़ने में बेहतर लगता है” एक ईमानदार धारणा है। लेकिन इससे अभी यह पता नहीं चलता कि कोई स्किल अपना काम बेहतर करती है या नहीं। हो सकता है नया सारांश छोटा हो और इस बीच उसने एकमात्र महत्वपूर्ण शर्त ही छोड़ दी हो। इसलिए जो कोई भी किसी स्किल को बेहतर बनाना चाहता है, उसे अपनी रुचि से बाहर किसी संदर्भ बिंदु की आवश्यकता होती है।
Anthropic का skill-creator ड्राफ़्ट, कार्यों, मूल्यांकन और संशोधन के एक पुनरावृत्त मार्ग का वर्णन करता है। शुरुआत के लिए इससे एक छोटी तुलना निकाली जा सकती है। निम्नलिखित परीक्षण व्यवस्था और उसका नमूना डेटा हमारे अपने सुझाव हैं; इनके साथ कोई परिणाम एकत्र नहीं किए गए।
धाराप्रवाह सारांश की झूठी सुरक्षा
एक सर्विस अनुरोध की कल्पना कीजिए: “स्पेयर पार्ट अनुमोदन मिलते ही भेजा जा सकता है।” “स्पेयर पार्ट भेजा जा रहा है” जैसा सारांश एक शर्त खो देता है। “शिपिंग अनुमोदन अभी लंबित” निर्णायक स्थिति को बनाए रखता है, भले ही वाक्य कम मैत्रीपूर्ण लगे।
तुलना से पहले तय कीजिए कि आपके कार्य के लिए कौन-सी त्रुटियाँ महँगी पड़ती हैं। उदाहरण में ये हैं: गढ़ी गई प्रतिबद्धताएँ, खोई हुई शर्तें और अस्पष्ट ज़िम्मेदारियाँ। लंबाई और लहजा अतिरिक्त मानदंड हैं, लेकिन उन्हें इन तथ्यात्मक प्रश्नों का स्थान नहीं लेना चाहिए।
एक पसंदीदा उदाहरण के बजाय पाँच मामले
हर मामले के लिए एक छोटी फ़ाइल बनाइए: एक पूर्ण अनुरोध, एक शिपिंग शर्त वाला, एक परस्पर विरोधी तारीखों वाला, एक बिना ज़िम्मेदार व्यक्ति वाला और एक अप्रासंगिक विषयांतर वाला। हर फ़ाइल के लिए एक संदर्भ नोट लिखिए। यह आवश्यक व्यवहार का वर्णन करता है, कोई एकल बाध्यकारी आदर्श शब्दावली नहीं।
Case: versand-bedingt
Must be preserved: shipping requires approval.
Must not appear: a claim that the part has already been shipped.
Appropriate gap: who gives the approval?
Style: short, clear working note.ऐसा संदर्भ अलग-अलग अच्छे उत्तरों की गुंजाइश देता है। साथ ही, यह किसी विशेष रूप से आत्मविश्वासी शब्दावली को बिना ध्यान में आए मूल्यांकन मानक को खिसकाने से रोकता है। विवादित मामलों में मूल नोट ही आधिकारिक स्रोत बना रहता है।
समान इनपुट, पहचानने योग्य परिस्थितियाँ
उन्हीं फ़ाइलों को स्किल के साथ और उसके बिना प्रोसेस कीजिए। अन्य सेटिंग्स को यथासंभव स्थिर रखिए और नोट कीजिए कि आप क्या समान नहीं रख सके। आउटपुट को शुरू में तटस्थ रूप से लेबल कीजिए, उदाहरण के लिए वैरिएंट A और B। जो भी उनकी समीक्षा करे, उसे केवल फ़ाइल नाम से यह पता नहीं चलना चाहिए कि कौन-सा उत्तर आपके पसंदीदा ड्राफ़्ट ने तैयार किया।
तथ्यात्मक सटीकता, शर्तों के संरक्षण, खुले विवरणों की दृश्यता और स्पष्टता का अलग-अलग आकलन कीजिए। एक सरल पैमाना पर्याप्त है: पूरा हुआ, आंशिक रूप से पूरा हुआ या उल्लंघन हुआ। निर्णायक अंश जोड़िए। निर्णय और साक्ष्य का संयोजन बिना व्याख्या वाली किसी संख्या से अधिक उपयोगी है।
“बहुत अधिक अनुवर्ती प्रश्न” वाला मामला भी यहीं आता है। यदि किसी पूर्ण इनपुट को हर बार अस्पष्ट माना जाए, तो भी प्रक्रिया ठीक से काम नहीं करती। एक सतर्क स्किल को लापता निर्णयों को दृश्यमान बनाना चाहिए, न कि एहतियात के तौर पर हर संभालने योग्य काम को रोक देना चाहिए।
एक त्रुटि से एक सीमित बदलाव निकालना
यदि शिपिंग शर्त खो जाती है, तो ठीक उसी के लिए एक नियम जोड़िए: प्रतिबद्धताओं से जुड़ी शर्तें सारांश में बनी रहनी चाहिए। उसी चरण में, यदि संभव हो तो आउटपुट की लंबाई, संबोधन का तरीका और सभी उदाहरण बदलने से बचिए। अन्यथा किसी सुधार के प्रभाव का कारण निर्धारित करना कठिन होता है।
मौजूदा मामलों को दोहराइए और किसी अलग संदर्भ से एक नया शर्त-आधारित मामला जोड़िए। यह कोई रिफ़ंड हो सकता है जो रसीद मिलने के बाद ही किया जाता है। यदि स्किल इस संबंध को भी बनाए रखती है, तो यह एक उपयोगी ढंग से लिखे गए नियम का संकेत देता है। यह अभी सभी शर्तों और विषयों के लिए सामान्य प्रमाण नहीं होगा।
तुलना वास्तव में क्या दिखाती है
पाँच मामले किसी विशिष्ट समस्या को दृश्यमान बना सकते हैं। वे किसी मॉडल की सामान्य श्रेष्ठता या समय की निश्चित बचत सिद्ध नहीं करते। स्वचालित मूल्यांकन भी उसी शर्त को चूक सकते हैं जिसे जनरेशन ने चूका था। इसलिए महत्वपूर्ण विचलनों का आकलन किसी व्यक्ति से मूल अंश के आधार पर करवाइए।
इनपुट, आउटपुट, मानदंड और बदलाव को एक साथ रखिए। तब आप बाद में समझा सकते हैं कि कोई नियम क्यों मौजूद है और वह किस अवलोकन का समर्थन करने के लिए है। यही समझने योग्य संबंध किसी स्किल को रखरखाव योग्य बनाता है; केवल एक ऊँचा स्कोर, जो आपको संयोग से पसंद हो, अपने आप ऐसा नहीं करता।
स्रोत और दस्तावेज़ीकरण की स्थिति: 25 अक्टूबर 2026।
