एंटरप्राइझमध्ये Text-to-SQL का अपयशी ठरते

बहुतेक Text-to-SQL डेमो खूपच सोपे असतात.

ते साधे स्कीमा (schemas) आणि स्पष्ट टेबल नावे वापरतात. एक किंवा दोन टेबल्स एकमेकांशी अचूकपणे जोडलेले आहेत असे ते गृहीत धरतात. हे डेमोसाठी ठीक आहे, पण खऱ्या कंपनीमध्ये ते अपयशी ठरते.

एंटरप्राइझ डेटाबेसमध्ये, कठीण भाग 'SELECT' क्लॉज नसून 'join path' हा असतो.

एखादे मॉडेल ग्राहकानुसार महसूल (revenue) मिळवण्यासाठी एक वैध क्वेरी लिहू शकते. SQL रन होते. डॅशबोर्डवर आकडे दिसतात. पण उत्तर चुकीचे असते.

हे का घडते?

  • कस्टमर टेबल ही अधिकृत मास्टर लिस्ट नाही.
  • महसूल (revenue) फील्ड हे फायनान्सने मंजूर केलेले व्हर्जन नाही.
  • विविध क्षेत्रांमध्ये रेकॉर्ड्सची पुनरावृत्ती (duplicate) झालेली असते.
  • जॉइनमुळे 'fanout' त्रुटी निर्माण होतात.
  • आर्थिक कॅलेंडर (fiscal calendars) हे सामान्य कॅलेंडर वर्षांपेक्षा वेगळे असतात.

सिंटॅक्टिकली (syntactically) वैध असलेली क्वेरी म्हणजे विश्वासार्ह क्वेरी असा होत नाही.

वास्तविक प्रोडक्शन सिस्टम्स खूप गुंतागुंतीच्या असतात. तुम्हाला मिसिंग फॉरेन कीज (foreign keys), लेगसी टेबल्स आणि 'one-to-many' रिलेशनशिप्सचा सामना करावा लागतो, ज्यामुळे आकडे चुकीच्या पद्धतीने वाढू शकतात. अगदी माणसांनाही एखाद्या जॉइनवर विश्वास ठेवण्यापूर्वी जुने रिपोर्ट तपासावे लागतात किंवा फायनान्स विभागाला विचारावे लागते.

AI मॉडेलला फक्त नावे आणि कॉलम्स दिसतात. ते अंदाज लावते. कधीकधी हा अंदाज धोकादायक ठरू शकतो.

'fanout' चा विचार करा. जर तुम्ही 'orders' ला 'order lines' शी आणि त्यानंतर 'shipments' शी जॉइन केले, तर एक ऑर्डर अनेक वेळा मोजली जाऊ शकते. SQL बरोबर असते, पण निकाल चुकीचा असतो.

मेटाडेटा (Metadata) मदत करतो, पण तो पुरेसा नाही. एखादे रिलेशनशिप फायनान्शिअल रिपोर्टिंगसाठी सुरक्षित आहे की नाही, हे कॉलमची नावे सांगू शकत नाहीत. फॉरेन कीज ऐतिहासिक अपवाद स्पष्ट करत नाहीत.

Text-to-SQL ला 'relationship intelligence' ची गरज आहे.

एका विश्वासार्ह सिस्टमला खालील गोष्टी माहित असणे आवश्यक आहे:

  • विशिष्ट व्यावसायिक प्रश्नांसाठी मंजूर केलेले जॉइन पाथ्स (join paths).
  • रिलेशनशिप कार्डिनॅलिटी (Relationship cardinality).
  • माहित असलेले fanout धोके.
  • कोणते पाथ्स आता वापरात नाहीत (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