సపోర్ట్ ఏజెంట్, టూ-ఫ్యాక్టర్ అథెంటికేషన్ను రీసెట్ చేయాలనే వినియోగదారుడి అభ్యర్థనకు, అసలు లేని దశలతో (steps) సమాధానం ఇచ్చారు. ఆ సమాధానం చాలా నమ్మకంగా అనిపించింది, HTTP రిక్వెస్ట్ 200 OK అని చూపించింది, లేటెన్సీ (latency) సాధారణంగా ఉంది మరియు ప్రతి మానిటరింగ్ చార్ట్ కూడా గ్రీన్ (green) గానే ఉంది.
అంతర్గత తనిఖీలు (internal checks) ఎర్రర్ను గుర్తించాల్సింది పోయి, అవి అసలు రన్ కాలేదు, అందుకే AI-ఆధారిత సపోర్ట్ ఏజెంట్ ఒక తప్పుడు సమాధానాన్ని (hallucinated answer) ఇచ్చారు. ఇంజనీర్లు నమ్మే డ్యాష్బోర్డ్లు అంతా పర్ఫెక్ట్గా ఉందని చూపించాయి, కానీ ఏజెంట్ నిశ్శబ్దంగా ఒక తప్పుడు పరిష్కారాన్ని సృష్టించారు.
సాంప్రదాయ డ్యాష్బోర్డ్లు AI హాలూసినేషన్లను (hallucinations) ఎందుకు గుర్తించలేవు
చాలా అబ్జర్వబిలిటీ స్టాక్స్ (observability stacks) AI ఏజెంట్ను మరే ఇతర మైక్రోసర్వీస్ లాగానే పరిగణిస్తాయి: ఒకే ఒక ఇన్బౌండ్ రిక్వెస్ట్ మరియు ఒకే ఒక అవుట్బౌండ్ రెస్పాన్స్. అవి HTTP స్టేటస్, రెస్పాన్స్ టైమ్ మరియు ఎర్రర్ కౌంట్ను మాత్రమే లాగ్ చేస్తాయి. కానీ రిక్వెస్ట్ లోపల జరిగే దాగి ఉన్న దశలను అవి లాగ్ చేయవు – అంటే ఎక్స్టర్నల్ డాక్యుమెంట్ల రిట్రీవల్ (retrieval), లార్జ్ లాంగ్వేజ్ మోడల్స్కు చేసే కాల్స్, అక్సిలరీ టూల్స్ వాడకం మరియు అవుట్పుట్ను ధృవీకరించే గార్డ్-రైల్ లాజిక్ (guard-rail logic) వంటివి.
రిట్రీవల్ దశలో ఫలితం ఖాళీగా వచ్చినప్పుడు, మోడల్ తరచుగా ఆ ఖాళీని నమ్మశక్యంగా అనిపించే టెక్స్ట్తో "నింపేస్తుంది". మానిటరింగ్ సిస్టమ్ దృష్టిలో ఆ కాల్ విజయవంతమైనట్లుగానే కనిపిస్తుంది, ఎందుకంటే ఏదీ క్రాష్ కాలేదు మరియు స్టేటస్ కోడ్ 200 గానే ఉంది. దీనివల్ల హాలూసినేషన్ కంటికి కనిపించదు, వినియోగదారుడికి తప్పుడు సమాధానం చేరడమే దీని ఏకైక లక్షణం అవుతుంది.
బ్లాక్ బాక్స్ను చదవగలిగే ట్రీ (tree) లాగా మార్చడం
నమ్మదగిన డీబగ్గింగ్ (debugging) కోసం మొదటి అడుగు ఏమిటంటే, ఏజెంట్ను ఒకే ఒక మోనోలిథిక్ కాల్గా చూడటం మానేసి, ప్రతి అంతర్గత ఆపరేషన్ను ట్రేస్ టేబుల్లో (trace table) ఒక ప్రత్యేక రో (row) లాగా విజువలైజ్ చేయడం ప్రారంభించాలి. ఒక సాధారణ రన్ ఈ క్రింది విధంగా విభజించబడుతుంది:
- టాప్-లెవల్ ఏజెంట్ ఇన్వోకేషన్ (invocation)
- సంబంధిత డాక్యుమెంటేషన్ను తీసుకువచ్చే రిట్రీవల్ దశ
- రిట్రీవ్ చేసిన డేటాను ప్రాసెస్ చేసే ప్రతి లాంగ్వేజ్-మోడల్ ఇన్ఫరెన్స్ (inference)
- ప్రతి టూల్ కాల్ (ఉదాహరణకు, డేటాబేస్ లుకప్, API రిక్వెస్ట్)
- వాస్తవికతను లేదా పాలసీ కంప్లయన్స్ (policy compliance)ను నిర్ధారించే గార్డ్-రైల్ తనిఖీలు
ప్రతి రో టైమ్స్టాంప్, సక్సెస్ ఫ్లాగ్ మరియు ఆ దశ ద్వారా ప్రయాణించిన పేలోడ్ (payload)ను రికార్డ్ చేస్తుంది. ఈ నిర్మాణంతో, ఎగ్జిక్యూషన్ అనేది ఒక ట్రీ లాగా మారుతుంది, దీనివల్ల ఫైనల్ అవుట్పుట్ను బట్టి ఊహించే బదులు, ప్రతి లైన్ను విడివిడిగా పరిశీలించవచ్చు.
తప్పించుకున్న బగ్ (bug)
ఆ తప్పుగా జరిగిన సపోర్ట్ ఇంటరాక్షన్లో ట్రేస్ ఇలా ఉంది:
- Retrieval రన్ అయ్యింది కానీ ఎటువంటి డాక్యుమెంట్లు తిరిగి ఇవ్వలేదు.
- తదుపరి దశ ఏదేమైనా కొనసాగింది, మోడల్కు ఖాళీ కాంటెక్స్ట్ను పంపింది.
- మోడల్ లేని సమాచారాన్ని కల్పిత దశలతో నింపుతూ ఒక సమాధానాన్ని రూపొందించింది.
- పైప్లైన్లో ఎటువంటి ఎక్సెప్షన్ (exception) ఎదురుకాదు కాబట్టి సిస్టమ్ 200ను రిటర్న్ చేసింది.
ఈ హాలూసినేషన్ లాంగ్వేజ్ మోడల్లో ఉన్న లోపం కాదు; ఇది రిట్రీవల్ మరియు జనరేషన్ దశల మధ్య ఉండాల్సిన గార్డ్-రైల్ లేకపోవడం వల్ల జరిగింది. తన సమాధానానికి ఆధారంగా ఉండటానికి ఏమీ లేకపోయినప్పటికీ ఏజెంట్ సమాధానం ఇచ్చింది.
హాలూసినేషన్లను అడ్డుకునే సరళమైన గార్డ్-రైల్స్
రెండు నిర్దిష్ట మార్పులు ఈ సమస్యను తొలగించాయి:
- ఖాళీ రిట్రీవల్ జరిగినప్పుడు నిలిపివేయండి (Abort on empty retrieval) – డాక్యుమెంట్ స్టోర్ నుండి ఏమీ రానప్పుడు, ఏజెంట్ జనరేషన్ దశకు వెళ్లకుండా, "మీకు కావాల్సిన సమాచారాన్ని నేను కనుగొనలేకపోయాను" అని సమాధానం ఇవ్వాలి.
- గ్రౌండింగ్ చెక్ (Grounding check) – మోడల్ ఒక రెస్పాన్స్ను ఇచ్చిన తర్వాత, అందులోని ప్రతి వాస్తవ అంశం రిట్రీవ్ చేసిన కంటెంట్లో ఉందో లేదో ధృవీకరించండి. ఒకవేళ చెక్ విఫలమైతే, ఆ సమాధానాన్ని తిరస్కరించి, "సమాధానం చెప్పలేను" అనే రెస్పాన్స్కు వెళ్లండి.
వేగవంతమైన డీబగ్గింగ్ కోసం ఒక ప్రాక్టికల్ వర్క్ఫ్లో
- ప్రతి అంతర్గత కాల్ను ట్రేస్ చేయండి – ప్రతి రిట్రీవల్, మోడల్ ఇన్ఫరెన్స్ మరియు టూల్ వాడకం ఒక పర్సిస్టెంట్ లాగ్లో (persistent log) ఒక రోను రాసేలా ఏజెంట్ను ఇన్స్ట్రుమెంట్ చేయండి.
- విఫలమైన రన్లను భద్రపరచండి – వినియోగదారుడు తప్పు అని రిపోర్ట్ చేసిన ఏ ఇంటరాక్షన్ యొక్క పూర్తి ట్రేస్నైనా భద్రపరచండి. స్టోరేజ్ ఆదా చేయడానికి వాటిని డిలీట్ చేయడం వల్ల, రిగ్రెషన్లను (regressions) కనుగొనడానికి అవసరమైన డేటా మరుగున పడిపోతుంది.
- రన్లను వెర్షన్ సమాచారంతో ట్యాగ్ చేయండి – ప్రతి ట్రేస్ రోలో రిలీజ్ ఐడెంటిఫైయర్ మరియు ఏదైనా ఫీచర్-ఫ్లాగ్ స్టేట్ను చేర్చండి. ఇది కొత్త బగ్ను ఇటీవలి కోడ్ మార్పుతో అనుసంధానించడానికి మీకు సహాయపడుతుంది.
- వేగాన్ని మాత్రమే కాకుండా, నాణ్యతను కూడా స్కోర్ చేయండి – సమాధానం సూచనలను ఎంత బాగా అనుసరిస్తుంది మరియు రిట్రీవ్ చేసిన కంటెంట్కు ఎంతవరకు కట్టుబడి ఉంది అనే అంశాలను కొలిచే మెట్రిక్స్ను జోడించండి. సమాధానాలు తప్పుగా ఉన్నప్పుడు, హై త్రూపుట్ (high throughput) వల్ల పెద్దగా ఉపయోగం ఉండదు.
- ప్రతిరోజూ వైఫల్యాలను సమీక్షించండి – భద్రపరచిన వైఫల్యాలను క్రమబద్ధంగా సమీక్షించడం వల్ల, అవి చాలా మంది వినియోగదారులను ప్రభావితం చేసే ముందే కొన్ని ప్యాటర్న్లను (ఉదాహరణకు, ఒక నిర్దిష్ట రకమైన క్వెరీ నిరంతరం ఖాళీ రిట్రీవల్స్ను ఇస్తుండటం) గుర్తించవచ్చు.
"గ్రీన్" (green) ను "వెరిఫైడ్" (verified) గా మార్చడం ద్వారా, బృందాలు హాలూసినేషన్లను త్వరగా గుర్తించగలవు మరియు వినియోగదారు అనుభవాన్ని నమ్మదగినదిగా ఉంచగలవు.
అంతర్గత వైఫల్యాలను విస్మరించడం వల్ల కలిగే నష్టం
డ్యాష్బోర్డ్లు కేవలం HTTP లేయర్లో మాత్రమే విజయాన్ని రిపోర్ట్ చేసినప్పుడు, సంస్థలు నమ్మదగినవిగా కనిపించే కానీ క్రమంగా తప్పుడు మార్గదర్శకత్వాన్ని అందించే ఏజెంట్లను వినియోగిస్తాయి.
తదుపరి ఏమి చూడాలి
అవి సర్వసాధారణం అయ్యే వరకు, ప్రతి అంతర్గత ప్రక్రియను గమనించదగినదిగా (observable) పరిగణించడం మరియు ఆధారాలు లేనప్పుడు త్వరగా విఫలం కావడం (fail fast) అత్యంత సురక్షితమైన విధానం.
ముఖ్యాంశం: గ్రీన్ డ్యాష్బోర్డ్ అనేది వ్యవస్థ (plumbing) సరిగ్గా పనిచేస్తుందని చెబుతుంది; కానీ సమాధానం సరైనదని అది హామీ ఇవ్వదు. ప్రతి రిట్రీవల్ (retrieval), మోడల్ కాల్ (model call) మరియు గార్డ్-రైల్ చెక్లను (guard-rail check) ట్రాస్ చేయడం ద్వారా, మీరు దాగి ఉన్న హాలూసినేషన్లను (hallucinations), వినియోగదారుడికి చేరుకోకముందే సరిచేయగలిగే స్పష్టమైన వైఫల్యాలుగా మారుస్తారు.