வாரக்கணக்கில் அமைதியாகத் தரவு இழப்பு ஏற்பட்ட பிறகு, LangGraph ஏஜென்ட்கள் (agents) தங்கள் நிலையை (state) பராமரிக்க இறுதியாக ஒரு நம்பகமான வழியைக் கண்டறிந்துள்ளன. SQLite, நேரடி ஆப்ஜெக்ட் ஸ்டோரேஜ் (object storage) மற்றும் அவற்றின் தோல்வியுற்ற பதிப்புகள் என மூன்று தோல்வியுற்ற செக்பாயிண்டிங் (checkpointing) முறைகளுக்குப் பிறகு, ஒவ்வொரு முறை கோரிக்கை வரும்போதும் ஏஜென்ட்கள் மீண்டும் ஆரம்பத்திலிருந்து தொடங்குவதைத் தடுக்கும் ஒரு அணுக்கரு-புதுப்பித்தல் (atomic-update) முறையை ஆசிரியர் கண்டறிந்துள்ளார்.
LangGraph-க்கு செக்பாயிண்டிங் ஏன் முக்கியமானது?
LangGraph டெவலப்பர்கள் LLM அழைப்புகளை மீண்டும் பயன்படுத்தக்கூடிய "ஏஜென்ட்களாக" (agents) இணைக்க அனுமதிக்கிறது, இவை உரையாடலில் முன்னரே நடந்தவற்றை நினைவில் கொள்ளும் திறன் கொண்டவை. அந்த ஏஜென்ட்கள் பயனர் கோரிக்கையை துணைப் பணிகளாகப் பிரித்து, இடைநிலை முடிவுகளைச் சேமித்து, அடுத்த அழைப்பின் போது விட்ட இடத்திலிருந்து தொடர்கின்றன. சேமிக்கப்பட்ட நிலை (state) மறைந்துவிட்டால், ஏஜென்ட் அனைத்தையும் மீண்டும் கணக்கிடுகிறது, இது கணினித் திறனை (compute) வீணாக்குகிறது, தாமதத்தை (latency) அதிகரிக்கிறது மற்றும் மோசமான பயனர் அனுபவத்தை அளிக்கிறது. டெலிகிராம் செய்திகளைக் கையாளும் ஒரு தயாரிப்பு நிலையில் உள்ள (production) பாட்டில், இந்த இழப்பு வாரக்கணக்கிலான உரையாடல் வரலாற்றையே அழித்துவிட்டது.
முதல் தீர்வு: SQLite saver
ஒரு ஒற்றை இன்ஸ்டன்ஸ் (instance) ஏஜென்ட்டை இயக்கும்போது உள்ளமைக்கப்பட்ட SqliteSaver நன்றாகச் செயல்படுகிறது. இது ஒவ்வொரு செக்பாயிண்டையும் ஒரு உள்ளூர் SQLite கோப்பில் JSON பிளாப் (blob) ஆக எழுதுகிறது. டெவலப்பர் AgentState வகைக்கு (type) ஒரு புதிய புலத்தைச் (field) சேர்த்து மீண்டும் வரிசைப்படுத்தியபோது (redeploy) சிக்கல் தொடங்கியது. ஸ்கீமா (schema) மாற்றத்திற்கு முன் உருவாக்கப்பட்ட ஏற்கனவே உள்ள செக்பாயிண்டுகளில் புதிய புலம் இல்லை. SqliteSaver ஒருபோதும் மைக்ரேஷனை (migration) செய்யாததால், LangGraph முழுமையற்ற JSON-ஐ ஏற்றியது, விடுபட்ட தரவை நீக்கியது, மேலும் ஏஜென்ட் ஆரம்பத்திலிருந்து மீண்டும் தொடங்கியது.
முக்கிய புள்ளி: ஸ்கீமா பரிணாம வளர்ச்சி (schema evolution) தேவைப்படும்போது, SQLite சேமிப்பு என்பது ஒரு டெமோ கருவியே தவிர, தயாரிப்பு நிலைக்குத் தயாரான தீர்வு அல்ல.
இரண்டாவது தீர்வு: Object storage
சீரியலைசேஷன் (serialization) வடிவத்தின் மீது கட்டுப்பாட்டைப் பெற, ஆசிரியர் JSON செக்பாயிண்ட்டை Oracle Cloud Object Storage-க்கு பதிவேற்றும் ஒரு தனிப்பயன் சேவரை (custom saver) எழுதினார். இந்த நடவடிக்கை ஸ்கீமாவை கைமுறையாக பதிப்புப்படுத்த (version) நெகிழ்வுத்தன்மையைக் கொடுத்தது, ஆனால் இது ஒரு புதிய தோல்வி முறையை அறிமுகப்படுத்தியது. இரண்டு கோரிக்கைகள் ஒரே நேரத்தில் ஒரே உரையாடல் திரெட்டில் (conversation thread) மோதும்போது, இரண்டும் ஒரே ஆப்ஜெக்ட்டை மேலெழுத (overwrite) முயன்றன. ஆப்ஜெக்ட் ஸ்டோரேஜ் சேவைகள் 'ஒருமுறை எழுதுதல், பலமுறை படித்தல்' (write-once, read-many) முறைகளுக்கு உகந்தவை; அவை அணுக்கரு மேலெழுதும் (atomic overwrite) தன்மையைக் கொண்டிருக்கவில்லை. இந்த ரேஸ் கண்டிஷன் (race condition) சிதைந்த அல்லது முழுமையற்ற JSON கோப்புகளை உருவாக்கியது, மேலும் ஏஜென்ட் மீண்டும் அதன் சூழலை (context) இழந்தது.
முக்கிய புள்ளி: பல பணியாளர்கள் (workers) ஒரே நேரத்தில் ஒரே சாவியை (key) அணுக முடியும் போது, ஆப்ஜெக்ட் ஸ்டோரேஜில் சாதாரண மேலெழுதல்கள் பாதுகாப்பானவை அல்ல.
மூன்றாவது தீர்வு: பதிப்புப்படுத்துதலுடன் கூடிய அணுக்கரு புதுப்பிப்புகள் (Atomic updates with versioning)
இறுதி, நிலையான வடிவமைப்பு இரண்டு யோசனைகளை இணைக்கிறது: தெளிவான பதிப்பு எண்கள் மற்றும் ஆப்ஜெக்ட்டின் ETag (சேமிப்பு சேவையின் செக்சம் அடையாளங்காட்டி) அடிப்படையிலான நிபந்தனை எழுதுதல்கள் (conditional writes).
- தற்போதைய செக்பாயிண்ட்டை வாசிக்கவும் (Read) மற்றும் அதன் ETag-ஐப் பெறவும்.
- செக்பாயிண்ட் என்வலோப்பிற்குள் (envelope) உள்ள ஒரு பதிப்பு புலத்தை (version field) அதிகரிக்கவும் (Increment).
- முன்பு வாசிக்கப்பட்ட ETag-உடன் இது ஒத்துப்போனால் மட்டுமே வெற்றிபெறும் ஒரு நிபந்தனை கோரிக்கையைப் (conditional request) பயன்படுத்தி புதுப்பிக்கப்பட்ட செக்பாயிண்ட்டை எழுதவும் (Write).
- மற்றொரு செயல்முறை ஆப்ஜெக்ட்டை மாற்றியதால் நிபந்தனை எழுதுதல் தோல்வியடைந்தால், முழு வாசிப்பு-அதிகரிப்பு-எழுதுதல் (read-increment-write) சுழற்சியையும் மீண்டும் முயற்சிக்கவும் (Retry).
வேறு எந்தச் செயல்முறையும் கோப்பை மாற்றாதபோது மட்டுமே எழுதுதல் வெற்றி பெறுவதால், ஒரே நேரத்தில் ஒரு பணியாளரால் மட்டுமே புதிய நிலையை உறுதிப்படுத்த (commit) முடியும். பதிப்புப் புலம் (version field) பழைய செக்பாயிண்ட்டுகளைக் கண்டறியவும், ஸ்கீமா மாறும்போது அவற்றை முன்னோக்கி மாற்றவும் (migrate) எளிதாக்குகிறது.
இந்த முறை ETag-அடிப்படையிலான நிபந்தனை எழுதுதல்களை ஆதரிக்கும் ஆப்ஜெக்ட் ஸ்டோரேஜில் செயல்படும்.
AI பொறியாளர்களுக்கான பாடங்கள்
- SQLite-ஐ புரோட்டோடைப்களுக்கு (prototypes) மட்டுமே பயன்படுத்தவும். தயாரிப்பு ஏஜென்ட்களுக்கு ஸ்கீமா மாற்றங்கள் மற்றும் ஒரே நேரத்தில் நடக்கும் எழுதுதல்களை (concurrent writes) கையாளக்கூடிய ஒரு சேமிப்பகம் தேவை.
- ஸ்கீமா மைக்ரேஷன்களை நீங்களே திட்டமிடுங்கள். Typed dictionaries நிலையான பகுப்பாய்விற்கான (static analysis) வடிவங்களை விவரிக்கின்றன, ஆனால் ரன்டைம் கட்டமைப்பை (runtime structure) கட்டாயமாக்கவில்லை.
- நிலையை (state) ஒரு பகிரப்பட்ட வளமாக (shared resource) கருதுங்கள். Concurrency பிழைகள் அமைதியான தரவு இழப்பாகத் தோன்றும்; அவை நேரடி விதிவிலக்குகளை (exceptions) விடக் கண்டறிவதற்கு (debug) கடினமானவை.
- கிளவுட் பிரிமிட்டிவ்களைப் (cloud primitives) பயன்படுத்தவும். ETag-அடிப்படையிலான நிபந்தனை எழுதுதல்கள், தனிப்பயன் லாக் சேவை (lock service) இல்லாமலேயே மலிவான ஆப்டிமிஸ்டிக் லாக்கிங்கை (optimistic locking) வழங்குகின்றன.
- ஒவ்வொரு படிநிலையையும் பதிவு செய்யவும் (Log). LangGraph புறக்கணிக்கும் விடுபட்ட புலம் போன்ற அமைதியான தோல்விகளைக் கண்டறிவது மிகவும் கடினம்.
LangGraph செக்பாயிண்டிங்கிற்கு அடுத்து என்ன?
ஏற்கனவே இதே போன்ற தடைகளை எதிர்கொண்ட குழுக்களுக்கு, இந்த அணுக்கரு-புதுப்பித்தல் முறை ஒரு விரைவான, குறைந்த செலவிலான தீர்வை வழங்குகிறது. ஒரு நம்பகமான தயாரிப்பு குழாய்முறைக்கு (production pipeline) ஒரு கனமான நிலை சேமிப்பகம் தேவையில்லை—ஒரே நேரத்தில் நடக்கும் செயல்பாடுகள் (concurrency) மற்றும் பதிப்புப்படுத்துதல் ஆகியவற்றின் கவனமான கையாளுதல் மட்டுமே போதுமானது என்பதை இது காட்டுகிறது.
சுருக்கம்: ஒரு எளிய பதிப்புப்படுத்தப்பட்ட என்வலப்பும் (versioned envelope) நிபந்தனை எழுதுதல்களும் ஒரு நிலையற்ற அமைப்பை நம்பகமான ஒன்றாக மாற்றுகின்றன, இது AI பொறியாளர்கள் முடிவற்ற தரவு இழப்பு பிழைத்திருத்தத்திற்குப் பதிலாக ஏஜென்ட் லாஜிக்கில் கவனம் செலுத்த அனுமதிக்கிறது.