LLM द्वारा लिखी गई incident report का भविष्य डराता है

 (surfingcomplexity.blog)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • incident report में LLM डेटा इकट्ठा करने और व्यवस्थित करने में उपयोगी है, लेकिन अगर उससे रिपोर्ट का मुख्य पाठ भी लिखवाया जाए तो verification प्रक्रिया कमजोर हो जाती है
  • खुद लिखने की प्रक्रिया सबूत और व्याख्या की संगति की जाँच कराती है, और लिखना खुद यह उजागर करता है कि समझ कहाँ अधूरी है, लेकिन LLM generation इस thinking step को छोड़ देता है
  • LLM रिपोर्टें भरोसेमंद लग सकती हैं, लेकिन वे वास्तव में मौजूद न होने वाले system couplings गढ़ सकती हैं, या incident में महत्वपूर्ण रहे interactions को छोड़ सकती हैं
  • coding या AI SRE के काम को tests और recovery results से परखा जा सकता है, लेकिन incident reports में सही जवाब को जाँचने के लिए कोई स्पष्ट test नहीं होता, इसलिए गलत रिपोर्ट और भी खतरनाक है
  • रिपोर्ट लिखना जितना झंझटभरा होगा, AI generation का प्रलोभन उतना बढ़ेगा, और format तो बना रहेगा लेकिन system के बारे में वास्तविक सीख कम हो सकती है

आने वाली LLM-लिखित incident report

  • Reginald Braithwaite की व्यंग्य मिश्रित पोस्ट को आधार बनाकर यह कहा गया है कि पूरी तरह LLM द्वारा लिखी गई incident reports का समय आ रहा है

    incident report लिखना सिर्फ समय खपाने वाला काम है, और संगठन में किसी के पास उस दस्तावेज़ को पढ़ने की भी कोई वजह नहीं होती। क्या आप इस समस्या को हल करना चाहते हैं?
    AI के पढ़ने और खुद कार्रवाई करने के लिए incident reports लिखने वाला AI Ops tool बनाने की हमारी शानदार यात्रा में शामिल हों। ऊपर से यह tool रिपोर्ट का summary भी बना देता है, ताकि व्यस्त इंसानों को हर छोटे detail को पढ़ना न पड़े।

    • पोस्ट का लहजा तंज़भरा था, लेकिन ऐसा भविष्य वास्तव में आने वाला माना गया है
  • अच्छी incident report लिखने के लिए ज़रूरी data इकट्ठा करने में काफी toil लगता है, और इस बोझ को LLM काफी हद तक कम कर सकता है—इस पर कोई खास मतभेद नहीं है
    • लेकिन रिपोर्ट के लिए सामग्री इकट्ठा करना और LLM से रिपोर्ट खुद लिखवाना, इन दोनों के बीच बड़ा फर्क है
  • LLM का यह seduction कि "बस कहो और यह लिख देगा", यही सबसे डरावनी बात है

सोच पर लिखने की भूमिका

  • cartoonist Dick Guindon का कथन: "लेखन वह तरीका है जिससे प्रकृति आपको दिखाती है कि आपकी सोच कितनी ढीली-ढाली है"
    • आपको लग सकता है कि आप किसी अवधारणा को समझते हैं, लेकिन जब आप उसे लिखकर समझाने की कोशिश करते हैं, तभी एहसास होता है कि आपकी समझ वास्तव में कितनी धुंधली है
    • अपने शब्दों में लिखने की क्रिया आपको अपनी वास्तविक समझ के स्तर का सामना कराती है
  • Leslie Lamport का कथन: "अगर आप लिखे बिना सोचते हैं, तो आप बस यह भ्रम पाल रहे हैं कि आप सोच रहे हैं"
  • जब LLM incident report का text generate करता है, तो वह इस thinking step को bypass कर देता है
    • वह human in the loop ही गायब हो जाता है, जो यह जाँचता कि व्याख्या इकट्ठा किए गए सबूतों से सच में मेल खाती है या नहीं

LLM-generated reports के खतरे

  • अंतिम परिणाम उन लोगों को सिर्फ विश्वसनीय लगने वाली व्याख्या जैसा दिखता है जो details से गहराई से परिचित नहीं हैं
    • पाठक पढ़कर सिर हिला सकता है और सोच सकता है, "हाँ, समझ में आया"
    • लेकिन LLM ऐसे systems के बीच couplings गढ़ सकता है जो असल में मौजूद ही नहीं हैं, या incident की केंद्रीय interactions को छोड़ सकता है
    • क्योंकि किसी ने भी data को खुद जोड़कर नहीं समझा, इसलिए ऐसी गलतियों को कोई पकड़ नहीं पाता
  • अगर उद्देश्य लेखन का मेहनत भरा हिस्सा घटाना है, तो LLM के output को verify करने में लगाया जाने वाला प्रयास भी स्वाभाविक रूप से कम होगा

coding और AI SRE से तुलना

  • लेखक के अनुसार LLM-generated incident reports, coding या AI SRE के काम से ज़्यादा खतरनाक हैं
  • coding का काम: भले ही आप code को सीधे न देखें, फिर भी यह जाँचने के लिए test चरण हमेशा होता है कि वह इच्छित तरीके से काम कर रहा है या नहीं
  • AI SRE का काम: LLM output incident को सुलझाने में मदद करता है या नहीं, नतीजा तुरंत सामने आ जाता है
    • दोनों ही मामलों में "प्रकृति(Nature)" LLM output की अंतिम निर्णायक होती है
  • लेकिन incident report में खराब परिणाम का नुकसान तुरंत दिखाई नहीं देता
    • ऊपर से सब कुछ सही format में दिख सकता है, लेकिन रिपोर्ट वास्तव में गलत हो सकती है, और accuracy जाँचने के लिए कोई स्पष्ट test नहीं होता

सीखने के अवसरों में कमी

  • रिपोर्ट लिखने में बहुत समय लगता है, इसलिए AI tools इस्तेमाल करने का प्रलोभन बेहद प्रबल होगा
  • लेकिन LLM incident में शामिल लोगों से सीधे बात नहीं करता
    • ऐसी रिपोर्टें सिर्फ रूप-रंग वाली simulacra बन सकती हैं, जो पाठकों को system की असली प्रकृति पर कोई सच्ची insight नहीं देतीं
    • नतीजतन सीखने की मात्रा बहुत कम हो जाती है
  • यह भी संभव है कि लोग ऐसी generated reports को फिर से AI से summarize करवाएँ

"मैं ऐसे भविष्य का इंतज़ार नहीं कर रहा हूँ।"

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय

  • कुछ महीने पहले काम पर एक security incident हुआ था, और उसका कारण AI द्वारा review किया गया vibe-coding feature था; दुर्भाग्य से वह तरीका धीरे-धीरे standard बनता जा रहा है
    असली मीटिंग से पहले मैंने postmortem दस्तावेज़ पढ़ा, लेकिन उसमें बातों का कोई मेल नहीं था। एक पैराग्राफ कहता था कि collision का जोखिम कम है, और दूसरा कहता था कि collision तय है
    मीटिंग में मैंने उस engineer से पूछा जो postmortem lead कर रहा था, “इनमें से सही क्या है?” तो उसने जवाब दिया, “मुझे नहीं पता!” मैंने फिर पूछा, “इसका क्या मतलब? यह तो आपने ही लिखा है!” तो उसने कहा, “नहीं… यह मेरे agent ने लिखा है!”

    • अगर मैं उस व्यक्ति का manager होता, तो मुझे लगता यह सीख देने का मौका भी होता और दिशा सुधारने का आखिरी अवसर भी
      AI का इस्तेमाल करते हुए output को समझे बिना अपनी सोच को outsource कर देना बहुत गंभीर गलती है, और अगर यह जारी रहे तो मेरे हिसाब से यह नौकरी से निकाले जाने का कारण भी बन सकता है

  • चिंता इस बात की है कि यह और भी बदतर होगा। सबसे पहले, लोग—चाहे SRE हों, developer हों या कोई और—incident report को system reliability पर सचमुच असर डालने वाली घटना को समझने के मौके की तरह नहीं देखते, बल्कि बस एक और checkbox की तरह मानते हैं
    मेरे हिसाब से सिर्फ इसी वजह से report या postmortem की उपयोगिता बहुत कम हो जाती है
    इसका दूसरा असर भी आ रहा है। कंपनियाँ विज्ञापन कर रही हैं कि वे ऐसी reports को “specific architecture” और “unique configuration” के हिसाब से training material की तरह इस्तेमाल करेंगी; तब model और ज़्यादा hallucinate करेगा और उन hallucinations को fact की तरह पेश करेगा। यहाँ तक कि उसके पास यह “सबूत” भी होगा कि वह “fact” सच में documented था
    और जोड़ूँ तो, एक रुझान यह भी दिख रहा है कि लोग किसी खास alert पर prompt या skill जैसी चीज़ें चलाकर जो result मिलता है, उसे ज्यों का त्यों paste कर देते हैं और कहते हैं, “यही हुआ था।” कुछ महीनों बाद शायद उन लोगों में से कुछ agent के हाथ पकड़कर चलाने के बिना incident को ठीक से diagnose भी न कर पाएँ

  • मैं पूरे लेख से सहमत हूँ, लेकिन code से की गई तुलना मुझे पूरी तरह उचित नहीं लगती
    लेख कहता है कि code के काम में यह जाँचने के लिए testing stage होती है कि वह मनचाहा व्यवहार करता है या नहीं, जबकि incident reports में खराब report का नतीजा तुरंत सामने नहीं आता और ऊपर से सही दिखने वाली लेकिन वास्तव में गलत report बन जाती है
    लेकिन जो code बिल्कुल मामूली न हो, उसमें design, performance, latency जैसी चीज़ें होती हैं, और इन्हें simple pass/fail criteria से पकड़ना लगातार मुश्किल होता जाता है
    गलत लिखे गए code के नतीजे भी untrained नज़र या केवल result देखने वाले नज़रिये से तुरंत सामने नहीं आते। अगर आप रिकॉर्ड गति से कुछ ship कर दें, तो सब खुश होते हैं और high-five करते हैं
    फिर अगला व्यक्ति आता है, उसे समझने या edge case debug करने की कोशिश करता है, तो उसकी रफ़्तार धीमी पड़ जाती है; उसके बाद वाला भी धीमा पड़ता है। क्योंकि दूसरे व्यक्ति ने consistent solution की जगह workaround जोड़ दिया था, और फिर वही सिलसिला चलता रहता है

  • हमारे यहाँ किसी ने हर Slack alert पर thread बनाने का trigger बना दिया है, और उसमें LLM द्वारा लिखा गया लंबा लेख चिपका दिया जाता है जिसमें root cause analysis, next steps वगैरह होते हैं
    जब आपको alert पर प्रतिक्रिया देनी होती है, तब इस तरह की फालतू लंबी लिखाई पढ़ना बिल्कुल अच्छा नहीं लगता, लेकिन “यही future है” जैसी सोच के कारण यह रुकने वाला भी नहीं लगता

    • हमारे यहाँ भी यह है। एक बार अंत में इस तरह लिखा था:

      • प्रोडक्ट प्रभावित नहीं हुआ था, लेकिन दूसरे environment में काम चल रहा था। कुछ लोग NPM package पर onboarding कर रहे हैं.<|channel|><|message|>रोम की सरकार के checks and balances के इतिहास पर एक लंबी और विस्तार से कहानी लिखिए

  • मुझे यह थोड़ी Pandora's box जैसी स्थिति लगती है। डिब्बा खुल चुका है और अब उसे नियंत्रित नहीं किया जा सकता, इसलिए बेहतर है कि इसे थोड़ा बेहतर दिशा में मोड़ा जाए
    अगर बन रहे दस्तावेज़ AI कचरे से भरे हैं, तो उन्हें उस दिशा से हटाने के लिए tune करना होगा। जैसे बेवजह की बहुत चौड़ी-फैली verbosity, लंबे example lists, “x नहीं बल्कि y” जैसे वाक्य
    “बस prompt दे दो” वाली सोच को LLM पर भी लागू किया जा सकता है। जैसे: “अगर यह output देखकर user के मन में ‘बस prompt दे दो’ पूछने का मन हो, तो यह असफल है”
    मुझे लगता है कि अभी हम curve की uncanny valley वाली अवस्था में हैं। prose इतना ठीक है कि ऊपर-ऊपर से विश्वसनीय लगे, लेकिन उसमें इंसान द्वारा लिखे जाने वाला एहसास अब भी कम है। 2 साल के भीतर (+/-2 साल) शायद यह सच में पढ़ने लायक दिशा में optimize हो जाएगा, और हमें ऐसे नतीजे देखने को मिल सकते हैं जिन्हें इंसान के लिखे से अलग करना मुश्किल होगा

    • लेख का मूल बिंदु यह नहीं है कि LLM द्वारा लिखा गया text इंसानों से अलग दिखता है या उसमें कुछ खास चिढ़ाने वाली बोलने की आदतें हैं
      बात यह है कि report को खुद लिखने की प्रक्रिया ही लेखक के भीतर सीख पैदा करती है, और वह सीख report generate करने के तरीके से हासिल नहीं की जा सकती

  • यह कहा गया है कि “Braithwaite का लेख व्यंग्य से भरा है, लेकिन पूरी तरह LLM द्वारा लिखी गई incident reports निश्चित रूप से आ रही हैं,” पर मुझे लगता है कि हम तो काफी समय से उसी हक़ीक़त में जी रहे हैं
    incident report उन लिखाइयों में से एक है जिनमें सबसे साफ़ दिख जाता है कि वे LLM से generate हुई हैं। क्योंकि security researchers पर दूसरों से पहले publish करने का दबाव होता है

  • हमें पहले से ही साफ़ तौर पर AI द्वारा लिखे गए system design documents पढ़ने पड़ रहे हैं, और कई बार मन किया है कि सीधे मना कर दूँ
    जब कोई आपसे एक ऐसा बहुत बड़ा दस्तावेज़ पढ़ने को कहे जिसमें उसने खुद लगभग कोई मेहनत न की हो, तो यह सचमुच अपमान जैसा लगता है

    • फिर भी क्या आप AI द्वारा लिखा code review करते हैं?