Agentic AI ROI-ன் அமைதியான கொலையாளி
உங்கள் Kubernetes pods பச்சை நிறத்தில் உள்ளன (சரியாக இயங்குகின்றன). உங்கள் API latency குறைவாக உள்ளது. உங்கள் LLM provider 99.9% uptime-ஐக் காட்டுகிறது.
இருப்பினும், உங்கள் தானியங்கி கடன் அமைப்பு (automated loan system) வெறும் மூன்று மணிநேரத்தில் அதன் முழு மாத API பட்ஜெட்டையும் தீர்த்துவிட்டது. இரண்டு agents ஒரு லூப்பில் (loop) சிக்கிக்கொண்டன.
இதுதான் "ஆரோக்கியமாக இருந்தாலும் மாயத்தோற்றம் (Hallucinating) காணும்" முரண்பாடு.
பாரம்பரிய மென்பொருளில், ஒரு அமைப்பு இயங்கிக் கொண்டிருக்கலாம் அல்லது நின்றுவிடலாம். ஆனால் ஒரு agentic mesh-இல், ஒரு அமைப்பு ஆரோக்கியமாகத் தோன்றினாலும் முற்றிலும் தோல்வியடையக்கூடும். நீங்கள் agents-களுக்கு வழக்கமான Site Reliability Engineering (SRE)-ஐப் பயன்படுத்தினால், நீங்கள் தவறான சிக்னல்களைக் கண்காணிக்கிறீர்கள் என்று அர்த்தம். செயல்பாட்டு ரீதியாக மூளைச்சாவு அடைந்த ஒரு நோயாளியின் இதயத் துடிப்பை நீங்கள் அளவிடுகிறீர்கள் என்று பொருள்.
ஏன் வழக்கமான உள்கட்டமைப்பு (infrastructure) agentic வீழ்ச்சியைத் தடுக்கத் தவறிவிடுகிறது?
பாரம்பரிய SRE தீர்மானிக்கப்பட்ட (deterministic) அமைப்புகளுக்காக உருவாக்கப்பட்டது. ஒரு சேவை தோல்வியடையும் போது, அது ஒரு பிழையை (error) ஏற்படுத்தும். அது இருமடியமானது (binary). Agent தோல்விகள் வேறுபட்டவை. ஒரு agent செயலிழந்துவிடாது (crash). அது திசைமாறுகிறது (drift). அது time out ஆகாது. அது ஒரு அளவுருவை (parameter) கற்பனை செய்து (hallucinate) உருவாக்குகிறது, இது சில நிலைகளுக்குப் பிறகு ஒரு அமைதியான தோல்விக்கு (silent failure) வழிவகுக்கிறது.
ஒற்றை பாட்களிலிருந்து (single bots) நிறுவன அளவிலான agent fabrics-க்கு மாறும் போது இந்த இடைவெளியை நாம் காண்கிறோம். ஒரு குழு ஒரு benchmark-இல் 95% துல்லியத்தைக் (accuracy) கூறலாம், ஆனால் அந்த அமைப்பு production-இல் தோல்வியடைகிறது. Benchmarks ஒரு மாடல் ஒரு கேள்விக்கு பதிலளிக்க முடியுமா என்பதை அளவிடுகின்றன. நான்கு agents உள்ளடங்கிய 12-படி பணிப்பாய்வில் (workflow), ஒரு அமைப்பு தனது நிலையை (state) பராமரிக்க முடியுமா என்பதை அவை அளவிடுவதில்லை.
உங்களுக்கு Agent Reliability Engineering (ARE) தேவைப்படுகிறது.
பாரம்பரிய SRE இருமடிய நிலைகளை (binary states) நிர்வகிக்கிறது. ARE நிகழ்தகவு பரவல்களை (probability distributions) நிர்வகிக்கிறது. நீங்கள் CPU மற்றும் memory-ஐ மட்டும் கண்காணித்தால், agent தோல்விகளைப் பார்க்க முடியாது.
பல-agent அமைப்புகளில் (multi-agent systems) பிழைகள் வெறும் கூட்டல் மட்டுமல்ல, அவை பெருக்கப்படுகின்றன. ஏனெனில் agents மற்ற agents-களின் வெளியீட்டை (output) உண்மையாகக் கருதுகின்றன, எனவே முதல் படியில் ஏற்படும் ஒரு சிறிய பிழை ஐந்தாவது படிக்கு வரும்போது ஒரு பேரழிவாக மாறுகிறது.
பொதுவான தோல்வி முறைகள் (failure modes) பின்வருமாறு:
- Agentic முடிவற்ற லூப்கள் (infinite loops)
- State drift (நிலை மாற்றம்)
- Prompt injection cascades
- Tool-call மாயத்தோற்றங்கள் (hallucinations)
ஒரு ஆபத்தான உதாரணம்: ஒரு agent ஒரு update tool-ஐ அழைக்கிறது. அது இல்லாத ஒரு parameter-ஐக் கற்பனை செய்கிறது. API அந்த கூடுதல் parameter-ஐப் புறக்கணித்துவிட்டு 200 OK-வை வழங்குகிறது. Agent தான் வெற்றிகரமாகச் செய்துவிட்டதாக நினைக்கிறது, ஆனால் வணிகத் தர்க்கம் (business logic) அமைதியாகத் தோல்வியடைகிறது.
ARE "நோக்கம்-செயல்-விளைவு" (intent-action-outcome) லூப்பில் கவனம் செலுத்துகிறது. ஒரு agent ஒரு tool-ஐ அழைத்ததா என்பதை மட்டும் நீங்கள் கண்காணிக்கவில்லை. அந்த அழைப்பு அசல் நோக்கத்துடன் (original intent) பொருந்துகிறதா மற்றும் அதன் விளைவு இலக்கை அடைந்ததா என்பதையும் நீங்கள் கண்காணிக்கிறீர்கள்.
Agent Reliability Engineer (ARE) பணி இவற்றை கையாள்கிறது:
- Intent Analysis: ஒரு agent இலக்கிலிருந்து எப்போது திசைமாறுகிறது என்பதைக் கண்டறிதல்.
- Guardrail Tuning: லூப்களைத் தடுக்க கட்டுப்பாடுகளை (constraints) சரிசெய்தல்.
- Dependability Mapping: ஒரு agent எப்போது ஒரு மனிதரிடம் ஒப்படைக்க வேண்டும் என்பதைத் தீர்மானித்தல்.
- Audit Architecture: உள்நிலைத் தர்க்கம் (internal reasoning) மற்றும் நிலை மாற்றங்களைப் பதிவு செய்தல்.
துல்லியத்தைப் (accuracy) பற்றிப் பேசுவதை நிறுத்துங்கள். கணினி நம்பகத்தன்மை (System Dependability) பற்றிப் பேசத் தொடங்குங்கள்.
மனிதத் தலையீட்டின் (human intervention) செலவைக் கணக்கிடுவதன் மூலம் நீங்கள் இதை ஒரு CFO-விடம் நியாயப்படுத்தலாம். ஒவ்வொரு முறையும் ஒரு மனிதன் ஒரு agent-இன் தவறைச் சரிசெய்யும் போது, அது ஒரு நம்பகத்தன்மை தோல்வியாகும். அந்த மணிநேரங்களை உங்கள் நிபுணர்களின் சம்பளத்துடன் பெருக்கினால், நம்பகத்தன்மையின்மைக்கான (unreliability) செலவு தெளிவாகத் தெரியும்.
Agentic Error Budgets-ஐப் பயன்படுத்துங்கள். ஒரு எளிய மின்னஞ்சல் சுருக்கிகான (email summarizer) உங்கள் error budget அதிகமாக இருக்கலாம். $10M பரிமாற்றம் செய்யும் ஒரு அமைப்புக்கு, உங்கள் error budget பூஜ்ஜியம்.
AI-ஐ ஒரு மென்பொருள் அம்சமாக (software feature) கருதாதீர்கள். அதை ஒரு அமைப்பு ரீதியான அபாயமாக (systemic risk) கருதுங்கள். இந்த யுகத்தின் வெற்றியாளர்கள் மிகச்சிறந்த மாடல்களைக் கொண்டிருப்பார்கள் அல்ல; அவர்கள் மிகவும் நம்பகமான அமைப்புகளைக் கொண்டிருப்பார்கள்.
Optional learning community: https://t.me/GyaanSetuAi