தானியங்கி பணிப்பாய்வுகளில் LLM மின்னஞ்சல்களைத் தனிமைப்படுத்துதல்

ஒரு LLM ஏஜென்ட் மின்னஞ்சல்களை அனுப்பத் தொடங்கும்போது அல்லது டிக்கெட்டுகளை (tickets) அங்கீகரிக்கத் தொடங்கும்போது, சிக்கல் மாறுகிறது. உங்கள் ப்ராம்ப்ட் (prompt) வேலை செய்கிறதா இல்லையா என்பது மட்டும் இனி முக்கியமல்ல. இப்போது, உங்கள் அமைப்பு மூன்று அடுக்குகளைச் சார்ந்துள்ளது: முடிவு (decision), செயல்படுத்துதல் (execution), மற்றும் சரிபார்த்தல் (verification).

இந்த அடுக்குகளை நீங்கள் ஒன்றாகக் கலந்தால், ஏஜென்ட் உண்மையில் என்ன செய்தது என்பதைப் புரிந்துகொள்ள உங்கள் குழுவினர் சிரமப்படுவார்கள்.

மின்னஞ்சல் படிநிலை பெரும்பாலும் ஒரு பணிப்பாய்வின் (workflow) முடிவைப் போலத் தோன்றும். ஆனால் உண்மையில், தோல்விகள் முதலில் வெளிப்படும் இடம் இதுதான். ஒரு ஏஜென்ட் ஒரு கோரிக்கையைச் சரியாக வகைப்படுத்தலாம், ஆனால் அதைத் தவறான நபருக்கு அனுப்பலாம் அல்லது காலாவதியான இணைப்பைப் (link) பயன்படுத்தலாம். நீங்கள் சோதனைகளையும் (tests) தடயங்களையும் (traces) தனிமைப்படுத்த வேண்டும்.

ஒரு நிலையான வடிவமைப்பு (stable design) புத்திசாலித்தனத்தை (intelligence) ஒரே நேரத்தில் சோதிக்க முயற்சிப்பதில்லை. அதற்குப் பதிலாக, உங்கள் அமைப்பைச் சிறிய ஒப்பந்தங்களாகப் பிரிக்கவும்:

• உள்ளீட்டு ஒப்பந்தம் (Input Contract): ஏஜென்ட் பயன்படுத்தும் தரவு மற்றும் அது கோரக்கூடிய செயல்கள் என்ன என்பதை வரையறுக்கவும்.
• செயல்பாட்டு ஒப்பந்தம் (Execution Contract): ஒரு செயல் எவ்வாறு ஒரு குறிப்பிட்ட மின்னஞ்சலாக மாறுகிறது என்பதை வரையறுக்கவும்.
• கண்காணிப்பு ஒப்பந்தம் (Observability Contract): லாக்ஸ்கள் (logs), பெறப்பட்ட செய்திகள் மற்றும் இறுதி அமைப்பின் நிலையை (system state) இணைக்கவும்.

மின்னஞ்சல் தர்க்கத்தை (logic) சுதந்திரமான ப்ராம்ப்ட்டிலிருந்து (free prompt) விலக்கி வைக்கவும். LLM "send_followup_email" போன்ற ஒரு செயலை பரிந்துரைக்கலாம். இருப்பினும், ஹெடர்கள் (headers), பெறுநர்கள் (recipients) அல்லது மீண்டும் முயற்சிக்கும் கொள்கைகளை (retry policies) மாடல் தீர்மானிக்கக் கூடாது. இந்த மாற்றங்களுக்குத் தீர்மானிக்கப்பட்ட குறியீட்டை (deterministic code) பயன்படுத்தவும்.

இந்த அணுகுமுறை செயல்பாட்டு அபாயத்தைக் (operational risk) குறைக்கிறது. LLM பரிந்துரைக்கிறது, அமைப்பு சரிபார்க்கிறது, மற்றும் செயல்படுத்துபவர் (executor) அனுப்புகிறார்.

தெளிவான பார்வைத்திறனைப் பராமரிக்க, இந்த நான்கு சமிக்ஞைகளைக் (signals) கண்காணிக்கவும்:

• ஏஜென்ட் எடுத்த முடிவு மற்றும் பயன்படுத்தப்பட்ட சூழல் (context).
• மின்னஞ்சல் செயல்படுத்துபவருக்கு அனுப்பப்பட்ட இறுதி கட்டளை.
• தனிமைப்படுத்தப்பட்ட இன்பாக்ஸில் (isolated inbox) பெறப்பட்ட செய்தி.
• ஒரு இணைப்பைக் கிளிக் செய்த பிறகு அல்லது ஒரு செயலை உறுதிப்படுத்திய பிறகு ஏற்படும் இறுதி விளைவு.

ஆரம்ப நிகழ்விலிருந்து இறுதி கிளிக் வரை ஒரு பொதுவான trace_id-ஐப் பயன்படுத்தவும். இது பிழைகளை விரைவாகக் கண்டறிய உதவும். தோல்வி மாடலிலா, கருவி கொள்கையிலா (tool policy) அல்லது பணியாளரிடமா (worker) நடந்தது என்பதை நீங்கள் அறியலாம்.

சிறந்த தானியங்கி முறைக்காக இந்தச் சரிபார்ப்புப் பட்டியலைப் (checklist) பின்பற்றவும்:

• ஒவ்வொரு செயல்பாட்டிற்கும் அதன் சொந்த trace_id உள்ளது.
• LLM ஒரு செல்லுபடியாகும் ஸ்கீமாவிற்குள் (valid schema) மட்டுமே செயல்களைக் கோருகிறது.
• மின்னஞ்சல் செயல்படுத்துபவர் பெறுநர் மற்றும் டெம்ப்ளேட்டை (template) மீண்டும் சரிபார்க்கிறார்.
• ஒவ்வொரு சோதனைச் சூழலும் (test scenario) அதன் சொந்த தனிமைப்படுத்தப்பட்ட இன்பாக்ஸைப் பயன்படுத்துகிறது.
• இறுதி கிளிக் எதிர்பார்க்கப்பட்ட நிலை மாற்றத்தை (state change) உறுதிப்படுத்துகிறது.
• லாக்ஸ்கள் (logs) யூகிக்காமல் ஒரு வழக்கை உங்களால் பின்தொடர அனுமதிக்கின்றன.

இந்தப் படிநிலைகளைப் பிரிப்பது சற்று கூடுதல் வேலையைத் தரும். ஆனால் இது உங்களுக்கு ஒரு மதிப்புமிக்க விஷயத்தைக் கொடுக்கிறது: ஏன் ஒரு மின்னஞ்சல் அனுப்பப்பட்டது அல்லது ஏன் அது தோல்வியடைந்தது என்பதை விளக்கும் திறன்.

Source: https://dev.to/silviutech/como-aislar-emails-de-agentes-llm-en-flujos-automatizados-sin-perder-trazabilidad-26ac

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