நான் ஒரு AI பாதுகாப்பு ஸ்கேனரை உருவாக்கினேன் — பிறகு எனது சொந்தக் கண்டறிதலில் ஒரு பிழையைக் கண்டறிந்தேன்
Prompt injection என்பது LLM பயன்பாடுகளுக்கு ஒரு முக்கியமான பாதுகாப்பு அபாயமாகும். ஒரு மாடலின் அசல் வழிமுறைகளைப் புறக்கணிக்கச் சொல்லும் உரையை நீங்கள் அதற்கு வழங்குகிறீர்கள். சில நேரங்களில், அந்த மாடல் அதைக் கேட்டுவிடுகிறது.
இதைச் சோதிக்க நான் AgentProbe-ஐ உருவாக்கினேன். இது jailbreaks மற்றும் data extraction போன்ற 8 வகைகளில் 49 தாக்குதல் ப்ராம்ப்ட்களை (attack prompts) அனுப்புகிறது. ஒரு மாடல் எவ்வளவு அடிக்கடி தோல்வியடைகிறது என்பதை இது அறிக்கையிடுகிறது.
உண்மையான பாடம் அந்த ஸ்கேனர் அல்ல. அது எனது கண்டறிதல் குறியீட்டில் (detection code) இருந்த ஒரு பிழை.
கடினமான பகுதி தாக்குதல் நடத்துவது அல்ல. கடினமான பகுதி கண்டறிவதுதான்.
ஒரு மாடல் உண்மையில் ஒரு தாக்குதலுக்கு இணங்கிவிட்டதா என்பதை நீங்கள் எப்படி அறிவீர்கள்? Keyword matching என்பது எளிதான வழி. "I cannot help" போன்ற மறுப்புத் தொடர்கள் அல்லது "developer mode" போன்ற இணக்கத் தொடர்களை நீங்கள் தேடுவீர்கள்.
ஆனால் மாடல்கள் "hedge-then-comply" (தவிர்த்துவிட்டுப் பிறகு இணங்குதல்) முறையைப் பயன்படுத்துகின்றன. அவை "I cannot help with that" என்று சொல்லும், ஆனால் பிறகு அந்தத் தடைசெய்யப்பட்ட தகவலையும் வழங்கிவிடும். மறுப்புத் தொடர் அங்கு இருப்பதால், keyword matching இங்கே தோல்வியடைகிறது.
இதைச் சரிசெய்ய, நான் "LLM-as-judge" முறையைப் பயன்படுத்தினேன். இலக்கு மாடல் உண்மையில் இணங்கிவிட்டதா என்பதைத் தீர்மானிக்க, அந்த உரையாடலை ஒரு வலிமையான மாடலுக்கு அனுப்பினேன். முதலில் மலிவான keyword சோதனைகளைப் பயன்படுத்தவும், keyword சோதனை நிச்சயமற்றதாக இருக்கும்போது மட்டுமே விலையுயர்ந்த judge முறையைப் பயன்படுத்தவும் நான் திட்டமிட்டிருந்தேன்.
அப்போதுதான் எனது பிழையைக் கண்டறிந்தேன்.
எனது keyword detector ஒரு "hedge-then-comply" முறையைக் கண்டறியும்போது 1 என்ற நம்பிக்கைப் புள்ளியை (confidence score) வழங்கியது. இருப்பினும், எனது குறியீடு (code) நம்பிக்கைப் புள்ளி 2 அல்லது அதற்கு அதிகமாக இருந்தால் மட்டுமே keyword நிலையை நம்பியிருந்தது.
இதன் பொருள் எனது "மலிவான" கண்டறிவி (detector) உண்மையில் ஒரு முடிவையும் எடுக்கவில்லை என்பதாகும். ஒவ்வொரு வழக்கையும் விலையுயர்ந்த judge முறைக்கே அனுப்ப வேண்டியிருந்தது. எனது இலவசக் கருத்தே அதைச் செய்திருக்க வேண்டிய இடத்தில், ஒவ்வொரு வழக்கிற்கும் நான் judge-க்காகப் பணம் செலுத்தி வந்தேன்.
மற்ற LLM-களை மதிப்பிடுவதற்கு LLM-களைப் பயன்படுத்துவது குறித்து இந்தத் தவறு எனக்கு மூன்று பாடங்களைக் கற்பித்தது:
- judge இலக்கை விட புத்திசாலியாக இருக்க வேண்டும். judge மற்றும் இலக்கு ஆகிய இரண்டும் ஒரே அளவிலானதாக இருந்தால், அவை ஒரே மாதிரியான குறைகளைக் (blind spots) கொண்டிருக்கும்.
- துல்லியம் (Accuracy) ஏமாற்றலாம். பெரும்பாலான மாடல்கள் மறுத்தால், எப்போதும் "refused" என்று சொல்லும் ஒரு judge துல்லியமாகத் தோன்றும், ஆனால் அது எதையும் கற்றுக்கொள்ளாது. அதிர்ஷ்டத்தைக் கணக்கில் கொள்ள Cohen's kappa போன்ற அளவீடுகளைப் பயன்படுத்தவும்.
- judge நிலையானதாக இருக்க வேண்டும். ஒரே சோதனையை ஐந்து முறை செய்யவும். judge தனது முடிவை மாற்றினால், முடிவு தெளிவற்றதாக உள்ளது என்று அர்த்தம், அதற்கு மனிதக் கண்காணிப்பு தேவை.
நீங்கள் LLM-களைக் கொண்டு உருவாக்குகிறீர்கள் என்றால், இந்த விஷயங்களை நினைவில் கொள்ளுங்கள்:
- இணக்கத்தைக் கண்டறிவது அதை உருவாக்குவதை விடக் கடினம்.
- முதல் வாக்கியத்தில் மறுத்துவிட்டு, இரண்டாவது வாக்கியத்தில் இணங்கும் மாடல்களைக் கவனியுங்கள்.
- ஒரு LLM judge-ஐக் கண்மூடித்தனமாக நம்பாதீர்கள். அதன் நம்பகத்தன்மையை அளவிடுங்கள்.
- உங்கள் பிழைகளைப் பகிர்ந்து கொள்ளுங்கள். ஒரு குறையற்ற தொடக்கத்தை விட, எனது சொந்தக் குறையைக் கண்டறிந்ததே எனக்கு அதிகம் கற்பித்தது.
Source: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a
Optional learning community: https://t.me/GyaanSetuAi
