کدام عدد پیش‌بینی را مبنای ظرفیت فردا بگذاریم؟

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

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

چهار روز ممکن، سه انتخاب متفاوت

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

حساب ردیف میانی را باز کنیم. اگر ظرفیت ۱۲۵ باشد، در چهار حالت به‌ترتیب ۴۵، ۲۵، ۵ و صفر جای خالی داریم؛ متوسط آن ۱۸٫۷۵ است. فقط در حالت چهارم کم می‌آوریم: ۷۵ درخواست بیشتر از ظرفیت می‌رسد. متوسط کمبود هم ۱۸٫۷۵ می‌شود. پس هزینه برابر است با ۱۸٫۷۵، به‌علاوه چهار برابر ۱۸٫۷۵؛ یعنی ۹۳٫۷۵ واحد.

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

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

از مدل میانگین می‌خواهیم یا یک صدک مشخص؟

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

میانگین، متوسط وزن‌دار نتیجه‌های ممکن بر پایه احتمال آن‌هاست. میانه، توزیع را از وسط تقسیم می‌کند. صدک هشتادم، آستانه‌ای است که احتمال تجمعی در آن به دست‌کم ۸۰ درصد می‌رسد. با وجود روزهای کم‌تعداد اما بسیار شلوغ، این سه کمیت لزوماً برابر نیستند.

در نمونه ما هر عددی از ۱۰۰ تا ۱۲۰ یک میانه است. اگر صدک را کوچک‌ترین مقداری بگیریم که احتمال تجمعی به سطح خواسته‌شده می‌رسد، صدک هشتادم ۲۰۰ می‌شود. تا ۱۲۰ فقط ۷۵ درصد احتمال جمع شده است. در ۲۰۰ به صد درصد می‌رسیم. بنابراین انتخاب صدک هشتادم در این توزیع گسسته، همه حالت‌ها را پوشش می‌دهد؛ نه دقیقاً ۸۰ درصد آن‌ها را. وجود احتمال مثبت روی یک عدد، این تفاوت را ایجاد می‌کند.

پژوهش تیلمان گنایتینگ درباره ارزیابی پیش‌بینی نقطه‌ای بر تناسب کمیت خواسته‌شده و قاعده امتیازدهی تأکید دارد. مربع خطا با میانگین تناسب دارد و قدرمطلق خطا با میانه. هیچ‌کدام خودبه‌خود ترجیح مدیر بین کمبود و مازاد را بیان نمی‌کنند.

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

هزینه کمبود، سطح صدک را تعیین می‌کند

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

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

مستندات سنجه‌های Amazon Forecast نیز زیان در یک صدک مشخص را از متوسط زیان چند صدک جدا می‌کند و وزن متفاوت خطای کم‌برآوردی و بیش‌برآوردی را توضیح می‌دهد. استناد ما به معنای سنجه است، نه توصیه خرید یا ادعای دسترسی به این خدمت.

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

بازه پیش‌بینی با دستور تأمین ظرفیت فرق دارد

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

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

بازه هر روز هم تضمین نمی‌کند تمام روزهای هفته هم‌زمان داخل بازه‌های خود بمانند. برای جمع هفتگی، صدک‌های روزانه را بدون شناخت وابستگی جمع نزنید. فرض کنید دو حالت هم‌احتمال داریم: در یکی، دوره اول ۱۰۰ درخواست و دوره دوم صفر دارد؛ در دیگری برعکس. صدک نودم هر دوره ۱۰۰ است، ولی جمع دو دوره همیشه ۱۰۰ می‌شود، نه ۲۰۰. برای جمع، مسیرهای سناریویی را جمع کنید یا همان مقدار کل را مستقیم مدل کنید.

عددی را بسنجید که واقعاً در تصمیم استفاده می‌کنید

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

در مثال چهارروزه، متوسط این زیان برای ظرفیت‌های ۱۲۰، ۱۲۵ و ۲۰۰ به‌ترتیب ۱۹، ۱۸٫۷۵ و ۱۵ است. هرکدام را در پنج ضرب کنیم، هزینه تصمیم متناظر به دست می‌آید. این برابری تصادفی نیست: هزینه عملیاتی مثال را با همان نسبت و به‌صورت خطی تعریف کرده‌ایم. برای فرایندی با هزینه‌های غیرخطی، چنین برابری را نباید فرض کرد.

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

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

تصمیم گذشته را با اطلاعات همان زمان بازسازی کنید

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

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

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

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

پوشش مناسب در کل، خطای یک تیم را پنهان نکند

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

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

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

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

پیش‌بینی را از برنامه اجرایی جدا نگه دارید

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

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

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

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

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

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

• گنایتینگ، ساخت و ارزیابی پیش‌بینی نقطه‌ای — ارسال نخست ۴ دسامبر ۲۰۰۹؛ نسخه دوم ۷ مارس ۲۰۱۰. ادعای مورد استفاده، تناسب هدف و قاعده امتیازدهی است.
• هایندمن و آتاناسوپولوس، بازه‌های پیش‌بینی — ویرایش سوم کتاب اصول و عمل پیش‌بینی، ۲۰۲۱؛ نسخه آنلاین کتاب با به‌روزرسانی ۱۶ سپتامبر ۲۰۲۶.
• همان نویسندگان، ارزیابی پیش‌بینی توزیعی — امتیازهای چندکی و بازه‌ای، در همان ویرایش آنلاین.
• همان نویسندگان، اعتبارسنجی سری زمانی — ارزیابی با مبدأ متحرک و فاصله زمانی مشخص. این سه فصل، یک منبع سازمانی محسوب می‌شوند.
• مرجع mean_pinball_loss در scikit-learn — مستندات نسخه ۱٫۹٫۱، دیده‌شده در تاریخ بررسی؛ تاریخ انتشار ثابتی برای صفحه ذکر نشده است.
• AWS، ارزیابی دقت پیش‌بینی — مستندات جاری Amazon Forecast بدون تاریخ ثابت، دیده‌شده در تاریخ بررسی؛ برای معنای سنجه‌ها، نه دسترسی یا توصیه خرید خدمت.