आपने किसी LLM को पूरे आत्मविश्वास से कुछ ग़लत कहते देखा है। हमने भी देखा है। इसीलिए PulseMQ में मशीन से जवाब पाने का रास्ता “किसी डॉक्यूमेंट के बारे में chatbot से पूछना” नहीं है। यह तीन ठोस नियम हैं, जो कोड के स्तर पर लागू होते हैं और प्लांट फ़्लोर पर इंडस्ट्रियल AI को ईमानदार रखते हैं।
इंडस्ट्रियल AI को परखने वाले हर प्लांट मैनेजर का एक ही सवाल होता है: “मुझे कैसे पता चलेगा कि यह बातें गढ़ नहीं रहा?” यह सवाल वहम नहीं है। यह पेशेवर सावधानी है।
Large language model धाराप्रवाह, आत्मविश्वास भरे और सही लगने वाले जवाब देने में कमाल के होते हैं। यही उनका काम है। समस्या यह है कि ऐसा ही धाराप्रवाह, आत्मविश्वास भरा और सही लगने वाला जवाब आपको तब भी मिलता है जब असली तथ्य सही हों, और तब भी जब ग़लत हों। मार्केटिंग टूल में यह बस एक झुंझलाहट है। जिस प्लांट को लगातार प्रोडक्ट बनाते रहना है, वहाँ यह एक ख़तरा है।
PulseMQ मैन्युफैक्चरिंग के लिए एक AI सिस्टम है। यह AWS पर Claude (Anthropic) पर चलता है। यह लाइव उपकरणों के बारे में सरल अंग्रेज़ी में पूछे गए सवालों का जवाब देता है। और इसे चलती प्रोडक्शन लाइन पर डिप्लॉय करने लायक सुरक्षित हम एविडेंस कॉन्ट्रैक्ट से बनाते हैं — तीन नियम जो कोड में लागू होते हैं, सिर्फ़ मार्केटिंग में नहीं।
अगर इस session में कोई tag कंट्रोलर से poll नहीं हुआ, तो PulseMQ उसकी वैल्यू ख़ुद से नहीं बनाएगा। कोई hallucinated setpoint नहीं। कोई गढ़ी हुई cycle count नहीं। सही लगने वाली पर ग़लत sensor रीडिंग नहीं।
जब कोई ऑपरेटर पूछता है “Zone 1 अभी क्या कर रहा है?”, तो assistant वह वैल्यू किसी डॉक्यूमेंट या training set में नहीं ढूँढता। वह उस poll loop के पास जाता है जो कंट्रोलर को पढ़ता है, और सबसे ताज़ा वैल्यू माँगता है। अगर poll loop ने वह tag देखा ही नहीं, तो assistant आपको यही बताता है — कुछ गढ़ता नहीं।
ऑपरेटर पूछता है: “Extruder 2 पर melt temperature कितना है?”
AlarmIQ लाइव poll cache देखता है: Ext2_MeltTemp आख़िरी बार 340 ms पहले 218°C पढ़ा गया था। जवाब: “218°C, 340 ms पहले पढ़ा गया।”
अगर वह tag poll नहीं हो रहा, तो जवाब होता है “मैं अभी Ext2_MeltTemp को poll नहीं करता। क्या आप इसे poll list में जोड़ना चाहते हैं?” — कोई अनुमान नहीं।
Alarm, cycle leg, permissive, drift flag — assistant का हर दावा उस tag के साथ दर्ज होता है जिससे वह आया, जिस पल वह पढ़ा गया, और जिस कंट्रोलर से आया। Audit किया जा सकता है। Replay किया जा सकता है। जब कॉरपोरेट से कोई पूछे “हमने लाइन रोकने का फ़ैसला कैसे किया?”, तब भी उसका बचाव किया जा सकता है।
यह दो वजहों से अहम है। पहली, जो इंजीनियर किसी जवाब को जाँचना चाहता है, वह एक क्लिक में उसे कंट्रोलर के raw डेटा तक ट्रेस कर सकता है। दूसरी, जब जवाब के आधार पर कोई एक्शन लिया जाता है — alarm reset करना, setpoint बदलना, मेंटेनेंस भेजना — तो evidence chain अपने-आप audit log का हिस्सा बन जाती है। उसे सेव करना याद रखने की ज़रूरत नहीं।
AlarmIQ कहता है: “Line 5 DI_Air_Pressure_OK = FALSE का इंतज़ार कर रही है।”
जवाब पर क्लिक करें। आपको दिखता है: वह सटीक rung जो इस input को पढ़ता है, input की लाइव स्थिति (FALSE), वह timer जो प्रेशर लौटने पर permissive क्लियर कर देगा, और input की पिछले 30 सेकंड की हिस्ट्री। कुछ भी गढ़ा हुआ नहीं। सब कुछ ट्रेस करने लायक।
Machine Intelligence™ दसियों हज़ार रन में हर cycle के हर leg पर नज़र रखता है — forward stroke, return, total, dwell। “Normal” एक मापी गई रेंज है, अनुमानित नहीं। Drift detection deterministic है: पिछले 8,400 cycle में shuttle return leg का औसत 4.2 सेकंड था; इस बार 6.8 सेकंड लगे। यह एक observation है, अनुमान (inference) नहीं।
Predictive model ऐसे तरीक़ों से ग़लत हो सकते हैं जिन्हें audit करना मुश्किल है। सीखी हुई रेंज के साथ ऐसा नहीं होता। अगर PulseMQ कहता है कि कोई mechanism drift कर रहा है, तो आप पिछले 8,400 cycle का डेटा निकालकर ख़ुद देख सकते हैं। अगर आप असहमत हैं, तो असहमति डेटा को लेकर होगी, किसी छिपे हुए मॉडल के confidence को लेकर नहीं।
Machine Intelligence फ़्लैग करता है: “Pusher cylinder का return leg drift कर रहा है — मौजूदा औसत 5.1s, 12,340 cycle में सीखा गया normal 4.6s ± 0.3s।”
आप नीचे के dataset पर query चला सकते हैं। आप फ़्लैग पर सवाल उठा सकते हैं। आप threshold बदल सकते हैं। जो आपको नहीं मिलेगा, वह है बिना सबूत का black-box जवाब “AI को लगता है कुछ गड़बड़ है”।
मैन्युफैक्चरिंग AI का बाज़ार ऐसे टूल्स से भरा है जो उन उपकरणों के बारे में सही लगने वाले जवाब देते हैं, जिनसे वे असल में कभी जुड़े ही नहीं। Vendor synthetic डेटा पर डेमो दिखाते हैं। उनके “insights” दरअसल सोच-समझकर लगाए गए अनुमान हैं, जिन्हें इंजीनियरिंग निष्कर्ष की तरह पेश किया जाता है।
जब ग़लत जवाब की क़ीमत कम हो, तब यह तरीक़ा ठीक है। लेकिन तब ठीक नहीं, जब ग़लत जवाब की वजह से ऑपरेटर ऐसा alarm reset कर दे जो reset नहीं होना चाहिए था, या मेंटेनेंस टेक्नीशियन ऐसा पार्ट बदल दे जो ख़राब ही नहीं था, या लाइन इसलिए रुक जाए क्योंकि “drift warning” असल में सिर्फ़ noise थी।
वह failure mode जिसकी कोई बात नहीं करता: ऐसा AI सिस्टम जो 95% समय सही है और बाक़ी 5% समय ग़लत — और दोनों जवाब एक जैसे दिखते हैं। अगर आप अच्छे जवाब और hallucination में फ़र्क़ नहीं कर सकते, तो वह “95%” बेकार है — हर जवाब को वैसे भी जाँचना पड़ेगा, तो AI को छोड़ ही देते।
एविडेंस कॉन्ट्रैक्ट इसे डिज़ाइन के स्तर पर ठीक करता है। PulseMQ का हर जवाब एक chain के ज़रिए कंट्रोलर के raw डेटा तक जुड़ा होता है। अगर यह chain नहीं बन सकती, तो जवाब बनता ही नहीं। आपको कभी आत्मविश्वास से दिया गया ग़लत जवाब नहीं दिखता, क्योंकि ऐसा जवाब बनाने वाला कोई code path है ही नहीं।
मैन्युफैक्चरिंग के ज़्यादातर AI “copilot” बस एक language model के ऊपर की परत हैं, जिसे आपके डॉक्यूमेंट खिला दिए गए हैं। यह उस AI जैसा नहीं है जो आपके लाइव उपकरणों को पढ़ता है। फ़र्क़ यह है।
“हम वादा करते हैं कि हमारा AI hallucinate नहीं करेगा” — यह एक मार्केटिंग दावा है। एविडेंस कॉन्ट्रैक्ट सिस्टम का एक गुण है। ये चीज़ें इसे सिर्फ़ एक इरादा नहीं, बल्कि लागू होने वाला नियम बनाती हैं:
बात यह नहीं कि हमारा AI “झूठ नहीं बोलता।” बात यह है कि ऐसे code path मौजूद ही नहीं जो उसे झूठ बोलने दें।
एविडेंस कॉन्ट्रैक्ट को परखने का सबसे तेज़ तरीक़ा इसके बारे में पढ़ना नहीं है। अपनी किसी लाइन का program export हमें दें, और हम आपकी मशीन को उसके बारे में सवालों के जवाब देते हुए दिखाएँगे — हर जवाब के साथ उसकी evidence chain जुड़ी होगी।
पायलट बुक करें सेल्स गाइड पाएँ (PDF, अंग्रेज़ी में)क्या PulseMQ, LLM का इस्तेमाल करता है?
हाँ — भाषा समझने और जवाब तैयार करने के लिए। लेकिन language model कभी प्लांट डेटा नहीं गढ़ता। वह जो भी वैल्यू बताता है, वह मौजूदा session में आपके PLC से लाइव लाई जाती है। अगर कोई tag पढ़ा नहीं गया, तो PulseMQ उसका ज़िक्र नहीं करेगा। अगर कोई कंट्रोलर offline है, तो assistant कुछ गढ़ने के बजाय यही बताता है।
मुझे कैसे पता चले कि AI का जवाब hallucinated नहीं है?
PulseMQ के हर जवाब के साथ वे tag होते हैं जिनसे वह बना, वह पल जब उन्हें पढ़ा गया, और सोर्स कंट्रोलर। Alarm सटीक rung से लिंक होते हैं। Cycle drift उस leg से लिंक होता है जिस पर उसे मापा गया। अगर evidence chain नहीं बन सकती, तो जवाब भी नहीं बनता।
अगर PLC offline हो तो क्या होता है?
PulseMQ आपको बताता है कि कंट्रोलर offline है, और लाइव स्थिति पर निर्भर सवालों का जवाब नहीं दे सकता। यह cached वैल्यू या आख़िरी ज्ञात रीडिंग का सहारा नहीं लेगा। ऐसा जानबूझकर है — प्लांट फ़्लोर पर पुराना जवाब, कोई जवाब न होने से भी बुरा है।
“Normal” रेंज कैसे तय होती हैं?
Machine Intelligence™ दसियों हज़ार रन में हर cycle के हर leg पर नज़र रखता है। Normal एक मापी गई रेंज है, अनुमानित नहीं। Drift detection deterministic है: “पिछले 8,400 cycle में shuttle return leg का औसत 4.2s था; इस बार 6.8s लगे।”