உண்மையிலேயே செயல்படும் AI செயலிகளை உருவாக்குவது என்பது சரியான ப்ராம்ப்ட்டை (prompt) உருவாக்குவதை விட, நீங்கள் மாடலுக்கு வழங்கும் தகவல்களைக் கட்டுப்படுத்துவதைப் பொறுத்தது. ஒரு உதவியாளருடன் நீண்ட நேரம் உரையாடியபோது, பத்து நிமிடங்களுக்கு முன்பு நீங்கள் சொன்ன ஒன்றை அவர் மறந்துவிட்டதை உணர்ந்திருந்தால், கான்டெக்ஸ்ட் இன்ஜினியரிங் (context engineering) தோல்வியடையும் போது என்ன நடக்கும் என்பதை நீங்கள் ஏற்கனவே உணர்ந்திருப்பீர்கள். AI-க்கு மோசமான நினைவாற்றல் இருப்பதாகக் கருதுவது எளிது. உண்மையில், நீங்கள் கான்டெக்ஸ்ட் விண்டோவின் (context window) கடினமான வரம்புகளைத் தொட்டுவிட்டீர்கள்.
நம்பகமான மற்றும் விரைவாகப் பதிலளிக்கும் அமைப்புகளை உருவாக்க, நீங்கள் மூன்று அடிப்படைகளைப் புரிந்துகொள்ள வேண்டும்: டோக்கன்கள் (tokens), கான்டெக்ஸ்ட் விண்டோக்கள் (context windows), மற்றும் கான்டெக்ஸ்ட் மற்றும் மெமரி (context and memory) ஆகியவற்றிற்கு இடையிலான வேறுபாடு.
டோக்கன்களே உண்மையான நாணயம்
ஒரு டோக்கன் என்பது ஒரு சொல் அல்ல. நீங்கள் ஒரு உரையை மாடலுக்கு அனுப்பும்போது, ஒரு டோக்கனைசர் (tokenizer) அதைச் சிறிய துண்டுகளாக உடைக்கிறது. "cat" அல்லது "the" போன்ற குறுகிய பொதுவான சொற்கள் ஒவ்வொன்றும் ஒரு டோக்கனை நிரப்பலாம். "internationalization" போன்ற ஒரு அடர்த்தியான தொழில்நுட்பச் சொல் பல துண்டுகளாகப் பிரிக்கப்படும். நிறுத்தற்குறிகள், இடைவெளிகள் மற்றும் சிறப்பு எழுத்துக்களும் கணக்கிடப்படுகின்றன. இது முக்கியமானது, ஏனெனில் டோக்கன்கள் அனைத்தையும் தீர்மானிக்கின்றன: உங்கள் API கட்டணம், பதிலளிக்கும் வேகம் மற்றும் வெளியீட்டின் தரம்.
சொற்களை எண்ணி செலவுகளைத் திட்டமிடும் ஒரு டெவலப்பர், எதையும் அறியாமல் செயல்படுகிறார். கோட் பிராக்கெட்ஸ் (code brackets) மற்றும் நீண்ட வேரியபிள் பெயர்கள் (variable names) கொண்ட நூறு சொற்கள் கொண்ட ப்ராம்ப்ட், எதிர்பார்ப்புகளை விட அதிகமாகச் செலவை அதிகரிக்கலாம். அதனால்தான் டோக்கனைசர்கள் தனித்த கருவிகளாக உள்ளன. ஒரு அம்சத்தை வெளியிடுவதற்கு முன், உங்கள் வழக்கமான தரவுகளை (payloads) ஒன்றின் மூலம் இயக்கவும். சிஸ்டம் இன்ஸ்ட்ரக்ஷன்ஸ் (system instructions), ஃபார்மேட்டிங் (formatting) மற்றும் சாட் ஹிஸ்டரி (chat history) ஆகியவை உண்மையான பயனர் வினாவை விட உங்கள் பட்ஜெட்டை அதிகம் பயன்படுத்துவதை நீங்கள் அடிக்கடி கண்டறிவீர்கள். டோக்கன்களை முதல் நாளிலிருந்தே ஒரு அரிய வளமாக (scarce resource) கருதுங்கள்.
கான்டெக்ஸ்ட் விண்டோ என்பது ஒரு நிலையான வைட்போர்டு
கான்டெக்ஸ்ட் விண்டோ என்பது ஒரு கோரிக்கையில் (request) ஒரு மாடல் பார்க்கக்கூடிய மொத்தத் தகவல் அளவு ஆகும். இதை நிலையான அளவுகளைக் கொண்ட ஒரு வைட்போர்டு (whiteboard) போலக் கருதவும். இதில் சிஸ்டம் விதிகள், உரையாடல் வரலாறு, பெறப்பட்ட ஆவணங்கள் மற்றும் தற்போதைய கேள்வி ஆகியவற்றை நிரப்பலாம். ஆனால் மேற்பரப்பு நிரம்பிவிட்டால், ஏதோ ஒன்று மாற வேண்டும். பழைய குறிப்புகள் அழிக்கப்பட வேண்டும், புகைப்படம் எடுக்கப்பட்டு சுருக்கப்பட வேண்டும் அல்லது போர்டு நிரம்பி வழிந்துவிடும்.
நவீன மாடல்கள் சில ஆயிரம் டோக்கன்கள் முதல் பல லட்சம் டோக்கன்கள் வரையிலான கான்டெக்ஸ்ட் விண்டோக்களை விளம்பரப்படுத்துகின்றன. ஒரு பெரிய விண்டோவை வரம்பற்ற சேமிப்பகமாக (unlimited storage) கருதுவது கவர்ச்சிகரமானது. ஆனால் அது இல்லை. வைட்போர்டிற்கு இன்னும் ஓரங்கள் உள்ளன. வரலாறு வரம்பைத் தாண்டும்போது, பயன்பாடு பழைய செய்திகளைத் தவிர்க்க வேண்டும் அல்லது அவற்றைச் சுருக்க வேண்டும். இந்தத் தடையைப் புரிந்துகொள்வது, விண்டோவை ஒரு டேட்டாபேஸ் (database) போலக் கருதாமல், ஒரு செயல்பாட்டுப் பணிப்பரப்பாக (active workspace) கருத உங்களுக்கு உதவும்.
கான்டெக்ஸ்ட் என்பது மெமரி அல்ல
அனுபவம் வாய்ந்த உருவாக்குநர்களையே குழப்பமடையச் செய்யும் ஒரு வேறுபாடு இது. மாடல் தானாகவே 'ஸ்டேட்லெஸ்' (stateless) ஆகும். அது நேற்று, கடந்த வாரம் அல்லது வேறு ஒரு அமர்வில் (session) பத்து நிமிடங்களுக்கு முன்பு நீங்கள் பேசியதை நினைவில் வைத்துக்கொள்ளாது. ஒரு AI உங்களுக்கு Python பிடிக்கும் அல்லது சுருக்கமான பதில்கள் பிடிக்கும் என்பதை நினைவில் வைத்திருப்பது போலத் தோன்றினால், அந்த நினைவாற்றல் அப்ளிகேஷன் லேயரில் (application layer) உள்ளது, மாடலில் இல்லை.
அப்ளிகேஷன் அந்தத் தகவல்களை ஒரு டேட்டாபேஸ், கேச் (cache) அல்லது மெமரி ஸ்டோரில் சேமிக்கிறது. ஒவ்வொரு புதிய கோரிக்கைக்கும், அது தொடர்புடைய ப்ரொஃபைல் தரவை (profile data) மீண்டும் ப்ராம்ப்ட்டில் சேர்க்கிறது. மாடல் முதல் அங்கம் (act one) முதல் தனது வரிகளை உள்ளடக்கிய ஒரு ஸ்கிரிப்டை வாசிக்கிறது. அதற்கு நிலையான சுய அடையாளம் (persistent self) இல்லை. இந்தத் தனித்துவத்தைப் புரிந்துகொண்டால், உங்கள் கட்டமைப்பு (architecture) மாறும். நீங்கள் மாடலை நினைவில் கொள்ளச் சொல்வதை நிறுத்திவிட்டு, சரியான நேரத்தில் சரியான கான்டெக்ஸ்டைப் பெறும் அமைப்புகளை வடிவமைக்கத் தொடங்குவீர்கள்.
ஏன் அதிக கான்டெக்ஸ்ட் எதிர்மறையான விளைவுகளை ஏற்படுத்தும்
அதிக பின்னணித் தகவல் இருந்தால் சிறந்த பதில்கள் கிடைக்கும் என்று பொது அறிவு கூறுகிறது. ஆனால் பெரும்பாலும் அதற்கு நேர்மாறாக நடக்கிறது. அதிகப்படியான கான்டெக்ஸ்ட் இரைச்சலை (noise) உருவாக்குகிறது. உங்களுக்கு ஒரு செயல்பாடு (function) மட்டும் சரிசெய்யத் தேவைப்படும்போது, நீங்கள் ஒரு முழு கோட்பேஸையும் (codebase) மாடலுக்குக் கொடுத்தால், அது சத்தத்திற்குள் சிக்னலைத் தேட வேண்டிய கட்டாயத்திற்குத் தள்ளப்படுகிறது. ஆராய்ச்சியாளர்கள் "Lost in the Middle" விளைவைக் கண்டறிந்துள்ளனர்: மாடல்கள் பெரும்பாலும் ப்ராம்ப்ட்டின் தொடக்கத்திலும் முடிவிலும் உள்ள விவரங்களுக்கு அதிகக் கவனம் செலுத்துகின்றன, அதே நேரத்தில் நடுவில் புதைந்துள்ள தகவல்கள் குறைக்கப்பட்டோ அல்லது புறக்கணிக்கப்பட்டோ போகின்றன. இது நீங்கள் புத்திசாலித்தனமான வார்த்தைகளால் சரிசெய்யக்கூடிய பிழை (bug) அல்ல. இது டிரான்ஸ்பார்மர் அடிப்படையிலான கட்டமைப்புகளில் (transformer-based architectures) உள்ள ஒரு கட்டமைப்பு ரீதியான நடத்தை.
வீணான ப்ராம்ப்ட்கள் உங்கள் செலவையும் நேரத்தையும் பாதிக்கும். ஒவ்வொரு கூடுதல் டோக்கனுக்கும் கணக்கீடு (computation) தேவைப்படுகிறது. லேட்டன்சி (latency) அதிகரிக்கிறது. செலவுகள் உயர்கின்றன. பயனரின் பொறுமை குறைகிறது. தேவையற்ற ஆவணங்களால் நிரப்பப்பட்ட ஒரு ப்ராம்ப்ட் முரண்பாடுகளை உருவாக்குகிறது, மாடலைத் திசைதிருப்புகிறது மற்றும் தவறான சிக்கலில் பதிலளிக்கும் வாய்ப்பை அதிகரிக்கிறது. அளவு (Volume) என்பது துல்லியத்திற்கு (precision) எதிரி.
சிறந்த கான்டெக்ஸ்டை எவ்வாறு வடிவமைப்பது
சிறந்த கான்டெக்ஸ்ட் இன்ஜினியரிங் என்பது மிகக் கடுமையான திருத்தங்களின் (ruthless editing) பயிற்சியாகும். அதை நடைமுறைப்படுத்துவது எப்படி என்பது இதோ.
பணிக்குத் தேவையானதை மட்டும் அனுப்பவும். ஒரு பயனர் உங்கள் ரீஃபண்ட் கொள்கையைப் (refund policy) பற்றி கேட்டால், ஊழியர் கையேடு, API ஆவணங்கள் மற்றும் கடந்த காலாண்டின் மார்க்கெட்டிங் நகல்களைச் சேர்க்க வேண்டாம். விரிவான தகவல்களை விடத் தொடர்புடைய தகவல்களே சிறந்தது.
தொடர்புடைய ஆவணங்களைப் பெற RAG-ஐப் பயன்படுத்தவும். Retrieval-Augmented Generation என்பது ஒரு பெரிய அறிவுத் தளத்தில் தேடவும், மிகச்சரியாகப் பொருந்தும் பகுதிகளை மட்டும் ப்ராம்ப்ட்டிற்குள் (prompt) செலுத்தவும் அனுமதிக்கிறது. ஆயிரம் பக்கங்களைக் கொண்ட கையேட்டை அப்படியே உள்ளிடுவதற்குப் பதிலாக, உங்கள் ஆவணங்களை எம்பெட் (embed) செய்து, பயனரின் வினாவிற்கு எதிராக ஒரு செமாண்டிக் தேடலை (semantic search) நடத்தி, மிகவும் தொடர்புடைய மூன்று பத்திகளை மட்டும் சேர்க்கலாம். இதன் மூலம் மாடலுக்குத் தேவையானவை சரியாகக் கிடைக்கும், மேலும் உங்கள் டோக்கன் பட்ஜெட்டும் (token budget) குறையாமல் இருக்கும்.
பழைய உரையாடல்களைச் சுருக்கவும். முழுமையான சாட் டிரான்ஸ்கிரிப்ட்கள் (chat transcripts) அதிகச் செலவுமிக்கவை மற்றும் குழப்பமானவை. நீண்ட செய்தி வரலாற்றிற்குப் பதிலாகத் தொடர்ச்சியான சுருக்கங்களைப் பயன்படுத்தவும். உதாரணமாக, முப்பது செய்திகளை மாடலுக்குக் கொடுப்பதற்குப் பதிலாக, ஒரு பத்தியைச் சேமித்து வைக்கலாம்: "பயனர் Django deployment பற்றி கேட்டார், static files error ஏற்பட்டது, பின்னர் permissions சரிசெய்யப்பட்டது. தற்போதைய சிக்கல் Postgres 14-இல் database migration தோல்வியடைவதுதான்." அந்தச் சுருக்கம் தேவையற்றத் தகவல்களைச் சேர்க்காமல் சூழலைப் (state) பாதுகாக்கும்.
நீண்ட கால நினைவகத்தை (long-term memory) நேரடி உரையாடலில் இருந்து பிரிக்கவும். பயனர் விருப்பங்கள், திட்ட அமைப்புகள் மற்றும் கணக்கு வரலாறு ஆகியவை ஒரு வெளிப்புற நினைவகச் சேமிப்பகத்தில் (external memory store) இருக்க வேண்டும். அந்தச் சேமிப்பகத்திலிருந்து தேவையானவற்றை மட்டும் தேர்ந்தெடுக்கவும். நேரடி கான்டெக்ஸ்ட் விண்டோ (context window) உடனடிப் பணி மற்றும் தொடர்ச்சியைப் பேணத் தேவையான மிகச் சுருக்கமான தனிப்பட்ட சூழலை மட்டுமே கொண்டிருக்க வேண்டும்.
தயாரிப்பு நிலையில் (production) டோக்கன் பயன்பாட்டைக் கண்காணிக்கவும். லேட்டன்சி அதிகரிப்பு (latency spikes) பெரும்பாலும் கான்டெக்ஸ்ட் அதிகரிப்பால் (context bloat) ஏற்படுகிறது. கோரிக்கைகள் உங்கள் மாடலின் வரம்பை நெருங்கும்போது எச்சரிக்கைகளை (alerts) அமைக்கவும். தேவையற்ற தகவல்களைக் கொண்டு செல்லும் ப்ராம்ப்ட்களைக் கண்டறிய லாக்ஸ்களை (logs) ஆய்வு செய்யவும். ஒவ்வொரு முறையும் ஒரே கேள்வியுடன் உகப்பாக்கம் (optimization) தொடங்குகிறது: பணியைப் பாதிக்காமல் எதை நாம் நீக்க முடியும்?
முக்கியமான கருத்து
சிறந்த AI செயலிகள் மிகப்பெரிய கான்டெக்ஸ்ட் விண்டோக்களைக் கொண்டிருப்பதாலேயே வெற்றி பெறுவதில்லை. அவை கான்டெக்ஸ்ட்டை ஒழுக்கத்துடன் நிர்வகிப்பதாலேயே வெற்றி பெறுகின்றன. ஒரு வைட்போர்டு (whiteboard) கிறுக்கல்களால் நிறைந்திருந்தால் அது பயனற்றது. தகவல்களைத் தேடி எடுக்கும், சுருக்கி வழங்கும் மற்றும் வடிகட்டும் அமைப்புகளை உருவாக்குங்கள். இதன் மூலம் உங்கள் பயனர்களுக்கு விரைவான பதில்கள் கிடைக்கும், உள்கட்டமைப்புச் செலவுகள் கணிக்கக்கூடியதாக இருக்கும், மேலும் உங்கள் மாடல்கள் உண்மையில் முக்கியமான விஷயங்களில் கவனம் செலுத்தும்.
மூலம்: AI Context Engineering: Tokens, Context Windows, & Memory
சமூகம்: GyaanSetu AI on Telegram
