एजंट्ससाठी सुरक्षित डिलिव्हरी पाइपलाइन तयार करणे

बहुतेक एजंट डेमोमध्ये एक महत्त्वाचा प्रश्न सुटतो. एखादी स्वायत्त प्रणाली (autonomous system) तुमच्या वतीने गोष्टी पाठवताना, त्या पुन्हा पुन्हा पाठवल्या जाऊ नयेत किंवा अप्रमाणित काम पाठवले जाऊ नये यासाठी तुम्ही काय कराल?

'डबल-सेंड' (double-send) ही दुर्मिळ चूक नाही. जेव्हा एखादा वर्कर (worker) कामाच्या दरम्यान क्रॅश होतो, तेव्हा साध्या क्यू (queue) चे हे डीफॉल्ट वर्तन असते. एखादा वर्कर मेसेज पाठवतो आणि यश नोंदवण्यापूर्वीच क्रॅश होतो. सिस्टिमला वाटते की काम अयशस्वी झाले आहे आणि ती नवीन वर्करला पुन्हा प्रयत्न करण्यास सांगते. ग्राहकाला दोन ईमेल मिळतात आणि तुम्हाला सपोर्ट तिकीट मिळते.

तुम्ही प्रत्येक क्रॅश रोखू शकत नाही. कृती (action) आणि नोंद (record) यांच्यातील अंतरामध्ये क्रॅश झाल्यास काय होईल, याचा विचार करूनच तुम्हाला डिझाइन करावे लागेल.

वास्तविक परिणाम असलेल्या कोणत्याही एजंट आउटपुटसाठी ही सहा-टप्प्यांची पाइपलाइन वापरा:

• Produce (तयार करणे): एजंट संपूर्ण आर्टिफॅक्ट (artifact) तयार करतो. तो अजून काहीही पाठवत नाही. • Persist (साठवणे): प्रथम हेतू (intent) आणि आर्टिफॅक्ट टिकाऊ स्टोरेजमध्ये (durable storage) लिहा. • Score (स्कोअरिंग): आउटपुटला कॉन्फिडन्स स्कोअर जोडा. • Review (पुनरावलोकन): कमी कॉन्फिडन्स असलेले आयटम्स मानवी पुनरावलोकनासाठी पाठवा. • Approve (मंजुरी): 'फेल-क्लोज्ड गेट' (fail-closed gate) वापरा. जोपर्यंत एखादी व्यक्ती स्पष्ट परवानगी देत नाही, तोपर्यंत सिस्टिम सर्व पाठवणी रोखून धरते. • Send and Attest (पाठवणे आणि प्रमाणित करणे): लीज (lease) अंतर्गत आयटम पाठवा आणि त्यानंतर पुराव्याची पावती (evidence receipt) लिहा.

प्रत्येक टप्पा हा एक स्वतंत्र आणि टिकाऊ ट्रान्झिशन (durable transition) असला पाहिजे. स्टेट (state) तुमच्या डेटाबेसमध्ये असावी, वर्करच्या मेमरीमध्ये नाही.

डुप्लिकेट्स रोखण्यासाठी, रो-लेव्हल लीजिंग (row-level leasing) वापरा. Postgres मध्ये, SELECT ... FOR UPDATE SKIP LOCKED वापरा. यामुळे एका वेळी फक्त एकच वर्कर एखाद्या टास्कचा मालक असेल याची खात्री मिळते.

सर्वात महत्त्वाचा नियम म्हणजे तुम्ही एक्सपायर्ड लीजेस (expired leases) कशा हाताळता. जर एखादा वर्कर बाह्य मेसेज पाठवताना क्रॅश झाला, तर तो आपोआप पुन्हा प्रयत्न (retry) करू नका. त्याऐवजी, मानवी पुनरावलोकनासाठी तो टास्क तसाच सोडा. अदृश्य 'डबल-सेंड' पेक्षा समोर दिसणारा अडकलेला टास्क अधिक चांगला आहे.

तुम्हाला 'फेल-क्लोज्ड' (fail-closed) तत्त्वांचे देखील पालन करावे लागेल:

  • पाठवणे (Sending) डीफॉल्टनुसार बंद असते. सर्व आउटबाउंड ट्रॅफिक सुरू करण्यासाठी एका सिंगल फ्लॅगची आवश्यकता असावी.
  • ओळख (Identity) तपासली जाते. पाठवण्याच्या क्षणी सिस्टिमने पाठवणाऱ्याचा पत्ता आणि ट्रान्सपोर्ट सिक्युरिटीची पडताळणी करणे आवश्यक आहे.
  • प्रत्येक गोष्टीची पावती मिळते. नोंद न झालेली पाठवणी ही एक अपयशी प्रक्रिया आहे.

अंतर्गत लॉग्ससारख्या कमी जोखमीच्या कामांसाठी हे तयार करू नका. जेव्हा चुकीमुळे आर्थिक नुकसान होते, कायदेशीर समस्या निर्माण होते किंवा सपोर्ट तिकीट लागते, तेव्हाच याचा वापर करा.

Source: https://dev.to/danmercede/building-a-governed-double-send-safe-delivery-pipeline-for-agent-outputs-80e

Optional learning community: https://t.me/GyaanSetuAi