कोडजेन डेव टूल (जीपीटी पायलट) पर 6 महीने काम करने के बाद, मैंने यही सीखा

पिछले 6 महीनों से, मैं यह समझने के लिए GPT पायलट ( https://github.com/Pythagora-io/gpt-pilot ) पर काम कर रहा हूं कि हम वास्तव में AI के साथ कोडिंग को कितना स्वचालित कर सकते हैं, इसलिए मैं अपनी सीख साझा करना चाहता था यह कितनी दूर तक और कितनी दूर तक जाने में सक्षम है।

जब मैंने जीपीटी पायलट का निर्माण शुरू किया, तो मैंने यह ब्लॉग पोस्ट लिखा कि इसकी कल्पना कैसे की जाती है। अब, मैं अपनी संशोधित सोच साझा करना चाहता हूं और यह बताना चाहता हूं कि क्या काम आया और क्या नहीं।

अंत में, आप उन ऐप्स के उदाहरण देखेंगे जो GPT पायलट के साथ बनाए गए थे और आप वास्तविक AI जोड़ी प्रोग्रामर के साथ एक ऐप कैसे बना सकते हैं।

GPT पायलट के पीछे क्या विचार है?

जीपीटी पायलट की कल्पना एक वास्तविक एआई डेवलपर के रूप में की गई है - एक स्वत: पूर्ण या चैटबॉट नहीं । बल्कि, यह एक डेवलपर है जो आपके ऐप या फीचर को कैसे बनाया जाना चाहिए, इसके लिए एक योजना बनाता है और कोडिंग शुरू करता है। यह अधिकांश कोडिंग स्वयं करना चाहता है, लेकिन जब यह अटक जाता है, तो इसे दी गई आवश्यकताओं के बारे में स्पष्टीकरण की आवश्यकता होती है, या कोड समीक्षा की आवश्यकता होती है, यह आपसे मदद मांगता है।

क्या AI एक जूनियर डेवलपर की तरह है? या…

मैं अक्सर CodeGen GPT-4-आधारित टूल देखता हूं जो कहते हैं कि वे एक AI जूनियर डेवलपर का निर्माण कर रहे हैं।

किसी न किसी तरह, मुझे इससे हमेशा एक समस्या रही है क्योंकि जब मैं कोडिंग के लिए चैटजीपीटी का उपयोग करता हूं, तो यह मुझे ऐसे उत्तर और विचार देता है जो केवल एक अति-वरिष्ठ व्यक्ति ही दे सकता है - कुछ ऐसा जिसे कोई भी कनिष्ठ डेवलपर भी समझ नहीं पाएगा। फिर भी, कोई भी एलएलएम एक वरिष्ठ डेवलपर जितना अच्छा ऐप नहीं बना सकता है, लेकिन कोडिंग के बारे में GPT-4 का ज्ञान किसी भी जूनियर डेवलपर से कहीं अधिक है।

मैं कहूंगा कि GPT-4 को सॉफ्टवेयर विकास के हर हिस्से के बारे में इतना ज्ञान है जैसे कि यह दुनिया का सबसे वरिष्ठ डेवलपर हो, लेकिन उसकी याददाश्त एक सुनहरी मछली की तरह है। मैं इसे एक अलौकिक रोबोट के रूप में देखता हूं जो एक कमरे के बीच में खड़ा है और एक समय में केवल एक छोटी सी कार्रवाई कर सकता है, लेकिन यह कई क्रियाओं को संयोजित नहीं कर सकता है और दोहराव से काम नहीं कर सकता है। आपको इसे ठीक-ठीक बताना होगा कि इसे आगे क्या करना चाहिए।

जीपीटी पायलट के साथ हम यही चाहते हैं - हम एलएलएम के लिए सोच का एक ढांचा तैयार करना चाहते हैं जो उस अलौकिक रोबोट को अपने पिछले कार्यों को संशोधित करके लगातार काम करने के लिए प्रेरित करता है, एक फीडबैक लूप रखता है, और यह निर्धारित करता है कि उसे आगे क्या करना चाहिए। अंतिम लक्ष्य को पूरा करने के लिए, जो एक उत्पादन-तैयार एप्लिकेशन का निर्माण करना है।

ऊपर बताए गए ब्लॉग पोस्ट में , मैंने उन मुख्य स्तंभों की रूपरेखा तैयार की है जिन पर जीपीटी पायलट बनाया गया था। लेकिन हमारी टीम की सीख के आधार पर इनमें थोड़ा बदलाव आया है, इसलिए यहां संशोधित स्तंभ दिए गए हैं:

1. एआई की निगरानी के लिए एक इंसान की आवश्यकता न केवल इसलिए है क्योंकि एआई पर्याप्त अच्छा नहीं है, बल्कि इसलिए भी कि आप किसी चीज़ के काम करने के तरीके को बदलना चाहते हैं या उसके कार्यान्वयन के बाद उसकी देखभाल करना चाहते हैं। किसी डेवलपर या उत्पाद प्रबंधक के लिए यह आम बात है कि एक बार जब वे देख लें कि कार्यान्वयन कैसा दिखता है, तो वे इसे बदलने का निर्णय लेते हैं।

   
   

2. या, आपको एहसास होता है कि शुरुआत में आपके अनुमान से कहीं अधिक गंभीर मामले हैं और सोचते हैं कि हर मुद्दे को ठीक करने की तुलना में अपने वर्तमान कार्यान्वयन को दोबारा करना आसान है। समस्या तब होती है जब आप पूरे ऐप को समाप्त कर देते हैं और फिर इसे दोबारा करने का प्रयास करते हैं - यह तब होता है जब यह बहुत कठिन हो जाता है क्योंकि प्रत्येक परिवर्तन अन्य सभी सुविधाओं को प्रभावित करेगा।

   
   

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

   
   

   इस तरह, जीपीटी पायलट अगले कार्य पर आगे बढ़ने से पहले मानव प्रत्येक कार्य के कार्यान्वयन की समीक्षा कर सकता है (पीआर के विलय से पहले एक कोड समीक्षा की तरह)। यदि कोई मानव जीपीटी पायलट को बताता है कि क्या गलत है, तो कार्य के भीतर ही समस्याओं को ठीक करना बहुत आसान हो जाएगा। साथ ही, एलएलएम में यह संदर्भ होता है कि कार्य में क्या करने की आवश्यकता है और अब तक क्या किया गया है।

   
   

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

   
   

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

   
   

5. कोडिंग प्रक्रिया एक सीधी रेखा नहीं है . जब हमने जीपीटी पायलट का पहला संस्करण बनाया, तो हमने सोचा कि इसमें कार्यों को दोहराना, कोड लागू करना, इसे ठीक करना और आगे बढ़ना होगा। वास्तव में, किसी ऐप को कोड करते समय आप लगातार प्रगति नहीं करते हैं - आप हर समय अपना कोड फिर से लिखते हैं।

   
   

   कभी-कभी, आप कोडबेस को रिफैक्टर करते हैं क्योंकि, प्रारंभिक कार्यान्वयन के बाद, आपको एहसास होता है कि किसी चीज़ को लागू करने का एक बेहतर तरीका है। अन्य बार, आप आवश्यकताओं में बदलाव के कारण ऐसा करते हैं। जैसा कि मैंने #1 में उल्लेख किया है, जब आप देखते हैं कि कोई समाधान काम नहीं कर रहा है, तो आपको कभी-कभी कई बदलावों को वापस लेना पड़ता है, समस्या के वैकल्पिक समाधान के बारे में सोचना पड़ता है, और इसे उस तरह से हल करने का प्रयास करना पड़ता है।

   
   

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

हमने क्या सीखा?

एलएलएम, सामान्य तौर पर, एक नई तकनीक है जिसे हर कोई समझने की कोशिश कर रहा है - यह कैसे काम करता है, क्या बेहतर किया जा सकता है, उचित त्वरित इंजीनियरिंग कैसे करें, आदि। हमारा दृष्टिकोण प्राप्त करने पर काम करने के बजाय एप्लिकेशन परत के निर्माण पर ध्यान केंद्रित करना है बेहतर परिणाम देने के लिए एलएलएम ।

तर्क यह है कि एलएलएम बेहतर हो जाएंगे, और यदि हम किसी प्रॉम्प्ट को अनुकूलित करने में सप्ताह बिताते हैं, तो इसे जीपीटी के नए संस्करण के साथ पूरी तरह से हल किया जा सकता है।

इसके बजाय, हम इस बात पर ध्यान केंद्रित कर रहे हैं कि उपयोगकर्ता अनुभव कैसा दिखना चाहिए और एलएलएम को नियंत्रित करने के लिए किन तंत्रों की आवश्यकता है ताकि यह लगातार काम कर सके, अंतिम समाधान के करीब पहुंच सके। तो, यहाँ हमारी अब तक की सीख है:

1. ऐप का प्रारंभिक विवरण जितना हमने सोचा था उससे कहीं अधिक महत्वपूर्ण है । हमारी मूल सोच यह थी कि, मानव के इनपुट के साथ, जीपीटी पायलट सही दिशा में नेविगेट करने और कामकाजी समाधान के करीब और करीब पहुंचने में सक्षम होगा, भले ही प्रारंभिक विवरण अस्पष्ट हो।

   
   

   हालाँकि, जीपीटी पायलट की सोच प्रारंभिक विवरण से शुरू होकर सभी संकेतों में फैलती है। और इसके साथ ही, यदि प्रारंभिक संकेत में कुछ भ्रामक है, तो जीपीटी पायलट के पास मौजूद अन्य सभी जानकारी गलत दिशा में ले जाएगी। इसलिए, जब आप इसे सही रास्ते पर ले जाएंगे, तो यह गलत तरीके से इतना गहरा हो जाएगा कि इसे सही रास्ते पर लाना लगभग असंभव हो जाएगा।

   
   

   अब, जैसा कि मैं यह लिख रहा हूं, यह बहुत स्पष्ट लगता है, लेकिन यह कुछ ऐसा है जिसे हमें सीखने की जरूरत है - प्रारंभिक विवरण पर अधिक ध्यान केंद्रित करने के लिए। इसलिए, हमने "स्पेक राइटर" नामक एक नया एजेंट बनाया, जो कोडिंग शुरू करने से पहले प्रोजेक्ट आवश्यकताओं को तोड़ने के लिए आपके साथ काम करता है।

   
   

2. कोडिंग कोई सीधी रेखा नहीं है . जैसा कि मैंने ऊपर स्तंभ अनुभाग में उल्लेख किया है, रिफैक्टरिंग हर समय होती है, और जीपीटी पायलट को भी ऐसा करना चाहिए। हमने इसके लिए अभी तक कोई समाधान लागू नहीं किया है, लेकिन यह संभवतया जीपीटी पायलट के लिए अपने निर्णय वृक्ष के चारों ओर मार्कर बनाने की क्षमता जोड़कर काम करेगा ताकि जब भी कुछ काम नहीं कर रहा हो, तो वह मार्करों की समीक्षा कर सके और सोच सके कि वह कहां हो सकता है। गलत मोड़ ले लिया.

   
   

3. एजेंट स्वयं समीक्षा कर सकते हैं . मेरी सोच यह थी कि यदि कोई एजेंट समीक्षा करता है कि दूसरे एजेंट ने क्या किया, तो यह अनावश्यक होगा क्योंकि यह वही एलएलएम है जो उसी जानकारी को पुन: संसाधित कर रहा है। लेकिन यह पता चला है कि जब एक एजेंट दूसरे एजेंट के काम की समीक्षा करता है, तो यह आश्चर्यजनक रूप से अच्छा काम करता है। हमारे पास 2 अलग-अलग "समीक्षक" एजेंट हैं जो समीक्षा करते हैं कि कोड कैसे लागू किया गया था।

   
   

   एक इसे उच्च स्तर पर करता है, जैसे कि संपूर्ण कार्य कैसे कार्यान्वित किया गया था, और दूसरा फ़ाइल में किए जाने से पहले प्रत्येक परिवर्तन की समीक्षा करता है (जैसे कि git add -p करना)।

   
   

4. एलएलएम तब सबसे अच्छा काम करते हैं जब वे एक ही प्रॉम्प्ट में कई समस्याओं की तुलना में एक समस्या पर ध्यान केंद्रित कर सकते हैं । उदाहरण के लिए, यदि आप GPT पायलट को एक ही विवरण में 2 अलग-अलग बदलाव करने के लिए कहते हैं, तो उसे दोनों पर ध्यान केंद्रित करने में कठिनाई होगी। इसलिए, यदि इनपुट में कई अलग-अलग अनुरोध हों तो हम प्रत्येक मानव इनपुट को कई टुकड़ों में विभाजित करते हैं।

   
   

5. वर्बोज़ लॉग मदद करते हैं । यह अब बहुत स्पष्ट है, लेकिन शुरुआत में, हमने GPT-4 को कोड के आसपास कोई लॉग जोड़ने के लिए नहीं कहा था। अब, यह वर्बोज़ लॉगिंग के साथ कोड बनाता है, ताकि जब आप ऐप चलाएं और किसी त्रुटि का सामना करें, तो GPT-4 को डिबगिंग करना बहुत आसान हो जाएगा जब वह देखेगा कि कौन से लॉग लिखे गए हैं और वे लॉग कोड में कहां हैं।

   
   

6. कोडबेस को छोटी फ़ाइलों में विभाजित करने से बहुत मदद मिलती है । यह भी एक स्पष्ट निष्कर्ष है, लेकिन हमें इसे सीखना होगा। यदि कोड को कुछ बड़ी फ़ाइलों के बजाय कई फ़ाइलों में विभाजित किया गया है, तो GPT-4 के लिए सुविधाओं को लागू करना और बग्स को ठीक करना बहुत आसान है। ठीक वैसे ही जैसे हम इंसान सोचते हैं - बड़े कोड के बजाय छोटे कोड को प्रोसेस करना बहुत आसान है। हम अमूर्तता के स्तर - फ़ंक्शंस, कक्षाएं इत्यादि बनाकर ऐसा करते हैं।

   
   

   एलएलएम को अधिक प्रबंधनीय अमूर्त बनाने के लिए सबसे आसान तरीकों में से एक यह है कि इसे अधिक मॉड्यूलर कोड बनाने और इसे अधिक फ़ाइलों में विभाजित करने के लिए कहें। यह आश्चर्यजनक रूप से अच्छी तरह से काम करता है, और अंतिम परिणाम हमारे, डेवलपर्स के लिए भी बेहतर है।

   
   

7. किसी इंसान को कोड ठीक करने में सक्षम होने के लिए, उन्हें यह स्पष्ट रूप से दिखाना होगा कि कार्य में क्या लिखा गया था और इसके पीछे का विचार क्या था। जीपीटी पायलट का लक्ष्य सभी कोडिंग कार्यों का 90% करना और शेष 10% मानव पर छोड़ना है। इस 10% में आमतौर पर सुधार या छोटे बदलाव शामिल होते हैं जिन्हें एलएलएम नोटिस करने में संघर्ष करता है, लेकिन मानव के लिए, यह एक साधारण बदलाव हो सकता है।

   
   

   हालाँकि, समस्या यह है कि मानव को यह बताना आसान नहीं है कि क्या काम नहीं कर रहा है और उन्हें किस कोड को देखना चाहिए। यदि GPT पायलट कोड की 3,000 पंक्तियाँ लिखता है, तो मानव डेवलपर, यदि वे GPT पायलट की मदद करना चाहते हैं, तो उन्हें वास्तविक कोड में गोता लगाने से पहले पूरे कोडबेस को समझने की आवश्यकता होती है।

   
   

   जीपीटी पायलट के भविष्य के संस्करणों में, मानव डेवलपर के पास इस बात का विस्तृत विवरण होगा कि वर्तमान कार्य में कौन सा कोड जोड़ा गया है और इसके पीछे क्या तर्क है। इस तरह आप जीपीटी पायलट की मदद कर पाएंगे।

   
   

8. मनुष्य आलसी हैं . एलएलएम में इंसानों से सभी संभावित त्रुटियों के बारे में सोचने देने के बजाय उनसे सवाल पूछना बेहतर है। फिर से, पीछे मुड़कर देखने पर यह बहुत स्पष्ट है, लेकिन एक चीज जो हमने देखी वह यह थी कि लोग उन सवालों का जवाब देने के लिए अधिक इच्छुक थे जो जीपीटी पायलट ने उनसे पूछे थे बजाय एक ओपन-एंड इनपुट फ़ील्ड के जहां वे अनियंत्रित प्रतिक्रिया लिख सकें।

   
   

9. लीक से हटकर सोचने के लिए एलएलएम प्राप्त करना कठिन है । यह मेरे लिए सबसे बड़ी सीख में से एक थी। मैंने सोचा कि आप GPT-4 को कुछ ऐसे समाधान देकर प्रेरित कर सकते हैं जिनका उपयोग वह पहले ही किसी समस्या को ठीक करने के लिए कर चुका है और उसे किसी अन्य समाधान के बारे में सोचने के लिए कह सकता है। हालाँकि, यह उतना आसान नहीं है जितना लगता है।

   
   

   आख़िरकार हमने एलएलएम से उन सभी संभावित समाधानों की सूची बनाने के लिए कहा जिनके बारे में वह सोच सकता था और उन्हें स्मृति में सहेज सकता था। जब हमें कुछ और आज़माने की ज़रूरत पड़ी, तो हमने वैकल्पिक समाधान निकाला और उसे एक अलग, लेकिन विशिष्ट समाधान आज़माने के लिए कहा।

जीपीटी पायलट के साथ बनाए गए ऐप्स

वर्तमान में, आप GPT पायलट के साथ सरल लेकिन गैर-तुच्छ ऐप्स बना सकते हैं। हमने लोगों को जीपीटी पायलट के साथ ऐप बनाते हुए भी देखा है जो बहुत प्रभावशाली हैं, जैसे कि एक ऐप जो ताड़ के पेड़ों की गिनती करने के लिए एक रेसनेट मॉडल को ठीक कर सकता है और फिर, जब आप एक छवि अपलोड करते हैं, तो उसमें पेड़ों की गिनती कर सकते हैं। कोड, आँकड़े और डेमो के साथ हमारे द्वारा बनाए गए कुछ ऐप्स यहां दिए गए हैं:

प्रॉम्प्ट लैब ( डेमो )

इसे स्टेरॉयड पर ओपनएआई प्लेग्राउंड के रूप में सोचें - यह आपको JSON सरणी से वार्तालाप लोड करने या इसे मैन्युअल रूप से दर्ज करने, एलएलएम एक्स के साथ वार्तालाप चलाने, डेटाबेस में वार्तालाप को सहेजने और इसे वापस लोड करने में सक्षम बनाता है। हम वास्तव में इस ऐप का उपयोग तब करते हैं जब हम एक प्रॉम्प्ट इंजीनियर करते हैं और यह देखना चाहते हैं कि यह कैसा व्यवहार करता है।

खेल का मैदान पर्याप्त अच्छा नहीं है क्योंकि एक ही प्रॉम्प्ट को बार-बार चलाने में समय लगता है। प्रॉम्प्ट लैब के साथ, आप चुन सकते हैं कि इसे कितनी बार चलाना है और ऐप को प्रॉम्प्ट को बार-बार चलाने दें।

एक बार यह समाप्त हो जाए, तो आप परिणामों का विश्लेषण कर सकते हैं। यह उन लोगों के लिए उपयोगी हो सकता है जो एआई ऐप बना रहे हैं और उन्हें अपने संकेतों को अनुकूलित करने की आवश्यकता है।

• ⏳ बिताया गया समय: ~2 दिन
• 💾 जीथब रेपो

SQLite डेटाबेस विश्लेषक उपकरण ( डेमो )

यह भी एक ऐप है जिसका उपयोग हम स्थानीय SQLite डेटाबेस का विश्लेषण करने के लिए आंतरिक रूप से करते हैं। यह डेटाबेस से डेटा को ऐसे प्रारूप में खींचता है जो GPT पायलट डेटाबेस संरचना के लिए बहुत विशिष्ट है, लेकिन इसे अन्य संरचनाओं में फिट करने के लिए आसानी से संशोधित किया जा सकता है।

यह आपके SQLite डेटाबेस को पढ़ता है और अपलोड करता है, पंक्तियों को एक विशिष्ट फ़ील्ड द्वारा विभाजित करता है, पंक्तियों को मानों में अनपैक करता है, LLM वार्तालाप डेटा को एक फॉर्म में लोड करता है, और आपको केवल संदेशों में से एक को बदलने और LLM अनुरोध को GPT-4 में सबमिट करने में सक्षम बनाता है। यह देखने के लिए कि परिणाम कैसे दिखेंगे.

इस तरह, आप जीपीटी पायलट के एजेंटों की एलएलएम के साथ हुई बातचीत का विश्लेषण कर सकते हैं और आसानी से पता लगा सकते हैं कि यदि संकेत अलग होते तो क्या होता।

• ⏳ बिताया गया समय: ~2 दिन
• 💾 जीथब रेपो

कोड व्हिस्परर ( डेमो )

कोड व्हिस्पर एक मज़ेदार प्रोजेक्ट है जिसे हमने प्रदर्शन के लिए एक उदाहरण के रूप में बनाया है। विचार यह है कि आप इसका उपयोग अपने कोडबेस के बारे में एलएलएम प्रश्न पूछने के लिए कर सकते हैं। आप सार्वजनिक Github रेपो का लिंक पेस्ट करें।

फिर, यह रिपॉजिटरी को क्लोन करता है, प्रासंगिक फ़ाइलों को विश्लेषण के लिए एलएलएम में भेजता है, जो प्रत्येक फ़ाइल के लिए एक विवरण बनाता है कि कोड क्या करता है, और उन विवरणों को डेटाबेस में सहेजता है।

उसके बाद, आप ऐप से कोडबेस के बारे में प्रश्न पूछ सकते हैं, और कोडबेस आपको प्रतिक्रिया दिखाता है। इस डेमो में, हम GPT-3.5 का उपयोग करते हैं।

• ⏳ बिताया गया समय: 7 घंटे
• 💾 जीथब रेपो

सितारा इतिहास ( डेमो )

मैं वर्षों से ओपन-सोर्स प्रोजेक्ट जारी कर रहा हूं, और मैं हमेशा यह देखना चाहता हूं कि https://star-history.com/ पर अन्य सफल रिपॉजिटरी की तुलना में मेरा जीथब रेपो कितनी तेजी से बढ़ रहा है। समस्या यह है कि स्टार हिस्ट्री पर, मैं ग्राफ़ को ज़ूम करने में असमर्थ हूं, इसलिए 1,000 सितारों वाले एक नए रेपो की तुलना 50,000 वाले बड़े रेपो से नहीं की जा सकती क्योंकि आप यह नहीं देख सकते कि बड़ा रेपो अपनी शुरुआत में कैसे करता है .

इसलिए, मैंने GPT पायलट से यह कार्यक्षमता बनाने के लिए कहा। यह स्टारगेज़र्स के लिए जीथब रिपोज़ को स्क्रैप करता है, उन्हें डेटाबेस में सहेजता है, उन्हें एक ग्राफ़ पर प्लॉट करता है, और ग्राफ़ को ज़ूम इन और आउट करने में सक्षम बनाता है।

• ⏳ बिताया गया समय: 6 घंटे
• 💾 जीथब रेपो

निष्कर्ष

मुझे आशा है कि आपको वर्तमान स्थिति, समस्याओं और निष्कर्षों के बारे में कुछ जानकारी प्राप्त हुई होगी जिनसे हम जीपीटी पायलट में निपटते हैं।

तो, पुनर्कथन करने के लिए:

हमारा मानना है कि एक वास्तविक AI डेवलपर टूल निम्नलिखित स्तंभों पर आधारित होना चाहिए:

• AI की निगरानी के लिए एक इंसान की आवश्यकता होती है।

  
  

• हमें एआई को अपनी गलतियों को दोहराने में सक्षम बनाना चाहिए।

  
  

• सॉफ्टवेयर विकास को व्यवस्थित किया जा सकता है , जिसे एलएलएम के शीर्ष पर एक परत पर लागू किया जाना चाहिए।

  
  

• एआई डेवलपर को कोडबेस को दोबारा तैयार करने में सक्षम होना चाहिए क्योंकि, वास्तव में, कोडिंग प्रक्रिया एक सीधी रेखा नहीं है।

अब तक, हमने यह सीखा है:

1. प्रारंभिक ऐप विवरण जितना हमने सोचा था उससे कहीं अधिक महत्वपूर्ण है

2. कोडिंग कोई सीधी रेखा नहीं है, एजेंट स्वयं समीक्षा कर सकते हैं

3. एलएलएम तब सबसे अच्छा काम करते हैं जब वे एक ही प्रॉम्प्ट में कई समस्याओं की तुलना में एक समस्या पर ध्यान केंद्रित करते हैं

4. वर्बोज़ लॉग चमत्कार करते हैं

5. कोडबेस को छोटी फ़ाइलों में विभाजित करने से बहुत मदद मिलती है

6. एक इंसान के लिए कोड को ठीक करने में सक्षम होना

7. उन्हें स्पष्ट रूप से दिखाया जाना चाहिए कि क्या लिखा गया है और उसके पीछे का विचार क्या है

8. मनुष्य आलसी हैं

9. एलएलएम को दायरे से बाहर सोचना कठिन है

   
   

आप क्या सोचते हैं? क्या आपने एलएलएम के साथ अपनी बातचीत में इनमें से किसी व्यवहार पर ध्यान दिया है, या क्या इनमें से किसी पर आपकी राय अलग है?

मुझे आपकी बात सुनकर बहुत खुशी होगी, इसलिए नीचे एक टिप्पणी छोड़ें या मुझे [email protected] पर एक ईमेल भेजें।

आप यहां GPT पायलट के साथ AI के साथ एक ऐप बनाने का प्रयास कर सकते हैं:

• जीपीटी पायलट ओपन सोर्स रेपो
• जीपीटी पायलट वीएस कोड एक्सटेंशन

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

यहाँ भी प्रकाशित किया गया