एंटरप्राइज में Text-to-SQL क्यों विफल हो जाता है
अधिकांश Text-to-SQL डेमो बहुत ही सरल होते हैं।
वे सरल स्कीमा और स्पष्ट टेबल नामों का उपयोग करते हैं। वे मान लेते हैं कि एक या दो टेबल पूरी तरह से जुड़े हुए हैं। यह एक डेमो के लिए तो ठीक है, लेकिन एक वास्तविक कंपनी में यह विफल हो जाता है।
एंटरप्राइज डेटाबेस में, कठिन हिस्सा SELECT क्लॉज नहीं है। कठिन हिस्सा जॉइन पाथ (join path) है।
एक मॉडल ग्राहक के अनुसार राजस्व (revenue) के लिए एक वैध क्वेरी लिख सकता है। SQL रन हो जाता है। डैशबोर्ड पर नंबर दिखाई देते हैं। लेकिन उत्तर गलत होता है।
यह क्यों होता है?
- कस्टमर टेबल आधिकारिक मास्टर लिस्ट नहीं है।
- रेवेन्यू फील्ड फाइनेंस द्वारा स्वीकृत वर्जन नहीं है।
- विभिन्न क्षेत्रों में रिकॉर्ड डुप्लिकेट हैं।
- जॉइन के कारण फैनआउट एरर (fanout errors) पैदा होते हैं।
- वित्तीय कैलेंडर (fiscal calendars) कैलेंडर वर्षों से भिन्न होते हैं।
सिंटैक्टिकली वैध (syntactically valid) क्वेरी का मतलब यह नहीं है कि वह भरोसेमंद क्वेरी है।
वास्तविक प्रोडक्शन सिस्टम काफी जटिल होते हैं। आपको मिसिंग फॉरेन कीज़ (foreign keys), लेगेसी टेबल्स और वन-टू-मेनी (one-to-many) रिलेशनशिप का सामना करना पड़ता है जो आंकड़ों को बढ़ा-चढ़ाकर दिखा सकते हैं। यहाँ तक कि इंसान भी किसी जॉइन पर भरोसा करने से पहले पुराने रिपोर्ट चेक करते हैं या फाइनेंस टीम से पूछते हैं।
एक AI मॉडल केवल नाम और कॉलम देखता है। वह अनुमान लगाता है। कभी-कभी यह अनुमान खतरनाक हो सकता है।
फैनआउट (fanout) पर विचार करें। यदि आप ऑर्डर्स को ऑर्डर लाइन्स से और फिर शिपमेंट्स से जोड़ते हैं, तो एक ऑर्डर की गिनती कई बार हो सकती है। SQL सही है, लेकिन परिणाम गलत है।
मेटाडेटा मदद करता है, लेकिन यह पर्याप्त नहीं है। कॉलम के नाम आपको यह नहीं बताते कि क्या कोई रिलेशनशिप वित्तीय रिपोर्टिंग के लिए सुरक्षित है। फॉरेन कीज़ ऐतिहासिक अपवादों (historical exceptions) की व्याख्या नहीं करती हैं।
Text-to-SQL को रिलेशनशिप इंटेलिजेंस (relationship intelligence) की आवश्यकता है।
एक विश्वसनीय सिस्टम को पता होना चाहिए:
- विशिष्ट व्यावसायिक प्रश्नों के लिए स्वीकृत जॉइन पाथ।
- रिलेशनशिप कार्डिनैलिटी (cardinality)।
- ज्ञात फैनआउट जोखिम।
- कौन से पाथ डिप्रिकेटेड (deprecated) हैं।
केवल कोड लिखने के बजाय, सिस्टम को सुरक्षा के बारे में तर्क (reasoning) करना चाहिए। इसे भरोसेमंद पाथ चुनना चाहिए या जब पाथ स्पष्ट न हों तो मदद मांगनी चाहिए।
वर्तमान सिस्टम में कमी नामों को मैप करने से लेकर SQL जेनरेट करने के बीच के अंतर में है। आपको रिलेशनशिप कॉन्टेक्स्ट (relationship context) की एक परत जोड़नी होगी।
Text-to-SQL केवल भाषा की समस्या नहीं है। यह कॉन्टेक्स्ट (context) की समस्या है।
जब तक मॉडल यह नहीं समझ जाते कि कौन से जॉइन सुरक्षित हैं, वे डेमो में तो काम करेंगे लेकिन प्रोडक्शन में विफल हो जाएंगे।
Source: https://dev.to/arisyndata/why-text-to-sql-breaks-when-the-join-path-is-not-obvious-3bk0
Optional learning community: https://t.me/GyaanSetuAi