यूनिवर्सिटी ऑफ इलिनोइस अर्बाना-चैंपेन की एक शोध टीम ने पाया है कि व्यापक रूप से उपयोग किए जाने वाले BIRD Text-to-SQL बेंचमार्क में आधे से अधिक एनोटेशन गलत हैं, जिससे उन सटीकता स्कोर (accuracy scores) की विश्वसनीयता पर सवाल उठ रहे हैं जिन पर कई डेवलपर्स भरोसा करते हैं।

यह बेंचमार्क क्यों महत्वपूर्ण है

BIRD इस बात को मापने के लिए एक मानक (de-facto standard) है कि कोई मॉडल प्राकृतिक भाषा के प्रश्न को SQL क्वेरी में कितनी अच्छी तरह बदल सकता है। शोध पत्र, प्रोडक्ट शीट और हायरिंग टेस्ट BIRD स्कोर का हवाला देते हैं। यदि "गोल्ड" SQL स्टेटमेंट, जो शुद्धता को परिभाषित करते हैं, त्रुटिपूर्ण हैं, तो एक बेहतर क्वेरी लिखने वाले मॉडल को दंडित किया जा सकता है, जबकि एक गलत "गोल्ड" उत्तर की नकल करने वाले मॉडल को पुरस्कृत किया जा सकता है।

त्रुटि दर का पता कैसे चला

UIUC टीम ने BIRD-dev स्प्लिट से 238 विफलताओं का परीक्षण किया। प्रत्येक मॉडल आउटपुट को गलत क्यों माना गया, इसका अनुमान लगाने के बजाय, उन्होंने मॉडल द्वारा जनरेट किए गए SQL और गोल्ड रेफरेंस के बीच प्रत्येक विसंगति को मैन्युअल रूप से टैग किया। उनके ऑडिट में पाया गया कि 52.8% मामलों में एनोटेशन त्रुटि है—गलत SQL, गलत स्कीमा, या यहाँ तक कि एक त्रुटिपूर्ण प्राकृतिक-भाषा प्रश्न।

एक पैटर्न ने चिह्नित की गई गलतियों में से 19% हिस्से की व्याख्या की: मॉडल ने DISTINCT का उपयोग किया जबकि गोल्ड क्वेरी में इसका उपयोग नहीं किया गया था। कल्पना कीजिए कि कोई उपयोगकर्ता असामान्य लैब परिणामों वाले रोगियों की संख्या पूछ रहा है। गोल्ड उत्तर COUNT(ID) के साथ पंक्तियों (rows) को गिनता है। यदि एक ही रोगी के पांच असामान्य लैब परिणाम हैं, तो गोल्ड क्वेरी एक के बजाय पांच रिपोर्ट करती है। मॉडल का COUNT(DISTINCT ID) प्रत्येक रोगी को सही ढंग से एक बार गिनता है। इन मामलों में, बेंचमार्क मॉडल की त्रुटि दर्ज करता है, भले ही मॉडल का उत्तर इच्छित अर्थ (semantics) के साथ बेहतर मेल खाता हो।

मॉडल विकास पर वास्तविक दुनिया का प्रभाव

डेवलपर्स अक्सर प्रॉम्प्ट में बदलाव करके, "don't use DISTINCT" जैसे प्रतिबंध जोड़कर, या बेंचमार्क डेटा पर फिर से प्रशिक्षण (retraining) देकर कम BIRD स्कोर पर प्रतिक्रिया देते हैं। वे समायोजन रिपोर्ट किए गए स्कोर को बढ़ा सकते हैं, जिससे प्रगति का भ्रम पैदा होता है। UIUC का विश्लेषण दिखाता है कि यह "सुधार" केवल गलत उत्तर कुंजी (answer key) के प्रति ओवरफिटिंग (overfitting) हो सकता है, जो संभावित रूप से वास्तविक डेटाबेस पर प्रदर्शन को खराब कर सकता है जहाँ सही तर्क (logic) की आवश्यकता होती है।

शोधकर्ताओं ने इसके विपरीत परिदृश्य का प्रदर्शन किया। मॉडल और गोल्ड दोनों क्वेरीज़ का विश्लेषण करने के बाद, उन्होंने सात ऐसे उदाहरणों की पहचान की जहाँ मॉडल ने गलती से दो अलग-अलग कॉलम को एक में मिला दिया था। इन मामलों में गोल्ड SQL सही था। एक परिष्कृत प्रॉम्प्ट के साथ केवल उन वास्तविक त्रुटियों को लक्षित करके, उन्होंने बेंचमार्क स्कोर को बढ़ाए बिना मॉडल के प्रदर्शन को बढ़ाया।

हितधारकों के लिए इन निष्कर्षों का क्या अर्थ है

  • शोधकर्ता (Researchers): BIRD स्कोर पर आधारित प्रकाशन दावों में एनोटेशन की गुणवत्ता के बारे में एक चेतावनी (caveat) होनी चाहिए। विभिन्न शोध पत्रों के बीच तुलना वास्तविक पद्धतिगत प्रगति के बजाय बेंचमार्क शोर (noise) के प्रति अलग-अलग सहनशीलता को दर्शा सकती है।
  • प्रोडक्ट टीमें (Product teams): रिलीज की तैयारी के लिए एकमात्र मेट्रिक के रूप में BIRD पर भरोसा करने से ऐसे मॉडल शिप करने का जोखिम रहता है जिन्होंने त्रुटिपूर्ण क्वेरीज़ को दोहराना सीख लिया है। मालिकाना स्कीमा (proprietary schemas) पर वास्तविक दुनिया का परीक्षण आवश्यक हो जाता है।
  • बेंचमार्क क्यूरेटर (Benchmark curators): उच्च त्रुटि दर बताती है कि एक व्यवस्थित समीक्षा (systematic review) की तत्काल आवश्यकता है। गोल्ड सेट को साफ करना या एक माध्यमिक "सत्यापित" (verified) स्प्लिट प्रदान करना विश्वास बहाल कर सकता है।

एक व्यावहारिक ऑडिट वर्कफ़्लो

UIUC टीम एक हल्का (lightweight) प्रक्रिया प्रस्तावित करती है जिसे किसी भी Text-to-SQL बेंचमार्क पर लागू किया जा सकता है:

  1. मॉडल-जनरेटेड और गोल्ड दोनों SQL स्टेटमेंट को एब्स्ट्रैक्ट सिंटैक्स ट्री (abstract syntax trees) में पार्स (Parse) करें।
  2. चयनित कॉलम, फिल्टर, जॉइन और एग्रीगेशन फंक्शन में अंतर को उजागर करने के लिए संरचनाओं को संरेखित (Align) करें।
  3. प्रत्येक अंतर को टैग (Tag) करें (जैसे, अतिरिक्त कॉलम, गायब फिल्टर, गलत एग्रीगेशन)।
  4. प्रमुख त्रुटि श्रेणियों का पता लगाने के लिए एक हिस्टोग्राम में टैग को सारांशित (Summarize) करें।
  5. प्रॉम्प्ट इंजीनियरिंग के लिए लक्ष्य के रूप में उपयोग करने से पहले प्रत्येक उच्च-आवृत्ति वाले टैग के लिए गोल्ड क्वेरी को सत्यापित (Validate) करें।

प्रॉम्प्ट संशोधनों को केवल उन मामलों पर केंद्रित करके जहाँ गोल्ड उत्तर निर्विवाद रूप से सही है, डेवलपर्स "टूटे हुए मेट्रिक के लिए अनुकूलन (optimising for a broken metric)" के जाल से बच सकते हैं।

निष्कर्ष

एक बेंचमार्क जो अपने आधे से अधिक उदाहरणों को गलत लेबल करता है, वह एक विश्वसनीय मानक के रूप में काम नहीं कर सकता। UIUC का अध्ययन दिखाता है कि BIRD द्वारा चिह्नित कई "गलतियाँ" वास्तव में मॉडल की सफलताएँ हैं, जबकि वास्तविक त्रुटियाँ सही गोल्ड उत्तरों के पीछे छिपी होती हैं। गोल्ड सेट का ऑडिट करना, मूल्यांकन पाइपलाइनों को परिष्कृत करना और बेंचमार्क स्कोर को व्यापक सत्यापन रणनीति के एक हिस्से के रूप में मानना ही यह सुनिश्चित करने के एकमात्र तरीके हैं कि कागज़ पर होने वाले सुधार वास्तविक दुनिया की विश्वसनीयता में बदल सकें।