நான்கு தன்னாட்சி AI முகவர்கள் (autonomous AI agents) இப்போது ஒரு மென்பொருள் பிழையைக் கண்டறிந்து, அந்தப் பிழையான குறியீட்டைத் திருத்தி, அதைச் சரிசெய்ததையும் உறுதிப்படுத்த முடியும்—இவை அனைத்தும் ஒரு நிமிடத்திற்கும் குறைவான நேரத்தில் நடக்கும். SigNoz ஹேக்கத்தானிற்காக உருவாக்கப்பட்ட புதிய observability-driven workflow மூலம் இது சாத்தியமாகியுள்ளது.
AgentOps என்று அழைக்கப்படும் இந்த அமைப்பு, SigNoz-இல் பிழைகள் அதிகரிப்பதைக் கண்காணிக்கிறது, தொடர்புடைய logs மற்றும் traces-களைப் பெறுகிறது, பிழைக்குக் காரணமான துல்லியமான கோப்பு மற்றும் வரியைக் கண்டறிகிறது, sandbox-இல் மூலக் குறியீட்டைத் திருத்துகிறது, பின்னர் அந்தப் பிழை நீக்கப்பட்டுவிட்டதை நிரூபிக்க மீண்டும் அதே கோரிக்கையை (request) இயக்குகிறது. ஒவ்வொரு முழுச் சுழற்சியும் 30-60 வினாடிகளில் முடிவடைகிறது, மேலும் இந்த முழுச் செயல்பாடும் மனிதத் தலையீடு இன்றி தானாகவே இயங்குகிறது.
AI முகவர்களுக்கு observability ஏன் முக்கியமானது
பாரம்பரிய SRE நடைமுறையில், logs, metrics மற்றும் distributed traces ஆகியவை ஒரு சேவையின் (service) கண்களாகக் கருதப்படுகின்றன. ஒரு கோரிக்கை (request) தோல்வியடையும் போது, ஒரு பொறியாளர் அந்தப் பிழைக்குக் காரணமான கூறைக் கண்டறிய trace-ஐப் பின்தொடர்கிறார். இதே தத்துவமே இப்போது AgentOps-ஐ இயக்குகிறது, ஆனால் இங்கே கண்காணிக்கப்படும் "சேவை" என்பது அந்த AI முகவர் தான்.
முகவர் பயன்படுத்தும் ஒவ்வொரு கருவியும்—அது ஒரு language model call ஆக இருந்தாலும், file-system edit ஆக இருந்தாலும் அல்லது test runner ஆக இருந்தாலும்—trace-இல் ஒரு span-ஐ உருவாக்குகிறது. ஒரு span அதன் தொடக்க நேரம், கால அளவு மற்றும் வெற்றி நிலையை (success status) பதிவு செய்கிறது, இதன் மூலம் ஒவ்வொரு சிந்தனைப் படிநிலையும் (reasoning step) எவ்வளவு நேரம் எடுத்தது மற்றும் அது வெற்றியடைந்ததா என்பதை முகவரால் பார்க்க முடியும். மனிதர்கள் ஒரு பிழையைத் திருத்தும் போது (debugging) செய்வது போலவே, அந்த spans அனைத்தையும் இணைப்பதன் மூலம், முகவர் தனது சொந்தச் சிந்தனைச் செயல்முறையின் முழுமையான பிம்பத்தை உருவாக்குகிறது.
"observability என்பது ஒரு அறிக்கையிடும் அடுக்கு" (reporting layer) என்பதிலிருந்து "observability என்பது ஒரு உணர்தல் திறன்" (perception) என்ற நிலைக்கு மாறுவதே இங்குள்ள முக்கிய மாற்றம். AgentOps, trace தரவுகளை மீண்டும் முகவர்களுக்கே வழங்குகிறது, இது அவர்கள் தங்கள் சொந்தச் செயல்களை நிகழ்நேரத்தில் (real time) பகுப்பாய்வு செய்ய அனுமதிக்கிறது. இதன் விளைவாக, AI ஒரு கருதுகோளை (hypothesis) உருவாக்குவது மட்டுமல்லாமல், சிக்கலைக் கண்டறியப் பயன்படுத்தும் அதே telemetry தரவைக் கொண்டு அதைச் சரிபார்க்கும் ஒரு சுழற்சி உருவாகிறது.
நான்கு படிநிலைச் செயல்முறை (workflow)
- கண்காணித்தல் (Monitor) – ஒரு இலகுரகக் கண்காணிப்பாளர் (lightweight watcher) SigNoz-இல் புதிதாகப் புகாரளிக்கப்பட்ட பிழைகளைத் தேடுகிறது.
- கண்டறிதல் (Diagnose) – முகவர் தொடர்புடைய logs மற்றும் traces-களைப் பெற்று, stack-ஐப் பிரித்தெடுத்து, பிழைக்குக் காரணமான மூலக் கோப்பு மற்றும் வரி எண்ணைத் தனிமைப்படுத்துகிறது.
- சரிசெய்தல் (Fix) – ஒரு sandboxed file-system server-ஐப் பயன்படுத்தி, முகவர் கண்டறியப்பட்ட வரியில் ஒரு patch-ஐ எழுதுகிறது. sandbox கடுமையான அனுமதிகளைக் (permissions) கடைப்பிடிக்கிறது மற்றும் திருத்தம் கொள்கைகளை மீறினால் தானாகவே பழைய நிலைக்குத் திரும்புகிறது (rollback).
- சரிபார்த்தல் (Verify) – முகவர் திருத்தப்பட்ட குறியீட்டிற்கு (patched code) மீண்டும் அதே கோரிக்கையை அனுப்புகிறது. trace ஒரு வெற்றிகரமான இயக்கத்தைக் காட்டினால், அந்தத் திருத்தம் உறுதி செய்யப்படுகிறது (committed); இல்லையெனில் முகவர் மீண்டும் முயற்சிக்கும்.
அனைத்துப் படிநிலைகளும் ஒரே முகவர் தொகுப்பால் ஒருங்கிணைக்கப்படுகின்றன, இதில் ஒவ்வொரு முகவரும் ஒரு தன்னாட்சி நுண்-சேவையாக (autonomous micro-service) செயல்படுகிறது. இந்த முழுச் சங்கிலியும் OpenTelemetry-க்கு இணக்கமான spans மூலம் கண்காணிக்கப்படலாம், இவற்றை SigNoz உள்வாங்கி காட்சிப்படுத்துகிறது.
நம்பகத்தன்மை குறித்த கடினமான பாடங்கள்
பிழைத் தெளிவு (Error clarity)
ஒரு பொதுவான "failed" என்ற நிலை எதையும் உணர்த்துவதில்லை. அடுத்தடுத்த முகவர்கள் மீண்டும் முயற்சி செய்ய வேண்டுமா, பின்வாங்க வேண்டுமா அல்லது நிறுத்த வேண்டுமா என்பதைத் தீர்மானிக்க ஏதுவாக, "தவறான கருதுகோள்" (wrong hypothesis) அல்லது "patch செயல்முறையைச் சிதைத்தது" (patch broke process) போன்ற விரிவான தோல்வி காரணங்களை இக்குழுவினர் சேர்த்துள்ளனர். இது மனிதர்கள் ஒரு நிகழ்வுக்குப் பிந்தைய ஆய்வில் (post-mortems) மூலக் காரணங்களைக் குறிப்பிடும் முறையைப் பிரதிபலிக்கிறது.
தரவு தாமதம் (Data latency)
Telemetry தரவுகள் உடனடியாகத் தோன்றாது. எனவே, ஒரு திருத்தத்தை உறுதி செய்வதற்கு முன், தேவையான logs வந்துவிட்டன என்பதை உறுதிப்படுத்த முகவர்கள் இப்போது ஒரு சிறிய இடைவெளியையும் (pause) மற்றும் ஒரு சரிபார்ப்பையும் (sanity check) மேற்கொள்கின்றன. இந்தத் தடுப்பு முறை இல்லையெனில், ஒரு முகவர் முழுமையற்ற தரவின் அடிப்படையில் செயல்பட்டு தவறான முடிவுகளை (false positive) வழங்கக்கூடும்.
பாதுகாப்பு எல்லைகள் (Security boundaries)
ஒரு AI-யை குறியீடு எழுத அனுமதிப்பது என்பது ஒரு பாதுகாப்பு அபாயத்தை (privilege escalation risk) ஏற்படுத்தும். sandbox ஒரு பிரத்யேக filesystem server-இன் பின்னணியில் இயங்குகிறது, இது எழுதும் எல்லையை (write scope) இலக்கு களஞ்சியத்திற்குள் (target repository) மட்டுமே கட்டுப்படுத்துகிறது மற்றும் ஒரு சோதனை தோல்வியடைந்தால் தானாகவே முந்தைய நிலையை மீட்டெடுக்கிறது. இந்தத் தடுப்பு முறை (containment model) AI-யின் அதிகாரத்தைக் கட்டுப்பாட்டில் வைக்கிறது.
டோக்கன் வரம்புகள் (Token limits)
Large language models API tokens-களைப் பயன்படுத்துகின்றன, மேலும் ஆய்வின் நடுவிலேயே தினசரி ஒதுக்கீடு (daily quota) தீர்ந்துவிடக்கூடும். AgentOps ஒவ்வொரு சம்பவத்திற்கும் டோக்கன் பயன்பாட்டைக் கண்காணிக்கிறது மற்றும் ஒரு குறிப்பிட்ட வரம்பு எட்டப்பட்டவுடன் அடுத்தடுத்த அழைப்புகளைக் குறைக்கிறது (throttles), இதனால் ஒதுக்கீடு தீர்ந்துபோகும் போது தோல்வியுற்ற திருத்தங்களின் தொடர்ச்சியான சிக்கல்களைத் தவிர்க்க முடிகிறது.
டெமோ எதை நிரூபித்தது
அந்தக் குறியீட்டுத் தொகுப்பில் (codebase) இதற்கு முன் இருந்ததே இல்லாத ஒரு புதிய பிழையை இக்குழுவினர் உருவாக்கினர். AgentOps அந்த முரண்பாட்டைக் (anomaly) கண்டறிந்து, அதைத் துல்லியமான வரிக்குக் கொண்டு சென்று, ஒரு திருத்தத்தை உருவாக்கி, sandbox-இல் அந்த patch-ஐப் பயன்படுத்தி, கோரிக்கை வெற்றி பெற்றதையும் சரிபார்த்தது—இவை அனைத்தும் எந்தவிதமான கைமுறை குறியீடு மாற்றங்கள் அல்லது புதிய prompts இன்றி நிகழ்ந்தன. ஒட்டுமொத்தச் செயல்முறையும் ஒரு நிமிடத்திற்கும் குறைவாகவே முடிந்தது, இது அறிக்கையிடப்பட்ட 30-60 வினாடி கால அளவோடு ஒத்துப்போகிறது.
எதிர்முனை: தன்னாட்சி என்பது அனைத்துப் பிரச்சினைகளுக்கும் தீர்வல்ல
அடுத்து கவனிக்க வேண்டியவை
- மாடல்-சார்பற்ற டெலிமெட்ரி (Model-agnostic telemetry) – அதிகப்படியான விற்பனையாளர்கள் OpenTelemetry-க்கு இணக்கமான spans-களை வெளிப்படுத்தும் போது, இந்த அணுகுமுறை விற்பனையாளர்-சார்பற்றதாக மாறி, பல்வேறு வகையான தொழில்நுட்பக் கட்டமைப்புகளில் (heterogeneous stacks) இதனைப் பயன்படுத்துவதை எளிதாக்கும்.
- கொள்கை சார்ந்த பாதுகாப்பு வழிமுறைகள் (Policy-driven guardrails) – ஒரு ஏஜென்ட் எந்தக் கோப்புகளைத் திருத்தலாம் அல்லது ஒரு commit-க்கு முன் எந்தச் சோதனைத் தொகுப்புகள் (test suites) தேர்ச்சி பெற வேண்டும் என்பதைத் தீர்மானிக்கும் மாற்றியமைக்கக்கூடிய கொள்கைகளை உட்பொதிப்பது, நிர்வாகக் கவலைகளைச் (governance concerns) சரிசெய்யும்.
- செலவு சார்ந்த டோக்கன் வரவு-செலவுத் திட்டம் (Cost-aware token budgeting) – சம்பவத்தின் தீவிரத்தைப் பொறுத்து மாறும் டோக்கன் ஒதுக்கீடு, அதிக பாதிப்பை ஏற்படுத்தும் பிழைகளைக் கையாளுவதற்கான திறனைத் தக்கவைக்கும் அதே வேளையில், ஒதுக்கீடு செய்யப்பட்ட அளவு (quota) தீர்ந்துபோவதைத் தடுக்கலாம்.
AgentOps பிழைத் திருத்தச் சுழற்சி 30-60 வினாடிகள் வரை எடுக்கலாம் என்பதைக் காட்டுகிறது. கண்காணிப்புத் திறனை (observability) தன்னாட்சி மென்பொருள் உதவியாளர்கள் பயன்படுத்த முடியும் என்பதற்கான ஒரு நிரூபணக் கருத்தாக்கத்தை (proof-of-concept) இந்தச் சோதனை விளக்குகிறது.