थोडक्यात उत्तर: large language model हे पुढचा शब्द वर्तवणारे अतिशय चांगले यंत्र आहे. ते मजकूर tokens च्या रूपात वाचते, त्यातील मर्यादित भाग context window मध्ये धरून ठेवते, आणि सर्वात पटणारा पर्याय निवडत एका वेळी एक token लिहिते. म्हणूनच ते अस्खलित असते आणि म्हणूनच hallucinate ही करते: पटणारे म्हणजे खरे नव्हे. काल रात्री fermenter 7 वरचा CIP spec मध्ये होता का, असे विचारले तर तुमच्या SOP शिवाय ते उद्योगातील सर्वसाधारण मूल्याशी तुलना करेल आणि खात्रीने बोलेल. Retrieval (RAG) द्वारे SOP मधले कलम आणि लॉगच्या ओळी दिल्या तर ते तुमच्याच मानकाविरुद्ध, संदर्भासह उत्तर देऊ शकते. प्लांटमध्ये महत्त्वाचे असलेले बहुतांश याच एका design निर्णयात आहे.

'काल रात्री FV-7 वरचा CIP spec मध्ये होता का?' (उदाहरणार्थ) फक्त मॉडेल प्रश्न + चिकटवलेली लॉग ओळ LLM फक्त सर्वसाधारण प्रशिक्षण 'होय, 78 C वर 1.8% सर्वसाधारण मर्यादेत आहे.' पटणारे, खात्रीचे, पण तुमचे मानक नव्हे RETRIEVAL (RAG) सह retriever SOP 4.2 + FV-7 लॉग ओळी 2.0% NaOH, 80 C, 20 min LLM दिलेल्या मजकुरावरून उत्तर 'नाही. तिन्ही मर्यादांवर SOP 4.2 पेक्षा कमी.' कलम आणि लॉग ओळींचा संदर्भ देते तेच मॉडेल · फरक फक्त त्याच्यासमोर तुम्ही काय ठेवता याचा
मूल्ये उदाहरणादाखल. SOP शिवायचे मॉडेल खोटे बोलत नाही. ते चांगला अंदाज लावत आहे, आणि ते अधिक धोकादायक आहे.

एका fermenter वरच्या काल्पनिक CIP लॉगमधील ही एक ओळ आहे. प्रत्येक brewery, winery आणि distillery अशा हजारो ओळी तयार करते:

02:14 | FV-07 | CAUSTIC STEP START | NaOH 1.8% | SUPPLY 78.0 C
02:31 | FV-07 | CAUSTIC STEP END | DURATION 17 MIN

हे एखाद्या chatbot मध्ये चिकटवा आणि विचारा की clean spec मध्ये होता का. जवळजवळ नक्कीच तुम्हाला खात्रीचे ‘होय’ मिळेल: सुमारे 75 ते 85 अंश C वर 1 ते 2 टक्के caustic हे CIP साठी सर्वसाधारण आहे, आणि 17 मिनिटे ठीक वाटतात. आता समजा तुमचा SOP सांगतो की 80 अंशावर किमान 20 मिनिटे 2.0 टक्के हवे. म्हणजे clean तिन्ही बाबतीत अयशस्वी झाला, आणि chatbot ने तुम्हाला तो पास झाल्याचे सांगितले.

या मालिकेतील पहिल्या पोस्टने generative AI ला शिडीवर जागा दिली. ही पोस्ट त्याला उघडून पाहते, कारण language model कसे काम करते हे एकदा कळले की ते चुकीचे उत्तर गूढ राहत नाही.

Tokens: मॉडेल कसे वाचते

Language model अक्षरे किंवा पूर्ण शब्द वाचत नाही. ते tokens वाचते, म्हणजे मजकुराचे तुकडे, जे बहुतेकदा एक शब्द, शब्दाचा भाग किंवा एखादे चिन्ह असतात. ‘Caustic’ हा कदाचित एक token असेल. ‘NaOH’ दोन किंवा तीन असू शकतात. इंग्रजीसाठी ढोबळ नियम असा की हजार tokens म्हणजे सुमारे 750 शब्द.

Tokens दोन व्यावहारिक कारणांसाठी महत्त्वाचे आहेत. खर्च आणि मर्यादा tokens मध्ये मोजल्या जातात, आणि आकडे विचित्र पद्धतीने tokens मध्ये तुटतात. ‘78.0’ चे कदाचित अनेक तुकडे होतील. Language models अंकगणितात अविश्वसनीय असण्याचे हे एक कारण आहे: ते आकड्याशी काम करत नाहीत, ते त्याच्या मजकुराच्या तुकड्यांशी काम करतात.

Context window: मॉडेलला काय दिसते

Context window म्हणजे मॉडेलला एकाच वेळी दिसणारे सगळे: तुमचा प्रश्न, तुम्ही चिकटवलेले दस्तऐवज, आतापर्यंतचे संभाषण आणि त्याचे स्वतःचे उत्तर. 2026 मध्ये आघाडीची मॉडेल लाखो tokens स्वीकारतात आणि काही तर दहा लाखांच्या पुढे जातात. प्लांटमधले प्रत्येक SOP चिकटवायला हे पुरेसे वाटते.

इतके सोपे नाही. खूप लांब context मध्ये मॉडेलचे लक्ष सगळीकडे सारखे नसते, आणि लांब दस्तऐवजाच्या मधल्या भागातील तपशील सुटणे सोपे असते. आणि context तात्पुरता असतो. संभाषण संपले की मॉडेलला काहीच आठवत नाही. त्याने तुमचा SOP शिकलेला नाही. त्याने तो एकदा वाचला.

पुढच्या token चा अंदाज: मॉडेल कसे लिहिते

मुळात large language model एकच गोष्ट करते: आतापर्यंतचे tokens पाहून पुढे कोणता token येण्याची सर्वाधिक शक्यता आहे हे वर्तवते. मग तो token जोडते आणि पुन्हा तेच करते. एक पूर्ण उत्तर म्हणजे अशा शेकडो अंदाजांची सलग मालिका.

हे अंदाज करायला ते प्रचंड मजकुरावर प्रशिक्षण घेऊन शिकले. त्याचे सर्वसाधारण ज्ञान तिथूनच येते. त्याने CIP बद्दलचे हजारो दस्तऐवज वाचले आहेत, म्हणून त्याला caustic ची सर्वसाधारण मर्यादा माहीत आहे. त्याने तुमचा SOP कधीच वाचलेला नाही, म्हणून तुम्ही दाखवल्याशिवाय त्याला तुमचे मानक कळू शकत नाही.

Hallucination: खात्रीचे चुकीचे उत्तर का येते

हे तुकडे एकत्र ठेवले की hallucination उघड होते. मॉडेल सर्वात पटणारा पुढचा मजकूर तयार करण्यासाठी बनवलेले आहे. खरे उत्तर समोर असेल तेव्हा पटणारे आणि खरे सहसा जुळतात. ते नसेल तेव्हाही मॉडेल काहीतरी पटणारे तयार करतेच, कारण त्याला तेवढेच करता येते. ‘माझ्याकडे ही माहिती नाही’ असे सांगणारा कोणताही अंतर्गत alarm नाही.

म्हणूनच CIP चे उत्तर ‘होय’ आले. प्रशिक्षणात मॉडेलने जे पाहिले त्यानुसार सर्वात पटणारा मजकूर असा होता की 78 अंशावर 1.8 टक्के हा सामान्य clean आहे. त्याने तुमचे मानक तपासले नाही, कारण तपासायला त्याच्याकडे मानकच नव्हते.

Hallucination कमी करता येते, पूर्णपणे काढता येत नाही. मुख्य उपाय अधिक चांगले मॉडेल नाही. मॉडेलला योग्य मजकूर देणे हा आहे.

RAG: मॉडेलला योग्य मजकूर देणे

Retrieval-augmented generation, म्हणजे RAG, हा प्रमाणित उपाय आहे. मॉडेल उत्तर देण्यापूर्वी एक retrieval पायरी तुमचेच दस्तऐवज (SOP, specifications, maintenance manuals, जुने incident reports) शोधते आणि सर्वात संबंधित उतारे प्रश्नासोबत context मध्ये ठेवते. मॉडेलला त्या उताऱ्यांवरूनच उत्तर द्यायला आणि त्यांचा संदर्भ द्यायला सांगितलेले असते.

RAG सह पुन्हा विचारल्यावर प्रणाली SOP कलम 4.2 आणि FV-7 च्या लॉग ओळी आणते. आता मॉडेल उत्तर देते: caustic पायरी strength, तापमान आणि कालावधी तिन्हीत SOP च्या किमान मर्यादेपेक्षा कमी होती, कलम 4.2 पाहा. तेच मॉडेल, वेगळे input, वेगळे उत्तर.

प्लांटमध्ये विश्वासार्ह बनवण्यासाठी दोन सुधारणा लागतात:

  • प्रत्येक गोष्टीचा संदर्भ द्या. प्रत्येक उत्तर कोणत्या दस्तऐवजातून आणि कलमातून आले ते सांगते, त्यामुळे operator SOP उघडून तपासू शकतो.
  • तुलना code ला करू द्या. मॉडेल SOP मधून ‘2.0 टक्के किमान’ वाचू शकते. 1.8 हे 2.0 पेक्षा कमी आहे की नाही हे code च्या एका ओळीचे काम आहे, language model चे नाही. सर्वोत्तम प्रणाली मर्यादा आणि readings काढून घेतात आणि तुलना साध्या software ला करू देतात.

मी याआधी GenAI ने brewery SOP शोधण्यावर एक पोस्ट लिहिली होती. कल्पना बदललेली नाही. फक्त मॉडेल इतकी चांगली झाली आहेत की आता retrieval ची गुणवत्ता हीच कमकुवत कडी आहे.

Fine-tuning: एक वेगळे साधन

Fine-tuning म्हणजे अस्तित्वात असलेल्या मॉडेलला तुमच्याच उदाहरणांवर थोडे अधिक प्रशिक्षण देणे. लोकांना अनेकदा वाटते की मॉडेलला तुमचे SOP शिकवण्याचा हाच मार्ग आहे. त्या कामासाठी ते सहसा चुकीचे साधन असते.

मॉडेलचे वर्तन बदलण्यात fine-tuning चांगले आहे: उत्तरांचे स्वरूप, handover ची भाषा, एखाद्या प्रकारच्या line stop चे वर्गीकरण. बदलणारी तथ्ये साठवण्यात ते वाईट आहे, कारण तथ्ये मॉडेलच्या weights मध्ये संदर्भाशिवाय आणि सहज अद्ययावत करता न येण्याजोगी बसतात. SOP सुधारला की RAG प्रणाली दुसऱ्याच दिवशी नवीन आवृत्ती वाचते. Fine-tuned मॉडेल तुम्ही पुन्हा प्रशिक्षण देईपर्यंत जुनीच आवृत्ती सांगत राहते.

एक उपयुक्त नियम: ज्ञानासाठी RAG, वर्तनासाठी fine-tuning, आणि बहुतेक प्लांटना दुसऱ्याची कधीच गरज पडत नाही.

Multimodal: input मजकूर नसतो तेव्हा

सध्याची अनेक मॉडेल multimodal आहेत: ती मजकुरासोबत प्रतिमा, आणि काही audio सुद्धा स्वीकारतात. प्लांटच्या floor वर यामुळे काही उपयुक्त दारे उघडतात. Operator एखाद्या gauge चा, HMI वरच्या fault screen चा किंवा हाताने लिहिलेल्या batch sheet चा फोटो काढतो आणि मॉडेल तो वाचते. Maintenance technician एखाद्या nameplate चा फोटो काढतो आणि त्याला manual चा योग्य भाग मिळतो.

नियम तेच लागू होतात. Gauge चा फोटो वाचणारे मॉडेल तो चुकीचा वाचू शकते, आणि ती चूक तितक्याच खात्रीने सांगेल. त्याचा वापर नोंद घेण्यासाठी आणि मसुद्यासाठी करा, मग आकडे पडताळा.

हे कुठे मोडते

Retrieval चुकीचा उतारा आणू शकते. Bright beer tanks चा SOP आणि fermenters चा SOP जवळजवळ सारखे असतील तर retriever चुकीचा आणू शकतो. संदर्भामुळेच माणसाला ती चूक पकडता येते.

दस्तऐवज अनेकदा जुने असतात. RAG मॉडेलला तुमच्या दस्तऐवज संग्रहाइतकेच अद्ययावत ठेवते. सुधारणा न केलेला SOP खात्रीने कालबाह्य उत्तरे देतो.

आकडे धोकादायकच राहतात. योग्य मजकूर असूनही मॉडेल एखादा table चुकीचा वाचू शकते किंवा मूल्य round करू शकते. जिथे निर्णय आकड्यावर अवलंबून आहे, तिथे तो आकडा system of record किंवा गणनेतून आला पाहिजे, मॉडेलच्या गद्यातून नव्हे.

चुकीचे असताना मॉडेल वेगळे वाटत नाही. बरोबर आणि रचलेल्या उत्तराच्या स्वरात काहीच फरक नसतो. लोकांना संदर्भ तपासायला शिकवणे हे प्रणाली बांधण्याइतकेच महत्त्वाचे आहे.

निष्कर्ष

Language model एका वेळी एक token असा पटणारा मजकूर वर्तवते. त्याला सर्वसाधारण काय असते ते माहीत असते, आणि तुम्ही दाखवल्याशिवाय तुमच्या प्लांटबद्दल काहीच नाही. त्यामुळे ते अस्खलित, उपयुक्त आणि खात्रीच्या चुकांना प्रवण असते. तुमचे स्वतःचे SOP आणि लॉग मॉडेलसमोर ठेवून आणि त्याला त्यांचा संदर्भ द्यायला लावून RAG ही दरी बहुतांश भरून काढते. Fine-tuning वर्तन बदलते, ज्ञान नाही. आणि उत्तर महत्त्वाचा आकडा असेल तेव्हा तो code ला तपासू द्या.

पुढे: agentic AI म्हणजे काय, जेव्हा मॉडेल प्रश्नांची उत्तरे देणे थांबवून साधने वापरायला लागते. या मूलभूत गोष्टींचा distillery च्या दृष्टीने विचार What Is Generative AI? The Difference That Matters for Distillers मध्ये पाहा. हीच कल्पना एका winery च्या data assistant चा पाया कशी आहे हे Cellar Ledger मालिकेत आहे.

वारंवार विचारले जाणारे प्रश्न

सोप्या भाषेत large language model म्हणजे काय? Large language model हे एक neural network आहे, ज्याला प्रचंड मजकुरावर प्रशिक्षण देऊन पुढचा मजकूर, एका वेळी एक token, वर्तवायला शिकवलेले असते. त्याने इतकी भाषा पाहिलेली असल्याने ते लिहू शकते, सारांश करू शकते, भाषांतर करू शकते आणि प्रश्नांची उत्तरे देऊ शकते. तुम्ही मार्ग दिल्याशिवाय ते तथ्ये शोधत नाही, आणि आपण जे लिहितो ते खरे आहे की नाही याची त्याला स्वतःहून जाणीव नसते.

LLM hallucinate का करतात? कारण ते सर्वात पटणारे पुढचे शब्द तयार करण्यासाठी बनवलेले असतात, बरोबर शब्द नव्हे. उत्तर दिलेल्या मजकुरात नसेल तर ते ती पोकळी बरोबर वाटणाऱ्या गोष्टीने भरतात. तुमचा SOP न देता CIP caustic concentration बद्दल विचारले, तर तुम्हाला उद्योगातील एक सर्वसाधारण मूल्य आत्मविश्वासाने मिळेल, जे कदाचित तुमचे नसेल.

प्लांटने RAG वापरावे की fine-tuning? SOP, specifications आणि maintenance manuals सारख्या दस्तऐवजांत असलेल्या तथ्यांसाठी retrieval (RAG) वापरा: प्रणाली संबंधित उतारा शोधते आणि प्रश्नासोबत तो मॉडेलला देते, त्यामुळे उत्तरे तुमच्याच दस्तऐवजांचा संदर्भ देतात आणि दस्तऐवज बदलले की उत्तरेही बदलतात. Fine-tuning मॉडेलची शैली बदलते किंवा त्याला एखाद्या कामाचे स्वरूप शिकवते. बदलणारी तथ्ये साठवण्याचा तो वाईट मार्ग आहे.