અઠવાડિયાઓના મૌન ડેટા લોસ (data loss) પછી, LangGraph એજન્ટ્સને તેમનો સ્ટેટ (state) જાળવી રાખવા માટે આખરે એક ભરોસાપાત્ર રીત મળી ગઈ છે. ત્રણ નિષ્ફળ ચેકપોઇન્ટિંગ ટ્રિક્સ—SQLite, રો ઓબ્જેક્ટ સ્ટોરેજ, અને તે બંનેના ખામીયુક્ત વર્ઝન—ત્યારબાદ લેખક એક એટોમિક-અપડેટ પેટર્ન (atomic-update pattern) પર પહોંચ્યા, જે એજન્ટ્સને દરેક વિનંતી (request) આવે ત્યારે ફરીથી શરૂઆતથી શરૂ થતા અટકાવે છે.
LangGraph માટે ચેકપોઇન્ટિંગ શા માટે મહત્વનું છે
LangGraph ડેવલપર્સને LLM કોલ્સને ફરીથી ઉપયોગ કરી શકાય તેવા “એજન્ટ્સ” (agents) માં જોડવાની સુવિધા આપે છે, જે વાતચીતમાં અગાઉ શું થયું હતું તે યાદ રાખી શકે છે. તે એજન્ટ્સ યુઝરની વિનંતીને સબ-ટાસ્કમાં વિભાજિત કરે છે, મધ્યવર્તી પરિણામો (intermediate results) સંગ્રહિત કરે છે, અને આગામી કોલ પર જ્યાંથી છોડ્યું હતું ત્યાંથી જ ફરી શરૂ કરે છે. જો સંગ્રહિત સ્ટેટ (state) ગુમ થઈ જાય, તો એજન્ટ બધું ફરીથી ગણતરી કરે છે, જેનાથી કમ્પ્યુટિંગ પાવરનો બગાડ થાય છે, લેટન્સી (latency) વધે છે અને યુઝર એક્સપિરિયન્સ ખરાબ થાય છે. ટેલિગ્રામ મેસેજ હેન્ડલ કરતા એક પ્રોડક્શન બોટમાં, આ ડેટા લોસને કારણે અઠવાડિયાનો વાતચીતનો ઇતિહાસ ભૂંસાઈ ગયો હતો.
પહેલો ઉકેલ: SQLite saver
જ્યારે કોઈ સિંગલ ઇન્સ્ટન્સ એજન્ટ ચલાવે છે ત્યારે ઇન-બિલ્ટ SqliteSaver બરાબર કામ કરે છે. તે દરેક ચેકપોઇન્ટને લોકલ SQLite ફાઇલમાં JSON બ્લોબ તરીકે લખે છે. મુશ્કેલી ત્યારે શરૂ થઈ જ્યારે ડેવલપરે AgentState પ્રકારમાં નવું ફીલ્ડ ઉમેર્યું અને તેને ફરીથી ડિપ્લોય (redeploy) કર્યું. સ્કીમા ફેરફાર પહેલાં બનાવેલા હાલના ચેકપોઇન્ટ્સમાં નવું ફીલ્ડ નહોતું. કારણ કે SqliteSaver ક્યારેય માઈગ્રેશન (migration) ચલાવતું નથી, તેથી LangGraph અપૂર્ણ JSON લોડ કરે છે, ખૂટતો ડેટા કાઢી નાખે છે, અને એજન્ટ ફરીથી શરૂઆતથી શરૂ થાય છે.
મુખ્ય મુદ્દો: જ્યારે સ્કીમા ઇવોલ્યુશન (schema evolution) જરૂરી હોય, ત્યારે SQLite સ્ટોરેજ એ માત્ર ડેમો ટૂલ છે, પ્રોડક્શન માટે તૈયાર ઉકેલ નથી.
બીજો ઉકેલ: Object storage
સિરિયલાઈઝેશન ફોર્મેટ (serialization format) પર નિયંત્રણ મેળવવા માટે, લેખકે એક કસ્ટમ સેવર લખ્યું જે JSON ચેકપોઇન્ટને Oracle Cloud Object Storage પર અપલોડ કરે છે. આ પગલાથી સ્કીમાને મેન્યુઅલી વર્ઝન કરવાની સુવિધા મળી, પરંતુ તેનાથી એક નવો નિષ્ફળતાનો પ્રકાર (failure mode) ઊભો થયો. જ્યારે બે વિનંતીઓ એકસાથે એક જ કન્વર્સેશન થ્રેડ પર આવે છે, ત્યારે બંને એક જ ઓબ્જેક્ટને ઓવરરાઈટ (overwrite) કરવાનો પ્રયાસ કરે છે. ઓબ્જેક્ટ સ્ટોરેજ સેવાઓ 'write-once, read-many' પેટર્ન માટે ઓપ્ટિમાઇઝ્ડ હોય છે; તેઓ એટોમિક ઓવરરાઈટ સેમેન્ટિક્સ (atomic overwrite semantics) પ્રદાન કરતી નથી. રેસ કન્ડિશન (race condition) ને કારણે ખોટી રીતે બનેલી અથવા અધૂરી JSON ફાઇલો બની, અને એજન્ટ ફરીથી તેનો કોન્ટેક્સ્ટ (context) ગુમાવી બેઠો.
મુખ્ય મુદ્દો: જ્યારે મલ્ટિપલ વર્કર્સ એક જ સમયે એક જ કી (key) ને સ્પર્શી શકે છે, ત્યારે ઓબ્જેક્ટ સ્ટોરેજમાં સાદા ઓવરરાઈટ સુરક્ષિત નથી.
ત્રીજો ઉકેલ: વર્ઝનિંગ સાથે એટોમિક અપડેટ્સ
અંતિમ અને સ્થિર ડિઝાઇન બે વિચારોનું મિશ્રણ છે: સ્પષ્ટ વર્ઝન નંબર અને ઓબ્જેક્ટના ETag (સ્ટોરેજ સર્વિસનું ચેકસમ આઈડેન્ટિફાયર) પર આધારિત કન્ડીશનલ રાઈટ્સ (conditional writes).
- વર્તમાન ચેકપોઇન્ટને વાંચો (Read) અને તેનો ETag મેળવો.
- ચેકપોઇન્ટ એન્વલપની અંદર વર્ઝન ફીલ્ડને વધારો (Increment).
- અપડેટ કરેલા ચેકપોઇન્ટને કન્ડીશનલ રિક્વેસ્ટનો ઉપયોગ કરીને લખો (Write), જે ત્યારે જ સફળ થાય જો ETag અગાઉ વાંચેલા ETag સાથે મેચ થાય.
- જો કન્ડીશનલ રાઈટ નિષ્ફળ જાય કારણ કે અન્ય કોઈ પ્રોસેસે ઓબ્જેક્ટ બદલી નાખ્યો છે, તો આખા read-increment-write લૂપને ફરીથી પ્રયાસ (Retry) કરો.
કારણ કે રાઈટ ત્યારે જ સફળ થાય છે જ્યારે અન્ય કોઈ પ્રોસેસે ફાઇલ સાથે છેડછાડ ન કરી હોય, તેથી એક સમયે માત્ર એક જ વર્કર નવો સ્ટેટ કમિટ કરી શકે છે. વર્ઝન ફીલ્ડ જૂના (stale) ચેકપોઇન્ટ્સને શોધવા અને સ્કીમા બદલાય ત્યારે તેને આગળ માઈગ્રેટ કરવા માટે પણ સરળ બનાવે છે.
આ પેટર્ન એવા ઓબ્જેક્ટ સ્ટોરેજ સાથે કામ કરે છે જે ETag-આધારિત કન્ડીશનલ રાઈટ્સને સપોર્ટ કરે છે.
AI એન્જિનિયર્સ માટે પાઠ
- SQLite નો ઉપયોગ ફક્ત પ્રોટોટાઇપ્સ માટે જ કરો. પ્રોડક્શન એજન્ટ્સને એવા સ્ટોરની જરૂર છે જે સ્કીમા ફેરફારો અને કન્કરન્ટ રાઈટ્સ (concurrent writes) હેન્ડલ કરી શકે.
- સ્કીમા માઈગ્રેશનનું આયોજન જાતે કરો. ટાઇપ્ડ ડિક્શનરીઝ (Typed dictionaries) સ્ટેટિક એનાલિસિસ માટે આકારનું વર્ણન કરે છે પરંતુ રનટાઇમ સ્ટ્રક્ચરને લાગુ પડતી નથી.
- સ્ટેટને શેર કરેલા રિસોર્સ તરીકે ગણો. કન્કરન્સી બગ્સ (Concurrency bugs) મૌન ડેટા લોસ તરીકે દેખાય છે; તેઓ સીધા એક્સેપ્શન (exceptions) કરતા ડિબગ કરવામાં વધુ મુશ્કેલ હોય છે.
- ક્લાઉડ પ્રિમીટિવ્સ (cloud primitives) નો ઉપયોગ કરો. ETag-આધારિત કન્ડીશનલ રાઈટ્સ અલગ લોક સર્વિસ વગર સસ્તું ઓપ્ટિમિસ્ટિક લોકિંગ (optimistic locking) આપે છે.
- દરેક સ્ટેપ લોગ કરો. મૌન નિષ્ફળતાઓ—જેમ કે ખૂટતું ફીલ્ડ જેને LangGraph અવગણે છે—તેને શોધવી સૌથી મુશ્કેલ છે.
LangGraph ચેકપોઇન્ટિંગ માટે આગળ શું?
જે ટીમોએ પહેલેથી જ આ જ અવરોધોનો સામનો કર્યો છે, તેમના માટે એટોમિક-અપડેટ રેસીપી એક ઝડપી અને ઓછા ખર્ચાળ ઉકેલ આપે છે. તે દર્શાવે છે કે એક વિશ્વસનીય પ્રોડક્શન પાઇપલાઇન માટે હેવીવેઇટ સ્ટેટ સ્ટોરની જરૂર નથી—માત્ર કન્કરન્સી અને વર્ઝનિંગનું સાવચેતીપૂર્વક સંચાલન જરૂરી છે.
સારાંશ: એક સાદું વર્ઝન કરેલું એન્વલપ અને કન્ડીશનલ રાઈટ્સ એક અસ્થિર સિસ્ટમને વિશ્વસનીય બનાવે છે, જેનાથી AI એન્જિનિયર્સ ડેટા લોસના અનંત ડિબગિંગને બદલે એજન્ટ લોજિક પર ધ્યાન કેન્દ્રિત કરી શકે છે.