किसी लैंग्वेज मॉडल से पूछें कि “strawberry” शब्द में कितने अक्षर हैं। इसकी पूरी संभावना है कि वह गलत जवाब देगा। वह दस कह सकता है। वह ग्यारह का अनुमान लगा सकता है। वह पूरी तरह से आत्मविश्वास के साथ कहेगा, फिर भी वह गलत होगा। उसी मॉडल से किसी ऋण पर चक्रवृद्धि ब्याज की गणना करने, या दो बड़ी संख्याओं को जोड़ने, या दो तारीखों के बीच कार्य दिवसों (business days) को गिनने के लिए कहें, और आपको अक्सर एक विश्वसनीय दिखने वाला उत्तर मिलेगा जिसमें अंक थोड़े, लेकिन खतरनाक रूप से गलत होंगे।

ऐसा इसलिए होता है क्योंकि लार्ज लैंग्वेज मॉडल्स (LLMs) संख्याओं के बारे में उस तरह से तर्क नहीं करते जैसे इंसान करते हैं। वे टोकन (tokens) की भविष्यवाणी करते हैं। एक टोकन एक पूरा शब्द, शब्द का हिस्सा, या एक एकल अंक हो सकता है। जब मॉडल “strawberry” देखता है, तो वह एक पंक्ति में लगे आठ अलग-अलग अक्षरों को नहीं देखता। वह केवल कुछ टुकड़ों (chunks) को देखता है। उसे अक्षरों को गिनना कभी नहीं सिखाया गया है, केवल यह भविष्यवाणी करना सिखाया गया है कि अगला टेक्स्ट का टुकड़ा कौन सा होगा। यही सीमा अंकगणित (arithmetic) पर भी लागू होती है। मॉडल के पास कोई आंतरिक कैलकुलेटर नहीं होता। उसमें 'कैरी लॉजिक' (carry logic) की कमी होती है। उसे स्थानीय मान (place value) की कोई वास्तविक समझ नहीं होती। जब वह 148 को 279 से गुणा करता है, तो वह गुणा नहीं कर रहा होता है। वह प्रशिक्षण के दौरान देखे गए समान अभिव्यक्तियों के साथ पैटर्न-मैचिंग कर रहा होता है, और यह अनुमान लगा रहा होता है कि अंकों का कौन सा क्रम आगे आना चाहिए। बहुत छोटे योगों के लिए पैटर्न इतना मजबूत होता है कि वह काम कर जाता है। लेकिन जिस भी चीज़ में वास्तविक सटीकता की आवश्यकता होती है, वहां अनुमान अंततः विफल हो जाता है।

दो काम, एक बॉट

मानक प्रॉम्प्टिंग विधियाँ एक ही सिस्टम से एक साथ दो बहुत अलग काम करने के लिए कहती हैं। पहला, समस्या के तर्क (logic) को समझना। दूसरा, सटीक गणित का निष्पादन करना। मॉडल पहले कार्य में वास्तव में प्रभावशाली है। वह एक वर्ड प्रॉब्लम (word problem) पढ़ सकता है, वेरिएबल्स (variables) निकाल सकता है, संबंधों को मैप कर सकता है और समाधान का रास्ता तैयार कर सकता है। लेकिन फिर उसे अपने स्वयं के कैलकुलेटर के रूप में कार्य करना पड़ता है। यहीं पर कड़ी टूट जाती है। तीसरे चरण में एक भी अंक की चूक उसके बाद के हर चरण को खराब कर देती है। तर्क स्वयं सटीक हो सकता है, फिर भी अंतिम उत्तर गलत होता है क्योंकि मॉडल ने गलत तरीके से जोड़ा था।

प्रोग्राम-एडेड लैंग्वेज मॉडल्स (Program-Aided Language Models), या PAL, काम को विभाजित करके इस समस्या का समाधान करते हैं। मॉडल से उत्तर मांगने के बजाय, आप उससे एक प्रोग्राम मांगते हैं।

यहाँ बताया गया है कि यह प्रवाह वास्तव में कैसे काम करता है। आप समस्या प्रस्तुत करते हैं। मॉडल तर्क को समझता है, वेरिएबल्स को परिभाषित करता है, और एल्गोरिदम की संरचना करता है। फिर, स्वयं परिणाम की गणना करने के बजाय, यह एक छोटा स्क्रिप्ट लिखता है, जो आमतौर पर Python में होता है। वह स्क्रिप्ट एक वास्तविक कोड इंटरप्रेटर (code interpreter) को सौंप दी जाती है। इंटरप्रेटर तर्क को चलाता है और सटीक, नियतात्मक (deterministic) परिणाम वापस करता है। मॉडल गणित का वर्णन करता है। Python गणित करता है।

व्यवहार में निष्पादन योग्य तर्क (Executable Reasoning)

PAL को 'एक्जीक्यूटेबल रीजनिंग' के रूप में सोचें। यदि कोई स्क्रिप्ट किसी समस्या को हल कर सकती है, तो मॉडल को स्क्रिप्ट लिखने दें।

एक ठोस उदाहरण पर विचार करें। आपको ₹50,000 की फिक्स्ड डिपॉजिट पर 8.5 प्रतिशत की वार्षिक ब्याज दर पर, त्रैमासिक रूप से चक्रवृद्धि (compounded quarterly), सात वर्षों के लिए मैच्योरिटी राशि की गणना करने की आवश्यकता है। यदि आप सीधे किसी लैंग्वेज मॉडल से पूछेंगे, तो वह एक फॉर्मूला लिख सकता है, मानों को प्रतिस्थापित कर सकता है और 'चेन ऑफ थॉट' (chain of thought) में परिणाम की गणना कर सकता है। हालाँकि, ध्यान से देखने पर आप पाएंगे कि उसने त्रैमासिक चक्रवृद्धि (quarterly compounding) को गलत तरीके से दर विभाजित करके या किसी मध्यवर्ती चरण को राउंड ऑफ करके और उस त्रुटि को आगे बढ़ाकर गलत तरीके से संभाला है। उत्तर तर्कसंगत लगता है लेकिन सैकड़ों रुपये कम या ज्यादा हो सकता है।

PAL के साथ, इंटरैक्शन बदल जाता है। आप मॉडल को Python कोड जेनरेट करने का निर्देश देते हैं जो principal = 50000, rate = 0.085, time = 7, और n = 4 को परिभाषित करता है, और फिर amount = principal * (1 + rate/n) ** (n * time) की गणना करता है। मॉडल कोड देता है। एक Python रनटाइम इसे निष्पादित करता है। आपको हर बार, अंतिम दशमलव तक सटीक आंकड़ा मिलता है। गुणा में कोई अनुमान नहीं, कोई काल्पनिक शेषफल (remainder) नहीं, और कोई आत्मविश्वासपूर्ण राउंडिंग एरर नहीं होता।

यही पैटर्न तारीखों के गणित पर भी लागू होता है। किसी मॉडल से पूछें कि सप्ताहांत (weekends) को छोड़कर, आज से ठीक 120 कार्य दिवसों (business days) के बाद कौन सी तारीख आती है। केवल टेक्स्ट वाला मॉडल आगे की गिनती कर सकता है और शनिवार पर चूक सकता है। PAL दृष्टिकोण में मॉडल datetime और calendar लॉजिक का उपयोग करके एक स्क्रिप्ट लिखता है, और फिर इंटरप्रेटर को सटीक रूप से गणना करने देता है। डेटा मैनिपुलेशन भी इसी तरह काम करता है। यदि आपको किसी अव्यवस्थित CSV को पार्स करने, नेस्टेड JSON को फ़िल्टर करने, या त्वरित सांख्यिकीय रूपांतरण (statistical transform) चलाने की आवश्यकता है, तो मॉडल को लॉजिक का मसौदा तैयार करना चाहिए जबकि इंटरप्रेटर पुनरावृत्ति (iteration) को संभालता है।

यह वास्तव में क्यों मायने रखता है

गद्य उत्तरों से निष्पादन योग्य कोड की ओर बदलाव तीन व्यावहारिक लाभ प्रदान करता है।

डिटरमिनिज्म (Determinism). एक ही सवाल दो बार पूछे जाने पर एक लैंग्वेज मॉडल अपनी शब्दावली बदल सकता है या किसी अंक (digit) में बदलाव कर सकता है। एक इंटरप्रेटर हर बार एक ही इनपुट के लिए समान आउटपुट देता है। अकाउंटिंग, लॉजिस्टिक्स, शेड्यूलिंग और किसी भी इंजीनियरिंग गणना में यह स्थिरता अत्यंत महत्वपूर्ण है, जहाँ निरंतरता (consistency) वैकल्पिक नहीं है।

सत्यापनीयता (Verifiability). जब कोई मॉडल आपको तर्क के तीन पैराग्राफ देता है, तो आपको एक गलत नंबर खोजने के लिए हर वाक्य को पढ़ना पड़ता है। जब वह आपको दस लाइनों का एक स्क्रिप्ट देता है, तो आप कोड की समीक्षा कर सकते हैं। आप इंटरप्रेटर द्वारा रन किए जाने से पहले ही यह सत्यापित कर सकते हैं कि चक्रवृद्धि ब्याज (compound-interest) का फॉर्मूला सही है। आप वेरिएबल नामों की जांच कर सकते हैं, 'off-by-one' त्रुटियों को पकड़ सकते हैं, और यहाँ तक कि समाधान का वर्जन-कंट्रोल (version-control) भी कर सकते हैं। छिपी हुई गलतियों की गुंजाइश नाटकीय रूप से कम हो जाती है।

विश्वसनीयता (Reliability). मॉडल अपनी सीमा में रहता है। यह वही करता है जिसके लिए इसे बनाया गया है: संरचना (structure), अर्थविज्ञान (semantics) और समस्या के विघटन (problem decomposition) के बारे में तर्क करना। मशीन वही करती है जिसके लिए इसे बनाया गया है: सटीक गणना करना। 'सेपरेशन ऑफ कंसर्न्स' (separation of concerns) ही वह तरीका है जिससे विश्वसनीय सॉफ्टवेयर का आर्किटेक्चर तैयार किया जाता है। कंपोजिशन (Composition), मोनोलिथिक डिज़ाइन (monolithic design) से बेहतर है।

इसे अन