તમારું એજન્ટ ડેમો કામ કરે છે. એ જ એક જાળ છે.
હું કંપનીઓ માટે AI એજન્ટ્સ બનાવું છું. હું વારંવાર એક જ પ્રકારની પેટર્ન જોઉં છું. મોડેલ ડેમોમાં કામ કરે છે. તમે પ્રોડક્ટ લોન્ચ કરો છો. પછી પ્રોડક્શનમાં તે દર ત્રણમાંથી એક વાર નિષ્ફળ જાય છે. કોઈને ખબર નથી હોતી કે કેમ.
ડેમો અને પ્રોડક્શન વચ્ચેનું અંતર ગણિતનું છે. એકવાર તમે ગણિત સમજી લો, પછી તમે અલગ રીતે નિર્માણ કરશો.
જો તમારા એજન્ટનું દરેક સ્ટેપ 95% વિશ્વસનીય હોય, તો તે સારું લાગે છે. પરંતુ એજન્ટ્સ સ્ટેપ્સની ચેઈન (chains of steps) નો ઉપયોગ કરે છે. જો તમે દસ સ્ટેપ્સને એકસાથે જોડો છો, તો તમારી સફળતાનો દર ઘટીને 60% થઈ જાય છે. જો તમે વીસ સ્ટેપ્સનો ઉપયોગ કરો છો, તો તમારી સફળતાનો દર ઘટીને 36% થઈ જાય છે.
વાસ્તવિક કામમાં, સ્ટેપ્સમાં ઘણીવાર 10% થી 20% સુધીનો એરર રેટ (error rate) હોય છે. જો કોઈ એજન્ટમાં 85% વિશ્વસનીયતા સાથે આઠ સ્ટેપ્સ હોય, તો તે 75% વખત નિષ્ફળ જાય છે.
મોડેલ સમસ્યા નથી. કમ્પાઉન્ડિંગ પ્રોબેબિલિટી (Compounding probability) સમસ્યા છે.
ડેમો એક સિંગલ 'હેપ્પી પાથ' (happy path) બતાવે છે. તે ક્લીન ઇનપુટ અને ટૂંકી ચેઈનનો ઉપયોગ કરે છે. પ્રોડક્શન સેંકડો વપરાશકર્તાઓ પાસેથી મળતા અસ્તવ્યસ્ત (messy) ડેટાનો ઉપયોગ કરે છે. તે લાંબી ચેઈનનો ઉપયોગ કરે છે જેમાં છુપાયેલા સ્ટેપ્સ હોય છે.
એજન્ટ્સમાં નિષ્ફળતા ક્રેસ (crash) જેવી દેખાતી નથી. તે એક શાંત ભૂલ (quiet error) જેવી લાગે છે.
સ્ટેપ 3 કોઈ ફિલ્ડ ખોટી રીતે વાંચે છે. આઉટપુટ હજુ પણ વેલિડ JSON જેવું લાગે છે. સ્ટેપ 4 તે ખરાબ ડેટાનો ઉપયોગ તર્ક (reasoning) કરવા માટે કરે છે. સ્ટેપ 5 થી 8 તે ભૂલ પર આધારિત હોય છે. અંતિમ જવાબ ખોટો હોય છે પરંતુ તે સાચો હોવાનું લાગે છે. તે ક્યાં ખોટું થયું તે બતાવવા માટે કોઈ એરર લોગ (error log) હોતો નથી.
મોડેલે 'હેલ્યુસિનેશન' (hallucinated) કર્યું એમ કહેવાનું બંધ કરો. મોડેલે ફક્ત તેને મળેલા ખરાબ ડેટાને આગળ મોકલ્યો હતો. તમારા સિસ્ટમમાં સ્ટેપ 3 પર ભૂલ પકડવા માટે ચેકપોઈન્ટનો અભાવ હતો.
એજન્ટને માત્ર એક પ્રોમ્પ્ટ તરીકે જોવાનું બંધ કરો. તેને એક સિસ્ટમ તરીકે જોવાનું શરૂ કરો.
વિશ્વસનીય એજન્ટ્સ બનાવવા માટે આ નિયમોનું પાલન કરો:
સ્ટેટ (state) ને એજન્ટની બહાર સેવ કરો. સ્ટેટને ડેટાબેઝમાં રાખો, વાતચીતમાં (conversation) નહીં. જો કોઈ પ્રક્રિયા સ્ટેપ 6 પર નિષ્ફળ જાય છે, તો તમે સ્ટેપ 6 થી ફરી શરૂ કરી શકો છો. તમારે આખી ચેઈન ફરીથી શરૂ કરવાની જરૂર નથી.
બોર્ડરીઝ (boundaries) પર વેલિડેશન કરો. દરેક ઇનપુટ અને આઉટપુટને સ્કીમા (schema) સામે તપાસો. ભૂલ જ્યાં થાય છે તે સ્ટેપ પર જ તેને પકડો. આનાથી રહસ્યમય ભૂલને સુધારી શકાય તેવી ભૂલ (recoverable error) માં બદલી શકાય છે.
સાઇડ ઇફેક્ટ્સને આઈડેમપોટેન્ટ (idempotent) બનાવો. જ્યારે સ્ટેપ્સ નિષ્ફળ જાય ત્યારે તમારે તેને ફરીથી પ્રયાસ (retry) કરવો જોઈએ. જો કોઈ સ્ટેપ ઈમેલ મોકલે છે અથવા કાર્ડ ચાર્જ કરે છે, તો આઈડેમપોટન્સી કી (idempotency key) નો ઉપયોગ કરો. આ રીટ્રાય દરમિયાન ડુપ્લીકેટ એક્શનને અટકાવે છે.
તમારા CI માં ઇવેલ્સ (evals) નો ઉપયોગ કરો. દરેક ફેરફાર સાથે એજન્ટનું વર્તન બદલાય છે. પ્રોમ્પ્ટમાં ફેરફાર કરવાથી એક કેસ સુધરી શકે છે પરંતુ અન્ય પાંચ બગડી શકે છે. આ પ્રકારના રિગ્રેશન (regressions) ને આપમેળે પકડવા માટે ટેસ્ટ સેટનો ઉપયોગ કરો.
ડેમોમાંથી વાસ્તવિક પ્રોડક્ટ તરફ જવું એ એન્જિનિયરિંગ વિશે છે. તે એરર હેન્ડલિંગ, સ્ટેટ મેનેજમેન્ટ અને ઓબ્ઝર્વેબિલિટી (observability) વિશે છે. તે માત્ર સારા પ્રોમ્પ્ટ્સ વિશે નથી.
જો તમારો એજન્ટ પ્રોડક્શનમાં નિષ્ફળ જાય, તો મોટા મોડેલની શોધ ન કરો. તે સ્ટેપ શોધો જ્યાં ચેઈન ખોટી દિશામાં જાય છે. પૂછો કે તમારી સિસ્ટમે ત્યાં ભૂલ કેમ પકડી નહીં.
સ્ત્રોત: https://dev.to/sagar_jain4010/your-agent-demo-works-thats-the-trap-4joc
વૈકલ્પિક લર્નિંગ કોમ્યુનિટી: https://t.me/GyaanSetuAi