bozo bit चालू करते ही सीखना बंद हो जाता है

 (surfingcomplexity.blog)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • bozo bit वह रवैया है जिसमें किसी खास व्यक्ति के निर्णय और बातों को अब सुनने लायक नहीं माना जाता
  • अगर दुर्घटना के जिम्मेदार व्यक्ति को अयोग्य मानकर अलग कर दिया जाए, तो संगठन के लिए उस दुर्घटना से सीखने के अवसर कम हो जाते हैं
  • PocketOS की AI दुर्घटना-प्रतिक्रिया Cook और Woods के distancing through differencing का उदाहरण है
  • विदेशी फैक्टरी में लगी आग को दूसरों की समस्या मानने वाली अमेरिकी फैक्टरी ने साझा system commonalities को नज़रअंदाज़ किया
  • अगर AI दुर्घटना को “उन्हें यह पता होना चाहिए था” कहकर खत्म कर दिया जाए, तो उससे सुरक्षा सुधार तक पहुँचना मुश्किल हो जाता है

दुर्घटना को दूसरों की समस्या मानें तो सीखना रुक जाता है

  • bozo bit सॉफ्टवेयर उद्योग का एक मुहावरा है, जिसमें किसी खास व्यक्ति के निर्णय का सम्मान करना छोड़ दिया जाता है और यह माना जाता है कि उसकी बात सुनने लायक नहीं है
  • दुर्घटना की खबर सुनकर अगर कोई कहे, “कोई X कैसे नहीं कर सकता?”, तो वह दुर्घटना से जुड़े लोगों को अयोग्य मानते हुए उन्हें अपने संगठन से अलग करके देख रहा होता है
  • PocketOS के संस्थापक Jer Crane की X पोस्ट An AI Agent Just Destroyed Our Production Data. It Confessed in Writing ने AI-संबंधित दुर्घटना के रूप में काफी ध्यान खींचा, और ऑनलाइन PocketOS को अयोग्य बताने वाली कई प्रतिक्रियाएँ आईं
  • ऐसा रवैया दुर्घटना से सीखने के अवसर कम कर देता है, और यह Cook और Woods के बताए distancing through differencing से मेल खाता है

  • अंतर के ज़रिये दूरी बनाना (distancing through differencing)

    • Richard Cook और David Woods ने 2006 के लेख Distancing Through Differencing: An Obstacle to Organizational Learning Following Accidents में इस शब्द का इस्तेमाल किया था
    • यह लेख Resilience Engineering: Concepts and Precepts की एक chapter के रूप में प्रकाशित हुआ था
    • जब लोग दुर्घटना झेलने वाले पक्ष और अपने बीच के अंतर पर ध्यान केंद्रित करते हैं, तो वे मान लेते हैं कि अपनी operations और practical work पर लागू करने लायक कोई सबक नहीं है
    • “वह दुर्घटना यहाँ नहीं हो सकती” इस प्रवृत्ति का सबसे सामान्य रूप है

बार-बार होने वाली दुर्घटनाएँ और छूटते साझा पैटर्न

  • Cook और Woods ने अमेरिका की एक manufacturing factory में लगी chemical fire का उदाहरण लिया
  • उसी कंपनी की एक विदेशी factory में पहले भी ऐसी ही आग लग चुकी थी, और अमेरिका के कर्मचारियों को इसकी जानकारी थी
  • लेकिन अमेरिकी कर्मचारियों ने यह मान लिया कि विदेशी कर्मचारी कम skilled, कम motivated और कम careful हैं, इसलिए उनसे सीखने जैसा कुछ नहीं है
  • अमेरिकी factory में आग लगने के बाद भी उसी factory की दूसरी shift के workers ने दुर्घटना के कारण को उस shift की कम skill पर डाल दिया जिसमें आग लगी थी
  • इस तरह का विभाजन लोगों को अपने और दुर्घटना झेलने वालों के बीच मौजूद system commonalities को देखने से रोक देता है
  • Cook और Woods का कहना था कि ऊपर-ऊपर अलग दिखने वाली घटनाओं को यूँ ही खारिज नहीं करना चाहिए; विश्लेषण के किसी स्तर पर हर घटना अनोखी होती है, लेकिन किसी दूसरे स्तर पर वही साझा pattern भी दिखाती है
  • अगर PocketOS की दुर्घटना को सिर्फ “AI का गैर-जिम्मेदाराना इस्तेमाल किया गया” कहकर समाप्त कर दिया जाए, तो उससे कुछ सीखने को नहीं बचेगा
  • PocketOS जिस Railway का इस्तेमाल कर रहा था, वह delete API उपलब्ध कराने वाला vendor था, और बाद में उसने पूरे system की safety बढ़ाने वाले बदलाव किए, जैसा कि Your AI wants to nuke your database. Guardrails fix that में बताया गया
  • आगे भी उद्योग में AI-संबंधित दुर्घटनाएँ आती रहेंगी, और “उन्हें पता होना चाहिए था कि X नहीं करना चाहिए” जैसी सोच distancing through differencing के जाल में फँसी हुई है
  • कोई व्यक्ति जानबूझकर अत्यधिक जोखिम ले रहा हो और कोई अनजाने में अत्यधिक जोखिम ले बैठे, ये दोनों स्थितियाँ अलग हैं; और किसी को सिर्फ इस वजह से दोष देना कठिन है कि उसे यह नहीं पता था कि वह क्या नहीं जानता
  • जब संगठन distancing through differencing से आगे बढ़ते हैं, तभी उनकी प्रतिक्रिया बदल सकती है

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की रायें

  • bozo bit की उपयोगिता इस बात में है कि कुछ लोग लगातार उलटी जानकारी के स्थिर स्रोत होते हैं
    ऐसे लोग आदतन बार-बार गलत निष्कर्षों पर पहुँचते हैं, बहुत सीधे लिखे गए दस्तावेज़ों को भी गलत समझ लेते हैं, और ऐसे डिज़ाइन पेश करते हैं जो लक्ष्य हल नहीं करते बल्कि नई समस्याएँ पैदा करते हैं
    किसी पर bozo bit ऑन करने का मतलब है कि आपने तय कर लिया है कि उस व्यक्ति के संचार से ज्ञान निकालने की कोशिश में समय लगाना बेकार है
    यह लेख bozo bit को एक दूसरी घटना के साथ गड्डमड्ड करता है, जिसमें कोई व्यक्ति मज़बूती से मान लेता है कि कोई खास समस्या हो ही नहीं सकती, और फिर वहीं से उलटी दिशा में कारण गढ़ता है
    इसका एक जाना-पहचाना नाम post hoc rationalization है, और सदियों बल्कि हज़ारों वर्षों से इसे टालने की चर्चा होती रही है
    लेख के उदाहरण, यानी उस कंपनी पर लौटें जिसने LLM को production database की admin permission दे दी: “यह मेरे साथ X की वजह से नहीं होगा” जैसी प्रतिक्रिया तभी जायज़ है जब X कुछ ऐसा हो: “production database admin permission किसी LLM को देना इतना अजीब और पागलपन भरा जोखिम है कि हम शुरुआत में ही ऐसा नहीं करते”
    यह कुछ वैसा ही है जैसे लोग कुछ खतरनाक खा लें और फिर त्रासदी हो जाए। अगर मैं यह खबर पढ़ूँ कि किसी ने slug खाया और brain parasite से मर गया, तो मैं यक़ीन से कह सकता हूँ कि मैं उस खास वजह से नहीं मरूँगा
    लेखक कल्पना करता है कि ऐसा इसलिए है क्योंकि मैं मानता हूँ कि मैं मरे हुए व्यक्ति से बेहतर या ज़्यादा होशियार हूँ, लेकिन असली सोच कुछ इस तरह है: “अगर मैं रस भरे slugs से भरे निर्जन द्वीप पर भूखा भी पड़ा रहूँ, तब भी मैं अपनी मर्ज़ी से slug नहीं खाऊँगा—इस पर मुझे 100% भरोसा है; इसलिए slug-borne parasite मेरे risk model में है ही नहीं”
    “उन्हें पता होना चाहिए था” वाली बात incoherent है—इससे सहमत होना भी मुश्किल है। लोग जो नहीं जानते उसके लिए लगातार दोषी ठहराए जाते हैं, और यही वयस्क जीवन का हिस्सा है
    अगर 3 साल का बच्चा slug खा ले तो मैं उसे दोष नहीं दूँगा, लेकिन अगर 30 साल का सहकर्मी slug खाए, तो मैं उसे ज़रूर दोष दूँगा। कुछ हरकतें इतनी साफ़ तौर पर मूर्खतापूर्ण होती हैं कि व्यक्ति को दोष देना ठीक है

    • “किसी चीज़ को न जानने” के लिए किसी को दोषी कैसे ठहरा सकते हैं—इसके लिए willful ignorance जैसा शब्द पहले से मौजूद है
      मुझे लगता है कि इस लेख ने एक अच्छा बिंदु उठाया जिसे मैंने पहले नहीं सोचा था, लेकिन मेरे लिए इसमें कुछ साफ़ खामियाँ भी थीं, और यह पहली है
      दूसरी यह थी कि अमेरिकियों के बारे में पढ़ते हुए मैंने खुद से पूछा: “क्या उनका distancing through differencing सचमुच वही है जो मैं AI द्वारा किए गए operational deletion incident को नज़रअंदाज़ करते समय करता हूँ?”
      यानी अगर वे यह जाने बिना कि किसी दूसरे कारखाने में जोखिम कैसे पैदा हुआ, बस यह मान लें कि वह उन तक नहीं पहुँचेगा, तो यह जायज़ नहीं है
      लेकिन अगर उन्होंने सुना कि किसी manager ने एक नया, experimental, non-deterministic humanoid robot फैक्टरी फ़्लोर पर उतार दिया, ताकि वह skilled workers की आज़ादी से मदद करे और उन्हें तेज़ काम करवाए, तो उनकी उपेक्षा को उसी नज़र से नहीं देखा जा सकता
      फिर भी मैं निष्कर्ष स्वीकार करता हूँ। क्योंकि लापरवाही binary नहीं होती
      अगली बार जब मैं कोई बेतुकी कहानी सुनूँगा, तो शायद रुककर सोचूँगा: “भले ही मैं उनकी तरह लापरवाह नहीं हूँ, लेकिन मैं जो कर रहा हूँ उसमें ऐसी कौन-सी चीज़ है जहाँ मुझे ज़्यादा सावधान होकर safety guardrails लगानी चाहिए?”
    • मैं यह नहीं पूछूँगा कि 3 साल के बच्चे ने slug क्यों खाया
      लेकिन अगर 30 साल के सहकर्मी ने slug खाया, तो मैं पूरी तरह जाँच करूँगा कि बात वहाँ तक पहुँची कैसे
      अगर मुझे उसे “दोष” देना है, तो पहले मैं यह पूछूँगा कि हमने slug खाने वाला व्यक्ति नौकरी पर रखा ही क्यों, और क्या हम अब भी ऐसा कर रहे हैं
    • इस लेख से मेरी मुख्य सीख यह है कि लेखक bozo bit क्या होता है, यह नहीं जानता

  • इसमें कुछ वाजिब बातें हैं
    “मैं बताना चाहता हूँ कि यह प्रतिक्रिया उलटी क्यों पड़ती है। और bozo bit ऑन करने की रिश्तेदार-सी इस घटना के लिए तकनीकी शब्द भी बताना चाहता हूँ। इसे distancing through differencing कहते हैं” — इस हिस्से में यह प्रतिक्रिया उत्पादक भी है और उलटी भी पड़ती है
    ऐसी दुनिया में जहाँ पहले ही हमारी क्षमता से ज़्यादा घटनाएँ लगातार सामने आ रही हों, हर input को evaluate न करना एक बहुत बड़ा optimization है, इसलिए यह उत्पादक है
    और साथ ही, लेख में दिए गए कारणों से यह उलटा असर भी करती है
    असली कौशल यह जानना है कि किस चीज़ को गंभीरता से लेना है और किस पर ध्यान देना है। वह कौशल सीख जाऊँ तो फिर बताऊँगा

  • अगर किसी ने AI को production environment का direct access दे दिया, तो मुझे उससे क्या सीखना चाहिए?

    • अगर LLM incident को थोड़ी उदारता से पढ़ें, तो इससे यह सबक निकाला जा सकता है कि production access पर access control होना चाहिए, और destructive operations के लिए two-person approval चाहिए
      मैं कभी एक तेज़ी से बढ़ रही कंपनी में काम करता था, जहाँ engineering practices का काफ़ी हिस्सा 1000 लोगों वाली multinational company से कम और garage startup से ज़्यादा मिलता-जुलता था
      उस समय तीन बातें सच थीं। पहली, service deploy करने का तरीका यह था कि लैपटॉप में Git checkout directory तक cd करो और फिर <tool> deploy <service-name> चलाओ, और जो Git commit उस समय checkout था वही deploy हो जाता था
      दूसरी, सहकर्मियों पर भरोसे की संस्कृति के कारण deploy system में access control बहुत न्यूनतम था। एक allowlist थी, और अगर आप उसमें थे तो किसी भी service को deploy कर सकते थे
      तीसरी, मुख्य Git repository बड़ी थी और office Wi‑Fi भरा हुआ रहता था, इसलिए clone में बहुत समय लगता था। नए hires को जल्दी शुरू कराने के लिए laptop provisioning image में main repository का Git checkout पहले से शामिल रहता था
      फिर एक दिन database team में नया intern आया, और Database Team 101 wiki tutorial का पालन करते हुए उसने यह recommended command चला दी कि deploy permission काम कर रही है या नहीं: <tool> deploy --prod <database>
      बाद में पता चला कि laptop provisioning image पुरानी थी, और उस intern ने अभी तक वह onboarding lesson भी नहीं लिया था जिसमें git pull origin master करना सिखाया जाता था
      “LLM ने production environment बिगाड़ दिया” वाली कहानी और “intern ने production environment बिगाड़ दिया” वाली कहानी एक जैसी हैं, लेकिन दूसरी वाली से सीखना आसान है। क्योंकि उसमें अलग-अलग गलतियाँ छोटी हैं

  • incident analysis के नज़रिये से देखें, तो bozo bit ऑन करने के बाद सीखना बंद कर देना उस स्थिति जैसा है जहाँ पूरे fault tree को देखना चाहिए, लेकिन कोई एक ही contributing factor—यानी “human error!”—पर रुक जाता है
    दिए गए उदाहरण में fault tree का “LLM loop को production access दिया गया” वाला node पाठक के “मूर्ख को ignore करो” heuristic को trigger कर देता है
    लेकिन उसका sibling node—“system ने API के ज़रिए unconfirmed deletion की अनुमति दी”—एक कीमती सबक है, और अगर आप पहली नज़र में दिखे node पर ही रुक जाएँ तो यह छूट सकता है
    fault tree में ऐसे child nodes भी होने चाहिए जो यह खंगालें कि वह खतरनाक operation GUI से तो हटा दिया गया था, फिर API में क्यों बचा रहा, और LLM को production access मिला ही कैसे

    • दूसरी ओर, यह पूछा जा सकता है कि क्या हमें bozo जैसी जगह से आई report में एक तर्कसंगत fault tree पुनर्निर्मित होने की संभावना कम माननी चाहिए
      और दूसरी तरफ़, असली सवाल शायद यह है कि क्या उसमें ऐसे nodes मौजूद हैं जो bozo स्थिति में और चमककर दिखते हैं
      उन nodes की पहचान गलत हुई या वे आपस में गलत जोड़े गए—यह शायद उतना महत्वपूर्ण नहीं है। आख़िरकार, मुझे उनकी पिछली विफलता का fault tree नहीं चाहिए; मुझे तो यह देखना है कि अपनी भविष्य की विफलता रोकने के लिए मैं अपने fault tree में क्या छोड़ रहा हूँ

  • यह लेख साफ़ तौर पर उस हिस्से को छोड़ देता है जहाँ इसे समझाना चाहिए था कि दिए गए मुख्य उदाहरण में bozo पर bozo bit ऑन करना गलत क्यों है
    यह paper वाले case पर चला जाता है और अपनी ही पोस्ट के मुख्य उदाहरण को नहीं संभालता
    इसलिए लगता है जैसे लेखक किसी दूसरे bozo को चुपके से निकल जाने देना चाहता है

  • मैंने एक बात सीखी: AI tools का इस्तेमाल मत करो