உங்கள் லாகுகளைச் (logs) சேமிக்காத ஒரு AI Incident Copilot-ஐ நான் உருவாக்கினேன்

ஒவ்வொரு பொறியாளரும் இதைத்தான் செய்கிறார்கள்.

ப்ரொடக்ஷனில் (production) ஏதோ ஒன்று உடைந்துவிடுகிறது. நீங்கள் லாகுகளை எடுக்கிறீர்கள். அவற்றை ஒரு AI சாட்டில் பேஸ்ட் செய்கிறீர்கள். உதவி கேட்கிறீர்கள். AI ஒரு நல்ல பதிலை அளிக்கிறது.

பெரும்பாலான மக்கள் இது இயல்பானது என்று நினைக்கிறார்கள். ஆனால் அது இல்லை. இது ஒரு மிகப்பெரிய பாதுகாப்பு அபாயம் (security risk).

ப்ரொடக்ஷன் லாகுகளில் முக்கியமான தரவுகள் (sensitive data) இருக்கும். அவற்றில் வாடிக்கையாளர் ஐடிக்கள் (customer IDs), அங்கீகாரப் பிழைகள் (auth errors), stack traces மற்றும் API பதில்கள் இருக்கும். சில நேரங்களில் அவற்றில் ரகசியத் தகவல்களும் (secrets) இருக்கலாம்.

தற்போது பிழைகளைத் திருத்தும் (debug) முறை என்பது, தனிப்பட்ட தரவுகளை ஒரு சாட் பாக்ஸில் பேஸ்ட் செய்துவிட்டு, எல்லாம் சரியாக நடக்கும் என்று நம்புவதாகும். தரவு கசிவு அபாயம் இல்லாமல் எனக்கு AI உதவி தேவைப்பட்டது.

எனவே நான் ஒரு AI incident copilot-ஐ உருவாக்கினேன். நான் ஒரு விதியைப் பின்பற்றினேன்: உங்கள் தரவைச் சேமிக்க மறுத்தாலும், இந்த ஆப் பயனுள்ளதாக இருக்க வேண்டும்.

இந்த ஆப் ஒரு AI war room போலச் செயல்படுகிறது. நீங்கள் லாகுகள், ட்ரேஸ்கள் அல்லது பிழைகளைப் பேஸ்ட் செய்யலாம். இது உங்களுக்குப் பின்வருவனவற்றில் உதவுகிறது:

• மாற்றங்களைச் சுருக்கிக் கூற (Summarize changes) • தோல்விப் புள்ளிகளைக் கண்டறிய (Find failure points) • தேவையற்ற லாகுகளைக் குழுவாக்க (Group noisy logs) • stack traces-களை விளக்க (Explain stack traces) • தணிப்பு நடவடிக்கைகளைப் பரிந்துரைக்க (Suggest mitigation steps) • postmortem காலவரிசைகளைத் தயாரிக்க (Draft postmortem timelines)

பெரும்பாலான டெவலப்பர்கள் இத்தகைய ஆப்ஸ்களை உருவாக்குகிறார்கள்: Input → Backend → Database → LLM → Database → UI.

இது ஒரு ஆபத்தான முறை. இப்போது உங்கள் ஆப் ஒவ்வொரு ப்ரொடக்ஷன் தோல்வியின் ஆவணத்தையும் (archive) வைத்திருக்கிறது. தரவு மீறல்கள் (breaches), பேக்கப்கள் (backups) மற்றும் அட்மின் அணுகல் (admin access) ஆகியவற்றைப் பற்றி நீங்கள் கவலைப்பட வேண்டியிருக்கும்.

எனக்கு ஒரு தனிப்பட்ட ஸ்க்ராட்ச்பேடு (private scratchpad) தேவைப்பட்டது, ஒரு SaaS டேஷ்போர்டு அல்ல.

எனது வடிவமைப்பு விதி: தரவைச் செயலாக்குங்கள் (Process), ஆனால் அதைச் சேகரிக்காதீர்கள்.

இதன் கட்டமைப்பு (architecture) வித்தியாசமாகச் செயல்படுகிறது:

  • சாட் ஹிஸ்டரி (Chat history) உங்கள் பிரவுசரிலேயே இருக்கும்.
  • பேக்எண்ட் (Backend) ப்ராம்ப்ட்களைச் சேமிக்காது.
  • பேக்எண்ட் மாடல் பதில்களைச் சேமிக்காது.
  • ஒவ்வொரு கோரிக்கையும் (request) தற்காலிகமானது.

இந்தத் தனியுரிமை மாதிரிக்கு (privacy model) ஏற்றது என்பதால் நான் Icelake AI API-ஐப் பயன்படுத்தினேன். சர்வர் மூன்று படிகளைச் செய்கிறது:

  1. முக்கியமான மதிப்புகளை நீக்குகிறது (Redacts sensitive values).
  2. சுருக்கப்பட்ட ஒரு ப்ராம்ப்ட்டை API-க்கு அனுப்புகிறது.
  3. கோரிக்கையைச் சேமிக்காமல் பதிலை வழங்குகிறது.

Redaction உதவுகிறது, ஆனால் அது ஒரு மாயக் கேடயம் அல்ல. அது அனைத்தையும் கண்டறிந்துவிடாது. கோரிக்கை முடிந்த பிறகு நீங்கள் எவ்வளவு தரவை வைத்திருக்கிறீர்கள் என்பதைக் குறைப்பதே உண்மையான வெற்றி.

Redaction அழைப்பின் போது அபாயத்தைக் குறைக்கிறது. லாகுகளைச் சேமிக்காமல் இருப்பது அபாயத்தை என்றென்றும் குறைக்கிறது.

பெரும்பாலான AI ஆப்ஸ்கள் கேட்கின்றன: நாங்கள் எதைச் சேகரிக்கலாம்? இந்த ஆப் கேட்கிறது: எதைத் தவிர்க்கலாம்?

இந்த அணுகுமுறை தயாரிப்பைச் சிறப்பாக்குகிறது. பயனர்கள் பாதுகாப்பாக உணர்கிறார்கள். உண்மையான இன்கிடென்ட்களின் (incidents) போது இதைப் பயன்படுத்த அவர்கள் தயாராக இருக்கிறார்கள், ஏனெனில் அவர்களின் தகவல்கள் எனது டேட்டாபேஸில் சேமிக்கப்படுவதில்லை என்பது அவர்களுக்குத் தெரியும்.

அடுத்த தலைமுறை AI ஆப்ஸ்கள் அவை எவ்வளவு புத்திசாலித்தனமானவை என்பதில் மட்டும் போட்டியிடக் கூடாது. அவை எவ்வளவு கட்டுப்பாட்டுடன் (restraint) செயல்படுகின்றன என்பதிலும் போட்டியிட வேண்டும்.

உங்களையே கேட்டுக்கொள்ளுங்கள்: • எதைச் சேமிக்க நீங்கள் மறுக்கிறீர்கள்? • எதை நீங்களே அணுக முடியாதபடி செய்கிறீர்கள்? • செஷன் (session) முடிந்ததும் எது மறைந்துவிடுகிறது?

AI கருவிகள் அனைத்தையும் நினைவில் கொள்ளாததால்தான் பயனுள்ளதாக இருக்க வேண்டும்.

Source: https://dev.to/bart_holden_0d0cf2aaa0424/i-built-an-ai-incident-copilot-that-does-not-store-your-production-logs-3l0p

Optional learning community: https://t.me/GyaanSetuAi