બ્લોક થવું એટલે નિષ્ફળતા નથી: એજન્ટ્સને બાઉન્ડરી ફીડબેકની જરૂર છે

મોટાભાગના એજન્ટ સેટઅપ્સ બ્લોક થયેલ ક્રિયાને ટૂલની નિષ્ફળતા તરીકે ગણે છે.

એક એજન્ટ ટૂલને કોલ કરે છે. વિનંતી (request) કોઈ નિયમ તોડે છે. સિસ્ટમ એક સામાન્ય ભૂલ (generic error) દર્શાવે છે. ટૂલ કોલ નિષ્ફળ જાય છે.

શરૂઆતમાં આ બરાબર લાગે છે. અસુરક્ષિત ક્રિયા અટકાવી દેવામાં આવી હતી. પરંતુ આ માત્ર અડધી સમસ્યાનો જ ઉકેલ લાવે છે.

એક સામાન્ય ભૂલ એજન્ટને તેની મર્યાદામાં કામ કરવામાં મદદ કરતી નથી. તે પોલિસીના નિર્ણયને માત્ર 'નોઈઝ' (noise) માં ફેરવી નાખે છે. એજન્ટ સુધારા માટે અનુમાન લગાવવાનો પ્રયાસ કરી શકે છે. તે તે જ ભૂલનું પુનરાવર્તન કરી શકે છે અથવા અલગ પેલોડ (payload) સાથે પ્રયાસ કરી શકે છે. આનાથી નકામા પ્રયાસોનું એક લૂપ (loop) સર્જાય છે.

બ્લોક થયેલ ક્રિયા એ એક વ્યવસ્થિત (structured) નિર્ણય હોવો જોઈએ, અણધારી ક્રેશ (crash) નહીં.

જ્યારે કોઈ વિનંતી બ્લોક કરવામાં આવે, ત્યારે બાહ્ય સિસ્ટમમાં ફેરફાર થવો જોઈએ નહીં. જોકે, પ્રતિસાદ (response) એ એજન્ટને જણાવવું જોઈએ કે સુરક્ષિત રીતે કેવી રીતે આગળ વધવું.

સાદી ભૂલને બદલે, વ્યવસ્થિત પ્રતિસાદનો ઉપયોગ કરો.

કલ્પના કરો કે એક એજન્ટ એવી ફાઇલમાં લખવાનો પ્રયાસ કરે છે જે તેના પ્લાનિંગ દરમિયાન બદલાઈ ગઈ હોય. એક સામાન્ય ભૂલ કહે છે "નિષ્ફળ" (failed). એક વ્યવસ્થિત પ્રતિસાદ કહે છે:

  • નિર્ણયની સ્થિતિ (Decision status): સંઘર્ષ (conflict)
  • પરિણામની સ્થિતિ (Outcome status): કોઈ અસર નથી (no impact)
  • કારણ (Reason): જૂની સ્થિતિ (stale state)
  • આગલી ક્રિયા (Next action): લક્ષ્ય સ્થિતિ ફરીથી વાંચો (re-read target state)

હવે એજન્ટ જાણે છે કે લક્ષ્ય અશક્ય નથી. તેણે ફક્ત તેની માહિતી અપડેટ કરવાની જરૂર છે. તે અનુમાન લગાવવાનું બંધ કરે છે અને સાચું આગલું પગલું લે છે.

આ ઘણા કિસ્સાઓમાં કામ કરે છે:

  • જો કોઈ પાથ સ્કોપની બહાર હોય, તો માન્ય પાથ સૂચવો.
  • જો કોઈ અસર પહેલેથી જ અસ્તિત્વમાં હોય, તો પરિણામનો ફરીથી ઉપયોગ કરવાનું સૂચવો.
  • જો અસર ખૂબ વધારે હોય, તો માનવ સમીક્ષા (human review) માટે રાહ જોવાનું સૂચવો.

આ કરવાથી બાઉન્ડરી નરમ બનતી નથી. ક્રિયા બ્લોક જ રહે છે. સિસ્ટમ સુરક્ષિત રહે છે. તમે ફક્ત એક બંધ રસ્તાને માર્ગદર્શિત રસ્તામાં ફેરવી રહ્યા છો.

તમારે આને સુરક્ષા સાથે સંતુલિત કરવું જોઈએ. ચોક્કસ ફીડબેક એક ખરાબ એજન્ટને તમારી મર્યાદાઓ તપાસવામાં મદદ કરી શકે છે.

જૂના ડેટા અથવા ખોટા ઇનપુટ્સ જેવા ઓપરેશનલ ઘર્ષણ માટે સ્પષ્ટ રીઝન કોડ્સ (reason codes) નો ઉપયોગ કરો. જો એજન્ટ શંકાસ્પદ વર્તન બતાવે અથવા સંકેતોને અવગણે, તો સામાન્ય અસ્વીકાર (generic rejections) અથવા માનવ સમીક્ષા પર સ્વિચ કરો.

એજન્ટ ફીડબેકને ઓડિટ સ્કોર્સથી અલગ રાખો. એજન્ટને જાણવાની જરૂર છે કે નિયમોનું પાલન (compliant) કેવી રીતે કરવું. સિસ્ટમને જાણવાની જરૂર છે કે એજન્ટ ખરાબ રીતે વર્તી રહ્યો છે કે નહીં. આ બંને કામોને મિક્સ ન કરો.

બાઉન્ડરીઓ એટલા માટે અસ્તિત્વ ધરાવે છે કારણ કે એજન્ટ્સ વાસ્તવિક સિસ્ટમ્સ પર કામ કરવા માટે પૂરતા ઉપયોગી બની રહ્યા છે. વાસ્તવિક કામમાં નિયમો અને મર્યાદાઓ હોય છે.

જે બાઉન્ડરી માત્ર નિષ્ફળતા દર્શાવે છે તે એક દીવાલ છે. જે બાઉન્ડરી માર્ગદર્શન પૂરું પાડે છે તે એક સાધન (tool) છે.

Blocked નો અર્થ આ હોવો જોઈએ:

  • જે પ્રભાવની અપેક્ષા હતી તે થયો નથી.
  • કારણ જાણીતું છે.
  • આગામી સુરક્ષિત પગલું સ્પષ્ટ છે.

સ્ત્રોત: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg

વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi