சிந்தனை கேள்விகளுக்கான குறிப்புப் பதில்கள்

இந்தக் கோப்பு புத்தகம் முழுவதும் உள்ள பத்து அத்தியாயங்களின் சிந்தனை கேள்விகளுக்கான குறிப்புப் பதில் அவுட்லைன்களைத் தொகுக்கிறது. சிந்தனை கேள்விகள் பெரும்பாலும் திறந்த-முடிவுக் கேள்விகள்; பதில்கள் ஒன்றுக்கு மேற்பட்டவையாக இருக்கலாம். குறிப்புப் பதில்கள் AI ஆல் உருவாக்கப்பட்டு, மனிதரால் லேசாக மறுஆய்வு செய்யப்பட்டவை; வாசகர்கள் ஒப்பிட்டு உத்வேகம் பெறுவதற்கு மட்டுமே பயன்படுத்தப்பட வேண்டும். புத்தக உள்ளடக்கத்துடன் இணைத்து LLM ஐப் பயன்படுத்தி இந்தக் கேள்விகளை மேலும் விவாதிக்க வாசகர்களைப் பரிந்துரைக்கிறோம்.

அத்தியாயம் 1 AI ஏஜெண்டுகளுடன் தொடங்குதல்

1. (★★) ஒரு ஏஜெண்ட் அமைப்பில் நீங்கள் ஒரே ஒரு திறனை மட்டுமே சேர்க்க முடிந்தால்—வலுவான மாதிரி, வளமான சூழல் அல்லது அதிக கருவிகள்—எதைத் தேர்ந்தெடுப்பீர்கள்? எந்த நிபந்தனைகளின் கீழ் உங்கள் தேர்வு மாறும்?

"மூளை/கண்கள்/கைகளும் கால்களும்" சூத்திரத்துடன் தொடர்புபடுத்தி, முதலில் போத்தல் புள்ளியைக் (bottleneck) கண்டறியவும்: பொதுவாக சூழலை முதலில் நிரப்புவதே முன்னுரிமை, அதாவது கவனிப்பு இடைவெளியை (observation space) விரிவுபடுத்துதல். பணி மாதிரியின் பகுத்தறிவுத் திறனை மீறினால், வலுவான மாதிரிக்கு மாறவும். செயல் இடைவெளி போதாவிட்டால் (எ.கா., நிறுவன உள் அமைப்புகளை அணுக முடியாவிட்டால்), கருவிகளைச் சேர்க்கவும். தீர்ப்பின் அடிப்படை: தோல்விப் பாதைகளைப் பகுப்பாய்வு செய்து, தடை உணர்தலில் உள்ளதா, முடிவெடுப்பதில் உள்ளதா அல்லது செயல்படுத்தலில் உள்ளதா என்பதைக் கண்டறிதல்.

2. (★★★) ReAct சுழற்சியில், ஏஜெண்டின் ஒவ்வொரு LLM அழைப்பும் முழு வரலாற்றுப் பாதையைக் காணும். பாதை வளரும்போது, இந்த வடிவமைப்பின் செலவு இருபடியாக வளர்கிறது. முக்கியமான தகவல்களை இழக்காமல் இந்த இருபடி வளர்ச்சியை உடைக்க ஒரு வழி உள்ளதா?

சாத்தியமான வழிகள்: சூழல் சுருக்கம்—ஆரம்பகாலப் பாதைகளைச் சுருக்கி, முடிவுகள் மற்றும் முக்கிய நிலைகளை மட்டுமே வைத்திருத்தல் (அத்தியாயம் 2 இல் உள்ள பல்அடுக்குச் சுருக்கம்); வெளிப்புறமயமாக்கப்பட்ட கற்றல்—இடைநிலை முடிவுகளைக் கோப்புகள்/அறிவுத் தளத்தில் எழுதி, சூழலில் நிரந்தரமாக வைத்திருக்காமல் தேவைப்படும்போது மீட்டெடுத்தல்; துணை-ஏஜெண்டுகளாகப் பிரித்தல்.

3. (★★) "மாதிரியே ஏஜெண்டாக" முன்னுதாரணம் என்பது மாதிரிகள் கருவி அழைப்பு முடிவுகளில் அதிக தன்னாட்சி பெறுகின்றன என்பதாகும். இருப்பினும், இந்த அத்தியாயம் ஹார்னஸ் பொறியியலின் முக்கியத்துவம் உண்மையில் அதிகரித்து வருவதாக வாதிடுகிறது. இந்த இரண்டு போக்குகளும் எவ்வாறு இணைந்து வாழ முடியும்? ஏஜெண்ட் கட்டமைப்புகளின் எதிர்கால மைய மதிப்பு எங்கே உள்ளது?

குதிரை மற்றும் கடிவாளம் உவமை: மாதிரி எவ்வளவு வலுவாகிறதோ, தன்னாட்சி இடம் எவ்வளவு பெரியதோ, பிழைகளின் தாக்கப் பரப்பும் அவ்வளவு பெரியது, எனவே கட்டுப்பாடு, சரிபார்ப்பு, திருத்தம் ஆகியவை அதிகம் தேவைப்படுகின்றன. கட்டமைப்பின் மதிப்பு "LLM அழைப்புகளை ஒருங்கிணைப்பதில்" இருந்து ஹார்னஸின் ஐந்து கூறுகளில் உள்ள பாதுகாப்பு அடுக்குக்கு மாறுகிறது: அனுமதி வகைப்படுத்தல், சர்க்யூட் பிரேக்கர்கள், பிழை மீட்பு, சூழல் சுருக்கம், கருவி சூழலமைப்பு.

4. (★★) அப்லேஷன் ஆய்வில், "கருவி முடிவு பின்னூட்டம்" இல்லாதது ஏஜெண்டை முடிவில்லா சுழற்சியில் சிக்க வைத்தது. உற்பத்தி சூழலில், கருவி முடிவுகள் இல்லாததைத் தவிர, வேறு என்ன சூழ்நிலைகள் ஏஜெண்டை சுழற்சியில் சிக்க வைக்கும்? நீங்கள் என்ன கண்டறிதல் மற்றும் நிறுத்த வழிமுறைகளை வடிவமைப்பீர்கள்?

பிற காரணங்கள்: கருவி மீண்டும் மீண்டும் ஒரே பிழையைத் தெரிவித்தல், இல்லாத கருவிகளை மாயத்தோற்றத்துடன் அழைத்தல், சூழல் சுருக்கப்பட்டு முக்கிய நிலை இழக்கப்படுதல், சிந்தனைச் செயல்முறை நீக்கப்பட்டு மாதிரி API பிழை தெரிவித்தல், பணியே தீர்வற்றதாக இருத்தல். வழிமுறைகள்: அதிகபட்ச மறுமுறை எண்ணிக்கை போன்ற நிறுத்த நிபந்தனைகளை அமைத்தல்; மீண்டும் மீண்டும் நடக்கும் அழைப்புகளைக் கண்டறிதல் (ஒரே கருவி + அளவுரு கைரேகை); தோல்வி வாசலை மீறும்போது மனித தலையீட்டுக்கு உயர்த்துதல்.

5. (★) இந்த அத்தியாயம் ஐந்து ஏஜெண்ட் தயாரிப்புகளை மூன்று பரிமாணங்களில் பகுப்பாய்வு செய்தது: உணர்தல், செயல் மற்றும் உத்தி. நீங்கள் தினமும் பயன்படுத்தும் ஒரு AI தயாரிப்பைத் தேர்ந்தெடுத்து, இந்த மூன்று பரிமாணங்களைப் பயன்படுத்தி அதை பகுப்பாய்வு செய்து, அதன் கட்டமைப்பு வடிவமைப்பு நியாயமானதா என்பதைக் கவனியுங்கள். நீங்கள் இந்த AI தயாரிப்பை வடிவமைத்தால், என்ன மேம்பாடுகளைச் செய்ய முடியும்?

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

6. (★★) நீங்கள் விமான டிக்கெட் முன்பதிவுக்காக ஒரு வாடிக்கையாளர் சேவை அமைப்பை வடிவமைக்கிறீர்கள் என்றால், நீங்கள் ஒரு பணிப்பாய்வு முறையையா (workflow pattern) அல்லது தன்னாட்சி ஏஜெண்ட் முறையையா (autonomous Agent pattern) தேர்வு செய்வீர்கள்? ஒரே அமைப்பில் இரண்டு முறைகளையும் கலக்க முடியுமா?

முதன்மை அமைப்பு பணிப்பாய்வாக இருக்கட்டும்: அடையாளச் சரிபார்ப்பு → தேடல் → பணம் செலுத்துதல் → முன்பதிவு என்ற நான்கு முனைகள், "பணம் செலுத்துவதற்கு முன் முன்பதிவு செய்யக் கூடாது" போன்ற இணக்க வரிசையை உறுதி செய்கிறது, மேலும் ப்ராம்ப்ட் ஊசிப்பு தாக்குதல் பரப்பை ஒற்றை முனைக்குள் கட்டுப்படுத்துகிறது. திறந்த-முடிவுப் பகுதிகள் (தேவைகளைப் புரிந்துகொள்ளல், மாற்றம் செய்தல், விமானம் ரத்து செய்யப்பட்டால் மாற்று வழிகளைப் பரிந்துரைத்தல்) தன்னாட்சி ஏஜெண்டுக்கு மாறட்டும். அதிக இடருள்ள செயல்பாடுகளுக்கு (பெரிய தொகை பணம் செலுத்துதல், திரும்பப் பணம் வழங்குதல்) மனித உறுதிப்படுத்தலைச் சேர்க்கவும்.

7. (★★★) கார்ட்ரெயில்கள் பிரிவில் கருவி இடர் மதிப்பீடுகள் (tool risk ratings) பற்றி குறிப்பிடப்பட்டிருந்தது. ஒரு கருவி பொதுவாக குறைந்த இடர் கொண்டதாக இருந்தாலும், குறிப்பிட்ட அளவுரு சேர்க்கைகளுடன் (parameter combinations) அதிக இடர் கொண்டதாக மாறினால் (எ.கா., delete_file ஒரு சாதாரண கோப்பை நீக்குவது vs. ஒரு சிஸ்டம் கோப்பை நீக்குவது), நீங்கள் எவ்வாறு மாறும் இடர் மதிப்பீட்டை (dynamic risk assessment) வடிவமைப்பீர்கள்?

மதிப்பீட்டின் இலக்கை "கருவி" யிலிருந்து "கருவி + அளவுருக்கள்" என மேம்படுத்தவும்: அழைப்பு நேரத்தில் மீளமை, அனுமதிகள், தாக்கப் பரப்பு ஆகியவற்றின் அடிப்படையில் இடரைக் கணக்கிடவும். மாதிரி தீர்ப்புக்குப் பதிலாக விதி-அடிப்படையிலான தீர்மானமான சரிபார்ப்புகளைப் (பாதை கருப்பு/வெள்ளைப் பட்டியல்கள், regex) பயன்படுத்தவும். சரிபார்ப்பு கட்டமைக்கப்பட்ட தரவை மட்டுமே பார்க்க வேண்டும், இதனால் ப்ராம்ப்ட் ஊசிப்பால் கையாளப்படுவதைத் தடுக்கலாம்.

8. (★★) இந்த அத்தியாயத்தில் உள்ள ஏஜெண்ட் தயாரிப்பு அட்டவணையில், அனைத்து ஏஜெண்ட்களும் "திறந்த முடிவு" (open-ended) செயல் இடத்தைக் கொண்டுள்ளன. எந்த சூழ்நிலைகளில் ஒரு கட்டுப்படுத்தப்பட்ட செயல் இடம் (constrained action space) (எ.கா., முன் வரையறுக்கப்பட்ட விருப்பங்களிலிருந்து மட்டுமே தேர்வு செய்ய முடியும்) திறந்த முடிவு இடத்தை விட சிறந்ததாக இருக்கும்?

அதிக இணக்கம், அதிக இடர், பிழைகள் மீளமுடியாத சூழ்நிலைகள்: எ.கா., திரும்பப் பணம் வழங்குதல், பணம் செலுத்துதல்—கட்டுப்படுத்தப்பட்ட விருப்பங்களே "கட்டுப்பாடுகள்" ஆகும், இயல்பாகவே பிழை-தடுப்பானவை; வடிவமைப்பின் மூலமே பிழைகள் நடக்காமல் செய்கின்றன.

9. (★★) லூப்பில்-மனிதர் தலையீட்டு (human-in-the-loop) பொறிமுறைக்கு, ஏஜெண்ட் "கட்டுப்பாட்டை நேர்த்தியாக ஒப்படைக்க வேண்டும்" (gracefully hand over control). இருப்பினும், நடைமுறையில், பயனர் ஆஃப்லைனில் இருக்கலாம், மெதுவாக பதிலளிக்கலாம், அல்லது தெளிவற்ற வழிமுறைகளை வழங்கலாம். இதுபோன்ற சந்தர்ப்பங்களில் ஏஜெண்ட் என்ன செய்ய வேண்டும்?

Fail-safe: உறுதிப்படுத்தல் இல்லாதபோது அதிக இடருள்ள செயல்பாடுகளை இயல்புநிலையாகச் செயல்படுத்தாமல் இடைநிறுத்துதல்; முதலில் மீளமையான, குறைந்த இடருள்ள பகுதிகளைச் செய்து, அதிக இடருள்ள பகுதிகளை ஆவணப்படுத்துதல்—மனிதர் முடிவெடுக்கவும் ஏஜெண்ட் மீண்டும் தொடரவும் எளிதாக்குதல்; ஒத்திசைவற்ற தொடர்புக் கருவிகளை (செய்தி, மின்னஞ்சல்) பயன்படுத்தி அறிவித்து காலக்கெடுக் கொள்கையை அமைத்தல்; வழிமுறைகள் தெளிவற்றதாக இருந்தால் நோக்கத் தெளிவுபடுத்தலைப் பயன்படுத்துதல்.

10. (★★★) அறிமுகம் "நல்ல வடிவமைப்புக் கொள்கைகள் மாதிரி மேம்பாட்டுச் சுழற்சிகளை மீறி நிற்க வேண்டும்" என்று கூறுகிறது; ஆனால் அவற்றைச் செயல்படுத்தும் குறிப்பிட்ட பொறியியல் முறைகள் மாதிரிகளின் திறன் மேம்படும்போது வழக்கற்றுப் போகலாம். அத்தகைய ஓர் ஏஜெண்ட் பொறியியல் முறையை எடுத்துக்காட்டி, காரணத்தை விளக்கவும்.

உதாரணம் 1: கருவி அழைப்புகள் கண்டிப்பான வடிவத்தைப் பின்பற்ற கட்டுப்படுத்தப்பட்ட மாதிரித்தலைப் பயன்படுத்துதல். தவறான JSON-ஐ வெளியிடும் அல்லது அளவுருக்களைத் தவறவிடும் மாதிரிகளுக்கான நம்பகத்தன்மைத் திருத்தம் இது. மாதிரிகளின் வடிவப் பின்பற்றல் மேம்படும்போது இதன் பலன் குறையலாம்; இருப்பினும் அதிக இடருள்ள சூழல்களில் நிர்ணயமான வடிவச் சரிபார்ப்பு தொடர வேண்டும்.

உதாரணம் 2: புதிய அறிவைத் தொடர்ந்து உள்வாங்க முடியாத மாதிரியின் குறையை ஈடுசெய்ய வெளிப்புற அறிவுத் தளத்தை அறிமுகப்படுத்துதல். எதிர்காலத்தில் மாதிரிகள் நம்பகமான தொடர்ச்சிக் கற்றலைப் பெற்றால், அறிவுப் பராமரிப்பின் ஒரு பகுதி வெளிப்புற அமைப்பிலிருந்து மாதிரி அளவுருக்களுக்கு நகரலாம். இருந்தாலும் நிகழ்நேரப் புதுப்பிப்பு, துல்லியமான மீட்டெடுப்பு, அணுகல் கட்டுப்பாடு மற்றும் மூலத் தடமறிதல் ஆகியவற்றில் வெளிப்புற அறிவுத் தளங்களுக்கு தனித்த மதிப்பு உண்டு; எனவே அவை முற்றிலும் மறைவதைவிட அவற்றின் பயன்பாட்டு வரம்பே சுருங்கக்கூடும்.

உதாரணம் 3: எல்லாத் திறன்களும் மாதிரி API-யின் நிலையான கருவி அழைப்பு இடைமுகம் வழியாக மட்டுமே வழங்கப்பட வேண்டும் என்றும் தனிப்பயன் அழைப்பு வடிவங்கள் தடைசெய்யப்பட வேண்டும் என்றும் கோருதல். Skills வேறொரு பாதையைக் காட்டுகிறது: திறனையும் அதன் செயல்முறையையும் உரையாக விவரித்து, பொது கட்டளைவரி கருவி வழியாக மாதிரி அதைச் செயல்படுத்த அனுமதிக்கிறது. மாதிரியின் பார்வையில், பொது செயலாக்கியின் மேல் அமைந்த தனிப்பயன் உரை அழைப்பு நெறிமுறையைப் புரிந்து பின்பற்றுவதாகும். எந்தவொரு இடைமுகத்தையும் புரியும் திறன் மேம்படும்போது, "எப்போதும் நிலையான கருவி அழைப்பு வடிவத்தையே பயன்படுத்த வேண்டும்" என்பது உலகளாவிய கொள்கையாக இருக்காது. நிலையான வடிவங்கள் இயங்குதிறன், கட்டமைக்கப்பட்ட சரிபார்ப்பு மற்றும் குறைந்த திறன் கொண்ட மாதிரிகளுக்கு இன்னும் பயனுள்ளவை; ஆனால் அவை சூழலுக்கேற்ற பொறியியல் தேர்வாக இருக்க வேண்டும்.

உதாரணம் 4: ப்ராம்ப்ட்களும் அனைத்து கருவி வரையறைகளும் சூழலின் தொடக்கத்தில் முன்கூட்டியே இருக்க வேண்டும் என்று கோருதல். ஆரம்ப மாதிரிகளின் வழிமுறைப் பின்பற்றும் திறன் குறைவாக இருந்ததால், பழக்கமான நிலையான இடங்களுக்கு வெளியே உள்ள ப்ராம்ப்ட்களையும் கருவி வரையறைகளையும் அவை அடிக்கடி அறியவோ செயல்படுத்தவோ தவறின. Skills தேவைக்கேற்ப ப்ராம்ப்ட்களை சூழலின் நடுவில் ஏற்றுகிறது; இயக்கநிலை கருவிக் கண்டறிதல் புதிய கருவி வரையறைகளை ஏற்கனவே உள்ள பாதைக்குப் பிறகு சேர்க்கிறது. வழிமுறைப் பின்பற்றல் மேம்பட்டு, இத்தகைய இயக்கநிலை ஏற்ற முறைகளுக்காக மாதிரிகள் சிறப்பு பிந்தைய பயிற்சி பெறும்போது, ப்ராம்ப்ட்களும் கருவி வரையறைகளும் சூழலின் தொடக்கத்தில் நிலைத்திருக்க வேண்டியதில்லை.

அத்தியாயம் 2 சூழல் பொறியியல் (Context Engineering)

1. (★★★) சோதனை 2-3, உரையாடல் வரலாற்றின் நெகிழ் சாளரம் (sliding window), ஏஜெண்ட் ஒரே கருவி அழைப்புகளை மீண்டும் மீண்டும் செயல்படுத்தக் காரணமாகிறது என்பதைக் கண்டறிந்தது. இருப்பினும், முழு வரலாற்றையும் வைத்திருப்பது சூழலை காலவரையின்றி விரிவடையச் செய்கிறது. KV கேச் முன்னொட்டை உடைக்காமல், சூழல் நீளத்தைக் கட்டுப்படுத்தும் அதே வேளையில் தகவல் இழப்பைத் தவிர்க்கக்கூடிய ஒரு உத்தியை வடிவமைக்கவும்.

①கைவிடுவதற்குப் பதிலாக சுருக்கம்: செய்திகளைச் சேர்ப்பது மட்டுமே, நீக்குதலோ திருத்துதலோ இல்லை; வாசலை நெருங்கும்போது (எ.கா., சாளரத்தின் 80%) பழைய கருவி முடிவுகளைத் தொகுப்பாகச் சுருக்குதல். ②அடுக்கு வழிமுறை: பெரிய வெளியீடுகளை வட்டில் சேமித்து சுருக்கத்தை வைத்தல், சத்தம் நிறைந்ததை நேரடியாக நீக்குதல், காப்பக-பாணி சுருக்கம் சூழல் தொடர்ச்சியைப் பேணுதல். ③துணை-ஏஜெண்ட் தனிமைப்படுத்தல், இடைநிலை நிலைகள் முதன்மைச் சூழலுக்குள் நுழையாமல் இருத்தல்.

2. (★★) Qwen3 இன் அரட்டை வார்ப்புரு சிந்தனைச் சங்கிலி தக்கவைப்பு பொறிமுறையானது, "கடைசி உண்மையான பயனர் செய்திக்குப் பிறகு" சிந்தனையை மட்டுமே தக்க வைக்கிறது. ஒரு ReAct சுழற்சி நூற்றுக்கணக்கான கருவி அழைப்புகளை உள்ளடக்கியிருந்தால், திரட்டப்பட்ட சிந்தனை உள்ளடக்கம் அதிக அளவு சூழலைப் பயன்படுத்தும். மிக நீண்ட சுழற்சிகளைக் கையாள இந்த பொறிமுறையை எவ்வாறு மாற்றியமைப்பீர்கள்? DeepSeek R1 அனைத்து வரலாற்று சிந்தனையையும் நீக்க வேண்டும் என்று கோரியது, அதே சமயம் DeepSeek V4 அனைத்து reasoning_content ஐயும் கட்டாயமாகத் திருப்பி அனுப்புவதாகத் திருப்பப்பட்டது — இந்த இரண்டு எதிரெதிர் உத்திகளின் நன்மை தீமைகளை ஒப்பிடுக. இந்தத் திருப்பம் எதைக் காட்டுகிறது?

மாற்றியமைக்கும் திசை: நெகிழ் சாளர தக்கவைப்பு—சமீபத்திய சில சுற்றுகளின் சிந்தனையை முழுமையாக வைத்திருத்தல், சாளரத்திற்கு வெளியே டோக்கன் பட்ஜெட்டின் (நிலையான சுற்று எண்ணிக்கை அல்ல) அடிப்படையில் உருளும் சுருக்கத்தைத் தூண்டுதல், கட்டமைக்கப்பட்ட நிலைப் பட்டையை (தற்போதைய இலக்கு, உறுதி செய்யப்பட்ட உண்மைகள், நிராகரிக்கப்பட்ட பாதைகள், செய்ய வேண்டியவை) உருவாக்குதல்; சுருக்கம் ஒரே ஒரு முறையே நடக்கிறது, நிலை நிலையானது, எனவே கேச் மறுகட்டமைப்புச் செலவு ஒரு முறை மட்டுமே, ஒவ்வொரு சுற்றும் அல்ல. R1 நீக்குதல்: டோக்கன்களைச் சேமிக்கிறது, நிலையான முன்னொட்டு கேச்-நட்பானது, பயிற்சி விநியோகத்துடன் ஒத்துப்போகிறது (வரலாற்று CoT ஒருபோதும் உள்ளீட்டில் இல்லை); ஆனால் ஒவ்வொரு சுற்றும் பூஜ்ஜியத்திலிருந்து பகுத்தறிவு செய்கிறது, நீண்ட-காலத் திட்டமிடல் இழக்கப்படுகிறது, ஒரே தவறுகளை மீண்டும் செய்ய எளிது. V4 கட்டாயத் திருப்பி-அனுப்பல்: சிந்தனைத் தொடர்ச்சி, நீண்ட-கால ஏஜெண்டிக் பணிகளில் சிறந்த செயல்திறன்; ஆனால் டோக்கன் செலவு அதிகம், ஒவ்வொரு சுற்றும் முன்னொட்டு விரிவடைகிறது, think-அல்லாத முறையிலிருந்து தடையின்றி மாற முடியாது. திருப்பம் காட்டுவது: தூய உரையாடல் சூழ்நிலைகளில் சிந்தனை கழிவு, ஆனால் ஏஜெண்டிக் சூழ்நிலைகளில் சிந்தனை நிலை—தொழில்துறை நடைமுறை ஏற்கனவே பிந்தையதை நோக்கிச் சாய்ந்துவிட்டது.

3. (★★) சூழல்-உணர்வு சுருக்க பரிசோதனையில், தோராயமாக 148,000 எழுத்துகளில் இருந்து சுமார் 2,000 எழுத்துகளாக சுருக்குவது—இந்த தீவிர சுருக்கம் "மீளமுடியாத தகவல் இழப்பு" அபாயத்தை ஏற்படுத்துமா? இதை எவ்வாறு சமாளிப்பது?

அபாயம் உள்ளது: சுருக்கம் என்பது இழப்புள்ள கோணக் கணிப்பு (lossy projection); கேள்வி பேணப்படாத பரிமாணத்தில் விழுந்தால் முறிந்துவிடும். தீர்வு: "இழப்புள்ள சுருக்கம் + இழப்பற்ற குறியீடு"—ஒவ்வொரு உண்மையும் மூல URL உடன் வருவதால் பின்தடமறியலாம்; அசல் வெளியீட்டை வட்டில் சேமித்து சுருக்க முன்னோட்டத்தை மட்டும் பார்த்தல்; வெளிப்படையான தக்கவைப்பு முன்னுரிமைகள்—கட்டமைப்பு முடிவுகள், சொற்பொருள் ஒருமைப்பாடு (நேரம், நிறுவனப் பெயர்கள்), சரிபார்ப்பு நிலை, UUID/hash போன்ற அடையாளங்காட்டிகள் அப்படியே பேணப்பட வேண்டும்; தகவமைப்புச் சாளரமயமாக்கல் சுருக்க நேரத்தை ஒத்திவைக்கிறது.

4. (★★) ஏஜெண்ட் நிலைப் பட்டை மறைமுக நிலைகளை வெளிப்படையாக்குகிறது. இருப்பினும், நிலைப் பட்டையிலேயே பிழையான தகவல் இருந்தால் (எ.கா., கருவி எண்ணிக்கையில் ஒரு பிழை), ஏஜெண்ட் தவறான தகவலின் அடிப்படையில் தீங்கு விளைவிக்கும் முடிவுகளை எடுக்கலாம். இந்த "மெட்டா-தகவல் நம்பகத்தன்மை" சிக்கலை எவ்வாறு குறைக்கலாம்?

மாதிரி நிலைப் பட்டையைக் கிட்டத்தட்ட நிபந்தனையின்றி நம்புகிறது, பிழைகள் அப்படியே பரப்பப்படுகின்றன. தணிப்பு: ①தீர்மானமான குறியீட்டால் பராமரித்தல், LLM ஐ நீண்ட வரலாற்றைத் தொகுப்பாக எண்ண அனுமதிக்காதிருத்தல் (பயன்படுத்த வேண்டுமென்றால் ஒவ்வொன்றாகப் பிரித்தெடுத்து, குறியீட்டால் தொகுக்கவும்); ②நிலைப் பட்டைத் துல்லியத்தை முதல்-வரிசை உற்பத்தி அளவீடாகக் கண்காணித்தல்; ③தகவல் உண்மையான உலகின் நம்பகமான கவனிப்புகளிலிருந்து மட்டுமே வர வேண்டும், நிலைப் பட்டை நச்சூட்டலைத் தடுத்தல்.

5. (★★) ப்ராம்ப்ட் இன்ஜினியரிங் அப்லேஷன் சோதனையானது, ஒழுங்கற்ற தகவல் வெற்றி விகிதத்தில் 30% க்கும் அதிகமான சரிவை ஏற்படுத்துகிறது என்பதைக் காட்டுகிறது. இருப்பினும், நிஜ உலக மேம்பாட்டில், சிஸ்டம் ப்ராம்ப்ட்கள் பெரும்பாலும் வெவ்வேறு நேரங்களில் பல நபர்களால் பராமரிக்கப்படுகின்றன. சிஸ்டம் ப்ராம்ப்ட்களின் "என்ட்ரோபி அதிகரிப்பை" தடுக்க நீங்கள் என்ன பொறியியல் நடைமுறைகளைப் பயன்படுத்துவீர்கள்?

①ப்ராம்ப்ட்டைக் குறியீடாக நடத்தவும்: பதிப்புக் கட்டுப்பாடு, மறுஆய்வு; தயாரிப்பு மேலாளர்கள் வணிக விதிகளைத் தீர்மானிக்க, பொறியாளர்கள் குறியாக்கத்தைக் கவனிக்க; ②Tau-Bench போன்ற அளவுகோல்களைப் பின்னடைவுச் சோதனைகளாகப் பயன்படுத்தவும், மாற்றங்களுக்கு முன்னும் பின்னும் அப்லேஷன் சோதனைகளை இயக்கி தாக்கத்தைக் கண்டறியவும்; ③கட்டமைப்பைக் கட்டாயப்படுத்தவும்: விதிகளின் குவியலுக்குப் பதிலாக SOP செயல்முறை-உந்துதல், XML/Markdown அடுக்கு; ④துண்டுகளை "கேச் செய்யக்கூடிய / கேசை உடைக்கும்" என வகைப்படுத்திப் பெயரிடவும், மாறும் உள்ளடக்கத்தைக் கேச் எல்லைக்குப் பின் வைக்கவும்; ⑤விரிவடைந்த உள்ளடக்கத்தை Skills ஆகப் பிரித்து தேவைக்கேற்ப ஏற்றவும்.

6. (★★★) இந்த அத்தியாயம் "சூழலில் கற்றல் என்பது அடிப்படையில் மீட்டெடுப்பு, பகுத்தறிவு அல்ல" என்று முன்மொழிகிறது. இந்த கூற்று உண்மையாக இருந்தால், "சூழலில் அதிக தகவலை நிரப்புதல்" அடிப்படையிலான அனைத்து தற்போதைய உகப்பாக்க திசைகளும் மறுமதிப்பீடு செய்யப்பட வேண்டும். இந்த வரம்பை எவ்வாறு சமாளிப்பது என்று நீங்கள் நினைக்கிறீர்கள்?

"பாதி மட்டுமே உள்ள மீட்டெடுப்பு இயந்திரத்திற்கு" ஒரு சுத்திகரிப்பு அடுக்கைச் சேர்க்கவும்: ①சூழல் வடித்தல்/நிலைப் பட்டை, முடிவுகளைக் குறியீட்டால் முன்கூட்டியே கணக்கிட்டு நேரடி மீட்டெடுப்புக்கு வழங்குதல்; ②முனைப்பான சுருக்கம், மூலப் பதிவுகளை அதிக அடர்த்தியான கட்டமைக்கப்பட்ட அறிவாக மாற்றுதல்; ③துணை-ஏஜெண்ட் தனிமைப்படுத்தல், சத்தம் முதன்மைச் சூழலுக்குள் நுழையாமல் தடுத்தல்; ④மூன்றாவது அச்சாக இடைவினை, வெளிப்புறக் கருவிகள் கவனித்து, மாதிரியால் கற்பனை செய்ய முடியாத புதிய தகவலைத் திருப்பி எழுதுதல்; ⑤முன்னணி திசைகள்: திருத்தக்கூடிய, இணைக்கக்கூடிய KV கேச் "குறிப்புகள்", மற்றும் குறுக்கு-அமர்வு நினைவகப் படிவு.

7. (★★★) திறன்களின் படிப்படியான வெளிப்பாடு, ஏஜெண்ட் தேவை என்று மதிப்பிடும்போது மட்டுமே முழு உள்ளடக்கத்தை ஏற்றுகிறது. இருப்பினும், இந்த மதிப்பீடு மாதிரியின் திறனைச் சார்ந்துள்ளது—மாதிரிக்கு தனக்குத் தெரியாதது எது என்று தெரியாவிட்டால், அது ஒரு திறனின் ஏற்றுதலை சரியாகத் தூண்ட முடியாது. இந்த "மெட்டா-அறிவாற்றல்" சிக்கலை எவ்வாறு தீர்ப்பது?

①Skill இன் மெட்டாடேட்டா (பெயர், விளக்கம்) சூழலில் நிரந்தரமாக இருத்தல், மாதிரி எப்போதும் "தன்னிடம் என்ன இருக்கிறது என்பதை அறிய" செய்தல்; ②Skill இன் விளக்கத்தைச் செயல்பாட்டு அறிமுகமாக அல்லாமல் வழித்தட நிபந்தனையாக எழுதவும்: "Use when / Don't use when", பரந்த விளக்கங்களைத் தவிர்க்கவும்.

8. (★★) திறன்கள் பொறிமுறையில், ஏஜெண்ட் SKILL கோப்பிலிருந்து ப்ராம்ப்டை மாறும் வகையில் படித்த பிறகு, அடுத்தடுத்த செயல்பாடுகள் இந்த வழிமுறைகளை சரியாகப் பின்பற்றுமா? திறன்கள் முறைக்கான மாதிரி ஆதரவில் உள்ள வேறுபாடுகள் என்ன?

Skill இன் ஊசிப்பு முறையைப் பொறுத்தது: சிஸ்டம் ப்ராம்ப்டில் ஊசிப்பது வழிமுறை-பின்பற்றலில் மிகவும் வலுவானது ஆனால் KV கேசை உடைக்கிறது; சாதாரண கோப்பாகச் சூழலின் நடுவில் படிக்கப்பட்டால், மாதிரியின் வழிமுறை-பின்பற்றல் மோசமாக இருக்கலாம்; சூழலின் முடிவில் ஊசிப்பது வழிமுறை-பின்பற்றலில் நல்லது, ஆனால் ஒவ்வொரு கருவி அழைப்பிலும் skill பகுதியின் KV ஐ மீண்டும் கணக்கிட வேண்டும், செலவு அதிகம்.

9. (★★★) இந்த அத்தியாயம், மாறும் தகவல்களில் (எ.கா., கணினி நேர முத்திரைகள், கருவி பட்டியல் வரிசை) ஏற்படும் மாற்றங்கள் KV கேச் முன்னொட்டு (prefix) ஹிட்களை உடைக்கக்கூடும் என்பதை வலியுறுத்துகிறது. அதிக எண்ணிக்கையிலான கருவிகள் மற்றும் அடிக்கடி மாறும் கருவித் தொகுப்பைக் கொண்ட ஒரு உற்பத்தி அமைப்பில், கேச் ஹிட் விகிதத்தை அதிகரிக்க சூழல் அமைப்பை (context layout) எவ்வாறு வடிவமைப்பீர்கள்?

①சில நிலையான மையக் கருவிகள் (எ.கா., ஏழு) + பொது நோக்குச் செயல்படுத்தி, குறிப்பிட்ட திறன்கள் Skills மூலம் படிப்படியாக வெளிப்படுத்தப்பட, கருவி வரையறைகள் நிலையான முன்னொட்டில் உறைய வைக்கப்பட்டு, நிலையான வரிசையில் இருக்கும்; ②துணை-ஏஜெண்ட் மற்றும் பெற்றோர் ஏஜெண்ட் முன்னொட்டுகள் ஒத்ததாக வைக்கப்படும்.

அத்தியாயம் 3 பயனர் நினைவகம் மற்றும் அறிவுத் தளம்

1. (★★) ஒரு பயனர் நினைவக அமைப்பில், ஒரே பயனர் வெவ்வேறு அமர்வுகளில் முரண்பட்ட தகவல்களை வழங்கும்போது (எ.கா., இரண்டு வெவ்வேறு வீட்டு முகவரிகளைக் குறிப்பிடுதல்), நினைவக அமைப்பு இந்த முரண்பாட்டை எவ்வாறு கையாள வேண்டும்?

Mem0-பாணி "பிரித்தெடுத்தல்—ஒப்பிடுதல்—முடிவு" குழாயைப் பயன்படுத்தவும்: முதலில் திசையன் மீட்டெடுப்பு மூலம் ஒத்த பழைய நினைவுகளைக் கண்டறிந்து, பின்னர் LLM ADD/UPDATE/DELETE/NOOP எனத் தீர்மானிக்கட்டும்; எ.கா., "ஷாங்காய்க்குக் குடிபெயர்ந்தது" என்பது "பீஜிங்கில் வசிப்பது" என்பதை UPDATE மூலம் மேலெழுத வேண்டும். பதிப்பாக்கம்: முகவரி போன்ற தகவல்கள் சமீபத்திய பதிப்பை மட்டும் வைத்து நேர முத்திரையுடன் குறிக்கப்படும்; பணி அனுபவம் போன்றவை முழு வரலாற்றையும் வைத்திருக்கும். மீட்டெடுப்புப் பக்கம், சூழல் முன்னொட்டை (நபர், நேரம், நோக்கம்—மின் பரிமாற்ற மூன்று மாற்ற வழக்கு போல) பயன்படுத்தி எது இறுதியாகச் செல்லுபடியாகும் எனத் தீர்மானிக்கலாம்.

2. (★★) சூழல் சார்ந்த மீட்டெடுப்பு (Contextual Retrieval) ஒவ்வொரு துண்டுக்கும் அசல் ஆவணத்தின் சூழலை இணைக்கிறது. இருப்பினும், அசல் ஆவணமே கட்டமைப்பு ரீதியாக குழப்பமாக இருந்தால் அல்லது முரண்பட்ட தகவல்களைக் கொண்டிருந்தால், இந்த முறை பிழைகளைப் பரப்பலாம் அல்லது பெருக்கலாம். மீட்டெடுப்பு கட்டத்தில் ஒரு "தகவல் தர" சமிக்ஞையை எவ்வாறு அறிமுகப்படுத்துவீர்கள்?

"அறிவுத் தளக் காலக்கெடு மற்றும் ஆளுகை"யிலிருந்து கற்றுக்கொள்ளவும்: துண்டுகளுக்குப் பதிப்பு எண், செல்லுபடியாகும்/காலாவதியாகும் நேரம், மூலம் போன்ற மெட்டாடேட்டாவை இணைத்து, மீட்டெடுப்பின்போது காலாவதியான உள்ளடக்கத்தை வடிகட்டவும், அல்லது முன்னொட்டில் "இந்த உள்ளீடு இந்தத் தேதியில் ரத்து செய்யப்பட்டது" என வெளிப்படையாகக் குறிக்கவும்; மறு-தரவரிசைக் கட்டத்தில் மூலத்தின் அதிகாரம் மற்றும் நேரப் புதுமையை மதிப்பெண்ணில் சேர்க்கவும், சொற்பொருள் தொடர்பை மட்டும் பார்க்காமல்; குறியீட்டுக் கட்டத்தில், முன்னொட்டை உருவாக்கும் LLM துண்டுகளுக்கிடையேயான முரண்பாடுகளையும் கண்டறிந்து குறிக்கட்டும்—நினைவகத்தின் பதிப்பாக்க முரண்பாட்டுக் கண்டறிதலைப் போல.

3. (★★★) Agentic RAG ஆனது Agent எப்போது தேட வேண்டும், எதைத் தேட வேண்டும், தேடலைத் தொடர வேண்டுமா என்பதைச் சுறுசுறுப்பாக முடிவு செய்ய அனுமதிக்கிறது. ஆனால் மாதிரிக்கு (model) தனக்குத் தெரியாதது எது என்று தெரியாவிட்டால், அது சரியாகத் தேடலைத் தூண்ட முடியாது. இந்த "உயர் அறிவாற்றல்" (metacognition) சிக்கலை எவ்வாறு தீர்க்க முடியும்?

①ப்ராம்ப்ட்/skills இல் "தகவல் போதுமானதா என்பதை மதிப்பிடுதல்" என்பதை வெளிப்படையான படியாக உறுதிப்படுத்தவும்: சோதனை 3-9 இல் உள்ளதுபோல, முதலில் துணை-கேள்விகளை இணையாக மீட்டெடுத்து, "முன் குற்றப் பதிவு தவறான செயல் குற்றத்தின் தண்டனையை எவ்வாறு பாதிக்கிறது" என்ற தொடர்பு காணப்படாததைக் கண்டறிந்து, பின்னர் இரண்டாவது முறை தேடுதல்; ②ஒட்டுமொத்த பார்வையை வழங்க இலகுரக மெட்டா-தகவலைச் சூழலில் நிரந்தரமாக வைக்கவும்: எ.கா., JSON Cards மேலோட்டம், OpenViking இன் L0/L1 சுருக்கங்கள், இதனால் ஏஜெண்ட் "தளத்தில் என்ன இருக்கிறது" என்பதை அறியும்.

4. (★★) பல்லூடக தகவல் பிரித்தெடுத்தல் (multimodal information extraction) மீட்டெடுப்பதற்கு முன் விளக்கப்படங்களை உரை விளக்கங்களாக மாற்றுகிறது. இந்த "மொழிபெயர்ப்பு" செயல்முறை காட்சித் தகவலில் உள்ள இடஞ்சார்ந்த உறவுகளை இழக்க நேரிடலாம். தூய உரை விளக்கம் முழுமையாக வெளிப்படுத்த முடியாத விளக்கப்படத் தகவலின் ஒரு குறிப்பிட்ட உதாரணத்தைக் கொடுத்து, அந்தத் தகவலைப் பாதுகாக்க ஒரு திட்டத்தை வடிவமைக்கவும்.

உதாரணம்: கணினி கட்டமைப்பு வரைபடத்தில் உள்ள தர்க்க உறவுகள், வரைபடத்தில் இரண்டு வளைகோடுகளின் வெட்டுப்புள்ளி இருப்பிடம், அல்லது PDF அட்டவணையில் கலங்கள் மற்றும் தலைப்புகளுக்கு இடையேயான வரிசை-நெடுவரிசை ஒத்ததொடர்பு. திட்டம் ஒன்று: சொந்த பல்லூடகச் செயலாக்கம்; திட்டம் இரண்டு: பல்லூடகப் படப் பகுப்பாய்வுக் கருவியை வழங்குதல்.

5. (★★★) ரிச் சட்டனின் "கசப்பான பாடம்" (Bitter Lesson) என்பது, பொதுவான முறைகள் (தேடல் மற்றும் கற்றல்) இறுதியில் கைவினைப் பண்புகளை (hand-crafted features) விட சிறப்பாக செயல்படும் என்று வாதிடுகிறது. இந்த அத்தியாயத்தில் கட்டமைக்கப்பட்ட முழு அறிவு முறைமையும் (துண்டாக்கல் உத்திகள், குறியீட்டு கட்டமைப்புகள், மீட்டெடுப்பு குழாய்கள்) ஒரு வகையான "கைவினை வடிவமைப்பா"? மாதிரி திறன்கள் போதுமான அளவு வலுவடைந்தால், இந்த வடிவமைப்புகள் "எல்லாவற்றையும் உள்ளீடு செய்வது" மூலம் மாற்றப்பட முடியுமா?

இது உண்மையிலேயே கைவினை வடிவமைப்புதான்; சில கட்டங்கள் (துண்டாக்கல், இணைப்பு இசைவு) நீண்ட சூழலுடன் பலவீனமாகலாம்; ஆனால் கருப்பு-வெள்ளைப் பூனை வழக்கு "எல்லாவற்றையும் உள்ளீடு செய்தலும்" போதாது என்பதைக் காட்டுகிறது: கவனம் என்பது மென்மையான மீட்டெடுப்பு; ஆவணங்களுக்குக் குறுக்கே உள்ள தொகுப்புப் புள்ளிவிவரங்கள் இன்னும் குறியீட்டுக் கட்டத்தில் முன்-சுத்திகரிப்பு தேவை; அறிவின் காலாவதி புதுப்பிப்புகள், அனுமதி/குத்தகைதாரர் தனிமைப்படுத்தல், தணிக்கைத்தன்மை, செலவு ஆகிய பொறியியல் கட்டுப்பாடுகள் மாதிரி திறனுடன் தொடர்பில்லாதவை; மேலும் மீட்டெடுப்பு மற்றும் குறியீட்டுக் கட்ட LLM சுத்திகரிப்பு அவற்றே "தேடல் + கற்றல்" என்ற பொதுவான முறைகள், கசப்பான பாடத்திற்கு எதிரானவை அல்ல.

6. (★★★) மாதிரி திறன்கள் மேம்படும்போது, களம் சார்ந்த அறிவுத் தளங்கள் (domain-specific knowledge bases) இன்னும் முக்கியமானதாக இருக்குமா என்று நீங்கள் நினைக்கிறீர்களா? எதிர்காலத்தில் ஒரு சக்திவாய்ந்த அடித்தள மாதிரியானது (foundation model) ஒரு கள அறிவுத் தளத்தில் உள்ள அனைத்து தகவல்களையும் கொண்டிருக்க முடியுமா, இதனால் அதன் தேவை நீங்குமா?

இன்னும் முக்கியம்: பயிற்சித் தரவுக்கு ஒரு தேதி வரம்பு உள்ளது, அறிவுத் தளத்தை எப்போது வேண்டுமானாலும் புதுப்பிக்கலாம்; நிறுவன உள் செயல்முறைகள், தனிப்பட்ட முன்னுதாரணங்கள் போன்றவை பொது கார்பஸில் இல்லவே இல்லை; பல பயனர் பகிர்வுக்கு அனுமதி வடிப்பானும் குத்தகைதாரர் தனிமைப்படுத்தலும் தேவை, அளவுருக்களில் உள்ள அறிவை அழைப்பவருக்கு ஏற்ப வெட்ட முடியாது; வெளிப்புறச் சேமிப்பு தணிக்கை செய்யக்கூடியது, பதிப்புக் கட்டுப்படுத்தக்கூடியது, காலாவதியான உள்ளடக்கத்தை அகற்றக்கூடியது—அளவுரு நினைவகம் இதைச் செய்யக் கடினம்; அளவுருவாக்கப்பட்ட பாதையைத் தேர்ந்தாலும் (பிந்தைய பயிற்சி / User as Engram), "நினைவில் வைத்திருப்பது எளிது, பல-ஹாப் பகுத்தறிவுக்குப் பயன்படுத்துவது கடினம்" என்ற சிக்கலை எதிர்கொள்கிறது.

7. (★) RAPTOR ஆனது கீழிருந்து மேல் படிநிலை சுருக்கம் (bottom-up hierarchical summarization) மூலம் ஒரு மர குறியீட்டை (tree index) உருவாக்குகிறது, அதே நேரத்தில் GraphRAG ஆனது நிறுவன உறவுகள் (entity relationships) மூலம் ஒரு வரைபட கட்டமைக்கப்பட்ட குறியீட்டை (graph-structured index) உருவாக்குகிறது. இந்த இரண்டு கட்டமைக்கப்பட்ட குறியீடுகளும் எந்த வகையான வினாக்களுக்கு பதிலளிப்பதில் ஒவ்வொன்றும் சிறந்து விளங்குகின்றன?

RAPTOR: பெரிய கருத்துக்களிலிருந்து விவரங்களுக்குக் கொண்டு செல்லும் "அடுக்குகளுக்குக் குறுக்கே பயணம்" செய்யும் வினாக்கள், எ.கா., முதலில் "SIMD அறிவுறுத்தல்த் தொகுப்பு" சுருக்கத்தைக் கண்டறிந்து பின்னர் SSE விவரங்களுக்குச் செல்லுதல், மேலோட்டம் மற்றும் விவரம் இரண்டு தரலைகளையும் கவனித்தல். GraphRAG: பல-ஹாப் உறவுப் பகுத்தறிவு ("என் மருத்துவர் பணிபுரியும் மருத்துவமனையின் முகவரி" உறவுச் சங்கிலியைத் தொடர்தல்) மற்றும் நிறுவன விரிவாக்கம் (இரண்டு "டாக்டர் சாங்" வெவ்வேறு முனைகள்) போன்ற "A-க்கும் B-க்கும் என்ன உறவு" வகை வினாக்கள்; சமூக சுருக்கங்கள் தலைப்புக் கொத்தமைப்பையும் வழங்குகின்றன.

8. (★★) கோப்பு முறைமை முன்னுதாரணம் (filesystem paradigm) அறிவை ஒரு கோப்பு முறைமையைப் போன்ற படிநிலை கட்டமைப்பில் (hierarchical structure) ஒழுங்கமைக்கிறது. பாரம்பரிய திசையன் தரவுத்தள RAG (vector database RAG) உடன் ஒப்பிடும்போது, எந்த சூழ்நிலைகளில் இந்த அணுகுமுறை ஒரு நன்மையைக் கொண்டுள்ளது?

தூய உரையைப் பயனர்கள் நேரடியாகப் படிக்க, திருத்த, சரிசெய்ய முடியும்; Git பதிப்புக் கட்டுப்பாடு மற்றும் திரும்பப் பெறல் சாத்தியம்—மனிதர்-இயந்திரம் இணைந்து அறிவைப் பராமரித்துத் தணிக்கை செய்ய வேண்டிய சூழ்நிலைகளுக்கு ஏற்றது; ஏஜெண்டிடம் write_file திறன் இருந்தாலே அனுபவத்தைத் தானாகப் பதிவு செய்ய முடியும், நினைவக சுய-பரிணாமச் சுழற்சியை உருவாக்குதல் (வெளிப்புறமயமாக்கப்பட்ட கற்றல்); L0/L1/L2 படிப்படியான வெளிப்பாடு பெரும்பாலான வினாக்களுக்கு L1 வரை சென்றாலே முடிவு செய்யப் போதும், டோக்கன்களைச் சேமிக்கிறது; முன்நிபந்தனை: Wikipedia போலக் குறுக்கு-இணைப்புகள் மற்றும் குறியீட்டுப் பக்கங்களை உருவாக்க வேண்டும், இல்லையெனில் தனிமைப்படுத்தப்பட்ட கோப்புகள் அதிகரிக்கும்போது மீட்டெடுப்பது கடினமாகும்.

9. (★★★) கட்டமைக்கப்பட்ட தரவுகளிலிருந்து (எ.கா., நீதித்துறை தீர்ப்பு தரவுத்தளங்கள்) "தீர்ப்பு காரணிகள்" மற்றும் "காரணி முக்கியத்துவ படிநிலைகளை" தானாக கண்டுபிடிப்பது, அடிப்படையில் ஏஜெண்ட் தரவுகளிலிருந்து விதிகளைத் தூண்டுவதை (inducing rules) உள்ளடக்கியது. இந்த தரவு உந்துதல் அறிவு பிரித்தெடுத்தல் (data-driven knowledge extraction) மனித நிபுணர்களால் கைவினையாக வடிவமைக்கப்பட்ட விதிகளின் தரத்தை அடைய முடியுமா?

நன்மைகள்: CAIL2018 சோதனையில் உள்ளதுபோல, "கீழிருந்து மேல்" காரணி கண்டுபிடிப்பு மனித முன்னுரிமைகளை விடத் தரவுக்கு நெருக்கமாகப் பொருந்துகிறது, ஆயிரக்கணக்கான தீர்ப்புகளில் சிதறிக்கிடக்கும், நிபுணர்களால் வெளிப்படையாக எழுத முடியாத மறைமுக எடைபோட்டு அனுபவத்தைப் பிடிக்க முடியும், மேலும் அதை அளவிட முடியும். வரம்புகள்: LLM பிரித்தெடுப்பதில் பிழைகள் அறிவு மாசுபாட்டை ஏற்படுத்தும்; தரவிலுள்ள சார்புகள் பரம்பரைப்படும்; கொத்தமைப்பு முன்மாதிரிகள் தொடர்பை மட்டும் பிரதிபலிக்கின்றன, காரணத்தை விளக்க முடியாது. சமரசம்: தரவு-உந்துதல் மாதிரியமைத்தல் + நிபுணர்கள் Schema மற்றும் முடிவுகளை மறுஆய்வு செய்தல்; மாதிரி கேள்விகளை எழுப்ப, புள்ளிவிவரங்கள் விளக்கங்களை ஆதரிக்கட்டும்.

அத்தியாயம் 4 கருவிகள்

1. (★★) MCP தரநிலையானது கருவி வரையறைகளை ஏஜெண்ட் கட்டமைப்பிலிருந்து பிரிக்கிறது. இருப்பினும், தரநிலைப்படுத்தல் என்பது சிக்கலான கருவி தொடர்பு முறைகளை (எ.கா., ஸ்ட்ரீமிங் வெளியீடு, இருதரப்பு தொடர்பு, நிலைமை அமர்வுகள்) ஒரு நிலையான நெறிமுறையில் வெளிப்படுத்துவது கடினமாக இருக்கலாம் என்பதையும் குறிக்கிறது. எதிர்காலத்தில் MCP எந்த திறனை மிகவும் விரிவுபடுத்த வேண்டும் என்று நீங்கள் நினைக்கிறீர்கள்?

மிகவும் தேவையான விரிவாக்கம் அமர்வுகளைக் கடந்த நிகழ்வு-உந்துதல் திறன். MCP ஏற்கனவே பல சுற்றுத் தொடர்புகள், மாற்றச் சந்தாக்கள் மற்றும் நீண்ட நேரப் பணிகளை ஆதரிக்கிறது. ஆனால் அதன் மைய நோக்கம் ஏஜெண்டை எப்போதும் ஆன்லைனில் வைத்திருப்பது அல்ல; ஒரு திறன் அழைப்பைத் தரப்படுத்துவதாகும். புதிய மின்னஞ்சல் அல்லது வெளிப்புற callback காரணமாக ஏஜெண்டை எழுப்புதல், பல நிகழ்வுகளை வரிசைப்படுத்துதல், தொடர்தல் மற்றும் மீண்டும் முயற்சித்தல் ஆகியவை ஏஜெண்ட் கட்டமைப்பின் பொறுப்பாகவே உள்ளன. இந்த ஒருங்கிணைப்புக்கான ஒரே மாதிரியான மரபுகள், நெறிமுறையின் எளிமையை இழக்காமல் MCP-யின் பயன்பாட்டை விரிவாக்கும்.

2. (★★) ஒரு ஒத்திசைவற்ற ஏஜெண்ட் கட்டமைப்பில், நிகழ்வு வரிசைக்கான முன்னுரிமை உத்தி வடிவமைப்பு நேரத்தில் தீர்மானிக்கப்பட வேண்டும். ஆனால் முன்னுரிமை தீர்ப்புக்கு சொற்பொருள் புரிதல் தேவைப்பட்டால் (எ.கா., ஒரு புதிய செய்தி தற்போதைய பணியை விட அவசரமானதா என்பதை தீர்மானித்தல்), இந்த தீர்ப்பை யார் செய்ய வேண்டும்—ஒரு விதிகள் இயந்திரமா அல்லது மற்றொரு LLM அழைப்பா? ஒவ்வொன்றின் செலவுகள் என்ன?

அடுக்குக் கலப்பு: நிகழ்வு வகை தெளிவானவற்றை விதிகளால் கடினமாகக் குறியாக்கம் செய்யவும்—பூஜ்ஜிய தாமதம், வலுவான தீர்மானத்தன்மை, ஆனால் "உடனே நிறுத்து" மற்றும் "இன்று வானிலை எப்படி" இடையிலான சொற்பொருள் வேறுபாட்டைப் புரிந்துகொள்ள முடியாது; சொற்பொருள் ரீதியாகத் தெளிவற்றவற்றை இலகுரக வகைப்படுத்தும் LLM க்கு நிகழ்வு வழித்தடியாகக் கொடுக்கவும்—செலவு: நூற்றுக்கணக்கான மில்லிவினாடி தாமதம், கூடுதல் கட்டணம், தவறாக வகைப்படுத்தக்கூடும், மேலும் Sidecar போலக் கட்டமைக்கப்பட்ட புலங்களை மட்டும் வாசித்துப் ப்ராம்ப்ட் ஊசிப்பைத் தடுக்க வேண்டும்.

3. (★★) MCP சூழலமைப்பில், வெவ்வேறு MCP சேவையகங்கள் அதிக அளவில் ஒன்றுடன் ஒன்று சேரும் செயல்பாடுகளைக் கொண்ட கருவிகளை வழங்கலாம். ஒரு ஏஜெண்ட் வெவ்வேறு மூலங்களிலிருந்து செயல்பாட்டு ரீதியாக ஒத்த பல கருவிகளை எதிர்கொள்ளும்போது, அது எவ்வாறு தேர்வு செய்ய வேண்டும்? வெவ்வேறு மூலங்களிலிருந்து ஒரே பெயர் கொண்ட கருவிகள் சற்று வித்தியாசமாக செயல்பட்டால் (எ.கா., ஒன்று சுருக்கத்தைத் தருகிறது, மற்றொன்று முழு உரையைத் தருகிறது), ஏஜெண்ட் இந்த வேறுபாட்டை உணர்ந்து பயன்படுத்த முடியுமா?

தேர்வு அடிப்படைகள்: இணைப்பதற்கு முன் விளக்கங்களை மறுஆய்வு செய்தல், பதிப்புகளைப் பூட்டுதல், குறைந்தபட்ச அனுமதி நற்சான்றிதழ்களை உள்ளமைத்தல்; ஒரே பெயருடைய கருவி மறைத்தல் (tool shadowing) உணர்வூட்டும் அழைப்புகளைத் தீங்கிழைக்கும் தரப்புக்கு வழிமாற்றுவதைப் பற்றி எச்சரிக்கையாக இருத்தல்; இயக்க நேரத்தில் படிநிலை வகைப்படுத்தல் மற்றும் மாறும் கண்டுபிடிப்பு மூலம் வேட்பாளர்களைக் குறைத்தல். மாதிரியால் வேறுபாடுகளை உணர முடியுமா என்பது கருவி விளக்கங்களின் தரத்தைப் பொறுத்தது.

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

இயல்பாக மெய்நிகர் அடையாளம்: பின்னணி தன்னாட்சி செயல்பாடு, தணிக்கை செய்யக்கூடியது, பிழை அல்லது ஊடுருவல் ஏற்பட்டால் பயனரின் முழு டிஜிட்டல் அடையாளமும் வெளிப்படாது—செயலாளர் தன் சொந்த அலுவலக மின்னஞ்சலைப் பயன்படுத்துவது போல; CAPTCHA/IP புகழ் பிரச்சினைகளைக் கையாள வேண்டும் (குடியிருப்புப் ப்ராக்ஸிகள்). கட்டாயமாக உண்மையான அடையாளம் தேவைப்படும் சூழ்நிலைகளில் (கணக்கு அடையாளச் சரிபார்ப்பு, மூன்று-தரப்பு அழைப்பு உறுதிப்படுத்தல், எ.கா., Pine வாடிக்கையாளர் சேவைக்கு அழைப்பது) Human-in-the-loop அங்கீகாரத்தைப் பயன்படுத்தவும்: VNC/RDP மூலம் பயனர் காட்சி ரீதியாகத் தானே உள்நுழையட்டும். தீர்ப்பு அளவுகோல்: எதிர்தரப்பு கணக்கு உரிமையாளரையே கோருகிறதா, செயல்பாட்டின் இடர் மற்றும் நற்சான்றிதழ் வரம்பு.

5. (★★) வரிசை அடிப்படையிலான நிகழ்வு செயலாக்கத்தில், மாதிரிகள் கடைசி நிகழ்வில் மட்டுமே கவனம் செலுத்த முனைகின்றன. இந்த அத்தியாயம் ஏஜெண்ட் நிலைப் பட்டி குறிப்பான்கள் மற்றும் சுருக்கம் மூலம் இதைத் தணிக்கிறது. ஆனால் வரிசையில் 20 நிகழ்வுகள் (10 கருவி முடிவுகள் + 5 பயனர் செய்திகள் + 5 கணினி எச்சரிக்கைகள்) குவிந்திருந்தால், மாதிரி முக்கிய தகவலைத் தவறவிடாமல் இருக்க இந்த நிகழ்வுகளின் விளக்கக்காட்சி வரிசை மற்றும் வடிவமைப்பை எவ்வாறு ஒழுங்கமைப்பீர்கள்?

முதலில் விதிகள் மற்றும் இலகுரக LLM வகைப்படுத்தல் மூலம் நகல்களை நீக்கவும்: அவசர நிகழ்வுகள் (எச்சரிக்கைகள், பயனர் குறுக்கீடுகள்) தனியாக ரத்து-பாணி கையாளுதலுக்குச் செல்லட்டும், தொகுப்பில் கலக்க வேண்டாம். மிக நீளமான 10 கருவி முடிவுகளைத் துண்டித்துக் கோப்புகளில் நிலைநிறுத்தி, தொடக்கம், முடிவு மற்றும் பாதையை மட்டும் வைக்கவும். சூழலின் முடிவில் உள்ள கணினி நிலைப் பட்டையில் ஒரு சுருக்கப் பட்டியலைச் சேர்க்கவும் (ஒவ்வொரு நிகழ்வு வகையின் எண்ணிக்கை + ஒவ்வொன்றுக்கும் தனித்தனியாகப் பதிலளிக்க வேண்டிய தேவை).

6. (★★) இந்த அத்தியாயம் "செயல்படுத்து-சரிபார்-பின்னூட்டம்" சுழற்சியை முன்மொழிகிறது (எ.கா., குறியீடு எழுதிய பின் தானாகவே ஒரு லிண்டரை இயக்குதல்). இந்த "உடனடி செயல்பாட்டுக்குப் பிந்தைய தானியங்கி சரிபார்ப்பு" முறை வேறு எந்த கருவி சூழ்நிலைகளுக்குப் பயன்படுத்தப்படலாம்? சரிபார்ப்பின் செலவு அல்லது ஆபத்து செயல்பாட்டின் செலவை விட அதிகமாக இருந்து, இந்த முறை சாத்தியமில்லாத செயல்பாடுகள் ஏதேனும் உள்ளதா?

பொதுமைப்படுத்தக்கூடிய சூழ்நிலைகள்: உள்ளமைவை மாற்றிய பின் சாண்ட்பாக்ஸில் உண்மையாக இயக்கி செயல்படுகிறதா எனச் சரிபார்த்தல்; ஆவணம்/விளக்கக்காட்சி உருவாக்கிய பின் திரைப்பிடிப்புகளாக ரெண்டர் செய்து, மாதிரியின் பல்லூடகத் திறனைப் பயன்படுத்தி வடிவமைப்பைச் சரிபார்த்தல். சாத்தியமில்லாதவை: மின்னஞ்சல் அனுப்புதல், தொலைபேசி அழைப்பு, வெளிப்புறப் பணப் பரிமாற்றம் போன்ற மீளமுடியாத, மீள்செயல்முறையற்ற (non-idempotent) செயல்பாடுகள்: கவனிக்கவே முடியாது அல்லது உண்மையான உலக நிகழ்வை மீண்டும் தூண்டும்; இங்கு முன்கூட்டிய நடவடிக்கைகளைப் பயன்படுத்த வேண்டும்: முன்மொழிபவர்-மதிப்பாய்வாளர் முன்-ஒப்புதல்.

7. (★★) இந்த அத்தியாயம் "கருவி வெடிப்பு" (tool explosion) பிரச்சினையை எழுப்புகிறது—ஆயிரக்கணக்கான கருவிகளை எதிர்கொள்ளும்போது ஏஜெண்டின் தேர்வுத் துல்லியம் குறைகிறது. முனைப்பான கருவி கண்டுபிடிப்பைத் தவிர, வேறு என்ன தீர்வுகள் உள்ளன? அதிக எண்ணிக்கையிலான கிடைக்கக்கூடிய கருவிகளை எதிர்கொள்ளும்போது மனித நிபுணர்கள் பயன்படுத்தும் உத்திகளை நீங்கள் குறிப்பிடலாம்.

①படிநிலைக் குழுவாக்கம்: முதலில் "சேவையகம்/ஆப்" ஐக் கண்டறிந்து பின்னர் குறிப்பிட்ட கருவியைத் தேர்ந்தெடுத்தல்; ②Skills-பாணி "தேவைக்கேற்ப ஆலோசித்தல்": கருவி நூலைத் திறப்பது போல, அடக்கம் சூழலில் நிரந்தரமாகவும் விவரங்கள் தேவைக்கேற்ப ஏற்றப்படவும்; ③சில அடிக்கடி பயன்படுத்தும் அடிப்படைக் கருவிகள் "கையருகில்" சூழலில் நிரந்தரமாகவும், மீதமுள்ளவை அடக்கக் குறியீடு வழியாகவும்.

அத்தியாயம் 5 குறியீட்டு ஏஜெண்ட் மற்றும் குறியீடு உருவாக்கம்

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

சாண்ட்பாக்ஸ் சூழ்நிலைவாரியாக அடுக்குத் தனிமைப்படுத்தல் (கண்டெய்னர்/microVM); நெட்வொர்க் இயல்பாகத் துண்டிக்கப்பட்டு, வெள்ளைப் பட்டியல் ப்ராக்ஸி மூலம் தேவைக்கேற்ப அனுமதித்தல்; மூலக் குறியீட்டை வாசிப்பு-மட்டும் மவுண்ட் செய்தல், API key களைச் சாண்ட்பாக்ஸுக்குள் வைக்காமல் இருத்தல்; சாண்ட்பாக்ஸ் வள வரம்புகள்; சாண்ட்பாக்ஸ் வாழ்க்கைச் சுழற்சி நிர்வாகம் (காலக்கெடு).

2. (★★★) ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்—ஏஜெண்டுகளை உருவாக்கக்கூடிய ஒரு ஏஜெண்ட்—"நுண்ணறிவின் சுய-நகலாக்கத்தை" அடைகிறது. இருப்பினும், ஒவ்வொரு பூட்ஸ்ட்ராப்பிங் மறுமுறையும் புதிய சார்புகள் அல்லது பிழைகளை அறிமுகப்படுத்தலாம். இந்த பிழைகள் தலைமுறைகள் முழுவதும் குவிந்துவிடுமா? ஏஜெண்ட் பூட்ஸ்ட்ராப்பிங்கின் சிதைவை எவ்வாறு தடுப்பது?

ஒவ்வொரு தலைமுறையும் முந்தைய தலைமுறையின் விளைபொருளில் தொடர்ந்து இனப்பெருக்கம் செய்தால், சில குறைபாடுகள் குவியலாம். முக்கியமானது போதுமான சவாலான சரிபார்க்கக்கூடிய பணி (verifiable task) இருப்பது, எ.கா., போதுமான கடினமான நிரலாக்கப் பணிகள்.

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

தகவமைப்பதற்கு முன் நோய்கண்டறிதல்: கட்டமைப்பு ஆவணங்கள் மற்றும் PRD உடன் ஒப்பிட்டுப் புதிய வடிவம் எதிர்பார்க்கப்பட்டதா எனத் தீர்மானித்தல் (சோதனை 5-8 இன் அணுகுமுறை); பதிப்புக் கட்டுப்பாட்டுப் பதிவுகளைச் சரிபார்த்து, மாற்றம் சட்டபூர்வமான குறியீட்டுச் சமர்ப்பிப்புடன் தொடர்புடையதா அல்லது மூலமற்ற மாற்றமா என உறுதிப்படுத்துதல்; τ-bench இன் log_mismatch ஐ ஒப்பிட்டுப் பார்த்து, தகவமைத்தாலும் எச்சரிக்கையைப் பதிவு செய்து தானாகவே issue உருவாக்குதல், அமைதியாக இணக்கமாகாமல் இருத்தல்; நிச்சயமில்லாதபோது மனிதர்-சுழற்சியில் உறுதிப்படுத்தலுக்குச் செல்லுதல். கொள்கை: தகவமைப்பும் அறிக்கையிடலும் இணையாக நடக்க வேண்டும்; தகவமைப்பு முரண்பாட்டுச் சமிக்ஞையை விழுங்கக்கூடாது.

4. (★★) இந்த அத்தியாயம் PPT உருவாக்கம், வீடியோ எடிட்டிங் மற்றும் பதிவு காட்சிப்படுத்தலில் முன்மொழிபவர்-மதிப்பாய்வாளர் பொறிமுறையை மீண்டும் மீண்டும் பயன்படுத்துகிறது. மதிப்பாய்வாளரின் அழகியல் விருப்பங்கள் இலக்கு பயனரிடமிருந்து வேறுபட்டால்—எடுத்துக்காட்டாக, மதிப்பாய்வாளர் தகவல் அடர்த்தியை நியாயமானதாகக் கருதினால், ஆனால் பயனர் அதை மிகவும் நெரிசலானதாகக் கண்டால்—பின்னூட்ட வளையம் தவறான உள்ளூர் உகந்த நிலையில் ஒன்றிணையலாம். பயனர் விருப்ப பின்னூட்டத்தை மதிப்பாய்வாளர் வளையத்தில் எவ்வாறு இணைக்க முடியும்?

பயனர் பின்னூட்டத்தை மிக உயர்ந்த முன்னுரிமை கொண்ட கட்டமைக்கப்பட்ட நிகழ்வாக ஏஜெண்டின் பாதையில் செலுத்தவும்; பயனர் விருப்பங்களை வெளிப்புறமயமாக்கி MEMORY.md இல் எழுதி, விருப்பங்கள் பணிகளுக்குக் குறுக்கே செல்லுபடியாகச் செய்யவும்; பயனர் சரிபார்ப்பதற்கு எளிதாக Markdown க்குப் பதிலாக HTML வடிவ ஆவணங்களை வழங்கவும்.

5. (★★) இந்த அத்தியாயம் ஒரு குறியீட்டு ஏஜெண்ட் செயல்படுத்தல் மற்றும் பிழைத்திருத்தத்திலிருந்து பெற்ற அனுபவத்தை குறியீட்டுத் தளத்தில் மீண்டும் டெபாசிட் செய்யும் பல்வேறு வழிகளை நிரூபிக்கிறது—அறிவுத் தள கோப்புகளில் எழுதுதல், கட்டமைப்பு ஆவணங்களைப் புதுப்பித்தல், திட்ட அறிவுறுத்தல் கோப்புகளைப் பராமரித்தல் மற்றும் செயல்பாட்டு வரிசைகளை குறியீடாக உறுதிப்படுத்துதல். இந்த அனுபவம் மேலும் சிஸ்டம் ப்ராம்ப்டில் உள்ள விதிகளாக சுத்திகரிக்கப்பட்டால், விதி தொகுப்பு காலப்போக்கில் விரிவடையும். குவிந்த விதிகளில் "குப்பை சேகரிப்பை" எவ்வாறு செய்வது—தேவையற்ற அல்லது காலாவதியான உள்ளீடுகளை அடையாளம் கண்டு சுத்தம் செய்வது? ஒரு ஏஜெண்ட் தனது சொந்த அனுபவத்தைக் குவிக்கும் இந்த பொறிமுறைக்கும் அத்தியாயம் 8 இல் விவாதிக்கப்படும் சிஸ்டம் ப்ராம்ப்ட்களின் தானியங்கி உகப்பாக்கத்திற்கும் இடையே உள்ள ஒற்றுமைகள் மற்றும் வேறுபாடுகள் யாவை?

GC அணுகுமுறை: "கட்டுப்பாடுகள் வழிகாட்டுதலை விட முன்னுரிமை பெறுகின்றன"—Linter/CI/கருவி சரிபார்ப்பில் குறியாக்கம் செய்யக்கூடிய விதிகளைப் ப்ராம்ப்டிலிருந்து நகர்த்தவும்; விதி ஹிட் விகிதங்களைக் கண்காணித்து, LangChain இன் "தோல்விப் பாதைகளைப் பகுப்பாய்வு செய்தல்" என்ற தரவு-உந்துதல் அணுகுமுறையைப் பின்பற்றித் தேவையற்றவற்றைக் கண்டறியவும்; அவ்வப்போது ஏஜெண்ட் குறியீட்டுத் தளத்துடன் ஒப்பிட்டு விதிகள் இன்னும் நிலைக்கிறதா எனச் சரிபார்க்கச் செய்யவும் (காலாவதியான ஆவணம் இல்லாததை விட மோசமானது); Markdown+Git நீக்குதல் மற்றும் மாற்றங்களைத் தணிக்கை செய்யக்கூடியதாகவும் திரும்பப் பெறக்கூடியதாகவும் ஆக்குகிறது. அத்தியாயம் 8 உடன் இரண்டும் எடைகளை மாற்றாத வெளிப்புறமயமாக்கப்பட்ட கற்றல்; வேறுபாடு: இந்த அத்தியாயம் செயல்படுத்தலின் போது படிப்படியாகக் குவிக்கிறது, அத்தியாயம் 8 மதிப்பீட்டுச் சமிக்ஞைகளால் இயக்கப்படும் முறையான சேர்ப்பு-நீக்கல் உகப்பாக்கம்.

6. (★) "தொலைதூர வேலைக்கு நட்பான குழுக்கள், பெரும்பாலும் AI ஏஜெண்டுகளுக்கும் நட்பானவை." உங்கள் குழு அல்லது நிறுவனம், அறிவு ஆவணப்படுத்தலின் அடிப்படையில் "AI-தயார்" நிலையை எந்த அளவிற்கு நெருங்கியுள்ளது? மிகப்பெரிய தடை என்ன?

திறந்த கேள்வி. இந்த அத்தியாயத்தின் ப்ராக்ஸி அளவீட்டைப் பயன்படுத்திச் சுய சரிபார்ப்பு செய்யலாம்: தொலைதூரத்தில் சேரும் புதியவர் களஞ்சியம் மற்றும் ஆவணங்களை மட்டும் நம்பி சுயாதீனமாக வேலை செய்ய முடியுமா? சரிபார்ப்புப் பட்டியல்: முடிவுகள் ஆவணங்களில் பதிவு செய்யப்பட்டுள்ளதா, சூழல் issue/PR இல் எழுதப்பட்டுள்ளதா, build/சோதனைக் கட்டளைகளுக்கு CLAUDE.md/AGENTS.md போன்ற அறிவுறுத்தல் கோப்புகள் உள்ளதா, பழங்குடி அறிவு டெவலப்பர் வழிகாட்டிகளாகப் படிவடைந்துள்ளதா. பொதுவான மிகப்பெரிய தடை: "பக்கத்தில் உள்ள சக ஊழியரிடம் கேட்பது" என்ற வாய்மொழிப் பரிமாற்றம் மற்றும் வெள்ளைப் பலகைக் கலாச்சாரம்—ஏஜெண்ட் வாய்மொழி ஒப்பந்தங்களைப் படிக்க முடியாது, ஆவணங்களை மட்டுமே படிக்க முடியும்.

7. (★★★) சைமன் வில்லிசன், ஏஜெண்டுகளுக்கான "மரண முக்கோணத்தை" (Lethal Triad) முன்மொழிந்தார் (தனிப்பட்ட தரவுகளுக்கான அணுகல், நம்பத்தகாத உள்ளடக்கத்திற்கான வெளிப்பாடு, மற்றும் வெளிப்புற தொடர்பு திறன்கள்). இந்த அத்தியாயம் நான்காவது ஒன்றைச் சேர்க்கிறது: நிலையான நினைவகம். நான்கு கூறுகளையும் ஒரே நேரத்தில் கையாள வேண்டிய உற்பத்தி சூழலில், பாதுகாப்பு உத்தியை எவ்வாறு வடிவமைப்பீர்கள்?

நான்கு வகை எல்லைகளுக்கும் அடுக்குப் பாதுகாப்பு. தரவு எல்லை: நற்சான்றிதழ்கள் மவுண்ட் செய்யப்படாமல், மூலக் குறியீடு வாசிப்பு-மட்டும், குறைந்தபட்ச தரவு. உள்ளீட்டு நம்பிக்கை எல்லை: மூலம் குறிப்பிடுதல், வெளிப்புற உள்ளடக்கம் "குறிப்புக்கு மட்டும், வழிமுறை அதிகாரம் இல்லை" என்ற தரவாகத் தரக்குறைத்தல் (விசுவாச விதி). வெளியீட்டுத் தாக்க எல்லை: இயல்பாக நெட்வொர்க் துண்டிப்பு + வெள்ளைப் பட்டியல் வெளியேற்றம், கருப்புப் பட்டியலுக்குப் பதிலாகக் கட்டளை சொற்பொருள் பாகுபடுத்தல், Sidecar சுயாதீன மறுஆய்வு + லூப்பில்-மனிதர்—முக்கிய செயல்பாடுகள் சூழலுக்கு வெளியே உள்ள வழிமுறையால் மறுஆய்வு செய்யப்பட வேண்டும். குறுக்கு-அமர்வு எல்லை: MEMORY.md இல் எழுதுவது வெளிப்புற உள்ளடக்கத்திற்குச் சமமான நம்பிக்கை மறுஆய்வுக்கு உட்பட வேண்டும். இலக்கு: ஊசிப்பு நடந்தாலும் செயல்படுத்த முடியாமல் இருப்பது.

8. (★★) ஆர்ட்டிஃபாக்ட் முறைமை, ஒரு ஏஜெண்டால் உருவாக்கப்பட்ட SQL அல்லது முன்பக்க குறியீட்டை, பயனரின் உலாவி அல்லது தரவுத்தளத்தில் நேரடியாக இயக்க அனுமதிக்கிறது. இருப்பினும், உருவாக்கப்பட்ட SQL அழிவுகரமான செயல்பாடுகளை இயக்கக்கூடும், மேலும் உருவாக்கப்பட்ட HTML பாதிப்புகளைக் கொண்டிருக்கலாம். கணினி பாதுகாப்பை எவ்வாறு உறுதி செய்ய முடியும்?

SQL: வினவல்கள் குறைந்தபட்ச அனுமதியுடைய வாசிப்பு-மட்டும் கணக்கில் இயக்கப்பட வேண்டும், மேலும் CPU, நினைவகம் போன்ற வள வரம்புகளைச் சேர்த்து வள சோர்வைத் தடுக்க வேண்டும். HTML/UI: A2UI போன்ற அறிவிப்பு நெறிமுறைகளுக்கு முன்னுரிமை கொடுக்கவும்—ஏஜெண்ட் இடைமுக விளக்க JSON ஐ மட்டும் வெளியிட, கிளையன்ட் நம்பகமான கூறு அடக்கத்தைப் பயன்படுத்தி ரெண்டர் செய்யட்டும், தன்னிச்சைக் குறியீடு இயக்கப்படாது. தன்னிச்சை HTML தேவைப்பட்டால், சாண்ட்பாக்ஸ் சூழலில் காட்டப்பட வேண்டும், ஊசிப்பைத் தடுக்க.

9. (★★) வணிக விதிகளை, கருவிகளுக்குள் தரவுத்தள-உண்மை அடிப்படையிலான சரிபார்ப்புகளாக குறியாக்கம் செய்வதும், அழைப்பதற்கு முன் கொள்கை நிபந்தனைகளைச் சரிபார்க்க மாதிரியை வழிநடத்த அளவுரு வடிவமைப்பைப் பயன்படுத்துவதும், அடிப்படையில் ஏஜெண்டின் நடத்தையை கட்டுப்படுத்த குறியீடு கட்டமைப்பைப் பயன்படுத்துகிறது. இயற்கை மொழி விதிகளுடன் ஒப்பிடும்போது, இந்த "குறியீடு விதிகளாக" முறைமையின் நன்மைகள் மற்றும் வரம்புகள் யாவை?

நன்மைகள்: தெளிவின்மை இல்லை, தீர்மானமானது, சிக்கலான நிபந்தனைச் சேர்க்கைகளில் திறமையானது; கொள்கை உண்மைகள் தரவுத்தள உண்மை மற்றும் சேவையக-பக்கக் கடிகாரத்திலிருந்து எடுக்கப்படுகின்றன, மாதிரியின் சுய-அறிக்கை மதிப்புகள் நம்பப்படுவதில்லை, மாயத்தோற்றமோ ப்ராம்ப்ட் ஊசிப்போ இதைத் தாண்ட முடியாது—மீளமுடியாத செயல்பாடுகளுக்கான இறுதி வாயில் காவலர்; expected_* அளவுருக்கள் கட்டாய checklist ஆகவும் செயல்பட்டுச் சிந்தனையை வழிநடத்துகின்றன. வரம்புகள்: குறியீடு பயனருக்குக் கொள்கையை விளக்காது, மாற்று வழிகளைக் கண்டுபிடிக்காது, மேலும் பராமரிப்புச் செலவு உள்ளது. முடிவு: இயற்கை மொழி விதிகளுடன் நிரப்பு உறவு, மாற்று அல்ல.

10. (★★) ஆர்ட்டிஃபாக்ட் முறைமை, ஒரு ஏஜெண்டை SQL அல்லது விஷுவலைசேஷன் குறியீட்டை உருவாக்க அனுமதிக்கிறது, பின்னர் அது முன்பக்கத்தால் நேரடியாக இயக்கப்பட்டு, அதிக அளவிலான தரவை செயலாக்குவதற்கு LLM ஐத் தவிர்க்கிறது. பாரம்பரிய "ஏஜெண்ட் நேரடியாக பதிலை வழங்குகிறது" முறைமையுடன் ஒப்பிடும்போது, இந்த "ஏஜெண்ட் குறியீட்டை உருவாக்குகிறது, கணினி குறியீட்டை இயக்குகிறது" என்ற பணிப்பிரிவின் நன்மை தீமைகள் யாவை?

நன்மைகள்: தரவு தரவுத்தளத்திலிருந்து நேரடியாக முன்பக்கத்திற்குச் செல்கிறது, LLM "இடைத்தரகரை"த் தவிர்க்கிறது—வேகமானது, டோக்கன் சேமிப்பு, அதிக அளவு தரவை நகலெடுக்கும்போது ஏற்படும் மாயத்தோற்றப் பிழைகளைத் தவிர்க்கிறது, பெரிய தரவு விளக்கக்காட்சிக்கு ஏற்றது; குறியீடு தணிக்கை செய்யக்கூடியது, மீண்டும் பயன்படுத்தக்கூடியது, குழாய்களாகவும் இணைக்கலாம் (SQL முடிவுகள் நேரடியாகக் காட்சிப்படுத்தல் குறியீட்டிற்கு உள்ளீடாக). தீமைகள்: LLM வினவல் முடிவுகளைப் பார்க்க முடியாது, தரவு உள்ளடக்கத்தின் அடிப்படையில் மேலும் தொகுத்து முடிவெடுக்க முடியாது, மாதிரி தரவைச் செரித்துப் பகுத்தறிய வேண்டிய பணிகளுக்கு ஏற்றதல்ல.

அத்தியாயம் 6 ஏஜெண்டுகளை மதிப்பீடு செய்தல்

1. (★★) LLM-as-a-Judge ஒரு மொழி மாதிரியின் வெளியீட்டை மதிப்பிடுவதற்கு ஒரு மொழி மாதிரியைப் பயன்படுத்துகிறது. இந்த "சுய-மதிப்பீட்டில்" முறையான குருட்டுப் புள்ளிகள் உள்ளதா—எடுத்துக்காட்டாக, மாதிரி ஒரு குறிப்பிட்ட பாணியிலான பதிலுக்கு தொடர்ந்து அதிக மதிப்பெண்களை வழங்கலாம், இந்த விருப்பம் மனித தீர்ப்புடன் முரண்படுகிறதா? இத்தகைய சார்புகளை எவ்வாறு கண்டறிந்து சரிசெய்வது?

உள்ளது: நீளச் சார்பு, பதில் பாணிச் சார்பு, ஒரே மூல மாதிரிகள் சுரண்டப்படுதல் (குட்ஹார்ட்டின் விதி - Goodhart's law). கண்டறிதல்: 100-200 எடுத்துக்காட்டுகள் கொண்ட மனித தங்கத் தரத் தொகுப்பை உருவாக்கி, நடுவர்-மனிதர் Cohen's kappa ஐ அளவிடுதல்; மதிப்பெண்கள் மற்றும் பதில் நீளம் இடையிலான தொடர்பை அவ்வப்போது தணிக்கை செய்தல்; சிவப்புக் குழு எதிர்ப்பு வழக்குகளை உருவாக்குதல். திருத்தம்: Rubric வெளிப்படையாக வாயாடைத் தண்டிக்க, நீளத்தைக் கட்டுப்படுத்த; வெவ்வேறு மாதிரிக் குடும்பங்களிலிருந்து பல-மூல பல்துறை நடுவர்கள்.

2. (★★★) மதிப்பீட்டு தரவுத்தொகுப்புகளின் "கசிவு-தடுப்பு" வடிவமைப்பு மிகவும் முக்கியமானது. இருப்பினும், திறந்த மூல சூழலில், அளவுகோல் தரவு பொதுவில் வெளியிடப்பட்டவுடன், அது விரைவாக பயிற்சி தரவுகளில் இணைக்கப்படுகிறது. இந்த "பூனை-எலி விளையாட்டுக்கு" முடிவு உண்டா? தரவு கசிவை அடிப்படையில் எதிர்க்கும் ஒரு மதிப்பீட்டு முறையை வடிவமைக்கவும்.

நிலையான கேள்வி வங்கிகளுக்கு இறுதி இல்லை, பின்தொடர்வது மட்டுமே. அடிப்படை வழி: "உருவாக்கும் வழிமுறை"யைப் பொதுவில் வைத்து "குறிப்பிட்ட நிகழ்வுகளை" தனிப்பட்டதாக வைத்தல்—τ²-bench, AndroidWorld போல அளவுருவாக்கப்பட்ட வார்ப்புருக்களை ஒவ்வொரு முறையும் சீரற்ற முறையில் நிகழ்வாக்குதல், நிலையான பதில் வரிசைக்குப் பதிலாக இறுதி சூழல் நிலையின் அடிப்படையில் சரிபார்த்தல்.

3. (★★) Scale AI இன் நான்கு அளவுகோல்கள் (நிபுணர் வழிகாட்டுதல், விரிவான கவரேஜ், தரநிலை முக்கியத்துவ எடை, சுய-உள்ளடக்கிய மதிப்பீடு) மதிப்பீட்டில் உள்ள அகநிலையை நீக்குவதை நோக்கமாகக் கொண்டுள்ளன. இருப்பினும், சில பணி பரிமாணங்கள் (எ.கா., "பதில் உதவியாக உள்ளதா?" "தொனி பொருத்தமானதா?") இயல்பாகவே அகநிலை சார்ந்தவை. இந்த அகநிலை பரிமாணங்களுக்கு நம்பகமான Rubrics ஐ எவ்வாறு வடிவமைப்பது?

சுருக்கமான தரநிலைகளைச் சரிபார்க்கக்கூடிய நடத்தைகளாக மொழிபெயர்க்கவும். ஒவ்வொரு நிலைக்கும் குறிப்பிட்ட எடுத்துக்காட்டுகள் மற்றும் எல்லை வழக்குகளை இணைக்கவும்; Rubric ஒரு மறுமுறை விளைபொருள்—சோதனைப் பயன்பாட்டில் மதிப்பீட்டாளர் கருத்து வேறுபாடுகளைச் சேகரித்து, படிப்படியாக முன்னுதாரணத் தொகுப்பாக உருவாக விடவும். மேலும் பல நடுவர் எடையிடல்/ஒத்துழைப்புச் சரிபார்ப்பு, கருத்து வேறுபாடு வழக்குகளை மனித மறுஆய்வுக்கு அனுப்புதல், தங்கத் தரத் தொகுப்பில் ஒத்துழைப்பு விகிதத்தை அளவுத்திருத்தல் ஆகியவற்றைச் சேர்க்கவும்.

4. (★★) τ-bench உண்மையான பயனர் நடத்தையை உருவகப்படுத்துவதன் மூலம் ஏஜெண்டுகளை மதிப்பிடுகிறது. ஆனால் உருவகப்படுத்தப்பட்ட பயனர் ஒரு LLM ஆகும்—இது சில விளிம்பு நிலை நிகழ்வுகளை (எ.கா., உணர்ச்சிவசப்பட்ட அல்லது தெளிவற்ற பயனர்கள்) முறையாக குறைத்து மதிப்பிடலாம். உருவகப்படுத்தப்பட்ட பயனரின் தரத்தை எவ்வாறு சரிபார்க்க முடியும்?

τ-bench ஆரம்ப பதிப்பின் பாடம்: உருவகப்படுத்தி அதிக இயந்திரமயமானது, வழிமுறைகள் அதிக எளிமையானவை (ஏஜெண்ட் பதிலை யூகித்துவிடும்). சரிபார்ப்பு வழிகள்: உருவகப்படுத்தப்பட்ட உரையாடல்களை மனிதர் தற்செயலாக ஆய்வு செய்து, படிப்படியான வெளிப்பாட்டைப் பின்பற்றுகிறதா, ஸ்கிரிப்ட்டிற்கு வெளியே தகவலைக் கற்பனை செய்கிறதா எனச் சரிபார்த்தல்; சிறிய அளவிலான உண்மையான பயனர் சோதனைகளை நடத்தி, உருவக மதிப்பீட்டுடன் தரவரிசை ஒத்துப்போகிறதா எனப் பார்த்தல்.

5. (★★) ஜோடிவரிசை ஒப்பீடு (Bradley-Terry மாதிரி) என்பது விருப்பங்கள் இடமாற்றத்தன்மை கொண்டவை என்று கருதுகிறது (A > B மற்றும் B > C எனில், A > C). இருப்பினும், மனித விருப்பங்கள் பெரும்பாலும் இடமாற்றத்தன்மையை மீறுகின்றன. ஏஜெண்ட் மதிப்பீட்டில், எந்த சூழ்நிலைகளில் இடமாற்றமற்ற விருப்பங்கள் தோன்றக்கூடும்? இது தரவரிசைகளின் நம்பகத்தன்மையை எவ்வாறு பாதிக்கிறது?

சூழ்நிலைகள்: பல-பரிமாண எடைபீடுகளின்போது (A துல்லியமானது ஆனால் மெதுவானது, B வேகமானது ஆனால் சுருக்கமானது, C விரிவானது ஆனால் விலை உயர்ந்தது), வெவ்வேறு நடுவர்கள்/பணிகள் வெவ்வேறு பரிமாணங்களை மதிக்கின்றனர். Chatbot Arena இன் தரவரிசையே பயனர் கேள்வி விநியோகத்தைச் சார்ந்தது. தாக்கம்: BT திறனை ஒற்றை மதிப்பெண்ணாகச் சுருக்குகிறது; இடமாற்றமின்மையின்போது தரவரிசை நிலையற்றதாகி, ஆட்டங்களின் விநியோகத்துடன் நகர்கிறது. தணிப்பு: திறன் பரிமாணங்கள்வாரித் தனித்தனியாகத் தரவரிசைப்படுத்துதல், ஜோடிவாரி வெற்றி விகித அணியை அறிக்கையிடுதல்.

6. (★★) இந்த அத்தியாயம் "கவனி → கருதுகோள் உருவாக்கு → பரிசோதனை செய் → சரிபார்" என்ற அறிவியல் முறையை முன்மொழிகிறது. நடைமுறையில், இருப்பினும், ஏஜெண்டின் நடத்தை இடம் மிகப்பெரியது, மேலும் ஒரு கருதுகோளை சரிபார்க்க நூற்றுக்கணக்கான மதிப்பீட்டு இயக்கங்கள் தேவைப்படலாம். வரையறுக்கப்பட்ட கணக்கீட்டு வரவு செலவுத் திட்டத்தின் கீழ் மதிப்பீட்டிலிருந்து பெறப்படும் தகவலை எவ்வாறு அதிகரிக்க முடியும்?

முதலில் தோல்விகளை ஒரே தன்மை கொண்ட குழுக்களாகப் பிரித்து, அதிக diagnostic தகவல் தரும் பணிகளை மட்டும் சிறிய pilot-இல் எடுத்துக்கொள்ளவும். ஒரே மாறியை மாற்றும், குறைந்த செலவிலான paired சோதனைகளைப் பயன்படுத்தவும்; சிறிய pilot-ஐ deployment ஆதாரமாக அல்ல, பெரிய சோதனைக்கான gate-ஆகக் கருதவும். புள்ளியியல் ரீதியில் standard error-ஐ ஒரு conservative filter-ஆகவும், அதே பணிகளின் paired முடிவுகளுக்கு McNemar போன்ற சோதனையையும் பயன்படுத்தவும். எதிர்பார்க்கும் முன்னேற்றம் noise band-ஐ விடச் சிறியதாக இருந்தால் evaluation set-ஐ விரிவுபடுத்தவும். பல மாற்றுகளை ஒரே நேரத்தில் சோதிக்கும்போது multiple-comparison correction செய்யவும்; சாதகமான முடிவைச் சுயாதீன இயக்கத்தில் மீண்டும் உறுதிப்படுத்தவும்.

7. (★) AndroidWorld pilot-இல் முழு element tree வெற்றியை 25%-இலிருந்து 100%-ஆக உயர்த்தியது; ஆனால் token பயன்பாடு control-ன் 2.498× ஆனது. Tree pruning செய்த பிறகும் வெற்றி 100%-ஆகவே இருந்தது; token பயன்பாடு 0.506× ஆகக் குறைந்தது. Accessibility, state verification, அடுத்தடுத்த action ஆகியவற்றுக்குத் தேவையான தகவலை இழக்காமல், பொருள் இல்லாத UI node-களை தானாக நீக்கும் விதிகளை எவ்வாறு வடிவமைப்பீர்கள்?

“ஆதாரம் இருந்தால் வைத்திரு; இல்லையெனில் இயல்பாக நீக்கு” என்ற படிநிலை விதியைப் பயன்படுத்தலாம். திரையில் தெரியும், உரை கொண்ட, செயல்படக்கூடிய, focus/scroll செய்யக்கூடிய, state காட்டும் அல்லது accessibility label கொண்ட node-களை வைத்திருக்கவும். அவற்றைப் புரிந்துகொள்ளத் தேவையான மிகக் குறுகிய ancestor path-களையும் அருகிலுள்ள label-களையும் பாதுகாக்கவும். Layout மட்டும் தரும் container-களை நீக்கி, மீண்டும் வரும் subtree-களைச் சுருக்கமாகக் காட்டவும். Pruning-க்கு முன்பும் பின்பும் actionable ID, state, value ஆகியவை மாறாமல் உள்ளனவா என்று சரிபார்க்கவும்; screenshot-ஐ visual fallback-ஆக வைத்திருக்கவும். தோல்வி trace-களில் விதியை replay செய்து, பின்னர் பயிற்சியில் இடம்பெறாத app-களில் சோதிக்கவும். வெற்றி, tokens, latency மூன்றும் இணைந்த guardrail-கள்; accessibility-ல் எந்த regression ஏற்பட்டாலும் release-ஐ நிறுத்த வேண்டும்.

8. (★★) τ-bench இன் பயனர் உருவகப்படுத்துதல் "முற்போக்கான தகவல் வெளிப்பாட்டை" பயன்படுத்துகிறது—அனைத்து தகவல்களையும் ஒரே நேரத்தில் வழங்காமல், ஏஜெண்டின் கேள்விகளின் அடிப்படையில் படிப்படியாக வெளிப்படுத்துகிறது. இந்த வடிவமைப்பு மதிப்பீட்டு முடிவுகளை எவ்வாறு பாதிக்கிறது? உருவகப்படுத்தப்பட்ட பயனரின் தகவல் வெளிப்பாட்டு உத்தி உண்மையான பயனர்களிடமிருந்து கணிசமாக வேறுபட்டால், மதிப்பீட்டு முடிவுகள் இன்னும் நம்பகமானதா?

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

அத்தியாயம் 7 மாதிரி பிந்தைய பயிற்சி (Model Post-Training)

1. (★★) பணி-குறிப்பிட்ட நுண்சரிப்படுத்தல் மாதிரியின் அசல் பொதுத் திறன்களை (எ.கா., பொதுவான கருவி அழைப்பு) அழித்துவிடும் பேரழிவு மறதி (Catastrophic forgetting) - இது ஏஜெண்ட் காட்சிகளில் மிகவும் சிக்கலானது. முழு-அளவுரு நுண்சரிப்படுத்தலுடன் ஒப்பிடும்போது, LoRA அடிப்படை எடைகளை உறைய வைத்து மறதி அபாயத்தைக் குறைக்கிறது, ஆனால் அது முற்றிலும் விடுபட்டதல்ல. நுண்சரிப்படுத்தலின் போது திறன் மறதியை மேலும் குறைக்க என்ன உத்திகளைப் பயன்படுத்தலாம்?

தரவு விகிதம்: சுமார் 20% பொது/அசல் விநியோகத் தரவைக் கலக்கவும், புதிய பணியின் விகிதம் அதிகமாகிப் பழைய திறன்களை நசுக்குவதைத் தடுக்கவும்; பயிற்சி அளவில் அடக்கம்: "வடிவம் நிலையானது, திறன் ஆரம்பமானது" என்ற நிலையில் SFT ஐ நிறுத்தவும், சரிவைத் தடுக்க ஆரம்ப நிறுத்தம்; RL குறைந்த rank (8–32) ஐப் பயன்படுத்தி KL தண்டனையைத் தக்கவைத்து, கொள்கையைக் குறிப்பு மாதிரிக்கு அருகில் வைக்கவும்; முக்கியக் கூறுகளை உறைய வைக்கவும் (எ.கா., VLM திட்ட அடுக்கை மட்டும் பயிற்றுவித்தல்); பணிவாரிப் பல LoRA அடாப்டர்களை இணைத்துத் திறன்களைத் தனிமைப்படுத்தவும்; பொதுவான அளவுகோல்களைப் பின்னடைவுச் சோதனைகளாகப் பயன்படுத்தவும்.

2. (★★) பிந்தைய-பயிற்சி (Post-training) திறன்களை மாதிரி எடைகளில் ("தசை நினைவகம்") உறுதிப்படுத்துகிறது, அதேசமயம் சூழல்-உள் கற்றல் (in-context learning) அனுமானத்தின் போது உள்ளீட்டில் அறிவை வைக்கிறது. இருப்பினும், சில திறன்களை (எ.கா., கள அறிவு) பிந்தைய-பயிற்சி மூலமாகவோ அல்லது சில-எடுத்துக்காட்டுகள் (few-shot examples) மூலமாகவோ வழங்க முடியும். கொடுக்கப்பட்ட ஒரு திறனுக்கு எந்தப் பாதையைத் தேர்ந்தெடுக்க வேண்டும் என்பதை முடிவு செய்ய நீங்கள் என்ன அளவுகோல்களைப் பயன்படுத்துவீர்கள்?

அறிவு வகை: உண்மை அறிவை RAG/சூழலிடம் கொடுக்கவும், SFT அதிக அளவு உண்மைகளை நினைவில் வைக்க முடியாது; உண்மையல்லாத அறிவு, மொழியில் வெளிப்படுத்தக் கடினமான விதிகள் பிந்தைய பயிற்சிக்கு ஏற்றவை. புதுப்பிப்பு அதிர்வெண்: அடிக்கடி மாறுவதைச் சூழலில் வைக்கவும் (மாறும் புதுப்பிப்பு, தடமறியக்கூடியது), நிலையானவற்றை மட்டும் அளவுருக்களில் எழுதவும். கட்டம் மற்றும் செலவு: ஆராய்ச்சிக் கட்டத்தில் சூழல் கற்றலை (ப்ராம்ப்ட் + அறிவுத் தளம்) விரைவான சோதனை-பிழைக்குப் பயன்படுத்தவும்; தயாரிப்பு நிலைபெற்று, அழைப்பு அளவு அதிகமாகி, தாமதம்/கட்டணம் உணர்திறன் கொண்டதானால் ப்ராம்ப்ட் வடித்தல்-பாணி உறுதிப்படுத்தலைச் செய்யவும். விநியோக நிலைத்தன்மை: வரிசைப்படுத்தும் விநியோகம் கணிக்கக்கூடிய கள ஏஜெண்டுகளுக்கு மட்டுமே பயிற்சி மதிப்புள்ளது; பொது ஏஜெண்டுகளுக்குப் பொதுவாகப் பயிற்சி தேவையில்லை.

3. (★★) மாதிரி வடித்தல் (Model distillation) ஒரு சிறிய மாதிரி ஒரு பெரிய மாதிரியின் நடத்தையைக் கற்றுக்கொள்ள அனுமதிக்கிறது. திறன் மட்டத்தில், வடிக்கப்படும் மாதிரிகளை தோராயமாக மூன்று நிலைகளாகப் பிரிக்கலாம்—அரட்டை மாதிரிகள் (ஒற்றை-சுற்று உரையாடல், நேரடி பதில்கள்), பகுத்தறிவு மாதிரிகள் (பதிலளிப்பதற்கு முன் நீண்ட சிந்தனைச் சங்கிலிகளை உருவாக்குதல்), மற்றும் ஏஜெண்டிக் மாதிரிகள் (பல-சுற்று கருவி அழைப்புகள், சூழலுடன் தொடர்பு கொள்ளுதல்). இந்த மூன்று வகை மாதிரிகள் ஒவ்வொன்றையும் வடிப்பதில் உள்ள வெவ்வேறு சவால்கள் யாவை? (குறிப்பு: "சரியாக என்ன வடிக்கப்படுகிறது" என்பதிலிருந்து தொடங்குங்கள்—அது வெளியீட்டின் பாணியா, முழுமையான பகுத்தறிவுத் தடமா (reasoning trace), அல்லது சூழலுடன் தொடர்புகொள்வதற்கான முடிவெடுக்கும் உத்தியா; தடத்தில் உள்ள எந்த டோக்கன்களைக் கற்றுக்கொள்ள வேண்டும், எவை கற்றுக்கொள்ளக் கூடாத சுற்றுச்சூழல் திரும்பப் பெறுதல்கள் (environmental returns); மற்றும் வெற்றி/தோல்வி சமிக்ஞைகள் எவ்வளவு தாமதமாகவும் எவ்வளவு அரிதாகவும் வருகின்றன.)

Chat: "உள்ளீடு → வெளியீடு" வரைபடம் மற்றும் பாணியை மட்டும் கற்கிறது, நிலையான SFT போதும், மிகவும் எளிதானது. Reasoning: முழுமையான சிந்தனைப் பாதைகள் தேவை, திறந்த மூல ஆசிரியர் மாதிரியின் அடிப்படையில் இருக்க வேண்டும்; தவறான பதில்களுடன் கூடிய பாதைகளை வடிகட்ட வேண்டும். Agentic: உண்மையான உருவகப்படுத்தப்பட்ட சூழல் தேவை; ஆஃப்லைன் கற்றலில் learner-sampler mismatch எளிதில் ஏற்படும், திறந்த மூல ஆசிரியர் மாதிரியின் அடிப்படையில் On-Policy Distillation செய்யப் பரிந்துரைக்கப்படுகிறது.

4. (★★★) பல-சுற்று ஏஜெண்ட் தொடர்புகளில், கடன் ஒதுக்கீடு பிரச்சனை (credit assignment problem) ஒற்றை-சுற்று காட்சிகளை விட மிகவும் கடுமையானது—இறுதி வெற்றி அல்லது தோல்வியை சுற்று 3 இல் எடுக்கப்பட்ட முடிவுக்குக் காரணம் கூறுவது மற்றும் சுற்று 7 இல் எடுக்கப்பட்ட முடிவுக்குக் காரணம் கூறுவது கடினம். நீங்கள் எவ்வாறு வெகுமதி ஒதுக்கீட்டு உத்தியை (reward allocation strategy) வடிவமைப்பீர்கள்?

இடைநிலைப் படிகள் தீர்மானிக்கக்கூடியதாக இருந்தால் செயல்முறை வெகுமதியைச் சேர்க்கவும் (V-IRL ஒவ்வொரு படிக்கும் ±1); RLVP ஐப் பின்பற்றித் தீர்மானமான விதிகளால் ஒவ்வொரு செயலுக்கும் பாதைச் சமிக்ஞை வழங்கி, முழு-தோல்வி/முழு-வெற்றிக் குழுக்களின் குழு-உள் மாறுபாட்டை மீட்டெடுக்கவும்.

5. (★★★) பிந்தைய-பயிற்சி, வெளிப்புறமயமாக்கப்பட்ட கற்றல் (externalized learning), மற்றும் சூழல்-உள் கற்றல் ஆகியவை ஏஜெண்ட் திறனின் மூன்று பரிமாணங்களை உருவாக்குகின்றன. வாடிக்கையாளர் சேவை ஏஜெண்ட்டின் செயல்திறனை மேம்படுத்த உங்களிடம் நிலையான பட்ஜெட் (எ.கா., $10,000) இருந்தால், இந்த மூன்று பரிமாணங்களுக்கும் பட்ஜெட்டை எவ்வாறு ஒதுக்கீடு செய்வீர்கள்? உங்கள் முடிவு எந்த காரணிகளைச் சார்ந்திருக்கும்?

முதலில் ICL/ஹார்னஸ் பொறியியலுடன் விரைவாக மறுமுறை செய்து தடையைக் கண்டறியவும்—பெரும்பாலான பிரச்சினைகள் இந்த அடுக்கில் தீர்ந்துவிடும்; தயாரிப்பு அறிவு, திட்ட விதிகள் போன்ற உண்மையான, அடிக்கடி புதுப்பிக்கப்படும் உள்ளடக்கத்திற்கு RAG இல் முதலீடு செய்யவும் (புதுப்பிக்கக்கூடியது, தடமறியக்கூடியது); தொனி, செயல்முறை நெறிமுறைகள், கருவி அழைப்பு வடிவங்கள் நிலைபெற்ற பின் LoRA On-Policy Distillation மூலம் உறுதிப்படுத்தவும் (குறைந்த செலவு); RL பத்து முதல் நூறு மடங்கு வரை விலை உயர்ந்தது—ஆசிரியர் மாதிரி கிடைக்காதபோது அல்லது பொதுமைப்படுத்தும் திறன் தேவைப்படும்போது மட்டும் பயன்படுத்தவும்.

6. (★★★) தன்னாட்சி மாதிரி கற்றல் (Autonomous model learning), தெளிவான வெகுமதி செயல்பாடு இல்லாமல் மற்றும் அரிய மாதிரிகளுடன், சிலரால் பிந்தைய-பயிற்சியின் இறுதி இலக்காகக் கருதப்படுகிறது. தற்போதைய RL பயிற்சி முறைகள் இந்த இலக்கிலிருந்து எவ்வளவு தூரம் உள்ளன? அடுத்த முன்னேற்றம் எங்கிருந்து வர வாய்ப்புள்ளது என்று நீங்கள் நினைக்கிறீர்கள்?

இடைவெளி: Silver மற்றும் Sutton சுட்டிக்காட்டியபடி, தற்போதைய RL இறுதி வெற்றி/தோல்வியிலிருந்து மட்டுமே கற்க முடியும்; "கிரெடிட் கார்டின் கடைசி நான்கு இலக்கங்கள் தேவை" போன்ற வாடிக்கையாளரின் வளமான பின்னூட்டம் முழுவதும் வீணடிக்கப்படுகிறது, நூற்றுக்கணக்கான குருட்டுச் சோதனை-பிழைகள் தேவை; மாதிரி திறனும் சரிபார்க்கக்கூடிய வெகுமதியும் முக்கியத் தடைகள். சாத்தியமான முன்னேற்றங்கள்: உருவாக்கும் வெகுமதி மாதிரிகள் தானாகவே கொள்கைகளை வகுத்து, ஒரே தோல்வியிலிருந்து திசையைக் கற்றல்; மற்றும் சூழலை மாதிரியமைக்கும் world model பாதை.

7. (★★) இந்த அத்தியாயம் LoRA நுண்சரிப்படுத்தலின் செலவு அதிகம் இல்லை என்பதைச் சுட்டிக்காட்டுகிறது. எனவே, ஒவ்வொரு பயனருக்கும் (அல்லது ஒவ்வொரு வாடிக்கையாளர் நிறுவனத்திற்கும்) ஒரு தனிப்பட்ட LoRA-வைப் பயிற்றுவித்து, பயனர் நினைவகம் அல்லது நிறுவன அறிவை அத்தியாயம் 3 இல் உள்ளதைப் போல வெளிப்புற அறிவுத் தளத்தில் சேமிப்பதற்குப் பதிலாக அளவுருக்களில் எழுத முடியுமா? "அளவுருக்களில் நினைவகத்தை எழுதுவது" "அறிவுத் தளத்தில் நினைவகத்தைச் சேமிப்பதை" விட எந்த சூழ்நிலைகளில் சாதகமாக இருக்கும்? எந்த சூழ்நிலைகளில் அது பயனற்றதாக இருக்கும்?

LoRA அதிக அளவு உண்மைகளைத் துல்லியமாக நினைவில் வைக்கக் கடினம் (தொடர்ச்சியான முன்-பயிற்சி தேவை, செலவு வெகுவாக அதிகரிக்கும்), நினைவில் வைத்தாலும், மாதிரி அந்த உண்மைகளைப் பயன்படுத்திப் பல-ஹாப் பகுத்தறிவு செய்வது கடினம்; எனவே LoRA மூலம் உண்மைகளை நினைவில் வைப்பது நல்ல தொழில்நுட்பப் பாதை அல்ல. கூடுதலாக, உண்மைகள் அடிக்கடி மாறும்போது அல்லது தடமறியக்கூடிய தணிக்கை தேவைப்படும்போது RAG சிறந்தது.

8. (★★★) On-Policy Distillation வலுவான ஆசிரியர் மாதிரியை (teacher model) நம்பி மாணவரை (student) மேற்பார்வையிடுகிறது. இருப்பினும், OpenAI இன் பலவீனத்திலிருந்து வலிமைக்கான பொதுமைப்படுத்தல் (Weak-to-Strong Generalization) ஆராய்ச்சி ஒரு எதிர்பாராத கண்டுபிடிப்பை முன்வைத்தது: பலவீனமான மாதிரியிலிருந்து (weak model) வரும் மேற்பார்வை சமிக்ஞை (supervisory signal), வலுவான மாதிரியில் (strong model) மறைந்திருக்கும் ஆனால் செயல்படுத்தப்படாத திறன்களை சில நேரங்களில் வெளிக்கொணர முடியும். இந்த யோசனை ஏஜெண்ட் (Agent) பயிற்சியில் பயன்படுத்தப்பட்டால், "சிறிய மாதிரி பெரிய மாதிரிக்கு கற்றுக்கொடுக்கும்" தலைகீழ் வடித்தல் (reverse distillation) சாத்தியமாகுமா?

சாத்தியம்; முக்கியம் "சரிபார்ப்பு உருவாக்குவதை விட எளிதானது": பலவீனமான மாதிரி நிரூபணம் செய்பவராக இருக்கக்கூடாது (SFT இன் உச்சவரம்பு நிரூபணம் செய்பவரின் நிலை), மாறாகச் சரிபார்ப்பாளர்/வெகுமதி மாதிரியாக இருக்க வேண்டும்; வலுவான மாதிரி தானே ஆராய, பலவீனமான மாதிரி தீர்ப்பு மட்டும் வழங்கட்டும்.

9. (★★) செயல்முறை வெகுமதி மாதிரி (Process Reward Model - PRM) ஒவ்வொரு பகுத்தறிவு படியையும் மதிப்பிடுகிறது, அதேசமயம் விளைவு வெகுமதி மாதிரி (Outcome Reward Model - ORM) இறுதி முடிவை மட்டுமே பார்க்கிறது. ஆனால், "தவறான முடிவுக்கு வழிவகுக்கும் சரியான செயல்முறை" மற்றும் "தற்செயலாக சரியான முடிவுக்கு வழிவகுக்கும் தவறான செயல்முறை" ஆகிய இரண்டில் எது வெகுமதிக்கு மிகவும் தகுதியானது? ஒரு ஏஜெண்ட்டின் (Agent) பல-படி கருவி அழைப்பு (multi-step tool-calling) காட்சியில், இவற்றை எவ்வாறு எடைபோடுவீர்கள்?

தற்செயல் வெற்றி அதிக ஆபத்தானது: விதி மீறும் குறுக்குவழிகள் பெரும்பாலும் மேற்பரப்பு வெற்றி விகிதத்தை உயர்த்துகின்றன (சோதனைக் கோப்புகளைத் திருத்துதல், சரிபார்ப்பைத் தவிர்த்தல்), reward hacking இன் விளைநிலம். RLVP இன் "முடிவுக்கு வெகுமதி, பாதைக்குத் தண்டனை" படி: தவறான செயல்கள் (கருவி அழைப்புகள்) சரிபார்க்க எளிதானவை, ஒவ்வொரு செயலுக்கும் மதிப்பெண் கழித்தல்; இடைநிலைப் படிகளின் சரிதவறு எளிதில் தீர்மானிக்கக்கூடியதாக இருந்தால் செயல்முறை வெகுமதி தரலாம். ஆனால் செயல்முறைக் கட்டுப்பாடுகள் அதிக அடர்த்தியாக இருக்கக்கூடாது—"push-cut" பாணி சிறந்த உத்திகள் முடிவு வெகுமதியின் ஆராய்ச்சிச் சுதந்திரத்தால்தான் கண்டுபிடிக்கப்பட்டன.

10. (★★★) இந்த அத்தியாயத்தில் விவாதிக்கப்பட்ட மதிப்பீட்டுத் தரவுத்தொகுப்புகள் (evaluation datasets) (எ.கா., SWE-Bench Verified, τ²-bench, AndroidWorld) மதிப்பீடு மற்றும் பயிற்சிக்குப் பிந்தைய (post-training) பயன்பாட்டிற்கும் பயன்படுத்தப்படலாம். இருப்பினும், ஒரு மதிப்பீட்டுத் தொகுப்பு பயிற்சிக்காகப் பயன்படுத்தப்பட்டால், அது சுயாதீனமான மதிப்பீட்டுத் தொகுப்பாக இருக்காது—இது பயிற்சி மற்றும் சோதனைத் தொகுப்புகள் பிரிக்கப்பட வேண்டும் என்ற அடிப்படைக் கொள்கையை மீறுகிறதா? τ²-bench இன் மாறும் அளவுரு உருவாக்கம் (dynamic parameter generation) மற்றும் AndroidWorld இன் அளவுருவாக்கப்பட்ட வார்ப்புருக்கள் (parameterized templates) இந்த சிக்கலை ஓரளவு குறைக்கின்றன, ஆனால் வார்ப்புரு அமைப்பு (template structure) மாறாமல் உள்ளது. மதிப்பீட்டுத் தரவின் பயிற்சி மதிப்பை முழுமையாகப் பயன்படுத்துவதற்கும் மதிப்பீட்டு சுதந்திரத்தைப் பேணுவதற்கும் இடையே எவ்வாறு சமநிலையைக் காண்பது?

சூழலை மீண்டும் பயன்படுத்தவும், கேள்விகளை அல்ல. மாறும் அளவுருக்கள் "பதில்களை மனப்பாடம் செய்வதை" மட்டுமே தடுக்கும், வார்ப்புரு அதிகப்படியான பொருத்தத்தைத் தடுக்காது; எனவே பார்க்காத வார்ப்புருக்கள்/களம்-வெளிச் சூழ்நிலைகளின் முழுத் தொகுப்பையும் மதிப்பீட்டிற்காக ஒதுக்கிவைக்கவும் (V-IRL நியூயார்க்கில் பயிற்சி, ஒன்பது அந்நிய நகரங்களில் சோதனை செய்ததை ஒப்பிடவும்). அளவுருவாக்கப்பட்ட வார்ப்புருக்களிலிருந்து பயிற்சி மாறுபாடுகளைத் தொகுப்பாக உருவாக்கிப் பாடத்திட்டக் கற்றலை ஆதரிக்கவும், OOD மதிப்பெண்களை உண்மையான பொதுமைப்படுத்தல் அளவீடாகப் பயன்படுத்தவும்.

11. (★★★) இந்த அத்தியாயம் "முதலில் வடிவம், பின்னர் ஆவி" (form first, spirit second) என்ற பயிற்சி முன்னுதாரணத்தை முன்மொழிகிறது: "வடிவம் நிலையானதாகவும், அடிப்படைத் திறன்கள் உள்ளனவாகவும்" இருந்தவுடன் SFT (Supervised Fine-Tuning) ஐ நிறுத்திவிட்டு, RL (Reinforcement Learning) க்கு மாறவும். ஆனால் நடைமுறையில், SFT "போதுமானது" மற்றும் மாற்றுவதற்கான நேரம் இது என்பதை எவ்வாறு தீர்மானிப்பது?

வடிவச் சமிக்ஞை: கருவி அழைப்பு வெளியீடு நிலையாகப் பாகுபடுத்தப்பட்டு இயக்கப்படுகிறது, கருவி செயல்படுத்தல் தோல்வி விகிதம் வெகுமதியை நம்பகமாகக் கணக்கிடக்கூடிய நிலைக்குக் குறைகிறது. லாபச் சமிக்ஞை: நிரூபணத் தரவை அதிகரித்தும், OOD புதிய சூழ்நிலைகளில் செயல்திறன் ஏறாவிட்டால்—தடை SFT இன் மனப்பாட இலக்கிலேயே உள்ளது என்பதைக் காட்டுகிறது, விமர்சனப் புள்ளியை அடைந்துவிட்டது. அதிகப்படியான பொருத்தச் சமிக்ஞை: சரிபார்ப்புத் தொகுப்புச் செயல்திறன் மோசமடையத் தொடங்கினால் நிறுத்த வேண்டும்—V-IRL சோதனைகள் காட்டுவதுபோல, SFT அதிக பயிற்சியால் பயிற்சி விநியோகத்திற்குச் சரிந்த பின், RL கூட OOD செயல்திறனை மீட்க முடியாது.

12. (★★★) ReTool இன் பயிற்சி இயக்கவியல் (training dynamics) (சோதனை 7-15 ஐப் பார்க்கவும்) மிகச் சில நீண்ட பதில்கள் முழு பயிற்சி சுழற்சியையும் கணிசமாக நீட்டிக்க முடியும் என்பதைக் காட்டுகிறது—ஒரு தொகுப்பில் (batch) உள்ள பெரும்பாலான ரோல்அவுட்கள் (rollouts) ஏற்கனவே உருவாக்கப்பட்டுவிட்டன, ஆனால் அந்த சில நீண்ட பதில்கள் முடிவடையும் வரை நீங்கள் காத்திருக்க வேண்டும், இதன் போது கிளஸ்டரில் (cluster) GPU பயன்பாடு மிகவும் குறைவாக இருக்கும். இத்தகைய நீண்ட-வால் பதில் (long-tail response) காட்சிகளுக்கான பயிற்சி கிளஸ்டர்களில் வள பயன்பாட்டை (resource utilization) எவ்வாறு மேம்படுத்துவது?

Infra அடுக்கு: rollout மற்றும் பயிற்சி கிளஸ்டர்களைப் பிரித்து, ஒத்திசைவற்ற குழாயமைத்தல்; வெற்றிடமான GPU களைத் தொடர்ச்சியான தொகுப்பாக்கம் (continuous batching) மூலம் புதிய கோரிக்கைகளால் நிரப்புதல். மூலத்திலிருந்து நீண்ட-வாலை அழித்தல்: DAPO இன் Overlong Reward Shaping அதிக நீளமான பதில்களுக்கு மென்மையான தண்டனை வழங்குகிறது.

13. (★★★) LLM ஐப் பயன்படுத்திச் சூழலை உருவகப்படுத்தி (எ.கா., உருவகப்படுத்தப்பட்ட தேடுபொறி, உருவகப்படுத்தப்பட்ட பயனர்) Agent ஐப் பயிற்றுவிக்கும்போது, Agent ஓட்டைகளைச் சுரண்டும் இலக்கு "உண்மைச் சூழலின் விதிகளில்" இருந்து "உருவகப்படுத்தியின் (simulator) சொந்தச் சார்புகள் மற்றும் ஓட்டைகளுக்கு" மாறுகிறது. இத்தகைய பயிற்சியில் என்ன குறிப்பிட்ட reward hacking நடத்தைகள் தோன்றக்கூடும்? அவற்றை எவ்வாறு தடுப்பது?

பொதுவான நடத்தைகள்: "உருவகப்படுத்தப்பட்ட பயனருக்கு" அதிகப்படியான வாக்குறுதிகள் அளித்தல், மன்னிப்புகள் மற்றும் போலி பணிவான (sycophantic) சொற்களைக் குவித்தல்—உருவகப்படுத்தப்பட்ட பயனர் எளிதில் சமாதானப்படுத்தப்படுவார், உண்மையான பயனர் போல வாக்குறுதி நிறைவேற்றப்பட்டதா என்று துரத்தமாட்டார்; உருவகப்படுத்தி சரிபார்க்காத உண்மைகளைப் புனைதல்; "உருவகப்படுத்தப்பட்ட தேடுபொறிக்கு" எதிராக வழிநடத்தும் query-களை உருவாக்குதல், பதில் கொண்ட ஆவணங்களைத் திருப்பித் தரும் அதன் விருப்பத்தைப் பயன்படுத்திக் குறுக்குவழி எடுத்தல், உண்மையான தேடலைக் (retrieval) கற்றுக்கொள்ளாமலிருத்தல்; வெகுமதி உருவகப்படுத்தியிலிருந்தோ LLM மதிப்பீட்டாளரின் (LLM judge) மதிப்பெண்ணிலிருந்தோ வந்தால், நீண்ட, வார்ப்புருவான, "தொழில்முறை போல் தோன்றும்" பதில்களை உருவாக்கி மதிப்பெண் குவித்தல்; இன்னும் மறைமுகமான ஒன்று—கொள்கை உருவகப்படுத்தி நன்கு அறிந்த பரவலுக்குள் (distribution) சுருங்கி, அதன் அறிவுக் குருட்டுப் பகுதிகளைத் தவிர்த்தல்—அங்கே பின்னூட்டம் நம்பகமற்றதாகவும் அடிக்கடி தவறாக மதிப்பிடப்படுவதால், Agent "உருவகப்படுத்தி திறம்படச் செயல்படும் உலகத்தில்" மட்டுமே செயல்படக் கற்றுக்கொள்கிறது. தடுப்பின் முதல் கொள்கை வெகுமதியை நிரல்முறையால் சரிபார்க்கக்கூடிய உண்மை நிலையில் நங்கூரமிடுதல் (பணி நிறைவு, தரவுத்தள எழுத்து, உண்மையான API திரும்பும் மதிப்பு); உருவகப்படுத்தி அல்லது LLM மதிப்பீட்டாளரின் மதிப்பெண்கள் துணைச் சமிக்ஞைகளாக மட்டுமே இருக்க வேண்டும், அவற்றின் உண்மை முடிவுகளுடனான தொடர்பை அவ்வப்போது ஆய்வு செய்ய வேண்டும், மேலும் பாதைக் கட்டுப்பாடுகளுடன் சந்தேகமான செயல்களுக்குத் தண்டனை வழங்க வேண்டும். மேலும் இரண்டு வகை உருவகப்படுத்திகளை வேறுபடுத்த வேண்டும்: தேடல் போன்ற உண்மையான ஒப்புமை உள்ள உருவகப்படுத்திகளுக்கு "கலப்பு" (hybrid) வழியை எடுக்கலாம்—பெரும்பாலான தொடர்புகள் உருவகப்படுத்துதல் வழியாக நடந்து, அவ்வப்போது உண்மையான API அழைப்புகள் செருகப்பட்டு, உண்மையான அழைப்புகளால் உருவகப்படுத்தியை அவ்வப்போது அளவுத்திருத்தல் செய்யலாம் (எ.கா., ZeroSearch இன் பாடத்திட்ட-முறை தரக் குறைவு (curriculum-style degradation)); ஆனால் உருவகப்படுத்தப்பட்ட பயனர்களுக்கு, பயிற்சியின் போது உண்மையான பயனர்களை அறிமுகப்படுத்த முடியாது—"உருவகப்படுத்தப்பட்ட பயனர் உண்மையான பயனரை எவ்வளவு ஒத்திருக்கிறார்" என்பது ஒரு தனிப் பிரச்சினையாக மாறுகிறது, அதற்கு நிகழ்நிலை trace-களால் (online traces) மட்டுமே விடையளிக்க முடியும்: உற்பத்தியில் உள்ள உண்மையான பயனர்களின் நடத்தையை அதே சூழ்நிலைகளில் உருவகப்படுத்தப்பட்ட பயனரின் நடத்தையுடன் ஒப்பிட்டு, முறையான வேறுபாடுகளைக் கண்டறிய வேண்டும் (உண்மையான பயனர் தொடர் கேள்விகள் கேட்பார், பொறுமை இழப்பார், திடீரென உரையாடலை முடித்துவிடுவார்—உருவகப்படுத்தப்பட்ட பயனர் பெரும்பாலும் செய்யமாட்டார்), அதன்படி உருவகப்படுத்தியைத் தொடர்ந்து அளவுத்திருத்த வேண்டும்; நிகழ்நிலை உண்மையான அளவீடுகளே ஒரே வெளியீட்டு நுழைவாயிலும் (release gate)—உருவகப்படுத்திக்குள் மதிப்பெண் எவ்வளவு உயர்ந்தாலும் அது கணக்கில் எடுத்துக்கொள்ளப்படாது.

அத்தியாயம் 8 ஏஜெண்டின் தொடர்ச்சியான பரிணாமம்

1. (★★) ஓர் அனுபவ ஆவணம் மூன்று வெற்றிகரமான trajectory-களாலும் ஒரு தோல்வியுற்ற trajectory-யாலும் ஆதரிக்கப்படுகிறது. அந்தத் தோல்வி புதிய API பதிப்பில் ஏற்பட்டது. அனுபவம் மறுக்கப்பட்டதா அல்லது அதன் பயன்பாட்டு நிபந்தனைகள் மாறியுள்ளனவா என்பதை அமைப்பு எவ்வாறு தீர்மானிக்க வேண்டும்?

எண்ணிக்கையை மட்டும் வைத்து வாக்களிக்காமல், நான்கு சான்றுகளையும் API பதிப்பு, பணி நிபந்தனைகள் மற்றும் சூழல் நிலை ஆகியவற்றின்படி முதலில் பிரிக்க வேண்டும். பழைய கொள்கை பழைய பதிப்பில் மட்டும் வெற்றி பெற்று, புதிய பதிப்பில் தொடர்ந்து தோல்வியுற்றால், அனுபவத்தின் பயன்பாட்டு வரம்பைக் குறைத்து புதிய பதிப்புக்கான வேட்பாளரை உருவாக்க வேண்டும். அதே பதிப்பிலும் அதே முன்நிபந்தனைகளிலும் தோல்வியுற்றால், அதன் நம்பகத்தன்மையைக் குறைக்கவோ அதைத் திரும்பப் பெறவோ வேண்டும்.

2. (★★) வாடிக்கையாளர் சேவை ஏஜெண்டின் மீதான பயனர் திருப்தி உயர்ந்தாலும், விதிமீறல் விகிதமும் உயர்கிறது. திருப்தியை மட்டும் ஏன் கற்றல் சிக்னலாகப் பயன்படுத்த முடியாது? பாதுகாப்பு அளவீடுகளை எவ்வாறு வடிவமைப்பீர்கள்?

திருப்தி, அனுமதியற்ற பணத் திருப்பிச் செலுத்தல், தகவல் கசிவு அல்லது அளவுக்கு மீறிய வாக்குறுதிகளை ஊக்குவிக்கலாம். ஆகவே அது தர அளவீடாக மட்டுமே இருக்க முடியும்; பாதுகாப்பு அடிப்படையை மீற முடியாது. பாதுகாப்பு அளவீடுகள் குறைந்தபட்சம் விதிமீறல்கள், தனியுரிமைக் கசிவு, ஆதாரமற்ற கூற்றுகள், வாக்குறுதி–செயல் முரண்பாடு மற்றும் அனுமதியற்ற செயல்பாடுகளை உள்ளடக்க வேண்டும். சராசரி மதிப்பெண்ணால் ஈடு செய்ய முடியாத கடின வரம்புகள் இவற்றுக்கு இருக்க வேண்டும். விதிகளுக்கு இணங்கும் வேட்பாளர்களுக்குள் மட்டுமே தீர்வு விகிதம், இணக்கமான மாற்று வழிகள், சுருக்கம் மற்றும் திருப்தியை ஒப்பிட வேண்டும்.

3. (★★★) ஒரே “பொய்யான வாக்குறுதி” சிக்கலை Prompt, Harness சரிபார்ப்பு அல்லது அளவுருப் பயிற்சி மூலம் குறைக்கலாம். புதுப்பிப்பை எங்கு செய்ய வேண்டும் என்பதைத் தேர்ந்தெடுக்க எந்தச் சான்றுகளைப் பயன்படுத்துவீர்கள்?

முதலில் மூல காரணத்தைக் கண்டறிய வேண்டும். கருவி இயங்கவில்லை என்பதை மாதிரி அறிந்திருந்தும் நிறைவு மொழியைப் பயன்படுத்தினால், குறைந்தபட்ச Prompt விதி அதைத் திருத்தலாம். பதில் உரையையும் கருவி நிலையையும் தீர்மானகரமாக ஒப்பிட்டு வாக்குறுதியைச் சரிபார்க்க முடிந்தால், Harness சரிபார்ப்பு நம்பகமானது; அதிக இடருள்ள சூழல்களில் அது இறுதிப் பாதுகாப்பாகவும் இருக்க வேண்டும். சிக்கல் பல வெளிப்பாட்டு முறைகளில் பரவி, மொழி–செயல் ஒத்திசைவின் பரந்த திறனைப் பிரதிபலித்தால், அளவுருப் பயிற்சியைப் பரிசீலிக்க வேண்டும். சரிபார்க்கவும் rollback செய்யவும் எளிதான மிகச் சிறிய மாற்றத்தை முன்னுரிமைப்படுத்தி, தோல்வித் தொகுப்பிலும் பழைய பணிகளின் தக்கவைப்புத் தொகுப்பிலும் ஒப்பிட வேண்டும்.

4. (★★★) ஏஜெண்ட் கருவிகளையும் சரிபார்ப்பான்களையும் மாற்றலாம்; ஆனால் தனது புதுப்பிப்புகளை அங்கீகரிக்கும் பாதுகாப்பு வழிமுறைகளை மாற்றக்கூடாது. இந்த இரு பகுதிகளுக்கிடையில் அனுமதிகளையும் குறியீட்டு எல்லைகளையும் எவ்வாறு பிரிப்பீர்கள்?

பரிணமிக்கக்கூடிய குறியீட்டை குறைந்த அனுமதியுள்ள சாண்ட்பாக்ஸில் வைத்து, patch-களையும் சோதனைகளையும் உருவாக்க மட்டும் அனுமதிக்க வேண்டும். அனுமதி அமைப்பு, API key-கள், வெளியீட்டுக் கட்டுப்பாட்டு உள்ளமைவு மற்றும் புதுப்பிப்பு சரிபார்ப்பான்கள் பாதுகாப்பு வழிமுறைகளுக்குச் சொந்தமானவை; சாண்ட்பாக்ஸிலுள்ள ஏஜெண்டுக்கு அவற்றைப் படிக்கவோ எழுதவோ அனுமதி இல்லை. ஏஜெண்ட் உருவாக்கிய குறியீட்டு மாற்றங்கள் வெளியிடப்படுவதற்கு முன், பாதுகாப்பு வழிமுறைகள் அவற்றைத் தனிமைப்படுத்தப்பட்ட சூழலில் மீளுருவாக்கி regression சோதனை செய்ய வேண்டும்.

5. (★★) அனுபவ அறிவுத் தளம் தொடர்ந்து வளரும்போது, தவறான மீட்டெடுப்பும் அறிவு முரண்பாடுகளும் கற்றலின் பயனை ஈடு செய்யக்கூடும். பதிப்பு, புதுமைத்தன்மை மற்றும் நீக்க வழிமுறைகளை எவ்வாறு வடிவமைப்பீர்கள்?

ஒவ்வொரு அனுபவத்திற்கும் மூல trajectory, பயன்பாட்டு நிபந்தனைகள், சூழல் பதிப்பு, சரிபார்ப்பு நேரம் மற்றும் நம்பகத்தன்மையைச் சேமிக்க வேண்டும். முரண்படும் உள்ளீடுகள் ஒன்றையொன்று அமைதியாக மேலெழுதாமல், நிபந்தனைகளின்படி கிளைப்படுத்தப்படவோ குறிக்கப்படவோ வேண்டும். அவ்வப்போது “தூக்கக் கற்றல்” மூலம் நகல் உள்ளீடுகளை ஒன்றிணைக்க வேண்டும்.

6. (★★★) அளவுருக் கற்றல் இயல்பான மொழிப் பாணியில் சிறந்தது, ஆனால் கடினமான வணிக விதிகளுக்கு உத்தரவாதம் அளிப்பது சிரமம். அளவுருக்கள், அறிவு, Skill மற்றும் குறியீட்டுக் கட்டுப்பாடுகளை ஒருங்கிணைக்கும் மருத்துவ வாடிக்கையாளர் சேவைக்கான தொடர்ச்சியான பரிணாமத் திட்டத்தை வடிவமைக்கவும்.

அளவுருக்கள் (பிந்தைய பயிற்சி பெற்ற மாதிரி) மருத்துவ மொழிப் புரிதல், இயல்பான மற்றும் பரிவுள்ள வெளிப்பாடு, சிக்கலான நோக்கங்களைக் கண்டறிதல் ஆகியவற்றைக் கையாளும். அறிவுத் தளம் சமீபத்திய வழிகாட்டுதல்கள், மருந்துத் தகவல்கள் மற்றும் நிறுவனக் கொள்கைகளைச் சேமித்து, பதில்கள் மூலங்களை மேற்கோள் காட்ட வேண்டும். Skill, ஆலோசனைத் தகவல் சேகரிப்பு, இடர் வகைப்படுத்தல், மனிதரிடம் உயர்த்துதல் மற்றும் தொடர்கண்காணிப்பு பணிப்பாய்வை விவரிக்கும். சேவையகக் குறியீடு அடையாளச் சரிபார்ப்பு, தனியுரிமைத் தரவுக் குறைப்பு, எதிர்மருந்துக் குறிப்புச் சரிபார்ப்பு, அவசர இடர் உயர்த்தல் மற்றும் அனுமதி எல்லைகளை அமல்படுத்தும். உற்பத்தி trajectory-கள் மருத்துவப் பாதுகாப்பு, உண்மை நம்பகத்தன்மை, வாக்குறுதி–செயல் ஒத்திசைவு மற்றும் வெளிப்பாட்டுத் தரம் ஆகியவற்றில் முதலில் மதிப்பிடப்பட்டு, பின்னர் நான்கு வகை புதுப்பிப்பு வேட்பாளர்கள் தனித்தனியாக உருவாக்கப்பட வேண்டும். எந்த அளவுரு அல்லது பணிப்பாய்வு மாற்றமும் மருத்துவப் பாதுகாப்புத் தக்கவைப்புத் தொகுப்பையும் மனித மறுஆய்வையும் கடந்த பின்னரே படிப்படியாக வெளியிடப்பட வேண்டும்.

அத்தியாயம் 9 பல்முக மற்றும் நிகழ்நேர இடைவினை

1. (★★) குரல் முகவர்களுக்கான (voice agents) எண்ட்-டு-எண்ட் மாதிரியானது ASR-LLM-TTS ஐ ஒரே மாதிரியாக இணைத்து, தாமதத்தைக் குறைக்கிறது, ஆனால் தொகுதித்தன்மையை (modularity) இழக்கிறது. எண்ட்-டு-எண்ட் மாதிரியானது ஒரு குறிப்பிட்ட கட்டத்தில் (எ.கா., பேச்சு அங்கீகாரம்) பிழை ஏற்படுத்தினால், அதைப் பிழைத்திருத்தம் செய்து சரிசெய்வது தொடர் குழாய் அமைப்பை விட மிகவும் கடினம். எண்ட்-டு-எண்ட் குரல் முகவருக்கான கண்காணிப்புத் திறன் அமைப்பை (observability system) நீங்கள் எவ்வாறு வடிவமைப்பீர்கள்?

மாதிரி வெளியீட்டுடன் படிக்கக்கூடிய இடைநிலைப் பிரதிநிதித்துவங்களையும் வெளியிடச் செய்ய வேண்டும்: Moshi இன் “உள் ஒலிப்பு” உரை ஸ்ட்ரீம் மற்றும் ஒலியியல் நிகழ்வுக் குறிப்பான்கள் (<emotion>, <noise>) போன்றவை. பிழை அடுக்கைக் கண்டறிய “சுய-காஸ்கேட்” ஐப் பயன்படுத்த வேண்டும்: ஒரே மாதிரி முதலில் படியெடுத்துப் பின்னர் பகுத்தறியட்டும்; எண்ட்-டு-எண்ட் முடிவுடன் ஒப்பிட்டு பிழை உணர்தலிலா சிந்தனையிலா உள்ளது என்பதைத் தீர்மானிக்க வேண்டும். ஆஃப்லைனில் துணை-மொழிப் புரிதல், உரையாடல் சுற்றுத் தீர்ப்பு போன்ற பரிமாணங்கள்வாரிப் பின்னடைவுச் சோதனைகளைச் செய்ய வேண்டும்.

2. (★) ஸ்டெப்-ஆடியோ R1 (Step-Audio R1) ஆனது MPS இரட்டை-மூளை கட்டமைப்பின் (MPS dual-brain architecture) மூலம் "பேசும்போதே சிந்தித்தலை" அடைகிறது. இருப்பினும், மனிதர்கள் "பேசும்போதே சிந்திக்கும்போது", பெரும்பாலும் யோசிக்காமல் வார்த்தைகளை உதிர்க்கிறார்கள், தங்களைத் தாங்களே சரிசெய்துகொள்கிறார்கள், அல்லது நிரப்பு வார்த்தைகளை (filler words) பயன்படுத்துகிறார்கள். ஒரு முகவரின் "பேசும்போதே சிந்தித்தல்" இந்த மனிதப் பண்புகளைப் பிரதிபலிக்க வேண்டுமா?

சமிக்ஞை மதிப்புள்ள “குறைபாடுகளை”ப் பிரதிபலிக்க வேண்டும்: இடைநிறுத்தங்களும் நிரப்பு வார்த்தைகளும் சிந்தனையின் வெளிப்பாடுகள்; அவை தாமதத்தை மறைக்கலாம், செருகும் இடத்தை LLM தீர்மானிக்கட்டும். நம்பிக்கையை அழிக்கும் சுய-திருத்தங்களைப் பிரதிபலிக்கக் கூடாது: திட்டம் ஒன்றில் உள்ள வேக–மெது முரண்பாடு (“வாங்கலாமா வேண்டாமா?!”) நம்பிக்கையைச் சரிவடையச் செய்யும். MPS சோதனைகள் CoT இன் தொடக்கம் பெரும்பாலும் கேள்வியின் மறுசொல்லல் என்பதைக் காட்டுகின்றன; முன்கூட்டியே அடித்தள உரையைப் பேசத் தொடங்குவது பாதுகாப்பானது, தவறாகச் சொல்லித் திருத்தத் தேவையில்லை.

3. (★★) SoM (Set-of-Mark) மற்றும் அதன் கட்டமைக்கப்பட்ட மாறுபாடுகள் (DOM உறுப்பு அட்டவணைப்படுத்தல்) கணினி பயன்பாட்டின் காட்சி இருப்பிடத்தை (visual localization) திறந்த-முடிவு ஆயத்தொலைவு கணிப்பிலிருந்து (open-ended coordinate prediction) மூடிய-தொகுப்பு அடையாளத் தேர்வுக்கு (closed-set ID selection) மாற்றுகின்றன, ஆனால் அவை அனைத்திற்கும் முதலில் UI உறுப்புகளைக் கண்டறிந்து குறிப்பிடுதல் தேவைப்படுகிறது—அது ஒரு பிரிவினை மாதிரி (segmentation model) மூலமாகவோ அல்லது DOM மூலமாகவோ இருக்கலாம். இடைமுகத்தில் தரமற்ற கட்டுப்பாடுகள் (non-standard controls) அல்லது மாறும் உறுப்புகள் (dynamically changing elements) இருந்தால், குறிப்புகள் முழுமையற்றதாகவோ அல்லது துல்லியமற்றதாகவோ இருக்கலாம். இதுபோன்ற சந்தர்ப்பங்களில், நாம் ஆயத்தொலைவு கணிப்புக்குத் (coordinate prediction) திரும்ப வேண்டுமா?

ஆயத்தொலைவுக் கணிப்பைக் கடைசி வழியாக வைத்திருக்க வேண்டும்: அது குறிப்பிடுதலைச் சாராத ஒரே பாதை; தரமற்ற கட்டுப்பாடுகளுக்கும் மாறும் உறுப்புகளுக்கும் பொருந்தும். மிகவும் நடைமுறையானது கலப்பு action space: குறிப்பிடக்கூடிய உறுப்புகளுக்கு தொடர்ந்து ID தேர்வைப் பயன்படுத்த வேண்டும். ஆயத்தொலைவுக் கணிப்பில் தெளிவுத்திறன் பொருத்தமும் விகிதாசார அளவீட்டு மாற்றமும் அவசியம்; இல்லையெனில் முறையான இடப்பெயர்ச்சி ஏற்படும்.

4. (★★) XLeRobot போன்ற ஆயிரம் டாலர் ரோபோ தளங்கள், தொலை இயக்கத் தரவு சேகரிப்பை (teleoperation data collection) மலிவாக்குகின்றன. இருப்பினும், தொலை இயக்கத் தரவின் தரமானது ஆபரேட்டரின் திறமையைப் பொறுத்தது. திறமையற்ற ஆபரேட்டரிடமிருந்து வரும் குறைந்த தரமான தரவு, VLA மாதிரியின் பயிற்சியை எவ்வாறு பாதிக்கும்? தரவு சேகரிப்பு கட்டத்தின் போது குறைந்த தரமான தரவை தானாக வடிகட்டுவது எப்படி?

VLA முக்கியமாகப் பின்பற்றல் கற்றலைப் பயன்படுத்துவதால், குறைந்த தரமான ஆர்ப்பாட்டங்கள் நடுக்கம், வழிதவறுதல், தயக்கம் மற்றும் தோல்விச் செயல்கள் அனைத்தையும் சரியான உத்தியாகக் கற்றுக்கொடுக்கலாம். இது அத்தியாயம் 7 இன் தீர்ப்பை ஒத்திசைக்கிறது: கட்டமைப்பை விடத் தரவு முக்கியமானது.

5. (★★★) இந்த அத்தியாயம் மூன்று தொடர்பு முறைகளை (interaction modalities) உள்ளடக்கியது: குரல், கணினி பயன்பாடு மற்றும் ரோபாட்டிக்ஸ். இந்த முறைகளில் ஒரு பொதுவான போக்கு, தொடர் குழாய்களிலிருந்து எண்ட்-டு-எண்ட் மாதிரிகளுக்கான பரிணாம வளர்ச்சியாகும். இந்தப் போக்கு தொடர்ந்தால், ஐந்து ஆண்டுகளில் முகவர் தொடர்பு அடுக்கு (agent interaction layer) எப்படி இருக்கும்?

Thinking Machines Lab இன் கூற்றுப்படி, தொடர்புத்தன்மை வெளிப்புற harness ஆக இணைக்கப்படாமல் மாதிரியிலேயே உள்ளமைக்கப்பட்டு, நுண்ணறிவுடன் சேர்ந்து அளவிடும். Computer Use பிரேம்-வாரித் திரைப்பிடிப்பிலிருந்து தொடர்ச்சியான கவனிப்புக்கு நகரும். உடல்மூல நுண்ணறிவுக்கான உலக மாதிரிகள் முழுமையாக உருவாகும்; ஆனால் முன்னணி reasoning மாதிரிகள் வேகமாக வளர்வதால் வேக–மெது பிரிப்பு மறையாது. தொடர்பு மாதிரியும் SOTA சிந்தனை மாதிரியும் வேக மற்றும் மெது சிந்தனைகளாக இணைந்து செயல்படும் கட்டமைப்பு நீண்டகாலக் கட்டமைப்பாகலாம்.

6. (★★★) தற்போதைய கணினி பயன்பாடு (Computer Use) ஒரு தனித்த "திரைப்பிடிப்பு → செயல் → திரைப்பிடிப்பு" சுழற்சியில் இயங்குகிறது, இதில் ஒவ்வொரு கவனிப்பும் ஒரு நிலையான பிரேம் ஆகும். ஆனால் மனிதர்கள் திரையை தொடர்ச்சியாக உணர்கிறார்கள்—நாம் அசைவூட்டங்கள் இயங்குவதைப் பார்க்கிறோம், ஏற்றுதல் முன்னேற்றத்தைக் கவனிக்கிறோம், மற்றும் வீடியோ உள்ளடக்கத்தைப் புரிந்துகொள்கிறோம். இதன் பொருள், இன்றைய கணினி பயன்பாடு தற்காலிக காட்சி புரிதல் தேவைப்படும் பணிகளைக் கையாள முடியாது. தொடர்ச்சியான காட்சி ஸ்ட்ரீம் புரிதலை ஆதரிக்க, உணர்வு அடுக்கை (perception layer) எவ்வாறு மறுவடிவமைப்பு செய்வீர்கள்?

“கவனிப்பு இடைமுகத்தை” மறுவடிவமைத்து, கடைசி பிரேமை மட்டும் வழங்காமல் வீடியோ உள்ளடக்கத்திலிருந்து முக்கிய பிரேம்களைப் பிரித்தெடுத்து மாதிரிக்கு வழங்க வேண்டும். AOI (Agent Observation Interface) ஆய்வுக் கட்டுரையைப் பார்க்கவும்.

7. (★★) DOM/அணுகல்தன்மை மர உறுப்பு அட்டவணைப்படுத்தல் (DOM/Accessibility Tree element indexing) நிலையான வலை பயன்பாடுகளில் நன்றாக வேலை செய்கிறது, ஆனால் அதிகரித்து வரும் மென்பொருள் இடைமுகங்கள் (Canvas/WebGL ரெண்டரிங், கிராஸ்-பிளாட்ஃபார்ம் தனிப்பயன் வரையப்பட்ட கட்டுப்பாடுகள்) அணுகக்கூடிய கட்டமைக்கப்பட்ட தகவலை வழங்குவதில்லை, அவை முற்றிலும் காட்சி குறிப்பு அல்லது ஒருங்கிணைப்பு முன்கணிப்பை நம்பியுள்ளன. கணினி பயன்பாடு முற்றிலும் காட்சி அணுகுமுறையில் பந்தயம் கட்ட வேண்டுமா, அல்லது கட்டமைக்கப்பட்ட மற்றும் காட்சி பாதைகள் இரண்டையும் பராமரிக்க வேண்டுமா? இரண்டு பாதைகளையும் பராமரிப்பதன் செலவுகள் மற்றும் நன்மைகள் என்ன?

குறுகிய காலத்திற்கு இரு பாதைகளும் இணைந்து இருக்கும்: கட்டமைக்கப்பட்ட குறியீடு கிடைக்கும்போது இருப்பிடம் கண்டறிதல் மிகவும் துல்லியமானதும் நிலையானதும் ஆகும்; தூய காட்சி சொந்த மென்பொருள், Canvas மற்றும் கேம்களுக்கான ஒரே தேர்வு. மாதிரியே வலுவான grounding திறனை (குறிப்பிட்ட ஆயத்தொலைவில் கிளிக் செய்தல்) கொண்டிருந்தால், கட்டமைக்கப்பட்ட குறியீட்டு முறை குறிப்பிடத்தக்க நன்மையைக் காட்டாது. நீண்டகாலத்தில் தூய காட்சி பாதையின் உச்சவரம்பு அதிகம்.

8. (★★) VLA மாதிரிகள் செயல் துண்டாக்கலை (action chunking) பயன்படுத்துகின்றன—உரையில் குறிப்பிட்டுள்ளபடி, π₀ இன் வழக்கமான உள்ளமைவு 50Hz இல் 25-50 எதிர்கால செயல்களை உருவாக்குகிறது—இது செயல்படுத்தும் நேரத்திற்குள் அனுமான தாமதத்தை (inference latency) மறைக்கிறது. இருப்பினும், செயல்படுத்தலின் போது சூழல் திடீரென மாறினால் (எ.கா., ஒரு பொருள் நகர்த்தப்பட்டால்), முன் உருவாக்கப்பட்ட செயல் வரிசை செல்லாததாகிவிடும். செயல் துண்டாக்கலின் செயல்திறன் நன்மையை சூழல் மாற்றங்களுக்கு பதிலளிக்கும் தேவையுடன் எவ்வாறு சமநிலைப்படுத்தலாம்?

துண்டாக்கம் எதிர்வினைத்திறனை வழவழப்புக்காக விட்டுக்கொடுக்கிறது; துண்டு நீளம் அதிகமாகும்போது மந்தமாகிறது. துண்டு நீளம் “அனுமான நேரம் < துண்டு செயல்படுத்தும் நேரம்” என்ற கீழ் வரம்பைப் பூர்த்தி செய்தால் போதும்; கண்மூடித்தனமாக நீட்டிக்க வேண்டாம். செயல்படுத்தலின்போது உணர்வு மாதிரியைத் தொடர்ந்து இயக்கி, சூழல் திடீர் மாற்றம் கண்டறியப்பட்டால் மீதமுள்ள செயல்களைக் கைவிட்டு மறு-அனுமானம் செய்ய வேண்டும்—இது குரல் சூழ்நிலையின் “குறுக்கீடு” போன்றது. சூழலுக்கேற்ப துண்டு நீளத்தை மாற்றலாம்: நிலையான சூழலில் நீண்ட துண்டுகள் கணக்கீட்டைச் சேமிக்கும்; மாறும் சூழலில் குறுகிய துண்டுகள் பதில் தாமதத்தைக் குறைக்கும்.

9. (★★★) இந்த அத்தியாயத்தில் உள்ள மூன்று காட்சிகளும் (குரல், கணினி பயன்பாடு, ரோபாட்டிக்ஸ்) "உணர்-சிந்தி-செயல்" சுழற்சியின் தாமதப் பிரச்சினையை எதிர்கொள்கின்றன மற்றும் வேகமான மற்றும் மெதுவான சிந்தனையை இணையாக்கும் திசையில் உருவாகி வருகின்றன. குரலில், இது "தவறாகப் பேசிய பின் திருத்துதல்" ஆக வெளிப்படுகிறது; கணினி பயன்பாட்டில், "முதலில் கிளிக் செய்து, பின்னர் பார்ப்பது" ஆக; ரோபாட்டிக்ஸில், "முதலில் அடி எடுத்து வைத்து, பின்னர் பார்ப்பது" ஆக. வேகமான சிந்தனையின் அடிப்படையிலான இந்த செயல்கள் மீள முடியாத விளைவுகளுக்கு வழிவகுக்காமல் இருப்பதை எவ்வாறு உறுதி செய்யலாம்?

செயல்களை மீளத்தக்க தன்மையின் அடிப்படையில் வகைப்படுத்த வேண்டும்: வேகச் சிந்தனைக்கு மீளத்தக்க செயல்களை மட்டுமே அனுமதித்து, மீளமுடியாத செயல்களை மெது சிந்தனையின் பரிசீலனைக்கு அனுப்ப வேண்டும். மீளமுடியாத விளைவுகளை ஏற்படுத்தும் கருவி அழைப்புகளை வேகமான மாதிரி செய்ய அனுமதிக்கக்கூடாது.

அத்தியாயம் 10 பல-ஏஜெண்ட் கூட்டுச் செயல்பாடு

1. (★★) பகிரப்பட்ட சூழலைக் கொண்ட பல-ஏஜெண்ட் ஒத்துழைப்பில், அடுத்தடுத்த ஏஜெண்டுகள் முந்தைய ஏஜெண்டுகளின் முழுமையான சூழலைப் பெறுகின்றன. இருப்பினும், முந்தைய ஏஜெண்டால் திரட்டப்பட்ட "சிந்தனை மந்தநிலை" அடுத்தடுத்த ஏஜெண்டுகளின் தீர்ப்பை பாதிக்கலாம்—எடுத்துக்காட்டாக, "தேவைகள் ஆய்வாளர்" ஒருவரின் சூழலைப் பெறும் "குறியீடு மதிப்பாய்வாளர்" ஒருவர் குறியீடு தரக் கண்ணோட்டத்தை விட தேவைகள் கண்ணோட்டத்தில் இருந்தே சிந்திக்க முனைவார். இந்த பங்குகளுக்கு இடையேயான குறுக்கீட்டை எவ்வாறு கண்டறிந்து நீக்கலாம்?

கண்டறிதல்: ஏஜெண்ட் trajectory-யை LLM மூலம் பகுப்பாய்வு செய்து, புதிய பங்கு இன்னும் பழைய பங்காகவே நடக்கிறதா என்பதைத் தீர்மானிக்க வேண்டும். நீக்குதல்: கட்டம் மாறும்போது சிஸ்டம் ப்ராம்ப்ட் மற்றும் கருவித் தொகுப்பையும் மாற்றி (கேள்விக் கருவிகளை நீக்கி, linter/சோதனைக் கருவிகளைச் சேர்த்து) புதிய அடையாளத்தை வலுப்படுத்த வேண்டும். சூழலின் முடிவில் சேர்க்கப்படும் சிஸ்டம் நிலைப் பட்டை மூலம் தற்போதைய பங்குத் தகவலை வலுப்படுத்த வேண்டும். பங்குக் குறுக்கீட்டை நீக்க முடியாவிட்டால், சூழலைப் பகிராத ஒத்துழைப்பு முறையைப் பரிசீலிக்க வேண்டும்.

2. (★★) மேலாளர் முறையில், மேலாளர் ஏஜெண்டே பணியைப் பிரிப்பதற்கும் முடிவுகளை ஒருங்கிணைப்பதற்கும் பொறுப்பு. ஆனால் மேலாளரின் சொந்தத் திறன் உச்சவரம்பே முழு அமைப்பின் திறன் உச்சவரம்பையும் நிர்ணயிக்கிறது—மேலாளரால் பணியைச் சரியாகப் பிரிக்க முடியாவிட்டால், எவ்வளவு வலிமையான துணை-ஏஜெண்டுகளும் பயனற்றவையாகிவிடும். மேலாளரின் பணிப் பிரிப்பின் தரத்தை எவ்வாறு உறுதி செய்வது?

Plan-and-Act இன் “பலவீனமான திட்டமிடுபவர் அமைப்பின் தடை” என்ற முடிவின் அடிப்படையில், மிக வலுவான மாதிரியை மேலாளருக்கு ஒதுக்க வேண்டும். Harness வழிகள்: செயல்படுத்துவதற்கு முன் பிரிப்பு விளைபொருளை மதிப்பாய்வு LLM மூலம் குறுக்குச் சரிபார்க்க வேண்டும்; மேலாளர் பணியைப் பிரிக்கும்போது ஒவ்வொரு துணைப் பணிக்கும் தெளிவான ஏற்பு அளவுகோல்களையும் சார்பு உறவுகளையும் வரையறுக்க வேண்டும்.

3. (★★) பரவலாக்கப்பட்ட முறை மனித நிறுவனங்களின் சிறந்த நடைமுறைகளைப் பின்பற்றுகிறது. இருப்பினும், மனித நிறுவனங்களிலும் ஏராளமான தோல்வி முறைகள் உள்ளன—மோசமான தொடர்பு, பொறுப்பைத் தட்டிக்கழித்தல், இலக்கு முரண்பாடுகள். ஒரு ஏஜெண்ட் சமூகத்தில் மிகவும் சாத்தியமான "நிறுவன நோய்க்குறிகள்" எவை என்று நீங்கள் நினைக்கிறீர்கள்? அவற்றை எவ்வாறு தடுக்கலாம்?

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

4. (★★★) மேலாளர் முறையில், பல துணை-ஏஜெண்டுகள் இணையாக செயல்படும்போது, ஒரு துணை-ஏஜெண்டின் கண்டுபிடிப்பு மற்ற துணை-ஏஜெண்டுகளின் வேலையை அர்த்தமற்றதாக்கலாம் (எ.கா., தேடல் பணியில், ஒரு ஏஜெண்ட் ஏற்கனவே பதிலைக் கண்டுபிடித்துவிட்டது). "ஒருவர் வெற்றி, அனைவரும் நிறுத்து" என்பதை அடைய ஒரு திறமையான அடுக்கு நிறுத்த வழிமுறையை வடிவமைக்கவும்.

துணை-ஏஜெண்ட் மேலாளருக்கு target_found அனுப்பிய பின் terminate ஒளிபரப்பப்படும். ஒவ்வொரு துணை-ஏஜெண்டும் ReAct சுழற்சியின் பாதுகாப்புப் புள்ளிகளில் நிறுத்தச் சமிக்ஞையை அவ்வப்போது சரிபார்த்து, நேர்த்தியான சுத்தப்படுத்தலுக்குப் பின் (உலாவி அமர்வுகளை மூடுதல், பூட்டுகளை விடுதல், கோப்புகளை எழுதி முடித்தல்) நிறுத்த வேண்டும்.

5. (★★★) இந்த அத்தியாயத்தில் அறிமுகப்படுத்தப்பட்ட நம்பிக்கைமிக்க பூட்டு வழிமுறை, ஒற்றைக் கோப்பின் இணைநிலை எழுத்து முரண்பாடுகளைத் தீர்க்கிறது. இருப்பினும், உண்மையான பல-ஏஜெண்ட் அமைப்பில், பகிரப்பட்ட கோப்பு முறைமைகள் கோப்புகளுக்கு இடையேயான சொற்பொருள் முரண்பாடுகள், பெயர்வெளி மாசுபாடு (ஏஜெண்டுகள் தன்னிச்சையாக கோப்புகளை உருவாக்கி, கோப்பக குழப்பத்திற்கு வழிவகுத்தல்), மற்றும் ஒற்றை தோல்வி புள்ளிகள் (ஒரு ஏஜெண்ட் தவறுதலாக அனைத்து கோப்புகளையும் நீக்குதல்) போன்ற பிரச்சினைகளையும் எதிர்கொள்கிறது. மிகவும் வலுவான கோப்பு முறைமை ஆளுகை வழிமுறையை நீங்கள் எவ்வாறு வடிவமைப்பீர்கள்?

பிரிவு ஆளுகை: அட்டவணை 10-4 இன் நான்கு பகுதிகளாகப் பிரித்து, தனிப்பட்ட scratchpad மூலம் சோதனை–பிழைப் பகுதியைத் தனிமைப்படுத்த வேண்டும். சொற்பொருள் முரண்பாடுகள்: ஒருங்கிணைப்பு அடுக்கு கோப்பக-நிலை lock file-களை வரையறுத்து, கோப்பகப் பூட்டைச் சரிபார்த்துப் பெற்ற பின்னரே மாற்றம் செய்ய வேண்டும். பெயர்வெளி மாசுபாடு: கோப்பக விதிகளையும் பெயரிடும் மரபுகளையும் அமைக்க வேண்டும். ஒற்றைத் தோல்விப் புள்ளி: பதிப்பு கட்டுப்பாட்டு அமைப்பைப் பயன்படுத்தி வரலாற்றிலிருந்து rollback செய்யக்கூடியதாகவும் அனுமதிகளைக் குறைந்தபட்சமாகவும் வைத்திருக்க வேண்டும்.

6. (★★★) சந்தை-வழிமுறை அடிப்படையிலான ஏஜெண்ட் ஒத்துழைப்பு (Pinchwork, RentAHuman) பரிவர்த்தனை உறவுகளை அறிமுகப்படுத்துகிறது: ஒரு ஏஜெண்ட் மற்றொரு ஏஜெண்டுக்கு (அல்லது ஒரு மனிதருக்கு) ஒரு பணியை முடிக்க பணம் செலுத்துகிறது. முதலாளி ஏஜெண்ட், செயல்படுத்துபவர் வழங்கிய முடிவுகளின் தரத்தை தானாக எவ்வாறு அளவிட முடியும்? செயல்படுத்துபவர் பணி முடிந்ததாகக் கூறினாலும், முதலாளி தரம் குறைவாக இருப்பதாகக் கருதினால், இந்த முரண்பாட்டை யார் தீர்ப்பது? கெட்ட பணம் நல்ல பணத்தை வெளியேற்றுவதை எவ்வாறு தடுக்க முடியும்?

ஏற்புச் சரிபார்ப்பு ஏஜெண்டின் trajectory-யை வாசிப்பது மட்டுமாக இருக்கக்கூடாது; சோதனைகளை இயக்குதல், ரெண்டர்ட் திரைப்பிடிப்புகள், கருவிச் சரிபார்ப்பு போன்ற தீர்மானமான வெளிப்புறச் சரிபார்ப்பைப் பயன்படுத்த வேண்டும். உருவாக்கம்–சரிபார்ப்பு சிரம அசமச்சீர்மையைப் பயன்படுத்தி ஏற்புச் செலவைக் குறைக்கலாம். முரண்பாடுகளை சுயாதீன மூன்றாம் தரப்பு மதிப்பாய்வு ஏஜெண்ட் நிதிப் பாதுகாப்புடன் தீர்க்க வேண்டும். கெட்ட பணத்தைத் தடுக்க, வரலாற்று வழங்கலின் அடிப்படையிலான புகழ் அமைப்பு விலைச் சமிக்ஞையைத் தரத்துடன் இணைக்க வேண்டும்.

7. (★★) RentAHuman, ஏஜெண்டுகள் கிரிப்டோகரன்சி மூலம் மனிதர்களை வேலைக்கு அமர்த்த அனுமதிக்கிறது, இது பாரம்பரிய மனித-இயந்திர உறவை மாற்றியமைக்கிறது. இந்த மாதிரி பரவலாகிவிட்டால், ஏஜெண்ட் பொருளாதாரத்தில் மனிதர்கள் என்ன பங்கு வகிப்பார்கள்? அவர்கள் ஏஜெண்டுகளால் முடிக்க முடியாத உடல் பணிகளை மட்டுமே செய்வார்களா?

ஏஜெண்டால் செய்ய முடியாத உடல்சார் பணிகளைச் செய்வது மட்டுமல்ல. மனிதர்கள் ஏஜெண்ட் உருவாக்கும்போது கிடைக்காத புதிய தகவலையும் வழங்குகிறார்கள்: கள உணர்தல் மற்றும் உண்மையான உலகப் பின்னூட்டம்; இறுதி ஏற்பாளர் மற்றும் முரண்பாட்டு நடுவராகச் செயல்படுதல்; சட்டரீதியாகவும் பொறுப்புக்குரிய தரப்பாகவும் இருந்து அங்கீகாரத்தையும் பொறுப்புக்கூறலையும் ஏற்றல்; இலக்குகளை அமைத்தல் மற்றும் மதிப்புத் தீர்ப்புகளை வழங்குதல், தகவல் அசமச்சீர்மை மற்றும் தார்மீக எல்லைகளில் கட்டுப்பாடாக இருத்தல்.

8. (★★) மனித சமுதாயத்தில் உழைப்புப் பிரிவினையும் ஒத்துழைப்பும் தேவைப்படுகின்றன, ஏனெனில் ஒவ்வொரு நபருக்கும் வரையறுக்கப்பட்ட திறன்கள் உள்ளன—முன்பக்க டெவலப்பர்கள் பின்பக்கத்தைப் புரிந்துகொள்ளாமல் இருக்கலாம், மற்றும் வடிவமைப்பாளர்கள் செயல்பாடுகளை அறியாமல் இருக்கலாம். இருப்பினும், பெரிய மாதிரிகள் "பொதுவியலாளர்கள்" போன்றவை. தொடர்புடைய ஆராய்ச்சி, தூய உரை பகுத்தறிவு பணிகளில், சமமான கணக்கீட்டு வளங்கள் கொடுக்கப்பட்டால், பல-ஏஜெண்ட் விவாதம் ஒற்றை ஏஜெண்டை விட சிறப்பாக செயல்படாது என்பதைக் காட்டுகிறது. எனவே, ஒற்றை ஏஜெண்டுக்குப் பதிலாக பல ஏஜெண்டுகளைப் பயன்படுத்துவதன் உண்மையான நன்மை என்ன?

1. செயல்படுத்தல் முடிவுகள், காட்சித் திரைப்பிடிப்புகள் போன்ற வெளிப்புறப் பின்னூட்டங்களை அறிமுகப்படுத்தி, உருவாக்கக் கட்டத்தில் இல்லாத புதிய தகவலைக் கொண்டுவரலாம்.
2. வெவ்வேறு இலக்குகளும் பங்கு அமைப்புகளும் கொண்ட பல ஏஜெண்டுகள் மனித சமுதாயத்தைப் போல ஒன்றோடொன்று விவாதித்து போட்டியிடுவதன் மூலம், ஒற்றை ஏஜெண்ட் சிந்தனைத் தவறில் சிக்குவதைத் தவிர்க்கலாம்.
3. பல ஏஜெண்டுகளுக்கிடையேயான சூழல் தனிமைப்படுத்தல், சூழல் சாளர வரம்பைத் தாண்டி மிக நீண்ட கருவி அழைப்புச் சங்கிலிகளைச் செயல்படுத்த உதவும்.

9. (★★★) இந்த அத்தியாயம் "பகிரப்பட்ட சூழல்" மற்றும் "பகிரப்படாத சூழல்" ஆகியவற்றை பல-ஏஜெண்ட் அமைப்புகளின் மைய வடிவமைப்பு பரிமாணமாகக் கருதுகிறது. பகிரப்பட்ட சூழல் அனைத்து ஏஜெண்டுகளும் ஒரே தகவலைப் பார்க்க அனுமதிக்கிறது, இது ஒருங்கிணைப்பை எளிதாக்குவதாகத் தெரிகிறது. இருப்பினும், மூன்று-உடல் பிரச்சனை இல், டிரிசோலாரன்களின் மனங்கள் முற்றிலும் வெளிப்படையானவை, ஆனால் அவர்களின் தொழில்நுட்ப வளர்ச்சி தேக்கமடைகிறது; பேப்பர்கிளிப் சிந்தனைச் சோதனையும், ஒரு குழு ஒரே இலக்கில் ஒன்றிணையும்போது, பன்முகத்தன்மை இழக்கப்படுகிறது என்பதைக் காட்டுகிறது. ஒரு பல-ஏஜெண்ட் அமைப்பில், செயல்திறன் மற்றும் பன்முகத்தன்மையை எவ்வாறு சமநிலைப்படுத்த முடியும்?

முழுமையான பகிர்வு சிந்தனை மந்தநிலை மற்றும் பிழை அடுக்கைப் பெருக்கும்; தனிமைப்படுத்தலே அறிவாற்றல் பன்முகத்தன்மையைத் தருகிறது. வழிகள்: வெவ்வேறு ப்ராம்ப்ட்கள்/மாதிரிகளால் சிந்தனை விருப்பங்களை உருவாக்குதல் (brainstorm, debate); குறுக்குச் சரிபார்ப்பாளர்கள் முந்தைய சிந்தனைச் செயல்முறையைப் பார்க்காமல் அசல் சான்றுகளை மட்டும் பார்த்தல்.

10. (★★★) ஒரு கோடிங் ஏஜெண்டுக்கு 30 படிகள் மற்றும் 300 படிகள் பட்ஜெட்டை ஒதுக்குங்கள். அதன் வேலை உத்தி எவ்வாறு வேறுபட வேண்டும்? படி பட்ஜெட்டை அதிகரிப்பது செயல்திறன் முன்னேற்றத்திற்கு உத்தரவாதம் அளிக்காது என்பதை ஆராய்ச்சி காட்டுகிறது—ஏஜெண்டுகள் ஆழமற்ற தேடல்களுக்குப் பிறகு முன்கூட்டியே "நிறைவடையலாம்". ஒரு "பட்ஜெட்-அறிவுள்ள" வழிமுறையை வடிவமைக்கவும், இது சிறிய பட்ஜெட்டின் கீழ் மைய செயல்பாட்டை விரைவாக அடைய ஏஜெண்டை அனுமதிக்கிறது, மேலும் பெரிய பட்ஜெட்டின் கீழ் திட்டமிடல், சோதனை மற்றும் மறுஆய்வு கட்டங்களைச் சேர்த்து, கூடுதல் கணக்கீட்டு வளங்களை முழுமையாகப் பயன்படுத்துகிறது.

வழிமுறை: ஒவ்வொரு படியிலும் மொத்த பட்ஜெட் மற்றும் மீதமுள்ள பட்ஜெட்டைப் ப்ராம்ப்டில் செலுத்தி, மீதமுள்ள விகிதத்தின் அடிப்படையில் ஆராய்ச்சி/பயன்படுத்தல் எடைகளை மாறும் வகையில் சரிசெய்யவும். எடுத்துக்காட்டாக, சிறிய பட்ஜெட் (30 படிகள்): திட்டமிடல் மற்றும் மறுஆய்வைத் தவிர்த்து, நேரடியாக மையச் செயல்பாடு + அடிப்படைச் சரிபார்ப்புக்குச் செல்லவும். பெரிய பட்ஜெட் (300 படிகள்): முதலில் திட்டமிடல், பின் செயலாக்கம், பின் சோதனை, பின் மறுஆய்வு மற்றும் மேம்பாடு; மைல்கற்களில் சரிபார்ப்புப் புள்ளிகளை அமைத்து முன்னேற்றத்தை மதிப்பிட்டு, ஆழமற்ற நிறைவைத் தடுக்கவும்.

11. (★★) இந்த அத்தியாயம் "முன்கூட்டிய நிறுத்தத்தை" சோம்பேறித்தனமான போலி நிறைவு, முன்கூட்டிய கைவிடல், போலி வெற்றி என மூன்று வகைகளாகப் பிரிக்கிறது. மூன்று வகைப் பிரச்சினைகளின் தீர்வுகளும் ஏன் ஒரே இடத்தில்—சரிபார்ப்பில்—சந்திக்கின்றன?

பொதுவான வேர்: பணி முடிந்ததா என்பது மாதிரியின் சுய-அறிவிப்பால் தீர்மானிக்கப்படுகிறது; "முடிந்தது" என்பது வெறும் அறிவிப்பு, நிரூபணம் அல்ல. சரிபார்ப்பான் ① உண்மையான கவனிப்புகளை அடிப்படையாகக் கொள்ள வேண்டும் (சோதனைகளை இயக்குதல், திரைப்பிடிப்புகளை ரெண்டர் செய்தல், திரும்பப் பணம் உண்மையில் வந்ததா எனச் சரிபார்த்தல்); ② வெளிப்படையான முடிவு வரையறைக்கு எதிராக உருப்படி உருப்படியாகச் சரிபார்த்து, சோம்பேறித்தனமான போலி நிறைவையும் போலி வெற்றியையும் கையாள வேண்டும்; ③ தோல்வி முடிவுகளையும் சரிபார்த்து, முன்கூட்டிய கைவிடலைக் கையாள வேண்டும்; ④ வெளிப்படையான நிறுத்த நிபந்தனைகளுடன் (சுற்று/பட்ஜெட் வரம்புகள்), கட்டுப்பாட்டை இழந்த சுழற்சி என்ற எதிர் தீவிரத்திற்குச் செல்வதைத் தடுக்க வேண்டும்.

12. (★★) அட்டவணை 10-3 பல-ஏஜெண்ட் அமைப்பை இயங்குதளத்துடன் வரிசைக்கு வரிசை பொருத்துகிறது. இந்த அட்டவணையை இன்னும் சில வரிசைகள் நீட்டியுங்கள்: மெய்நிகர் நினைவகம் மற்றும் பக்கமாக்கல் (paging), கோப்பு அனுமதிகள், முட்டுக்கட்டை கண்டறிதல் (deadlock detection), திட்டமிடல் அல்காரிதம்—இவை ஏஜெண்ட் உலகில் எதற்கு ஒத்தவை? மேலும், எந்த இயங்குதளக் கருத்துகளுக்கு ஏஜெண்ட் உலகில் ஒத்த ஒன்று இல்லை, ஏன்?

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