രണ്ട് AI ഏജന്റുകൾക്ക് ഒരേ ഫയൽ എഡിറ്റ് ചെയ്യാൻ സാധിക്കും, രണ്ടുപേർക്കും “success” എന്ന സ്ഥിരീകരണം ലഭിച്ചേക്കാം, എങ്കിലും അവരിൽ ഒരാളുടെ മാറ്റങ്ങൾ മാത്രമേ നിലനിൽക്കുകയുള്ളൂ. അഞ്ച് ഏജന്റുകൾ ഒരേസമയം പ്രവർത്തിച്ചുകൊണ്ടുള്ള ഒരു ലളിതമായ പരീക്ഷണത്തിൽ, അഞ്ച് എഴുത്തുകളിൽ നാലെണ്ണം യാതൊരു പിഴവോ ലോഗ് എൻട്രിയോ ഇല്ലാതെ തന്നെ അപ്രത്യക്ഷമായി—ഇത് ടോക്കണുകൾ പാഴാക്കുന്ന ഒരു ക്ലാസിക് lost-update anomaly ആണ്.
ഈ പ്രശ്നം എന്തുകൊണ്ട് പ്രധാനമാണ്
ഒരു AI ഏജന്റ് ഒരു റിസൾട്ട് തിരികെ എഴുതുമ്പോൾ, അതിന് ഉപയോഗിച്ച ടോക്കണുകൾക്ക് അടിസ്ഥാന സേവനം ചാർജ് ചെയ്യും. എഴുതിയ വിവരങ്ങൾ നിശബ്ദമായി മറ്റൊരു വിവരത്താൽ മാറ്റിസ്ഥാപിക്കപ്പെട്ടാൽ (overwritten), ഒഴിവാക്കപ്പെട്ട ഔട്ട്പുട്ടിനായി നിർമ്മിച്ച കമ്പ്യൂട്ടേഷന് സേവനദാതാവ് ബില്ല് നൽകേണ്ടി വരും. മൾട്ടി-ഏജന്റ് പൈപ്പ്ലൈനുകളിൽ—ഏജന്റ് സ്വാര്മുകൾ (agent swarms), സമാന്തര ഡാറ്റാ ക്ലീനിംഗ് വർക്കർമാർ, അല്ലെങ്കിൽ പല ബോർട്ടുകൾ ഒരു പ്ലാൻ ഫയലോ സ്ക്രാച്ച്പാഡോ പങ്കിടുന്നുണ്ടെങ്കിൽ—ഈ മറഞ്ഞിരിക്കുന്ന നഷ്ടങ്ങൾ വലിയൊരു സാമ്പത്തിക നഷ്ടമായി മാറാം. ഈ അപാകത ഡാറ്റാ ഇന്റഗ്രിറ്റിയെയും (data integrity) ബാധിക്കുന്നു: അപൂർണ്ണമായതോ പഴയതോ ആയ വിവരങ്ങൾ ഉപയോഗിച്ച് അടുത്ത ഘട്ടങ്ങൾ പ്രവർത്തിക്കുന്നത് വലിയ പിഴവുകൾക്ക് കാരണമായേക്കാം.
ഈ അപാകത എങ്ങനെ സംഭവിക്കുന്നു
ഇതിന്റെ മൂലകാരണം ഒരു race condition ആണ്:
- രണ്ട് (അല്ലെങ്കിൽ അതിലധികം) ഏജന്റുകൾ ഒരു റിസോഴ്സിന്റെ (ഉദാഹരണത്തിന് ഒരു JSON പ്ലാൻ ഫയൽ) ഒരേ വേർഷൻ വായിക്കുന്നു.
- ഓരോ ഏജന്റും ആ വിവരത്തിന്റെ അടിസ്ഥാനത്തിൽ സ്വന്തം പ്രക്രിയകളോ മാറ്റങ്ങളോ നടത്തുന്നു.
- രണ്ട് ഏജന്റുകളും പങ്കിട്ട സ്റ്റോറേജിലേക്ക് (shared storage) വിവരങ്ങൾ എഴുതാൻ ശ്രമിക്കുന്നു.
- സ്റ്റോറേജ് സിസ്റ്റം രണ്ടാമത്തെ എഴുത്ത് സ്വീകരിക്കുകയും, ആദ്യത്തെ എഴുത്തിനെ യാതൊരു തടസ്സവും കൂടാതെ മാറ്റിസ്ഥാപിക്കുകയും ചെയ്യുന്നു.
- ആദ്യത്തെ മാറ്റം നഷ്ടപ്പെട്ടുവെങ്കിലും, എഴുത്ത് വിജയകരമായി പൂർത്തിയായി എന്ന് അറിയിച്ചുകൊണ്ട് രണ്ട് ഏജന്റുകൾക്കും “ACK” ലഭിക്കുന്നു.
സ്റ്റോറേജ് സിസ്റ്റത്തിന്റെ സ്ഥിരീകരണം (acknowledgment) ഒരു എഴുത്ത് നടന്നുവെന്ന് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ; മറ്റ് മാറ്റങ്ങളുമായി താരതമ്യം ചെയ്യുമ്പോൾ ആ എഴുത്ത് സുരക്ഷിതമാണെന്ന് അത് ഉറപ്പുനൽകുന്നില്ല. പലപ്പോഴും സുരക്ഷാ മാർഗമായി പറയപ്പെടുന്ന append-only log-ഉം ഇതേ രീതിയിലാണ് പ്രവർത്തിക്കുന്നത്: ഒരു എഴുത്ത് നടന്നുവെന്ന് അത് രേഖപ്പെടുത്തുമെങ്കിലും, പിന്നീട് വരുന്ന എഴുത്തുകൾ മുൻപത്തെ വിവരങ്ങളെ മായ്ച്ചുകളയുന്നത് തടയാൻ അതിന് കഴിയില്ല.
എന്താണ് ഒരു compare-and-set gate ചെയ്യുന്നത്
ഒരു compare-and-set (CAS) ഗേറ്റ്, എഴുത്ത് സ്വീകരിക്കുന്നതിന് മുമ്പ് ഒരു വേർഷൻ പരിശോധന കൂടി നടത്തുന്നു:
- Read: ഏജന്റ് ഫയലിന്റെ നിലവിലെ വേർഷൻ നമ്പറോ (അല്ലെങ്കിൽ hash) എടുക്കുന്നു.
- Compute: ഏജന്റ് അതിന്റെ ജോലി പൂർത്തിയാക്കി ഫയലിന്റെ പുതിയ വേർഷൻ നിർമ്മിക്കുന്നു.
- Write: ഏജന്റ് താൻ ആദ്യം വായിച്ച വേർഷനും പുതിയ ഉള്ളടക്കവും ഒരുമിച്ച് അയക്കുന്നു.
- Validate: സ്റ്റോറേജ് ലെയർ നൽകപ്പെട്ട വേർഷനെ നിലവിലെ വേർഷനുമായി താരതമ്യം ചെയ്യുന്നു. അവ തമ്മിൽ വ്യത്യാസമുണ്ടെങ്കിൽ എഴുത്ത് നിരസിക്കപ്പെടും; വ്യത്യാസമില്ലെങ്കിൽ അത് സ്വീകരിക്കുകയും വേർഷൻ വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു.
വേർഷനിൽ മാറ്റം വന്നിട്ടുണ്ടെങ്കിൽ, താൻ ഉപയോഗിച്ച വിവരങ്ങൾ പഴയതാണെന്ന് ഏജന്റിന് മനസ്സിലാകും. അപ്പോൾ ഏജന്റ് പുതിയ വേർഷൻ ഉപയോഗിച്ച് വീണ്ടും—read, compute, write—എന്ന പ്രക്രിയ ആവർത്തിക്കണം. ഇത് കാണാൻ കഴിയാത്ത രീതിയിലുള്ള ഓവർറൈറ്റിനെ, ലോഗ് ചെയ്യാനും വീണ്ടും ശ്രമിക്കാനും സാധിക്കുന്ന ഒരു വ്യക്തമായ പരാജയമായി മാറ്റുന്നു.
സുരക്ഷയ്ക്കുള്ള വില
CAS ഗേറ്റ് സൗജന്യമല്ല. അഞ്ച് ഏജന്റുകൾ ഉപയോഗിച്ചുള്ള അതേ പരീക്ഷണത്തിൽ:
| Scenario | Writes attempted | Successful contributions | Token cost |
|---|---|---|---|
| No CAS gate | 5 | 1 | 5 units |
| With CAS gate | 5 | 5 (after retries) | 9 units |
വേർഷൻ തർക്കങ്ങൾ (version conflict) നേരിടുന്ന ഏജന്റുകൾക്ക് അധികമായി read-compute-write സൈക്കിളുകൾ ആവശ്യമായി വരുന്നതിനാൽ ടോക്കൺ ചിലവ് വർദ്ധിക്കുന്നു. ഇതിലെ ഗുണദോഷം വ്യക്തമാണ്: ഗേറ്റ് ഇല്ലെങ്കിൽ ഡാറ്റ നിശബ്ദമായി നഷ്ടപ്പെടും; ഗേറ്റ് ഉണ്ടെങ്കിൽ ചെറിയൊരു അധിക ചിലവ് ഉണ്ടായേക്കാം, എന്നാൽ ഓരോ തർക്കത്തെക്കുറിച്ചും നിങ്ങൾക്ക് വ്യക്തമായ അറിവ് ലഭിക്കും.
ഈ പരാജയം എത്രത്തോളം സാധാരണമാണ്?
വെറും രണ്ട് ഏജന്റുകൾ ഉപയോഗിച്ചപ്പോൾ പോലും, എഴുത്തുകളിൽ ഒന്ന് നഷ്ടപ്പെടാൻ 75% സാധ്യതയുണ്ടെന്ന് പരീക്ഷണം കാണിച്ചു. അഞ്ച് ഏജന്റുകൾ ഉപയോഗിച്ചപ്പോൾ നഷ്ടം 100%-ന് അടുത്തായി. പ്രൊഡക്ഷൻ നിലവാരത്തിലുള്ള മൾട്ടി-ഏജന്റ് വർക്ക്ഫ്ലോകളിൽ “സാധാരണയായി കുഴപ്പമില്ല” എന്ന് കരുതുന്നത് അപകടകരമാണെന്ന് ഈ കണക്കുകൾ സൂചിപ്പിക്കുന്നു.
എതിർവാദം: എപ്പോഴാണ് ഗേറ്റ് ഒഴിവാക്കേണ്ടത്
ഒരു സിസ്റ്റത്തിൽ ഓരോ റിസോഴ്സിനും ഒരു ഏജന്റ് മാത്രമാണ് പ്രവർത്തിക്കുന്നതെങ്കിൽ അല്ലെങ്കിൽ ഉയർന്ന തലത്തിൽ കർശനമായ സീരിയലൈസേഷൻ (serialization) ഉണ്ടെങ്കിൽ, അധികമായ CAS പരിശോധനകൾ ആവശ്യമില്ലായേക്കാം. എന്നിരുന്നാലും, പരാജയപ്പെട്ട ജോലി വീണ്ടും ചെയ്യേണ്ടി വരുന്നതിലെ മറഞ്ഞിരിക്കുന്ന ചിലവും, ഡാറ്റ നഷ്ടപ്പെട്ടാൽ ഉണ്ടാകാൻ സാധ്യതയുള്ള പ്രത്യാഘാതങ്ങളും കണക്കിലെടുത്ത് വേണം റിസ്ക് വിലയിരുത്താൻ.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
- Tooling support: വേർഷൻ നമ്പറുകളോ ETags-ഓ നൽകുന്നതും, നേരിട്ട് CAS ഓപ്പറേഷനുകൾ ലഭ്യമാക്കുന്നതുമായ സ്റ്റോറേജ് API-കൾ ഉപയോഗിക്കുക.
- Metrics: വേർഷൻ വ്യത്യാസം കാരണം എത്ര തവണ എഴുത്തുകൾ നിരസിക്കപ്പെടുന്നു എന്ന് രേഖപ്പെടുത്താൻ ഏജന്റുകളെ സജ്ജമാക്കുക. തർക്കങ്ങളുടെ നിരക്ക് കൂടുന്നത് റിസോഴ്സുകൾ വർദ്ധിപ്പിക്കേണ്ടതിനോ വർക്ക്ഫ്ലോ പുനർരൂപകൽപ്പന ചെയ്യേണ്ടതിനോ ഉള്ള സൂചനയാണ്.
- Retry strategies: സിമ്പിൾ എക്സ്പോണൻഷ്യൽ ബാക്ക്-ഓഫ് (exponential back-off) രീതികൾ നന്നായി പ്രവർത്തിക്കും, എന്നാൽ ആവർത്തിച്ചുള്ള ശ്രമങ്ങൾ ടോക്കൺ ഉപയോഗം വർദ്ധിപ്പിക്കുമെന്ന് ഓർക്കുക. ഡാറ്റ നഷ്ടപ്പെടുന്നത് ഒഴിവാക്കുന്നതിനും ടോക്കൺ ചിലവ് നിയന്ത്രിക്കുന്നതിനും ഇടയിലുള്ള ഒരു സന്തുലിതാവസ്ഥ നിലനിർത്തുക.
- Hybrid approaches: ചില ടീമുകൾ ഓഡിറ്റിംഗിനായി append-only log-ഉം, ഡാറ്റാ സ്ഥിരതയ്ക്കായി (consistency) CAS ഗേറ്റും സംയോജിപ്പിക്കുന്നു. ഇത് നടന്ന കാര്യങ്ങളുടെ റെക്കോർഡും ഒപ്പം ഓവർറൈറ്റുകൾക്കെതിരെയുള്ള സംരക്ഷണവും ഉറപ്പാക്കുന്നു.
ചുരുക്കത്തിൽ
ലോസ്റ്റ്-അപ്ഡേറ്റ് അനോമലിസുകൾ (Lost-update anomalies) ടോക്കൺ അധിഷ്ഠിത AI പൈപ്പ്ലൈനുകളെ പണം നഷ്ടപ്പെടുത്തുന്ന ബ്ലാക്ക് ഹോളുകളാക്കി മാറ്റുന്നു. ഒരു 'കംപെയർ-ആൻഡ്-സെറ്റ്' (compare-and-set) വേർഷൻ ഗേറ്റ് ചെറിയ തോതിലുള്ള ടോക്കൺ അധികച്ചെലവ് ഉണ്ടാക്കുമെങ്കിലും, നിശബ്ദമായ ഡാറ്റാ നഷ്ടത്തെ ദൃശ്യമായതും വീണ്ടും ശ്രമിക്കാവുന്നതുമായ (retryable) ഒരു സംഭവമാക്കി മാറ്റുന്നു. ഒന്നിലധികം ഏജന്റുകൾ സ്റ്റേറ്റ് പങ്കിടുന്ന ഏതൊരു സിസ്റ്റത്തിലും—ഡാറ്റാബേസുകൾ, പ്ലാൻ ഫയലുകൾ, അല്ലെങ്കിൽ സ്ക്രാച്ച്പാഡുകൾ എന്നിവയിൽ—ഡാറ്റ എഴുതുന്നതിന് മുമ്പ് ഒരു വേർഷൻ ചെക്ക് ഉൾപ്പെടുത്തുന്നത്, മറഞ്ഞിരിക്കുന്ന ചെലവുകൾക്കും തകരാറിലായ വർക്ക്ഫ്ലോകൾക്കും എതിരെയുള്ള ഏറ്റവും കുറഞ്ഞ ചെലവിലുള്ള ഇൻഷുറൻസ് ആണ്.