ஒரு பயனர் தனது இருபடி அங்கீகாரத்தை (two-factor authentication) மீட்டமைக்கக் கோரியபோது, ஆதரவு முகவர் (support agent) இல்லாத வழிமுறைகளைக் கூறி பதிலளித்தார். அந்தப் பதில் நம்பிக்கையானதாகத் தோன்றியது, HTTP கோரிக்கை 200 OK என்று திரும்பியது, தாமத நேரம் (latency) இயல்பாக இருந்தது மற்றும் அனைத்து கண்காணிப்பு வரைபடங்களும் (monitoring charts) பச்சை நிறத்திலேயே இருந்தன.
ஒரு AI-அடிப்படையிலான ஆதரவு முகவர் தவறான பதிலை உருவாக்கினார் (hallucinated), ஏனெனில் பிழையைக் கண்டறிய வேண்டிய உள்முறைச் சோதனைகள் (internal checks) நடக்கவில்லை. பொறியாளர்கள் நம்பியிருக்கும் டேஷ்போர்டுகள் (dashboards) அனைத்தும் அனைத்தும் சரியாக நடந்ததாகக் காட்டின, ஆனால் முகவர் அமைதியாக ஒரு கற்பனையான தீர்வை வழங்கினார்.
பாரம்பரிய டேஷ்போர்டுகள் ஏன் AI மாயத்தோற்றங்களைக் (hallucinations) கண்டறிவதில்லை
பெரும்பாலான கண்காணிப்பு அமைப்புகள் (observability stacks) ஒரு AI முகவரை மற்ற மைக்ரோசர்வீஸ்களைப் போலவே கருதுகின்றன: ஒரு உள்ளீட்டுக் கோரிக்கை (inbound request) மற்றும் ஒரு வெளியீட்டுப் பதில் (outbound response). அவை HTTP நிலை (status), பதில் நேரம் மற்றும் பிழை எண்ணிக்கையைப் பதிவு செய்கின்றன. ஆனால் கோரிக்கைக்குள் இருக்கும் மறைமுகமான படிகளை அவை பதிவு செய்வதில்லை – அதாவது வெளிப்புற ஆவணங்களைப் பெறுதல் (retrieval), பெரிய மொழி மாதிரிகளுக்கான (large language models) அழைப்புகள், துணை கருவிகளின் பயன்பாடு மற்றும் வெளியீட்டைச் சரிபார்க்கும் பாதுகாப்பு வழிமுறைகள் (guard-rail logic).
ஒரு தகவல் தேடல் படி (retrieval step) காலியான முடிவைத் தரும்போது, மாதிரி (model) பெரும்பாலும் அந்த இடைவெளியை நம்பகமானதாகத் தோன்றும் உரையை வைத்து நிரப்ப முயல்கிறது. கண்காணிப்பு அமைப்பின் பார்வையில், எதுவும் செயலிழக்காததாலும் மற்றும் நிலை குறியீடு (status code) 200 ஆக இருந்ததாலும், அந்த அழைப்பு வெற்றிகரமாக முடிந்தது என்று காட்டுகிறது. இதனால் அந்த மாயத்தோற்றம் (hallucination) கண்ணுக்குத் தெரியாமல் போகிறது, பயனருக்குத் தவறான பதில் கிடைப்பது மட்டுமே அதன் ஒரே அறிகுறியாக உள்ளது.
ஒரு கருப்புப் பெட்டியை (black box) வாசிக்கக்கூடிய மரக் கட்டமைப்பாக மாற்றுதல்
நம்பகமான பிழைத்திருத்தத்திற்கான (debugging) முதல் படி, முகவரை ஒரு ஒற்றை அழைப்பாகக் கருதுவதை நிறுத்திவிட்டு, அதன் ஒவ்வொரு உள் செயல்பாட்டையும் ஒரு 'trace table'-இல் தனித்தனி வரிசைகளாகக் காட்சிப்படுத்துவதாகும். ஒரு வழக்கமான செயல்முறை பின்வருமாறு பிரிக்கப்படுகிறது:
- முகவரின் முதன்மை அழைப்பு (top-level agent invocation)
- தொடர்புடைய ஆவணங்களைப் பெறும் தகவல் தேடல் படி (retrieval step)
- பெறப்பட்ட தரவைச் செயலாக்கும் ஒவ்வொரு மொழி மாதிரி அனுமானமும் (language-model inference)
- ஒவ்வொரு கருவி அழைப்பும் (எ.கா., தரவுத்தளத் தேடல், API கோரிக்கை)
- உண்மைத்தன்மை அல்லது கொள்கை இணக்கத்தை உறுதிப்படுத்தும் பாதுகாப்புச் சோதனைகள் (guard-rail checks)
ஒவ்வொரு வரிசையும் நேர முத்திரை (timestamp), வெற்றித் தகவல் (success flag) மற்றும் அந்தப் படி வழியாகச் சென்ற தரவுப் பகுதி (payload) ஆகியவற்றைப் பதிவு செய்கிறது. இந்த அமைப்பின் மூலம், செயல்பாட்டை இறுதி வெளியீட்டை வைத்து ஊகிப்பதற்குப் பதிலாக, வரிசை வாரியாக ஆய்வு செய்யக்கூடிய ஒரு மரக் கட்டமைப்பாக மாற்ற முடியும்.
தப்பிச் சென்ற பிழை
தவறான ஆதரவுத் தொடர்பில், அந்த 'trace' இவ்வாறு இருந்தது:
- தகவல் தேடல் (Retrieval) நடந்தது, ஆனால் எந்த ஆவணங்களையும் வழங்கவில்லை.
- அடுத்த படிநிலை இருந்தபோதிலும் தொடர்ந்தது, மாதிரியிடம் காலியான சூழலை (empty context) வழங்கியது.
- மாதிரி, விடுபட்ட தகவல்களைக் கற்பனையான வழிமுறைகளைக் கொண்டு நிரப்பி ஒரு பதிலை உருவாக்கியது.
- குழாய் அமைப்பு (pipeline) எந்தத் தவறுக்கும் (exception) உள்ளாகாததால், அமைப்பு 200 என்ற பதிலைத் தந்தது.
இந்த மாயத்தோற்றம் மொழி மாதிரியில் இருந்த குறைபாடு அல்ல; அது தகவல் தேடல் மற்றும் உருவாக்கும் நிலைகளுக்கு இடையே இருந்த பாதுகாப்பு வழிமுறை (guard-rail) விடுபட்டதே ஆகும். பதிலைத் தாங்குவதற்குத் தேவையான அடிப்படைத் தகவல்கள் இல்லாதபோதும் முகவர் பதிலளித்தார்.
மாயத்தோற்றங்களைத் தடுக்கும் எளிய பாதுகாப்பு வழிமுறைகள் (guard-rails)
இரண்டு குறிப்பிட்ட மாற்றங்கள் இந்தப் பிரச்சனையை நீக்கின:
- காலியான தேடலில் நிறுத்தவும் (Abort on empty retrieval) – ஆவணக் களஞ்சியம் எதையும் வழங்கவில்லை என்றால், முகவர் பதிலுருவாக்கத்திற்குச் செல்வதற்குப் பதிலாக, "உங்களுக்குத் தேவையான தகவலை என்னால் கண்டறிய முடியவில்லை" என்று பதிலளிக்க வேண்டும்.
- அடிப்படைத் தரச் சரிபார்ப்பு (Grounding check) – மாதிரி ஒரு பதிலை உருவாக்கிய பிறகு, அதில் உள்ள ஒவ்வொரு உண்மைத் தகவலும் பெறப்பட்ட உள்ளடக்கத்தில் உள்ளதா என்பதைச் சரிபார்க்கவும். சரிபார்ப்பு தோல்வியடைந்தால், அந்தப் பதியை நிராகரித்து, "பதிலளிக்க முடியாது" என்ற பதிலுக்கு மாறவும்.
வேகமான பிழைத்திருத்தத்திற்கான நடைமுறைப் பணிப்பாய்வு (workflow)
- ஒவ்வொரு உள் அழைப்பையும் கண்காணிக்கவும் (Trace every internal call) – ஒவ்வொரு தகவல் தேடல், மாதிரி அனுமானம் மற்றும் கருவி பயன்பாடு ஆகியவற்றையும் ஒரு நிரந்தரப் பதிவில் (persistent log) ஒரு வரிசையாக எழுதும்படி முகவரை வடிவமைக்கவும்.
- தோல்வியடைந்த செயல்பாடுகளைச் சேமிக்கவும் (Preserve failed runs) – பயனர் தவறானது என்று புகாரளிக்கும் எந்தவொரு தொடர்பின் முழுமையான 'trace'-ஐயும் சேமிக்கவும். சேமிப்பகத்தைக் குறைக்க அவற்றை நீக்குவது, பிழைகளைக் கண்டறியத் தேவையான தரவை மறைத்துவிடும்.
- பதிப்புகளின் தகவலுடன் அடையாளமிடுங்கள் (Tag runs with version information) – ஒவ்வொரு trace வரிசையிலும் வெளியீட்டு அடையாள எண் (release identifier) மற்றும் ஏதேனும் அம்சம் சார்ந்த நிலையை (feature-flag state) சேர்க்கவும். இது ஒரு புதிய பிழையை சமீபத்திய குறியீடு மாற்றத்துடன் தொடர்புபடுத்த உதவும்.
- வேகத்தை மட்டுமல்ல, தரத்தையும் மதிப்பிடவும் (Score quality, not just speed) – பதில் அறிவுறுத்தல்களை எவ்வளவு சிறப்பாகப் பின்பற்றுகிறது மற்றும் பெறப்பட்ட உள்ளடக்கத்துடன் எவ்வளவு உண்மையாக உள்ளது என்பதை அளவிடும் அளவீடுகளைச் சேர்க்கவும். பதில்கள் தவறாக இருந்தால், அதிக வெளியீட்டு வேகம் (high throughput) பெரிய அளவில் உதவாது.
- தோல்விகளைத் தினமும் ஆய்வு செய்யவும் (Review failures daily) – சேமிக்கப்பட்ட தோல்விகளைத் தொடர்ந்து ஆய்வு செய்வதன் மூலம், அவை பல பயனர்களைப் பாதிப்பதற்கு முன்பே குறிப்பிட்ட வடிவங்களைக் (எ.கா., ஒரு குறிப்பிட்ட வகை வினவல் தொடர்ந்து காலியான முடிவுகளைத் தருகிறது) கண்டறிய முடியும்.
"பச்சை நிறக் குறியீட்டை" (green) "சரிபார்க்கப்பட்டது" (verified) என மாற்றுவதன் மூலம், குழுக்கள் மாயத்தோற்றங்களை முன்கூட்டியே கண்டறிந்து பயனர் அனுபவத்தை நம்பகமானதாக வைத்திருக்க முடியும்.
உள் தோல்விகளைப் புறக்கணிப்பதன் விலை
டேஷ்போர்டுகள் HTTP நிலையில் வெற்றியை மட்டுமே தெரிவிக்கும்போது, நிறுவனங்கள் நம்பகமானதாகத் தோன்றும் ஆனால் அடிக்கடி தவறான வழிகாட்டுதல்களை வழங்கும் முகவர்களைப் பயன்படுத்துகின்றன.
அடுத்து கவனிக்க வேண்டியவை
அவை வழக்கமானதாக மாறும் வரை, ஒவ்வொரு உள் செயல்பாட்டையும் கண்காணிக்கக்கூடியதாகக் கருதுவதும், ஆதாரங்கள் இல்லாதபோது உடனடியாகத் தோல்வியடைவதே (fail fast) பாதுகாப்பான அணுகுமுறையாகும்.
முக்கியக் கருத்து: ஒரு பச்சை நிற டேஷ்போர்டு உங்கள் அடிப்படை கட்டமைப்பு சரியாக இயங்குவதைக் காட்டலாம்; ஆனால் பதில் சரியானது என்பதற்கு அது உத்தரவாதம் அளிக்காது. ஒவ்வொரு தரவுத் தேடல் (retrieval), மாடல் அழைப்பு (model call) மற்றும் பாதுகாப்புச் சரிபார்ப்பு (guard-rail check) ஆகியவற்றைக் கண்காணிப்பதன் மூலம், மறைந்திருக்கும் மாயத்தோற்றங்களை (hallucinations) பயனரைச் சென்றடைவதற்கு முன்பே சரிசெய்யக்கூடிய கண்ணுக்குத் தெரியும் தோல்விகளாக நீங்கள் மாற்றுகிறீர்கள்.