இரண்டு AI முகவர்கள் ஒரே கோப்பைத் திருத்த முடியும், இரண்டுமே “வெற்றி” (success) என்ற உறுதிப்படுத்தலைப் பெறலாம், இருப்பினும் அவர்களில் ஒருவரின் மாற்றங்கள் மட்டுமே நிலைத்திருக்கும். ஐந்து ஒரே நேரத்தில் இயங்கும் முகவர்களுடன் நடத்தப்பட்ட ஒரு எளிய சோதனையில், ஐந்து எழுத்துக்களில் நான்கு எழுத்துக்கள் எந்தத் தவறு அல்லது பதிவு (log entry) இன்றி மறைந்துவிட்டன—இது காணாமல் போன வேலைக்காகச் செலுத்தப்பட்ட டோக்கன்களை வீணடிக்கும் ஒரு வழக்கமான lost-update முரண்பாடு ஆகும்.
ஏன் இந்த பிரச்சனை முக்கியமானது
ஒரு AI முகவர் ஒரு முடிவை எழுதும்போது, அடிப்படைச் சேவை உருவாக்கப்பட்ட ஒவ்வொரு டோக்கனுக்கும் கட்டணம் வசூலிக்கிறது. அந்த எழுத்து அமைதியாக மேலெழுதப்பட்டால் (overwritten), நிராகரிக்கப்பட்ட வெளியீட்டை உருவாக்கப் பயன்படுத்தப்பட்ட கணக்கீட்டிற்கும் சேவை வழங்குநர் கட்டணம் வசூலிப்பார். பல முகவர் குழாய்கள் (multi-agent pipelines)—முகவர் கூட்டங்கள் (agent swarms), இணையாக இயங்கும் தரவு-சுத்திகரிப்பு பணியாளர்கள் அல்லது பல பாட்கள் ஒரு திட்டக் கோப்பு அல்லது ஒரு தற்காலிகப் பதிவேட்டைப் (scratchpad) பகிர்ந்து கொள்ளும் எந்தவொரு அமைப்பிலும்—இந்த மறைமுக இழப்புகள் ஒரு குறிப்பிடத்தக்க செலவு கசிவாக (cost leak) மாறக்கூடும். இந்த முரண்பாடு தரவு ஒருமைப்பாட்டிற்கும் (data integrity) அச்சுறுத்தலாக அமைகிறது: அடுத்தடுத்த நிலைகள் (downstream steps) முழுமையற்ற அல்லது காலாவதியான தகவல்களின் அடிப்படையில் செயல்படலாம், இது தொடர்ச்சியான பிழைகளுக்கு (cascading errors) வழிவகுக்கும்.
இந்த முரண்பாடு எப்படி நிகழ்கிறது
இதன் மூலக் காரணம் ஒரு ரேஸ் கண்டிஷன் (race condition) ஆகும்:
- இரண்டு (அல்லது அதற்கு மேற்பட்ட) முகவர்கள் ஒரு வளத்தின் (resource) ஒரே பதிப்பைப் படிக்கிறார்கள், உதாரணமாக ஒரு JSON திட்டக் கோப்பு.
- ஒவ்வொன்றும் அந்த ஸ்னாப்ஷாட் (snapshot) அடிப்படையில் தனது சொந்தக் காரணமறிதல் அல்லது மாற்றத்தைச் செய்கிறது.
- இரண்டு முகவர்களும் பகிரப்பட்ட சேமிப்பகத்திற்கு (shared storage) ஒரு எழுத்துச் செயல்பாட்டை (write operation) அனுப்புகிறார்கள்.
- சேமிப்பு அமைப்பு இரண்டாவது எழுத்தை ஏற்றுக்கொண்டு, எந்த முரண்பாட்டையும் கண்டறியாமல் முதல் எழுத்தை மேலெழுதுகிறது.
- முதல் பங்களிப்பு மறைந்துவிட்டாலும், இரண்டு முகவர்களுக்கும் எழுத்து வெற்றி பெற்றதற்கான “ACK” கிடைக்கிறது.
சேமிப்பு அமைப்பின் உறுதிப்படுத்தல் (acknowledgment) ஒரு எழுத்து நிகழ்ந்ததை மட்டுமே நிரூபிக்கிறது; அது மற்ற ஒத்திசைவான மேம்படுத்தல்களுடன் (concurrent updates) ஒப்பிடும்போது அந்த எழுத்து பாதுகாப்பானது என்பதை உறுதிப்படுத்தாது. ஒரு append-only log, பெரும்பாலும் ஒரு பாதுகாப்பாகக் கருதப்பட்டாலும், அதேபோலவே செயல்படுகிறது: அது ஒரு எழுத்து நிகழ்ந்ததை மட்டுமே பதிவு செய்கிறது, ஆனால் பிந்தைய எழுத்துக்கள் முந்தையவற்றை அழிப்பதைத் தடுப்பதில்லை.
ஒரு compare-and-set gate என்ன செய்கிறது
ஒரு compare-and-set (CAS) கேட், எழுத்து ஏற்றுக்கொள்ளப்படுவதற்கு முன்னால் ஒரு பதிப்புச் சரிபார்ப்பைச் (version check) சேர்க்கிறது:
- வாசித்தல் (Read): முகவர் கோப்பின் தற்போதைய பதிப்பு எண்ணை (அல்லது hash) எடுக்கிறது.
- கணக்கிடுதல் (Compute): முகவர் தனது வேலையைச் செய்து, கோப்பின் புதிய பதிப்பை உருவாக்குகிறது.
- எழுதுதல் (Write): முகவர் தான் முதலில் வாசித்த பதிப்பு எண்ணுடன் புதிய உள்ளடக்கத்தையும் சேர்த்து அனுப்புகிறது.
- சரிபார்த்தல் (Validate): சேமிப்பு அடுக்கு (storage layer) வழங்கப்பட்ட பதிப்பு எண்ணை தற்போதைய பதிப்பு எண்ணுடன் ஒப்பிடுகிறது. அவை வேறாக இருந்தால், எழுத்து நிராகரிக்கப்படும்; இல்லையெனில், அது தொடரும் மற்றும் பதிப்பு எண்ணை அதிகரிக்கும்.
பதிப்பு எண் மாறியிருந்தால், தனது பார்வை காலாவதியாகிவிட்டது என்பதை முகவர் அறிந்து கொள்வார், மேலும் புதிய பதிப்பைப் பயன்படுத்தி முழுச் சுழற்சியையும்—வாசித்தல், கணக்கிடுதல், எழுதுதல்—மீண்டும் செய்ய வேண்டும். இது ஒரு கண்ணுக்குத் தெரியாத மேலெழுதலை, பதிவு செய்யக்கூடிய, மீண்டும் முயற்சிக்கக்கூடிய மற்றும் கணக்கிடக்கூடிய ஒரு வெளிப்படையான தோல்வியாக மாற்றுகிறது.
பாதுகாப்பிற்கான விலை
CAS கேட் இலவசமானது அல்ல. அதே ஐந்து முகவர் உருவகப்படுத்துதலில் (simulation):
| சூழல் | முயற்சிக்கப்பட்ட எழுத்துக்கள் | வெற்றிகரமான பங்களிப்புகள் | டோக்கன் செலவு |
|---|---|---|---|
| CAS கேட் இல்லை | 5 | 1 | 5 அலகுகள் |
| CAS கேட் உள்ளது | 5 | 5 (மறுமுயற்சிகளுக்குப் பிறகு) | 9 அலகுகள் |
பதிப்பு முரண்பாட்டைச் சந்திக்கும் முகவர்களுக்கு, இந்த கேட் கூடுதல் வாசித்தல்-கணக்கிடுதல்-எழுதுதல் சுழற்சிகளைச் சேர்க்கிறது, இது டோக்கன் செலவை அதிகரிக்கிறது. இதன் சமநிலை (trade-off) தெளிவானது: கேட் இல்லையென்றால் நீங்கள் தரவை அமைதியாக இழப்பீர்கள்; கேட் இருந்தால் நீங்கள் ஒரு சிறிய கூடுதல் தொகையைச் செலுத்த வேண்டியிருக்கும், ஆனால் ஒவ்வொரு முரண்பாட்டையும் தெளிவாகக் காண முடியும்.
இந்தத் தோல்வி எவ்வளவு பொதுவானது?
இரண்டு முகவர்கள் மட்டுமே இருந்தபோதும், ஒரு எழுத்து இழக்கப்பட 75% வாய்ப்பு இருப்பதாகச் சோதனை காட்டியது. ஐந்து முகவர்களுடன், இழப்பு விகிதம் 100% ஐ நெருங்கியது. இந்த எண்கள், எந்தவொரு உற்பத்தி நிலை (production-level) பல முகவர் பணிப்பாய்விற்கும் (multi-agent workflow) “பொதுவாகச் சரியாக இருக்கும்” என்ற அனுமானம் ஆபத்தானது என்பதை உணர்த்துகின்றன.
முரண்பட்ட வாதம்: எப்போது கேட்டைத் தவிர்க்கலாம்
ஒரு அமைப்பு ஒரு வளத்திற்கு ஒரு முகவரை மட்டுமே இயக்குகிறது அல்லது உயர் மட்டத்தில் கடுமையான தொடர் வரிசைப்படுத்துதலை (strict serialisation) நடைமுறைப்படுத்துகிறது என்றால், கூடுதல் CAS சரிபார்ப்புகள் தேவையில்லை. இருப்பினும், இடர் கணக்கீட்டில் தோல்வியடைந்த வேலையை மீண்டும் இயக்குவதற்கான மறைமுகச் செலவு மற்றும் விடுபட்ட தரவுகளால் ஏற்படக்கூடிய அடுத்தடுத்த பாதிப்புகள் ஆகியவற்றைச் சேர்க்க வேண்டும்.
அடுத்து கவனிக்க வேண்டியவை
- கருவி ஆதரவு (Tooling support): பதிப்பு எண்கள் அல்லது ETags-களை வெளிப்படுத்தும் மற்றும் இயல்பாகவே atomic CAS செயல்பாடுகளை வழங்கும் storage APIs-களைத் தேடுங்கள்.
- அளவீடுகள் (Metrics): பதிப்பு பொருந்தாமை காரணமாக ஒரு எழுத்து எவ்வளவு அடிக்கடி நிராகரிக்கப்படுகிறது என்பதைப் பதிவு செய்ய உங்கள் முகவர்களைக் கண்காணிக்கும் வகையில் (instrument) அமைத்திடுங்கள். அதிகரித்து வரும் முரண்பாட்டு விகிதம், நீங்கள் வளங்களை அதிகரிக்க வேண்டும் அல்லது பணிப்பாய்வை மறுவடிவமைப்பு செய்ய வேண்டும் என்பதைக் குறிக்கிறது.
- மறுமுயற்சி உத்திகள் (Retry strategies): எளிய exponential back-off சிறப்பாகச் செயல்படும், ஆனால் தொடர்ச்சியான மறுமுயற்சிகள் டோக்கன் நுகர்வை அதிகரிக்கும் என்பதை நினைவில் கொள்ளுங்கள். ஏற்றுக்கொள்ளக்கூடிய தரவு இழப்பிற்கும் மறுமுயற்சி வரம்புகளுக்கும் இடையே சமநிலையைப் பேணுங்கள்.
- கலப்பு அணுகுமுறைகள் (Hybrid approaches): சில குழுக்கள் தணிக்கைக்காக (auditability) ஒரு append-only log மற்றும் நிலைத்தன்மைக்காக (consistency) ஒரு CAS கேட் ஆகிய இரண்டையும் இணைக்கின்றன, இது என்ன நடந்தது என்பதற்கான பதிவையும் மற்றும் மேலெழுதல்களுக்கு எதிரான பாதுகாப்பையும் உறுதி செய்கிறது.
முக்கியக் கருத்து (Takeaway)
Lost-update முரண்பாடுகள், டோக்கன் மூலம் இயங்கும் AI pipelines-களை பணத்தை வெளியேற்றும் கருந்துளைகளாக மாற்றுகின்றன. ஒரு compare-and-set version gate, சிறிய அளவிலான token overhead-ஐச் சேர்த்தாலும், அமைதியான தரவு இழப்பை (silent data loss) கண்ணுக்குத் தெரியும், மீண்டும் முயற்சிக்கக்கூடிய ஒரு நிகழ்வாக மாற்றுகிறது. பல ஏஜெண்டுகள் (agents) நிலையைப் (state) பகிர்ந்து கொள்ளும் எந்தவொரு அமைப்பிற்கும்—தரவுத்தளங்கள் (databases), திட்டக் கோப்புகள் (plan files), அல்லது ஸ்க்ராட்ச்பேட்கள் (scratchpads)—எழுதுவதற்கு முன் ஒரு பதிப்புச் சரிபார்ப்பைச் (version check) சேர்ப்பது, மறைமுகச் செலவுகள் மற்றும் சிதைந்த பணிப்பாய்வுகள் (workflows) ஆகியவற்றிற்கு எதிரான மிக மலிவான காப்பீடாகும்.