قفسه خالی چگونه پیش‌بینی تقاضای هوش مصنوعی را گمراه می‌کند؟

ت

تیم ژرف

۲۳ شهریور ۱۴۰۵۱۲ دقیقه مطالعه
قفسه خالی چگونه پیش‌بینی تقاضای هوش مصنوعی را گمراه می‌کند؟

فروشگاهی ساعت هشت صبح دوازده بسته کالا دارد. تا ظهر همه را می‌فروشد و تا ساعت چهار، زمان تعطیلی، محموله دیگری نمی‌رسد. گزارش صندوق برای آن روز عدد دوازده را ثبت می‌کند. اگر مدل هوش مصنوعی همین عدد را «تقاضای روزانه» بداند، چه چیزی درباره مشتریان بعدازظهر یاد گرفته است؟ هیچ شاهد مستقیمی از خریدهای انجام‌نشده ندارد؛ فقط می‌داند فروش به سقف موجودی رسیده است.

این مثال فرضی، مسئله‌ای واقعی را نشان می‌دهد: تصمیم خرید امروز، داده آموزش فردا را شکل می‌دهد. این راهنما برای مدیر برنامه‌ریزی، مسئول موجودی و تیم داده‌ای است که می‌خواهند بدانند تاریخچه فروش چه وقت برای پیش‌بینی تقاضا کافی است، چه وقت به برآورد احتیاج دارد و کجا باید صریحاً گفت «نمی‌دانیم».

اول بپرسید صفر از کجا آمده است

صفر فروش، یک معنای ثابت ندارد. کالایی که تمام روز روی قفسه بوده و خریداری نداشته، با کالایی که از صبح ناموجود بوده یک نمونه آموزشی نیست. روز تعطیل هم با روز قطع ارتباط صندوق فرق دارد. اگر همه این وضعیت‌ها را با صفر پر کنیم، خودمان رابطه‌ای نادرست به مدل تحمیل کرده‌ایم.

پیشنهاد ژرف این است که پیش از انتخاب مدل، وضعیت مشاهده را کنار هر بازه فروش ثبت کنید:

وضعیت بازهبرداشت مجاز از فروش صفربرخورد با داده
فروشگاه باز، کالا قابل خرید، ثبت تراکنش سالمدر این شرایط خریدی ثبت نشده استمشاهده معتبر در دامنه تعریف‌شده
فروشگاه باز، کالا ناموجوددرباره تقاضای برآورده‌نشده خبر قطعی نداریمعلامت محدودشدن مشاهده به موجودی
کالا عرضه نشده یا فروشگاه تعطیلفرصتی برای این خرید وجود نداشته استجدا از تقاضای زمان فعالیت
وضعیت موجودی یا سامانه فروش نامعلومحتی کامل‌بودن گزارش روشن نیستبررسی کیفیت؛ نه صفر و نه برآورد قطعی

«موجودی مثبت» در نرم‌افزار نیز کافی نیست. کالا شاید آسیب‌دیده، رزروشده، در انبار پشتی یا پشت صفحه ناموجود فروشگاه اینترنتی باشد. وضعیت قابل خرید بودن را برای همان کانال و همان محل تحویل تعریف کنید. بازگشت کالا را هم از فروش ناخالص جدا نگه دارید؛ فروش خالص صفر ممکن است حاصل یک خرید و یک مرجوعی باشد، نه نبود مراجعه.

تقاضای کدام شرایط را پیش‌بینی می‌کنید؟

در این مقاله، تقاضا تعداد واحدهایی است که مشتریان در یک بازه مشخص، با قیمت، تخفیف، ترکیب کالاها و شرایط خدمت مشخص می‌خریدند، اگر کمبود موجودی مانع نمی‌شد. این یک کمیت وابسته به شرایط است، نه عددی ثابت که در هر فروشگاه و هر قیمت منتظر کشف باشد.

برای حالت ساده یک کالا، بدون تأمین مجدد در طول بازه، بدون سفارش معوق و بدون جایگزینی، فروش برابر کوچک‌ترِ تقاضا و موجودی قابل فروش است: Y = min(D, Q). در این بیان، Y فروش مشاهده‌شده، D تقاضا و Q موجودی است. وقتی همه موجودی فروخته شود، فقط D ≥ Q را می‌دانیم؛ نه اینکه تقاضا دقیقاً برابر موجودی بوده است.

آمار این وضعیت را «سانسورشدن مشاهده» می‌نامد: محدودیت عرضه اجازه نمی‌دهد انتهای تقاضا را ببینیم. این اصطلاح درباره حذف عمدی اطلاعات نیست. اگر فروشگاه سفارش معوق می‌پذیرد، ابتدا درخواست و زمان ثبت آن را از تحویل جدا کنید؛ آن مسئله با فروش ازدست‌رفته یکسان نیست.

راهنمای تقاضاسنجی و تصمیم موجودی در خرده‌فروشی زنجیره کامل پیش‌بینی تا سفارش را توضیح می‌دهد. بحث حاضر روی ورودی همان زنجیره مکث می‌کند: برچسبی که به مدل می‌دهیم واقعاً چه چیزی را اندازه گرفته است؟

ساعت اتمام کالا را همراه فروش نگه دارید

دو روز با فروش دوازده واحد، الزاماً شواهد یکسانی ندارند. در روز اول، آخرین واحد ظهر فروخته شده؛ در روز دوم، ساعت ۱۵:۵۵. روز دوم تقریباً تمام ساعات فعالیت را پوشش داده است. این تفاوت برای شناخت الگوی مراجعه ارزش دارد، هرچند به‌تنهایی تعداد تقاضای پنهان را معلوم نمی‌کند.

پژوهش جین، رودی و وانگ نشان می‌دهد که زمان اتمام موجودی، در مدل‌های مشخص ورود تقاضا، اطلاعات بیشتری از علامت ساده «تمام شد» فراهم می‌کند. نتیجه به فرض‌های همان مدل‌ها وابسته است؛ نمی‌توان آن را حکم عمومی درباره هر فروشگاه دانست. مطالعه زمان اتمام موجودی، ۲۰۱۵.

در عمل، برای هر کالا، شعبه و کانال، بازه‌های قابل خرید بودن را بازسازی کنید. زمان فروش، دریافت محموله، انتقال، رزرو، آزادشدن رزرو، شمارش و اصلاح موجودی باید قابل پیگیری باشند. زمان مشاهده رویداد را از زمان ورودش به سامانه جدا کنید. واحد کالا نیز ثابت بماند: یک جعبه را با یک عدد جمع نزنید.

گاهی ساعت دقیق اتمام معلوم نیست. اگر آخرین بررسی معتبر ساعت یازده موجودی را تأیید کرده و بررسی ساعت یک قفسه را خالی یافته، به جای ساختن ساعت دوازده، همان فاصله نامعلوم را نگه دارید. «آخرین فروش» لزوماً زمان خالی‌شدن نیست؛ ممکن است تراکنشی دیر رسیده یا کالا از قفسه برداشته شده باشد. کیفیت داده و مشاهده‌پذیری کمک می‌کند این ابهام‌ها به نشانه قابل بررسی تبدیل شوند، نه اصلاح پنهانی داده.

دوازده فروش، تقاضای بیست‌وچهار را ثابت نمی‌کند

به مثال آغاز برگردیم. فروشگاه چهار ساعت از هشت ساعت فعالیت موجودی داشته است. ضرب دوازده در دو، عدد بیست‌وچهار را می‌دهد. حساب درست است؛ فرض پشت آن هنوز اثبات نشده: آیا آهنگ خرید در چهار ساعت دوم شبیه چهار ساعت اول بوده است؟ خرید زمان ناهار، تخفیف صبحگاهی یا مراجعه پس از کار این برابری را به هم می‌زند.

یک تاریخچه مشاهده‌شده با چند وضعیت متفاوت سازگار است. شاید پس از ظهر هیچ خرید دیگری رخ نمی‌داد؛ شاید تقاضای روز به هجده یا سی واحد می‌رسید. این اعداد صرفاً سناریوهای فرضی‌اند، نه برآورد مدل و نه فاصله اطمینان. سقف عرضه به‌تنهایی حد بالای متناهی برای تقاضا تعیین نمی‌کند.

حذف همه روزهای ناموجود نیز راه‌حل بی‌هزینه‌ای نیست. اگر روزهای شلوغ زودتر موجودی را تمام کنند، داده باقی‌مانده بیشتر از روزهای آرام می‌آید. مدل روی نمونه‌ای انتخاب‌شده آموزش می‌بیند. در سوی مقابل، پرکردن خودکار هر ساعت ناموجود با میانگین فروش، تفاوت روزها را می‌پوشاند.

پیش از هر اصلاح، نسخه خام فروش را نگه دارید. کنار مقدار برآوردی، روش، داده مرجع، نسخه، دامنه اعتبار و میزان عدم قطعیت را ثبت کنید. برنامه‌ریز باید بتواند فروش ثبت‌شده را جدا از فروش فرض‌شده ببیند. اگر چند روش قابل دفاع، سفارش‌های بسیار متفاوت پیشنهاد می‌کنند، اختلاف آن‌ها خود یک هشدار تصمیم است.

مدل باید بداند کدام برچسب ناقص است

دو مسیر قابل بررسی دارید. در مسیر نخست، مدل مستقیماً تفاوت مشاهده کامل و محدودشده را در یادگیری لحاظ می‌کند. در نسخه ساده شمارشیِ رابطه بالا، روز بدون کمبود به احتمال P(D = y) مربوط است؛ روزی که موجودی q را تمام کرده به احتمال P(D ≥ q). مدل برای روز دوم نباید به دلیل پیشنهاد تقاضای بیشتر از فروش ثبت‌شده، همان جریمه روز اول را بگیرد.

این توضیح، شهود ریاضی حالت ساده است؛ نسخه آماده اجرا برای فروشگاه چندکالایی نیست. توزیع انتخابی، کیفیت موجودی و فرض‌های مربوط به تصمیم تأمین اهمیت دارند. اگر تصمیم قبلی خریدار بر اطلاعاتی متکی بوده که در داده امروز نیست، سازوکار کمبود را نیز باید در تحلیل لحاظ کرد. افزودن یک ستون «ناموجود» به هر مدل معمولی، خودبه‌خود این مسائل را حل نمی‌کند.

در مسیر دوم، ابتدا تقاضای بخش نامشهود را برآورد می‌کنید و سپس پیش‌بینی آینده را آموزش می‌دهید. برای شناخت داده مناسب، مجموعه FreshRetailNet-50K، نسخه پنجم ژوئن ۲۰۲۶ نمونه‌ای تازه است: نویسندگان پنجاه هزار سری زمانی کالا–فروشگاه با فروش ساعتی و برچسب اتمام موجودی ارائه کرده‌اند. این نوع ثبت، بررسی مسئله را ممکن می‌کند؛ برچسب ناموجودی، خودِ تقاضای نادیده را به واقعیت مشاهده‌شده تبدیل نمی‌کند.

هر دو مسیر به شاهد احتیاج دارند. برای کالایی که همیشه ناموجود بوده و مشابه قابل اتکایی ندارد، مدل پیچیده هم اطلاعات تازه خلق نمی‌کند. نتیجه درست ممکن است «داده ناکافی» باشد. مدل زبانی می‌تواند علت این وضعیت را برای خریدار توضیح دهد؛ نباید عدد فروش ازدست‌رفته را از متن مکاتبات حدس بزند و در جدول مرجع بنویسد.

خرید جایگزین را دوبار نشمارید

اگر کالای نخست تمام شود، بعضی مشتریان کالای دیگری می‌خرند، بعضی خرید را عقب می‌اندازند و بعضی می‌روند. بنابراین فروش کالای جایگزین نیز از وضعیت موجودی کالای نخست اثر می‌گیرد. جمع‌کردن برآورد تقاضای ازدست‌رفته کالای اول با تمام فروش واقعی کالای دوم، ممکن است یک خواسته خرید را دوبار حساب کند.

کانلون و مورتیمر در پژوهشی بر داده دستگاه‌های فروش خودکار، موجودبودن کالا را در فاصله‌های چهار‌ساعته دنبال کردند و از تغییر دسترسی برای برآورد الگوهای جایگزینی استفاده کردند. این مطالعه شاهدی برای اهمیت ترکیب کالاهای در دسترس است، نه اندازه اثر قابل تعمیم به همه خرده‌فروشان. تقاضا در شرایط دسترسی ناقص به کالا، ۲۰۱۳.

در گزارش خود روشن کنید که «تقاضای انتخاب اول برای یک کالا» را تخمین می‌زنید یا «فروش کل گروه در ترکیب فعلی کالاها» را. اگر مدل فقط یک کالا را می‌بیند، محدودیت جایگزینی را کنار نتیجه بنویسید. داده تجمیعی کالا و فروشگاه را نقطه شروع قرار دهید؛ برای این مسئله معمولاً لازم نیست هویت اشخاص را وارد مدل کنید.

گذشته اصلاح‌شده را به پیش‌بینی دیروز ندهید

ممکن است امروز بدانیم موجودی روز دوشنبه اشتباه بوده، اما سامانه سفارش دوشنبه این اصلاح را در اختیار نداشته است. برای بازسازی تصمیم گذشته، ویژگی‌ها باید همان اطلاعاتی باشند که در ساعت صدور پیش‌بینی موجود بودند. نسخه اصلاح‌شده برای بررسی واقعیت مفید است؛ جایگزین ورودی تاریخی نیست.

مستندات پارامترهای پیش‌بینی Google Cloud نیز میان ویژگی‌های آینده معلوم، مثل تعطیلی و برنامه ترفیع فروش، و مقدارهای هنوز نامعلوم، مثل هوای واقعاً رخ‌داده، تفاوت می‌گذارد. این تفکیک یک قاعده مفید طراحی است، نه توصیه به خرید آن محصول.

برای فردا، ساعت واقعی اتمام موجودی فردا را ورودی نکنید. موجودی برنامه‌ریزی‌شده را هم با موجودی محقق‌شده یکی نگیرید. اگر هدف، تقاضا بدون محدودیت عرضه است، موجودی می‌تواند سازوکار مشاهده را توضیح دهد، اما نباید بی‌صدا هدف را به «فروش تحت موجودی فعلی» تغییر دهد. راهنمای زمان رویداد و اطلاعات در دسترس هنگام تصمیم این تفاوت را در معماری داده باز می‌کند.

برآورد خودتان را پاسخ صحیح آزمون ننامید

آزمون را با چند مبدأ زمانی انجام دهید: در هر مبدأ فقط داده گذشته را در اختیار مدل بگذارید و همان افقی را بسنجید که سفارش به آن وابسته است. روش برآورد تقاضای پنهان نیز باید در هر نوبت فقط با داده مجاز آن زمان برازش شود. مبنای این ترتیب، ارزیابی با مبدأ پیش‌بینی غلتان است.

سه گزارش جدا لازم دارید. نخست، خطا روی بازه‌های واقعاً قابل خرید؛ این گزارش فقط درباره همان زیرمجموعه است و شاید روزهای شلوغ را کم‌نمایی کند. دوم، آزمون حذف مصنوعی بخشی از داده کامل برای سنجش بازسازی؛ این آزمون توان روش در برابر همان الگوی حذف را می‌سنجد، نه تقاضای واقعی همه کمبودها را. سوم، حساسیت تصمیم سفارش به چند فرض معقول درباره بخش نادیده.

اگر مدل دیگری تقاضای نامشهود را پر کرده، آن جدول را «حقیقت آزمون» ننامید. توافق دو مدل ممکن است فقط توافق فرض‌های مشترک باشد. حتی سنجش پوشش بازه پیش‌بینی روی روزهای موجود، تضمین پوشش همان بازه در روزهای ناموجود نیست. گزارش باید دامنه مشاهده‌شده را آشکار نگه دارد.

برای خطای واحدی، میانگین قدر مطلق خطا را کنار جهت خطا و عملکرد یک پیش‌بینی ساده فصلی ببینید. خطای درصدی در فروش صفر تعریف‌ناپذیر یا ناپایدار می‌شود؛ معیار مقیاس‌شده هم اگر مخرج مبنایش صفر باشد قابل استفاده نیست. راهنمای سنجش دقت پیش‌بینی تفاوت این معیارها را توضیح می‌دهد. هیچ معیاری برچسب نامعتبر را معتبر نمی‌کند.

چه چیزی اجازه تغییر سفارش را می‌دهد؟

اگر زمان‌های ناموجودی نامطمئن‌اند، اقدام بعدی بهبود مشاهده است، نه تعویض مدل. اگر مشاهده مناسب است ولی نتیجه به روش برآورد بسیار حساس است، پیشنهاد خرید را به بازبینی بسپارید. اگر شواهد در دامنه مشخص پایدارند، یک آزمون محدود عملیاتی طراحی کنید؛ برتری در بازسازی تاریخچه به‌تنهایی مجوز سفارش خودکار نیست.

برای یک آزمایش پیشنهادی، کالاهای کم‌ریسک و غیرفاسدشدنی، سقف موجودی اضافه، مدت آزمون و مسئول توقف را از قبل تعیین کنید. مقایسه با گروه مشابه یا تخصیص تصادفی، در صورت امکان، به تفکیک اثر تغییر کمک می‌کند. جابه‌جایی مشتری میان شعب و جانشینی کالاها را در انتخاب گروه‌ها لحاظ کنید. ژرف چنین آزمایشی را در این مقاله اجرا نکرده و نتیجه‌ای برای آن ادعا نمی‌کند.

صرفاً افزایش فروش را موفقیت ننامید. روزهای ناموجودی، زمان‌های وضعیت نامعلوم، سهم برچسب‌های برآوردی، موجودی پایان دوره، کالای مانده، ضایعات و پول درگیر را کنار هم ببینید. افزایش موجودی می‌تواند فروش را قابل مشاهده‌تر کند؛ همچنین ممکن است فقط سرمایه را در قفسه نگه دارد. مسئول خرید باید این مبادله را ببیند.

بعد از تغییر قیمت، ترفیع فروش، ترکیب کالاها، ساعات فعالیت یا سیاست تأمین، فرض‌های مدل را دوباره بررسی کنید. پرسش پایان جلسه خرید ساده است: کدام بخش این پیشنهاد از خریدهای ثبت‌شده آمده، کدام بخش برآورد است و اگر برآورد اشتباه باشد چه هزینه‌ای می‌دهیم؟ پاسخ روشن به این پرسش، از رقم دقیق‌نمایی که قفسه خالی را نادیده گرفته مفیدتر است.

یادداشت منابع — بررسی‌شده در ۱۴ سپتامبر ۲۰۲۶

این مقاله راهنمای عملی و تحلیل ژرف است، نه گزارش انتشار پژوهش یا توصیه سرمایه‌گذاری. مثال دوازده واحد و همه سناریوهای عددی فرضی‌اند. منابع باز و ادعاهای مورد استفاده بررسی شدند؛ نتایج عملکرد پژوهش‌ها به کسب‌وکار دیگر تعمیم داده نشده‌اند.

  1. جین، رودی و وانگ؛ زمان اتمام موجودی، Operations Research، ژانویه–فوریه ۲۰۱۵؛ انتشار آنلاین ۴ دسامبر ۲۰۱۴. نتیجه‌های نظری وابسته به فرض مدل‌اند.
  2. کانلون و مورتیمر؛ دسترسی ناقص به کالا، AEJ Microeconomics، نوامبر ۲۰۱۳؛ مطالعه دستگاه‌های فروش خودکار.
  3. وانگ و همکاران؛ FreshRetailNet-50K، نسخه پنجم ۱۸ ژوئن ۲۰۲۶، نسخه نخست ۲۲ مه ۲۰۲۵؛ داده ساعتی دارای برچسب اتمام موجودی.
  4. هایندمن و آتاناسوپولوس؛ اعتبارسنجی سری زمانی، نسخه آنلاین ویرایش سوم کتاب؛ مراجعه در تاریخ مقاله.
  5. همان نویسندگان؛ سنجش خطای پیش‌بینی، نسخه آنلاین ویرایش سوم؛ این دو فصل دو سازمان مستقل محسوب نمی‌شوند.
  6. Google Cloud؛ پارامترهای آموزش پیش‌بینی، به‌روزرسانی صفحه ۳ سپتامبر ۲۰۲۶؛ تفکیک ویژگی معلوم و نامعلوم هنگام پیش‌بینی.
#پیش‌بینی تقاضا#خرده‌فروشی#موجودی کالا#کیفیت داده#یادگیری ماشین

مطالب مرتبط

یک فرایند را برای کشف نیاز مشخص کنید

اگر این مطلب به یک سامانه واقعی در سازمان شما مربوط است، از خدمات و مطالعه موردی شروع کنید.