معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۲ — ICP، Serviceability، Pilot، Workload و Admission · 233
P50/P80/P95 Forecasting
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «P50/P80/P95 Forecasting». می‌تواند برای «P50/P80/P95 Forecasting» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خلاصهٔ درس
معماری یا تصمیم تجاری را با preference و الگوهای آماده می‌گیرد و constraint/cost/serviceability را مدل نمی‌کند. موضوع جاری: «P50/P80/P95 Forecasting».
می‌تواند برای «P50/P80/P95 Forecasting» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
خروجی این درس
می‌تواند برای «P50/P80/P95 Forecasting» یک تصمیم bounded با constraints، cost/risk و stop/pivot condition طراحی کند.
1) مسئلهٔ واقعی: سه Percentile بدون Context، Forecast نیستند
دیدن سه عدد P50/P80/P95 حس دقت می‌دهد، اما اگر Forecast object، Horizon، Window داده، سناریو و روش ساخت توزیع مشخص نباشد، این اعداد می‌توانند دقیق به‌نظر برسند و در عین حال برای تصمیم غلط باشند. هدف این درس ساخت Percentile Forecast Evidence Pack v1 است؛ بسته‌ای که عدد، روش و محدودیت را کنار هم نگه می‌دارد.
2) Percentile چه می‌گوید و چه نمی‌گوید؟
در یک مجموعه/توزیع مشخص، P95 آستانه‌ای است که حدود 95% مشاهدات در یا زیر آن قرار می‌گیرند. Google Cloud همین معنا را برای P95 latency در یک بازهٔ اندازه‌گیری توضیح می‌دهد. اما این تعریف به‌تنهایی نمی‌گوید «95% تضمین داریم که آینده از این عدد عبور نمی‌کند». Forecast به یک توزیع آینده‌نگر یا Scenario process نیاز دارد.
3) Forecast Object را دقیق نام ببر
«P95=820» بدون Object بی‌معناست. آیا 820 req/s برای peak پنج‌دقیقه‌ای است، تعداد Job روزانه، latency یا token/minute؟ Evidence Pack باید forecast_object و unit را صریح ثبت کند تا Percentile قابل تفسیر باشد.
4) Horizon بخشی از سؤال است
Forecast یک‌ماهه و Forecast یک‌فصل یک مسئله نیستند. Seasonality، Campaign، Trend و مقدار داده لازم تغییر می‌کند. تغییر Horizon بدون Refitting یا Revalidation باعث HOLD می‌شود؛ Percentileهای Horizon قبلی را نمی‌توان صرفاً با برچسب جدید استفاده کرد.
5) Sample Window و Sample Size را پنهان نکن
یک P95 از Sample ناقص، به‌ویژه اگر High-demand observationها حذف شده باشند، Tail را مصنوعی کوچک می‌کند. Pack باید Window، N و Completeness را نگه دارد. اگر سه هفته داده بعداً ناقص تشخیص داده شوند، نتیجه قبلی نیاز به Recompute دارد.
6) روش Distribution را ثبت کن
در Lab این درس از Empirical nearest-rank percentile روی داده‌های مرتب‌شده استفاده می‌کنیم تا Oracle کاملاً deterministic باشد. در Production می‌توان مدل دیگری داشت، اما نام روش و Version/Scenario آن باید در Pack بماند. P50/P80/P95 بدون روش تولید، Provenance ناقص دارند.
7) Tail Driver را جدا از عدد ببین
P95 بالا ممکن است از Campaign، End-of-month batch، Tenant خاص یا Failure retry ناشی شود. اگر Known spike در Calendar وجود دارد اما Scenario آن را وارد نکرده، Pack نباید USABLE بماند. Tail Driver بخشی از Evidence است، نه توضیح تزئینی بعد از Forecast.
8) Backtest خطای گذشته را آشکار می‌کند
یک Forecast خوش‌ظاهر بدون Backtest نمی‌گوید روش در Context مشابه چقدر خطا داشته است. در طراحی این درس، Backtest error تا 15% قابل استفاده است؛ بیشتر از آن INSUFFICIENT می‌شود تا Method بازبینی شود. این Threshold یک MAKNOW DESIGN است، نه الزام Google Cloud.
9) Freshness یک State مستقل است
اگر Data freshness از Window تصمیم عقب افتاده باشد، Pack STALE می‌شود حتی اگر Percentileها از نظر محاسباتی درست باشند. Stale یعنی «عدد تاریخی ممکن است درست باشد، اما برای تصمیم فعلی نیاز به Refresh دارد».
10) سناریوی پایه: از Observations تا P50/P80/P95
Baseline شامل 30 مشاهدهٔ Daily Peak کامل و تازه است، Horizon یک‌ماهه با Scenario فعلی و Backtest error برابر 8% دارد. با nearest-rank، Percentileها از همان Sample محاسبه و همراه Unit و Tail driver ثبت می‌شوند. چون Object، Horizon، Sample، Method، Assumptions و Backtest کامل‌اند، State برابر USABLE است.
| Forecast | Object | Horizon | Sample N | Scenario | Method | P50 | P80 | P95 | Unit | Tail Driver | Backtest | Freshness | State | Evidence |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Baseline | daily peak demand | 30d | 30 | current-plan | empirical nearest-rank | 600 | 690 | 820 | req/s | month-end + tenant bursts | 8% | 2d | USABLE | fixture://forecast/base |
| Tail removed | daily peak demand | 30d | 26 incomplete | current-plan | empirical nearest-rank | 580 | 660 | 700 | req/s | tail was removed | 8% | 2d | HOLD | fixture://forecast/tail-removed |
| Quarter transfer | daily peak demand | 90d | 32 + incomplete weeks | 2 known campaigns | must refit | 610 | 720 | 980 | req/s | campaign spikes | 8% | 2d | HOLD | fixture://forecast/transfer |
11) میان‌بُر غلط: حذف Tail برای «تمیزشدن» Forecast
اگر چند High-demand observation را حذف کنیم، P95 پایین‌تر و جذاب‌تر می‌شود، ولی Evidence Pack دیگر نماینده Sample اعلام‌شده نیست. این Mutation HOLD می‌شود تا Sample اصلاح و Forecast دوباره ساخته شود. هدف Percentile پنهان‌کردن Tail نیست؛ هدف دیدن Shape توزیع است.
12) Campaign و Known Events باید وارد Scenario شوند
یک Campaign قطعی که بعد از Forecast اعلام شده، Assumption set را عوض می‌کند. اگر Known spike material است و هنوز Refit نشده، نتیجه HOLD است. می‌توان Scenario جدا ساخت، اما نباید Baseline بدون Campaign را به‌عنوان Forecast همان Campaign عرضه کرد.
13) Lab: هشت Fixture، یک Oracle قابل بازتولید
Lab هشت Fixture مصنوعی دارد: Baseline، Tail removal، Horizon change، Known spike omitted، Missing object/unit، Stale data، High backtest error و Transfer. Evaluator فقط بر اساس Input visible و قواعد deterministic State می‌دهد. هیچ Answer key در مسیر Learner قرار ندارد؛ ارزیابی با ورودی‌های قابل‌مشاهده و قواعد صریح انجام می‌شود و مواد ارزیابی خارج از مسیر Learner نگه داشته می‌شوند.
14) Transfer: Campaign، داده ناقص و Horizon سه‌ماهه
در Transfer دو Spike شناخته‌شده اضافه می‌شود، سه هفتهٔ داده ناقص کشف می‌شود و Horizon از یک ماه به یک فصل تغییر می‌کند. این فقط «P95 جدید» نمی‌خواهد؛ Distribution process و Sample sufficiency عوض شده‌اند. نتیجه HOLD است تا داده ترمیم، Horizon refit و Scenarioهای Spike دوباره محاسبه شوند.
15) چک‌لیست تحویل
Evidence Pack باید Forecast ID/Object، Horizon، Sample window/N، Seasonality/Scenario، Distribution method، P50/P80/P95، Unit، Tail driver، Backtest error، Data freshness، Assumption set، Decision use و Evidence ref را داشته باشد. در متن تصمیم نیز صریح بنویس: Percentile یک Guarantee ظرفیت نیست و هر تغییر مادی در Horizon، Sample یا Scenario Recompute می‌خواهد.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ARC-014-Q1 retrieval
Explain what P95 means and why it is not a 95% guarantee about future maximum demand.
ARC-014-Q2 application
Build Percentile Forecast Evidence Pack v1 for the complete baseline fixture.
ARC-014-Q3 diagnosis
Several high-demand observations are removed. Identify why the pack must not remain USABLE and name the repair.
ARC-014-Q4 transfer
Recompute or HOLD after two known campaign spikes, three incomplete weeks, and a horizon change from 30d to 90d.
ملاک‌های ارزیابی (rubric)
- Boundary: the owned artifact is explicit; adjacent lesson outcomes are not absorbed.
- Evidence: decisive fields trace to visible sources/fixtures and missing data remains typed.
- Negative case: at least one tempting shortcut is rejected with the exact failed dimension.
- Bounded state: the result is no stronger than evidence and includes a stop/review/recompute trigger.
- Transfer: changed-context evidence is recomputed; the baseline label is not copied.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
از همین پوشه اجرا کنید:
python run_checks.pyبرای هر Fixture، P50/P80/P95 را با روش nearest-rank روی Observations visible محاسبه و State را از Completeness، Horizon fit، Known events، Backtest و Freshness تعیین کنید. P95 را Guarantee ظرفیت تعبیر نکنید.