तकनीकी सारांश: PluginEval

समस्या विवरण

जैसे-जैसे लार्ज लैंग्वेज मॉडल्स (LLMs) स्वायत्त एजेंटों के रूप में कार्य कर रहे हैं, टूल रूटिंग (फंक्शन कॉलिंग) का विश्वसनीय मूल्यांकन महत्वपूर्ण हो गया है। वर्तमान बेंचमार्क तीन संरचनात्मक सीमाओं से ग्रस्त हैं:

1. डेटा वितरण पूर्वाग्रह (Data Distribution Bias): पावर-लॉ डिस्ट्रीब्यूशन के कारण दुर्लभ परिदृश्य और एज केस (edge cases) कम प्रतिनिधित्व वाले रह जाते हैं।
2. आक्रामक कठोरता का अभाव (Lack of Adversarial Rigor): हार्ड नेगेटिव्स (hard negatives) की अनुपस्थिति मॉडल्स के बीच प्रदर्शन के अंतर को स्पष्ट नहीं होने देती।
3. अमान्य एनोटेशन पाइपलाइन्स (Unvalidated Annotation Pipelines): कई बेंचमार्क एनोटेशन के लिए LLM निर्णयों पर निर्भर करते हैं जिनका वास्तविक निष्पादन (execution) के माध्यम से सत्यापन नहीं किया गया है, जिससे संरचनात्मक शुद्धता के बावजूद संभावित अर्थ संबंधी त्रुटियां हो सकती हैं।

इसके अलावा, मौजूदा बेंचमार्क अक्सर कुल सफलता दर या कॉल सिंटैक्स पर ध्यान केंद्रित करते हैं, और विशिष्ट विफलता मोड जैसे कि मिस टूल कॉल, स्प्यूरियस कॉल (spurious calls), या पैरामीटर ग्राउंडिंग त्रुटियों का निदान करने में विफल रहते हैं। विशेष रूप से चीनी प्रश्नों (queries) के लिए, जो अक्सर अस्पष्ट या संदर्भ-निर्भर होते हैं, एक ऐसे बेंचमार्क की आवश्यकता है जो निष्पादन-आधारित (execution-grounded) एनोटेशन और ट्रिगर एवं एक्सक्लूजन बाउंड्रीज़ के संरचित कवरेज को जोड़ सके।

कार्यप्रणाली: द प्लगिनइवल क्लोज्ड-लूप कंस्ट्रक्शन फ्रेमवर्क (PCCF)

यह पेपर PluginEval को पेश करता है, जिसे एक दो-चरणीय, क्लोज्ड-लूप फ्रेमवर्क (PCCF) के माध्यम से बनाया गया है, जिसे एनोटेशन विश्वसनीयता को कवरेज आवश्यकताओं से अलग करने के लिए डिज़ाइन किया गया है।

कार्य सूत्रीकरण (Task Formulation)

टूल रूटिंग को तीन निर्णयों के पदानुक्रम के रूप में तैयार किया गया है:

1. आवश्यकता ($f_1$): क्या एक टूल की आवश्यकता है?
2. प्रासंगिकता ($f_2$): क्या लक्षित प्लगइन प्रासंगिक है?
3. इनवोकेशन ($f_3$): क्या अनुरोध को सही तर्कों के साथ एक वैध इनवोकेशन में बदला जा सकता है, या इसे अस्वीकार किया जाना चाहिए?

चरण I: निष्पादन-आधारित एंसेम्बल एनोटेशन (Execution-Grounded Ensemble Annotation)

यह चरण वास्तविक और सिंथेटिक दोनों प्रकार के प्रश्नों के लिए विश्वसनीय एनोटेशन स्थापित करने पर केंद्रित है।

• जेनरेशन (Generation): कई जनरेटर स्वतंत्र रूप से पूर्ण इनवोकेशन्स का प्रस्ताव देते हैं।
• सत्यापन (Verification): प्रस्तावों को एक बहु-चरणीय सत्यापन प्रक्रिया से गुजरना पड़ता है:
  • डिटरमिनिस्टिक स्कीमा वैलिडेशन: संरचनात्मक वैधता की जांच करता है।
  • आर्ग्युमेंट इवैल्यूएशन: एक LLM इवैल्यूएटर यह जांचता है कि क्या तर्क प्रश्न द्वारा समर्थित हैं और प्लगइन के अर्थ विज्ञान (semantics) के अनुरूप हैं।
  • निष्पादन (Execution): प्रस्तावों को MCP (मॉडल कॉन्टेक्स्ट प्रोटोकॉल) के माध्यम से निष्पादित किया जाता है।
  • परिणाम मूल्यांकन: एक अलग इवैल्यूएटर यह जांचता है कि क्या निष्पादन प्रतिक्रिया उपयोगकर्ता के अनुरोध को संतुष्ट करती है।
• रिफाइनमेंट लूप (Refinement Loop): वे प्रस्ताव जो सत्यापन में विफल रहते हैं (स्कीमा उल्लंघन, निष्पादन त्रुटियों, या अर्थ संबंधी बेमेल के कारण), उन्हें ट्रेसेस (traces) के रूप में रखा जाता है। इन ट्रेसेस को, स्वतंत्र इवैल्यूएटर स्कोर के साथ, सुधार के लिए जनरेटर्स को वापस भेजा जाता है। यह प्रक्रिया अधिकतम $R_{max}$ राउंड तक दोहराई जाती है जब तक कि एक प्रस्ताव आत्मविश्वास थ्रेशोल्ड $\tau$ को पूरा नहीं कर लेता या उसे न्यायसंगत अपवर्जन (justified abstention) के रूप में अस्वीकार नहीं कर दिया जाता।

चरण II: परिदृश्य-आधारित संश्लेषण और व्यवहार अंशांकन (Scenario-Grounded Synthesis and Behavioral Calibration)

यह चरण कवरेज अंतराल और कठिनाई अंशांकन को संबोधित करता है।

• परिदृश्य अपघटन (Scenario Decomposition): प्लगइन्स को ट्रिगर परिदृश्यों (समर्थित अनुरोध) और एक्सक्लूजन परिदृश्यों (ऐसे अनुरोध जिनमें टूल की आवश्यकता नहीं है, अन्य टूल की आवश्यकता है, या क्षमता से बाहर है) में विभाजित किया गया है।
• लक्षित संश्लेषण (Targeted Synthesis): सिस्टम कम-कवर इकाइयों (क्षमता, इरादा और बाउंड्री के संयोजन) की पहचान करता है और इन अंतरालों को भरने के लिए नए प्रश्न संश्लेषित करता है।
• कठिनाई अंशांकन (Difficulty Calibration):
  • पॉजिटिव उदाहरण: कठिनाई अनुमान गहराई (0, 1, या $\ge$2 स्टेप्स) पर आधारित है।
  • नेगेटिव उदाहरण: कठिनाई को व्यवहार संबंधी साक्ष्य के आधार पर अंशांकित किया जाता है। एक फ्रोजन रेफरेंस राउटर संश्लेषित नेगेटिव को $K$ बार मूल्यांकन करता है। यदि राउटर लगातार नेगेटिव को अस्वीकार करने में विफल रहता है (उच्च फाल्स पॉजिटिव रेट), तो उदाहरण को "हार्ड" माना जाता है। यदि इसे आसानी से अस्वीकार कर दिया जाता है, तो यह "ईजी" है।
• क्लोज्ड लूप: संश्लेषित उदाहरणों को सत्यापन के लिए चरण I में वापस भेजा जाता है। यह लूप तब तक चलता है जब तक कि कवरेज बजट पूरा नहीं हो जाता या सुधार स्थिर नहीं हो जाता।

मूल्यांकन ढांचा: गोल्ड-एंकर्ड जज (Gold-Anchored Judge)

कुल सफलता दर से आगे बढ़ने के लिए, पेपर एक गोल्ड-एंकर्ड LLM जज का उपयोग करता है:

• इनपुट: प्रेडिक्टेड कॉल्स, मानव-सत्यापित गोल्ड कॉल्स, और यूजर क्वेरी।
• प्रतिबंध: जज गोल्ड कॉल लिस्ट को एकमात्र एंकर मानता है। यह गोल्ड स्पेसिफिकेशन का विस्तार या ओवरराइड नहीं कर सकता।
• पदानुक्रमित सत्यापन (Hierarchical Verification):
  1. टूल अलाइनमेंट: प्रेडिक्शन और गोल्ड के बीच टूल नामों का मिलान करता है।
  2. आर्ग्युमेंट फ़िल्टरिंग: गैर-रिक्त, तुलनीय आर्ग्युमेंट सेट्स सुनिश्चित करता है।
  3. सिमेंटिक वेरिफिकेशन: निर्धारित करता है कि क्या प्रेडिक्टेड आर्ग्युमेंट्स क्वेरी के इरादे के तहत गोल्ड आर्ग्युमेंट्स के अर्थतः समान हैं (एलियास और फॉर्मेटिंग विविधताओं की अनुमति देता है लेकिन अस्थायी स्कोप का सख्ती से मूल्यांकन करता है)।
• त्रुटि आरोपण (Error Attribution): विफलताओं को परस्पर अनन्य श्रेणियों में वर्गीकृत किया जाता है:
  • मिस रिकॉल (Miss Recall): आवश्यक टूल्स का छूटना।
  • पैरामीटर एरर (Parameter Error): अर्थ संबंधी रूप से गलत तर्क (इसे टेम्पोरल एरर, मिसिंग आर्ग्युमेंट्स, और गलत वैल्यूज में उप-वर्गीकृत किया गया है)।
  • ओवर रिकॉल (Over Recall): नेगेटिव क्वेरीज पर स्प्यूरियस टूल एक्टिवेशन।

मुख्य योगदान

1. PluginEval बेंचमार्क: 54 प्लगइन्स, 63 टूल्स और 9 डोमेन को कवर करने वाले 3,000 मानव-सत्यापित इंस्टेंस वाला एक चीनी फंक्शन-कॉलिंग बेंचमार्क। इसमें स्पष्ट ट्रिगर/एक्सक्लूजन परिदृश्य, तीन प्रकार के बाउंड्री नेगेटिव्स और व्यवहारिक रूप से अंशांकित कठिनाई शामिल है।
2. PCCF फ्रेमवर्क: एक क्लोज्ड-लूप निर्माण विधि जो एनोटेशन विश्वसनीयता (निष्पादन-आधारित सत्यापन के माध्यम से) को कवरेज आवश्यकताओं (परिदृश्य संश्लेषण के माध्यम से) से अलग करती है। यह एनोटेशन को ठीक करने के लिए स्कीमा वैलिडेशन, स्वतंत्र मूल्यांकन और टूल निष्पादन का उपयोग करता है।
3. सूक्ष्म त्रुटि आरोपण (Fine-Grained Error Attribution): एक मूल्यांकन ढांचा जो विफलताओं को कुल सफलता मेट्रिक्स पर निर्भर रहने के बजाय विशिष्ट कारणों (मिस रिकॉल, पैरामीटर एरर, ओवर रिकॉल) में वर्गीकृत करता है।
4. अनुभवजन्य विश्लेषण (Empirical Analysis): पांच फ्रंटियर LLMs (प्रोप्राइटरी और ओपन-वेट मॉडल्स सहित) का मूल्यांकन, जो दर्शाता है कि कुल स्कोर कठिनाई संरचना के प्रति अत्यधिक संवेदनशील हैं और मॉडल्स के विशिष्ट विफलता प्रोफाइल होते हैं।

परिणाम

पेपर पांच मॉडल्स का मूल्यांकन करता है: GPT-5.4, Claude 4.6, Gemini 3.1 Pro, DeepSeek-V4-Pro, और Qwen3-235B-A22B।

• प्रदर्शन संवेदनशीलता (Performance Sensitivity): कुल प्रदर्शन कठिनाई वितरण पर अत्यधिक निर्भर है। मूल वितरण (40% Easy, 40% Medium, 20% Hard) पर, Claude Opus 4.6 ने सर्वश्रेष्ठ प्रदर्शन (67.60% रिकॉल, 68.17% सटीकता) किया। हालांकि, हार्ड इंस्टेंस पर प्रदर्शन काफी गिर जाता है (सभी मॉडल्स में रिकॉल गिरकर 2.8%–10.8% हो जाता है)।
• कठिनाई का प्रभाव: वितरण को ईजी-वेटेड (60% Easy) में बदलने से सभी मॉडल्स में काफी सुधार हुआ (रिकॉल ~15–21 पॉइंट्स बढ़ा), जो दर्शाता है कि यदि कठोरता से अंशांकित न किया जाए तो वर्तमान बेंचमार्क क्षमताओं को बढ़ा-चढ़ाकर दिखा सकते हैं।
• मौजूदा बेंचमार्क के साथ तुलना: मॉडल्स आमतौर पर BFCL, APIBench, या NexusRaven की तुलना में PluginEval पर खराब प्रदर्शन करते हैं। उदाहरण के लिए, Claude Opus 4.6 का रिकॉल BFCL पर 73.04% से गिरकर PluginEval पर 67.60% हो गया। यह सुझाव देता है कि PluginEval अधिक चुनौतीपूर्ण, यथार्थवादी और आक्रामक परिदृश्यों को कैप्चर करता है।
• त्रुटि प्रोफाइल (Error Profiles):
  • GPT-5.4: उच्चतम मिस रिकॉल (33.72%) और उच्चतम ओवर रिकॉल (33.20%) प्रदर्शित किया, जो आवश्यक टूल्स को पहचानने और अनावश्यक कॉल्स से बचने, दोनों में पर्याप्त कठिनाई को दर्शाता है।
  • Claude Opus 4.6: सबसे कम मिस रिकॉल (13.95%) था, लेकिन उच्च ओवर रिकॉल दर (29.10%) थी, जो Gemini से अधिक लेकिन GPT-5.4 से कम है।
  • Gemini 3.1 Pro: सबसे कम ओवर रिकॉल (18.55%) प्राप्त किया, जो कम रिकॉल के बावजूद प्रतिस्पर्धी सटीकता में योगदान देता है।
  • टेम्पोरल एरर्स (Temporal Errors): सभी मॉडल्स में, टेम्पोरल ग्राउंडिंग एरर्स सबसे आम पैरामीटर एरर सबटाइप थे, जो समय-आधारित बाधाओं को संभालने में एक साझा कमजोरी को दर्शाते हैं।
• विश्वसनीयता: मानव ऑडिट ने रेफरेंस एनोटेशन और जज एट्रिब्यूशन पर उच्च सहमति (Fleiss' $\kappa$ 0.9451 तक) की पुष्टि की, जो बेंचमार्क की विश्वसनीयता को प्रमाणित करता है।

महत्व और दावे

पेपर का दावा है कि PluginEval टूल रूटिंग के लिए डायग्नोस्टिक इवैल्यूएशन के महत्वपूर्ण अंतर को संबोधित करता है। कुल सफलता दर से आगे बढ़कर, यह प्रकट करता है कि:

1. कुल स्कोर विशिष्ट विफलता मोड को छिपा देते हैं: समान समग्र स्कोर वाले मॉडल पूरी तरह से अलग कारणों से विफल हो सकते हैं (जैसे, टूल चयन बनाम पैरामीटर ग्राउंडिंग)।
2. कठिनाई संरचना मायने रखती है: प्रदर्शन रैंकिंग आसान से कठिन उदाहरणों के अनुपात के आधार पर बदल सकती है, जिसके लिए मॉडल व्यवहार से प्राप्त अंशांकित कठिनाई लेबल की आवश्यकता होती है।
3. विश्वास के लिए निष्पादन आवश्यक है: केवल सिंटैक्टिक वैधता के लिए ही नहीं, बल्कि अर्थ संबंधी शुद्धता सुनिश्चित करने के लिए वास्तविक API निष्पादन और स्कीमा चेक के माध्यम से एनोटेशन का सत्यापन करना आवश्यक है।

लेखक निष्कर्ष निकालते हैं कि अधिक मजबूत एजेंटिक सिस्टम के विकास के लिए संरचित त्रुटि आरोपण आवश्यक है, और उनका क्लोज्ड-लूप फ्रेमवर्क ऐसे डायग्नोस्टिक बेंचमार्क बनाने के लिए एक पुनरुत्पादक (reproducible) विधि प्रदान करता है।