நீங்கள் நூறு பக்க ஆவணங்களை (documentation) ப்ராம்ப்ட்டில் (prompt) ஒட்டிவிட்டு ஒரு எளிய கேள்வியைக் கேட்கிறீர்கள். பதில் தவறாக வருகிறது. அல்லது நீங்கள் மேலே கொடுத்த வடிவமைப்புக் விதியைப் (formatting rule) புறக்கணிக்கிறது. நீங்கள் அதற்கு அனைத்தையும் கொடுத்துவிட்டீர்கள். அது சரியாக வேலை செய்திருக்க வேண்டும். ஆனால் அது செய்யவில்லை.

இதுதான் 'கான்டெக்ஸ்ட் டிராப்' (context trap). ஒரு AI-க்கு அதிக தகவல்களைக் கொடுப்பது தானாகவே சிறந்த முடிவுகளைத் தரும் என்று பெரும்பாலான டெவலப்பர்கள் கருதுகிறார்கள். ஆனால் பெரும்பாலும் உண்மை அதற்கு நேர்மாறானது. நம்பகமான AI பயன்பாடுகளை உருவாக்க மூன்று முக்கிய வழிமுறைகளைப் புரிந்துகொள்வது அவசியம்: மாடல்கள் உரையை எவ்வாறு கணக்கிடுகின்றன, அவை ஒரே நேரத்தில் எவ்வளவு தகவல்களைத் தாங்கிக்கொள்ள முடியும், மற்றும் ஒரு உரையாடல் முடிந்ததும் தகவல்களுக்கு என்ன நடக்கும் என்பது பற்றிய புரிதல்.

டோக்கன்கள் (Tokens): உண்மையான நாணயம்

ஒரு டோக்கன் என்பது ஒரு மொழி மாதிரி (language model) செயலாக்கும் மிகச்சிறிய அலகாகும். அது ஒரு ஒற்றை எழுத்துவாகவோ, ஒரு சொல்லின் பகுதியாகவோ அல்லது ஒரு முழுமையான பொதுவான சொல்லாகவோ இருக்கலாம். "purchase" என்ற சொல் பெரும்பாலும் இரண்டு டோக்கன்களாகப் பிரிக்கப்படுகிறது, ஆனால் "cat" போன்ற ஒரு சிறிய சொல் அப்படியே இருக்கும். நிறுத்தற்குறிகளும் (punctuation) இடைவெளிகளும் (spaces) டோக்கன்களைப் பயன்படுத்துகின்றன. கோட் (Code) என்பது குறிப்பாக அதிக டோக்கன்களை எடுத்துக்கொள்ளும். நெஸ்டட் இண்டன்டேஷன் (nested indentation) மற்றும் சிறப்பு எழுத்துக்களைக் கொண்ட ஒரு Python கோட் தொகுப்பு, நீங்கள் தோராயமாக நினைப்பதை விட மூன்று அல்லது நான்கு மடங்கு அதிக டோக்கன் எண்ணிக்கையை அடையக்கூடும்.

உருவாக்குநர்கள் (builders) ஏன் இதைப் பற்றி கவலைப்பட வேண்டும்? API விலை டோக்கன்களின் அடிப்படையில் கணக்கிடப்படுகிறது. செயலாக்க நேரமும் (processing time) அப்படித்தான். இரண்டு பக்க உரையைப் போலத் தோன்றும் ஒரு ப்ராம்ப்ட், அதன் உள்ளடக்கத்தைப் பொறுத்து சில காசுகள் அல்லது டாலர்களைச் செலவழிக்கக்கூடும். அதைவிட மோசமான விஷயம் என்னவென்றால், பரிமாற்றத்தின் இருபுறமும் டோக்கன்கள் கணக்கிடப்படுகின்றன. உங்கள் ப்ராம்ப்ட்டில் உள்ள ஒவ்வொரு டோக்கனுக்கும் நீங்கள் பணம் செலுத்த வேண்டும், மேலும் மாடல் பதிலளிக்கும் ஒவ்வொரு டோக்கனுக்கும் நீங்கள் பணம் செலுத்த வேண்டும். கட்டுப்படுத்தப்படாத கான்டெக்ஸ்ட் வளர்ச்சி (context growth) லாபத்தை மெதுவாகக் குறைத்துவிடும்.

கான்டெக்ஸ்ட் விண்டோ (Context Window) என்பது ஒரு வைட்போர்டு (Whiteboard) போன்றது

கான்டெக்ஸ்ட் விண்டோ என்பது ஒரு மாடல் ஒரே நேரத்தில் எவ்வளவு தகவல்களைப் பார்க்க முடியும் என்பதற்கான உச்சவரம்பைத் தீர்மானிக்கிறது. ஒரு சிறிய அறையில் தொங்கும் வைட்போர்டை கற்பனை செய்து பாருங்கள். அதில் சிஸ்டம் இன்ஸ்ட்ரக்ஷன்ஸ் (system instructions), பயனர் கேள்விகள், பெறப்பட்ட ஆவணங்கள் மற்றும் முந்தைய உரையாடல்களை நீங்கள் நிரப்பலாம். ஆனால் அந்தப் பலகை வளராது. புதிய உரை வரும்போது, பழைய உரை ஓரத்திலிருந்து வெளியேறிவிடும்.

இது ஏன் முக்கியம் என்றால், மாடல்கள் தகவல்களைத் தவிர்க்கத் தொடங்கும் போது உங்களுக்கு எச்சரிக்கை செய்யாது. உங்கள் சிஸ்டம் இன்ஸ்ட்ரக்ஷன் ஒரு நீண்ட உரையாடலின் உச்சியில் இருந்தால், நீங்கள் தொடர்ந்து செய்திகளைச் சேர்த்துக்கொண்டே சென்றால், அந்த இன்ஸ்ட்ரக்ஷன் இறுதியில் பார்வையில் இருந்து மறைந்துவிடும். மாடல் அதன் இயல்பான செயல்பாட்டிற்குத் திரும்பலாம், உங்கள் வடிவமைப்புக் விதியைப் புறக்கணிக்கலாம் அல்லது முந்தைய வழிகாட்டுதல்களுக்கு முரணாகச் செயல்படலாம். வெவ்வேறு மாடல்கள் வெவ்வேறு வரம்புகளைக் கொண்டுள்ளன; சில ஆயிரக்கணக்கான டோக்கன்களைக் கையாளும், மற்றவை பல லட்சக்கணக்கான டோக்கன்களைக் கையாளும், ஆனால் அதன் அடிப்படை வழிமுறை ஒன்றுதான். உள்ளீடு (input) மற்றும் வெளியீடு (output) இரண்டும் ஒரே பட்ஜெட்டைப் பகிர்ந்து கொள்கின்றன. இரண்டாயிரம் டோக்கன்கள் கொண்ட ஒரு பதிலை உருவாக்கும் மாடலுக்கு, நீங்கள் சொன்னதை நினைவில் வைத்துக்கொள்ள இரண்டாயிரம் டோக்கன்கள் குறைவாகவே இருக்கும்.

மெமரி (Memory) என்பது ஒரு ஹேக் (Hack), அம்சம் (Feature) அல்ல

இன்ஃபரன்ஸ் (inference) செய்யும் போது மாடல் வெயிட்டுகளுக்குள் (model weights) நிலையான மெமரி எதுவும் இல்லை. எதுவுமே இல்லை. நீங்கள் டேப்பை (tab) மூடிவிட்டு நாளைத் திரும்ப வரும்போது, மாடல் உங்களை அடையாளம் காணாது. ஒவ்வொரு API அழைப்பும் ஒரு 'கோல்ட் ஸ்டார்ட்' (cold start) ஆகும்.

மெமரி போலத் தோன்றுவது என்பது அப்ளிகேஷன் லேயரால் (application layer) செய்யப்படும் ஒரு புத்திசாலித்தனமான கணக்குப்பதிவு மட்டுமே. பிரண்ட்எண்ட் (frontend) உங்கள் செய்திகளை ஒரு டேட்டாபேஸில் (database) சேமித்து வைக்கிறது. நீங்கள் ஒரு புதிய கேள்வியைக் கேட்கும்போது, மென்பொருள் தொடர்புடைய வரலாற்றைப் பெற்று, அதை ஒரு புதிய ப்ராம்ப்ட்டாக இணைத்து, அந்த முழு தொகுப்பையும் மாடலுக்கு அனுப்புகிறது. மாடலுக்கு இது தெரியாது.

தயாரிப்புக் குழுக்களுக்கு (product teams) இந்த வேறுபாடு மிகவும் முக்கியமானது. ஒரு பயனரின் விருப்பத்தை "நினைவில் கொள்ள" நீங்கள் மாடலைச் சார்ந்திருந்தால், நீங்கள் மணலில் ஒரு கட்டிடத்தைக் கட்டுகிறீர்கள் என்று அர்த்தம். நீங்களே 'ஸ்டேட் மேனேஜ்மென்ட்டை' (state management) உருவாக்க வேண்டும். எதை கேச் (cache) செய்ய வேண்டும் என்பதைத் தீர்மானியுங்கள். அதை எவ்வாறு புதுப்பிப்பது என்பதையும் தீர்மானியுங்கள். மேலும், நீங்கள் மீண்டும் அனுப்பும் வரலாற்றின் ஒவ்வொரு பைட்டும் உங்கள் வைட்போர்டு இடத்தைப் பயன்படுத்துகிறது என்பதை உணருங்கள்.

கான்டெக்ஸ்ட் சத்தமாக (Noise) மாறும்போது

ப்ராம்ப்ட்டில் அதிகப்படியான தகவல்களைத் திணிப்பது கணிக்கக்கூடிய வழிகளில் எதிர்மறையான விளைவுகளை ஏற்படுத்தும்.

சத்தம் சிக்னலை அழித்துவிடும் (Noise kills signal). ஒரு பிழை (bug) பற்றி கேட்க முழு கோட்பேஸையும் (codebase) நீங்கள் வழங்கினால், மாடல் 'வைடேத்ல ஊசி தேடும்' (needle-in-a-haystack) சிக்கலை எதிர்கொள்ளும். அது தவறான கோப்பைக் குறிப்பிடலாம், பயன்படாத கோடிற்கு (dead code) மாற்றங்களைச் பரிந்துரைக்கலாம் அல்லது அதனால்