Large language models तब चूक जाते हैं जब आप उनसे एक साथ बहुत कुछ करने के लिए कहते हैं। एक चैट विंडो में पचास पन्नों की PDF डाल दें और एक ही बार में एक संरचित विश्लेषण, जोखिम मूल्यांकन और कार्यकारी सारांश मांगें। परिणाम आमतौर पर सतही, भ्रमित करने वाला या पूरी तरह से गलत होता है। एक बेहतर दृष्टिकोण यांत्रिक (mechanical) है। काम को अलग-अलग चरणों में विभाजित करें। पहले चरण के आउटपुट को सीधे दूसरे में डालें, और इसी तरह आगे बढ़ते रहें। Anthropic इसे prompt chaining कहता है। Google इसे sequential pipeline कहता है। दोनों नाम एक ही चीज़ का वर्णन करते हैं: एक असेंबली लाइन जहाँ प्रत्येक स्टेशन एक विशिष्ट रूपांतरण (transformation) को संभालता है।
व्यवहार में यह कैसा दिखता है
एक विशाल प्रॉम्प्ट के बजाय, आप छोटे, केंद्रित चरणों की एक श्रृंखला बनाते हैं। एक अनुपालन (compliance) टीम की कल्पना करें जो वेंडर सुरक्षा मूल्यांकन (vendor security assessments) को प्रोसेस करती है। पहला चरण स्कैन की गई PDF से कच्चा टेक्स्ट निकालता है। दूसरा चरण एन्क्रिप्शन मानकों और एक्सेस कंट्रोल के हर उल्लेख की पहचान करता है। तीसरा चरण उन निष्कर्षों को एक आंतरिक चेकलिस्ट के साथ मैप करता है। चौथा चरण सुरक्षा प्रमुख के लिए एक संक्षिप्त मेमो तैयार करता है। एक एजेंट PDF को टेक्स्ट में बदलता है। अगला एजेंट उस टेक्स्ट से विशिष्ट डेटा निकालता है। अंतिम एजेंट उस डेटा के आधार पर सारांश लिखता है। इनमें से कोई भी चरण ग्लैमरस नहीं है, और उनमें से कोई भी मल्टीटास्किंग नहीं करता है। प्रत्येक भाग एक काम अच्छी तरह से करता है।
यही कारण है कि असेंबली लाइन का रूपक सटीक बैठता है। एक कारखाने में, एक कर्मचारी पूरी कार को असेंबल नहीं करता है। विशेषज्ञता गुणवत्ता को उच्च और विफलता के तरीकों (failure modes) को सीमित रखती है। यही तर्क भाषा मॉडल पर भी लागू होता है। एक प्रॉम्प्ट जो केवल JSON एक्सट्रैक्शन के लिए कहता है, उसके hallucinate करने की संभावना उस प्रॉम्प्ट की तुलना में कम होती है जो एक ही अनुरोध में राय और फॉर्मेटिंग भी मांगता है।
अनुमान नहीं, गेट्स (Gates) बनाएँ
किसी भी चेन का सबसे कमजोर बिंदु हैंडऑफ (handoff) होता है। एक मॉडल विनम्र इनकार, JSON के बजाय markdown का एक टुकड़ा, या एक अधूरा उत्तर दे सकता है। यदि वह गलत डेटा दूसरे चरण में प्रवाहित होता है, तो पूरी चेन ढह जाती है। इसका समाधान एक 'गेट' (gate) है।
एक गेट मॉडल कॉल नहीं है। यह साधारण कोड है। आप एक छोटा स्क्रिप्ट लिखते हैं जो चरणों के बीच चलता है। यह आउटपुट की लंबाई की जाँच कर सकता है ताकि यह सुनिश्चित हो सके कि वह खाली नहीं है। यह पुष्टि करने के लिए JSON स्कीमा वैलिडेशन चला सकता है कि कुंजियाँ (keys) वही हैं जिसकी तीसरे चरण को अपेक्षा है। एक regex चेक यह सत्यापित कर सकता है कि अगला प्रॉम्प्ट बनाने से पहले ईमेल पता या दिनांक फ़ील्ड वास्तव में मौजूद है या नहीं। यह गलत आउटपुट पर पैसा बर्बाद करने से पहले त्रुटियों को रोकता है। एक गेट को कंप्यूट के कुछ माइक्रोसेकंड लगते हैं। एक विफल डाउनस्ट्रीम LLM कॉल टोकन, लेटेंसी और आपकी मानसिक शांति (sanity) की कीमत वसूलता है।
इसे कारखाने के फर्श पर एक गुणवत्ता चेकपॉइंट के रूप में सोचें। आपको विजेट्स गिनने के लिए AI की आवश्यकता नहीं है। आपको एक रूलर (ruler) की आवश्यकता है।
कब चेनिंग करें, और कब रुकें
प्रॉम्प्ट चेनिंग हर समस्या के लिए उपयुक्त नहीं है। इसका उपयोग तब करें जब काम में निश्चित, दोहराए जाने वाले चरण हों। मासिक वित्तीय रिपोर्ट, मानकीकृत अनुबंध समीक्षा और लॉग विश्लेषण पाइपलाइन इसके अच्छे उदाहरण हैं। यदि आप प्रक्रिया को एक चेकलिस्ट के रूप में लिख सकते हैं, तो आप संभवतः इसे चेन कर सकते हैं। आपको चेनिंग का सहारा तब भी लेना चाहिए जब आपको जटिल काम के लिए उच्च सटीकता की आवश्यकता हो। समस्या को चरणों में तोड़ने से मॉडल एक समय में एक तार्किक परत (logical layer) को संभालने के लिए मजबूर होता है। अंत में, मोनोलिथिक प्रॉम्प्ट की तुलना में चेन्स को डीबग करना आसान होता है। जब सारांश गलत होता है, तो आप एक्सट्रैक्शन की जाँच करते हैं। जब एक्सट्रैक्शन गलत होता है, तो आप स्रोत टेक्स्ट की जाँच करते हैं। आपके पास परीक्षण के लिए मध्यवर्ती आर्टिफैक्ट्स (intermediate artifacts) होते हैं।
प्रॉम्प्ट चेनिंग से तब बचें जब आप चरणों को पहले से नहीं जानते हों। अन्वेषणात्मक अनुसंधान (exploratory research), ओपन-एंडेड मंथन (brainstorming), या जांच संबंधी कार्य एक सीधी रेखा का पालन नहीं करते हैं। यदि गति आपकी एकमात्र प्राथमिकता है, तो इसे छोड़ दें। चेन्स सीरियल होती हैं; दूसरा चरण तब तक शुरू नहीं हो सकता जब तक पहला चरण समाप्त न हो जाए। यदि आपके चरण एक-दूसरे पर निर्भर नहीं हैं, तो उन्हें इसके बजाय पैरेलल (parallel) में चलाएं। एक ही दस्तावेज़ के तीन स्वतंत्र अनुवादों को चेन करने का कोई कारण नहीं है।
कठोरता का जाल
इस पूरी संरचना का ट्रेड-ऑफ कठोरता है। एक निश्चित चेन नई स्थितियों के अनुकूल नहीं हो सकती है। यदि कोई वेंडर छह-फील्ड वाला फॉर्म भेजता है और आपका स्कीमा वैलिडेशन गेट पांच की अपेक्षा करता है, तो लाइन रुक जाती है। यदि कोई उपयोगकर्ता PDF के बजाय Word दस्तावेज़ अपलोड करता है, तो पहला चरण टूट जाता है और बाकी चेन के पास काम करने के लिए कुछ नहीं बचता।
इससे भी बुरा यह है कि त्रुटियाँ फैलती हैं। शुरुआत में होने वाली गलती पूरी चेन में प्रवाहित होती है। यदि PDF एक्सट्रैक्टर किसी वित्तीय आंकड़े से नकारात्मक चिह्न हटा देता है, तो प्रत्येक डाउनस्ट्रीम चरण उस गलत संख्या को