मैंने एक प्रोग्रामिंग भाषा बनाई जिसे LLMs इस्तेमाल नहीं कर सकते

एक नई esoteric programming language, KillSwitch, को इस तरह डिज़ाइन किया गया है कि वह इंसानों के लिए आसान लेकिन बड़े language models के लिए जानबूझकर भ्रमित करने वाली हो, जिसमें भ्रामक specs, letter-counting rules, और safety filters को trigger करने वाले phrases जैसे tricks शामिल हैं। Commenters का तर्क है कि ऐसी “anti-LLM” designs अंततः interpreters, transpilers, या reverse-engineering के जरिए bypass की जा सकती हैं—और ये मशीनों से ज़्यादा humans को बाधित कर सकती हैं—इसलिए यह robust protection से ज़्यादा security-by-obscurity के करीब है। फिर भी यह project मौजूदा models की ठोस failure modes को उजागर करता है, इस बहस को तेज़ करता है कि क्या LLMs सचमुच code को “understand” करते हैं या training data को remix करते हैं, और adversarial तथा LLM-friendly languages दोनों के लिए एक व्यापक research space का संकेत देता है.

प्रेरणा और डिज़ाइन

  • लक्ष्य ऐसी भाषा बनाना है जिसे LLMs (और coding agents) के लिए पढ़ना, लिखना, समझना बहुत कठिन हो, लेकिन इंसानों के लिए फिर भी अपेक्षाकृत उपयोगी रहे।
  • तकनीकों में शामिल हैं: adversarial phrases (“ignore previous instructions”, unsafe topics), letter/word-count constraints, identifiers के रूप में anagrams, spec में छिपे झूठ और omissions, और noisy natural-language padding।
  • भाषा विकसित हो सकती है (features जोड़ना/हटाना) ताकि मॉडल्स और उनके training data से आगे बना रहे।

बायपास करना और सीमाएँ

  • कई commenters का तर्क है कि यह तरीका मूलतः “security by obscurity” है और आसानी से circumvent किया जा सकता है:
    • एक safe intermediate language से transpiler लिखना।
    • interpreter/compiler को decompile या reverse-engineer करना और textual spec की बजाय उसके behavior को target करना।
    • एक proxy का उपयोग करना जो trigger phrases को rewrite कर दे, उससे पहले कि LLM उन्हें देखे।
  • दूसरे लोग नोट करते हैं कि इंसान ऐसे tools बनाकर LLMs की मदद करेंगे, इसलिए language-level obfuscation सचमुच AI access को रोक नहीं सकती।

Benchmarks और प्रदर्शन

  • Benchmarks मॉडल्स को केवल spec और/या interpreter binary देते हैं, इंटरनेट नहीं।
  • सबसे अच्छे मॉडल लगभग mid‑60% score करते हैं और अक्सर spec को गलत समझते हैं या उसके traps में फँस जाते हैं; वे अक्सर मान लेते हैं कि गलत outputs सही हैं।
  • कुछ models मुख्यतः safety guardrails के कारण बाधित होते हैं, capability के कारण नहीं। कुछ दूसरे binary को reverse-engineer करके बेहतर प्रदर्शन करते हैं।
  • अभी तक कोई human baseline नहीं है; भविष्य का version humans को भी test कर सकता है।

मानव उपयोगिता

  • कई readers को लगता है कि यह भाषा LLMs से ज़्यादा humans के लिए hostile है, syntax highlighting और इसे “human-friendly” रखने की कोशिशों के बावजूद।
  • Author मानता है कि यह अभी humans के लिए भी कठिन है और इस संतुलन को बेहतर बनाने के लिए ideas चाहता है।

Guardrails और adversarial content

  • एक प्रमुख tactic ऐसे phrases embed करना है जो safety filters trigger करें (crime, bioweapons, Tiananmen, etc.)।
  • कुछ models spec को केवल पढ़ते ही इन पर फँस जाते हैं; दूसरे (विशेषकर कुछ Chinese models) कम प्रभावित होते हैं।
  • आलोचक कहते हैं कि यह provider policies का फायदा उठाता है, न कि LLM की मौलिक सीमाओं का, और preprocessing से इसे sidestep किया जा सकता है।

व्यापक विचार और संबंधित ideas

  • इस पर बहस है कि क्या यह LLMs में “understanding” बनाम pattern recall के बारे में कुछ गहरा कहता है; कुछ लोग ऐसा नहीं मानते, जबकि दूसरे इसे एक उपयोगी failure case मानते हैं।
  • esolangs, Forth जैसे stack languages, graphical languages, और “hate-speech” या slur-based languages जैसी अन्य LLM-unfriendly designs से तुलना की गई है।
  • कुछ लोग इसे CAPTCHAs, gated internal tools, या shibboleths के रूप में उपयोगी मानते हैं, हालांकि इसकी practicality पर सवाल उठते हैं।