ஒரு மொழி மாதிரியிடம் (language model) “strawberry” என்ற வார்த்தையில் எத்தனை எழுத்துக்கள் உள்ளன என்று கேளுங்கள். அது தவறாகச் சொல்லவே அதிக வாய்ப்புள்ளது. அது பத்து என்று சொல்லலாம். அது பதினொன்று என்று யூகிக்கலாம். அது மிகவும் உறுதியாகத் தோன்றும், ஆனால் அது தவறாகவே இருக்கும். அதே மாதிரியிடம் ஒரு கடனுக்கான கூட்டு வட்டியைக் கணக்கிடச் சொன்னாலோ, அல்லது இரண்டு பெரிய எண்களைக் கூட்டச் சொன்னாலோ, அல்லது இரண்டு தேதிகளுக்கு இடையிலான வணிக நாட்களைக் (business days) கணக்கிடச் சொன்னாலோ, பெரும்பாலும் நம்பகமானதாகத் தோன்றும் ஆனால் எண்கள் சற்றுத் தவறாக இருக்கும் பதிலைப் பெறுவீர்கள்.
இது ஏன் நடக்கிறது என்றால், பெரிய மொழி மாதிரிகள் மனிதர்களைப் போல எண்களைப் பற்றி சிந்திப்பதில்லை. அவை டோக்கன்களை (tokens) கணிக்கின்றன. ஒரு டோக்கன் என்பது ஒரு முழு வார்த்தையாகவோ, ஒரு வார்த்தையின் பகுதியாகவோ அல்லது ஒரு ஒற்றை இலக்கமாகவோ இருக்கலாம். மாதிரி “strawberry” என்பதைப் பார்க்கும்போது, அது வரிசையாக இருக்கும் எட்டு தனித்தனி எழுத்துக்களாகப் பார்ப்பதில்லை. அது சில துண்டுகளாகவே (chunks) பார்க்கிறது. எழுத்துக்களை எண்ணுவதற்கு அதற்குப் பயிற்சி அளிக்கப்படவில்லை, அடுத்ததாக எந்தத் தகவல் துண்டு வரும் என்பதைக் கணிக்க மட்டுமே அதற்குத் தெரியும். இதே கட்டுப்பாடு கணிதத்திற்கும் பொருந்தும். அந்த மாதிரிக்குத் தனியாகக் கணக்கீட்டு இயந்திரம் (calculator) கிடையாது. அதற்கு 'carry logic' போன்ற நுணுக்கங்கள் தெரியாது. இடமதிப்பு (place value) பற்றிய உண்மையான புரிதல் அதற்கு இல்லை. அது 148-ஐ 279-ஆல் பெருக்கும்போது, அது பெருக்கலைச் செய்யவில்லை. மாறாக, பயிற்சியின் போது அது பார்த்த ஒத்த வெளிப்பாடுகளுடன் ஒப்பிட்டு (pattern-matching), அடுத்ததாக எந்த எண்கள் வர வேண்டும் என்று யூகிக்கிறது. சிறிய கூட்டல்களுக்கு இந்த யூகங்கள் சரியாக இருக்கலாம். ஆனால் துல்லியமான கணக்கீடுகளுக்கு, இந்த யூகங்கள் இறுதியில் தோல்வியடையும்.
இரண்டு வேலைகள், ஒரு பாட் (Bot)
வழக்கமான ப்ராம்ப்டிங் (prompting) முறைகள் ஒரு அமைப்பிடம் ஒரே நேரத்தில் இரண்டு வெவ்வேறு விஷயங்களைச் செய்யக் கோருகின்றன. முதலாவதாக, சிக்கலின் தர்க்கத்தைப் (logic) புரிந்துகொள்ள வேண்டும். இரண்டாவதாக, துல்லியமான கணிதத்தைச் செய்ய வேண்டும். முதல் வேலையில் அந்த மாதிரி உண்மையிலேயே வியக்கத்தக்க வகையில் செயல்படுகிறது. அது ஒரு கணக்கு சார்ந்த சிக்கலைப் படித்து, மாறிகளை (variables) பிரித்தெடுத்து, உறவுகளைக் கண்டறிந்து, ஒரு தீர்வைத் திட்டமிட முடியும். ஆனால் அதன் பிறகு, அதுவே ஒரு கால்குலேட்டராகச் செயல்பட வேண்டும். அங்கேயே அந்தச் சங்கிலி உடைந்துவிடுகிறது. மூன்றாவது படிநிலையில் ஒரு சிறிய எண் தவறுபட்டாலும், அது அதற்குப் பிந்தைய அனைத்துப் படிநிலைகளையும் பாதிக்கும். தர்க்கம் சரியாக இருந்தாலும், மாதிரி தவறாகக் கூட்டியதால் இறுதி விடை தவறாக இருக்கும்.
Program-Aided Language Models அல்லது PAL, வேலையைப் பிரிப்பதன் மூலம் இதைத் தீர்க்கிறது. மாதிரிக்கு நேரடியாகப் பதிலைக் கேட்பதற்குப் பதிலாக, ஒரு நிரலை (program) எழுதச் சொல்லலாம்.
இதன் செயல்முறை உண்மையில் எவ்வாறு இயங்குகிறது என்றால்: நீங்கள் சிக்கலை முன்வைக்கிறீர்கள். மாதிரி அதன் தர்க்கத்தைக் கண்டறிந்து, மாறிகளை வரையறுத்து, அல்காரிதத்தை (algorithm) கட்டமைக்கிறது. பின்னர், அதுவே முடிவைக் கணக்கிடுவதற்குப் பதிலாக, பொதுவாக Python மொழியில் ஒரு சிறிய ஸ்கிரிப்டை (script) எழுதுகிறது. அந்த ஸ்கிரிப்ட் ஒரு உண்மையான கோட் இன்டர்பிரட்டருக்கு (code interpreter) அனுப்பப்படுகிறது. அந்த இன்டர்பிரட்டர் தர்க்கத்தைச் செயல்படுத்தி, துல்லியமான மற்றும் நிலையான (deterministic) முடிவைத் தருகிறது. மாதிரி கணிதத்தை விவரிக்கிறது. Python கணிதத்தைச் செய்கிறது.
நடைமுறையில் செயல்படுத்தக்கூடிய தர்க்கம் (Executable Reasoning)
PAL-ஐ 'செயல்படுத்தக்கூடிய தர்க்கம்' என்று நினைத்துக் கொள்ளுங்கள். ஒரு ஸ்கிரிப்ட் ஒரு சிக்கலைத் தீர்க்க முடியும் என்றால், அந்த ஸ்கிரிப்டை எழுத மாதிரியிடம் விட்டுவிடுங்கள்.
ஒரு நிஜமான உதாரணத்தைக் கருத்தில் கொள்ளுங்கள். ₹50,000 நிலையான வைப்புத் தொகைக்கு (fixed deposit), ஆண்டு வட்டி விகிதம் 8.5 சதவீதம், காலாண்டு வட்டி முறையில் (compounded quarterly), ஏழு ஆண்டுகளுக்குக் கிடைக்கும் முதிர்வுத் தொகையைக் (maturity amount) கணக்கிட வேண்டும். ஒரு மொழி மாதிரியிடம் நேரடியாகக் கேட்டால், அது ஒரு சூத்திரத்தை எழுதி, மதிப்புகளைப் பிரதியிட்டு, ஒரு தொடர்ச்சியான சிந்தனைச் சங்கிலி (chain of thought) மூலம் முடிவைக் கணக்கிடலாம். ஆனால் உற்று நோக்கினால், அது காலாண்டு வட்டி முறையைத் தவறாகக் கணக்கிட்டிருக்கலாம் அல்லது ஒரு இடைநிலைப் படிநிலையில் மதிப்பைத் தவறாக உருக்கி (rounding), அந்தத் தவறைத் தொடரச் செய்திருக்கலாம் என்பதைக் காணலாம். விடை நியாயமானதாகத் தோன்றலாம், ஆனால் நூற்றுக்கணக்கான ரூபாய்கள் வித்தியாசம் இருக்கலாம்.
PAL மூலம், இந்தத் தொடர்பு மாறுகிறது. நீங்கள் மாதிரியிடம் principal = 50000, rate = 0.085, time = 7, மற்றும் n = 4 என வரையறுத்து, பின்னர் amount = principal * (1 + rate/n) ** (n * time) என்பதைக் கணக்கிடும் Python குறியீட்டை உருவாக்கச் சொல்கிறீர்கள். மாதிரி அந்த குறியீட்டை வெளியிடுகிறது. ஒரு Python runtime அதைச் செயல்படுத்துகிறது. ஒவ்வொரு முறையும் கடைசி தசம எண் வரை துல்லியமானத் தொகையைப் பெறுகிறீர்கள். பெருக்கலில் யூகங்கள் இல்லை, தவறான மீதங்கள் இல்லை, அல்லது தவறான உருக்கல்கள் (rounding errors) இல்லை.
இதே முறை தேதிகள் தொடர்பான கணிதத்திற்கும் பொருந்தும். வார இறுதி நாட்களைத் தவிர்த்து, இன்று முதல் சரியாக 120 வணிக நாட்களுக்குப் பிறகு வரும் தேதி எது என்று ஒரு மாதிரியிடம் கேளுங்கள். வெறும் உரை சார்ந்த மாதிரி (text-only model) தேதிகளை எண்ணும்போது சனிக்கிழமைகளில் தவறிவிடக்கூடும். PAL அணுகுமுறை, datetime மற்றும் calendar தர்க்கத்தைப் பயன்படுத்தி ஒரு ஸ்கிரிப்டை எழுத மாதிரியிடம் சொல்லும், பின்னர் இன்டர்பிரட்டர் அதைத் துல்லியமாகச் செயல்படுத்தும். தரவு கையாளுதலும் (Data manipulation) இதே வழியில் செயல்படுகிறது. நீங்கள் ஒரு குழப்பமான CSV கோப்பைப் பகுப்பாய்வு செய்யவோ, சிக்கலான JSON கோப்புகளை வடிகட்டவோ அல்லது விரைவான புள்ளிவிவர மாற்றங்களைச் செய்யவோ தேவைப்பட்டால், மாதிரி தர்க்கத்தை வடிவமைக்க வேண்டும், இன்டர்பிரட்டர் அதைச் செயல்படுத்த வேண்டும்.
இது ஏன் உண்மையில் முக்கியமானது
உரை வடிவிலான பதில்களில் இருந்து செயல்படுத்தக்கூடிய குறியீட்டிற்கு மாறுவது மூன்று நடைமுறை நன்மைகளை வழங்குகிறது.
Determinism. A language model asked the same question twice might vary its wording or change a digit. An interpreter returns the same output for the same input every time. That stability matters deeply in accounting, logistics, scheduling, and any engineering calculation where consistency is not optional.
Verifiability. When a model hands you three paragraphs of reasoning, you must read every sentence to hunt for the one wrong number. When it hands you a ten-line script, you can review the code. You can verify that the compound-interest formula is correct before the interpreter ever runs. You can inspect variable names, spot off-by-one errors, and even version-control the solution. The surface area for hidden mistakes shrinks dramatically.
Reliability. The model stays in its lane. It does what it was built to do: reason about structure, semantics, and problem decomposition. The machine does what it was built to do: compute accurately. This separation of concerns is exactly how reliable software is architected. Composition beats monolithic design.
Run It Like Untrusted Code
A word of caution is necessary. Generated code should be treated as untrusted input. The model might write a script with an infinite loop, an unnecessary network request, or a filesystem operation you did not ask for. Always execute these programs inside an isolated sandbox. Use containers with restricted privileges, serverless functions with no network access, or tightly controlled environments with limited CPU time and no persistent storage. Security is not a footnote here. It is part of the system design.
Where PAL Shines, and Where It Stops
PAL works beautifully for math, dates, and structured data manipulation. It removes the mechanical errors that plague text-only reasoning.
It does not, however, fix bad logic. If the model chooses the wrong formula,