ठीक-ठीक जानें कि आप क्या भेजते हैं, उत्पन्न कोड का कानूनी रूप से क्या मूल्य है, और मॉडल के पूर्वाग्रह आपके तकनीकी निर्णयों को कैसे मोड़ते हैं।
इस पाठ को Kodokon में खोलेंहर प्रॉम्प्ट किसी तीसरे पक्ष को डेटा का प्रसारण है। किसी व्यावसायिक संदर्भ में असिस्टेंट का उपयोग करने से पहले, तीन प्रश्नों का प्रलेखित उत्तर होना चाहिए। धारण (retention): प्रदाता आपकी बातचीत को कितने समय तक रखता है, और उस तक कौन पहुँच सकता है (सपोर्ट, सुरक्षा, अदालती आदेश)? प्रशिक्षण: क्या आपके डेटा का उपयोग भविष्य के मॉडल प्रशिक्षित करने में किया जाता है, और क्या आपके खाते पर opt-out चालू है - उपभोक्ता प्लान और उद्यम (enterprise) प्लान लगभग हमेशा इस बिंदु पर भिन्न होते हैं? अनुबंध: क्या आपका नियोक्ता या आपके ग्राहक आपको यह कोड प्रसारित करने की अनुमति देते हैं, यह जानते हुए कि आपके हस्ताक्षरित गोपनीयता खंड एक प्रॉम्प्ट पर भी लागू होते हैं? एक कोड स्निपेट भले ही हानिरहित दिखे; आंतरिक डोमेन नामों, तालिका संरचनाओं और पूर्ण पथों वाले त्रुटि संदेशों के साथ मिलकर, वह आपके सूचना तंत्र का वर्णन कर देता है।
अच्छी प्रथा है न्यूनीकरण (minimization): तर्क के लिए जो नितांत आवश्यक हो केवल उतना ही भेजना। यह अपने आप में एक कौशल है - सामान्य नामों के साथ एक न्यूनतम पुनरुत्पादनीय उदाहरण बनाना - और इसका एक अप्रत्याशित शैक्षणिक गुण भी है: किसी समस्या को अलग करके उसे अमूर्त रूप में वर्णित करना आपको उसे समझने के लिए मजबूर करता है। निम्नलिखित प्रॉम्प्ट इस गोपनीयता बाधा को एक नैदानिक अभ्यास में बदल देता है।
संदर्भ: मैं ऐसे स्वामित्व वाले (proprietary) कोड पर काम कर रहा हूँ जिसे मैं साझा नहीं कर सकता। मैं अपनी समस्या का अमूर्त वर्णन करूँगा, सामान्य नामों के साथ और असली कोड पेस्ट किए बिना।
विवरण: [संबंधित संरचना का PSEUDO-CODE, पथ और पहचानकर्ता छिपाए गए ERROR MESSAGE, संबंधित लाइब्रेरियों के VERSIONS]।
आपका मिशन:
1. अगर मेरा विवरण तर्क करने के लिए बहुत अस्पष्ट है, तो मुझे ठीक-ठीक बताएँ कि आपको कौन सी जानकारी चाहिए और क्यों - मैं तय करूँगा कि क्या मैं उसे गुमनाम रूप में दे सकता हूँ।
2. केवल मेरे विवरण पर तर्क करें: मुझसे कभी पूरी फ़ाइल पेस्ट करने को न कहें।
3. कारण के लिए परिकल्पनाएँ प्रस्तावित करें, संभावना के अनुसार क्रमबद्ध, और हर एक के लिए एक सटीक परीक्षण जिसे मैं उसकी पुष्टि या खंडन करने के लिए स्थानीय रूप से चला सकूँ।
प्रारूप: परिकल्पना / संभावना / सत्यापन परीक्षण की एक तालिका। मैं परीक्षण के परिणामों के साथ वापस आऊँगा।दूसरा मामला: उत्पन्न-कोड का लाइसेंसिंग। कानून अभी तय नहीं है और अधिकार-क्षेत्र के अनुसार भिन्न होता है, पर तीन तथ्य स्थापित हैं। एक: मॉडल विविध लाइसेंसों वाले कोड पर प्रशिक्षित होते हैं, जिनमें GPL जैसे copyleft लाइसेंस भी शामिल हैं, और वे अपने स्रोत के बहुत निकट के स्निपेट पुनरुत्पादित कर सकते हैं - खासकर प्रसिद्ध एल्गोरिदम या अत्यधिक दोहराए गए स्निपेट के लिए। दो: कई अधिकार-क्षेत्रों में, बिना किसी मानवीय रचनात्मक योगदान वाले विशुद्ध यांत्रिक आउटपुट को copyright से सुरक्षित करना कठिन है, जो ज्यों-का-त्यों स्वीकार किए गए कोड पर आपके दावों को कमज़ोर कर देता है। तीन: कुछ प्रदाता किसी उल्लंघन-दावे की स्थिति में संविदात्मक क्षतिपूर्ति (indemnification) देते हैं, और ऐसे फ़िल्टर देते हैं जो corpus के बहुत निकट के आउटपुट को रोक देते हैं - जाँच लें कि ये सुरक्षाएँ आपके प्लान में हैं, केवल विज्ञापन-पुस्तिका में नहीं। व्यवहार में: कोई उत्पन्न स्निपेट जितना लंबा, जितना विशिष्ट और जितना कम-संपादित होता है, कानूनी जोखिम उतना ही ऊँचा होता है।
तीसरा मामला: पूर्वाग्रह। एक मॉडल अपने corpus की सांख्यिकीय नियमितताओं को पुनरुत्पादित करता है, और तीन पूर्वाग्रह सीधे आपके तकनीकी निर्णयों को प्रभावित करते हैं। लोकप्रियता पूर्वाग्रह: डेटा में अति-प्रस्तुत समाधान (प्रमुख फ़्रेमवर्क, दो साल पहले चलन में रहे पैटर्न) डिफ़ॉल्ट रूप से अनुशंसित होते हैं, तब भी जब आपका संदर्भ किसी और चीज़ की मांग करता है - corpus हमेशा नवीनतम अत्याधुनिक से एक कदम पीछे रहता है। चापलूसी पूर्वाग्रह (sycophancy): मॉडल उपयोगकर्ता को खुश करने के लिए अनुकूलित होते हैं और आपकी पूर्वधारणा को मान्य करने की ओर झुकते हैं; पूछें "मेरा microservices दृष्टिकोण सही क्यों है?" और आपको पुष्टियाँ मिलेंगी, प्रति-राय नहीं। उलटा प्राधिकार पूर्वाग्रह: लहजे की प्रवाहमयता एक ऐसी निश्चितता का आभास पैदा करती है जिसका भरोसेमंदी से कोई संबंध नहीं। इसका प्रतिकार प्रक्रियात्मक है: विरोधाभास को मजबूर करें।
आपने अभी मुझे [SOLUTION OR TECHNOLOGY] की अनुशंसा की। मेरे तय करने से पहले, रुख बदलें: अब आप एक अनुभवी अभियंता हैं जिसे इस अनुशंसा के खिलाफ़ तर्क देने का काम सौंपा गया है।
1. अपने ही उत्तर के खिलाफ़ 3 सबसे अच्छे तर्क दें, हर एक को एक ठोस परिदृश्य से समझाया जाए जहाँ वह विफल होता है।
2. कम से कम एक गंभीर विकल्प का उल्लेख करें जिसका आपने ज़िक्र नहीं किया था, और ईमानदारी से समझाएँ कि वह आपके पहले उत्तर से क्यों नदारद था।
3. आकलन करें कि आपकी शुरुआती अनुशंसा कितनी इस समाधान की आपके प्रशिक्षण डेटा में लोकप्रियता के कारण है, बजाय मेरे विशिष्ट संदर्भ के, जिसकी मैं आपको याद दिला दूँ: [YOUR CONTEXT: टीम का आकार, बाधाएँ, मौजूदा सेटअप]।
प्रारूप: दो कॉलम For / Against, फिर एक वाक्य में आपकी संशोधित अनुशंसा, आपके विश्वास स्तर और इसे क्या बदल सकता है के साथ।