नफा:
- वास्तविक उदाहरणांमधून सर्वात सामान्य प्रॉम्प्ट त्रुटी ओळखते
- प्रत्येक त्रुटीसाठी व्यावहारिक आणि पुनरावृत्ती करण्यायोग्य निराकरण लागू करू शकते
- हे लक्षात येते की खराब आउटपुट बर्याचदा खराब प्रॉम्प्टमुळे होते
या मॉड्युलमध्ये, आम्ही एक एक करून चांगले प्रॉम्प्ट्स लिहिण्याचे तंत्र शिकलो. आता याला वेगळ्या कोनातून बळकट करू या: सर्वात सामान्य चुका आणि त्यांचे निराकरण पाहून. बहुतेक खराब एआय आउटपुट खराब प्रॉम्प्टिंगमुळे आहे, मॉडेल अपुरेपणामुळे नाही. तुम्ही या युनिटमधील त्रुटी ओळखल्यास, तुम्ही तुमच्या स्वतःच्या प्रॉम्प्टमध्ये समस्यांचे त्वरीत निदान आणि निराकरण करू शकता; "एआय हे करू शकत नाही" असे म्हणण्याऐवजी तुम्ही म्हणू शकता "मला माझ्या प्रॉम्प्टचे असे निराकरण करू द्या".
त्रुटी ओळखणे का महत्त्वाचे आहे?
जेव्हा एखादे आउटपुट तुमच्या अपेक्षा पूर्ण करत नाही, तेव्हा तुम्ही दोन प्रकारे प्रतिक्रिया देऊ शकता: साधनाला दोष द्या किंवा प्रॉम्प्टवर प्रश्न विचारा. अनुभवी वापरकर्ता नंतरचे करतो. कारण बहुतेक वेळा, समस्येचा स्रोत स्पष्ट असतो आणि परिणाम थोड्या दुरुस्त्याने बदलतो. खाली आपण आठ सर्वात सामान्य त्रुटी, त्यांची लक्षणे आणि उपाय पाहू.
आठ सर्वात सामान्य चुका
त्रुटी
लक्षण
उपाय
अस्पष्टता
जेनेरिक, "एक आकार सर्वांसाठी फिट आहे" उत्तर
मोजण्यायोग्य सूचना द्या
शून्य संदर्भ
आउटपुट जे परिस्थितीशी जुळत नाही
कोण/का/इतिहास जोडा
स्वरूप निर्दिष्ट करत नाही
चुकीच्या स्वरूपात आउटपुट
सक्तीचे स्वरूप
निर्बंधांची अनुपस्थिती
अत्यधिक, विचलित सामग्री
"नको" यादी जोडा
ओव्हरलोड
मॉडेल काही विनंत्या वगळते
कामाची विभागणी करा, प्राधान्य द्या
पुष्टी न करणे
बनावट माहिती वापरणे
स्त्रोतासह तथ्य तपासा
एक शॉट अपेक्षा
पहिल्या बाहेर पडताना हार मानू नका
पुनरावृत्ती करा
विरोधाभासी सूचना
विसंगत आउटपुट
मर्यादा संरेखित करा
स्टेप बाय स्टेप डायग्नोस्टिक पद्धत
दूषित आउटपुट आल्यावर, या क्रमाचे अनुसरण करा:
- मिशन स्पष्ट आहे का? क्रियापद ठोस आहे, याचा अर्थ तुम्हाला पाहिजे तीच गोष्ट आहे का?
- संदर्भ पुरेसा आहे का? मॉडेलला परिस्थिती माहित आहे का?
- स्वरूप नमूद केले आहे का? तुम्हाला हवे तसे स्वरूप आहे का?
- काही निर्बंध आहेत का? जे नको ते लिहिले आहे का?
- मी खूप लोड केले? मी एकाच प्रॉम्प्टमध्ये 5 वेगवेगळ्या नोकऱ्या मागितल्या आहेत का?
- मी पडताळणी केली का? नंबर, नाव, तारीख तपासली आहे का?
या सहा प्रश्नांमध्ये जवळपास सर्वच त्रुटी आढळतात.
चार कॉपी करण्यायोग्य प्रूफरीडिंग टेम्पलेट्स
1) संदिग्धता दूर करणे:
ही सूचना मोजता येण्याजोगी बनवा: [अस्पष्ट सूचना]प्रत्येक अस्पष्ट बिंदूचे एका ठोस संख्या, प्रमाण किंवा निकषात भाषांतर करा.
2) ओव्हरलोड विभाजित करणे:
हे सर्व कार्य एकाच वेळी करू नका. या क्रमाने पुढे जा आणि तुम्ही प्रत्येक पायरी पूर्ण केल्यावर थांबा, माझ्या पुष्टीकरणाची प्रतीक्षा करा: 1) [सबटास्क 1]2) [सबटास्क 2]3) [सबटास्क 3]
3) मर्यादित फिटिंग:
मी खाली दिलेल्या माहितीवर अवलंबून रहा. कोणतीही माहिती नसल्यास, "डेटा नाही" लिहा; अंदाज लावू नका किंवा जोडू नका. तुम्ही वापरत असलेला प्रत्येक महत्त्वाचा दावा कोणत्या ओळीतून आला आहे ते दर्शवा. स्रोत: [मजकूर]
4) विरोधाभास सोडवणे:
मी तुम्हाला दिलेल्या सूचनांमध्ये काही विरोधाभास आहेत का ते तपासा. तसे असल्यास, परस्परविरोधी मुद्यांची यादी करा आणि मला विचारा की कोणते प्राधान्य द्यायचे; नंतर त्यानुसार उत्पादन करा.
कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट
कमकुवत (अनेक त्रुटी एकत्रित):
आमच्या कंपनीसाठी मार्केटिंग, बजेट आणि भरतीबद्दल एक सर्वसमावेशक योजना लिहा आणि तुम्ही जाण्यासाठी चांगले आहात.
शक्तिशाली (बग निश्चित केले):
भूमिका: तुम्ही SME ला सल्ला देणारे व्यवसाय विकास तज्ञ आहात. संदर्भ: 12 लोकांसह सॉफ्टवेअर कंपनी; या तिमाहीत 20 नवीन ग्राहक घेण्याचे उद्दिष्ट आहे. कार्य: विपणन योजना फक्त लिहा (बजेट आणि नियुक्ती समाविष्ट करू नका). स्वरूप: 5-बिंदू कृती सूची; प्रत्येक आयटम: क्रिया + जबाबदार + निकष. मर्यादा: सशुल्क जाहिरात बजेट 0; फक्त सेंद्रिय चॅनेलची शिफारस करा. बनावट मेट्रिक्स देऊ नका; सूचनेचे समर्थन करा.
शक्तिशाली आवृत्ती ओव्हरलोडचे विभाजन करते (तीन विषय एका प्रॉम्प्टमध्ये क्रॅम करते), अस्पष्टता ("नशीब") निकषांसह बदलते आणि स्वरूपन आणि मर्यादा जोडते.
तीन मिनी केसेस
केस 1 - ओव्हरलोड. एका व्यवस्थापकाने अहवालाचा सारांश, सादरीकरण योजना आणि ई-मेल एकाच प्रॉम्प्टमध्ये विनंती केली; मॉडेलने तीनही अर्ध्यामध्ये बनवले. तीन स्वतंत्र प्रॉम्प्टमध्ये कामाचे विभाजन करून, प्रत्येक आउटपुट पूर्ण आणि वापरण्यायोग्य होता. एका जटिल प्रॉम्प्टशी संघर्ष करण्यापेक्षा एकूण वेळ कमी होता.
केस 2 - पुष्टी न करणे. सामग्री संघाने मॉडेलने दिलेली “उद्योग आकडेवारी” सत्यापित न करता प्रकाशित केली; नंबर चुकीचा निघाला आणि त्यांना दुरूस्ती जारी करावी लागली. त्यानंतर, त्यांनी "प्रत्येक क्रमांक त्याच्या स्त्रोतासह द्या, मी स्त्रोत तपासतो" हा नियम स्वीकारला आणि हा धोका दूर केला.
केस 3 - परस्परविरोधी सूचना. जेव्हा मार्केटर म्हणाले "हे खूप लहान आहे परंतु सर्व वैशिष्ट्ये सांगा", तेव्हा मॉडेलने काही वैशिष्ट्ये वगळली. जेव्हा मी "3 सर्वात महत्वाच्या वैशिष्ट्यांचे 60 शब्दांमध्ये वर्णन करा" म्हणून सूचना गैर-विरोधाभासी केली तेव्हा आउटपुट लहान आणि पूर्ण दोन्ही होते.
टीप: थेट जाण्यापूर्वी "सहा निदान प्रश्न" द्वारे तुमची सूचना चालवा. हा 30-सेकंद चेक सुरुवातीपासूनच पुनरावृत्तीच्या बहुतेक फेऱ्या अनावश्यक बनवतो.
खबरदारी: सर्वात धोकादायक चूक म्हणजे "नॉन-व्हॅलिडेशन" कारण ती दुर्लक्षित केली जाते कारण आउटपुट गुळगुळीत आणि खात्रीशीर दिसते. मॉडेल मोठ्या आत्मविश्वासाने संख्या, नाव किंवा स्त्रोताशी जुळू शकते. प्रकाशित करण्यासाठी किंवा निर्णयाचा आधार म्हणून वापरण्यासाठी कोणतीही वस्तुस्थिती स्वतंत्रपणे सत्यापित करा. पुढील भागामध्ये आपण हा विषय अधिक सखोल करू.
अदृश्य त्रुटी: "जवळजवळ बरोबर" आउटपुट
काही त्रुटी पकडणे सोपे आहे: आउटपुट चुकीच्या स्वरूपात येते, विषय सोडून जाते किंवा रिक्त येते. परंतु सर्वात कपटी चूक म्हणजे आउटपुट जवळजवळ बरोबर आहे. मजकूर अस्खलित आहे, रचना गुळगुळीत आहे, टोन बिंदूवर आहे; फक्त एक चुकीची संख्या, दुर्लक्षित मर्यादा किंवा एक लहान तार्किक त्रुटी आहे. या प्रकारचे आउटपुट धोकादायक असतात कारण ते तपासणीतून सुटतात कारण ते "चांगले दिसतात."
दोन सवयी यापासून संरक्षण करतात. प्रथम, ते वाचल्याशिवाय आउटपुट वापरू नका: तुम्ही कितीही घाई केली तरीही ते पाठवण्यापूर्वी ते वाचा. दुसरे, मॉडेलचे आउटपुट तपासणे: “मी दिलेल्या सर्व मर्यादांचे तुम्ही पालन केले आहे का ते तपासा” किंवा “या मजकूरातील सर्व संख्यांची यादी करा” यामुळे पृष्ठभागावर लपविलेल्या त्रुटी येतील. या दोन चरणांना काही सेकंद लागतात, परंतु "जवळजवळ योग्य" आउटपुटमुळे चुकीच्या निर्णयांची किंमत जास्त आहे.
चुका टाळणे: नियंत्रणावर डिझाइन
आउटपुटमधील त्रुटींचा शोध घेण्याऐवजी, अनुभवी वापरकर्ता प्रॉम्प्टवर सुरुवातीपासूनच त्यांना प्रतिबंधित करण्याचा प्रयत्न करतो. हा मानसिकतेतला फरक आहे. प्रत्येक आवर्ती त्रुटीला "कायमचा नियम" मध्ये बदला: जर मॉडेल सारांश कार्यामध्ये टिप्पण्या जोडत राहिल्यास, आता प्रत्येक सारांश प्रॉम्प्टवर "टिप्पण्या जोडू नका" मर्यादा सेट करा. जर मॉडेल नेहमी सूचीच्या कामात खूप जास्त आयटम तयार करत असेल, तर तुमच्या टेम्पलेटमध्ये "नक्की X आयटम" मर्यादा ठेवा. अशा प्रकारे, तीच त्रुटी पुन्हा पुन्हा पकडण्याऐवजी, आपण ती प्रथम स्थानावर येण्यापासून प्रतिबंधित करता. चांगल्या प्रकारे डिझाइन केलेले प्रॉम्प्ट त्यानंतरच्या डझनभर दुरुस्त्या बदलते; हे ओझ्यापासून त्रुटी निदानाला शिक्षण आणि सुधारणा साधनात बदलते.
सामान्य चुका
- मध्यस्थाला दोष देणे. प्रॉम्प्टमध्ये समस्या शोधण्याऐवजी "AI करू शकत नाही" असे म्हणणे.
- एकाच प्रॉम्प्टमध्ये खूप जास्त काम करणे. पाच स्वतंत्र कार्ये एका निर्देशामध्ये संकुचित करणे आणि ती अर्धवट करणे.
- सत्यापन वगळणे. अस्खलित आउटपुट बरोबर आहे असे गृहीत धरून.
- परस्परविरोधी बंधने देणे. "लहान पण सर्वसमावेशक" सारख्या स्व-विरोधी मागण्या.
- निदान न करता पुन्हा प्रयत्न करत आहे. काय तुटले आहे हे न शोधता तीच चूक पुन्हा करणे.
सारांशात
- सर्वात खराब आउटपुट ही प्रॉम्प्टची समस्या आहे, मॉडेलची नाही; निदान आणि दुरुस्त केले जाऊ शकते.
- सर्वात सामान्य त्रुटी: अस्पष्टता, शून्य संदर्भ, स्वरूपाचा अभाव, मर्यादांचा अभाव, ओव्हरलोड, सत्यापनाचा अभाव, एक-शॉट अपेक्षा आणि विरोधाभास.
- सहा निदान प्रश्न (कार्य, संदर्भ, स्वरूप, मर्यादा, लोड, सत्यापन) बहुतेक त्रुटी पकडतात.
- जटिल नोकऱ्यांचे विभाजन केल्याने त्यांना एकाच प्रॉम्प्टवर लोड करण्यापेक्षा जलद आणि उच्च दर्जाचे परिणाम मिळतात.
- सर्वात कपटी त्रुटी म्हणजे सत्यापन न करणे; गुळगुळीत आउटपुटचा अर्थ अचूक नाही.
अर्ज कार्य
तुम्हाला आवडत नसलेले जुने प्रिंटआउट शोधा आणि त्याचा प्रॉम्प्ट "सहा निदान प्रश्न" द्वारे चालवा. कोणत्या त्रुटी आढळतात हे चिन्हांकित करा, प्रत्येकासाठी या युनिटमधील निराकरण लागू करा आणि प्रॉम्प्ट पुन्हा चालवा. लक्षात घ्या की कोणत्या एका सुधारणेने सर्वाधिक सुधारणा केली, किती फेऱ्या नाहीत.
चेकलिस्ट
- [ ] खराब आउटपुटच्या बाबतीत, मी प्रथम प्रॉम्प्टची चौकशी करतो, एजंटला नाही.
- [ ] मी सहा निदान प्रश्न करू शकतो.
- [ ] मी जटिल कार्ये एकाधिक प्रॉम्प्टमध्ये विभागतो.
- [ ] मला परस्परविरोधी आणि अस्पष्ट सूचना दिसल्या आणि त्या दुरुस्त केल्या.
- [ ] मी ते प्रकाशित करण्यापूर्वी तथ्यात्मक आउटपुट सत्यापित करतो.