“शायद चल जाएगा” प्रोडक्शन इन्फ्रास्ट्रक्चर में नहीं चलता #
BASTION एक “AI Ops Platform” है, जिसमें AI इन्फ्रास्ट्रक्चर के लॉग का विश्लेषण करता है, हमलों को अपने-आप रोकता है, और बैंडविड्थ की गुणवत्ता को नियंत्रित करता है। ऐसा लिखने पर यह दिखावटी लगता है, पर विकास में हम सबसे ज़्यादा ध्यान फ़ीचर बढ़ाने पर नहीं देते। हम ध्यान देते हैं उस साधारण अनुशासन पर ―― “केवल वही प्रोडक्शन में डालो जिसका चलना सिद्ध किया जा सके।”
प्रोडक्शन इन्फ्रास्ट्रक्चर में स्वचालित नियंत्रण डालने का अर्थ है कि AI की निर्णय-चूक सीधे एक हादसे में बदल जाती है। हमला न होने वाले ट्रैफ़िक को हमला मानकर रोक दें, तो असली ग्राहक बाहर अटक जाते हैं। जब भीड़ (congestion) है ही नहीं, तब बैंडविड्थ घटा दें, तो सेवा बिगड़ जाती है। इसीलिए “सिद्धांत में सही होना चाहिए”, “शायद चल जाएगा” इस स्तर की चीज़ों को हम प्रोडक्शन में नहीं डालते।
इस लेख में हम लिखते हैं कि किसी नई पहचान-लॉजिक या नियंत्रण को प्रोडक्शन में डालने से पहले हम असल में क्या करते हैं।
इंजीनियर “सुंदर डिज़ाइन” की ओर खिंचते हैं ―― और यही जाल बन जाता है #
सच कहें तो, हमारे पास भी एक “सैद्धांतिक रूप से सुरुचिपूर्ण मॉडल” था। काग़ज़ पर उसका तर्क बैठता था, और समझाने में अच्छा लगता था। ऐसे डिज़ाइन आकर्षक होते हैं।
पर प्रोडक्शन का ट्रैफ़िक काग़ज़ की मान्यताओं के अनुसार नहीं चलता। हमने अपने इन्फ्रास्ट्रक्चर के असली डेटा पर उस मॉडल को परखा, और ऐसे हिस्से पाए जो अपेक्षा से अलग व्यवहार करते थे। तब हमने जो किया वह सरल था ―― हमने मॉडल को ही दोबारा बनाया, और उसके दावों को उस दायरे तक घटा दिया जिसे डेटा समर्थन देता है। “आरेख सुंदर है इसलिए अपना लें” नहीं, बल्कि केवल उतना ही अपनाएँ जितने का डेटा समर्थन करता है।
यह हार नहीं है। उल्टे, अपनी सुंदर परिकल्पना को अपने ही डेटा से ग़लत साबित कर पाना ―― यही, हमारा मानना है, प्रोडक्शन इन्फ्रास्ट्रक्चर सँभालने वाले उत्पाद के लिए अनिवार्य है।
सत्यापन की रीति ―― प्रोडक्शन पर असर डाले बिना परिकल्पना आज़माना #
ठोस रूप में, हम इसी क्रम में सत्यापन करते हैं।
1. केवल अवलोकन से परिकल्पना आज़माएँ (READ-ONLY) #
नई पहचान-लॉजिक पहले एक “केवल-अवलोकन” मोड में चलती है, जो प्रोडक्शन में कुछ भी नहीं लिखती। प्रोडक्शन की रोक या नियंत्रण को बिल्कुल नहीं छूती; केवल असली डेटा पर यह दर्ज करती है कि “यदि यह प्रोडक्शन होता तो उसने कैसे निर्णय किया होता।” इस तरह, परिकल्पना ग़लत निकले तो भी किसी को कोई दिक़्क़त नहीं होती।
2. जाँचें कि वह असली असामान्यता को महज़ शोर से अलग कर पाती है या नहीं #
पहचान-लॉजिक का मूल्य “असामान्यता ढूँढ़ पाने” से कम, और “जो असामान्य नहीं है उसे असामान्य न कहने” से अधिक तय होता है। पृष्ठभूमि-शोर से भरे लॉग में से क्या वह केवल असली असामान्यता चुन पाती है? हम यह नहीं देखते कि कोई एकल मीट्रिक किसी सीमा (threshold) को पार कर गया या नहीं, बल्कि यह देखते हैं कि क्या कई अवलोकन-तल एक-दूसरे के साथ कदम मिलाकर बिगड़ने लगते हैं (एक समन्वित आरंभ, co-onset) ―― और इसे हर लक्ष्य की अपनी सामान्य स्थिति से सापेक्ष परिवर्तन के रूप में पकड़ते हैं। हम अपने परिवेश में अनुकरणीय भार और घटनाएँ देकर, असली डेटा पर जाँचते हैं कि लॉजिक “असली समन्वित असामान्यता” को “महज़ संयोग से एक ही समय पर हुई असंबद्ध उतार-चढ़ाव” से अलग कर पाती है या नहीं। यदि अलग न कर पाए, तो वह पहचान किसी काम की नहीं।
3. अपनी परिकल्पना से उल्टा दृष्टिकोण टकराएँ #
हम जान-बूझकर अपनी ही परिकल्पना पर विरोधी व्याख्याएँ टकराते हैं: “क्या यह पहचान सचमुच काम कर रही है? कहीं यह बस संयोग से सही तो नहीं बैठ गई?” अवलोकन-खिड़की लेने का ढंग बदलने पर भी निष्कर्ष वही रहता है या नहीं; किसी और व्याख्या से वही परिणाम तो नहीं निकलता। जो दावा खंडन के सामने टिक न सके, उसे उत्पाद के विवरण से हटा दिया जाता है।
जो सिद्ध हो वह प्रोडक्शन में, जो सिद्ध न हो वह अवलोकन-परत में #
केवल वही, जो सत्यापन पार कर लेता है, चरण-दर-चरण प्रोडक्शन तक बढ़ता है। प्रोडक्शन में लिखाई हमेशा “ड्राई-रन → सीमित प्रोडक्शन → पूर्ण प्रोडक्शन” इन तीन चरणों से होकर गुज़रती है। आपातकालीन-रोक कमांड शुरू से ही तैयार रहता है। और हर प्रोडक्शन-रोलआउट उस द्वार से गुज़रता है जहाँ “AI सुझाव देता है और मनुष्य स्वीकृति देता है।”
यह अनुशासन उत्पाद को प्रस्तुत करने के ढंग में भी सीधे झलकता है। मसलन, BASTION के दो मॉड्यूल की परिचालन-स्थिति अलग है।
- सुरक्षा मॉड्यूल ने वास्तविक संचालन में अनेक आक्रमण-अभियानों (attack campaigns) को पहचाना और अपने-आप रोका है, और यह प्रोडक्शन में पूर्ण-स्वचालित रूप से चल रहा है।
- दूसरी ओर, गुणवत्ता मॉड्यूल (बैंडविड्थ का गतिशील नियंत्रण) एक फ़ीचर के रूप में लागू तो है, पर अब भी मुख्यतः अवलोकन-केंद्रित, चरणबद्ध रूप से उतारा जा रहा है। जब लाइन सचमुच भीड़ (congestion) में आती है तब नियंत्रण मनचाहे ढंग से काम करता है या नहीं ―― यह हम पहले उसी स्थिति के डेटा से जाँचते हैं ―― इसीलिए हम यह नहीं लिखते कि यह “प्रोडक्शन में पूरी क्षमता पर चल रहा है।”
“लागू कर दिया” का अर्थ “प्रोडक्शन में चलता है” नहीं होता। इस भेद को हम उत्पाद-पृष्ठ पर भी धुँधला नहीं करते।
AI (LLM) पर भी हम भरोसा नहीं, सत्यापन करते हैं #
यह “भरोसा मत करो, सत्यापन करो” वाला रुख़ BASTION के केंद्र में बसे स्थानीय (local) LLM की ओर भी है।
पहले एक बार, स्थानीय LLM ने एक निगरानी-रिपोर्ट में एक ऐसी संख्या गढ़ दी जो थी ही नहीं (उस पूरे प्रसंग और उपाय को हमने “स्थानीय LLM द्वारा निगरानी-रिपोर्ट में संख्याएँ गढ़ने का प्रसंग और उसका उपाय” में लिखा है)। तब से, LLM के आउटपुट में से, जो निर्णय सिस्टम को असल में चलाते हैं ―― कोई IP हमलावर है या नहीं, इसका अंतिम निर्णय, और रोक का निष्पादन ―― वे LLM से नहीं कराए जाते, बल्कि असली मशीन-लॉग से मिलान कर गणितीय, नियतात्मक (deterministic) निर्णय से किए जाते हैं। LLM जिसमें कुशल है वह है प्राकृतिक भाषा का सारांश और सँवारना ―― प्रोडक्शन के निर्णय लेना नहीं। LLM भी, और (जो सेंध-योग्य DMZ में रखा जाता है वह) Agent भी, हमारे लिए “भरोसा नहीं, सत्यापन” की वस्तुएँ हैं।
यह साधारण अनुशासन ही सबसे बड़ा अंतर क्यों बनता है #
AI Ops और AI सुरक्षा का क्षेत्र दिखावटी शब्दों से भरा है। पर प्रोडक्शन इन्फ्रास्ट्रक्चर सँभालने वाले ज़मीनी ज़िम्मेदार जिस बात की सचमुच परवाह करते हैं वह है ―― “क्या यह कोई हादसा तो नहीं कराएगा”, “ग़लत पहचान या ग़लत नियंत्रण से कहीं हम मुश्किल में तो नहीं पड़ेंगे।”
इसीलिए हम buzzword से नहीं, बल्कि इस तथ्य से बात करते हैं कि यह असल में चल रहा है ―― प्रोडक्शन में चलता आक्रमण-अभियान पहचान, बंद-नेटवर्क (closed-network) विन्यास में लॉग का बिल्कुल बाहर न जाना, और “केवल वही प्रोडक्शन में डालो जिसे सिद्ध किया जा सके” यह बनाने का तरीक़ा ही।
सुंदरता से तय मत करो। काग़ज़ पर तय मत करो। अपनी सुंदर परिकल्पना पर डेटा से शक कर पाना ―― यही वह अनुशासन है जिसके बल पर हम BASTION को उस स्थिति तक लाते हैं जहाँ उसे प्रोडक्शन इन्फ्रास्ट्रक्चर में डाला जा सके।
