ஒவ்வொரு சில மாதங்களுக்கும், தானாகவே சிந்திப்பதாகக் கூறப்படும் மென்பொருளுக்காகத் தொழில் துறை ஒரு புதிய சொல்லை உருவாக்குகிறது. தற்போது அந்தச் சொல் "Agentic AI." விற்பனையாளர்கள் தங்கள் லேண்டிங் பக்கங்களிலும் பிட்ச் டெக்குகளிலும் (pitch decks) இதைப் பயன்படுத்துவதில் விரைவாக இருக்கிறார்கள். ஆனால், ஒரு அமைப்பு உங்கள் சூழல், உங்கள் தரவு மற்றும் உங்கள் தோல்வி முறைகளைச் சந்திக்கும் வரை, அந்த லேபிள் வெறும் சந்தைப்படுத்தல் வாசகம் மட்டுமே. அந்தச் சொல் பாதுகாப்பு, நம்பகத்தன்மை அல்லது பொருத்தம் பற்றி உங்களுக்கு எதையும் சொல்லவில்லை.
அம்சப் பட்டியல்களை (feature lists) வாசிப்பதை நிறுத்திவிட்டு, திறன்களை (capabilities) அளவிடத் தொடங்குவதற்கான நேரம் இது.
லேபிள் பிரச்சனை
விற்பனை பொறியாளர்கள் (Sales engineers) ஒரு "agentic" கட்டமைப்பிற்கான ஆதாரமாக டேஷ்போர்டுகள், மல்டி-மாடல் டிராப்டவுன் மெனுக்கள் மற்றும் மொபைல் அணுகலை உங்களுக்குக் காண்பிப்பார்கள். அவை இடைமுகத் தேர்வுகள் (interface choices) மட்டுமே, நடத்தை உத்தரவாதங்கள் (behavioral guarantees) அல்ல. ஒரு தயாரிப்பு அதிநவீனமாகத் தோன்றலாம், ஆனால் ஒரு API timeout-க்குப் பிறகு திட்டத்தை மாற்ற வேண்டிய தருணத்தில் அது உடைந்து போகலாம்.
ஒரு அமைப்பு உண்மையில் ஒரு தன்னாட்சி ஏஜென்ட் (autonomous agent) போலச் செயல்படுகிறதா என்பதே முக்கியம். அது வேலையை நிலைகளாகப் பிரிக்கிறதா? கடுமையான எல்லைகளுக்குள் உண்மையான அமைப்புகளைத் தொடுகிறதா? ஏதேனும் ஒன்று முடங்கும்போது, அது தன்னைத் தகவமைத்துக் கொள்கிறதா அல்லது வெறுமனே தோல்வியடைந்து காத்திருக்கிறதா? உங்கள் தொழில்நுட்பக் கட்டமைப்பிற்கு (stack) ஏற்ற ஆதாரங்களுடன் இந்தக் கேள்விகளுக்குப் பதிலளிக்கும் வரை, நீங்கள் ஒரு கருத்தைத்தான் வாங்குகிறீர்கள், ஒரு தயாரிப்பை அல்ல.
உண்மையில் முக்கியத்துவம் வாய்ந்த ஐந்து திறன் சோதனைகள்
ஒவ்வொரு Agentic கூற்றையும் ஐந்து குறிப்பிட்ட திறன்களின் அடிப்படையில் நான் மதிப்பீடு செய்கிறேன். ஒவ்வொன்றிற்கும், நான் ஒரு எளிய கேள்வி கேட்கிறேன்: அந்த நடத்தை ஆவணப்படுத்தப்பட்டுள்ளதா, ஒரு முன்னோட்ட சோதனையில் (pilot) சரிபார்க்கப்பட்டுள்ளதா அல்லது இன்னும் தெரியாததா? தெரியாதது என்பதே இயல்பானது. மாறாக நிரூபிக்கும் பொறுப்பு தயாரிப்பின் மீதே உள்ளது.
திட்டமிடல் (Planning). ஒரு தெளிவற்ற இலக்கை வரிசைப்படுத்தப்பட்ட, சரிபார்க்கக்கூடிய நிலைகளாக அந்த அமைப்பு பிரிக்கிறதா? யார் வேண்டுமானாலும் ஒரு செய்ய வேண்டிய பட்டியலை (to-do list) உருவாக்கலாம். "இந்த காலாண்டில் நமது கிளவுட் செலவை பதினைந்து சதவீதம் குறைக்கவும்" போன்ற ஒரு சிக்கலான நோக்கத்தைக் கையாளுவதே உண்மையான சோதனை. ஒரு உண்மையான ஏஜென்ட் தற்போதைய பயன்பாட்டிற்கான தணிக்கையைத் திட்டமிடுகிறது, பயன்படுத்தப்படாத வளங்களைக் கண்டறிகிறது, சரியான அளவு பரிந்துரைகளைத் தயாரிக்கிறது மற்றும் முறையான வரிசையில் மாற்றக் கோரிக்கைகளைத் திட்டமிடுகிறது. அது உங்களுக்கு ஒரு பொதுவான ஐந்து புள்ளிகள் கொண்ட கட்டுரையை மட்டும் கொடுத்து வேலையை முடித்துவிட்டதாகக் கூறினால், அது திட்டமிடல் அல்ல. அது சுருக்கம் கூறுதல் (summarizing) மட்டுமே.
கருவிகள் (Tools). நிர்ணயிக்கப்பட்ட எல்லைக்குள் அது உண்மையான அமைப்புகளில் செயல்படுகிறதா? ஒரு மெருகூட்டப்பட்ட டெமோவில் ஒரு mock API-ஐ அழைப்பது எளிது. குறைந்தபட்ச அதிகார வரம்பு கொண்ட (least-privilege) சான்றுகளுடன் உங்கள் தயாரிப்பு CRM-இல் அங்கீகாரம் பெறுவது, ஒரு பதிவை எழுதுவது மற்றும் பரிவர்த்தனையைப் பதிவு செய்வது கடினம். அது எந்த அமைப்புகளைத் தொடுகிறது, என்ன சாவிகளைக் (keys) கொண்டுள்ளது மற்றும் அதன் பாதிப்பு எல்லை (blast radius) எங்கு முடிகிறது என்பதை நீங்கள் துல்லியமாகத் தெரிந்து கொள்ள வேண்டும். எல்லை (Scope) கட்டுப்படுத்தப்பட்டிருக்க வேண்டும். இயல்பாகவே தயாரிப்புச் சூழலில் (production) எழுதும் அணுகல் (write access) ஏஜென்ட்டிடம் இருந்தால், உங்களிடம் ஒரு ஏஜென்ட் இல்லை. உங்களிடம் ஒரு பொறுப்பு (liability) உள்ளது.
திருத்தம் (Correction). ஒரு தோல்விக்குப் பிறகு அது தனது அடுத்த நகர்வை மாற்றுகிறதா? பெரும்பாலான முன்மாதிரிகள் (prototypes) இங்குதான் தோல்வியடைகின்றன. மூன்றாவது நிலை ஒரு 503 பிழையை அல்லது schema mismatch-ஐத் திருப்பிக் கொடுக்கும்போது, ஏஜென்ட் முடிவில்லாமல் சுழல்கிறதா, ஒரு வெற்றிகரமான செய்தியைத் தவறாகக் கற்பனை செய்கிறதா (hallucinate) அல்லது தனது பாதையைச் சரிசெய்கிறதா? உண்மையான திருத்தம் என்பது தோல்வியைக் கவனிப்பது, பணிப்பாய்வின் (workflow) மீதமுள்ள பகுதியை மீண்டும் திட்டமிடுவது மற்றும் கட்டுப்பாடுகளைத் தளர்த்தாமல் ஒரு புதிய பாதையைச் செயல்படுத்துவது ஆகும். நம்பிக்கையுடன் கூடிய ஒரு மறுமுயற்சி சுழல் (retry loop) திருத்தம் அல்ல.
சூழல் (Context). ஒவ்வொரு நிலையிலும் அது கட்டுப்பாடுகளைச் செயல்பாட்டில் வைத்திருக்கிறதா? நினைவகம் (Memory) மட்டும் போதாது. முதல் நிலை "ஐந்நூறு டாலர் பட்ஜெட்டைத் தாண்ட வேண்டாம்" அல்லது "EU வாடிக்கையாளர் தரவைத் தவிர்க்கவும்" போன்ற ஒரு கடுமையான விதியைத் தீர்மானித்தால், ப்ராம்ப்ட் சூழல் (prompt context) மாறியதால் ஏழாவது நிலையில் அந்த வரம்பை அது புறக்கணிக்க முடியாது. இது இணக்க விதிகள் (compliance rules), பிராண்ட் குரல் (brand voice), ஒப்புதல் படிநிலைகள் மற்றும் அணுகல் கட்டுப்பாடுகளுக்குப் பொருந்தும். நீண்ட சூழல் மாதிரிகள் (long-context models) மற்றும் பாரம்பரிய நிலை மேலாண்மை (classical state management) ஆகியவை சந்திக்க வேண்டிய இடம் இதுவே.
மேற்பார்வை (Oversight). ஒரு மனிதன் செயல்முறையை நிறுத்தவோ அல்லது மீண்டும் தொடங்கவோ முடியுமா? உங்களுக்கு நுணுக்கமான சர்க்யூட் பிரேக்கர்கள் (circuit breakers) தேவை, வர்ச்சுவல் மெஷினில் ஒரு 'kill switch' மட்டும் போதாது. இரண்டாவது நிலைக்குப் பிறகு யாராவது திட்டத்தைப் பரிசோதித்து மூன்றாவது நிலைக்கு ஒப்புதல் அளிக்க முடியுமா? ஒரு வெளிப்புறச் சார்பு (external dependency) தோல்வியடைந்தால், ஒரு மனிதன் அதைச் சரிசெய்து, நிலையை (state) இழக்காமல் பணிப்பாய்வை மீண்டும் தொடங்க முடியுமா? மேற்பார்வை என்பது பேரழிவு ஏற்பட்ட பிறகு நீங்கள் வாசிக்கும் ஒரு தணிக்கைப் பதிவு (audit log) அல்ல. இது தலையிடுவதற்கான ஒரு நேரடி வழிமுறையாகும்.
சரிபார்ப்புப் பட்டியல்களை விடச் சான்றுகளே மேலானது
ஒரு டெமோ என்பது நம்பகத்தன்மை விகிதம் அல்ல. ஒரு விற்பனையாளர் ஒப்பீட்டுத் தாளில் உள்ள சரிபார்ப்புப் பெட்டி (checkbox) ஒரு சான்று அல்ல. ஒரு கணக்கு நிர்வாகி (account executive) தயாரிப்பு "சோதனை தோல்விக்குப் பிறகு திருத்தமடைகிறது" என்று கூறும்போது, உங்கள் அடுத்த நடவடிக்கை சான்று அட்டையைக் (evidence card) கேட்பதாக இருக்க வேண்டும்.
ஒரு சான்று அட்டை சரிபார்ப்புப் பெட்டிக்குத் தெளிவான விளக்கத்தைத் தருகிறது. அது இவ்வாறு இருக்கும்:
- திறன் (Capability): திருத்தம் (Correction)
- கூற்று (Claim): சோதனை தோல்விக்குப் பிறகு திருத்தமடைகிறது
- சான்று (Evidence): கட்டுப்படுத்தப்பட்ட அமைப்பின் (controlled fixture) நிலுவையில் உள்ளது
- உரிமையாளர் (Owner): டெவலப்பர்-எக்ஸ்பீரியன்ஸ் குழு (Developer-experience team)
- நிறுத்தவும் (Stop if): திருத்தம் அங்கீகரிக்கப்பட்ட இடைமுகத்தை (interface) மாற்றினால்
இந்த வடிவம் தெளிவை வலியுறுத்துகிறது. இது சந்தைப்படுத்தல் கூற்றையும் ஆதாரத்தையும் தனித்தனியாகப் பிரிக்கிறது. இது ஒரு பொறுப்பினை நிர்ணயிக்கிறது; இதன் மூலம் ஏஜென்ட் (agent) தனது திருத்த முயற்சியின் போது அங்கீகரிக்கப்பட்ட ஒரு இடைமுகத்தை (interface) உடைக்கும்போது, எந்தக் குழுவிடம் தகவல் தெரிவிக்கப்பட வேண்டும் என்பதை நீங்கள் துல்லியமாகத் தெரிந்து கொள்ளலாம். ஒரு பொறுப்பாளர் இல்லையென்றால், பொறுப்புக்கூறல் இருக்காது. நிறுத்த நிபந்தனைகள் இல்லையென்றால், பாதுகாப்புத் தடுப்பு இருக்காது.
நீங்கள் எந்தவொரு முன்னோடித் திட்டத்தையும் (pilot) தொடங்குவதற்கு முன், மூன்று விஷயங்களை எழுத்துப்பூர்வமாக வரையறுக்கவும். முதலாவதாக, உங்கள் பணிகள். இவை செயற்கையான அளவுகோல்களிலிருந்து (synthetic benchmarks) அல்லாமல், உண்மையான வணிகத் தர்க்கத்திலிருந்து (business logic) எடுக்கப்பட வேண்டும். இரண்டாவதாக, உங்கள் தோல்விச் சோதனைகள். இயங்கிக் கொண்டிருக்கும் போதே ஒரு API சாவியை ரத்து செய்தல், தவறான வடிவம் கொண்ட JSON பதிலைச் செலுத்துதல் அல்லது எதிர்பார்க்கப்படும் தாமத நேரத்தை (latency) இருமடங்காக்குதல் போன்றவற்றைச் செய்யவும். மூன்றாவதாக, உங்கள் நிறுத்த நிபந்தனைகள். இவை தானியங்கி முறையில் இருக்க வேண்டும்; யாராவது கவனிப்பார்கள் என்று நீங்கள் நம்பும் ஒரு கைமுறை அவசரப் பொத்தானாக (manual panic button) இருக்கக்கூடாது.
விற்பனையாளர்களின் கூற்றுகளை எவ்வாறு கேள்வி கேட்பது?
ஏஜென்ட்களுக்கு மாதிரிகள் (models), கருவிகள் (tools), அறிவுறுத்தல்கள் (instructions), பாதுகாப்புத் தடுப்புகள் (guardrails) மற்றும் மனிதத் தலையீடு (human intervention) ஆகிய ஐந்து கூறுகள் தேவை என்று OpenAI முன்மொழிகிறது. அவர்களின் குறிப்பிட்ட கட்டமைப்பை (architecture) அப்படியே ஏற்காமல், விற்பனையாளர்களைக் கேள்வி கேட்பதற்கான ஒரு கலைச்சொல்லாக இந்த பட்டியலைப் பயன்படுத்தலாம்.
எந்த மாதிரி திட்டமிடலை (planning) கையாள்கிறது மற்றும் எது வெறும் உருவாக்கத்தை (generation) மட்டுமே செய்கிறது என்று கேளுங்கள். எந்தக் கருவியின் அனுமதிகள் நிலையானவை (hardcoded) மற்றும் எவை மாறும் தன்மை கொண்டவை (dynamic) என்று கேளுங்கள். பாதுகாப்புத் தடுப்புகள் எங்கு நடைமுறைப்படுத்தப்படுகின்றன — பிராம்ட் அடுக்கிலா (prompt layer) அல்லது ஆர்கெஸ்ட்ரேஷன் என்ஜினிலா (orchestration engine) என்று கேளுங்கள். மனிதத் தலையீடு என்பது ஒரு உள்ளமைக்கப்பட்ட சரிபார்ப்புப் புள்ளியா (built-in checkpoint) அல்லது ஏஜென்ட் ஏற்கனவே உங்கள் தரவுத்தளத்தைச் (database) சிதைத்த பிறகு அனுப்பப்படும் ஒரு ஆய்வு மின்னஞ்சலா (post-mortem email) என்று கேளுங்கள். நீங்கள் OpenAI-ன் தொழில்நுட்ப அடுக்குகளை (stack) வாங்கப் போகவில்லை. மாறாக, மற்றவர்களின் கட்டமைப்பில் உள்ள இடைவெளிகளைக் கண்டறிய அவர்களின் கட்டமைப்பையே நீங்கள் பயன்படுத்துகிறீர்கள்.
MonkeyCode ஒரு திறந்த மூல (open-source) வழியையும் இலவச கிளவுட் பதிப்பையும் வழங்குகிறது. அந்தத் தொகுப்பு ஒரு முன்னோடித் திட்டத்தைத் தொடங்குவதை மலிவாக மாற்றுகிறது. ஆனால் மலிவான தொடக்கம் என்பது உறுதிப்படுத்தப்பட்ட வெற்றிக்குச் சமமானது அல்ல. உங்கள் சொந்த உள்கட்டமைப்பில் (infrastructure) உங்கள் சொந்தப் பணிகளைச் செய்து முடிக்கும் வரை, அமைப்பின் தெரியாத பகுதிகள் தெரியாத நிலையிலேயே இருக்கும். கடினமான கேள்விகளுக்குப் பதில்கள் கிடைத்துவிட்டன என்று நினைக்க, பூஜ்ஜிய டாலர் கட்டணம் உங்களை ஏமாற்ற விடாதீர்கள்.
பட்ஜெட்டைச் சேமிக்கும் ஒரு வாங்கும் விதி
ஒரு ஏஜென்டிக் முன்னோடித் திட்டத்தை (agentic pilot) ஒரு உற்பத்திச் செயல்பாட்டு உறுதிப்பாடாக (production commitment) விரிவுபடுத்துவதற்கான எனது விதி எளிமையானது. முக்கியமான திறன்களுக்குச் சான்றுகளும், தோல்விகளுக்கான தெளிவான பொறுப்பாளரும் இருக்கும்போது மட்டுமே நான் அதன் நோக்கம் மற்றும் பட்ஜெட்டை அதிகரிக்கிறேன். இது ஒரு ரோட்மேப் ஸ்லைடு (roadmap slide) அல்ல, அல்லது ஒரு சப்போர்ட் டிக்கெட் வரிசை (support ticket queue) அல்ல. சான்று என்பது உங்கள் சூழலில் இருந்து பெறப்பட்ட பதிவுகள் (logs) ஆகும். பொறுப்பாளர் என்பது அந்த குறிப்பிட்ட தோல்வி முறைக்காகப் பொறுப்பேற்கும் ஒரு குறிப்பிட்ட நபர் ஆவார்.
விற்பனையாளரால் உங்களுக்குச் சான்றைக் காட்ட முடியாவிட்டால், அல்லது உங்கள் உள் குழுவால் ஒரு பொறுப்பாளரை நியமிக்க முடியாவிட்டால், நீங்கள் விரிவாக்கத் தயாராக இல்லை. நீங்கள் தொடர்ந்து சோதனை செய்யத் தயாராக மட்டுமே இருக்கிறீர்கள்.
நினைவில் கொள்ள வேண்டியது: "Agentic" என்ற சொல் உங்கள் மதிப்பீட்டிற்கான தொடக்கப் புள்ளியாகும். அது முடிவுக்கோடு அல்ல. கடினமான கேள்விகளைக் கேட்கவும், கடுமையான முன்னோடித் திட்டங்களை நடத்தவும், உங்கள் நிறுவனத்திற்குள் முக்கியத்துவம் வாய்ந்த ஆதாரங்களைக் கோரவும் இது ஒரு தூண்டுதலாக இருக்கட்டும். ஒரு தயாரிப்பு உங்கள் தளத்தில், உங்கள் தோல்விகளுடன், ஐந்து திறன் சோதனைகளையும் தாண்ட முடியாவிட்டால், அது உண்மையில் ஏஜென்டிக் (agentic) கிடையாது. அது வெறும் மற்றொரு செயல்விளக்கம் (demo) மட்டுமே.
Source: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h
Optional learning community: https://t.me/GyaanSetuAi