تصور کنید سیستمی می‌سازید که باید هزاران پیام را مدیریت کند، اما ناگهان متوجه می‌شوید قوانین پنهان متا اجازه نمی‌دهد اولین پاسخ شما به یک کامنت، اصلاً به عنوان یک پیام شناخته شود. این همان «میدان مین» از موارد خاص مستند نشده و مجوزهای سخت‌گیرانه API است که تیم تارژنیکس (Targenix) برای ساخت یک موتور اتوماسیون آماده برای محیط عملیاتی در پلتفرم‌های متا با آن دست‌وپنجه نرم کرد.
این پلتفرم که یک ابزار اتوماسیون رایگان برای کسب‌وکارهای ازبکستان است، اخیراً با گذار از منطق کدنویسی سخت (Hard-coded) به یک موتور جریان (Flow Engine) پیشرفته، با این چالش روبرو شد. این موتور جدید دارای ۹ محرک (Trigger) و ۱۷ نوع گام (Step type) است. این محرک‌ها مواردی مثل پاسخ به کامنت تبلیغات، پیام‌های مستقیم (DM)، ریپلای استوری‌ها، منشن شدن در استوری، کلیک روی تبلیغات، لینک‌های ig.me، یخ‌شکن‌ها (Ice Breakers)، منوی ثابت (Persistent Menu) و دکمه‌ها را پوشش می‌دهند. این تغییر در حالی رخ می‌دهد که کسب‌وکارها برای مقیاس‌بندی هزینه‌های تبلیغاتی خود، به‌طور فزاینده‌ای به جذب لید (Lead Generation) خودکار متکی شده‌اند. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه شکست‌های متادیتای عامل‌های هوش مصنوعی می‌تواند پاسخ‌ها را مختل کند اشاره کردیم، چالش اصلی برای تارژنیکس نه خودِ هوش مصنوعی، بلکه زیرساخت صلب API پیام‌رسان اینستاگرام و پلتفرم مسنجر بود.
به نقل از گزارشی در وب‌سایت dev.to که در ۲۸ سپتامبر ۲۰۲۶ منتشر شد، تیم توسعه متوجه شد که اولین پاسخ به یک کامنت تبلیغاتی، یک پیام استاندارد نیست. در واقع این پاسخ خطاب به «کامنت» است، نه «کاربر»؛ به این معنی که شناسه پیام‌رسان کاربر (PSID/IGSID) تنها پس از آنکه API ارسال (Send API) یک پاسخ برگرداند، در دسترس قرار می‌گیرد. این یافته باعث شد آن‌ها مدل داده‌های خود را کاملاً بازنویسی کنند. پیش از این، آن‌ها فرض می‌کردند که یک گفتگو با یک شناسه کاربر (User ID) شروع می‌شود، اما در جریان‌های مربوط به کامنت، ابتدا باید پاسخ خصوصی ارسال شود تا شناسه کاربر ثبت گردد و سپس جریان اتوماسیون بتواند باز شود.
مدیریت پنجره‌های ارتباطی
یکی از بزرگ‌ترین موانع فنی، مدیریت دو پنجره زمانی ارتباطی متمایز بود. پاسخ خصوصی به یک کامنت تا ۷ روز پس از ثبت آن کامنت معتبر است. در مقابل، پیام‌های استاندارد تحت یک قانون سخت‌گیرانه ۲۴ ساعته هستند که از آخرین تعامل مشتری شروع می‌شود.
تارژنیکس دریافت که اعمال یک بررسی ۲۴ ساعته جهانی برای همه پیام‌ها، باعث می‌شود جریان‌های مربوط به کامنت‌هایی که بیش از یک روز از آن‌ها گذشته است، بدون هیچ خطایی (Silently) متوقف شوند. برای حل این مشکل، آن‌ها تابع «آیا اکنون می‌توانم ارسال کنم؟» را به‌روزرسانی کردند تا به‌جای تکیه صرف به برچسب زمانی، دلیل خاص ارسال پیام را هم دریافت کند و بر اساس آن تصمیم بگیرد.
نرده‌های ایمنی مهندسی
برای تضمین پایداری سیستم و جلوگیری از فروپاشی در مقیاس بالا، تیم چندین اصلاح عملیاتی خاص را اجرا کرد:
- حالت سایه (Shadow Mode): موتور جدید به مدت ۴۸ ساعت در پس‌زمینه رویدادها را پردازش کرد و تصمیماتش را برای مقایسه با سیستم قدیمی در پایگاه‌داده ذخیره کرد تا پیش از فعال‌سازی نهایی، صحت آن تایید شود. آن‌ها از لاگ‌های stdout برای این کار استفاده نکردند، زیرا بازنشانی (Redeploy) کانتینرها باعث پاک شدن پنجره مقایسه‌ای می‌شد.
- ازسرگیری وب‌هوک (Webhook Resumption): آن‌ها وضعیت «در انتظار مشتری» را از تایمرها به وب‌هوک‌های ورودی منتقل کردند. چون تایمرها نمی‌توانند تشخیص دهند که مشتری چه زمانی پاسخ داده است، استفاده از آن‌ها برای پاسخ‌های اولیه باعث می‌شد جریان‌ها برای همیشه ساکت بمانند. اکنون تایمرها فقط برای سناریوهای «عدم پاسخ پس از N ساعت» رزرو شده‌اند.
- جداسازی حساب‌های تست: به دلیل اینکه متا هنگام تلاش ادمین یک صفحه برای پاسخ دادن به فعالیت خودش، خطای ۱۰۹۰۳ («این کاربر نمی‌تواند به این فعالیت پاسخ دهد») را برمی‌گرداند، تیم حساب‌های تست بدون نقش (Role-less) را برای بررسی‌های سرتاسری (End-to-End) ایجاد کرد.
رویکرد ترکیبی هوش مصنوعی
تارژنیکس از اشتباه رایج استفاده از چت‌بات‌های تمام‌هوش مصنوعی که اغلب از هدف کسب‌وکار منحرف می‌شوند (Drift)، دوری کرد. در عوض، آن‌ها یک مدل ترکیبی را پیاده کردند که در آن گام‌های قطعی (Deterministic) مسیرهای حیاتی را مدیریت می‌کنند؛ مواردی مثل پاسخ به قیمت‌ها، نمایش عکس‌ها، درخواست شماره تلفن و ایجاد لید در CRM یا گروه‌های تلگرام.
در این ساختار، یک گام پاسخ هوش مصنوعی سوالات غیرمنتظره (مثلاً «آیا به سمرقند ارسال دارید؟») را بر اساس متن تبلیغ و حقایق کسب‌وکار مانند شرایط ارسال و ساعات کاری پاسخ می‌دهد. این ساختار از اثر «حلقه تکرار» (Looping) که در عامل‌های مدل‌های زبانی بزرگ (LLM) رایج است، جلوگیری می‌کند. سوالات پیچیده و شکایات نیز مستقیماً به اپراتورهای انسانی ارجاع داده می‌شوند.
علاوه بر این، آن‌ها با تولید پاسخ‌های عمومی به کامنت‌ها به‌صورت مجزا، از ارسال متن‌های مشابه و تکراری که فیلترهای اسپم متا معمولاً آن‌ها را شناس می‌کنند، جلوگیری کردند. برای صاحب کسب‌وکار، این تفاوت بین یک حساب مسدود شده و یک قیف فروش مقیاس‌پذیر است.
انطباق با قوانین پلتفرم
برای محافظت از سلامت حساب‌ها، تیم آگاهانه تصمیم گرفت برخی قابلیت‌ها را اصلاً نسازد. آن‌ها از ساخت ابزارهای ارسال پیام انبوه (Broadcast)، پیام‌های «دلتنگت شده‌ایم» که روزها بعد ارسال می‌شوند و پیام دادن به کاربرانی که هرگز ارتباط را شروع نکرده بودند، پرهیز کردند.
اولویت آن‌ها از افزایش حجم پیام به محافظت از مجوزهای پیام‌رسانی تغییر کرد، چرا که تیم این مجوزها را ارزشمندتر از هر کمپین بازاریابی تک‌موردی می‌بیند. توسعه‌دهندگانی که ابزارهای مشابه می‌سازند، باید اکنون ماشین وضعیت (State Machine) خود را بازبینی کنند تا مطمئن شوند بین محرک‌های مبتنی بر کامنت و محرک‌های مبتنی بر DM تفاوت قائل می‌شوند.
گام بعدی شما
- اگر در حال توسعه ابزارهای اتوماسیون هستید، ماشین وضعیت (State Machine) خود را بازبینی کنید تا تفاوت محرک‌های مبتنی بر کامنت و DM را تفکیک کند.
- برای کاهش نرخ توهم در چت‌بات‌ها، مسیرهای تبدیل (Conversion Paths) را قطعی کنید و هوش مصنوعی را فقط برای سوالات باز به کار ببرید.
- از حساب‌های تست بدون نقش برای شبیه‌سازی دقیق رفتار کاربر نهایی در API متا استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو