ஏஜென்ட்களின் செயல்திறனை மேம்படுத்த முயலும் பெரும்பாலான செயற்கை நுண்ணறிவுக் குழுக்கள் ஒரே வழிமுறைகளை நாடுகின்றன: பெரிய சூழல் சாளரங்கள், அதிக ஆவணங்கள், திறன்மிக்க ப்ராம்ப்ட்கள். அந்த அணுகுமுறையே முற்றிலும் தவறானது என இந்தக் கட்டுரை வாதிடுகிறது. விடுபட்டிருப்பது கூடுதல் தகவல் அல்ல. அது கட்டுப்பாடு. செயல்விளக்கத்தில் மட்டும் இயங்கும் ஏஜென்டையும், உற்பத்திச் சூழலில் இயங்கும் ஏஜென்டையும் பிரிப்பது நன்கு வடிவமைக்கப்பட்ட கட்டுப்பாட்டு அடுக்குதான்.
செயற்கை நுண்ணறிவு ஏஜென்டுக்குப் பெரிய நினைவகம், அதிக ஆவணங்கள் அல்லது நீண்ட சூழல் சாளரத்தை வழங்குவது அதை மேலும் திறன்மிக்கதாக்காது. மாறாக, மெதுவாகவும் அதிகச் செலவுள்ளதாகவும் ஆக்கும். அனைத்தையும் ஒரே நேரத்தில் பயன்படுத்துவதற்குப் பதிலாக, தனக்கு என்ன தேவை, எப்போது தேவை என்பதைத் தேர்ந்தெடுக்க ஏஜென்டுக்குக் கற்பிப்பதிலிருந்தே உண்மையான முன்னேற்றம் வருகிறது.
நம்பகத்தன்மை மாடலிலிருந்து அல்ல, சுழற்சியிலிருந்து வருகிறது. செயல்விளக்கத்தில் கவரும் ஏஜென்டுக்கும், உற்பத்திச் சூழலில் உறுதியாகச் செயல்படும் ஏஜென்டுக்கும் உள்ள வேறுபாடு செயற்கை நுண்ணறிவின் தரமல்ல. அமைப்பு தனது வேலையைத் தானே சரிபார்க்கிறதா என்பதே வேறுபாடு. ஒவ்வொரு படியிலும் திட்டமிட்டு, செயல்பட்டு, கவனித்து, சரிபார்க்கும் ஏஜென்ட்கள் நம்பிக்கையுடன் தவறு செய்வதற்குப் பதிலாகத் தங்கள் பிழைகளைத் தாங்களே கண்டறிகின்றன.
இன்றைய பெரும்பாலான செயற்கை நுண்ணறிவு ஏஜென்ட்கள் கூடுதல் படிகளைக் கொண்ட அரட்டை நிரல்களே. சரியான பாதையில் செல்கிறோமா, எப்போது நிறுத்துவது, எப்போது வேறு அணுகுமுறையை முயல்வது என்பதை அறியும் எந்த வழிமுறையும் அவற்றிடம் இல்லை. தெளிவான வெற்றி அளவுகோல்கள், கட்டமைக்கப்பட்ட நிலை, செல்லுபடியாக்கச் சோதனைகள் ஆகியவற்றைக் கொண்ட முறையான கட்டுப்பாட்டு அடுக்கே, ஏஜென்ட் போன்ற ஒன்றை உண்மையில் நம்பக்கூடிய அமைப்பாக மாற்றுகிறது.
நேற்று மதிய உணவாக என்ன சாப்பிட்டீர்கள்?
“நேற்று + மதிய உணவு” என்பதை அடையும்வரை, உங்கள் வாழ்வின் ஒவ்வொரு நினைவையும் மீண்டும் நினைத்துப் பார்த்திருக்க மாட்டீர்கள். அந்தக் கருத்துகள் இடம்பெறும் அனுபவப் பகுதிக்கு நேரடியாகச் சென்றிருப்பீர்கள். ஏஜென்ட்களை உருவாக்குவதற்கு இது ஒரு பயனுள்ள மன மாடல்:
மிகப் பெரிய சூழல் சாளரம் நினைவகம் அல்ல.
மீட்டெடுக்கப்பட்ட ஆவணங்களின் குவியல் புரிதல் அல்ல.
நீண்ட செயின்-ஆஃப்-தாட் நம்பகத்தன்மை அல்ல.
அவை மூலப்பொருட்கள் மட்டுமே. ஆனால் ஓர் ஏஜென்டை ஏஜென்டாக உணரவைப்பதும், உங்கள் மூளை வாழ்நாள் வரலாறு முழுவதையும் ஒவ்வொன்றாகத் தேடாமல் இருப்பதற்குக் காரணமாக அமைவதும் ஒன்றுதான்: கட்டுப்பாடு.
சமீபத்திய பெரிய மொழி மாடல்களுக்கான ஏஜென்ட் சார்ந்த ரீஸனிங் என்ற கணக்கெடுப்பு, உருவாக்கப் பணியின்போது நம்மில் பலர் உணர்ந்த மாற்றத்தைச் சிறப்பாகச் சுருக்கி அதற்குப் பெயரிட்டது: மாடலின் உள்ளே ரீஸனிங் செய்வதிலிருந்து, ஊடாடல் வழியாக ரீஸனிங் செய்வதற்கான மாற்றம். இந்தப் பதிவு அந்த ஆய்வுக் கட்டுரையின் சுருக்கமல்ல. அந்த மாற்றத்தை நடைமுறை அமைப்பு வடிவமைப்பாக மாற்றும் முயற்சி இது:
கருவிகளுடன் கூடிய அரட்டை நிரல்களைப் போல ஏஜென்ட்களை உருவாக்கினால், அரட்டை நிரல்களின் தோல்வி முறைகளே தொடரும். ஆனால் பிழைகள் அதிகச் செலவுடையவையாக இருக்கும்.
“மாடலை மேலும் திறன்மிக்கதாக்குவதற்கான” நமது இயல்புநிலைத் திட்டம் நீண்ட காலமாக இதுதான்: சிறந்த ப்ராம்ப்ட்கள், செயின்-ஆஃப்-தாட், சுய-ஒத்திசைவு / மாதிரித் தேர்வு சார்ந்த மேம்பாடுகள், சில நேரங்களில் தேடல்.
“சிந்தனை → செயல் → கவனிப்பு” என்பதை இயல்பானதாக உணரச் செய்ததால், ரீஆக்ட் ஒரு திருப்புமுனையாக அமைந்தது. ஆனால் இதில் மறைந்துள்ள கட்டுப்பாட்டைக் கவனியுங்கள்: இதில் பெரும்பகுதி இன்னும் “அதிக டோக்கன்களுடன் கூடிய ஒன்-ஷாட் அனுமானமாகவே” முடிகிறது. கணக்கெடுப்பின் வரையறை இன்னும் கூர்மையானது. ஏஜென்ட் சார்ந்த ரீஸனிங், சோதனை நேர ஊடாடலை அளவீட்டில் விரிவுபடுத்துவதை வலியுறுத்துகிறது. இதனால் அனுமானம், மாடல், நினைவகம், சூழல் ஆகிய அனைத்தும் சுழற்சியில் தொடர்ந்து இடம்பெறும் மறுசெயல் செயல்முறையாகிறது.
செயல்விளக்கங்களில் கவர்ந்தாலும், நிஜப் பணிப்பாய்வுகளில் எளிதில் சிதையும் ஏஜென்ட்களை நீங்கள் உருவாக்கியிருந்தாலோ பயன்படுத்தியிருந்தாலோ, இது உங்களுக்கானது.
நான் அடிக்கடி கண்ட, நானும் பல வடிவங்களில் நிச்சயமாக உருவாக்கிய ஒரு முறையை விவரிக்கிறேன்:
ஒரு நல்ல அரட்டை மாடலை எடுத்துக்கொள்ளுங்கள்.
சில கருவிகளைச் சேருங்கள்: தேடல், தரவுத்தள வினவல், ஒருவேளை நிரல் இயக்கம்.
மீட்டெடுப்பு-செறிவூட்டப்பட்ட உருவாக்கத்தைச் சேருங்கள்.
“நீ ஒரு தன்னாட்சி ஏஜென்ட்” என்ற அமைப்பு ப்ராம்ப்ட்டைச் சேருங்கள்.
அது நிற்கும்வரை அல்லது நேர வரம்பை எட்டும்வரை, அனைத்தையும் தொடர்ச் சுழற்சிக்குள் இயக்குங்கள்.
வாழ்த்துகள், ஏஜென்ட் போன்ற ஒன்றை உருவாக்கிவிட்டீர்கள். ஆனால் அது முன்கணிக்கக்கூடிய வகைகளில் தோல்வியடைகிறது:
சூழல் வீக்கம்: ஒவ்வொரு கவனிப்பும் சேர்க்கப்படுகிறது. ப்ராம்ப்ட்கள் தொல்லியல் அடுக்குகளைப் போலாகின்றன.
கருவிகளைத் தடுமாறிப் பயன்படுத்துதல்: “தவறான கருவியை நம்பிக்கையுடன் பயன்படுத்துவது” இயல்புநிலைத் தோல்வி முறையாகிறது.
நிறுத்த நிபந்தனைகள் இல்லை: தொடர வேண்டியதற்காக அல்ல, தொடர முடிவதால் அது தொடர்ந்து செயல்படுகிறது.
கிரௌண்டிங் ஒழுங்குமுறை இல்லை: நீங்கள் கட்டாயப்படுத்தாதவரை, தான் தவறாக இருப்பதை அது உணராது.
மெமரி = அரட்டை வரலாறு: இது அடிப்படையில் பதிவுகளை எழுதிவிட்டு, அதைக் கற்றல் என்று அழைப்பதாகும்.
இதனால்தான் “ஏஜென்ட்கள்” செயல்விளக்கங்களில் மாயாஜாலமாகவும், உற்பத்திச் சூழலில் குழப்பமாகவும் தோன்றுகின்றன. ஏஜென்ட் சார்ந்த அமைப்புகளை உற்பத்திச் சூழலில் பயன்படுத்திய எங்கள் அனுபவமும் இதையே காட்டுகிறது. ஒரு மாடலுக்குப் பதிலாக அமைப்பை மதிப்பிடத் தொடங்கியதும், “மாடல் சரியாகப் பதிலளித்ததா” என்பதுடன் தோல்வி முறைகள் முடிவதில்லை. வழிசெலுத்தல், கருவிப் பயன்பாட்டு ஒழுங்கு, சூழல் சுருக்கம், மதிப்பீட்டு வடிவமைப்பு ஆகியவையும் அவற்றில் அடங்கும்.
எனவே கேள்வி இதுதான்: திட்டமிட்ட ஏஜென்ட் என்பது என்ன?
இதை மேலும் தெளிவாக்க, பெரும்பாலானோர் கற்பனை செய்யக்கூடிய ஓர் எளிய பணிப்பாய்வு இதோ: “அடுத்த செவ்வாய்க்கிழமை லண்டனிலிருந்து நியூயார்க்கிற்கு எனக்கு விமானப் பயணத்தை முன்பதிவு செய். மாலை 6 மணிக்கு முன் சென்றடைய வேண்டும். செலவு £900-க்குள் இருக்க வேண்டும். நடைபாதை ஓர இருக்கை வேண்டும்.”
பொதுவான ஓர் “ஏஜென்ட் போன்ற” செயலாக்கம் இவ்வாறு இருக்கும்:
அவை இன்னும் தேவையில்லை என்றாலும், விமான நிறுவன / பயணக் கொள்கை ஆவணங்கள் பலவற்றை உடனடியாக மீட்டெடுக்கும்.
தேடல் கருவியை அழைத்து, முடிவுகளின் நீண்ட பட்டியலை ப்ராம்ப்ட்டில் ஒட்டி, “ஒன்றைத் தேர்ந்தெடுக்கும்.”
கட்டுப்பாடுகளைச் சரிபார்க்காமல், வருகை நேரம் / சுமை / இருக்கை / கொள்கையை உறுதிப்படுத்துவதற்கு முன்பே முன்பதிவு செய்யும்.
தோல்வியடைந்தால், சற்றே மாறுபட்ட வகையில் மீண்டும் முயற்சிக்கும். ஆனால் எது மாறியது அல்லது என்ன கற்றது என்பது குறித்த தெளிவான புரிதல் இருக்காது.
மாடலால் ரீஸனிங் செய்ய முடியாதது தோல்விக்கான காரணமல்ல. பணிப்பாய்வை அமைப்பு கட்டுப்படுத்தாததே காரணம்.
மேலும் ஏஜென்ட் தன்மையுள்ள வடிவம், இப்பணியை வெளிப்படையான நிலையும் சரிபார்ப்புகளும் கொண்ட ஊடாடும் செயல்முறையாகக் கருதுகிறது:
திட்டமிடு: கட்டுப்பாடுகளை மீண்டும் கூறி, விடுபட்ட தகவல்களைப் பட்டியலிடு. எ.கா., “எந்த விமான நிலையத்தை விரும்புகிறீர்கள்?” / “ஒருமுறை இடைநிறுத்துவது ஏற்கத்தக்கதா?”
செயல்படு: கட்டமைக்கப்பட்ட வினவலுடன் விமானத் தேடலை அழை. இதில் தேதிக்கான காலவரம்பு, வருகைக் கட்டுப்பாடு, செலவு வரம்பு ஆகியவை இடம்பெற வேண்டும்.
கவனி: ஒட்டப்பட்ட பெரும் தகவல் குவியலாக இல்லாமல், விலை / வருகை / இடைநிறுத்தங்களுடன் சிறந்த 5 விருப்பங்களைக் கொண்ட சுருக்கமான நிலைப் பொருளில் முடிவுகளைச் சேமி.
புதுப்பி: கட்டுப்பாடுகள் நிறைவேறாவிட்டால் வினவலைச் செம்மைப்படுத்து. எ.கா., “மாலை 6 மணிக்கு முன் வருவது மிகவும் கடுமையான கட்டுப்பாடு. நேர வரம்பை விரிவாக்கலாமா அல்லது செலவு வரம்பை உயர்த்தலாமா?”
சரிபார்: சரிபார்ப்பிகளை இயக்கு: “வருகை < 18:00,” “விலை ≤ £900,” “கொள்கைக்கு இணக்கம்,” “இருக்கையைத் தேர்ந்தெடுக்க முடியும்.”
நிறுத்து: முன்பதிவு இடைமுகம் உறுதிப்படுத்தலை வழங்கி, அனைத்துச் சரிபார்ப்பிகளும் ஏற்றுக்கொண்ட பின்னரே நிறுத்து.
மாற்றம் நுட்பமானது, ஆனால் தீர்மானகரமானது. மீட்டெடுப்பு நிபந்தனைக்குட்பட்டது, இயல்பான எதிர்வினையல்ல. சூழல் நிர்வகிக்கப்படுகிறது, அதாவது நிலை குவிக்கப்படாமல் கட்டமைக்கப்படுகிறது. சரிபார்ப்பு சுழற்சிக்குள்ளேயே உள்ளது, பயனரிடம் விடப்படுவதில்லை. “விமானப் பயணத்தை முன்பதிவு செய்தல்” என்பதற்குப் பதிலாக “கொள்முதல் ஆணையை உருவாக்குதல்,” “பணத்தைத் திருப்பித் தருதல்,” “உற்பத்திச் சூழல் கட்டமைப்பை மாற்றுதல்,” அல்லது “மாற்றக் கோரிக்கையை வெளியிடுதல்” என வைத்தாலும் இதே நிலைதான். ஏஜென்டால் செயல்பட முடிந்ததும், ப்ராம்ப்ட்டைவிடச் சுழற்சியே முக்கியமாகிறது.
மேலே குறிப்பிட்ட கணக்கெடுப்பு, ஏஜென்ட் சார்ந்த ரீஸனிங்கை மூன்று அடுக்குகளாகப் பிரிக்கிறது: அடிப்படை அடுக்கு (திட்டமிடல் / கருவிப் பயன்பாடு / தேடல்), தானே மேம்படும் அடுக்கு (கருத்தளிப்பு + நினைவகம்), கூட்டுச் செயல்பாட்டு அடுக்கு (பல ஏஜென்ட் ஒருங்கிணைப்பு).
ஆனால் ஆழமான கருத்து இதுதான்: நம்பத்தகுந்த செயின்-ஆஃப்-தாட்டை உருவாக்குவதுடன் நின்றுவிடாமல், திட்டமிடல், முடிவெடுத்தல், சரிபார்ப்பு ஆகியவற்றை ஒழுங்கமைக்கும் கோட்பாடாக ரீஸனிங் மாறுகிறது. உங்கள் கட்டமைப்பில் ஏற்படும் மாற்றங்களுடன் இதைப் பொருத்திப் பார்க்கும்வரை இது கருத்தளவில் தெளிவற்றதாகத் தோன்றலாம். நினைவில் கொள்ள வேண்டிய மூன்று முக்கிய அம்சங்கள் உள்ளன:
ஒரு நல்ல ஏஜென்ட் மீட்டெடுப்பை “எப்போதும் செய்” என்பதாகக் கருதக்கூடாது. மீட்டெடுப்பு என்பது முடிவு, இயல்பான எதிர்வினையல்ல.
ஒரு நடைமுறை வழிகாட்டி இதோ:
ஒவ்வொரு முறையும் உங்கள் அமைப்பு தகவலை மீட்டெடுத்தால், நீங்கள் மீட்டெடுப்பு அமைப்பை உருவாக்கவில்லை. சூழல் வரியையே உருவாக்கியுள்ளீர்கள்.
நடைமுறைப் பணியில் இது எப்போதும் நிகழ்கிறது. உற்பத்திச் சூழல் நிகழ்வைப் பிழைநீக்கும்போது அனைத்துப் பதிவுகளையும் சூழலில் கொட்டுவதில்லை. தற்போதைய கருதுகோளின் அடிப்படையில் அடுத்து எந்த அளவீடுகள் / பதிவுகளைப் பெற வேண்டும் என முடிவெடுக்கிறீர்கள். இதுதான் “ஏஜென்ட் சார்ந்த மீட்டெடுப்பு.” மேலும் தெளிவான முறை இதோ:
மீட்டெடுப்பு தேவையா என முடிவெடு.
தேவைப்பட்டால்: வினவலை வரைந்து, தகவலைப் பெற்று, மேலோட்டமாகப் படித்து, தேவையானதைப் பிரித்தெடு.
ஆதாரங்கள் முரண்பட்டால்: மீண்டும் பெறு.
அதன் பிறகே ஒருங்கிணைத்துத் தொகுத்திடு.
“ஏஜென்ட் சார்ந்த மீட்டெடுப்பு-செறிவூட்டப்பட்ட உருவாக்கம்” மரபுவழி மீட்டெடுப்பு-செறிவூட்டப்பட்ட உருவாக்கத்திலிருந்து வேறுபடத் தொடங்குவதும் இங்குதான். மீட்டெடுப்பு இயல்புநிலைச் செயலாக்கப் படியாக இல்லாமல், நோக்கமுள்ள ரீஸனிங் படியாகிறது.
“ஒரு மாடலை” மதிப்பிடுவதை நிறுத்தி, “ஒரு அமைப்பை” மதிப்பிடத் தொடங்கியதும், நிலையைக் கண்காணிப்பதும் தடமறிவதும் முக்கியமாகின்றன.
ஏஜென்ட் பணிப்பாய்வுகளின் கண்காணிப்புத்தன்மை குறித்து இப்போது தொழில்துறை மிகவும் தெளிவாகப் பேசத் தொடங்கியுள்ளது. எடுத்துக்காட்டாக, OpenAI-இன் ஏஜென்ட்கள் மென்பொருள் உருவாக்கத் தொகுப்பில் உள்ளமைந்த தடமறிதலும், ஏஜென்ட் இயக்கங்களைப் பதிவுசெய்யும் தடங்கள் முகப்புப்பலகையும் உள்ளன. இவை உருவாக்கங்கள், கருவி அழைப்புகள், ஒப்படைப்புகள், பாதுகாப்புக் கட்டுப்பாடுகள், தனிப்பயன் நிகழ்வுகள் ஆகியவற்றைப் பதிவுசெய்து, நடந்ததைப் படிப்படியாகப் பிழைநீக்கவும் தணிக்கை செய்யவும் உதவுகின்றன.
அது “இருந்தால் நல்லது” என்ற வசதி அல்ல. பிழைநீக்கக்கூடிய அமைப்புக்கும், மேலோட்டமாக மட்டுமே சரிபார்க்கக்கூடிய அமைப்புக்கும் இடையிலான வேறுபாடு அதுதான்.
என் கருத்தில், கருத்தளிப்பு குறித்துக் கணக்கெடுப்பு நேரடியாகக் கூறுவதே அதில் நடைமுறைக்கு மிகவும் பயனுள்ள பகுதி. இது கருத்தளிப்பை மூன்று வகைகளாகப் பிரிக்கிறது: பிரதிபலிப்புக் கருத்தளிப்பு (உருவாக்கு → விமர்சி → திருத்து), அளவுரு ஏற்பு (நுண்சீரமைப்பு / வலுவூட்டல் கற்றல் வழியாகக் கற்றல்), சரிபார்ப்பி சார்ந்த கருத்தளிப்பு (சரிபார்ப்பி ஏற்கும்வரை மீண்டும் முயற்சித்தல்).
பெரும்பாலான குழுக்கள் சரிபார்ப்பி சார்ந்த கருத்தளிப்பில் தொடங்க வேண்டும். அது சுவாரசியமற்றதாக இருந்தாலும் பயனுள்ளது. அலகுச் சோதனை செய்யும், ஸ்கீமாவைச் சரிபார்க்கும், வணிக விதிகள் / கட்டுப்பாடுகளை அமைக்கும் (“மேல்நிலைக்கு அனுப்பாமல் X-க்கு மேல் பணத்தைத் திருப்பித் தரக்கூடாது”), அல்லது உண்மைத்தன்மையை உறுதிப்படுத்தும் (“மேற்கோள்கள் தேவை”) எந்தவொரு சரிபார்ப்பியையும் உங்களால் எழுத முடிந்தால், நிர்ணயிக்க இயலாத மாடல் வெளியீட்டை உண்மையில் நம்பக்கூடிய ஒன்றாக மாற்றலாம்.
இங்குள்ள “தெரியாதவை இருப்பதே தெரியாத” மாற்றங்களில் ஒன்று எளிமையானது: ஏஜென்ட்களின் உலகில் நம்பகத்தன்மை பெரும்பாலும் மாடலைவிடச் சுழற்சியிலிருந்தே வருகிறது.
பயிற்சியின்றியே செயல்பாட்டை நம்பகமாக மேம்படுத்துவதாக நான் கண்ட மிக எளிய சுழற்சி ஒழுங்குமுறை இதுதான்:
படிப்படியாகச் செயல்படுங்கள்: திட்டமிடு → செயல்படு → கவனி → புதுப்பி.
ஒவ்வொரு செயல்பாட்டுக்குப் பிறகும் கவனிப்பை 1–3 குறிப்புகளில் சுருக்குங்கள்.
வெற்றிக்கான அளவுகோல்கள் நிறைவேறியதும் அல்லது ஒதுக்கீட்டு வரம்பை எட்டியதும் நிறுத்துங்கள். இதுவரை கிடைத்த சிறந்த முடிவையும் மீதமுள்ள நிச்சயமின்மைகளையும் வழங்குங்கள்.
இது மாடலை அதிகமாகப் பேசவைப்பது பற்றியது அல்ல. அமைப்பைப் புரிந்துகொள்ளக்கூடியதாக மாற்றி, ஒவ்வொரு படியிலும் “யதார்த்தத்துடன் தொடர்பை” கட்டாயப்படுத்துவதே இதன் நோக்கம். பொறியாளர்கள் எளிதில் புரிந்துகொள்ளக்கூடிய ஓர் எடுத்துக்காட்டு, தொடர்ச்சியான ஒருங்கிணைப்பு பாணியிலான மூடிய சுழற்சி கிரௌண்டிங்:
திட்டமிடு: மாற்றங்களின் பட்டியலை முன்மொழி.
செயல்படு: சோதனைகள் / நிலைமுறைச் சோதனையை இயக்கு.
கவனி: தோல்விகளைப் பகுப்பாய்.
புதுப்பி: திருத்தமிட்டு மீண்டும் முயற்சி செய்.
தற்செயலாக உருவான ஏஜென்ட் வடிவமைப்புகளை வெளிப்படுத்தும் சில கேள்விகள்:
“எதை மீட்டெடுக்க வேண்டும் என்பதை என் ஏஜென்ட் தேர்வுசெய்கிறதா, அல்லது நான் எப்போதும் மீட்டெடுக்கிறேனா?”
மீட்டெடுப்பு நிபந்தனையற்றதாக இருந்தால், தாமதம், செலவு, சூழல் நீர்த்துப்போதல், தரமற்ற உள்ளீட்டால் தரமற்ற வெளியீடு கிடைக்கும் அதிக ஆபத்து ஆகியவற்றின் விலையைச் செலுத்துவீர்கள்.
“தான் தவறு செய்வதை என் ஏஜென்டால் உணர முடியுமா?”
“பயனர் எரிச்சலடைகிறார்” என்பதே உங்கள் ஏஜென்டின் ஒரே கருத்தளிப்புக் குறியீடாக இருந்தால், மனித வேதனையைக் கொண்டு வலுவூட்டல் கற்றலைச் செய்கிறீர்கள். யதார்த்தத்தைச் சரிபார்க்கும் வாய்ப்பை அதற்கு வழங்க, சரிபார்ப்பி சார்ந்த மறுமுயற்சிச் சுழற்சியே மிகத் தெளிவான வழி.
“நினைவகத்தில் எழுத முடியுமா, காலப்போக்கில் அது மேம்படுகிறதா?”
உங்கள் “நினைவகம்” அரட்டை வரலாற்றைச் சேர்த்துக்கொண்டே இருந்தால், நீங்கள் அடிப்படையில் பதிவுகளையே எழுதுகிறீர்கள். கணக்கெடுப்பு நினைவகத்தைச் சித்தரிக்கும் விதம் முக்கியமானது: நினைவகம் வெறும் உரையாடல் பதிவாக இல்லாமல், ஏஜென்ட்கள் காலப்போக்கில் செம்மைப்படுத்தும், இயக்கநிலையில் வளரும் சூழலாகிறது.
என்ன நடந்தது என்பதைப் பதிவுகள் கூறுகின்றன. அடுத்த முறை என்ன செய்ய வேண்டும் என்பதை நினைவகம் கூறுகிறது. அரட்டை வரலாறு ஓர் உரையாடல் பதிவு. எதை அடுத்தடுத்த பணிகளுக்கு எடுத்துச் செல்வது பயனுள்ளது என்பது பற்றித் தொடர்ந்து மேம்படும் கொள்கையே நினைவகம்.
தொடங்குவதற்கான நடைமுறை வழி, “கற்றுக்கொண்ட பாடங்கள்” என்ற சிறிய அட்டவணை. பணியின் வகை, கருவி, தோல்வி முறை ஆகியவற்றைத் திறவுகோலாகவும், பலனளித்தவை மற்றும் தவிர்க்க வேண்டியவற்றை மதிப்பாகவும் அதில் அமைக்கலாம். கச்சிதமான அறிவு வரைபடத்தை உருவாக்குவது நோக்கமல்ல. பலன் பெருகும் செயல்பாட்டை உருவாக்குவதே நோக்கம்: நினைவகமும் கருத்தளிப்பும் “நிலையற்ற உதவியாளர்களாக” உள்ள ஏஜென்ட்களைக் காலப்போக்கில் மேம்படும் அமைப்புகளாக மாற்றுகின்றன.
சிக்கலைத் தீர்க்க மேலும் பல ஏஜென்ட்களைப் பயன்படுத்தத் தோன்றும். ஆனால் இது பெரும்பாலும் ஒருங்கிணைப்புச் சுமையைப் பல மடங்காக்கும். ஒரு நல்ல “குறைந்தபட்சச் செயல்திறன் கொண்ட குழு” முறை:
ஒருங்கிணைப்பாளர்: பணியைப் பிரித்து ஒதுக்குகிறார்.
செயலாக்குநர்: கருவி அழைப்புகள் / மாற்றங்களைச் செய்கிறார்.
விமர்சகர் / மதிப்பீட்டாளர்: சரியானதா / ஆபத்துள்ளதா எனச் சரிபார்க்கிறார்.
நினைவகப் பராமரிப்பாளர்: பாடங்களை எழுதி / தொகுத்துப் பராமரிக்கிறார்.
ஒவ்வொரு ஏஜென்டின் பொறுப்பையும் உங்களால் விளக்க முடியாவிட்டால், பல ஏஜென்ட்கள் இன்னும் உங்களுக்குத் தேவையில்லை.
இந்தக் கருத்தியல் மாற்றத்தை நாம் உண்மையில் ஏற்றுக்கொண்டால், அனைத்தையும் ப்ராம்ப்ட்களில் திணிப்பதையும், தோல்விகளை இறுதி வெளியீடுகளாகக் கருதுவதையும், ஏஜென்ட்களை அரட்டை நிரல்கள் போல மதிப்பிடுவதையும் நிறுத்துவோம். மேலும், ஏஜென்ட்களை அவற்றின் உண்மையான வடிவிலேயே அணுகத் தொடங்குவோம்: மொழியைக் கட்டுப்பாட்டுத் தளமாகக் கொண்ட மென்பொருள் அமைப்புகள். அவற்றின் நம்பகத்தன்மை சுழற்சியிலிருந்து வருகிறது.
இன்னொரு மாடலைச் சேர்ப்பதற்கு முன், இன்னொரு மதிப்பீட்டுச் சுழற்சியைச் சேருங்கள். அனைத்தையும் மீட்டெடுப்பதற்கு முன், மீட்டெடுப்பை நிபந்தனைக்குட்படுத்துங்கள். பத்து சரிபார்ப்பிகளை வெளியிடுவதற்கு முன், ஒன்றை வெளியிடுங்கள். நினைவகத்தைத் தரவுத்தளமாக அல்ல, கொள்கை முடிவுகளாகக் கருதுங்கள். பல ஏஜென்ட் அமைப்பிற்கு மாறும்போது, இருபது ஏஜென்ட்களுடன் அல்ல, இரண்டு ஏஜென்ட்களுடன் தொடங்குங்கள். இவை விதிகள் அல்ல. உற்பத்திச் சூழலின் சோதனைகளைத் தாண்டி நிலைத்த முறைகள்.