NLnet Labs की LLM उपयोग नीति

 (nlnetlabs.nl)
1 पॉइंट द्वारा GN⁺ 9 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • NLnet Labs प्रोजेक्ट योगदान और कम्युनिकेशन में LLM के उपयोग को सीमित करता है, और नीति का उल्लंघन करने वाली सबमिशन बिना पूर्व सूचना के बंद या हटाई जा सकती हैं
  • कोड और दस्तावेज़ योगदान सीधे इंसानों द्वारा लिखे गए होने चाहिए, और इनमें LLM या अन्य probabilistic tools द्वारा जनरेट की गई सामग्री शामिल नहीं हो सकती
  • vulnerability और bug reports में LLM द्वारा सुझाए गए fixes को अपवादस्वरूप स्वीकार किया जा सकता है, लेकिन मानव योगदानकर्ता को समस्या और उसकी गंभीरता की पुष्टि करनी होगी
  • issues, vulnerability reports और forum posts जैसे NLnet Labs के साथ इंटरैक्शन में LLM उपयोग का खुलासा करना आवश्यक है, और machine translation के मामले में भी गलत अनुवाद की संभावना के कारण खुलासा करने की सिफारिश की जाती है
  • LLM का उपयोग linting, analysis और review में किया जा सकता है, लेकिन बाहर साझा की जाने वाली जानकारी की सटीकता को समझने और सत्यापित करने की जिम्मेदारी योगदानकर्ता की ही रहती है

नीति का दायरा और मूल दायित्व

  • NLnet Labs संगठन और प्रोजेक्ट संदर्भ में Large Language Models(LLMs) के उपयोग के तरीके को सीमित करता है
  • इस नीति का पालन न करने वाली सबमिशन बिना पूर्व सूचना के बंद या हटाई जा सकती हैं
    • इसमें PR, issue, comment और forum post शामिल हैं
  • इस नीति के साथ code of conduct और हर प्रोजेक्ट की CONTRIBUTING.md का पालन भी करना होगा

योगदान लिखने के सिद्धांत

  • कोड और दस्तावेज़ योगदान इंसानों द्वारा लिखे गए होने चाहिए
    • इनमें LLM या अन्य probabilistic tools द्वारा जनरेट की गई सामग्री शामिल नहीं हो सकती
    • vulnerability या bug report में शामिल LLM-सुझाए गए fixes को अपवादस्वरूप अनुमति है
    • इस अपवाद का उद्देश्य शुरुआती समीक्षा के दौरान समस्या के मूल कारण को अधिक आसानी से ढूँढना है
  • PR खोलते समय भी LLM-जनरेटेड योगदान स्वीकार नहीं किए जाते
    • सबमिट किया गया कोड LLM द्वारा जनरेट नहीं होना चाहिए
    • PR description अपने शब्दों में संक्षेप में लिखी जानी चाहिए
    • सामान्यतः नए feature वाले PR, NLnet Labs से पहले बात किए बिना, नहीं खोलने चाहिए
    • software changes के ideas को community forum पर अपने शब्दों में साझा किया जा सकता है

LLM उपयोग का खुलासा और अनुवाद

  • NLnet Labs के साथ इंटरैक्ट करते समय LLM का उपयोग हुआ या नहीं, यह बताना आवश्यक है
    • इसमें issue खोलना, vulnerability report करना और community forum पर पोस्ट करना शामिल है
  • यदि अंग्रेज़ी आपकी मातृभाषा नहीं है, तो machine translation मददगार हो सकता है
    • यदि machine translation का उपयोग किया गया है, तो गलत अनुवाद के कारण संभावित कम्युनिकेशन समस्याओं से दोनों पक्ष अवगत रहें, इसके लिए खुलासा करने की सिफारिश की जाती है
    • यदि आप अनुवाद की सटीकता का आकलन नहीं कर सकते, तो अपनी मातृभाषा में लिख सकते हैं
    • LLM translation की generative प्रकृति के कारण यह चर्चा को आसान बनाने के बजाय अधिक भ्रम पैदा कर सकती है, इसलिए इसकी सिफारिश नहीं की जाती

अनुमत उपयोग और सत्यापन की जिम्मेदारी

  • linting, analysis और review में LLM का उपयोग स्वीकार्य है
  • भले ही LLM ने समस्या ढूँढने या analysis में मदद की हो, साझा की जाने वाली जानकारी की सटीकता को समझने और सत्यापित करने की जिम्मेदारी उपयोगकर्ता की ही है

vulnerability report

  • NLnet Labs, LLM की मदद से खोजी गई vulnerability reports स्वीकार कर सकता है
    • रिपोर्ट में LLM-सुझाए गए fixes शामिल किए जा सकते हैं ताकि समस्या की जगह पहचानने में मदद मिले
    • मानव योगदानकर्ता को समस्या और उसकी अनुमानित गंभीरता की पुष्टि करनी होगी
    • sep@nlnetlabs.nl पर रिपोर्ट करते समय LLM उपयोग का खुलासा करना होगा
    • vulnerability report प्रक्रिया के लिए security report पेज देखें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 9 시간 전
Lobste.rs की टिप्पणियां

  • ऐसे नियमों के पीछे की सोच सुनना चाहूंगा
    मसलन, यह जानना चाहूंगा कि मुख्य प्रेरणा कानूनी अनिश्चितता है, quality या maintainability की चिंता है, या कोई और वजह है

    • NLnet Labs के Alex Band ने this toot में काफी संयमित तरीके से समझाया है: कोई व्यक्ति अच्छी prompt writing के जरिए कोई बेहतरीन और जरूरी feature contribute करने के लिए ऐसा 10,000 लाइनों का code generate कर सकता है जो functionally इच्छित जैसा दिखे
      लेकिन NLnet Labs टीम को pull request के रूप में submit करने से पहले असली सवाल यह है कि क्या उसने generated हर line review की है, उसे समझा है, और उसकी जिम्मेदारी ले सकता है। पिछले एक साल के अनुभव में ऐसा कम ही हुआ; code किसी सद्भावनापूर्ण gift की तरह दरवाजे पर छोड़ दिया जाता है, लेकिन उसे review करने, जिम्मेदारी लेने और main branch में merge करने का बोझ टीम पर आ जाता है। यह देखते हुए कि यह software इंटरनेट की बुनियाद बनने वाले critical infrastructure में चलता है, यह बहुत बड़ी मांग है। Review प्रक्रिया में problem domain और proposed solution के details, दोनों की साझा समझ के साथ बातचीत होनी चाहिए, लेकिन LLM का उपयोग submitter को ऐसी समझ नहीं देता और long-term maintenance पर भी बुरा असर डालता है
    • इस document को लिखने की सीधी वजह developers का समय बचाना था
      बेशक copyright, quality control, long-term maintenance और ethical concerns—इन सब पर भी विचार किया गया

  • अच्छा लगा कि focus इंसानों द्वारा patch लिखने और review करने पर है, और vulnerability reports में patch suggestions को exception रखा गया है
    अगर वे सरल और मुद्दे की बात करने वाले हों, तो ऐसे suggestions पढ़ने लायक होते हैं

  • समझ सकता हूं कि लोग AI-generated outputs से क्यों थक जाते हैं, खासकर जब scale बड़ा हो जाए
    जिस छोटी team में मैं काम करता हूं, वहां भी परेशान करने वाली चीजें होती हैं। जब पूछा जाता है, “आपने ऐसा क्यों किया?” तो जवाब आता है, “अरे, Claude ने ऐसा किया था,” और यह कोई जवाब नहीं है। लोग अपनी सोच की प्रक्रिया ही नहीं, जिम्मेदारी भी machine पर डाल रहे हैं। फिलहाल इसे conservative तरीके से इस्तेमाल करना जरूरी नहीं कि बुरा हो; जब हमें यह पता चल जाए कि इस technology को बड़े scale पर जिम्मेदारी से कैसे इस्तेमाल करना है, तभी restrictions ढीली करनी चाहिए। अभी तो किसी को भी इसका तरीका नहीं पता

  • यह सिर्फ NLnet Labs की अपनी policy है, NLnet से support पाने वाले projects के लिए इसे अपनाना जरूरी नहीं है

  • ऐसे फैसले के पीछे की वजह समझ आती है, लेकिन enforcement का तरीका “सब कुछ मना है” के करीब है, इसलिए नजरिया संकुचित लगता है

    • क्या बता सकते हैं कि यह normative judgment कहां से आ रहा है? यह जानना चाहूंगा कि किसी और के अपने project में LLM-generated submissions स्वीकार करने में आपकी दिलचस्पी क्यों है, और इससे उन्हें या society को क्या मिलता है
      मुझे यह logic consistent और reasonable लगता है, और आजकल के माहौल में एक healthy protective measure भी। यह भी जानना चाहूंगा कि क्या आपको चिंता है कि इस वजह से आपकी submission reject हो जाएगी, या आपके साथ पहले ही ऐसा हो चुका है। क्या इस policy का पालन करना इतना मुश्किल है? क्या आप खुद critical infrastructure के long-term maintainer के तौर पर रोज issue tracker में आने वाले low-quality noise से जूझ रहे हैं? Human-centered workflow में false positives की बाढ़ से होने वाले impact को कम करते हुए motivation बनाए रखने के लिए आपके हिसाब से क्या करना चाहिए?
    • इसे संकुचित कहने के बजाय मैं सावधान कहूंगा
    • जब यह स्पष्ट हो जाता है कि संबंधित community सभी stakeholders के हितों को ज्यादा सटीकता से reflect करने वाले खुले और जटिल नियमों को संभाल नहीं सकती, तो संकरे और सरल नियम बन जाना काफी आम है
      यह बुरी बात नहीं है। Developers थोड़े और mature हो जाएं तो इसे फिर से review किया जा सकता है