एका छोट्याशा PDF समस्येने लोक AI वर किती विश्वास ठेवू शकतात याची उपयुक्त चाचणी घेतली

आठवड्यातील अधिक जमिनीवरचे AI किस्से एखाद्या उत्पादन लाँच किंवा बेंचमार्क चार्टमधून आले नाहीत. ते घरगुती workflow समस्येतून आले. ZDNET साठी 5 जूनच्या एका अहवालात, डेव्हिड गेवर्‍त्झ यांनी सांगितले की त्यांनी ChatGPT ला एखादा दस्तऐवज थेट बदलायला न सांगता, ते काम ठराविक पद्धतीने करणारी command-line Python script लिहायला लावली. लक्ष्य होते पिवळ्या कागदावर छापलेले, स्कॅन केलेले choir booklet. पानांचा पिवळा background काढून टाकणे, जेणेकरून ती अधिक स्पष्टपणे पुन्हा छापता येतील आणि music software मध्ये अधिक प्रभावीपणे वापरता येतील, हे उद्दिष्ट होते.

ही कथा लक्षवेधी बनवणारी गोष्ट PDF स्वच्छ करणे स्वतः नाही. तर समाधानाकडे नेणारा तर्क आहे. ChatGPT-निर्मित PDF वर थेट प्रयोग काम करत होते, पण त्यांनी विश्वासार्हतेचा प्रश्न निर्माण केला. जर एखाद्या generative model ने sheet music ला हात लावला, तर ते नोट्स, lyrics किंवा layout सूक्ष्मपणे बदलू शकते का? साध्या मजकुरासाठी तो धोका कदाचित सहन करण्याजोगा असेल. संगीत सरावासाठी नाही.

म्हणून model ला संपादक बनवण्याऐवजी, कुटुंबाने त्याला toolmaker बनवले.

जनरेटिव्ह आउटपुटमधून ठराविक workflow कडे

हा बदल प्रत्यक्ष परिस्थितींमध्ये AI सर्वाधिक परिणामकारकपणे कसा वापरला जाऊ शकतो, याबद्दलचा व्यापक धडा पकडतो. जनरेटिव्ह प्रणाली शक्तिशाली आहेत, पण त्या non-deterministic देखील आहेत, म्हणजे त्यांच्या output मध्ये बदल होऊ शकतो आणि त्यांनी कधीच अभिप्रेत नसलेले बदल घडवू शकतात. स्रोताशी निष्ठा महत्त्वाची असताना, ही अनिश्चितता विश्वासाचा अडथळा बनते.

गेवर्‍त्झ ही तफावत स्पष्टपणे मांडतात. ChatGPT ने थेट केलेल्या PDF रूपांतरणांनी परिणामी फाइल्समध्ये सूक्ष्म बदल केले, ज्यामुळे त्यांची पत्नी त्यांवर सराव करण्याबद्दल साशंक झाली, असे ते सांगतात. तिला असा process हवा होता, जो फक्त background बदलेल आणि संगीताची सामग्री जशीच्या तशी ठेवेल.

पर्याय असा होता की ChatGPT कडून विशिष्ट रूपांतरण करणारे software लिहून घ्यायचे. एकदा तयार झाल्यावर, script मध्ये कोड बदलला नाही तोपर्यंत ती दरवेळी सारखीच वागते. त्यामुळे काम probabilistic generation मधून procedural execution कडे जाते. अनेक व्यावहारिक क्षेत्रांत हाच “interesting demo” आणि “usable tool” यांच्यातला फरक असतो.

तत्काळ उपयोग साधा होता, आणि तेच महत्त्वाचे

स्कॅन केलेली choir पृष्ठे पिवळ्या stock वर छापलेली होती. ती तशीच पुन्हा छापली असती तर खूप रंगीत शाई लागली असती किंवा black-and-white output मध्ये राखाडी background उरला असता. ही पृष्ठे PlayScore 2 सोबतही काम करायला हवी होती, जे एक music-reading app आहे, त्यामुळे दृश्य स्पष्टता मानव आणि यंत्र दोघांसाठीही महत्त्वाची होती.

सुरुवातीला Photoshop विचारात घेतले गेले, पण लेखानुसार प्रत्येक image साठी वेगवेगळ्या slider adjustments लागल्यामुळे manual प्रक्रिया खूपच किचकट होती. हे AI-संबंधित आणखी एक ओळखीचे pattern आहे. पारंपरिक software समस्या सोडवू शकते, पण नियमित वापरासाठी श्रमखर्च खूप जास्त असतो. AI योग्यरीत्या वापरले तर, नेमक्या त्या कामासाठी custom utility तयार करून setup चा भार कमी करू शकतो.

जे तयार झाले ते आकर्षक consumer application नव्हते. ते लहान उद्देशाचे command-line Python tool होते. पण यामुळेच उदाहरण महत्त्वाचे ठरते. AI च्या प्रत्यक्ष आर्थिक मूल्याचा मोठा भाग अशा अनालंकारी, अतिशय विशिष्ट software मधून येऊ शकतो, जे काल अस्तित्वात नव्हते, कारण ते लिहायला त्या कामापेक्षा जास्त वेळ लागला असता.

विश्वासाचे मॉडेल बदलत आहे

AI बद्दलच्या कथा सहसा मॉडेल थेट काय करू शकतात यावर लक्ष केंद्रित करतात: लिहिणे, सारांश करणे, रेखाटणे, code लिहिणे किंवा files स्वतः हाताळणे. हे प्रकरण वेगळ्या विश्वास मॉडेलकडे निर्देश करते. वापरकर्ते AI ला पद्धत सुचवू देण्यात किंवा code तयार करू देण्यात सहज असू शकतात, पण मौल्यवान स्रोत सामग्रीच्या अंतिम रूपांतरणासाठी ते पारदर्शक, पुन्हा करता येणारे tool प्राधान्याने निवडतील.

हा फरक enterprise साठी जितका महत्त्वाचा आहे, तितकाच घरांसाठीही आहे. कायदेशीर, वैद्यकीय, आर्थिक आणि अभिलेखीय संदर्भांत प्रश्न हा नाही की AI काम करू शकते का. प्रश्न असा आहे की प्रणाली ते ट्रेसबिलिटीसह आणि पुरेशा खात्रीने करू शकते का, जेणेकरून कुठेही अनधिकृत बदल समाविष्ट झाले नाहीत याची खात्री राहील.

त्याचा परिणाम असा की सर्वात व्यावहारिक AI workflow अनेकदा दोन टप्प्यांचा असू शकतो. प्रथम, software creation साठी model ला accelerator म्हणून वापरा. नंतर, तयार झालेली deterministic प्रक्रिया मूळ files वर चालवा. त्यामुळे code तपासण्याची किंवा output पडताळण्याची गरज संपत नाही, पण अनिश्चितता कमी होते.

हे आणखी एका AI trick पेक्षा का जास्त महत्त्वाचे आहे

हे किस्सा एखाद्या हुशार life hack म्हणून वाचून पुढे जाण्याचा मोह होतो. पण ते प्रत्यक्षात generative AI adoption curve मधील एक मध्यवर्ती मुद्दा स्पर्श करते: लोकांना केवळ capability नको असते. त्यांना controllability हवी असते.

choir booklet चे उदाहरण अतिशय स्पष्ट आहे, कारण धोका सहज समजतो. पानावरील एक नोट बदलली, तर संपूर्ण सरावाचा हेतूच फसतो. तरीही हाच तर्क अनेक कामाच्या ठिकाणी लागू होतो, जिथे documents, images किंवा data अशी meaning घेऊन येतात की ती अखंड राहिली पाहिजे. वापरकर्ते अनेकदा असा system पसंत करतील जो verify करता येईल, पुन्हा चालवता येईल आणि scope मध्ये मर्यादित असेल, अशा system पेक्षा जो जास्त हुशार वाटतो पण कमी अंदाज येतो.

याचा अर्थ direct AI editing ला स्थान नाही असे नाही. अनेक creative आणि low-stakes कामांसाठी ते जलद आणि पूर्णतः स्वीकार्य आहे. पण लेख दाखवतो की “फक्त model ला file हाताळू द्या” हे नेहमी सर्वोत्तम उत्तर नसते. कधी कधी AI चा सर्वोत्तम वापर म्हणजे कामाच्या अंतिम artifact ऐवजी त्याच्या सभोवतालची कंटाळवाणी infrastructure तयार करून घेणे.

AI adoption च्या पुढच्या टप्प्यासाठी एक उपयुक्त नमुना

ZDNET ची कथा त्यामुळे ठसठशीत वाटते, कारण ती पसरू शकणारा एक pattern वर्णन करते. लोक increasingly AI चा वापर मागणीनुसार अरुंद software utilities तयार करण्यासाठी करतील, विशेषतः जेव्हा पारंपरिक tools खूप किचकट वाटतील आणि पूर्णपणे जनरेटिव्ह workflows खूप धोकादायक वाटतील. त्याचा परिणाम कमी AI असा नाही. AI stack मध्ये एक थर खाली जाऊन, तो सूर वाजवण्याऐवजी वाद्य तयार करण्यात मदत करतो.

दैनंदिन computing मध्ये model साठीची ही कदाचित सर्वात स्पष्ट practical भूमिका आहे. ते custom scripting चा वेळखर्च कमी करू शकतात, development मधील कंटाळवाणे भाग automate करू शकतात आणि सामान्य वापरकर्त्यांसाठी एकदाच लागणारी tools सुद्धा शक्य करू शकतात. पण स्रोत सामग्री महत्त्वाची असेल, तर अंतिम कृती अजूनही deterministic असावी अशी अनेकांची इच्छा राहील.

त्या अर्थाने, PDF ची ही कथा प्रत्यक्षात पिवळा कागद किंवा choir practice याबद्दल नाही. ती trust कसा engineer केला जातो याबद्दल आहे. सर्वात टिकाऊ AI workflows हेच असू शकतात जे जनरेटिव्ह वेग आणि पारंपरिक software reliability यांना एकत्र करतात, जेणेकरून वापरकर्ते दोन्हींचा फायदा घेऊ शकतील, एकाला दुसऱ्याशी गल्लत न करता.

हा लेख ZDNET च्या रिपोर्टिंगवर आधारित आहे. मूळ लेख वाचा.

Originally published on zdnet.com