कोड जनरेशन: पायथन (पांडा) और एसक्यूएल के साथ एआई-सहायता प्राप्त विश्लेषण

लाभ:

• मजबूत एसक्यूएल और पांडा कोड लेने और कृत्रिम बुद्धिमत्ता को स्पष्ट स्कीमा और उद्देश्य देकर इसे लाइन दर लाइन पढ़ने और सत्यापित करने की क्षमता
• मर्ज/जॉइन के बाद पंक्ति गणना, फिटिंग फ़ंक्शन और थ्रूपुट जैसी मूक त्रुटियों को पकड़ने की क्षमता
• समस्या को शांत किए बिना डिबग में हल करने की क्षमता और उत्पादन परिवेश में परीक्षण किए बिना कोड को चलाने से बचने की क्षमता

डेटा विज्ञान की दो प्राथमिक भाषाएँ हैं: SQL (संरचित क्वेरी भाषा - डेटाबेस से डेटा क्वेरी करने की भाषा) और पायथन (विशेष रूप से, पांडा लाइब्रेरी - प्रोग्रामेटिक रूप से तालिकाओं में हेरफेर करने के लिए मानक उपकरण)। इस इकाई में, हम एआई को एक कोड पार्टनर के रूप में उपयोग करना सीखेंगे: सही प्रश्नों के साथ इससे ठोस एसक्यूएल और पांडा कोड प्राप्त करना, उस कोड को पढ़ना और मान्य करना, इसे डीबग करना, और इसे कभी भी आँख बंद करके नहीं चलाना। एआई मिनटों के बजाय सेकंडों में दोहराव वाला कोड लिखता है; लेकिन यह सुनिश्चित करना आपका काम है कि जो कोड वह उत्पन्न करता है वह सही कॉलम को सही तर्क के साथ संसाधित करता है। वर्किंग कोड का मतलब सही कोड नहीं है.

AI के साथ कोड बनाना शक्तिशाली लेकिन जोखिम भरा क्यों है?

एआई कोड जनरेशन में तीन बड़े लाभ प्रदान करता है: गति (सेकंड में 30-लाइन ग्रुपबाय-पिवट ऑपरेशन लिखता है), अनुस्मारक (आपको एक पांडा फ़ंक्शन की याद दिलाता है जिसे आप भूल गए थे), और शिक्षण (कोड लाइन को लाइन द्वारा समझाता है)। लेकिन इसमें तीन जोखिम हैं: साइलेंट लॉजिक एरर (कोड जो गलत कॉलम को जोड़ता है, त्रुटियों के बिना चलता है), फिटेड फ़ंक्शन (एक ऐसी विधि का सुझाव देता है जो मौजूद नहीं है), और यील्ड ट्रैप (कोड जो छोटे डेटा पर काम करता है लेकिन 10 मिलियन पंक्तियों पर क्रैश हो जाता है)। तो सुनहरा नियम: एआई के कोड को ऐसे पढ़ें जैसे कि आपने इसे स्वयं लिखा हो। वह लाइन न चलाएं जो आपको समझ में न आए।

एसक्यूएल: स्रोत पर डेटा संसाधित करें

SQL आपको डेटाबेस से डेटा पुनर्प्राप्त करने और उसे वहां संसाधित करने की अनुमति देता है; आप लाखों पंक्तियों को पायथन में खींचे बिना सारांशित कर सकते हैं। बुनियादी बिल्डिंग ब्लॉक: चुनें (कौन से कॉलम), कहां (कौन सी पंक्तियां), ग्रुप बाय (समूह और सारांश), जॉइन (टेबल में शामिल हों), हैविंग (पोस्ट-ग्रुप फ़िल्टर)। एआई जटिल जॉइन और विंडो फ़ंक्शंस लिखने में बहुत सहायक है, लेकिन दो चीजों की जांच करना सुनिश्चित करें: क्या जॉइन सही कुंजी के माध्यम से है (गलत कुंजी पंक्तियों को डुप्लिकेट करती है) और क्या फ़िल्टर तर्क सही है (विशेष रूप से शून्य व्यवहार और दिनांक सीमा)।

सावधानी: एआई-जनरेटेड SQL क्वेरी को सीधे उत्पादन डेटाबेस के विरुद्ध न चलाएं। पहले एक छोटी प्रति या LIMIT से परीक्षण करें। WHERE शर्त को मान्य किए बिना कभी भी UPDATE/DELETE क्वेरी न चलाएं; एक गलत WHERE पूरी तालिका को हटा सकता है।

पायथन/पांडा: लचीला विश्लेषण

पांडा, पायथन में तालिकाओं (डेटाफ़्रेम) में हेरफेर करने का मानक तरीका है। एआई का सबसे कुशल उपयोग इसे एक स्पष्ट योजना और उद्देश्य देना है। सबसे अधिक उपयोग किए जाने वाले ऑपरेशन: फ़िल्टर, ग्रुपबी, मर्ज, पिवोट_टेबल, लागू करें। एआई इन्हें शीघ्रता से लिखता है; आप जो जांचना चाहते हैं वह तर्क है: क्या सही कॉलम में समूहीकरण है, क्या मर्ज ने पंक्तियों की संख्या को अप्रत्याशित रूप से बदल दिया है (मर्ज के बाद हमेशा पंक्तियों की संख्या की जांच करें), क्या श्रृंखला संचालन मूल को बदल रहे हैं।

लेनदेन

एसक्यूएल

पांडा

चौकी

छानना

कहाँ

df[df.x > 5]

शून्य/NaN व्यवहार

समूहीकरण

समूह द्वारा

df.groupby()

क्या यह सही कॉलम है?

विलय

सम्मिलित हों

df.मर्ज()

पंक्ति संख्या परिवर्तन

सारांश

औसत(), योग()

.मीन(), .योग()

कौन सा कॉलम एकत्र किया गया था

क्रमबद्ध करें

द्वारा ऑर्डर करें

.sort_values()

दिशा (आरोही/अवरोही)

डुप्लिकेशन

विशिष्ट

.drop_डुप्लिकेट्स()

कौन से कॉलम में?

डिबगिंग: एआई के साथ

जब कोड विफल हो जाता है, तो AI एक उत्कृष्ट डिबगिंग भागीदार है। इसे पूर्ण त्रुटि संदेश और प्रासंगिक कोड स्निपेट दें। लेकिन दो जालों से सावधान रहें. सबसे पहले, एआई एक समाधान सुझा सकता है जो त्रुटि को "खामोश" कर देता है (उदाहरण के लिए, अलर्ट छिपाना) - यह त्रुटि को ठीक नहीं करता है, यह इसे छुपाता है। दूसरा, एआई कभी-कभी किसी समस्या को "समाधान" करते समय चुपचाप दूसरे व्यवहार को बदल देता है। नियम: समाधान को समझें, समाधान को म्यूट न करें और सत्यापित करें कि समाधान के बाद भी आउटपुट सही है।

व्याख्यायोग्य और रखरखाव योग्य कोड चाहते हैं

एआई से कोड खरीदते समय, ऐसा कोड मांगें जो पढ़ने योग्य और रखरखाव योग्य हो, न कि केवल "काम करने वाला" कोड। जब आप या आपका कोई सहकर्मी महीनों बाद उस कोड को खोलता है, तो उसे यह समझने में सक्षम होना चाहिए कि यह क्या करता है। ऐसा करने के लिए, एआई में तीन चीजों को शामिल करने की आदत बनाएं: सार्थक चर नाम (ऑर्डर_टेमिज़, डीएफ2 नहीं), महत्वपूर्ण चरणों पर छोटी टिप्पणी पंक्तियां (यह बताएं कि क्यों, क्या नहीं किया जा रहा है), और एक जादुई संख्या के बजाय एक नामित स्थिरांक (कोड में दफन 0.85 के बजाय ACCEPT_ESIGI = 0.85)। इसके अलावा लंबी एकल-पंक्ति श्रृंखलाओं (पांच क्रियाओं को एक पंक्ति में जोड़ना) से बचें; ये डिबगिंग को कठिन बनाते हैं। डिफ़ॉल्ट रूप से, AI अक्सर संक्षिप्त और "स्मार्ट" कोड उत्पन्न करता है; यदि आप स्पष्ट रूप से कहते हैं "पढ़ने योग्य, व्याख्या करने योग्य, रखरखाव योग्य लिखें", तो आपको बहुत अधिक रखरखाव योग्य आउटपुट मिलेगा। यह प्रतिलिपि प्रस्तुत करने योग्यता का आधार भी है (यूनिट 10): जो कोड समझ में नहीं आता है वह कोड है जिसे सुरक्षित रूप से दोबारा नहीं चलाया जा सकता है।

तीन मिनी मामले

केस 1 - जॉइन प्रतिकृति। एक विश्लेषक ने ऑर्डर को उत्पाद तालिका के साथ जोड़ा और पाया कि कुल कारोबार 3 गुना अधिक था। कारण: प्रत्येक उत्पाद की उत्पाद तालिका में कई पंक्तियाँ (अलग-अलग रंग) थीं; JOIN प्रत्येक ऑर्डर को डुप्लिकेट किया गया। एआई का कोड "काम कर रहा था", लेकिन लाइनों की संख्या 240 हजार से बढ़कर 690 हजार हो गई थी। पाठ: मर्ज/जॉइन के बाद हमेशा लाइनों की संख्या जांचें।

केस 2 - फिटिंग फ़ंक्शन। उन्होंने एक प्रशिक्षु को AI df.groupby('x').summarize() का सुझाव दिया; पांडा में ऐसी कोई विधि नहीं है (वहाँ .agg() है)। कोड काम नहीं किया, इंटर्न 20 मिनट के लिए गायब हो गया। पाठ: उस फ़ंक्शन को सत्यापित करें जिसे आप दस्तावेज़ से नहीं पहचानते हैं; एआई तरीके बना सकता है।

केस 3 - उपज पतन। एक कोड प्रत्येक पंक्ति के लिए आवेदन में डेटाबेस से पूछताछ कर रहा था; यह 5,000 लाइनों पर चला, 4 मिलियन लाइनों पर 9 घंटे लगा और रुक गया। जब एआई ने वेक्टरकृत (बैच) समाधान का सुझाव दिया, तो समय घटाकर 40 सेकंड कर दिया गया। पाठ: छोटे डेटा पर काम करने वाला कोड बड़े डेटा पर क्रैश हो सकता है; दक्षता पर विचार करें.

चार प्रतिलिपि योग्य टेम्पलेट

1) स्कीमा के साथ एसक्यूएल का अनुरोध करना:

आपकी भूमिका: SQL सहायक (PostgreSQL)। तालिकाएँ: - ऑर्डर (आईडी, ग्राहक_आईडी, दिनांक टाइमस्टैम्प, राशि संख्यात्मक) - ग्राहक (आईडी, शहर पाठ) कार्य: 2024 में प्रति शहर कुल टर्नओवर और ऑर्डर की संख्या प्राप्त करें, टर्नओवर के आधार पर अवरोही क्रम में क्रमबद्ध करें। बताएं कि आप NULL शहरों को कैसे संभालते हैं। मैं पहले LIMIT के साथ क्वेरी का परीक्षण करूंगा; अद्यतन/हटाएँ पीढ़ी।

2) चेकपॉइंट के साथ पांडा प्रक्रिया:

मेरे पास DataFrames df (ऑर्डर) और df_customers (ग्राहक) हैं। प्रति शहर औसत राशि की गणना करें. महत्वपूर्ण: मर्ज से पहले और बाद में पंक्तियों की संख्या प्रिंट करें ताकि मैं देख सकूं कि कोई दोहराव है या नहीं। बताएं कि आपने किस कॉलम में विलय किया है और आपने आंतरिक/बाएं क्यों चुना है।

3) कोड स्पष्टीकरण और सत्यापन:

निम्नलिखित पांडा कोड को पंक्ति दर पंक्ति समझाएं: प्रत्येक पंक्ति क्या करती है, यह क्या धारणा बनाती है, किन मामलों में यह गलत परिणाम दे सकती है? अगर मैंने फ़ज फ़ंक्शन का उपयोग किया है तो मुझे बताएं। कोड: [चिपकाएं]

4) डिबगिंग:

यह कोड यह त्रुटि देता है. पूर्ण त्रुटि संदेश: [चिपकाएँ]। कोड: [पेस्ट करें]. त्रुटि का मूल कारण बताएं और उसे ठीक करें। समस्या को वास्तव में हल करके इसे ठीक करें, न कि चेतावनी को शांत करके। यह भी बताएं कि क्या फिक्स ने आउटपुट बदल दिया है।

कमजोर संकेत/मजबूत संकेत

कमजोर संकेत:

एक क्वेरी लिखें जो मुझे प्रति शहर बिक्री बताए।

तालिका के नाम, कॉलम, डेटाबेस प्रकार, शून्य व्यवहार अस्पष्ट हैं। एआई सामान्य है, यह संभवतः एक ऐसी क्वेरी उत्पन्न करेगा जो आपकी तालिका में फिट नहीं होगी।

शक्तिशाली संकेत:

आपकी भूमिका: SQL सहायक (MySQL 8)। तालिका: बिक्री (आईडी, शहर वर्चर, राशि दशमलव, दिनांक दिनांक)। कार्य: वर्ष 2024 के लिए प्रति शहर ऑर्डर की कुल और औसत राशि, संख्या प्राप्त करें; कुल राशि के अनुसार घटते हुए क्रमबद्ध करें; केवल 100 से अधिक ऑर्डर वाले शहर दिखाएं (HAVING).NULL शहर को बाहर रखें। प्रश्न स्पष्ट करें; मैं LIMIT के साथ परीक्षण करूंगा.

यहां डेटाबेस, स्कीमा, फ़िल्टर, सॉर्टिंग और NULL नियम स्पष्ट हैं।

सामान्य गलतियाँ

• कोड को बिना पढ़े चलाना। वर्किंग कोड सही कोड नहीं है; गलत कॉलम में हेरफेर करने वाला कोड भी त्रुटियों के बिना चलता है।
• मर्ज/जॉइन के बाद पंक्तियों की संख्या की जाँच नहीं करना। गलत कुंजी चुपचाप पंक्तियों की नकल करती है और कुल को बढ़ा देती है।
• फिटिंग फ़ंक्शन का सत्यापन नहीं किया जा रहा है. एआई ऐसे तरीके सुझा सकता है जो मौजूद नहीं हैं; दस्तावेज़ से पुष्टि करें कि आप इसे नहीं पहचानते।
• दक्षता के बारे में नहीं सोच रहे. लागू/लूप लाखों पंक्तियों पर छोटे डेटा क्रैश पर काम कर रहा है; सदिशीकरण
• सीधे उत्पादन डेटाबेस पर चलाएँ। विशेषकर WHERE या परीक्षण के बिना UPDATE/DELETE चलाना विनाशकारी है।

युक्ति: एआई से प्राप्त कोड के प्रत्येक टुकड़े में एक "सत्यापन लाइन" जोड़ने की आदत डालें: लाइनों की एक पूर्व और बाद की प्रसंस्करण संख्या, कुछ नमूना लाइनें, और हाथ से एक महत्वपूर्ण कुल। ये तीन जाँचें अधिकांश मूक तर्क त्रुटियों को पकड़ती हैं।

संक्षेप में

एआई एक शक्तिशाली भागीदार है जो तेजी से एसक्यूएल और पांडा कोड तैयार करता है, लेकिन यह कोई अंध प्राधिकार नहीं है। उसे योजना और उद्देश्य स्पष्ट रूप से बताएं; इससे उत्पन्न कोड को ऐसे पढ़ें जैसे कि आपने इसे स्वयं लिखा हो; मर्ज/जॉइन के बाद पंक्तियों की संख्या, फिटिंग फ़ंक्शन और थ्रूपुट की जांच करें; इसे उत्पादन डेटाबेस पर परीक्षण किए बिना न चलाएं। डिबगिंग करते समय, समस्या को हल करने का लक्ष्य रखें, न कि उसे शांत करने का। जो कोड काम करता है वह सही कोड नहीं है; केवल आप ही सटीकता की गारंटी दे सकते हैं.

आवेदन कार्य

एक विश्लेषण प्रश्न चुनें (उदाहरण के लिए "प्रति चैनल मासिक टर्नओवर") और SQL और पांडा दोनों के साथ AI से कोड का अनुरोध करें। दोनों कोड को लाइन दर लाइन पढ़ें, मर्ज/जॉइन के बाद लाइनों की संख्या जांचें और कम से कम एक महत्वपूर्ण योग को मैन्युअल रूप से सत्यापित करें। तुलना करें कि क्या दोनों कोड समान परिणाम देते हैं; यदि भिन्न है, तो कारण जानें।

जांच सूची

• [ ] क्या मैंने एआई को तालिका/स्कीमा और उद्देश्य स्पष्ट रूप से बता दिया है?
• [ ] क्या मैंने पंक्ति दर पंक्ति उसके द्वारा उत्पादित कोड को पढ़ा और समझा?
• [ ] क्या मैंने मर्ज/जॉइन के बाद लाइनों की संख्या की जाँच की?
• [ ] क्या मैंने उन कार्यों को सत्यापित किया है जिन्हें मैं दस्तावेज़ीकरण से नहीं पहचानता?
• [ ] क्या मैंने पहले सुरक्षित/छोटे डेटा पर कोड का परीक्षण किया है, उत्पादन परिवेश में नहीं?