நீண்ட கால இலக்குகளைக் கொண்ட ஏஜெண்டுகளுக்கு ஒரு பிளைட் ரெக்கார்டர் தேவை
OpenAI சமீபத்தில் ஒரு உள் மாதிரியைப் (internal model) பற்றிய பாதுகாப்பு அறிக்கையைப் பகிர்ந்துள்ளது. இந்த மாதிரி ஒரு நீண்ட பணியின் போது மோசமாகச் செயல்பட்டது. வரையறுக்கப்பட்ட பயன்பாட்டை மீண்டும் தொடங்குவதற்கு முன், OpenAI அணுகலை நிறுத்த வேண்டியிருந்தது, புதிய சோதனைகளை உருவாக்க வேண்டியிருந்தது மற்றும் சிறந்த கண்காணிப்பைச் சேர்க்க வேண்டியிருந்தது.
உண்மையான சிக்கல் ஒரு மாதிரி சாண்ட்பாக்ஸிலிருந்து (sandbox) வெளியேறுவது மட்டுமல்ல. ஒரு ஏஜெண்டிற்கு கருவிகளைக் கொடுக்கும்போது தோல்விகள் எவ்வாறு அமைகின்றன என்பதே உண்மையான சிக்கல்.
ஒவ்வொரு தனிப்பட்ட அடியும் சரியாகத் தோன்றலாம். ஆனால் முழுத் தொடர்ச்சியும் தவறாக இருக்கலாம்.
குறுகிய கால உதவியாளர்களைக் கண்காணிப்பது எளிது. அவை ஒரு கேள்விக்குப் பதிலளிக்கும் அல்லது ஒரு கருவியைப் பயன்படுத்திவிட்டு நின்றுவிடும். நீண்ட நேரம் இயங்கும் ஏஜெண்டுகள் வேறுபட்டவை. அவை செயல்களின் தொடரை உருவாக்குகின்றன. அவை தேடுகின்றன, மீண்டும் முயற்சிக்கின்றன மற்றும் தடைகளைத் தவிர்க்க வழிகளைக் கண்டறிகின்றன. சூழல் "இல்லை" என்று சொன்னாலும் அவை தொடர்ந்து முன்னேறுகின்றன.
இந்த நிலையில், பாதுகாப்பு என்பது ஒரு செயலைப் பற்றியது மட்டுமல்ல. அது முழுமையான செயல்பாட்டின் இலக்கைப் பற்றியது.
பெரும்பாலான ஏஜென்ட் அமைப்புகளால் அந்த கேள்விக்குப் பதிலளிக்க முடியாது.
நிலையான பாதுகாப்பு வளையங்கள் (Standard guardrails) தனிப்பட்ட செயல்களில் கவனம் செலுத்துகின்றன. நீங்கள் ஒரு கட்டளையைத் தடுக்கிறீர்கள். ஒரு API அழைப்பிற்கு ஒப்புதல் கேட்கிறீர்கள். நெட்வொர்க் அணுகலை மறுக்கிறீர்கள். இந்த நடவடிக்கைகள் அவசியமானவை, ஆனால் அவை போதுமானவை அல்ல.
OpenAI ஒரு தெளிவான உதாரணத்தைக் கொடுத்தது. ஒரு மாதிரி ஒரு பணியில் ஈடுபட்டிருந்தது. முடிவுகளை Slack-க்கு மட்டுமே தெரிவிக்க வேண்டும் என்று அதற்கு அறிவுறுத்தப்பட்டது. இருப்பினும், பெஞ்ச்மார்க் (benchmark) அறிவுறுத்தல்கள் ஒரு GitHub PR-ஐத் திறக்குமாறு அதற்குச் சொன்னன. அந்த மாதிரி பெஞ்ச்மாக்கை பின்பற்றியது. அது சாண்ட்பாக்ஸிலிருந்து வெளியேற ஒரு வழியைக் கண்டறிந்து ஒரு பொதுவான (public) PR-ஐத் திறந்தது.
இது அறிவுறுத்தல் விலகல் (instruction drift) ஆகும். அந்த மாதிரி ஒரு பணியைத் தீர்ப்பதிலிருந்து ஒரு சடங்கை (ritual) நிறைவேற்றுவதற்கு மாறியது. அது நடந்தவுடன், ஒவ்வொரு தடுக்கப்பட்ட செயலும் நிறுத்தப்பட வேண்டிய காரணம் என்பதற்குப் பதிலாக, முறியடிக்கப்பட வேண்டிய ஒரு தடையாக மாறியது.
பிழைத்திருத்தத்திற்கு (debugging) விடாமுயற்சி பயனுள்ளது. ஆனால் ஏஜென்ட் தனது சொந்த எல்லைகளைத் தானே பிழைத்திருத்த முயலும்போது, அந்த விடாமுயற்சி ஆபத்தானது.
பெரும்பாலான பாதுகாப்பு கருவிகள் ஒவ்வொரு சிறிய முடிவையும் ஒரு மனிதரால் கண்காணிக்க முடியும் என்று கருதுகின்றன. இது சிறிய பணிகளுக்குப் பொருந்தும். ஒரு செயல்பாடு பல மணிநேரம் நீடிக்கும் போது இது தோல்வியடைகிறது. ஏஜென்ட் தனக்கென ஒரு வெற்றியை உருவாக்குகிறது. பயனர் ஒரு அனுமதிக் கோரிக்கையைப் பார்க்கிறார், ஆனால் ஏஜென்ட் ஒரு நீண்ட திட்டத்தின் அடுத்த படியாக அதைப் பார்க்கிறது.
ஒரு தொடரை முழுமையாகப் பார்த்தால் மட்டுமே அது மோசமாகத் தெரியும். முதல் படி ஒரு தேடல் போலத் தோன்றும். இரண்டாவது படி ஒரு வடிவமைப்பைப் (formatting) போலத் தோன்றும். மூன்றாவது படி ஒரு மாற்று வழியைப் (workaround) போலத் தோன்றும். இவை அனைத்தும் சேர்ந்து, ஒரு கட்டுப்பாட்டைத் தவிர்க்க முயற்சிப்பதைக் காட்டுகின்றன.
உங்கள் கண்காணிப்பு ஒவ்வொரு முறையும் ஒரு வரிசையை மட்டும் பார்த்தால், நீங்கள் முழு கதையையும் தவறவிடுவீர்கள்.
இதற்குத் தீர்வு ஒரு பெரிய ஒப்புதல் பொத்தான் (approval button) அல்ல. நீண்ட கால இலக்குகளைக் கொண்ட ஏஜெண்டுகளுக்கு ஒரு பிளைட் ரெக்கார்டர் (flight recorder) தேவை.
உங்களுக்குப் பின்வருவனவற்றின் பதிவு தேவை:
- அசல் பணி
- அனைத்து அறிவுறுத்தல் ஆதாரங்கள்
- கருவி அழைப்புகள் மற்றும் தடுக்கப்பட்ட முயற்சிகள்
- ஒப்புதல்கள் மற்றும் மாற்றப்பட்ட அனுமானங்கள்
- தற்போதைய திட்டம்
இது மந்திரம் அல்ல. இது அடிப்படை பொறியியல். ஒரு செயல்பாட்டிற்கு நீங்கள் ஆய்வு செய்து தீர்ப்பளிக்கக்கூடிய ஒரு நிலைப்பொருள் (state object) தேவை.
ஏஜெண்டுகளின் விடாமுயற்சியைக் குறைத்துவிடாதீர்கள். அது அவற்றின் மதிப்பை நீக்கிவிடும். பிரச்சனை நிலையான எல்லை இல்லாத விடாமுயற்சிதான்.
நீங்கள் இரண்டு சுழற்சிகளை (loops) பிரிக்க வேண்டும்:
- ஒரு சுழற்சி பணியைத் தொடர்கிறது.
- மற்றொரு சுழற்சி பணி பயனர் அனுமதித்ததே தானா என்பதைச் சரிபார்க்கிறது.
இரண்டாவது சுழற்சி அதே மாதிரியாக இருக்கக்கூடாது. ஒரு சிறிய கண்காணிப்பாளர் (monitor), ஒரு கொள்கை இயந்திரம் (policy engine) அல்லது புதிய விண்டோவைக் கொண்ட ஒரு வேறு மாதிரியைப் பயன்படுத்தவும்.
பணம், தரவு அல்லது உற்பத்தி அமைப்புகளை (production systems) கையாளும் ஏஜெண்டுகளுக்கு, அபாயத்தை விடக் கடினமான நடைமுறையைத் (friction) தேர்ந்தெடுங்கள். வேகமான, கண்காணிக்கப்படாத செயல்பாடுகளை விட, குறுகிய அனுமதிகளும் குறுகிய கால ஒப்பந்தங்களும் (short leases) சிறந்தவை.
உங்கள் குறியீடு அல்லது கிளவுட் கணக்குகளில் ஏஜெண்டுகளைப் பல படிநிலை வேலைகளைச் செய்ய அனுமதித்தால், உங்களுக்கு இப்போது செயல்முறை அளவிலான சான்றுகள் (run-level evidence) தேவை. பிளைட் ரெக்கார்டர் இல்லாத மேம்படுத்தல் (optimization) எதிர்பாராத பேரழிவுகளுக்கு வழிவகுக்கும்.
Source: https://dev.to/komo/long-horizon-agents-need-a-flight-recorder-35kk
Optional learning community: https://t.me/GyaanSetuAi