ইমেইল এজেন্ট তৈরির ক্ষেত্রে সাধারণ ভুলসমূহ
আপনার ইমেইল এজেন্ট টেস্টিংয়ের সময় ঠিকঠাক কাজ করে। তারপর আপনি এটি রিলিজ করেন। রাতারাতি, এজেন্ট তার নিজের পাঠানো মেসেজের উত্তর দিতে শুরু করে। গ্রাহকরা একই উত্তর তিনবার পান। কনভারসেশন থ্রেডগুলো ভেঙে টুকরো টুকরো হয়ে যায়।
এই ব্যর্থতাগুলো ইনফ্রাস্ট্রাকচার লেভেলে ঘটে, আপনার LLM প্রম্পটের কারণে নয়।
লঞ্চ করার আগে এই নয়টি বিষয় যাচাই করে নিন:
ইনফিনিট লুপ (The Infinite Loop) আপনার এজেন্ট যখন কোনো রিপ্লাই পাঠায়, তখন webhook ট্রিগার হয়। এটি আবার আরেকটি webhook ট্রিগার করে। ফলে একটি লুপ তৈরি হয়। সমাধান: আপনার কোডের শুরুতে এজেন্টের ইমেইল অ্যাড্রেসটি ফিল্টার করুন। যদি প্রেরক এজেন্ট হয়, তবে প্রসেসটি থামিয়ে দিন।
ডুপ্লিকেট মেসেজ (Duplicate Messages) নেটওয়ার্কের সমস্যার কারণে আপনার endpoint যথেষ্ট দ্রুত রেসপন্স করতে পারে না। ফলে সিস্টেম একই নোটিফিকেশন আবার পাঠায়। সমাধান: মেসেজ ID-র ওপর একটি atomic check ব্যবহার করুন। প্রতিটি ID যেন কেবল একবারই প্রসেস করা হয় তা নিশ্চিত করতে Redis বা Postgres ব্যবহার করুন।
রেস কন্ডিশন (Race Conditions) দুটি ওয়ার্কার একই মিলিসেকেন্ডে একই ইভেন্ট প্রসেস করে। এখানে শুধুমাত্র deduplication যথেষ্ট নয়। সমাধান: ৩০ সেকেন্ডের লিমিটসহ একটি per-thread lock ব্যবহার করুন। সেই lock-এর ভেতরেই চেক করুন যে এজেন্ট ইতিমধ্যে রিপ্লাই দিয়েছে কি না।
ট্রাঙ্কেটেড ডেটা (Truncated Data) Webhook প্রায়ই কেবল সারাংশ বহন করে, সম্পূর্ণ বডি নয়। বড় ইমেইলগুলো ট্রাঙ্কেটেড ইভেন্ট হিসেবে আসতে পারে। সমাধান: সবসময় ID ব্যবহার করে API থেকে সম্পূর্ণ মেসেজটি ফেচ (fetch) করুন। কন্টেন্টের জন্য webhook payload-এর ওপর নির্ভর করবেন না।
ভাঙা থ্রেড (Broken Threads) একটি রিপ্লাইকে নতুন মেসেজ হিসেবে পাঠালে Gmail বা Outlook-এ কনভারসেশন গ্রুপিং ভেঙে যায়। সমাধান: প্রতিটি রেসপন্সের সাথে
reply_to_message_idপাস করুন। রিপ্লাইগুলোthread_idদিয়ে মেলান, কখনোই subject line দিয়ে নয়।মানুষের সংশোধন (The Human Correction) একজন মানুষ তার প্রথম ইমেইলের কয়েক সেকেন্ড পরেই একটি ফলো-আপ সংশোধন পাঠাতে পারেন। আপনার এজেন্ট উভয় মেসেজেরই উত্তর দেয়। সমাধান: ৩০ থেকে ৬০ সেকেন্ডের একটি cooldown পিরিয়ড ব্যবহার করুন। পরপর আসা মেসেজগুলোকে একটি রিপ্লাইতে ব্যাচ (batch) করে ফেলুন।
রিপ্লাই স্টর্ম (The Reply Storm) একটি লজিক বাগের কারণে এজেন্ট মুহূর্তের মধ্যে শত শত ইমেইল পাঠিয়ে দিতে পারে। সমাধান: প্রতিটি থ্রেডের জন্য একটি send budget সেট করুন। যদি এজেন্ট ৫ মিনিটে ৩টি মেসেজ পাঠায়, তবে প্রসেস থামিয়ে দিন এবং একজন মানুষকে অ্যালার্ট করুন।
গারবেজ ইনপুট (Garbage Input) স্প্যাম এবং 'out-of-office' রিপ্লাই আপনার LLM-কে ট্রিগার করে। ফলে আপনি অদরকারি ইনফারেন্সের (inference) জন্য টাকা খরচ করেন। সমাধান: খারাপ প্রেরকদের ব্লক করতে বা অটোমেটেড মেইল অন্য ফোল্ডারে পাঠানোর জন্য inbox rules ব্যবহার করুন।
403 এরর ট্র্যাপ (The 403 Error Trap) আউটবাউন্ড রুলস ইমেইল পাঠানো ব্লক করতে পারে। এতে 403 error রিটার্ন হয়। স্ট্যান্ডার্ড রিট্রাই লজিক এই এররটিকে বারবার ট্রাই করতে থাকবে। সমাধান: 403-কে একটি terminal error হিসেবে গণ্য করুন। এটি রিট্রাই করবেন না। যদি 503 পান, তবে আপনি রিট্রাই করতে পারেন।
ফিল্টার, লক এবং ক্যাপের মতো একঘেয়ে সমাধানগুলোই একটি এজেন্টকে নিরাপদ রাখে।
Source: https://dev.to/qasim157/common-pitfalls-building-email-agents-and-fixes-29kg
Optional learning community: https://t.me/GyaanSetuAi