𝗖𝗼𝗺𝗺𝗼𝗻 𝗣𝗶𝘁𝗳𝗮𝗹𝗹𝘀 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗘𝗺𝗮𝗶𝗹 𝗔𝗴𝗲𝗻𝘁𝘀

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

இந்தத் தோல்விகள் உள்கட்டமைப்பு (infrastructure) மட்டத்தில் நிகழ்கின்றன, உங்கள் LLM ப்ராம்ப்ட் (prompt) காரணமாக அல்ல.

நீங்கள் தொடங்குவதற்கு முன் இந்த ஒன்பது விஷயங்களைச் சரிபார்க்கவும்:

• முடிவில்லாத சுழற்சி (The Infinite Loop) உங்கள் ஏஜென்ட் ஒரு பதிலைப் அனுப்பும்போது webhook இயங்குகிறது. இது மற்றொரு webhook-ஐத் தூண்டுகிறது. இதன் மூலம் ஒரு சுழற்சி உருவாகிறது. தீர்வு: உங்கள் குறியீட்டின் (code) தொடக்கத்திலேயே ஏஜென்ட்டின் மின்னஞ்சல் முகவரியைத் தடையிடுங்கள் (filter). அனுப்பியவர் ஏஜென்ட் என்றால் அந்தச் செயல்பாட்டை நிறுத்திவிடுங்கள்.

• நகல் செய்திகள் (Duplicate Messages) நெட்வொர்க் கோளாறுகள் ஏற்படலாம். உங்கள் endpoint போதுமான வேகத்தில் பதிலளிக்கவில்லை என்றால், சிஸ்டம் அதே அறிவிப்பை மீண்டும் அனுப்பும். தீர்வு: செய்தி ஐடியின் (message ID) மீது ஒரு atomic check-ஐப் பயன்படுத்தவும். ஒவ்வொரு ஐடியையும் ஒருமுறை மட்டுமே செயலாக்குவதை உறுதி செய்ய Redis அல்லது Postgres-ஐப் பயன்படுத்தவும்.

• ரேஸ் கண்டிஷன்ஸ் (Race Conditions) இரண்டு பணியாளர்கள் (workers) ஒரே மில்லி விநாடியில் ஒரே நிகழ்வைச் செயலாக்குகிறார்கள். இங்கே வெறும் deduplication மட்டும் போதாது. தீர்வு: 30 வினாடி வரம்புடன் கூடிய per-thread lock-ஐப் பயன்படுத்தவும். அந்த lock-க்குள் ஏஜென்ட் ஏற்கனவே பதிலளித்துவிட்டதா என்று சரிபார்க்கவும்.

• துண்டிக்கப்பட்ட தரவு (Truncated Data) Webhooks பெரும்பாலும் சுருக்கங்களை மட்டுமே கொண்டு வரும், முழுமையான உள்ளடக்கத்தை அல்ல. பெரிய மின்னஞ்சல்கள் துண்டிக்கப்பட்ட நிகழ்வுகளாக வரக்கூடும். தீர்வு: எப்போதும் ID-யைப் பயன்படுத்தி API-லிருந்து முழு செய்தியையும் பெறவும். உள்ளடக்கத்திற்காக webhook payload-ஐ மட்டும் நம்பியிருக்க வேண்டாம்.

• உடைந்து போன உரையாடல் தொடர்கள் (Broken Threads) ஒரு பதிலைத் தனிச் செய்தியாக அனுப்பும்போது, Gmail அல்லது Outlook-இல் உரையாடல் குழுவாக்கம் (conversation grouping) பாதிக்கப்படும். தீர்வு: ஒவ்வொரு பதிலிலும் reply_to_message_id-ஐ அனுப்பவும். பதில்களை thread_id மூலம் ஒப்பிட்டுப் பார்க்கவும், ஒருபோதும் subject line மூலம் செய்ய வேண்டாம்.

• மனிதத் திருத்தம் (The Human Correction) ஒரு மனிதர் தனது முதல் மின்னஞ்சலுக்குச் சில விநாடிகளிலேயே ஒரு திருத்தப்பட்ட மின்னஞ்சலை அனுப்புகிறார். உங்கள் ஏஜென்ட் இரண்டிற்கும் பதிலளிக்கிறது. தீர்வு: 30 முதல் 60 வினாடிகள் வரை cooldown நேரத்தைப் பயன்படுத்தவும். தொடர்ச்சியான செய்திகளை ஒரே பதிலில் தொகுக்கவும் (batch).

• பதில்களின் புயல் (The Reply Storm) ஒரு லாஜிக் பிழை (logic bug) காரணமாக ஏஜென்ட் ஒரே நேரத்தில் நூற்றுக்கணக்கான மின்னஞ்சல்களை அனுப்பக்கூடும். தீர்வு: ஒவ்வொரு thread-க்கும் ஒரு அனுப்பும் வரம்பை (send budget) நிர்ணயிக்கவும். ஏஜென்ட் 5 நிமிடங்களில் 3 செய்திகளை அனுப்பினால், அதை நிறுத்திவிட்டு ஒரு மனிதருக்குத் தகவல் தெரிவிக்கவும்.

• தேவையற்ற உள்ளீடுகள் (Garbage Input) Spam மற்றும் out-of-office பதில்கள் உங்கள் LLM-ஐத் தூண்டுகின்றன. இதனால் தேவையற்ற inference-களுக்கு நீங்கள் பணம் செலுத்த வேண்டியிருக்கும். தீர்வு: மோசமான மின்னஞ்சல் அனுப்புபவர்களைத் தடுக்க inbox விதிகளைப் பயன்படுத்தவும் அல்லது தானியங்கி மின்னஞ்சல்களை வேறு கோப்புறைக்கு (folder) மாற்றவும்.

• 403 பிழைப் பொறி (The 403 Error Trap) வெளியேறும் விதிகள் (Outbound rules) ஒரு மின்னஞ்சல் அனுப்புவதைத் தடுக்கலாம். இது 403 பிழையைத் தரும். சாதாரண retry logic இந்தத் தவறைத் திரும்பத் திரும்பச் செய்து கொண்டே இருக்கும். தீர்வு: 403-ஐ ஒரு இறுதிப் பிழையாக (terminal error) கருதவும். அதை மீண்டும் முயற்சிக்க வேண்டாம் (retry). உங்களுக்கு 503 கிடைத்தால், நீங்கள் மீண்டும் முயற்சிக்கலாம்.

ஃபில்டர்கள் (filters), லாக்ஸ் (locks) மற்றும் வரம்புகள் (caps) போன்ற சலிப்பூட்டும் தீர்வுகள் தான் ஒரு ஏஜென்ட்டைப் பாதுகாப்பாக வைத்திருக்கின்றன.

மின்னஞ்சல் ஏஜென்ட்களை (Email Agents) உருவாக்கும்போது ஏற்படும் பொதுவான சிக்கல்களும் அவற்றைத் தீர்க்கும் முறைகளும்

மின்னஞ்சல்களைக் கையாளும் ஒரு AI ஏஜென்ட்டை உருவாக்குவது கேட்பதற்கு ஒரு கனவு போலத் தோன்றலாம்—அனைத்து மின்னஞ்சல்களையும் தானாகவே வகைப்படுத்துவது, பதிலளிப்பது மற்றும் அட்டவணைப்படுத்துவது என அனைத்தும் சுலபமாக நடப்பது போலத் தோன்றும். ஆனால், நடைமுறையில் இது ஒரு மிகப்பெரிய சவாலானது.

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

1. சூழல் சாளரத் திணிப்பு (Context Window Overload)

சிக்கல்: மின்னஞ்சல் உரையாடல்கள் (Email threads) பெரும்பாலும் மிக நீளமானவை. ஒரு நீண்ட உரையாடலின் அனைத்துப் பகுதியையும் ஏஜென்ட்டின் சூழல் சாளரத்திற்குள் (Context window) திணிக்கும்போது, இரண்டு முக்கியப் பிரச்சினைகள் ஏற்படும்:

1. செலவு அதிகரிப்பு: அதிகப்படியான டோக்கன்களைப் பயன்படுத்துவதால் செலவு அதிகமாகும்.
2. தகவல் இழப்பு: சூழல் சாளரம் நிரம்பும்போது, ஏஜென்ட் ஆரம்பத்தில் இருந்த முக்கியமான தகவல்களை மறந்துவிடக்கூடும் (Lost in the middle).

தீர்வு:

• சுருக்கம் செய்தல் (Summarization): முழு உரையாடலையும் அனுப்புவதற்குப் பதிலாக, முந்தைய உரையாடல்களின் சுருக்கத்தை மட்டும் ஏஜென்டிடம் வழங்கவும்.
• RAG (Retrieval-Augmented Generation): தேவையான தகவல்களை மட்டும் தேடி எடுத்து (Retrieve) சூழலில் சேர்க்கும் முறையைப் பயன்படுத்தவும்.

2. கருவி அழைப்பில் ஏற்படும் மாயத்தோற்றங்கள் (Hallucinations in Tool Calling)

சிக்கல்: மின்னஞ்சல் ஏஜென்ட்கள் பொதுவாக மின்னஞ்சல் அனுப்ப, தேட அல்லது அட்டவணைப்படுத்த போன்ற கருவிகளைப் (Tools) பயன்படுத்துகின்றன. ஆனால், LLM-கள் சில நேரங்களில் தவறான கருவிகளைத் தேர்ந்தெடுக்கலாம் அல்லது தவறான அளவுருக்களை (Parameters) வழங்கலாம். உதாரணமாக, ஒரு மின்னஞ்சலைத் தயார் செய்ய (draft_email) வேண்டிய இடத்தில், நேரடியாக அனுப்பிவிட (send_email)க்கூடும்.

தீர்வு:

• Few-shot Prompting: ஏஜென்ட் எவ்வாறு கருவிகளைப் பயன்படுத்த வேண்டும் என்பதற்கான சில உதாரணங்களை ப்ராம்ப்ட்டில் (Prompt) வழங்கவும்.
• Structured Output: Pydantic போன்ற நூலகங்களைப் பயன்படுத்தி, ஏஜென்ட் வழங்கும் வெளியீடு ஒரு குறிப்பிட்ட வடிவத்தில் (Schema) இருப்பதை உறுதி செய்யவும்.

3. மனிதத் தலையீடு இல்லாமை (Lack of Human-in-the-loop)

சிக்கல்: முழுக்க முழுக்கத் தானியங்கி முறையில் (Fully autonomous) இயங்கும் ஏஜென்ட்கள் ஆபத்தானவை. ஒரு சிறிய தவறு கூட வாடிக்கையாளருக்குத் தவறான தகவலை அனுப்பவோ அல்லது தவறான நபருக்கு மின்னஞ்சல் அனுப்பவோ வழிவகுக்கும்.

தீர்வு:

• அங்கீகாரப் படிநிலை (Approval Workflow): முக்கியமான செயல்களைச் செய்வதற்கு முன் (உதாரணமாக: மின்னஞ்சல் அனுப்புதல்), ஒரு மனிதரின் ஒப்புதலைப் பெறும் முறையைச் சேர்க்கவும்.
• Draft Mode: ஏஜென்ட் நேரடியாக மின்னஞ்சலை அனுப்பாமல், ஒரு வரைவாக (Draft) மட்டும் சேமித்து வைக்கும்படி வடிவமைக்கவும்.

4. பாதுகாப்பு மற்றும் தனியுரிமை அபாயங்கள் (Security and Privacy Risks)

சிக்கல்: மின்னஞ்சல்களில் தனிநபர் அடையாளம் காணக்கூடிய தகவல்கள் (PII - Personally Identifiable Information) இருக்கும். இந்தத் தகவல்கள் LLM-களுக்கு அனுப்பப்படும்போது, தரவுப் பாதுகாப்பு மற்றும் தனியுரிமைச் சிக்கல்கள் ஏற்படலாம். மேலும், "Prompt Injection" மூலம் ஏஜென்ட் தவறான செயல்களைச் செய்யத் தூண்டப்படவும் வாய்ப்புள்ளது.

தீர்வு:

• PII Masking: மின்னஞ்சல்களை ஏஜென்டிடம் அனுப்புவதற்கு முன், பெயர்கள், தொலைபேசி எண்கள் மற்றும் மின்னஞ்சல் முகவரிகளை மறைக்கும் (Scrubbing) முறையைப் பயன்படுத்தவும்.
• Strict Guardrails: ஏஜென்ட் செய்யக்கூடிய செயல்களுக்குக் கடுமையான கட்டுப்பாடுகளை (Guardrails) விதிக்கவும்.

---

முடிவுரை: மின்னஞ்சல் ஏஜென்ட்களை உருவாக்குவது என்பது வெறும் ப்ராம்ப்ட் இன்ஜினியரிங் மட்டுமல்ல; அது தரவு மேலாண்மை, பாதுகாப்பு மற்றும் பயனர் அனுபவம் ஆகியவற்றைச் சரியாகக் கையாளுவதாகும். இந்தச் சிக்கல்களை முன்கூட்டியே உணர்ந்து செயல்பட்டால், மிகவும் நம்பகமான ஏஜென்ட்களை உங்களால் உருவாக்க முடியும்.