AI is code – और इसे प्रॉम्प्ट करके ज़्यादा स्मार्ट नहीं बनाया जा सकता

मूल लेख ↗ Hacker News चर्चा ↗

AI बनाम पारंपरिक कोड और “स्मार्टनेस”

  • कुछ लोगों का तर्क है कि किसी LLM को प्रॉम्प्ट करना किसी प्रोग्राम को कॉन्फ़िगर करने जैसा है: आप एल्गोरिदम नहीं बदलते, लेकिन व्यवहार को और अधिक “उपयोग-उपयुक्त” बना सकते हैं।
  • दूसरे एक अहम अंतर पर ज़ोर देते हैं: पारंपरिक कोड को औपचारिक रूप से निर्दिष्ट किया जा सकता है और (कुछ हद तक) सत्यापित भी; LLM का व्यवहार विश्वसनीय रूप से निर्दिष्ट नहीं किया जा सकता, न ही उसे सही साबित किया जा सकता है।
  • एक प्रतिवाद यह कहता है कि AI फिर भी “सिर्फ एक प्रोग्राम” है: अगर आप seed/temperature को फिक्स कर दें, तो आप यह सत्यापित कर सकते हैं कि वह एक तुच्छ स्पेक (इनपुट टोकन को आउटपुट टोकन में मैप करना) पूरा करता है, लेकिन semantic correctness नहीं।

प्रॉम्प्टिंग, क्षमता, और डिटर्मिनिज़्म

  • कई टिप्पणियाँ कहती हैं कि प्रॉम्प्ट्स मॉडलों को साफ़ तौर पर “ज़्यादा मूर्ख” बना सकते हैं, इसलिए वे व्यवहार में मौजूदा क्षमताओं का बेहतर उपयोग करके उन्हें “ज़्यादा स्मार्ट” भी बना सकते हैं।
  • प्रॉम्प्टिंग, retrieval, और “context engineering” की तुलना पारंपरिक सिस्टमों में data flow और instrumentation सुधारने से की जाती है।
  • डिटर्मिनिज़्म के मामले में अंतर बताया जाता है: क्लासिक एल्गोरिदम deterministic होते हैं; LLM के आउटपुट बदलते रहते हैं, जिससे reliability और verification जटिल हो जाती है।

Prompt Injection और jqwik-Style Booby Trap

  • Prompt injection (जैसे, “पिछले निर्देशों को अनदेखा करें…”) को एक स्थायी, मूलभूत समस्या माना जाता है क्योंकि LLM “instructions” और “data” को एक ही token stream में मिला देते हैं।
  • कुछ लोग इसका विरोध करते हुए कहते हैं कि भविष्य की architectures control/data planes को token metadata और roles के साथ अलग करेंगी।
  • एक testing library के उस विशेष मामले ने, जिसमें एक hidden prompt embedded था और जिसने AI agents को अपनी ही tests delete करने पर उकसाया, ज़ोरदार बहस छेड़ दी:
    • समर्थक इसे AI tools में अपने काम के इस्तेमाल के खिलाफ़ विरोध मानते हैं, या फिर उन लोगों को ही नुकसान पहुँचाने वाली “benign” sabotage, जो स्पष्ट चेतावनियों को नज़रअंदाज़ करते हैं।
    • आलोचक इसे malware, supply-chain attack, या कम-से-कम एक “dick move” कहते हैं, जो अनजान users और projects को दंडित करता है।

कानूनी और नैतिक असहमति

  • कुछ का दावा है कि यह व्यवहार स्पष्ट रूप से computer misuse laws (जैसे unauthorized access/damage) का उल्लंघन करता है, चाहे mechanism कुछ भी हो।
  • दूसरे तर्क देते हैं कि user/agent ने tool चलाने और instructions का पालन करने का चुनाव किया; ज़िम्मेदारी उन लोगों की है जिन्होंने AI को असुरक्षित authority सौंपी।
  • उपयोग की गई उपमाएँ: SQL injection, wheel bolts को ढीला करना बनाम सड़क में साफ़ दिखाई देने वाला log रखना, booby-trap packages, “shouting fire in a crowded theater.”
  • कोई सहमति नहीं बनती; legality पर व्यापक बहस होती है और इसे अस्पष्ट माना जाता है।

लाइसेंसिंग, ओपन सोर्स, और उपयोग पर नियंत्रण

  • एक पक्ष: open-source licenses (खासकर जो “no field-of-endeavor discrimination” नियम को पूरा करते हैं) AI उपयोग को प्रतिबंधित नहीं कर सकते; ऐसा license चुनना consent दर्शाता है।
  • दूसरा पक्ष: भले ही कानूनी रूप से open हो, authors की इस बात पर व्यक्त इच्छाओं का सम्मान किया जाना चाहिए कि उनका काम कैसे इस्तेमाल हो, ताकि contributors पर chilling effect न पड़े।
  • copyright शर्तों (copying/redistribution) और software को कैसे उपयोग किया जाए, इसे नियंत्रित करने की कोशिश के बीच अंतर बताया जाता है; open-source licenses आम तौर पर इसे प्रतिबंधित नहीं करते।

Backups, Source Control, और व्यावहारिक प्रभाव

  • कुछ लोग उन users का मज़ाक उड़ाते हैं जिन्होंने कहा कि “months of work destroyed,” और सुझाव देते हैं कि Git और remote repos का सही उपयोग स्थायी नुकसान रोक सकता था।
  • दूसरे ज़ोर देते हैं कि source control अपने आप backup नहीं होता; offsite copies के बिना deletion फिर भी विनाशकारी हो सकता है।
  • यह घटना दिखाती है कि broad file permissions वाले AI agents, prompt injection मौजूद हो या नहीं, वास्तविक नुकसान कर सकते हैं।