आप यह नहीं सीख रहे हैं कि LLM से SQL कैसे लिखवाया जाए। आप यह सीख रहे हैं कि बार-बार होने वाले BI वर्कलोड के लिए प्रोडक्शन-सेफ SQL कैसे डिलीवर किया जाए, जहाँ अगर क्वेरी गलत, धीमी या दोबारा न चलाई जा सकने वाली (non-reproducible) हो, तो उसके कारण होने वाली आगे की समस्याओं की ज़िम्मेदारी आपकी होती है। AI ड्राफ्टिंग, हाइपोथीसिस की डीबगिंग और ट्रेड-ऑफ का सारांश बनाने में तेज़ी लाता है। आप सिमेंटिक्स (अर्थ) की पुष्टि करते हैं, थ्रेशोल्ड सेट करते हैं और तय करते हैं कि क्या रिलीज़ किया जाएगा।
यह कोर्स एक ऐसी क्षमता बनाता है जिसे कहीं और भी इस्तेमाल किया जा सकता है। आप अनुरोध को सटीक रूप से परिभाषित करेंगे, ज़रूरी संदर्भ (context) देंगे, कैंडिडेट SQL बनाएंगे और कुछ भी शेयर या शेड्यूल करने से पहले वेरिफिकेशन गेट्स (जाँच के चरण) से गुज़रेंगे। हर लेसन उस डिलीवरी अनुशासन का एक हिस्सा जोड़ता है ताकि AI की मदद से आपकी गति बढ़े, लेकिन आपकी विश्वसनीयता का स्तर कम न हो।
किसी भी खास तकनीक का इस्तेमाल करने से पहले, डिलीवरेबल (जो चीज़ डिलीवर करनी है) पर ध्यान दें। डिलीवरेबल का मतलब है एक क्वेरी और साथ में वेरिफिकेशन के सबूत (artifacts), जिन्हें कोई दूसरा एनालिस्ट दोबारा चला सके, रिव्यू कर सके और उन पर भरोसा कर सके।
इसका व्यावहारिक दायरा उन बार-बार चलने वाली क्वेरीज़ तक है जो डैशबोर्ड, अलर्ट और शेड्यूल किए गए एक्सट्रैक्ट्स को डेटा देती हैं। इसका मतलब है कि SQL का सही लेवल (grain) पर सही होना, डेटा बढ़ने पर भी स्थिर रहना और रिव्यू करने वालों को आसानी से समझाया जा सकने वाला होना ज़रूरी है। AI जॉइन्स, विंडो फंक्शन्स और रिफ़ैक्टर्स का सुझाव दे सकता है। सिर्फ़ आप ही यह सर्टिफ़ाई कर सकते हैं कि क्वेरी बिज़नेस की परिभाषाओं से मेल खाती है और इससे आपके कॉस्ट और लेटेंसी बजट से ज़्यादा खर्च या समय नहीं लगेगा।
उस डिलीवरी आर्किटेक्चर का रिव्यू करें जिसके तहत आप काम कर रहे हैं, जिसमें यह भी शामिल है कि वेरिफिकेशन के सबूत कहाँ से आते हैं।
AI से बनी हर क्वेरी को सिर्फ़ एक संभावित विकल्प (candidate) मानें, पक्का जवाब नहीं। अगर यह प्रोडक्शन में जाती है और डैशबोर्ड खराब कर देती है, तो इसकी ज़िम्मेदारी उस एनालिस्ट और टीम की होगी जिन्होंने इसे मंज़ूरी दी थी, न कि मॉडल की।
AI के आउटपुट की क्वालिटी इस बात पर निर्भर करती है कि आप उसे कितना कॉन्टेक्स्ट (संदर्भ) देते हैं। SQL के लिए, कम-से-कम ज़रूरी पैकेज का मतलब बिज़नेस के बारे में सिर्फ़ एक पैराग्राफ़ लिखना नहीं है। यह असल में कुछ शर्तों (constraints) का सेट है, जिनका इस्तेमाल करके मॉडल बिना किसी नए स्ट्रक्चर को बनाए ही जॉइन कीज़, फ़िल्टर और एग्रीगेशन तैयार कर सकता है।
इसमें स्कीमा और जॉइन पाथ, हर टेबल का ग्रेन (डेटा का लेवल), ज़रूरी शर्तें (constraints), ज़रूरी फ़िल्टर, आपके वेयरहाउस की डायलैक्ट (भाषा/तरीका), और ऑपरेशनल शर्तें जैसे SLA और कॉस्ट सेंसिटिविटी शामिल करें। साथ ही, मंज़ूर किए गए अनुमानों (approximations) के बारे में भी बताएं, जैसे कि क्या देर से आने वाले इवेंट्स को नज़रअंदाज़ किया जा सकता है या क्या अलग-अलग काउंट (distinct counts) अनुमानित हो सकते हैं।
एक ई-कॉमर्स वेयरहाउस के लिए कॉन्टेक्स्ट पैकेज बनाएं और देखें कि कैसे हर छूटी हुई जानकारी एक फ़ेलियर मोड (काम न करने की वजह) बन जाती है।
एक अच्छा प्रॉम्प्ट एक कॉन्ट्रैक्ट की तरह होता है। यह मकसद बताता है और उन हिस्सों को तय करता है जो वरना बदल सकते हैं, जैसे कि जॉइन लॉजिक, नल (null) का व्यवहार और अनुमानित कार्डिनैलिटी। AI सिंटैक्स लिख सकता है। आपको यह बताना होगा कि क्वेरी का क्या मतलब हो सकता है।
आउटपुट का लेवल साफ़ तौर पर तय करें, जैसे कि चैनल के हिसाब से साप्ताहिक रेवेन्यू। किन चीज़ों को शामिल नहीं करना है, यह तय करें, जैसे कि रिटर्न और कैंसल किए गए ऑर्डर। नल (null) को कैसे हैंडल करना है, यह तय करें, जैसे कि क्या अनजान चैनल को '(unknown)' माना जाए या उसे फ़िल्टर करके हटा दिया जाए। अनुमानित रो (row) की संख्या बताएं, जैसे कि 52 हफ़्ते और 8 चैनल, ताकि आप तुरंत ‘जॉइन एक्सप्लोजन’ का पता लगा सकें।
एक ऐसा स्ट्रक्चर्ड प्रॉम्प्ट तैयार करें जो SQL बनने से पहले ही इन शर्तों को लागू करे।