தடுக்கப்பட்டது என்பது தோல்வி அல்ல: ஏஜென்ட்களுக்கு எல்லை சார்ந்த பின்னூட்டம் தேவை

பெரும்பாலான ஏஜென்ட் அமைப்புகள், ஒரு தடுக்கப்பட்ட செயலை ஒரு கருவியின் (tool) தோல்வியாகக் கருதுகின்றன.

ஒரு ஏஜென்ட் ஒரு கருவியை அழைக்கிறது. அந்த கோரிக்கை ஒரு விதியைப்breaking (மீறுகிறது). சிஸ்டம் ஒரு பொதுவான பிழையை (generic error) வழங்குகிறது. கருவி அழைப்பு தோல்வியடைகிறது.

இது முதலில் சரியாகத் தோன்றலாம். பாதுகாப்பற்ற செயல் தடுக்கப்பட்டது. ஆனால் இது பாதிப் பிரச்சனையை மட்டுமே தீர்க்கிறது.

ஒரு பொதுவான பிழை, ஒரு ஏஜென்ட் தனது எல்லைக்குள் செயல்பட உதவவில்லை. இது ஒரு கொள்கை முடிவை (policy decision) வெறும் இரைச்சலாக (noise) மாற்றிவிடுகிறது. ஏஜென்ட் ஒரு தீர்வை யூகிக்க முயலலாம். அது அதே தவறை மீண்டும் செய்யலாம் அல்லது வேறு ஒரு தரவை (payload) முயற்சி செய்யலாம். இது பயனற்ற மறுமுயற்சிகளின் சுழற்சியை உருவாக்குகிறது.

ஒரு தடுக்கப்பட்ட செயல் என்பது ஒரு கட்டமைக்கப்பட்ட முடிவாக (structured decision) இருக்க வேண்டுமே தவிர, எதிர்பாராத செயலிழப்பாக (unexpected crash) இருக்கக்கூடாது.

ஒரு கோரிக்கை தடுக்கப்படும்போது, வெளிப்புற சிஸ்டம் மாறக்கூடாது. இருப்பினும், அந்தப் பதில், ஏஜென்ட் எவ்வாறு பாதுகாப்பாகத் தொடர வேண்டும் என்பதைத் தெரிவிக்க வேண்டும்.

ஒரு சாதாரண பிழைக்கு பதிலாக, ஒரு கட்டமைக்கப்பட்ட பதிலை (structured response) பயன்படுத்தவும்.

ஒரு ஏஜென்ட் திட்டமிடும் போதே மாறிய ஒரு கோப்பில் எழுத முயற்சிப்பதாகக் கற்பனை செய்து பாருங்கள். ஒரு பொதுவான பிழை "தோல்வி" (failed) என்று சொல்லும். ஆனால் ஒரு கட்டமைக்கப்பட்ட பதில் இவ்வாறு சொல்லும்:

  • முடிவு நிலை (Decision status): முரண்பாடு (conflict)
  • விளைவு நிலை (Outcome status): பாதிப்பில்லை (no impact)
  • காரணம் (Reason): காலாவதியான நிலை (stale state)
  • அடுத்த செயல் (Next action): இலக்கு நிலையை மீண்டும் படிக்கவும் (re-read target state)

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

இது பல சூழல்களுக்குப் பொருந்தும்:

  • ஒரு பாதை வரம்பிற்கு அப்பாற்பட்டது (out of scope) என்றால், அனுமதிக்கப்பட்ட பாதையைப் பரிந்துரைக்கவும்.
  • ஒரு விளைவு ஏற்கனவே இருந்தால், அந்த முடிவை மீண்டும் பயன்படுத்துமாறு பரிந்துரைக்கவும்.
  • பாதிப்பு மிக அதிகமாக இருந்தால், மனித ஆய்விற்காக (human review) காத்திருக்கப் பரிந்துரைக்கவும்.

இது எல்லையைத் தளர்த்தாது. செயல் தடுக்கப்பட்டே இருக்கும். சிஸ்டம் பாதுகாப்பாகவே இருக்கும். நீங்கள் ஒரு முட்டுச்சந்தையை ஒரு வழிகாட்டப்பட்ட பாதையாக மாற்றுகிறீர்கள்.

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

காலாவதியான தரவு (stale data) அல்லது தவறான உள்ளீடுகள் (malformed inputs) போன்ற செயல்பாட்டுத் தடைகளுக்குத் தெளிவான காரணக் குறியீடுகளைப் (reason codes) பயன்படுத்தவும். ஏஜென்ட் சந்தேகத்திற்கிடமான நடத்தையைக் காட்டினால் அல்லது குறிப்புகளைப் புறக்கணித்தால், பொதுவான நிராகரிப்புகள் அல்லது மனித ஆய்விற்கு மாறவும்.

ஏஜென்ட் பின்னூட்டத்தை தணிக்கை மதிப்பெண்களிலிருந்து (audit scores) தனித்துப் பிரிக்கவும். ஏஜென்ட் எவ்வாறு இணங்கச் செயல்பட வேண்டும் (compliant) என்பதை அது அறிய வேண்டும். ஏஜென்ட் மோசமாகச் செயல்படுகிறதா என்பதை சிஸ்டம் அறிய வேண்டும். இந்த இரண்டு பணிகளையும் ஒன்றாகக் கலக்க வேண்டாம்.

ஏஜென்ட்கள் நிஜமான சிஸ்டங்களில் செயல்படும் அளவுக்குப் பயனுள்ளதாக மாறி வருவதால் தான் இந்த எல்லைகள் உள்ளன. நிஜமான வேலைகளுக்கு விதிகள் மற்றும் வரம்புகள் உண்டு.

தோல்வியை மட்டுமே வழங்கும் எல்லை ஒரு சுவர். வழிகாட்டலை வழங்கும் எல்லை ஒரு கருவி.

Blocked என்பதன் பொருள்:

  • கோரப்பட்ட தாக்கம் நிகழவில்லை.
  • அதற்கான காரணம் அறியப்பட்டுள்ளது.
  • அடுத்த பாதுகாப்பான நடவடிக்கை தெளிவாக உள்ளது.

மூலம்: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg

விருப்பத்தேர்வு கற்றல் சமூகம்: https://t.me/GyaanSetuAi