નવા મોડેલ બેન્ચમાર્ક ચલાવવાનું બંધ કરો અને તમારો એજન્ટ સબ્સ્ક્રિપ્શન રદ કરવાનો પ્રયાસ કરે છે તે જોવાનું શરૂ કરો. આ બે પ્રવૃત્તિઓ વચ્ચેનું અંતર એ છે જ્યાં પ્રોડક્શન સિસ્ટમ્સ નિષ્ફળ જાય છે. એક સિંગલ-ટર્ન ટેસ્ટ તમને જણાવી શકે છે કે પ્રતિસાદ સુખદ લાગે છે કે નહીં. પરંતુ તે તમને એ નથી જણાવી શકતું કે એજન્ટે હમણાં જ ખોટા ગ્રાહકને રિફંડ આપ્યું છે, કેલેન્ડર API સામે ચૌદ વખત લૂપ કર્યું છે, અથવા ફ્રોડ ચેક સંપૂર્ણપણે સ્કીપ કરવાનું નક્કી કર્યું છે. એજન્ટ જે કંઈ પણ બનાવે છે તેમાં ટેક્સ્ટ એ સૌથી ઓછું જોખમી છે. વાસ્તવિક જોખમો તે ટૂલ્સમાં છુપાયેલા છે જેને તે સ્પર્શે છે, તે ડેટામાં છે જેમાં તે ફેરફાર કરે છે, અને તે ક્ષણોમાં છે જ્યારે તેણે મદદ માંગવી જોઈતી હતી પરંતુ તે ચાલુ રાખ્યું.
પ્રોડક્શનમાં ટેક્સ્ટ બેન્ચમાર્ક કેમ નિષ્ફળ જાય છે
સ્ટાન્ડર્ડ બેન્ચમાર્ક પર ઊંચા સ્કોર એ આશ્વાસનનું એક ભ્રામક સ્વરૂપ બની ગયા છે. એક એજન્ટ જે સુંદર લખાણ લખે છે તે હજુ પણ ઓપરેશનલ જોખમ હોઈ શકે છે. જ્યારે તમારી સિસ્ટમ એપોઇન્ટમેન્ટ બુક કરે છે, ડેટાબેઝ રેકોર્ડ્સ એડિટ કરે છે, અથવા સપોર્ટ ટિકિટ્સ ફાઇલ કરે છે, ત્યારે જનરેટ થયેલ ટેક્સ્ટ એ વર્કફ્લોની માત્ર દેખીતી સપાટી છે. તેની નીચે, એજન્ટ કયા એન્ડપોઈન્ટનો ઉપયોગ કરવો, કયો પેલોડ મોકલવો અને ક્યારે અટકવું તે વિશે નક્કર નિર્ણયો લઈ રહ્યો હોય છે. તે રિસોર્સિસનું ડબલ-બુકિંગ કરીને, ખોટી રો (row) માં ફેરફાર કરીને અથવા લોગ ફાઇલમાં સેન્સિટિવ સ્ટેટ લીક કરીને તમને નાણાકીય નુકસાન પહોંચાડી શકે છે, છતાં તે રીડિંગ-કમ્પ્રિહેન્શન લીડરબોર્ડમાં ટોચ પર હોઈ શકે છે. તમારે માત્ર આઉટપુટની ચમક નહીં, પણ કામની મિકેનિક્સને ચકાસવાની જરૂર છે. જો કોઈ એજન્ટ ઓફલાઇન QA ટેસ્ટમાં સારું સ્કોર કરી શકે છે અને તેમ છતાં લૂપિંગ અથવા ટૂલનો દુરુપયોગ કરીને તમારા વર્કફ્લોમાં નિષ્ફળ જાય છે, તો તમારું મૂલ્યાંકન ખોટા સિગ્નલ્સ જોઈ રહ્યું છે.
પાંચ ડિપેન્ડન્સીઝનું મેપિંગ
Van Data Team ની ટીમ દરેક મૂલ્યાંકનની શરૂઆત પાંચ ચોક્કસ કંટ્રોલ પોઈન્ટ્સના મેપિંગથી કરે છે. આ પ્રશ્નને સંપૂર્ણપણે બદલી નાખે છે. તમે એ પૂછવાનું બંધ કરો છો કે એક મોડેલ બીજા કરતા સ્માર્ટ છે કે નહીં. તમે એ પૂછવાનું શરૂ કરો છો કે શું એજન્ટ ખરેખર તમારી વાસ્તવિક મર્યાદાઓ હેઠળ પ્રોડક્શન ટાસ્ક પૂર્ણ કરી શકે છે.
બિઝનેસ આઉટકમ્સ. ડોલર અને ગ્રાહક પરના પ્રભાવના સંદર્ભમાં "પૂર્ણ" એટલે શું તે વ્યાખ્યાયિત કરો. કોઈ કાર્ય માત્ર એટલા માટે પૂર્ણ નથી ગણાતું કારણ કે એજન્ટે સારાંશ આપ્યો છે. તે ત્યારે જ પૂર્ણ ગણાય છે જ્યારે ઇન્વેન્ટરી રેકોર્ડ સચોટ હોય, એપોઇન્ટમેન્ટ કન્ફર્મ થઈ હોય, અને ગ્રાહકને માન્ય ટ્રેકિંગ નંબર મળ્યો હોય.
મ્યુટેબલ સ્ટેટ. એજન્ટને શું બદલવાની મંજૂરી છે તે ચોક્કસ જાણો. કયા ટેબલ્સ, કયા સ્ટેટસ, કયા એકાઉન્ટ ફ્લેગ્સ? જો એજન્ટ રિફંડ આપી શકે છે, જોબ રિશૅડ્યુલ કરી શકે છે, અથવા બિલિંગ એડ્રેસ અપડેટ કરી શકે છે, તો તમારે તે સ્પર્શતા દરેક ફિલ્ડની યાદી બનાવવી પડશે.
ટૂલ પરમિશન. કયા API એન્ડપોઈન્ટ્સ અને ફંક્શન્સ સ્કોપમાં છે તે સ્પષ્ટ કરો. જો સીમાઓ અસ્પષ્ટ હોય, તો સર્ચ ટૂલ, રાઈટ ટૂલ અને નોટિફિકેશન ટૂલની ઍક્સેસ ધરાવતો એજન્ટ આ બધાને મિક્સ કરી નાખશે. દરેક પરમિશનને ચોક્કસ ઓપરેશનલ જરૂરિયાત સાથે મેપ કરો.
ફેઈલ્યોર રિકવરી. જ્યારે કેલેન્ડર API ટાઈમ આઉટ થાય, 500 રિટર્ન કરે અથવા ખોટું JSON આપે ત્યારે શું થાય તે નક્કી કરો. એજન્ટ ગભરાઈ જવો જોઈએ નહીં, સફળતાનો ખોટો સંદેશ (hallucinate) આપવો જોઈએ નહીં, અથવા અનંતકાળ સુધી પ્રયાસ (retry) કરવો જોઈએ નહીં. તેને સ્પષ્ટ ફોલબેક પાથની જરૂર છે.
હ્યુમન રિવ્યુ ગેટ્સ. એવા ક્ષણો ઓળખો જ્યાં એજન્ટ આગળ વધે તે પહેલાં વ્યક્તિએ મંજૂરી આપવી જરૂરી હોય. આ ઓટોમેશનમાં નબળાઈનું ચિહ્ન નથી. તે ઉચ્ચ-અસરકારક ફેરફારો માટે સેફ્ટી વાલ્વ છે અને તમારા રૂબ્રિક્સ માટે ગ્રાઉન્ડ-ટ્રુથ લેબલ્સનો સ્ત્રોત છે.
વાસ્તવિક મૂલ્યાંકન યોજના કેવી દેખાય છે
એકવાર ડિપેન્ડન્સીઝ મેપ થઈ જાય પછી, તમારે પ્રોડક્શનની જટિલતા સાથે મેળ ખાતી મૂલ્યાંકન યોજનાની જરૂર છે. સ્લાઇડ-ડેક મેટ્રિક્સ તમને અહીં મદદ કરશે નહીં.
સિન્થેટિક પ્રશ્ન બેંકોમાંથી નહીં, પણ વાસ્તવિક પ્રોડક્શન નિષ્ફળતાઓમાંથી ટેસ્ટ સેટ્સ બનાવો. જો તમારો એજન્ટ ગયા મંગળવારે બે સમાન SKUs વચ્ચે ભૂલ કરીને નિષ્ફળ ગયો હતો, તો તે ચોક્કસ ભૂલ એક કાયમી ટેસ્ટ કેસ હોવી જોઈએ. જ્યારે પણ કોઈ ઘટના તમને કંઈક નવું શીખવે, ત્યારે તમારો ઇવેલ્યુએશન સ્યુટ વધવો જોઈએ.
ઓપરેશનલ શબ્દોમાં સફળતાની વ્યાખ્યા આપતા રૂબ્રિક્સ લખો. "મદદરૂપ" અથવા "ચોક્કસ" જેવા અસ્પષ્ટ માપદંડો નકામા છે. એક ઉપયોગી રૂબ્રિક જણાવે છે કે રિફંડ કાર્ય ત્યારે જ સફળ ગણાય જો મૂળ પેમેન્ટ ID નો સંદર્ભ લેવામાં આવ્યો હોય, રકમ વિનંતી સાથે મેળ ખાતી હોય, કન્ફર્મેશન ઈમેલ ક્યુઅરમાં હોય અને ટ્રાન્ઝેક્શન ID લોગ કરવામાં આવ્યો હોય.
ટૂલ કોલ્સ અને રિટ્રાય માટે ટ્રેસ સ્પેક્સ વ્યાખ્યાયિત કરો. એજન્ટે શું આયોજન કર્યું હતું, તેણે ખરેખર શું કોલ કર્યું હતું, તેણે કેટલી વાર પ્રયાસ કર્યો હતો અને રિટ્રાય વ્યૂહરચના યોગ્ય હતી કે નહીં તે જાણવા માટે તમારે ઓબ્ઝર્વેબિલિટીની જરૂર છે. ટૂલ-લેવલ ગ્રેન્યુલારિટી વગરનો ટ્રેસ માત્ર એક સુંદર વાર્તા સમાન છે.
ક્યારે માણસને એલર્ટ કરવું તેના માટે નીતિઓ નક્કી કરો. એજન્ટ તેની પોતાની મર્યાદાઓ જાણવો જોઈએ. જો કોઈ વિનંતી ડોલર થ્રેશોલ્ડથી વધી જાય, VIP એકાઉન્ટનો સંદર્ભ આપે અથવા એવી સ્થિતિનો સામનો કરે જે તેણે પહેલા ક્યારેય જોઈ નથી, તો તેણે અનુમાન લગાવવાને બદલે એસ્કેલેટ કરવું જોઈએ.
ખરાબ મોડેલ અપગ્રેડ્સને રોકવા માટે રિલીઝ ગેટ્સ (release gates) ઇન્સ્ટોલ કરો. નવું મોડેલ ત્યારે જ અપગ્રેડ ગણાય જો તે તમારા ચોક્કસ પરિણામોમાં સુધારો કરે. જો તે વારંવાર ટૂલ આર્ગ્યુમેન્ટ્સમાં ભૂલો (hallucinate) કરે, લેટન્સી (latency) વધારે, અથવા નવા સુરક્ષા જોખમો ઊભા કરે, તો તેને શિપ (ship) ન કરવું જોઈએ. જ્યારે બેઝ મોડેલ વેન્ડર નવું વર્ઝન બહાર પાડે, ત્યારે પણ આ ગેટ પ્રોડક્શનને સ્થિર રાખે છે.
રનટાઇમ ગ્રેડિંગ (Runtime Grading): એજન્ટના કામ પર નજર રાખવી
Anthropic ઉદ્યોગને ઓફલાઇન ટેસ્ટથી આગળ વધીને રનટાઇમ ગ્રેડિંગ (runtime grading) તરફ વધવા માટે પ્રોત્સાહિત કરી રહ્યું છે. ટ્રાન્સક્રિપ્ટ બની ગયા પછી તેનું મૂલ્યાંકન કરવાને બદલે, રનટાઇમ ગ્રેડિંગ સિસ્ટમને કાર્ય ચાલુ હોય ત્યારે જ એજન્ટના કામનું મૂલ્યાંકન કરવાની મંજૂરી આપે છે. આનાથી ભૂલો વાસ્તવિક સમસ્યાઓમાં ફેરવાઈ જાય તે પહેલાં તેને પકડવાની તક મળે છે.
ગ્રેડર ઉમેરવાથી ટોકન્સ અને લેટન્સીનો ખર્ચ વધે છે. તમે દરેક નાની સ્ટેપનું ગ્રેડિંગ કરી શકતા નથી. દરેક ગ્રેડરનું સ્થાન એ એક ડિઝાઇન નિર્ણય છે. તેમને ત્યાં મૂકો જ્યાં ભૂલો મોંઘી પડે. સૌથી મૂલ્યવાન ચેકપોઈન્ટ્સ ડેટાબેઝમાં સ્ટેટ ચેન્જ કમિટ કરતા પહેલા, પેમેન્ટ લેતા પહેલા, અને ગ્રાહકને મેસેજ મોકલતા પહેલા હોય છે. આ એવા ક્ષણો છે જ્યાં ખોટો નિર્ણય લેવો એ અફર (irreversible) કાર્ય બની જાય છે.
એક ચોક્કસ બ્લાઇન્ડ સ્પોટ (blind spot) થી સાવધ રહો. જો એ જ મોડેલ કામ પણ કરે અને તેનું ગ્રેડિંગ પણ કરે, તો તે તે જ ભૂલો ચૂકી શકે છે. જે તર્ક (reasoning) દ્વારા ભૂલ થઈ હોય, તે જ તર્ક રિવ્યુ દરમિયાન તે ભૂલને યોગ્ય ઠેરવી શકે છે. ઉચ્ચ-અસરકારક કાર્યો માટે, હ્યુમન રિવ્યુ (human review) ને લૂપમાં રાખો. ખાસ કરીને જ્યારે નાણાં અથવા ગ્રાહકનો વિશ્વાસ જોખમમાં હોય, ત્યારે લોકોને ગ્રેડરના પોતાના નિર્ણયને ચકાસવા દો.
અહીં ધ્યેય ઓપરેશનલ કંટ્રોલ (operational control) છે. તમારા ઇન્સિડન્ટ ડેટા, તમારા ટાસ્ક રૂબ્રિક્સ (task rubrics), અને તમારા રનટાઇમ ટ્રેસિસને એક ફીડબેક સાયકલમાં જોડો. આખા માર્ગનું મૂલ્યાંકન કરો: પ્લાન, ટૂલનો ઉપયોગ, રિકવરી બિહેવિયર અને અંતિમ પરિણામ. રિલીઝ પહેલા જાણીતી અને ફરીથી થઈ શકે તેવી ભૂલો પકડવા માટે ઓફલાઇન ટેસ્ટનો ઉપયોગ કરો. તમે અપેક્ષા ન રાખી હોય તેવી નવી નિષ્ફળતાઓ શોધવા માટે રનટાઇમ ટ્રેસિસનો ઉપયોગ કરો. તમારા રૂબ્રિક્સ ક્યાં નબળા છે અને તેને વધુ સચોટ બનાવવાની જરૂર છે તે જાણવા માટે હ્યુમન રિવ્યુનો ઉપયોગ કરો.
તેથી તમારી જાતને પૂછો: તમે તમારા વર્કફ્લોમાં રનટાઇમ ગ્રેડર ક્યાં મૂકશો? ટૂલ કોલ પહેલા, ટૂલ કોલ પછી, કે ફક્ત જોખમી ફેરફાર પહેલા? મોટાભાગની ટીમો બધું જ ગ્રેડ કરીને ખૂબ જ વ્યાપક રીતે શરૂઆત કરે છે, અને પછી ખર્ચને કારણે અટકી જાય છે. સાંકડા પાયે શરૂઆત કરો. એવી એક ક્રિયા પસંદ કરો જે જો ખોટી પડે તો સૌથી વધુ નુકસાન થાય. પહેલા ત્યાં ગ્રેડર મૂકો.
એક મોંઘી ભૂલથી શરૂઆત કરો
ઓપરેશનલ ઇવેલ્યુએશન એ કોઈ સંશોધન અભ્યાસ નથી. એજન્ટ લાઇવ થયા પછી સારી રીતે ઊંઘવા માટેનો આ એક રસ્તો છે. તમારે પહેલા દિવસે સંપૂર્ણ ફ્રેમવર્કની જરૂર નથી. તમારે ફક્ત એક સચોટ વર્કફ્લો, સાદા બિઝનેસ શબ્દોમાં લખાયેલું રૂબ્રિક અને એ ક્ષણે ગ્રેડરની જરૂર છે જ્યાં ભૂલ મોંઘી પડે છે. જો તમે આ સાચું કરી લો, તો તમારી પાસે એક એવો પાયો હશે જેના પર તમે ખરેખર વિશ્વાસ કરી શકો છો.
જો તમે પ્રેક્ટિશનર્સના સમુદાય સાથે એજન્ટ ઇવેલ્યુએશન અને રનટાઇમ ગ્રેડિંગ વિશે વધુ ઊંડાણપૂર્વક જાણવા માંગતા હોવ, તો તમે GyaanSetu લર્નિંગ કોમ્યુનિટી https://t.me/GyaanSetuAi પર શોધી શકો છો.