AI ஏஜென்ட் ரோல்பேக் திட்டம் (Rollback Plan): பயனர்கள் நம்பிக்கையை இழப்பதற்கு முன் தவறான செயல்களைத் திரும்பப் பெறுதல்
ஒரு நம்பகமான AI ஏஜென்ட் எப்போதும் குறையில்லாமல் இருக்க வேண்டிய அவசியமில்லை. அது எவ்வாறு நிறுத்துவது, தனது தவறை விளக்குவது மற்றும் மீண்டும் பழைய நிலைக்குத் திரும்புவது என்பதைத் தெரிந்திருக்க வேண்டும்.
உங்கள் ஏஜென்ட் தவறான CRM புலத்தைப் (field) புதுப்பித்தாலோ அல்லது ஒருமுறை அனுப்ப வேண்டிய பணத்தை மீண்டும் ஒருமுறை அனுப்பினாலோ, ஒரு சாதாரண 'retry' மூலம் அந்தப் பாதிப்பைச் சரிசெய்ய முடியாது. ஒரு உண்மையான சிக்கலைச் சந்திப்பதற்கு முன்பே உங்களிடம் ஒரு ரோல்பேக் திட்டம் (rollback plan) இருக்க வேண்டும்.
ஏஜென்ட்கள் வெறும் உரையாடலில் (chat) இருந்து நிஜமான வேலைகளுக்கு மாறும்போது, அவை தரவு நிலையை (state) மாற்றுகின்றன. இதனால் ரோல்பேக் என்பது வெறும் பின்னணிப் பணி (backend task) மட்டுமல்ல, அது ஒரு தயாரிப்பு அம்சமாகவே (product feature) மாறுகிறது.
பொதுவான தோல்வி முறைகள்:
- ஏஜென்ட் தவறான ரெக்கார்ட் ஐடியைப் (record ID) பயன்படுத்துகிறது.
- ஒரு 'retry' செயல் ஒரு செயலை இரண்டு முறை செய்கிறது.
- மாடல் மாற்றம் (model switch) ஒரு கருவி (tool) செயல்படும் விதத்தை மாற்றுகிறது.
- ஒரு பணிப்பாய்வு (workflow) பழைய நினைவகத்துடன் (memory) மீண்டும் தொடங்குகிறது.
- ஒரு பகுதித் தொடர் தரவுகளை முரண்பாடாக (inconsistent) விட்டுவிடுகிறது.
ஒரு மீட்பு அடுக்கை (recovery layer) எவ்வாறு உருவாக்குவது:
ஒரு செயல் பதிவேட்டைப் (Action Ledger) பயன்படுத்துங்கள் லாகுகளை (logs) மட்டும் நம்பியிருக்க வேண்டாம். ஒவ்வொரு நிலை மாற்றத்தையும் பதிவு செய்யும் ஒரு பதிவேட்டை உருவாக்குங்கள். ஒவ்வொரு கருவி அழைப்பும் (tool call) செயல்படுவதற்கு முன்னும் பின்னும் ஒரு பதிவை உருவாக்க வேண்டும். இதுவே மீட்புக்கான உங்கள் உண்மையான ஆதாரமாகும் (source of truth).
உங்கள் செயல்களை வகைப்படுத்துங்கள் எல்லாச் செயல்களும் ஒன்றல்ல.
- Read-only: ரோல்பேக் தேவையில்லை.
- Internal updates: ஒரு ஸ்னாப்ஷாட் (snapshot) மூலம் முந்தைய மதிப்பை மீட்டெடுங்கள்.
- External reversible: நிகழ்வை நீக்குங்கள் அல்லது நிலையைப் புதுப்பிக்கவும்.
- External irreversible: உண்மையான 'undo' செய்வதற்குப் பதிலாக இழப்பீட்டு முறையைப் (compensation) பயன்படுத்துங்கள். மின்னஞ்சல்கள் அல்லது பணப் பரிமாற்றங்களை நீங்கள் "திரும்பப் பெற" (un-send) முடியாது. நீங்கள் ஒரு திருத்தத்தையோ அல்லது ரீஃபண்டையோ (refund) அனுப்ப வேண்டும்.
ஐடெம்போடென்சியை (Idempotency) உறுதிப்படுத்துங்கள் மாடல் ஐடெம்போடென்சியை உறுதிப்படுத்தாது. உங்கள் டூல் ரன்டைம் (tool runtime) அதைச் செய்ய வேண்டும். ஒரு ஏஜென்ட் ஒரு பணியை மீண்டும் செய்யும்போது, அது இரட்டைத் தாக்கங்களை (duplicate side effects) உருவாக்காமல் இருப்பதை உறுதி செய்ய ஐடெம்போடென்சி கீகளைப் (idempotency keys) பயன்படுத்துங்கள்.
சாகா பேட்டர்னைப் (Saga Pattern) பயன்படுத்துங்கள் நீண்ட பணிப்பாய்வுகளுக்கு (workflows), ஒவ்வொரு முன்னேற்றச் செயலுக்கும் ஒரு இழப்பீட்டுச் செயல் (compensating action) தேவை.
- ஒரு பணியை உருவாக்குகிறீர்களா? அதை நீக்குவது அல்லது ரத்து செய்வதுதான் இழப்பீடு.
- ஒரு புலத்தைப் புதுப்பிக்கிறீர்களா? பழைய மதிப்பை மீட்டெடுப்பதே இழப்பீடு.
- ஒரு மின்னஞ்சலை அனுப்புகிறீர்களா? ஒரு திருத்த மின்னஞ்சலை அனுப்புவதே இழப்பீடு.
செக்பாயிண்டுகளைச் (Checkpoints) செயல்படுத்துங்கள் ஒரு செயலி முடங்கிய பிறகு (crash), "நாம் எங்கே இருந்தோம் என்று கண்டறியவும்" என்று மாடலிடம் கேட்பதை நிறுத்துங்கள். தற்போதைய நிலை, முடிக்கப்பட்ட செயல்கள் மற்றும் நிலுவையில் உள்ள பணிகளைச் சேமிக்க செக்பாயிண்டுகளைப் பயன்படுத்துங்கள். பணியைத் தொடர சிஸ்டம் அந்த செக்பாயிண்டுகளை ஏற்ற வேண்டும்.
ஒரு மீட்பு வரிசையை (Recovery Queue) உருவாக்குங்கள் சரிபார்ப்புப் படிவம் தோல்வியடையும் போது, அந்தப் பணியை ஒரு மீட்பு வரிசைக்கு மாற்றவும். இது பணியைத் தொடரவோ, இழப்பீடு செய்யவோ அல்லது முடிக்கவோ உங்களுக்கு உதவும். அதிக ஆபத்துள்ள பிழைகளுக்கு, எப்போதும் ஒரு மனிதரின் ஒப்புதலைப் பெறுங்கள்.
வெளிப்படையான மீட்பு நடவடிக்கைகளின் மூலமே நம்பிக்கை கட்டமைக்கப்படுகிறது. ஒரு ஏஜென்ட் தவறு செய்யும்போது, தெளிவற்ற மொழியைப் பயன்படுத்த வேண்டாம். என்ன மாறியது, அது ஏன் நடந்தது மற்றும் அதை எப்படிச் சரிசெய்தீர்கள் என்பதைப் பயனருக்குத் துல்லியமாகத் தெரியப்படுத்துங்கள்.
முதல் சிக்கல் ஏற்படுவதற்கு முன்பே உங்கள் ரோல்பேக் திட்டத்தை உருவாக்கிவிடுங்கள்.
Optional learning community: https://t.me/GyaanSetuAi