સપોર્ટ એજન્ટે ટુ-ફેક્ટર ઓથેન્ટિકેશન (two-factor authentication) રિસેટ કરવાના વપરાશકર્તાના વિનંતીનો જવાબ એવા સ્ટેપ્સ સાથે આપ્યો જેનું અસ્તિત્વ જ નથી. પ્રતિસાદ આત્મવિશ્વાસપૂર્ણ લાગતો હતો, HTTP રિક્વેસ્ટ 200 OK રિટર્ન કરી હતી, લેટન્સી (latency) સામાન્ય હતી અને દરેક મોનિટરિંગ ચાર્ટ ગ્રીન (green) જ રહ્યો હતો.
એક AI-સંચાલિત સપોર્ટ એજન્ટે ખોટો જવાબ (hallucinated) આપ્યો કારણ કે જે આંતરિક તપાસ (internal checks) એ ભૂલ પકડી લેવી જોઈતી હતી તે ક્યારેય ચાલી જ નહીં. એન્જિનિયરો જે ડેશબોર્ડ્સ પર આધાર રાખે છે તેમાં બધું બરાબર હોવાનું દર્શાવવામાં આવ્યું હતું, જ્યારે એજન્ટે ચુપચાપ એક ખોટો ઉકેલ બનાવ્યો હતો.
પરંપરાગત ડેશબોર્ડ્સ AI Hallucinations કેમ ચૂકી જાય છે
મોટાભાગના ઓબ્ઝર્વેબિલિટી સ્ટેક્સ (observability stacks) AI એજન્ટને અન્ય કોઈપણ માઇક્રોસર્વિસની જેમ જ જુએ છે: એક સિંગલ ઇનબાઉન્ડ રિક્વેસ્ટ અને એક સિંગલ આઉટબાઉન્ડ રિસ્પોન્સ. તેઓ HTTP સ્ટેટસ, રિસ્પોન્સ ટાઇમ અને એરર કાઉન્ટ લોગ કરે છે. તેઓ રિક્વેસ્ટની અંદરના છુપાયેલા સ્ટેપ્સ લોગ કરતા નથી – જેમ કે બાહ્ય દસ્તાવેજો મેળવવાની પ્રક્રિયા (retrieval), લાર્જ લેંગ્વેજ મોડલ્સ (LLMs) ને કરવામાં આવતા કોલ્સ, સહાયક સાધનોનો ઉપયોગ અને આઉટપુટને વેલિડેટ કરતું કોઈપણ ગાર્ડ-રેલ લોજિક (guard-rail logic).
જ્યારે રિટ્રાઇવલ સ્ટેપ ખાલી પરિણામ આપે છે, ત્યારે મોડલ ઘણીવાર વ્યાજબી લાગતા લખાણ સાથે "ખાલી જગ્યા ભરી દે છે". મોનિટરિંગ સિસ્ટમના દૃષ્ટિકોણથી કોલ સફળ રહ્યો હતો, કારણ કે કંઈપણ ક્રેશ થયું નહોતું અને સ્ટેટસ કોડ 200 જ રહ્યો હતો. આ Hallucination અદ્રશ્ય રહે છે, અને તેનો એકમાત્ર લક્ષણ એ છે કે વપરાશકર્તા સુધી ખોટો જવાબ પહોંચે છે.
બ્લેક બોક્સને વાંચી શકાય તેવા ટ્રી (tree) માં ફેરવવું
વિશ્વસનીય ડીબગિંગ માટેનું પ્રથમ પગલું એ છે કે એજન્ટને એક મોનોલિથિક કોલ તરીકે જોવાનું બંધ કરો અને દરેક આંતરિક કામગીરીને ટ્રેસ ટેબલમાં (trace table) તેની પોતાની રો (row) તરીકે વિઝ્યુલાઇઝ કરવાનું શરૂ કરો. એક સામાન્ય રન નીચે મુજબ વિભાજિત થાય છે:
- એજન્ટનું ટોપ-લેવલ ઇન્વોકેશન (invocation)
- રિટ્રાઇવલ સ્ટેપ જે સંબંધિત ડોક્યુમેન્ટેશન મેળવે છે
- રિટ્રાઇવ કરેલા ડેટાને પ્રોસેસ કરતું દરેક લેંગ્વેજ-મોડલ ઇન્ફરન્સ (inference)
- દરેક ટૂલ કોલ (દા.ત., ડેટાબેઝ લુકઅપ, API રિક્વેસ્ટ)
- ગાર્ડ-રેલ ચેક્સ જે સત્યતા અથવા પોલિસી પાલન સુનિશ્ચિત કરે છે
દરેક રો ટાઇમસ્ટેમ્પ, સક્સેસ ફ્લેગ, અને તે સ્ટેપમાંથી પસાર થયેલ પેલોડ (payload) નો રેકોર્ડ રાખે છે. આ માળખા સાથે, એક્ઝિક્યુશન એક ટ્રી બની જાય છે જેને અંતિમ આઉટપુટ પરથી અનુમાન લગાવવાને બદલે લાઇન-બાય-લાઇન તપાસી શકાય છે.
છૂટી ગયેલી ભૂલ (bug)
ખામીયુક્ત સપોર્ટ ઇન્ટરેક્શનમાં ટ્રેસ આવો દેખાતો હતો:
- Retrieval ચાલ્યું પરંતુ કોઈ દસ્તાવેજો રિટર્ન કર્યા નહીં.
- પછીનું સ્ટેપ તેમ છતાં આગળ વધ્યું, મોડલને ખાલી કોન્ટેક્સ્ટ (context) મોકલ્યું.
- મોડલે એવો જવાબ આપ્યો જેણે ખૂટતી માહિતીને કાલ્પનિક સ્ટેપ્સ સાથે ભરી દીધી.
- સિસ્ટમે 200 રિટર્ન કર્યું કારણ કે પાઇપલાઇનમાં કોઈ એક્સેપ્શન (exception) આવી નહોતી.
Hallucination એ લેંગ્વેજ મોડલમાં રહેલી ખામી નહોતી; તે રિટ્રાઇવલ અને જનરેશન સ્ટેજ વચ્ચેના ગાર્ડ-રેલની ગેરહાજરી હતી. એજન્ટે ત્યારે પણ જવાબ આપ્યો જ્યારે તેની પાસે તેના પ્રતિસાદને આધાર આપવા માટે કંઈ જ નહોતું.
Hallucinations રોકતા સરળ ગાર્ડ-રેલ્સ
બે ચોક્કસ ફેરફારોએ આ સમસ્યા દૂર કરી:
- ખાલી રિટ્રાઇવલ પર અટકવું (Abort on empty retrieval) – જો ડોક્યુમેન્ટ સ્ટોર કંઈ જ રિટર્ન ન કરે, તો એજન્ટે જનરેશન તરફ આગળ વધવાને બદલે "મને તમારી જરૂરિયાત મુજબની માહિતી મળી નથી" એમ જવાબ આપવો જોઈએ.
- ગ્રાઉન્ડિંગ ચેક (Grounding check) – મોડલ પ્રતિસાદ આપ્યા પછી, ચકાસો કે દરેક તથ્યાત્મક દાવો રિટ્રાઇવ કરેલા કન્ટેન્ટમાં છે કે નહીં. જો ચેક નિષ્ફળ જાય, તો જવાબને નકારી કાઢો અને "જવાબ આપી શકાશે નહીં" તેવો પ્રતિસાદ આપો.
ઝડપી ડીબગિંગ માટે વર્કફ્લો
- દરેક આંતરિક કોલને ટ્રેસ કરો – એજન્ટને એવી રીતે ઇન્સ્ટ્રુમેન્ટ કરો કે દરેક રિટ્રાઇવલ, મોડલ ઇન્ફરન્સ અને ટૂલનો ઉપયોગ એક પર્સિસ્ટન્ટ લોગમાં રો (row) તરીકે લખાય.
- નિષ્ફળ રન સાચવી રાખો – વપરાશકર્તા જે ઇન્ટરેક્શનને ખોટું જણાવે છે તેનો સંપૂર્ણ ટ્રેસ સ્ટોર કરો. સ્ટોરેજ બચાવવા માટે તેને ડિલીટ કરવાથી રગ્રેસન (regressions) શોધવા માટે જરૂરી ડેટા છુપાઈ જાય છે.
- વર્ઝન માહિતી સાથે રન ટેગ કરો – દરેક ટ્રેસ રોમાં રિલીઝ આઇડેન્ટિફાયર અને કોઈપણ ફીચર-ફ્લેગ સ્ટેટનો સમાવેશ કરો. આ તમને નવા બગને તાજેતરના કોડ ફેરફાર સાથે જોડવામાં મદદ કરશે.
- માત્ર ઝડપ નહીં, ગુણવત્તાને સ્કોર કરો – એવા મેટ્રિક્સ ઉમેરો જે માપે છે કે જવાબ સૂચનાઓનું કેટલી સારી રીતે પાલન કરે છે અને રિટ્રાઇવ કરેલા કન્ટેન્ટમાં કેટલો આધારિત છે. જો જવાબો ખોટા હોય તો હાઈ થ્રુપુટ (high throughput) નો બહુ ઓછો અર્થ રહે છે.
- દરરોજ નિષ્ફળતાઓનું રિવ્યુ કરો – સ્ટોર કરેલી નિષ્ફળતાઓનું ટૂંકું અને નિયમિત રિવ્યુ ઘણીવાર પેટર્ન (દા.ત., ચોક્કસ પ્રકારના ક્વેરી સતત ખાલી રિટ્રાઇવલ આપે છે) ને ઘણા વપરાશકર્તાઓને અસર કરતા પહેલા જ શોધી કાઢે છે.
"ગ્રીન" ને "વેરિફાઇડ" માં ફેરવીને, ટીમો Hallucinations ને વહેલી તકે પકડી શકે છે અને વપરાશકર્તાના અનુભવને વિશ્વસનીય બનાવી શકે છે.
આંતરિક નિષ્ફળતાઓને અવગણવાની કિંમત
જ્યારે ડેશબોર્ડ્સ ફક્ત HTTP લેયર પર સફળતા રિપોર્ટ કરે છે, ત્યારે સંસ્થાઓ એવા એજન્ટો તૈનાત કરે છે જે વિશ્વસનીય લાગે છે પરંતુ નિયમિતપણે ખોટું માર્ગદર્શન આપે છે.
આગળ શું જોવું
જ્યાં સુધી તે સામાન્ય ન બને, ત્યાં સુધી દરેક આંતરિક પ્રક્રિયાને અવલોકનક્ષમ (observable) તરીકે ગણવી અને જ્યારે પુરાવા ન મળે ત્યારે તરત જ નિષ્ફળતા (fail fast) દર્શાવવી એ સૌથી સુરક્ષિત અભિગમ છે.
મુખ્ય વાત: ગ્રીન ડેશબોર્ડ તમને જણાવે છે કે પ્લમ્બિંગ કામ કરી રહ્યું છે; તે જવાબ સાચો હોવાની ખાતરી આપતું નથી. દરેક રિટ્રીવલ, મોડેલ કોલ અને ગાર્ડ-રેલ ચેકને ટ્રેસ કરીને, તમે છુપાયેલા હેલ્યુસિનેશનને એવી દેખીતી નિષ્ફળતાઓમાં બદલી શકો છો જેને વપરાશકર્તા સુધી પહોંચે તે પહેલાં સુધારી શકાય છે.