जेव्हा तुम्ही लार्ज लँग्वेज मॉडेल्सना (LLMs) एकाच वेळी खूप काही करायला सांगता, तेव्हा ती गोंधळतात. चॅट विंडोमध्ये पन्नास पानांचा PDF टाका आणि एकाच वेळी संरचित विश्लेषण (structured analysis), जोखीम मूल्यांकन (risk assessment) आणि कार्यकारी सारांश (executive summary) मागा. याचे परिणाम सहसा अपूर्ण, गोंधळलेले किंवा पूर्णपणे चुकीचे असतात. अधिक चांगला दृष्टिकोन हा यांत्रिक (mechanical) आहे. कामाचे वेगवेगळ्या टप्प्यांमध्ये विभाजन करा. पहिल्या टप्प्यातील आउटपुट थेट दुसऱ्या टप्प्यात वापरा, आणि ही प्रक्रिया पुढे सुरू ठेवा. Anthropic या पद्धतीला 'प्रॉम्प्ट चेनिंग' (prompt chaining) म्हणते. Google याला 'सिक्वेन्शियल पाईपलाईन' (sequential pipeline) म्हणून संबोधते. दोन्ही नावे एकाच गोष्टीचे वर्णन करतात: एक असेंब्ली लाईन (assembly line) जिथे प्रत्येक स्टेशन एका विशिष्ट परिवर्तनाची जबाबदारी घेते.
हे प्रत्यक्ष व्यवहारात कसे दिसते
एका मोठ्या प्रॉम्प्टऐवजी, तुम्ही लहान आणि केंद्रित टप्प्यांची एक मालिका तयार करता. व्हेंडर सिक्युरिटी असेसमेंट (vendor security assessments) प्रक्रिया करणारी एक कंप्लायन्स टीम डोळ्यासमोर ठेवा. पहिला टप्पा स्कॅन केलेल्या PDF मधून कच्चा मजकूर (raw text) काढतो. दुसरा टप्पा एन्क्रिप्शन मानके (encryption standards) आणि ॲक्सेस कंट्रोल्सचा (access controls) प्रत्येक उल्लेख ओळखतो. तिसरा टप्पा त्या निष्कर्षांची अंतर्गत चेकलिस्टशी तुलना करतो. चौथा टप्पा सिक्युरिटी लीडसाठी एक छोटा मेमो तयार करतो. एक एजंट PDF चे मजकुरात रूपांतर करतो. पुढचा एजंट त्या मजकुरातून विशिष्ट डेटा काढतो. शेवटचा एजंट त्या डेटाच्या आधारे सारांश लिहितो. यातील कोणताही टप्पा खूप आकर्षक नाही आणि कोणताही टप्पा एकाच वेळी अनेक कामे (multitask) करत नाही. प्रत्येक भाग एकच काम उत्तम प्रकारे करतो.
म्हणूनच असेंब्ली लाईनचे रूपक येथे लागू पडते. कारखान्यात एक कामगार संपूर्ण कार तयार करत नाही. विशेषीकरणामुळे (specialization) गुणवत्ता उच्च राहते आणि चुकांची शक्यता कमी होते. हेच तर्क लँग्वेज मॉडेल्सनाही लागू होते. केवळ JSON एक्सट्रॅक्शन (extraction) विचारणाऱ्या प्रॉम्प्टमध्ये 'हॅलुसिनेशन' (hallucination) होण्याची शक्यता, एकाच विनंतीमध्ये मत आणि फॉरमॅटिंग देखील विचारणाऱ्या प्रॉम्प्टपेक्षा कमी असते.
अंदाज नको, 'गेट्स' (Gates) तयार करा
कोणत्याही साखळीतील सर्वात कमकुवत दुवा म्हणजे 'हँडऑफ' (handoff - एका टप्प्यातून दुसऱ्या टप्प्यात माहिती देणे). मॉडेल एखादा नम्र नकार देऊ शकते, JSON ऐवजी मार्कडाउनचा (markdown) तुकडा देऊ शकते किंवा अपूर्ण प्रतिसाद देऊ शकते. जर असा कचरा दुसऱ्या टप्प्यात गेला, तर संपूर्ण साखळी कोलमडते. याचे उपाय म्हणजे 'गेट' (gate).
गेट म्हणजे मॉडेल कॉल नाही. ते साधे कोड आहे. तुम्ही टप्प्यांच्या दरम्यान चालणारा एक छोटा स्क्रिप्ट लिहिता. ते आउटपुटची लांबी तपासू शकते जेणेकरून ते रिकामे नाही याची खात्री होईल. तिसऱ्या टप्प्याला अपेक्षित असलेल्या कीज (keys) मॅच होतात की नाही हे तपासण्यासाठी ते JSON स्कीमा व्हॅलिडेशन (JSON schema validation) करू शकते. पुढचा प्रॉम्प्ट तयार करण्यापूर्वीच, ईमेल पत्ता किंवा तारीख फील्ड प्रत्यक्षात आहे की नाही हे 'रेगेक्स' (regex) चेकद्वारे तपासले जाऊ शकते. यामुळे चुकीच्या आउटपुटवर पैसे वाया जाण्यापूर्वीच चुका थांबतात. गेटसाठी केवळ काही मायक्रोसेकंद कॉम्प्युट लागतो. पण डाउनस्ट्रीम (downstream) LLM कॉल अयशस्वी झाल्यास टोकन्स, लॅटन्सी (latency) आणि तुमचा मानसिक त्रास खर्च होतो.
याला कारखान्यातील 'क्वालिटी चेकपॉइंट' समजा. विगेट्स (widgets) मोजण्यासाठी तुम्हाला AI ची गरज नाही. तुम्हाला फक्त एका मोजपट्टीची (ruler) गरज आहे.
कधी साखळी वापरावी आणि कधी थांबवावे
प्रॉम्प्ट चेनिंग प्रत्येक समस्येसाठी योग्य नाही. जेव्हा कामाचे टप्पे निश्चित आणि पुन्हा पुन्हा करता येण्यासारखे असतात, तेव्हाच याचा वापर करा. मासिक आर्थिक अहवाल, प्रमाणित करार पुनरावलोकन (standardized contract review) आणि लॉग विश्लेषण पाईपलाईन्स (log analysis pipelines) ही याची चांगली उदाहरणे आहेत. जर तुम्ही प्रक्रिया चेकलिस्टच्या स्वरूपात लिहू शकत असाल, तर तुम्ही कदाचित त्याचे चेनिंग करू शकता. जेव्हा तुम्हाला जटिल कामासाठी उच्च अचूकतेची गरज असते, तेव्हाही तुम्ही चेनिंगचा वापर केला पाहिजे. समस्येचे टप्प्यांमध्ये विभाजन केल्यामुळे मॉडेलला एका वेळी एकाच तार्किक स्तरावर (logical layer) काम करण्यास भाग पाडले जाते. शेवटी, मोनोलिथिक (monolithic) प्रॉम्प्ट्सपेक्षा साखळ्यांमध्ये त्रुटी शोधणे (debug) सोपे असते. जेव्हा सारांश चुकीचा असतो, तेव्हा तुम्ही एक्सट्रॅक्शन तपासता. जेव्हा एक्सट्रॅक्शन चुकीचे असते, तेव्हा तुम्ही मूळ मजकूर तपासता. तुमच्याकडे तपासण्यासाठी मध्यवर्ती आर्टिफॅक्ट्स (intermediate artifacts) उपलब्ध असतात.
जेव्हा तुम्हाला टप्पे आधीच माहित नसतील, तेव्हा प्रॉम्प्ट चेनिंग टाळा. शोधनिबंध (exploratory research), मुक्त विचारमंथन (open-ended brainstorming) किंवा तपासणीची कामे एका सरळ रेषेत चालत नाहीत. जेव्हा वेग ही तुमची एकमेव प्राथमिकता असते, तेव्हाही हे टाळा. साखळ्या 'सिरीयल' (serial) असतात; पहिला टप्पा पूर्ण झाल्याशिवाय दुसरा टप्पा सुरू होऊ शकत नाही. जर तुमचे टप्पे एकमेकांवर अवलंबून नसतील, तर त्याऐवजी ते समांतर (parallel) चालवा. एकाच दस्तऐवजाचे तीन स्वतंत्र भाषांतर करण्यासाठी साखळी वापरण्याचे कोणतेही कारण नाही.
ताठरतेचा सापळा (The Rigidity Trap)
या सर्व संरचनेचा तोटा म्हणजे ताठरपणा (rigidity) हा आहे. एक निश्चित साखळी नवीन परिस्थितीशी जुळवून घेऊ शकत नाही. जर एखाद्या व्हेंडरने सहा-फील्डचा फॉर्म पाठवला आणि तुमच्या स्कीमा व्हॅलिडेशन गेटला पाचची अपेक्षा असेल, तर प्रक्रिया थांबते. जर वापरकर्त्याने PDF ऐवजी वर्ड डॉक्युमेंट अपलोड केले, तर पहिला टप्पा चुकत आहे आणि उर्वरित साखळीकडे प्रक्रिया करण्यासाठी काहीच उरत नाही.
अधिक वाईट म्हणजे, चुका पसरत जातात. सुरुवातीला झालेली चूक संपूर्ण साखळीत प्रवाहित होते. जर PDF एक्सट्रॅक्टरने आर्थिक आकड्यांमधून उणे चिन्ह (-) काढून टाकले, तर प्रत्येक डाउनस्ट्रीम टप्पा त्या चुकीच्या आकड्याला