SkillsBench: विभिन्न कार्यों में एजेंट स्किल्स के प्रदर्शन का मूल्यांकन करने वाला बेंचमार्क

 (arxiv.org)
3 पॉइंट द्वारा GN⁺ 2026-02-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े भाषा मॉडल (LLM) आधारित एजेंटों की स्किल्स(Agent Skills) की प्रभावशीलता का मात्रात्मक मूल्यांकन करने के लिए यह पहला बेंचमार्क है, जिसमें 11 डोमेन के 84 कार्य शामिल हैं
  • हर कार्य का मूल्यांकन तीन शर्तों में किया जाता है: स्किल्स के बिना, क्यूरेटेड स्किल्स के साथ, और स्वयं-जनित स्किल्स के साथ; कुल 7,308 execution trajectories एकत्र किए गए
  • क्यूरेटेड स्किल्स ने औसतन +16.2%p प्रदर्शन सुधार दिखाया, लेकिन डोमेन-वार अंतर बड़ा था और कुछ कार्यों (84 में से 16) में प्रदर्शन उल्टा गिर गया
  • स्वयं-जनित स्किल्स(Self-generated Skills) औसतन प्रभावी नहीं रहे, जिससे पता चलता है कि मॉडल स्वयं procedural knowledge को स्थिर रूप से उत्पन्न नहीं कर पाते
  • छोटे और फोकस्ड स्किल मॉड्यूल (2–3 घटक) व्यापक दस्तावेज़-आधारित स्किल्स की तुलना में अधिक प्रभावी रहे, और स्किल्स का उपयोग करने वाले छोटे मॉडल ने बिना स्किल्स वाले बड़े मॉडल जैसा प्रदर्शन हासिल किया

SKILLSBENCH अवलोकन

  • SKILLSBENCH, LLM एजेंटों में स्किल augmentation के प्रभाव का मूल्यांकन करने के लिए बनाया गया बेंचमार्क है, और यह Harbor framework पर आधारित है
    • हर कार्य में container environment, deterministic validator, और reference answer (oracle) शामिल हैं
    • स्किल्स लागू होने या न होने की स्थिति में एक ही कार्य को बार-बार चलाकर स्किल्स के शुद्ध प्रभाव को मापा जाता है
  • जहाँ मौजूदा बेंचमार्क सिर्फ मॉडल की मूल क्षमता का मूल्यांकन करते थे, SKILLSBENCH सीधे स्किल्स का प्रदर्शन पर प्रभाव मापता है

स्किल्स(Agent Skills) की परिभाषा और संरचना

  • स्किल्स, procedural knowledge को समाहित करने वाला structured package हैं, जो मॉडल में बदलाव किए बिना inference के समय एजेंट के व्यवहार का विस्तार करते हैं
    • घटक: SKILL.md(कार्य तक पहुँचने की प्रक्रिया), executable scripts, code templates, examples आदि
  • स्किल्स को निम्नलिखित चार मानदंड पूरे करने चाहिए
    • procedural content शामिल हो
    • एकल उदाहरण नहीं, बल्कि task class स्तर पर लागू हो
    • structured components शामिल हों
    • file-system आधारित होने से portability सुनिश्चित हो
  • system prompts, few-shot examples, RAG retrieval, और tool documentation को स्किल्स नहीं माना जाता

कार्य(Task) संरचना और dataset निर्माण

  • हर कार्य चार तत्वों से बना है: निर्देश, environment, answer, validator
    • environment को Docker containers में isolate किया जाता है ताकि reproducibility सुनिश्चित हो
    • validator deterministic test scripts के ज़रिए pass/fail का स्वतः निर्णय करता है
  • 105 contributors ने 322 candidate tasks जमा किए, जिनमें से automatic validation और human review के बाद अंतिम 84 कार्य चुने गए
  • contributors को निम्न आवश्यकताएँ पूरी करनी थीं
    • मनुष्य द्वारा लिखे गए निर्देश (LLM-जनित नहीं)
    • स्किल्स को किसी विशेष कार्य के answer की जगह procedural guidance देनी चाहिए
    • सभी validation deterministic (assertion-based) तरीके से होने चाहिए
    • automatic structure validation, oracle execution, AI generation detection, और leakage audit पास करना आवश्यक था
  • leakage रोकने के लिए स्किल्स में कार्य-विशिष्ट file names, constants, test references आदि होने पर उन्हें अस्वीकार कर दिया जाता था

बेंचमार्क संरचना और कठिनाई वर्गीकरण

  • SKILLSBENCH में 11 डोमेन (software, healthcare, finance, robotics आदि) के 84 कार्य शामिल हैं
  • कठिनाई को मानव द्वारा लगने वाले समय के आधार पर तीन स्तरों में बाँटा गया है
    • Core (60 मिनट से कम): 17
    • Extended (1–4 घंटे): 43
    • Extreme (4 घंटे से अधिक): 26

प्रयोग सेटअप

  • तीन commercial agent harnesses का मूल्यांकन: Claude Code, Gemini CLI, Codex CLI
  • सात मॉडल उपयोग किए गए: GPT-5.2, Claude Opus 4.5/4.6, Claude Sonnet 4.5, Claude Haiku 4.5, Gemini 3 Pro, Gemini 3 Flash
  • तीन स्थितियों में मूल्यांकन
    • No Skills: बिना स्किल्स
    • With Skills: क्यूरेटेड स्किल्स के साथ
    • Self-Generated Skills: मॉडल द्वारा स्वयं बनाई गई स्किल्स के साथ
  • कुल 7,308 वैध execution trajectories एकत्र किए गए

मूल्यांकन मापदंड

  • pass rate को मूल metric के रूप में उपयोग किया गया
  • normalized gain की अतिरिक्त गणना की गई ताकि absolute improvement और relative improvement दोनों का विश्लेषण किया जा सके
  • हर कार्य को 5 बार दोहराने के बाद औसत स्कोर निकाला गया

मुख्य परिणाम

  • क्यूरेटेड स्किल्स ने औसतन +16.2%p सुधार दिखाया, और configuration के अनुसार यह +13.6~+23.3%p के दायरे में रहा
    • डोमेन-वार अंतर काफी बड़ा था; healthcare (+51.9%p) में सबसे अधिक सुधार और software engineering (+4.5%p) में सबसे कम
    • 84 में से 16 कार्यों में प्रदर्शन गिरा
  • स्वयं-जनित स्किल्स औसतन अप्रभावी रहे या उनका नकारात्मक प्रभाव पड़ा
    • मॉडल स्वयं procedural knowledge को स्थिर रूप से उत्पन्न नहीं कर पाए
  • फोकस्ड स्किल्स (2~3 मॉड्यूल) व्यापक दस्तावेज़-आधारित स्किल्स की तुलना में अधिक कुशल रहीं
  • छोटे मॉडल + स्किल्स संयोजन ने बिना स्किल्स वाले बड़े मॉडल के समान प्रदर्शन हासिल किया

निष्कर्ष

  • SKILLSBENCH, स्किल-केंद्रित मूल्यांकन ढाँचा प्रदान करता है और यह मात्रात्मक रूप से दिखाता है कि स्किल्स, LLM एजेंटों की वास्तविक task performance को कैसे प्रभावित करती हैं
  • परिणाम दिखाते हैं कि स्किल डिज़ाइन की गुणवत्ता और डोमेन उपयुक्तता प्रदर्शन सुधार के लिए निर्णायक हैं
  • भविष्य के शोध में स्किल्स के structural design principles और automatic generation की सीमाओं को समझने के लिए यह एक आधारभूत संसाधन बन सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-02-18
Hacker News की राय

  • “Self-Generated Skills” का कॉन्सेप्ट दिलचस्प है, लेकिन मैं यह बताना चाहता हूँ कि यह उस चीज़ से अलग है जिसे लोग आम तौर पर ‘LLM का खुद स्किल सीखने की प्रक्रिया’ समझते हैं
    इस शोध में बस इतना किया गया है कि समस्या हल करने से पहले मॉडल को संबंधित प्रक्रियात्मक ज्ञान उत्पन्न करने के लिए prompt दिया जाता है, इसलिए यह वास्तव में ‘अनुभव से सीखी गई स्किल’ से काफ़ी दूर है
    उम्मीद है कि मीडिया इस फ़र्क को साफ़ तौर पर समझाकर रिपोर्ट करेगा

    • प्रयोग में ‘task’ की सीमा बहुत संकीर्ण है। केवल एक markdown फ़ाइल और validator का उपयोग किया गया है, और मौजूदा codebase या refactoring जैसी वास्तविक समस्याओं को शामिल नहीं किया गया
      भले ही LLM खुद स्किल जनरेट करे, इस संरचना में न exploration संभव है न learning, इसलिए यह अंततः अपने ही context को दोहराने जैसा है
      ऐसे नतीजों को सामान्यीकृत करना भ्रामक हो सकता है
    • ‘स्किल’ का मूल उद्देश्य एक छोटे how-to memo की तरह होना है, जिसे ज़रूरत पड़ने पर बुलाकर इस्तेमाल किया जा सके
      अगर ज्ञान पहले से ही मॉडल के अंदर है, तो उसे अलग दस्तावेज़ में लिखने की ज़रूरत नहीं, और उसका अर्थ तभी है जब वह सचमुच आसानी से सामने न आने वाली जानकारी हो
    • मुझे भी उस तरीके में रुचि है जिसमें LLM कोशिश के बाद सीखे गए सबक को स्किल के रूप में व्यवस्थित करता है
      कोशिश से पहले स्किल बनाना वास्तविकता से कटा हुआ तरीका है
    • मैंने ‘role play session’ के ज़रिए उपयोगी स्किल बनाई हैं
      एजेंट से सवाल करवाना, समस्या-समाधान प्रक्रिया से गुज़रना, और फिर नतीजे को evidence-based compressed skill के रूप में संक्षेपित करना प्रभावी रहा
    • जैसा कि thisistheway.to/ai में लिखा है, हम एजेंट की विफलता को सीखने के अवसर की तरह लेते हैं
      ① विफलता पकड़ना → ② कारण का निदान → ③ सुधार का टूल चुनना → ④ version-controlled artifacts के रूप में दर्ज करना → ⑤ ज़रूरत हो तो gate में promote करना
      हम इस loop को सभी एजेंटों के लिए डिफ़ॉल्ट निर्देशों में शामिल करते हैं

  • मैं Claude के लिए skill-creator अलग से बनाकर इस्तेमाल कर रहा हूँ
    ताकि Claude उस जानकारी को फिर से स्किल के रूप में न लिखे जो वह पहले से जानता है, दस्तावेज़ में केवल ये चीज़ें शामिल की जाती हैं:
    ① training data के बाहर की जानकारी, ② केवल मौजूदा session के लिए मान्य context, ③ भविष्य के Claude के व्यवहार को align करने वाली जानकारी
    पूरी सामग्री GitHub लिंक में है

    • LLM की यह सोचने की क्षमता कि वह क्या जानता है और क्या नहीं कमज़ोर है, लेकिन फिर भी मुझे लगता है कि यह तरीका बहुत उपयोगी है
    • लेकिन यह मान लेना ख़तरनाक है कि Claude ‘सबसे अच्छा ज्ञान’ चुन सकता है
      इंटरनेट training data की quality असमान होती है, इसलिए मॉडल से ‘expert-level selection’ की उम्मीद करना मुश्किल है
    • मुझे यह बात पसंद आई कि यह skill document एक अच्छे blog post की तरह पढ़ा जाता है
      non-obvious insights वाले लेख को ही अच्छा स्किल मानने का मानदंड बनाया जा सकता है
    • ऐसी व्यावहारिक insights को शोधकर्ता paper के रूप में प्रकाशित करने से पहले arXiv पर पहले साझा कर सकते हैं

  • शोध के नतीजों में सबसे दिलचस्प बात यह है कि self-generated skills प्रदर्शन घटाते हैं (-1.3pp), जबकि curated skills इसे काफ़ी बढ़ाते हैं (+16.2pp)
    यह उस परिकल्पना से मेल खाता है कि LLM प्रक्रियात्मक ज्ञान के उपभोक्ता के रूप में तो उत्कृष्ट हैं, लेकिन उत्पादक के रूप में कमज़ोर
    खास तौर पर software की तुलना में healthcare में असर कहीं ज़्यादा है, शायद इसलिए कि SWE data पहले से बहुत अधिक उपलब्ध है

    • मैंने भी इस अंतर पर ध्यान दिया है। नई या दुर्लभ libraries के साथ काम करते समय स्किल का प्रभाव नाटकीय रूप से बढ़ जाता है
      उदाहरण के लिए Adobe React Spectrum UI को स्किल के बिना इस्तेमाल करें तो नतीजा ख़राब होता है, लेकिन अच्छी स्किल के साथ सब कुछ बदल जाता है

  • मॉडल से बस यह कहना कि “स्किल बना लो” अपने आप में अर्थहीन है
    अगर नई जानकारी या बाहरी सामग्री से ज्ञान का विस्तार नहीं किया जाता, तो यह आखिरकार अपने ही output को दोबारा input बनाने वाला चक्र भर है
    मैं स्किल बनाते समय अपने-आप research करने और उसे ताज़ा जानकारी या workflow के मुताबिक refine करने वाला skill-creator इस्तेमाल करता हूँ

    • शोध में एजेंट को स्वायत्त exploration या materials तक पहुँच की अनुमति नहीं दी गई थी
      ऐसी शर्तों में स्किल बनाना अर्थहीन है
    • वास्तविक काम में, अगर स्किल को मैदान में इस्तेमाल करने के बाद feedback से अपने-आप सुधारने दिया जाए, तो वह कहीं अधिक उपयोगी होता है

  • LLM को जितनी ज़्यादा परतों में automate किया जाता है, हर चरण की quality गिरने की प्रवृत्ति होती है
    अगर इंसान idea और implementation plan तय करे और LLM सिर्फ coding करे, तो ठीक रहता है, लेकिन planning भी उसी को सौंप दी जाए तो तेज़ी से quality degradation होता है

    • मैं इस घटना को ‘semantic collapse’ कहता हूँ
      बार-बार summary या reproduction होने पर अर्थ आखिरकार ढह जाता है
      कुछ अंतराल पर ताज़ा मानवीय input ज़रूरी होता है
    • लेकिन अगर context management अच्छा हो, तो उल्टा भी हो सकता है
      बड़े codebase में मैं पहले LLM से exploration report लिखवाता हूँ, फिर नए session में उसी का संदर्भ लेकर काम करता हूँ
      tokens ज़्यादा लगते हैं, लेकिन महत्वपूर्ण विवरण छूटते नहीं
    • Google का Aletheia ऐसे pipeline ढाँचे में भी प्रदर्शन बेहतर करता है
      आखिरकार कुंजी यह है कि मॉडल को पर्याप्त world knowledge दिया जा रहा है या नहीं
    • मैं इस प्रक्रिया की तुलना ‘telephone game’ से करना चाहूँगा
      natural language स्वभाव से अस्थिर है, इसलिए बार-बार आगे बढ़ने पर विकृति बढ़ती जाती है
      हम इंसान आपस में इतना अच्छा संवाद कर लेते हैं, यह अपने-आप में हैरान करने वाली बात है
    • हालांकि, feedback loop हो तो बात अलग है
      open loop संरचना में सटीकता घटती है, लेकिन अगर हर चरण खुद को adjust कर सके, तो व्यवस्था कहीं अधिक स्थिर हो जाती है

  • मैं agentic-ready data warehouse (GitHub.com/mathisdrn/orca) बना रहा हूँ
    शुरुआत में मैं skills को benchmark के हिसाब से optimize करना चाहता था, लेकिन DsPy और GEPA की तरह मॉडल की अपनी भाषा को evaluator और builder दोनों की तरह इस्तेमाल करने वाला तरीका ज़्यादा प्रभावी लगता है
    सोच रहा हूँ कि Anthropic या OpenAI के skill-creator में भी क्या ऐसी self-optimization structure है

  • मुझे यह शोध न तो चौंकाने वाला लगता है, न व्यावहारिक रूप से बहुत मायने रखता है
    वास्तविक दुनिया में मॉडल सिर्फ अपने latent knowledge से स्किल बनाते हों, ऐसा लगभग कभी नहीं होता
    शोध ने उसी सीमित स्थिति में प्रयोग किया, इसलिए नतीजा भी अपेक्षित है
    इससे ज़्यादा दिलचस्प होगा यह देखना कि मॉडल इंसानों का इंटरव्यू लेकर या deep research के बाद skill generate करे

    • मैं इस आलोचना से पूरी तरह सहमत हूँ
      बल्कि मुझे तो यह ज़्यादा हैरानी की बात लगती है कि ऐसा paper आया
    • आधुनिक विज्ञान ‘ग़ैर-चकित करने वाले नतीजों’ को भी प्रकाशित करने को प्रोत्साहित करता है
      और वैसे भी, ऐसे शोध उन managers को रोकने में मदद कर सकते हैं जो “मॉडल से बिना context के best practices दस्तावेज़ लिखवा देते हैं”
    • अतीत में ‘पहले योजना, फिर क्रियान्वयन’ जैसे तरीकों के वास्तव में प्रभावी होने के उदाहरण भी रहे हैं
      यह शोध उस संदर्भ पर विचार नहीं करता
    • अंततः यह वैसा ही है जैसे यह कहना कि अगर मॉडल ने CLAUDE.md या AGENTS.md खुद लिख दिया, तो वह बेकार है

  • आजकल लगता है कि बहुत सारे होशियार लोग अपनी ऊर्जा ऐसी AI बहसों में बर्बाद कर रहे हैं
    पहले लोग बस उपयोगी software बनाते थे, अब हर हफ़्ते आने वाले नए AI विषयों में फँसे रहते हैं
    इसमें Web3 या JS frameworks से भी ज़्यादा ताकतवर nerd-sniping effect है
    यह लेख भी मूलतः सिर्फ उसी नतीजे की पुष्टि करता है जिसकी पहले से उम्मीद थी

    • अभी वितरित विकास की प्रक्रिया चल रही है, इसलिए कई दोहराए गए प्रयास दिखते हैं
      लेकिन जल्द ही कोई नया मॉडल आकर इन चर्चाओं को अप्रासंगिक भी बना सकता है
      कई टीमों को ‘skills strategy’ अपनाने के निर्देश मिलते हैं, लेकिन इसी बीच नया मॉडल वह काम और बेहतर कर देता है
      आखिरकार सब लोग अस्थिर survival structure के भीतर दिशा खोजने की कोशिश कर रहे हैं

  • मैंने भी self-generated documents की quality गिरते अक्सर देखी है
    जब LLM code से ‘best practices’ निकालता है, तो कई बार ग़लत patterns भी वैसे के वैसे दस्तावेज़ में आ जाते हैं
    उदाहरण के लिए C# code में ConfigureAwait(false) या Task.Run के दुरुपयोग के मामले देखे गए
    इस समस्या को हल करने के लिए हम curated knowledge system बना रहे हैं
    मेरा मानना है कि Markdown-आधारित agentic coding अगली पीढ़ी का abstraction layer बनेगा

    • हालांकि, LLM layer पहले की भाषाओं से अलग इस मायने में है कि यह non-deterministic है
      इस विशेषता का पूरे व्यवहार पर क्या असर पड़ता है, यह अभी साफ़ नहीं है

  • सबमिट किया गया शीर्षक “Self-generated agent skills are useless” था, जो HN guidelines के ख़िलाफ़ है
    मूल शीर्षक बनाए रखना और राय को comment में व्यक्त करना ज़्यादा निष्पक्ष है

    • लेकिन यह भी समस्या है कि बहुत अस्पष्ट शीर्षक के नीचे मुख्य निष्कर्ष दब जाए
      मुझे लगता है कि स्पष्ट शीर्षक समुदाय को ज़्यादा बड़ी insight दे सकता है
      इरादा clickbait करना नहीं था, बल्कि मुख्य खोज को उभारना था