۸۰۰ میلیثانیه؛ این تمام فرصتی است که یک موتور توصیه دارد تا سایز لباس خریدار را تشخیص دهد، پیش از آنکه محصول در یک پخش زنده به پایان برسد. این فوریت توضیح میدهد چرا طبق تحلیل Digital Colliers، خرید شرکت Shaped توسط Whatnot یک سیگنال حیاتی است: تجارت زنده دیگر یک چالش بازاریابی نیست، بلکه یک مسئلهی دادههای جریانی است که رابط کاربری آن ویدیو است. وقتی یک فروشنده پیراهنی را برای ۴۰۰۰ بیننده نمایش میدهد، سامانه نمیتواند به پردازشهای دستهای (Batch Processing) — که شبیه به جمعآوری رسیدهای یک ماهه در پایان ماه است تا تحلیل شوند — تکیه کند. در این لحظه، دادههای دیروز هیچ ارزشی ندارند.
شکاف پردازش دستهای
اکثر برندهای بازار متوسط هنوز از پردازش دستهای استفاده میکنند؛ جایی که امتیازات تمایل به محصول شبانه بازسازی شده و رفتار کاربر صبح روز بعد تکهتکه به هم متصل میشود. این وضعیت باعث میشود سیستم نسبت به اتفاقاتی که در ۱۰ دقیقه گذشته رخ داده، کاملاً کور باشد. تصور کنید خریداری سه محصول مختلف را کلیک میکند و سپس به دلیل اینکه صفحه نخست هنوز توصیههایی بر اساس آنچه او هنگام صبحانه پسندیده ارائه میدهد، تب مرورگر را میبندد.
در یک ساختار معمولی بازار متوسط، سفارشات و کلیکها به یک انبار داده جریان مییابند و یک عملیات dbt در ساعت ۳ صبح اجرا میشود تا جدول توصیهها را منتشر کند. در حالی که این روش ارزان و کاربردی است، اما اساساً نسبت به جلسه فعلی کاربر (Immediate Session) کور است. معماری جریانی (Streaming Architecture) این قطبیت را میچرخاند: رویدادها فوراً به یک گذرگاه پیام میرسند، ویژگیها در حافظه همزمان با پیشروی جلسه بهروز میشوند و مدل بر اساس دنیای «همین حالا» امتیازدهی میکند.
فشارهای اقتصادی در سال ۲۰۲۵
این تأخیر در دادهها به شدت هزینهبر شده است. هزینههای جذب مشتری مستقیم (DTC) از سال ۲۰۲۳ تقریباً ۴۰٪ افزایش یافته و قیمتهای تبلیغاتی Meta (CPM) در طول سالهای ۲۰۲۴ و ۲۰۲۵ همچنان صعودی بوده است. به گزارش ONS، رشد تجارت الکترونیک در بریتانیا در سال ۲۰۲۴ تنها حدود ۳٪ بوده است. بنابراین، رشد اکنون در اختیار اپراتورهایی است که بتوانند ترافیکی را که بابت آن هزینه کردهاند، در لحظه و به صورت Real-time تبدیل به فروش کنند.
معماری فنی یک مخزن ویژگی
برای حل این مشکل، یک مخزن ویژگی (Feature Store) در سطح جلسه به چهار جزء کلیدی و مشخص نیاز دارد:
- جریان رویداد (Event Stream): ابزارهایی مانند Kafka، Kinesis یا Redpanda برای انتقال کلیکها، افزودن به سبد خرید (Add-to-cart)، زمان توقف (Dwell time) و عمق اسکرول.
- ذخیرهساز با تأخیر کم (Low-Latency Store): Redis، DynamoDB یا Feast (که بر روی هر یک از اینها ساخته شده) برای نگه داشتن ویژگیهای مربوط به هر جلسه که با پایان یافتن جلسه، منقضی میشوند.
- لایه محاسباتی (Computation Layer): سیستمی برای مدیریت پنجرههای لغزان (Rolling Windows)، مانند مشاهده ۵ کالای آخر، آخرین دستهبندی مشاهده شده، انحراف بازه قیمتی یا سرعت پر کردن سبد خرید.
- لایه سرویسدهی مدل (Model Serving Layer): یک رتبهبندیکننده (Ranker) که این ویژگیها را در کمتر از ۵۰ میلیثانیه بخواند و یک لیست رتبهبندی شده را بازگرداند.
نکته جالب این است که خودِ مدل یادگیری ماشین — که معمولاً یک مدل بازیابی دو-برجی (Two-tower retrieval) و رتبهبندی تقویتشده با گرادینت (Gradient-boosted ranker) است — تنها ۸۰٪ از مسیر را طی میکند و معمولاً سادهترین بخش این زنجیره است.
نرخ شکست در محیط عملیاتی
بر اساس بررسی منابع متعدد، ۹۵٪ پروژههای هوش مصنوعی سازمانی هرگز به مرحله تولید (Production) نمیرسند. دلیل این شکست به ندرت یک مدل بد است؛ بلکه پروژهها فرو میپاشند چون بودجه تأخیر (Latency Budget) تمام شده، ویژگیها در لحظه استنتاج (Inference) در دسترس نبودهاند، یا هیچکس نتوانسته توضیح دهد که چرا یک توصیه تغییر کرده است. در واقع، مانع اصلی اغلب لولهکشی داده است، نه خود هوش مصنوعی.
موجودی به عنوان متغیر اصلی
توصیههای لحظهای بدون سیگنال تازه و همزمان از موجودی انبار شکست میخورند. توصیه کردن یک کالا (SKU) که موجود نیست، از توصیه نکردن هیچچیز آسیبزاتر است. نرخ مرجوعی کالا در حال حاضر حدود ۱۹ تا ۲۰ درصد فروش ناخالص است و این عدد در صنعت پوشاک حتی بالاتر است.
برندهای چندکاناله معمولی متوجه شدهاند که حدود ۳۰٪ از SKUها، پس از کسر هزینههای تبلیغات و مرجوعی، در هر سفارش در واقع ضرر میدهند. اگر موتور جریانی از موجودی واقعیِ «قابل وعده» (Available-to-promise) آگاه نباشد یا کالاهایی با نرخ مرجوعی بالا را کماهمیت نکند، ممکن است برند را مستقیماً به سمت بهینهسازی روی آن ۳۰٪ زیانده سوق دهد.
موفقیت در سال ۲۰۲۶ مستلزم این است که با جریان رویداد به عنوان یک محصول درجهیک برخورد شود، نه یک پروژه جانبی تیم داده. اپراتورها باید مالک سیگنال موجودی، از دیوار انبار تا ویترین فروشگاه باشند. در نهایت، بهبود توصیهها باید با حاشیه سود سنجیده شود، نه فقط تعداد کلیکها.
کسبوکارها باید همین حالا تازگی فید موجودی خود را حسابرسی کنند. اگر رسیدن سیگنال به ویترین به جای دقایق، ساعتها زمان میبرد، یا اگر نرخ مرجوعی هر SKU و تخصیص انبار در یک «جعبه سیاه» ERP مخفی شده است، مدل ML شما در پاییندست یک مشکل لولهکشی قرار دارد که باید ابتدا اصلاح شود.
گام بعدی شما
- تأخیر رسیدن دادههای انبار به ویترین فروشگاه خود را اندازهگیری کنید (باید زیر ۱ دقیقه باشد).
- میزان مرجوعی هر SKU را به عنوان یک ویژگی (Feature) به مدل توصیه اضافه کنید تا از فروش کالاهای زیانده جلوگیری شود.
- بررسی کنید آیا مدل شما در لحظه استنتاج به دادههای «همین حالا» دسترسی دارد یا از جداول دیروز استفاده میکند.
اما تأثیر این معماری بر کاهش هزینههای GPU در مقیاس میلیونی حتی پیچیدهتر است. برای درک بهتر این موضوع، میتوانید بررسی کنید که چطور قیمتگذاری مبتنی بر درخواست توانسته است هزینهی استریم مدلهای سنگین را کاهش دهد و بهرهوری سختافزاری را بالا ببرد. به تحلیل ما درباره بهینهسازی لایه سرویسدهی مدلها مراجعه کنید.
گفتگو