तकनीकी सारांश: LLM टूल उपयोग में ज्ञान अंतराल का निदान (Diagnosing Knowledge Gaps in LLM Tool Use)

समस्या विवरण (Problem Statement)

कोड आधारित लार्ज लैंग्वेज मॉडल्स (LLMs) तेजी से एजेंट के रूप में कार्य कर रहे हैं जिन्हें जटिल कार्यों को हल करने के लिए सॉफ्टवेयर लाइब्रेरी और API को कॉल करना होता है। एक महत्वपूर्ण चुनौती तब उत्पन्न होती है जब ये एजेंट नवीन API (novel APIs) का सामना करते हैं—ऐसे फंक्शन या इंटरफेस जो लाइब्रेरी अपडेट, ब्रेकिंग चेंजेस, या उभरते हुए पैकेजों के कारण उनके प्रीट्रेनिंग डेटा में अनुपस्थित होते हैं। इन API का सफलतापूर्वक उपयोग करने के लिए केवल एक फंक्शन का नाम याद रखना पर्याप्त नहीं है; इसके लिए विषम प्रकार के ज्ञान को समन्वित करने की आवश्यकता होती है:

• घोषणात्मक (Declarative): सिग्नेचर, पैरामीटर प्रकार और मॉड्यूल पाथ।
• प्रक्रियात्मक (Procedural): वर्कफ़्लो के भीतर सही संयोजन और इम्पोर्ट रेजोल्यूशन।
• आधारित (Grounded): ठोस निष्पादन उदाहरण और कार्यान्वयन विवरण।

नवीन API अधिग्रहण के लिए मौजूदा मूल्यांकन बुनियादी ढांचा मौलिक रूप से सीमित है। वर्तमान बेंचमार्क अक्सर स्थिर होते हैं (जो मॉडल द्वारा नया डेटा सोखने के साथ तेजी से खराब हो जाते हैं), मोटे समग्र मेट्रिक्स (जैसे pass@k) पर निर्भर करते हैं जो विफलता के मूल कारणों को छिपा देते हैं, और अक्सर कृत्रिम कार्यों का संश्लेषण करते हैं जो वास्तविक दुनिया के लाइब्रेरी विकास को प्रतिबिंबित नहीं करते हैं। फलस्वरूप, यह समझना कठिन है कि विभिन्न अनुकूलन प्रतिमान (जैसे Retrieval-Augmented Generation बनाम Fine-Tuning) द्वारा कौन से विशिष्ट ज्ञान घटक सीखे जाते हैं और कौन से लुप्त घटक विशिष्ट विफलता मोडों की ओर ले जाते हैं।

कार्यप्रणाली: NOVELAPIBENCH

इन सीमाओं को संबोधित करने के लिए, लेखक NOVELAPIBENCH पेश करते हैं, जो कोड LLMs में ज्ञान के अंतरालों का निदान करने के लिए डिज़ाइन किया गया एक पूर्णतः स्वचालित, गतिशील और निष्पादन-आधारित बेंचमार्क है। यह फ्रेमवर्क चार चरणों वाली पाइपलाइन के माध्यम से संचालित होता है:

1. नवीन API खोज (Novel API Discovery): एक लक्षित लाइब्रेरी $L$ और एक बेस मॉडल $M$ को देखते हुए, सिस्टम उन API की पहचान करता है जो $M$ के नॉलेज कटऑफ के बाद जारी किए गए लाइब्रेरी वर्जनों में पेश किए गए हैं। यह इंट्रोस्पेक्शन और AST पार्सिंग का उपयोग करके प्री-कटऑफ संस्करण ($v_{old}$) और पोस्ट-कटऑफ संस्करण ($v_{new}$) के बीच सार्वजनिक API सतहों का अंतर (diff) निकालता है, और प्राइवेट, डेप्रकेटेड, या सोर्स-रहित प्रविष्टियों को फ़िल्टर करता है।
2. ज्ञान निष्कर्षण (Knowledge Extraction): प्रत्येक नवीन API के लिए, सिस्टम ज्ञान को चार विशिष्ट घटकों में विभाजित करता है:
   • $S$ (Surface): पूर्ण-योग्य नाम और पैरामीटर सिग्नेचर (प्रकार, डिफॉल्ट, विवरण)।
   • $E$ (Exemplars): डॉक्यूमेंटेशन और GitHub से निकाले गए कैनोनिकल उपयोग के उदाहरण, जिन्हें सैंडबॉक्स में सत्यापित किया गया है।
   • $M_{prose}$ (Mechanism Prose): अंतर्निहित एल्गोरिदम या डिज़ाइन का प्राकृतिक-भाषा विवरण।
   • $M_{code}$ (Mechanism Code): AST-एक्सट्रैक्टेड कार्यान्वयन सोर्स कोड।
3. कार्य पीढ़ी (Task Generation): सिस्टम कठिनाई-नियंत्रित टेस्ट हार्नेस के साथ निष्पादन योग्य कोडिंग कार्य उत्पन्न करता है। महत्वपूर्ण रूप से, प्रत्येक हार्नेस में एक ऑटो-इंजेक्टेड टारगेट-API स्पाय (target-API spy) शामिल होता है जो लक्षित API के सभी एलियास को पैच करता है। यह सुनिश्चित करता है कि टेस्ट पास करने के लिए लक्षित API को वास्तव में कॉल करना आवश्यक है, जिससे मॉडल को स्ट्रक्चरल मिमिक्री के माध्यम से कार्य को बायपास करने से रोका जा सके।
4. गुणवत्ता और नवीनता फ़िल्टरिंग (Quality & Novelty Filtering): कार्यों को यह सुनिश्चित करने के लिए फ़िल्टर किया जाता है कि रेफरेंस सॉल्यूशन वैध है, बेस मॉडल उन्हें बिना सहायता के हल नहीं कर सकता (अनुभवजन्य नवीनता), और कार्य पूर्ण ज्ञान बंडल के साथ हल करने योग्य है।

विफलता वर्गीकरण (Failure Taxonomy):
एक प्रमुख योगदान एक स्वचालित विफलता वर्गीकरण है जो निष्पादन विफलताओं को छह परस्पर अनन्य श्रेणियों में वर्गीकृत करता है, जो विशिष्ट त्रुटियों को लुप्त ज्ञान से जोड़ता है:

1. WrongAPISelection: लक्षित API कभी कॉल नहीं किया गया (हैलुसिनेटेड या सिब्लिंग सिंबल का उपयोग किया गया)।
2. WrongImport: सही सिंबल लेकिन गलत/लापता इम्पोर्ट पाथ।
3. WrongSyntax: अमान्य पायथन सिंटैक्स।
4. WrongParam: सही कॉल लेकिन गलत तर्क (arguments)।
5. WrongShapeDtype: API बॉडी के भीतर कॉन्ट्रैक्ट उल्लंघन (जैसे शेप मिसमैच)।
6. WrongLogic: सही API उपयोग के बावजूद आसपास का प्रोग्राम स्ट्रक्चर गलत है।

मुख्य योगदान

1. गतिशील बेंचमार्किंग (Dynamic Benchmarking): एक पुन: उत्पन्न करने योग्य बेंचमार्क जो किसी भी बेस मॉडल और विकसित होती लाइब्रेरी के अनुकूल होता है, जिससे कार्य वास्तव में नवीन बने रहते हैं।
2. सूक्ष्म निदान (Granular Diagnosis): एक स्वचालित विफलता वर्गीकरण जो विशिष्ट निष्पादन त्रुटियों को रिट्रीवल, फाइन-ट्यूनिंग और नॉलेज-एडिटिंग प्रतिमानों में लुप्त ज्ञान घटकों से जोड़ता है।
3. व्यवस्थित अनुभवजन्य अध्ययन (Systematic Empirical Study): 5 डोमेन, 4 बैकबोन मॉडल और कई अनुकूलन विधियों (RAG, SFT, RAFT, GRACE, MEMIT, AlphaEdit) में ~800 नवीन API वाला एक बड़े पैमाने पर मूल्यांकन।

प्रयोगात्मक परिणाम

1. ज्ञान घटकों की प्रभावशीलता (RQ1)

• उपयोग के उदाहरण ($E$) सबसे मजबूत स्टैंडअलोन घटक हैं: केवल उदाहरण प्रदान करने से pass@1 3.1% से बढ़कर 18.2% हो गया, मुख्य रूप से WrongAPISelection त्रुटियों को हल करके।
• सिग्नेचर ($S$) सबसे विश्वसनीय एंकर प्रदान करते हैं: सरफेस सेल ($S$) ने 21.7% pass@1 प्राप्त किया, जो सभी सिंगलटन से बेहतर था, API चयन त्रुटियों को कम करके।
• मैकेनिज्म प्रोस ($M_{prose}$) सिमेंटिक विसंगति निवारण में सहायता करता है: जब इसे सिग्नेचर ($S+M_{prose}$) के साथ जोड़ा गया, तो इसने लॉजिक त्रुटियों को और कम किया, लेकिन एक स्टैंडअलोन घटक के रूप में इसका प्रभाव न्यूनतम रहा।
• सोर्स कोड ($M_{code}$) शोर (noise) पेश करता है: कार्यान्वयन सोर्स कोड जोड़ने से अक्सर प्रदर्शन गिर जाता है। इसने WrongImport त्रुटियों को काफी बढ़ा दिया, जो बताता है कि कच्चा सोर्स कोड मॉड्यूल-पाथ का शोर पेश करता है जो शेष त्रुटियों को हल करने के बजाय मॉडल को भ्रमित करता है।
• इष्टतम कॉन्फ़िगरेशन: सर्वश्रेष्ठ दो-घटक कॉन्फ़िगरेशन ने सिग्नेचर ($S$) को डोमेन और बैकबोन के आधार पर मैकेनिज्म प्रोस या उदाहरणों के साथ जोड़ा। फुल बंडल्स ($S+E+M_{prose}+M_{code}$) अक्सर सोर्स कोड के नकारात्मक हस्तक्षेप के कारण खराब प्रदर्शन करते हैं।

2. कार्य और बैकबोन का प्रभाव (RQ2)

• कार्य नियमितता (Task Regularity): उदाहरण ($E$) टेम्पलेट योग्य, नियमित कार्यों (जैसे डेटा साइंस फिक्स्चर) के लिए अत्यधिक प्रभावी थे लेकिन विषम कार्यों (जैसे AI4Science) के लिए हानिकारक थे जहाँ उदाहरण विशिष्ट आवश्यकता से भिन्न थे। मैकेनिज्म प्रोस ($M_{prose}$) कार्य प्रकारों के बीच अधिक स्थिर था।
• बैकबोन प्राथमिकताएं: द्वितीयक घटक की इष्टतम पसंद बैकबोन की अंतर्निहित शक्ति पर निर्भर थी। वे मॉडल जिनमें सिग्नेचर ($S$) पहले से ही मजबूत थे, उन्हें प्रोस से अधिक लाभ हुआ; वे मॉडल जो उदाहरणों पर निर्भर थे, उन्हें स्पष्ट कॉल स्ट्रक्चर से लाभ हुआ।
• रीजनिंग-ओरिएंटेड मॉडल: रीजनिंग-ओरिएंटेड बैकबोन (जैसे R1-Distill) सोर्स कोड द्वारा पेश किए गए इम्पोर्ट-पाथ शोर के प्रति अधिक प्रतिरोधी थे, जो संभवतः उनकी आइडेंटिफायर को कॉपी करने के बजाय उन्हें पुनः हल करने की क्षमता के कारण है।

3. पैरामीट्रिक अनुकूलन बनाम रिट्रीवल (RQ3)

• अस्थिर तथ्यों का आंतरिककरण नहीं (No Internalization of Volatile Facts): किसी भी पैरामेट्रिक अनुकूलन प्रतिमान (SFT, RAFT, GRACE, MEMIT, AlphaEdit) ने नवीन API ज्ञान को पूरी तरह से आत्मसात नहीं किया। जब इन्फरेंस के समय बाहरी ज्ञान बंडल को हटा दिया गया, तो प्रदर्शन नाटकीय रूप से गिर गया (जैसे, SFT 85.5% से 3.3% हो गया), जो रिट्रीवल-आधारित विधियों के साथ अंतर को बंद करने में विफल रहा।
• प्रक्रियात्मक मेटा-कौशल सीखना (Learning Procedural Meta-Skills): फाइन-ट्यूनिंग ने API विवरणों (सिग्नेचर, पाथ) को याद नहीं किया, बल्कि एक हस्तांतरणीय प्रक्रियात्मक कौशल सीखा: प्रदान किए गए ज्ञान बंडलों का प्रभावी ढंग से उपयोग कैसे किया जाए।
  • SFT/RAFT/AlphaEdit ने एक बंडल की उपस्थिति में WrongAPISelection और WrongImport त्रुटियों को काफी कम कर दिया, जिससे विफलताएं WrongLogic की ओर स्थानांतरित हो गईं।
  • यह "बंडल उपयोग" कौशल होल्ड-आउट लाइब्रेरीज़ (OOD) में भी स्थानांतरित हुआ, लेकिन विशिष्ट मॉड्यूल-पाथ ज्ञान नहीं। एक लाइब्रेरी पर प्रशिक्षित मॉडल नई लाइब्रेरी में सही API की पहचान तो कर सकते थे लेकिन अक्सर सही इम्पोर्ट पाथ को हल करने में विफल रहे, जिससे WrongImport त्रुटियों में उछाल आया।

महत्व और दावे

पेपर का तर्क है कि कंटेंट एक्विजिशन (API और उसके कॉन्ट्रैक्ट की पहचान करना) और प्रोसीजरल रियलाइजेशन (उसे सही इम्पोर्ट और लॉजिक के साथ कोड में एकीकृत करना) अलग-अलग उप-कौशल हैं।

• रिट्रीवल उन अस्थिर, कम-संरचना वाले तथ्यों (API नाम, सिग्नेचर, पाथ) को आपूर्ति करने के लिए आवश्यक है जिन्हें मॉडल अनुमान लगाने या याद करने में कठिन पाते हैं।
• पैरामेट्रिक ट्यूनिंग (Fine-tuning) ऐसे तथ्यों के प्रक्रियात्मक एकीकरण को सुधारने के लिए प्रभावी है—मॉडल को यह सिखाना कि प्रदान किए गए साक्ष्य का सही उपयोग कैसे किया जाए।

लेखक निष्कर्ष निकालते हैं कि कोडिंग LLMs को नवीन API के अनुकूल बनाने के लिए इष्टतम आर्किटेक्चर RAG और फाइन-ट्यूनिंग के बीच चुनाव नहीं है, बल्कि एक संयोजन है: कॉम्पैक्ट, उच्च-मूल्य वाले रिट्रीवल यूनिट्स (जैसे सिग्नेचर + मैकेनिज्म प्रोस) को विषम API-उपयोग कार्यों के माध्यम से प्रशिक्षित एडैप्टर्स के साथ जोड़ना ताकि प्रक्रियात्मक एकीकरण में महारत हासिल की जा सके। वर्तमान "लोकेट-एंड-एडिट" विधियां अभी तक इस संयुक्त सीमा को प्राप्त नहीं कर पाई हैं। यह कार्य सुझाव देता है कि भविष्य की प्रगति के लिए निष्पादन-आधारित सुदृढीकरण शिक्षण (execution-grounded reinforcement learning) जैसे प्रोसेस-लेवल पर्यवेक्षण की आवश्यकता हो सकती है ताकि एक API को पहचानने और उसे सही ढंग से लागू करने के बीच के अंतर को बेहतर ढंग से पाटा जा सके।