AI ஏஜென்ட்களை (agents) உருவாக்கும் டெவலப்பர்கள், எப்போதும் ஒரே மூன்று விஷயங்களை மட்டுமே சரிபார்க்கிறார்கள் – ஒரு 200 HTTP status, ஒரு fired callback மற்றும் பதிலில் (response) ஏதேனும் உரை (text) இருக்கிறதா என்பதுதான் – அதன் பிறகு வேலை முடிந்துவிட்டது என்று நினைத்துக்கொள்கிறார்கள். ஒரு மூன்று அடுக்கு சிக்னல் மாடல் (three-layer signal model), இந்த மேலோட்டமான பார்வை எவ்வாறு அமைதியான தோல்விகளை (silent failures) மறைக்கிறது என்பதைக் காட்டுகிறது.

ஏன் மேலோட்டமான சரிபார்ப்பு போதுமானதல்ல

பெரும்பாலான கண்காணிப்பு டேஷ்போர்டுகள் (monitoring dashboards), பிரேம்வொர்க் (framework) வெற்றியை அறிவித்தவுடன் பச்சை நிறமாக மாறிவிடும். அந்த வெற்றி என்பது செயல்பாட்டின் முதல் அடுக்கு மட்டுமே. மாடல் ஒரு காலியான பேலோடை (empty payload) வழங்கினாலோ, டஜன் கணக்கான தேவையற்ற டூல் அழைப்புகளை (tool calls) செய்தாலோ, அல்லது ஏஜென்ட்களுக்கு இடையே தரவை இழந்தாலோ, டேஷ்போர்டு இன்னும் "எல்லாம் சரியாக உள்ளது" என்றே காட்டும். மறைந்திருக்கும் பிரச்சனைகள் பின்னர் தான் வெளிப்படும், பெரும்பாலும் ஒரு வாடிக்கையாளர் விடுபட்ட தகவலைப் பற்றி புகார் செய்யும்போதோ அல்லது ஒரு டவுன்ஸ்ட்ரீம் சேவை (downstream service) தோல்வியடையும்போதோ இது நிகழும்.

செயல்பாட்டு வெற்றியின் மூன்று அடுக்குகள்

அடுக்கு 1 – பிரேம்வொர்க் அடுக்கு (Framework layer)

இது கண்ணுக்குத் தெரியும் விளிம்புப் பகுதி: HTTP response code, பிரேம்வொர்க்கின் "task finished" flag மற்றும் ஏதேனும் வெளியீட்டு உரை (output text) இருக்கிறதா என்பதுதான் இது. ஒரு 200 status என்பது கோரிக்கை (request) சர்வரைச் சென்றடைந்தது மற்றும் சர்வர் பதிலளித்தது என்பதைக் கூறுகிறது, ஆனால் மாடல் உண்மையில் என்ன செய்தது என்பதைப் பற்றி எதுவும் சொல்லவில்லை. ஒரு காலியான பதில் அல்லது பூஜ்ஜிய டோக்கன் (zero-token) பதில் கூட இந்த நிலையில் வெற்றியாகவே கருதப்படுகிறது.

அடுக்கு 2 – தரவு அடுக்கு (Data layer)

இங்கே நீங்கள் செயல்பாட்டின் உள்ளே பார்க்கிறீர்கள். தொடர்புடைய சிக்னல்கள் பின்வருமாறு:

  • டோக்கன் எண்ணிக்கை (Token counts) – மாடல் ஏதேனும் வெளியீட்டு டோக்கன்களை வழங்கியதா?
  • டூல்-கால் அதிர்வெண் (Tool-call frequency) – ஒரு டூல் எதிர்பார்த்ததை விட பல மடங்கு அதிகமாக அழைக்கப்பட்டுள்ளதா?
  • ஸ்கீமா சரிபார்ப்பு (Schema validation) – தவறான வடிவம் கொண்ட JSON, தெளிவான பிழைக்கு பதிலாக ஒரு அமைதியான ஃபேல்பேக் (silent fallback) நிலையைத் தூண்டியதா?
  • லேட்டன்சி (Latency) – ஒரு பணி 3 வினாடிகளுக்குப் பதிலாக 45 வினாடிகள் எடுத்துக்கொண்டதா?

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

அடுக்கு 3 – ஹேண்டாஃப் அடுக்கு (Handoff layer)

மல்டி-ஏஜென்ட் அமைப்புகளில் (multi-agent systems), தரவு ஒரு கூறிலிருந்து அடுத்த கூறிற்கு நகர வேண்டும். இந்த அடுக்கு அந்த நகர்வைக் கண்காணிக்கிறது:

  • டெலிவரி (Delivery) – வெளியீடு உண்மையில் அடுத்த கட்டத்தை அடைந்ததா?
  • இழப்பு (Loss) – பரிமாற்றத்தின் போது ஏதேனும் தரவு விடுபட்டதா?
  • சிதைவு (Corruption) – ஏஜென்ட்களுக்கு இடையே நகரும்போது பேலோடு (payload) மாற்றியமைக்கப்பட்டதா?

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

இதில் உள்ள ஆபத்து என்ன

அமைதியான தோல்விகளை (Silent failures) கண்டறிந்து சரிசெய்வது (debug) கடினம். AI சார்ந்த சேவைகளை விற்கும் நிறுவனங்களுக்கு, இந்த மறைந்திருக்கும் பிழைகள் நேரடியாக வருவாய் இழப்பிற்கும் மற்றும் நற்பெயர் பாதிப்பிற்கும் வழிவகுக்கும்.

மறைந்திருக்கும் சிக்னல்களை எவ்வாறு வெளிக்கொணருவது

இயல்பான பிரேம்வொர்க் கால்பேக்குகளை (default framework callbacks) மட்டும் நம்பியிருப்பது இனி போதுமானதல்ல. திட்டமிட்டு இன்ஸ்ட்ருமென்டேஷனை (instrumentation) சேர்க்கவும்:

அடுக்கு 2-ஐக் கண்காணித்தல்

  • ஒவ்வொரு முறையும் உள்ளீடு மற்றும் வெளியீட்டு டோக்கன் எண்ணிக்கையைப் பதிவு செய்யவும் (Log).
  • டூல்-கால் அதிர்வெண்ணைக் கண்காணித்து, அதை இயல்பான செயல்பாட்டின் அடிப்படையுடன் (baseline) ஒப்பிட்டுப் பார்க்கவும்.
  • வெளியீட்டு பார்சிங் (output parsing) வெற்றியடைந்ததா அல்லது தோல்வியடைந்ததா என்பதைப் பதிவு செய்யவும், தவறான JSON வடிவங்களைக் கண்டறியவும்.
  • விலகல்களைக் (outliers) கண்டறிய, சராசரியை மட்டும் பார்க்காமல் லேட்டன்சி பெர்சென்டைல்களை (latency percentiles) சேகரிக்கவும்.

அடுக்கு 3-ஐக் கண்காணித்தல்

  • கட்டமைப்பு ஒன்றுக்கும் மேற்பட்ட ஏஜென்ட்களைப் பயன்படுத்தினால், உற்பத்தியாளரிடமிருந்து (producer) நுகர்வோருக்கு (consumer) தரவு ஓட்டத்தைக் கண்டறியவும் (trace).
  • ஒரு கூறின் வெளியீடு அடுத்த கூறின் எதிர்பார்க்கப்படும் உள்ளீடு ஸ்கீமாவுடன் (input schema) ஒத்துப்போகிறதா என்பதைச் சரிபார்க்கவும்.
  • பொருந்தாமை, விடுபட்ட டெலிவரி அல்லது எதிர்பாராத பேலோடு அளவுகள் குறித்து எச்சரிக்கை செய்யவும்.

வாடிக்கையாளர் புகார் வந்த பிறகு மட்டுமல்லாமல், முன்கூட்டியே இத்தகைய லாக்ஸ்களைச் (logs) சேகரிக்கவும்.

முக்கியக் கருத்து (Takeaway): ஒரு பச்சை நிற டேஷ்போர்டு, ஒரு AI ஏஜென்ட் சரியாகச் செயல்பட்டதற்கான உத்தரவாதம் அல்ல. பிரேம்வொர்க்கின் வெற்றி கொடியைத் (success flag) தாண்டி, தரவு அடுக்குத் தர அளவீடுகள் (data-layer quality metrics) மற்றும் ஹேண்டாஃப் ஒருமைப்பாடு (handoff integrity) ஆகியவற்றையும் உள்ளடக்கி கண்காணிப்பை விரிவுபடுத்துவதன் மூலம், டெவலப்பர்கள் பயனர்களையோ அல்லது டவுன்ஸ்ட்ரீம் சேவைகளையோ பாதிக்கும் முன்பே அமைதியான தோல்விகளைக் கண்டறிய முடியும். மல்டி-ஏஜென்ட் பைப்லைன்களின் (multi-agent pipelines) காலத்தில், மேலோட்டமாக மட்டும் பார்ப்பது என்பது கண் தெரியாமல் பறப்பதைப் போன்றது.

Source: https://dev.to/babarmaker76/three-signal-layers-where-ai-agent-silent-failures-hide-1k02

Community for deeper discussion: https://t.me/GyaanSetuAi