संक्षिप्त उत्तर: still-house copilot बनाने लायक है अगर वह वह पढ़ना-लिखना करे जो शिफ़्ट को खा जाता है, और कुछ नहीं। उसे नियंत्रित SOPs और बरसों के रन लॉग की ओर मोड़िए, उससे इस्तेमाल किए गए पैराग्राफ़ का हवाला दिलवाइए, historian से लाइव मानों के लिए उसे सिर्फ़ पढ़ने वाले टूल दीजिए, और शिफ़्ट के अंत में उससे handover का ड्राफ़्ट बनवाइए। उसे लिखने वाला कोई टूल मत दीजिए। setpoints, interlocks और cuts ऑपरेटर और control system के पास रहते हैं। still पर सबसे सुरक्षित टूल वह है जो मॉडल को कभी दिया ही नहीं गया।
सुबह के छह बजे हैं, शिफ़्ट बदल रही है। रात वाले ऑपरेटर के पास एक पन्ने के नोट्स हैं, एक रन जो रात दो बजे के आसपास थोड़ा धीमा चला, और एक steam trap जो सीटी मार रहा था। दिन वाले ऑपरेटर को पाँच मिनट का handover मिलता है, जिसका आधा यह ढूँढने में जाता है कि धीमा रन कौन सा रन नंबर था। उसी सुबह बाद में एक ट्रेनी पूछता है कि CIP के बाद feints receiver changeover कैसे होता है, और जवाब एक ऐसी SOP में है जिसे shared drive पर कोई ढूँढ नहीं पाता।
इनमें से कोई भी control की समस्या नहीं है। यह पढ़ने-लिखने की समस्या है, और पढ़ना-लिखना ठीक वही है जिसमें large language models सचमुच अच्छे हैं। यह पोस्ट उस काम के लिए एक copilot के बारे में है, और उस एक चीज़ के बारे में जो वह कभी नहीं कर पाना चाहिए।
copilot किसलिए है
चार काम, मूल्य के मोटे क्रम में:
1. प्रक्रिया के सवाल, स्रोत से जवाब। नियंत्रित SOPs पर retrieval-augmented generation (RAG): ऑपरेटर सादे शब्दों में पूछता है, copilot संबंधित पैराग्राफ़ ढूँढता है, जवाब देता है और दस्तावेज़ संख्या व संस्करण के साथ उसे उद्धृत करता है। अगर उसे स्रोत नहीं मिलता, तो वह अपनी ओर से कुछ गढ़ने की बजाय यही कहता है।
2. “क्या ऐसा पहले हुआ है?” बरसों के रन लॉग और शिफ़्ट नोट्स हर अजीब रन और उसे ठीक करने वाली चीज़ का रिकॉर्ड हैं। उन पर semantic search “boiler trip के बाद धीमा रन, strength जल्दी गिर रही” को मिलते-जुलते पिछले रनों की सूची में बदल देता है, साथ में यह कि ऑपरेटर ने उस समय क्या लिखा था। अक्सर यह सूची की सबसे काम की चीज़ होती है, और यह दबा हुआ टेक्स्ट है जिसे आज कोई नहीं पढ़ता।
3. शिफ़्ट handover। शिफ़्ट के अंत में copilot historian से रन, soft sensor पोस्ट वाले band फ़्लैग, ऑपरेटर के नोट्स और कोई भी खुले वर्क ऑर्डर उठाता है, और एक पन्ने का handover ड्राफ़्ट करता है। ऑपरेटर उसे संपादित करता है और हस्ताक्षर करता है। दिन की शिफ़्ट को एक सुसंगत सार मिलता है, बजाय उसके जो रात की शिफ़्ट 5:45 पर जितनी ताकत बची थी उतने में लिख पाई।
4. कागज़ी काम का ड्राफ़्ट। deviation नोट, near-miss रिपोर्ट और maintenance अनुरोध एक ऐसे ड्राफ़्ट से शुरू होते हैं जिसमें रन नंबर, timestamps और मान पहले से जुड़े हैं।
टूल्स: डिज़ाइन से ही सिर्फ़ पढ़ने वाले
लाइव प्लांट के बारे में बात करने के लिए copilot को डेटा चाहिए, और 2026 में इसे देने का साफ़ तरीका है historian के ऊपर बैठे टूल्स का एक छोटा सेट (आमतौर पर MCP के ज़रिए):
get_value(tag) -> current value, unit, timestamp, quality
get_trend(tag, from, to) -> time series, downsampled
get_run_summary(still, run_id) -> charge, cuts, fractions, alcohol balance
search_run_logs(query, still) -> matching notes with run ids
हर टूल पढ़ता है। उनमें से कोई नहीं लिखता। कोई set_setpoint नहीं, कोई acknowledge_alarm नहीं, कोई open_valve नहीं। यह प्रॉम्प्ट में लिखा कोई दिशानिर्देश नहीं है, जिससे कोई चालाक प्रॉम्प्ट बातों में उलझाकर निकल सके। यह क्षमता का न होना है। मॉडल ऐसा टूल नहीं बुला सकता जो मौजूद ही नहीं।
इसी कारण historian का कनेक्शन भी network और account स्तर पर सिर्फ़ पढ़ने वाला होना चाहिए। control system की अपनी सुरक्षा परत, अपने interlocks और अपने इंजीनियर हैं, और language model का वहाँ आसपास भी कोई काम नहीं।
जवाबों को भरोसेमंद बनाना
जो copilot आत्मविश्वास से बोलता है और किसी प्रक्रिया के बारे में गलत है, वह copilot न होने से बुरा है। कुछ नियम ज़्यादातर काम कर देते हैं:
- index में सिर्फ़ मौजूदा, नियंत्रित दस्तावेज़। जब कोई SOP संशोधित होती है, तो पुराना संस्करण उसी दिन retrieval से बाहर होता है। index में रद्द हो चुकी प्रक्रियाएँ सबसे आम तरीका हैं जिससे ये सिस्टम आत्मविश्वास से गलत जवाब देते हैं।
- हवाला दो या मना करो। प्रक्रिया वाला हर जवाब पैराग्राफ़ उद्धृत करता है और दस्तावेज़ का लिंक देता है। स्रोत नहीं, तो जवाब नहीं।
- संख्याएँ टूल से, मॉडल से कभी नहीं। अगर ऑपरेटर पूछे कि condenser outlet का तापमान क्या है, तो copilot
get_valueबुलाता है और जो लौटा उसे timestamp के साथ बताता है। वह अनुमान नहीं लगाता। - एक असली eval सेट। ऑपरेटरों के सचमुच पूछे पचास सवाल इकट्ठे कीजिए, जिनके जवाब शिफ़्ट लीडर ने जाँचे हों, और हर बार मॉडल, प्रॉम्प्ट या दस्तावेज़ index बदलने पर उन्हें चलाइए। स्कोर कीजिए। “क्या यह काफ़ी अच्छा है?” का यही एक ईमानदार जवाब है।
यह कहाँ टूटता है
सुरक्षा-महत्वपूर्ण सवालों को सार नहीं, स्रोत चाहिए। isolation, confined space, hot work या ethanol vapour से जुड़ी किसी भी चीज़ में copilot का काम सही SOP खोलना है, उसे अपने शब्दों में कहना नहीं। इसे डिज़ाइन और ट्रेनिंग दोनों में पक्का नियम बनाइए।
रन लॉग गड़बड़ हैं और कभी-कभी गलत। semantic search खुशी-खुशी 2021 का एक नोट ढूँढ लेगा जो कहता है “steam बढ़ाकर ठीक किया”, और हो सकता है वह गलत इलाज था। पुराने नोट्स सुराग हैं, निर्देश नहीं।
handover ड्राफ़्ट समस्याओं को चिकना कर सकते हैं। एक साफ़-सुथरा सार बेचैन रात को भी सामान्य जैसा बना सकता है। जिस ऑपरेटर ने शिफ़्ट जी है, उसे इसे संपादित करके हस्ताक्षर करना चाहिए, और ड्राफ़्ट में band फ़्लैग और खुले मुद्दे सार में दबाने की बजाय साफ़-साफ़ सूचीबद्ध होने चाहिए।
समय के साथ लोग इस पर ज़्यादा भरोसा करेंगे। यह जितना बेहतर होगा, उतना कम कोई जाँचेगा। यही तर्क है कि eval सेट सिर्फ़ लॉन्च पर नहीं, हमेशा चलता रहे।
निचोड़
still house की संचालन समस्या के भीतर एक पढ़ने-लिखने की समस्या छिपी है: ऐसी प्रक्रियाएँ जिन्हें कोई ढूँढ नहीं पाता, ऐसे रन लॉग जिन्हें कोई नहीं पढ़ता, और आधी नींद में लिखे handovers। language model ठीक इसी में अच्छा है। उसे नियंत्रित दस्तावेज़, लॉग और सिर्फ़ पढ़ने वाले टूल दीजिए, उससे हवाला दिलवाइए, असली सवालों से परखिए, और वह शिफ़्ट का असली समय बचाएगा। उसे लिखने वाला कुछ मत दीजिए। still ऑपरेटर चलाता है। कागज़ी काम copilot चलाता है।
डिस्टिलरी में Anthropic टूल्स के बड़े नज़रिए के लिए देखें डिस्टिलरियों के लिए Claude AI और Claude Code। प्रस्ताव-दो-कभी-लिखो-मत वाला यही नियम वाइन सीरीज़ में सेलर के event-sourcing में भी आता है। इस सीरीज़ में आगे: डेटा इंजीनियरिंग के रूप में cask इन्वेंटरी। पूरी सूची The Still and the Model सीरीज़ पेज पर है।
अक्सर पूछे जाने वाले सवाल
एक LLM copilot डिस्टिलरी ऑपरेटर के लिए क्या कर सकता है? यह नियंत्रित SOPs से पैराग्राफ़ के हवाले के साथ प्रक्रिया के सवालों के जवाब दे सकता है, मिलती-जुलती स्थितियों के लिए पिछले रन लॉग खोज सकता है, सिर्फ़ पढ़ने वाले टूल्स से लाइव process मान पढ़ सकता है, और historian व ऑपरेटर के नोट्स से शिफ़्ट handover का ड्राफ़्ट बना सकता है। यह ढूँढने और लिखने में समय बचाता है, जो शिफ़्ट का बड़ा हिस्सा है।
क्या AI copilot को still के setpoints बदलने की अनुमति होनी चाहिए? नहीं। copilot के पास लिखने वाला कोई टूल होना ही नहीं चाहिए। setpoints, interlocks और cut के फ़ैसले ऑपरेटर और control system के पास रहते हैं। सबसे सरल सुरक्षा डिज़ाइन वह टूल है जो मौजूद ही नहीं: अगर मॉडल set_setpoint बुला ही नहीं सकता, तो कोई प्रॉम्प्ट उससे यह नहीं करवा सकता।
still-house copilot को प्रक्रिया के गलत जवाब देने से कैसे रोकें? retrieval को सिर्फ़ SOPs के मौजूदा नियंत्रित संस्करणों की ओर रखें, मॉडल से इस्तेमाल किया गया पैराग्राफ़ उद्धृत और लिंक करवाएँ, स्रोत न मिलने पर मना करवाएँ, और हर बदलाव से पहले और बाद में उसे जाँचे हुए जवाबों वाले असली ऑपरेटर सवालों के सेट पर परखें। सुरक्षा से जुड़ी किसी भी चीज़ पर कदम उठाने से पहले ऑपरेटर स्रोत पढ़ता है।