AI has changed how we build software, but it has not changed a basic truth about machines. They drown in noise just like

AI மென்பொருளை நாம் உருவாக்கும் முறையை மாற்றியுள்ளது, ஆனால் இயந்திரங்களைப் பற்றிய ஒரு அடிப்படை உண்மையை அது மாற்றவில்லை. நாங்களைப் போலவே அவையும் இரைச்சலில் (noise) மூழ்கிவிடுகின்றன. பொறியாளர்கள் முதன்முதலில் AI-உதவி பெறும் பிழைத்திருத்தத்தை (debugging) சோதிக்கும்போது, அவர்களின் உள்ளுணர்வு எளிமையானது: மாதிரியிடம் (model) அனைத்தையும் கொடுத்துவிடுவது. மூலப் பதிவுகள் (Raw logs), தடயங்கள் (traces) மற்றும் அளவீடுகள் (metrics) அனைத்தும் சூழல் சாளரத்தில் (context window) கொட்டப்படுகின்றன. இதன் முடிவு நுண்ணறிவு அல்ல, தோல்வி மட்டுமே. அளவு மிக அதிகமாக உள்ளது. சிக்னல் (signal) சிதைந்துவிடுகிறது. அளவீடுகள் ஒரு கருவியிலும், தடயங்கள் வேறொரு கருவியிலும் உள்ளன, இதனால் மாதிரியால் அவற்றை ஒன்றிணைத்து ஒரு தெளிவான கதையாக மாற்ற முடிவதில்லை. AI உங்கள் அமைப்புகளைக் கண்காணிக்க உதவுவதற்கு முன், நீங்களே அவற்றை உற்றுநோக்க வேண்டும். முதலில் நீங்கள் தரவைச் செதுக்க வேண்டும்.

ஏன் மூலப் பதிவுகள் (Raw Logs) AI குழாய்களை (pipelines) உடைக்கின்றன

நவீன அமைப்புகள் மனிதர்களால் படிக்க முடியாத வேகத்தில் தொலைதூரத் தரவுகளை (telemetry) உருவாக்குகின்றன. இது அவற்றை செயற்கை நுண்ணறிவுக்குப் பொருத்தமானதாக மாற்ற வேண்டும். ஆனால் அப்படி இல்லை. ஒரு பெரிய மொழி மாதிரியின் (LLM) சூழல் சாளரம் வளர்ந்து வந்தாலும், அது இன்னும் ஒரு வரையறுக்கப்பட்ட குழாயாகவே உள்ளது. வடிகட்டப்படாத உற்பத்திப் பதிவுகளை (production logs) அதில் நிரப்பினால், உண்மையான முறிவை (outage) மறைத்துவிட்டு, cron job heartbeats மற்றும் health-check இரைச்சல்களுக்காக நீங்கள் டோக்கன்களை (tokens) வீணடிக்கிறீர்கள். அதைவிட மோசமாக, மூலப் பதிவுகளில் தொடர்புகள் (relationships) இல்லை. மதியம் 2:00 மணிக்கு ஏற்படும் தாமதத்தின் அதிகரிப்பும் (latency spike), அதே நேரத்தில் பதிவில் வரும் தரவுத்தள இணைப்புப் பிழையும் (database connection error) தெளிவாகத் தொடர்புடையவை, ஆனால் யாராவது முன்னரே அந்தத் தொடர்பை வடிவமைக்கவில்லை என்றால், AI யூகிக்க வேண்டியிருக்கும். யூகிக்கப்பது செலவுமிக்கது, மெதுவானது மற்றும் பெரும்பாலும் தவறானது.

இதற்குத் தீர்வு கட்டமைப்பு சார்ந்தது (architectural), அல்காரிதம் சார்ந்தது அல்ல. நீங்கள் ஒரு மாதிரியைத் தூண்டுவதற்கு (prompt) முன்பே, எதைச் சேகரிக்க வேண்டும், அதை எப்படி வடிவமைக்க வேண்டும் மற்றும் எந்தப் பின்னணி (backend) எந்தக் கேள்விக்கு விடையளிக்கும் என்பதைத் தீர்மானிக்க வேண்டும்.

கண்காணிப்பின் நான்கு அச்சுகள் (Four Axes of Monitoring)

airCloset-இல், பொறியியல் குழு கண்காணிப்பை (observability) ஒரு ஒற்றை நீர்வீழ்ச்சியாகக் கருதுவதை நிறுத்திவிட்டது. அவர்கள் கண்காணிப்பை நான்கு தனித்துவமான அச்சுகளாகப் பிரித்தனர். ஒவ்வொன்றும் ஒரு குறிப்பிட்ட வடிவத்தைக் கொண்டுள்ளது மற்றும் ஒரு குறிப்பிட்ட கேள்விக்கு விடையளிக்கிறது.

• Application: பதிவுகள் மற்றும் தடயங்கள் "இப்போது என்ன நடக்கிறது?" என்ற கேள்விக்குப் பதிலளிக்கின்றன.
• Infrastructure: அளவீடுகள் "எங்களிடம் போதுமான ஆதாரங்கள் உள்ளனவா?" என்ற கேள்விக்குப் பதிலளிக்கின்றன.
• CI: பதிவுகள் மற்றும் எச்சரிக்கைகள் "எது எப்போது உடைந்தது?" என்ற கேள்விக்குப் பதிலளிக்கின்றன.
• LLM: அளவீடுகள் மற்றும் கட்டமைக்கப்பட்ட பதிவுகள் "நாம் எவ்வளவு செலவு செய்கிறோம்?" என்ற கேள்விக்குப் பதிலளிக்கின்றன.

இந்தத் தனிப்பயனாக்கம் முக்கியமானது, ஏனெனில் நிகழ்நேர தாமத வரைபடத்திற்கு (real-time latency graph) ஏற்ற வடிவம், ஒரு பிந்தைய செலவுப் பகுப்பாய்விற்கு (post-hoc cost analysis) பயனற்றது. நான்கு களங்களுக்கும் ஒரே மாதிரியான திட்டத்தை (schema) திணிப்பது, AI உதவியை பயனற்றதாக்கும் இரைச்சலையே உருவாக்குகிறது.

CI கண்காணிப்பு: இழுங்கள் (Pull), தள்ளாதீர்கள் (Push)

தொடர்ச்சியான ஒருங்கிணைப்பு (Continuous integration) என்பது குறியீடு யதார்த்தத்தைச் சந்திக்கும் இடமாகும். ஒரு தொகுப்பு (build) தோல்வியடையும் போது, டெவலப்பர்களுக்கு அந்தத் தகவல் விரைவாகத் தேவைப்படுகிறது. ஒரு CI runner இயங்கும்போது, பதிவுகளை நேரடியாக உங்கள் கண்காணிப்புப் பின்னணிக்குத் தள்ளுவது (push) ஒரு எளிமையான அணுகுமுறையாக இருக்கலாம். இது திறமையானதாகத் தோன்றலாம், ஆனால் உண்மையில் இது ஆபத்தானது.

airCloset-இல், அவர்கள் இந்த மாதிரியை மாற்றினார்கள். CI runner கண்காணிப்புத் தொகுப்பை (observability stack) தொடாது. GitHub Actions workflow முடிந்த பிறகு, அவர்கள் GitHub API-லிருந்து பதிவுகளை இழுத்து (pull), அவற்றை Loki-க்குள் செலுத்துகிறார்கள் (ingest).

இந்த இழுக்கும் கட்டமைப்பு (pull architecture) மூன்று உறுதியான நன்மைகளை வழங்குகிறது.

தனிமைப்படுத்துதல் (Decoupling). தரவுச் செலுத்தும் குழாயில் (ingestion pipeline) தடங்கல் ஏற்பட்டாலோ அல்லது Grafana-வை அணுக முடியாவிட்டாலோ, சோதனை இயக்கம் (test run) பாதிக்கப்படாது. தொகுப்பு அதன் சொந்தத் தகுதியின் அடிப்படையில் வெற்றியடையும் அல்லது தோல்வியடையும். கண்காணிப்புத் தோல்வி ஒரு பதிவை (deployment) ஒருபோதும் நிறுத்தக்கூடாது.

பாதுகாப்பு (Security). CI workflow-க்கு ஒருபோதும் Grafana API key தேவையில்லை. சோதனை குறியீடுகள் (test code) தொடக்கூடாத ரகசியத் தகவல்களைத் தொடுவதில் பெயர் பெற்றவை; அந்தத் தொடர்பை நீக்குவது, ஒரு சார்பு (dependency) பாதிக்கப்பட்டால் ஏற்படும் பாதிப்பின் பரவலைக் (blast radius) குறைக்கிறது.

குறுக்கு-வினவல் (Cross-querying). CI முடிந்ததும்...