थोडक्यात उत्तर: agent म्हणजे साधने आणि चक्र असलेले language model. तुम्ही त्याला एक ध्येय देता, उदाहरणार्थ ‘काल रात्री line 2 ची 40 मिनिटे का गेली ते शोध’. ते एक पाऊल ठरवते, एक साधन वापरते (line stop log ची query), निकाल पाहते, पुढचे पाऊल ठरवते (त्या asset साठी maintenance प्रणाली तपासणे) आणि उत्तर मिळेपर्यंत किंवा माणसाची गरज पडेपर्यंत पुढे जात राहते. MCP हा मॉडेलना त्या साधनांशी जोडणारा प्रमाणित plug आहे. Memory मुळे ते पावलांदरम्यान आणि sessions दरम्यान संदर्भ सोबत ठेवते. महत्त्वाचा design प्रश्न agent किती हुशार आहे हा नाही, तर ते एकट्याने किती करू शकते हा आहे. मी L0 ते L4 अशी पाच पातळ्यांची शिडी वापरतो, आणि प्लांटच्या floor वर बहुतेक agents नी L1 किंवा L2 वर राहावे.

AGENT कसे काम करते, आणि ते किती करू शकते ध्येय plan act observe MCP द्वारे साधने line stop log maintenance प्रणाली SOP संग्रह उत्तर मिळेपर्यंत चक्र, नाहीतर माणसाला विचारा स्वायत्ततेची शिडी L4 एकट्याने कृती, माणूस देखरेख करतो L3 कडक मर्यादेत कृती, माणूस नकार देऊ शकतो L2 कृतींचा मसुदा, माणूस मंजूर करतो L1 data वाचते आणि समजावते L0 agent नाही, माणसे करतात प्लांट floor चा मूळ पर्याय: L1 आणि L2 PLC आणि SCADA मध्ये लिहिणे या शिडीवर नाही · AGENTS कधीच PROCESS CONTROL ला हात लावत नाहीत
चक्रामुळे ते agent बनते. शिडीमुळे ते प्लांटमध्ये चालवणे सुरक्षित होते.

Line 2 वरच्या रात्रपाळीची 40 मिनिटे गेली. सकाळच्या बैठकीत कोणीतरी विचारतो, का? सहसा उत्तर शोधायला अर्धा तास लागतो: line stop log उघडा, लांब stops शोधा, maintenance प्रणालीत तो asset पाहा, तो आधी बिघडला होता का ते तपासा, shift notes वाचा, मग सगळे जुळवा.

Chatbot हे करू शकत नाही. तुम्ही जे चिकटवता तेवढ्यावरूनच तो उत्तर देऊ शकतो. Agent करू शकते, कारण ते प्रत्येक तुकडा स्वतः जाऊन आणू शकते. मालिकेतील ही तिसरी पोस्ट ते कसे ते समजावते. मागच्या पोस्टमध्ये language model म्हणजे काय ते पाहिले. Agent म्हणजे तेच मॉडेल, दोन गोष्टींची भर घालून: साधने आणि चक्र.

Tools: agent कुठपर्यंत पोहोचू शकते

Tool म्हणजे असे function जे वापरण्याची मॉडेलला परवानगी आहे. त्याला एक नाव, साध्या भाषेतील वर्णन, ठरलेले inputs आणि ठरलेला output असतो. प्लांटसाठी उपयुक्त साधने अशी असू शकतात:

  • get_line_stops(line, start, end) प्रत्येक stop कालावधी, fault code आणि asset सह देते
  • get_asset_history(asset_id) maintenance प्रणालीतून जुने work orders आणि बिघाड देते
  • search_sop(query) संबंधित SOP उतारे कलम क्रमांकांसह देते
  • get_shift_notes(line, shift) operators नी काय लिहिले ते देते

मॉडेल maintenance database वर थेट SQL कधीच चालवत नाही. ते नावाने आणि काही inputs सह साधन मागते, साधे software एक तपासलेली query चालवते आणि निकाल मजकुराच्या रूपात परत येतो. ही विभागणी agent ची सर्वात महत्त्वाची सुरक्षा बाब आहे. काय शोधायचे हे मॉडेल ठरवते. कसे, आणि कशाला परवानगी आहे, हे code ठरवतो.

चक्र: plan, act, observe

साधने उपलब्ध असली की मॉडेल एका चक्रात काम करते:

  1. Plan. ध्येय आणि आतापर्यंत माहीत असलेल्या गोष्टी पाहून पुढचे पाऊल ठरवा. ‘आधी, काल रात्री line 2 वरचे लांब stops शोधा.’
  2. Act. साधन वापरा. get_line_stops("L2", "22:00", "06:00").
  3. Observe. निकाल वाचा. सहा stops, त्यातले चार labeller glue unit चे, एकूण 31 मिनिटे.
  4. पुन्हा. नव्या माहितीसह पुढचे पाऊल ठरवा. ‘Glue unit चा maintenance इतिहास तपासा.’ आणि असेच पुढे.

Agent कडे उत्तर द्यायला पुरेसे झाले की, किंवा एकट्याने ठरवू नये अशा गोष्टीपर्यंत पोहोचून ते माणसाकडे सोपवते तेव्हा, चक्र संपते. Line 2 च्या प्रश्नासाठी चांगले agent असे संपवू शकेल: 40 पैकी बहुतांश मिनिटे labeller glue unit ची होती, एकाच fault code चे चार stops; हाच fault मागच्या महिन्यातील दोन work orders मध्ये आहे; shift notes मध्ये glue तापमानाचा उल्लेख आहे; glue unit start-up वरचे SOP कलम 6.3 आहे.

ही जादू नाही. अर्ध्या तासाचे हाताने करायचे काम एका मिनिटात, प्रत्येक पाऊल दिसेल असे.

MCP: प्रमाणित plug

अलीकडेपर्यंत मॉडेलला साधनाशी जोडायचे म्हणजे प्रत्येक मॉडेल आणि प्रत्येक प्रणालीसाठी वेगळा code लिहिणे. Model Context Protocol (MCP), हे Anthropic ने 2024 च्या अखेरीस आणलेले आणि तेव्हापासून व्यापकपणे स्वीकारलेले खुले मानक, ही अडचण सोडवते. तुम्ही, उदाहरणार्थ, maintenance प्रणालीसाठी एकदाच MCP server बांधता. ते आपली साधने प्रमाणित पद्धतीने वर्णन करते. मग MCP बोलणारा कोणताही assistant ती वापरू शकतो.

प्लांटसाठी याचा व्यावहारिक फायदा म्हणजे मालकी. Maintenance प्रणालीच्या MCP server ची मालकी maintenance टीमकडे राहू शकते आणि ते कोणती साधने उघडी ठेवायची हे नेमके ठरवू शकतात. LIMS च्या server ची मालकी quality टीमकडे राहू शकते. एखादे साधन server वर नसेल तर वर कोणतेही मॉडेल असो, कोणताही agent ते वापरू शकत नाही.

Memory: agent काय सोबत ठेवते

Language models ना दोन संभाषणांदरम्यान काहीच आठवत नाही. Agents दोन प्रकारे memory जोडतात:

  • Working memory म्हणजे काम चालू असताना context window: ध्येय, प्रत्येक tool call आणि प्रत्येक निकाल. यामुळेच चौथ्या पावलावर agent ला पहिल्या पावलावर काय सापडले ते माहीत असते.
  • Long-term memory म्हणजे मॉडेलबाहेर साठवलेले आणि नंतर परत वाचले जाणारे काहीही: जुन्या तपासांच्या नोंदी, माहीत असलेल्या वारंवार येणाऱ्या faults ची यादी, वापरकर्त्याच्या आवडी.

Long-term memory प्रभावी आहे आणि तिला इतर कोणत्याही record इतकीच काळजी लागते. मागच्या महिन्यातला चुकीचा निष्कर्ष agent ला ‘आठवत’ असेल तर ते तो आत्मविश्वासाने पुन्हा वापरेल. साठवलेल्या memory ला दस्तऐवजासारखे वागवा: तारीख असलेली, स्रोत असलेली आणि दुरुस्तीसाठी खुली.

स्वायत्ततेच्या पाच पातळ्या

प्लांटमध्ये सर्वात महत्त्वाचा प्रश्न ‘agent किती हुशार आहे?’ हा नाही. ‘माणसाशिवाय ते काय करू शकते?’ हा आहे. मी एक सोपी पाच पातळ्यांची शिडी वापरतो:

  • L0: agent नाही. माणसे काम हाताने करतात.
  • L1: वाचते आणि समजावते. Agent data ची query करू शकते आणि उत्तर किंवा सारांश लिहू शकते. ते काहीही बदलत नाही.
  • L2: मसुदा करते, माणूस मंजूर करतो. Agent एखादी कृती तयार करते, जसे work order, changeover योजना किंवा email, आणि काहीही घडण्यापूर्वी माणूस ती मंजूर करतो.
  • L3: कडक मर्यादेत कृती करते, माणूस नकार देऊ शकतो. Agent कमी धोक्याच्या कृती स्वतः, ठरलेल्या मर्यादेत, log आणि उलटवण्याच्या मार्गासह करते. ठरलेल्या budget मध्ये एखादी consumable वस्तू पुन्हा मागवणे हे त्याचे उदाहरण.
  • L4: एकट्याने कृती करते, माणूस देखरेख करतो. Agent एखादे काम सुरुवातीपासून शेवटपर्यंत चालवते आणि माणसे नंतर त्याचे काम तपासतात.

Beverage प्लांटच्या floor वर बहुतेक agents नी बराच काळ L1 आणि L2 वरच राहावे. वाचणे आणि मसुदा करणे यातून बहुतांश मूल्य, धोक्याच्या अगदी थोड्या भागात मिळते. L3 फक्त अरुंद, उलटवता येण्याजोग्या, कमी किंमतीच्या कृतींसाठी आहे. आणि एक वर्ग शिडीच्या पूर्णपणे बाहेर आहे: agent ने PLC, SCADA प्रणाली किंवा process setpoint मध्ये काहीही लिहू नये. Process control engineered control प्रणाली आणि माणसांकडेच राहतो. पोस्ट 7 या guardrails चा सविस्तर विचार करते.

Human in the loop, नीट केलेले

‘Human in the loop’ म्हणणे सोपे आहे आणि वाईट प्रकारे करणेही सोपे आहे. Shift च्या शेवटी थकलेला planner चाळीस मसुद्यांवर ‘approve’ दाबतो, ही देखरेख नाही. तो नुसता शिक्का आहे.

काही सवयी ते खरे बनवतात:

  • प्रत्येक मसुद्यासोबत पुरावा दाखवा: कोणते tool calls, कोणता data, कोणते SOP कलम.
  • मसुदे कमी आणि नेमके ठेवा. दहा सुमार work orders चा मसुदा करणाऱ्या agent पेक्षा एक चांगला work order करणारे agent अधिक उपयोगी.
  • माणसे agent चे मसुदे किती वेळा बदलतात किंवा नाकारतात याचा मागोवा घ्या. बदलांचे प्रमाण कमी होणे चांगले. बदल शून्य असतील तर सहसा त्याचा अर्थ कोणीच वाचत नाही.

हे कुठे मोडते

Agents चक्रात अडकू शकतात किंवा भरकटू शकतात. नीट व्याप्ती न ठरवलेले agent पुन्हा पुन्हा साधने वापरू शकते किंवा असंबद्ध धागा पकडू शकते. पावले, वेळ आणि खर्च यांवर मर्यादा घाला, आणि ‘मला माणूस हवा’ हे स्वीकारार्ह उत्तर बनवा.

साधनांच्या निकालात सूचना दडलेल्या असू शकतात. Agent logs, notes आणि दस्तऐवजांतील मजकूर वाचते. त्या मजकुरात ‘आधीच्या सूचना दुर्लक्षित कर’ असे असेल तर निष्काळजी रचना ते पाळू शकते. याला prompt injection म्हणतात. साधन जे काही परत देते ते data म्हणून वागवा, आदेश म्हणून कधीच नाही, आणि लिहिणारी साधने मंजुरीच्या मागे ठेवा.

साखळी data इतकीच चांगली असते. ‘other’ fault codes ने भरलेला line stop log वाचणारे agent ‘other’ चा आत्मविश्वासपूर्ण सारांश देईल. Agents चांगला data वापरायला जलद बनवतात. ते वाईट data चांगला करत नाहीत.

स्वायत्तता हळूहळू वाढत जाते. Agent L2 वर चांगले चालू लागले की मंजुरी वगळण्याचा दबाव येतो. पातळी जाणीवपूर्वक, चुकीच्या किंमतीनुसार ठरवा, आणि ती लिहून ठेवा.

निष्कर्ष

Agent म्हणजे साधने आणि चक्र असलेले language model. ते plan करते, साधनाद्वारे act करते, निकाल observe करते आणि पुन्हा करते, ज्यामुळे supervisor च्या सकाळचा अर्धा तास खाणारे शोधणे आणि पडताळणे ते करू शकते. MCP हा त्याला प्लांट प्रणालींशी जोडण्याचा प्रमाणित मार्ग आहे, ज्यात प्रत्येक प्रणालीचा मालक कोणती साधने असतील हे ठरवतो. Memory मुळे ते पावलांदरम्यान आणि sessions दरम्यान उपयोगी राहते. स्वायत्तता हा निवडीचा प्रश्न आहे, आणि beverage प्लांटमध्ये समजूतदार मूळ पर्याय L1 आणि L2 आहे: वाचा, समजावा आणि मसुदा करा, माणूस मंजूर करतो आणि process control आवाक्याबाहेर.

पुढे: data लोकांसाठी operational excellence च्या मूलभूत गोष्टी, कारण agent योग्य नुकसानांचा पाठलाग करत असेल तरच उपयोगी आहे. Winery recall साठी MCP साधनांचे सविस्तर उदाहरण Lot Genealogy as a Graph मध्ये आहे. संपूर्ण यादी मालिकेच्या पानावर आहे.

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

Chatbot आणि AI agent यांत काय फरक आहे? Chatbot एका संदेशाला त्याच्याकडे आधीच असलेल्या माहितीवरून एक उत्तर देतो. Agent ला एक ध्येय आणि साधनांचा संच दिला जातो, आणि मग ते एका चक्रात काम करते: एक पाऊल ठरवते, database query सारखे साधन वापरते, निकाल पाहते आणि पुढचे पाऊल ठरवते, जोपर्यंत उत्तर मिळत नाही किंवा माणसाची गरज पडत नाही. मॉडेल त्याच प्रकारचे असते; साधने आणि चक्र त्याला agent बनवतात.

Agentic AI मध्ये MCP म्हणजे काय? MCP, म्हणजे Model Context Protocol, हे language models ना साधने आणि data sources शी जोडण्याचे एक खुले मानक आहे. प्रत्येक मॉडेल आणि प्रत्येक प्रणालीसाठी वेगळे integration लिहिण्याऐवजी तुम्ही, उदाहरणार्थ, तुमच्या maintenance प्रणालीसाठी एकदाच MCP server बांधता, आणि MCP वापरू शकणारा कोणताही assistant त्याची साधने वापरू शकतो. प्रत्येक साधन काय करते, कोणते inputs घेते आणि काय परत देते, हे ते सांगते.

Beverage प्लांटमध्ये AI agent ला किती स्वायत्तता असावी? स्वायत्तता चुकीच्या किंमतीशी जुळवा. Data वाचणे आणि मसुदा करणे कमी धोक्याचे आहे, म्हणून agents ते मोकळेपणाने करू शकतात. Record बदलणारी कोणतीही गोष्ट agent ने सुचवावी आणि माणसाने मंजूर करावी. Setpoint किंवा PLC सारख्या process control ला स्पर्श करणारी कोणतीही गोष्ट agent च्या आवाक्याबाहेरच ठेवावी.