ML system design — একটি পুরো নকশা, শুরু থেকে নজরদারি পর্যন্ত

এই কোর্সে এতদিন প্রায় প্রতিটি পর্ব একটি অংশ গভীরে দেখেছে: framing (পর্ব ০২), label-এর মান (পর্ব ০৫), model বাছাই (পর্ব ৩৮), A/B test (পর্ব ৬২), distribution shift (পর্ব ৫৯)। AI-এর ভিত্তি কোর্সের পর্ব ৭৪-এ একটি AI প্রকল্পের জীবনচক্রও দেখেছেন। এই পর্ব সব টুকরো জোড়া লাগায়: একটি বাস্তবধর্মী সমস্যা নিয়ে শুরু থেকে নজরদারি পর্যন্ত একটি পুরো নকশা, যেভাবে কাজে বা ইন্টারভিউতে লিখতে হয়। চারটি চালানো যায় এমন ব্লক পাতাতেই চলে (ব্রাউজারের Python, NumPy, pandas, scikit-learn আর matplotlib); প্রথমবার scikit-learn নামতে প্রায় দশ সেকেন্ড লাগে।

১ · ML system design কী — দশ ধাপের একটি মানচিত্র

ML system design মানে এমন একটি পুরো ব্যবস্থার নকশা, যা ডেটা থেকে শেখে, আসল ব্যবহারকারীর অনুরোধে সময়মতো উত্তর দেয়, ব্যর্থ হলে নিরাপদে নামে, আর সময়ের সঙ্গে নিজের মান মাপে ও ঠিক রাখে। সাধারণ system design (System Design কোর্সের পর্ব ০৬) থেকে তিনটি পার্থক্য: আচরণ কোডে লেখা নয়, ডেটা থেকে শেখা; সঠিকতা পরীক্ষায় হ্যাঁ বা না নয়, একটি পরিসংখ্যান; আর পৃথিবী বদলালে কোড একই থাকলেও system খারাপ হয়। এই পর্বে দশটি ধাপ ব্যবহার করব:

1. প্রশ্ন আর পরিধি: কোন সিদ্ধান্ত, কার জন্য, কী সীমার মধ্যে।
2. Framing: ML task, target, loss (পর্ব ০২-এর সাত আংটার শিকল)।
3. Metric: offline, online আর guardrail, আগে থেকে লিখে রাখা।
4. ডেটা আর label: কোথা থেকে, কখন জানা যায়, কতটা বিশ্বাসযোগ্য।
5. Feature: অনুমানের মুহূর্তে কী জানা যায়, আর training-এও ঠিক সেটিই।
6. Baseline আর model: সবচেয়ে সরল উত্তর আগে, তারপর তাকে হারানো।
7. Training pipeline: পুনরুৎপাদনযোগ্য, যাচাইসহ, version-সহ।
8. Serving: batch না online, latency, fallback.
9. মূল্যায়ন: shadow, canary আর A/B test.
10. নজরদারি আর পুনরাবৃত্তি: drift, দেরিতে আসা label, retrain, পরের সংস্করণ।

ধাপগুলো সরলরেখায় চলে না। Metric বাছতে গিয়ে প্রায়ই দেখা যায় label নেই; latency budget দেখে model বদলাতে হয়। তবু ক্রমটি একটি ভালো চেকলিস্ট। আমাদের সমস্যা: কাল্পনিক অনলাইন দোকান বাজারঘর checkout পাতায় ক্রেতাকে দেখাতে চায়, “এই অর্ডার এত ঘণ্টার মধ্যে পৌঁছাবে”। প্রথম ধাপ প্রশ্ন জিজ্ঞাসা, যা নিচের stepper-এ।

২ · Requirement আর framing — checkout-এ ডেলিভারির প্রতিশ্রুতি

Functional requirement: checkout পাতায় ঠিকানা আর ঝুড়ি দেখে একটি সংখ্যা, “N ঘণ্টার মধ্যে পৌঁছাবে”; ঠিকানা বদলালে সংখ্যাও বদলাবে; প্রতিটি অনুমান তার model-এর version-সহ লগ হবে। Non-functional requirement: ETA অংশের p99 latency ৬০ ms-এর নিচে; বড় sale-এর ভিড়েও চলবে; model বন্ধ থাকলেও checkout চলবে; প্রতিশ্রুতি অন্তত ৮০% অর্ডারে রক্ষা হবে, আর প্রতিটি অঞ্চলে (zone) আলাদাভাবেও।

Framing. Unit একটি অর্ডার; অনুমানের মুহূর্ত checkout পাতা খোলা; target “অর্ডার নিশ্চিত থেকে ক্রেতার হাতে পৌঁছানো, ঘণ্টায়”; বাতিল অর্ডারের target নেই। প্রতিশ্রুতির জন্য আমরা শর্তসাপেক্ষ ৮০%-quantile অনুমান করি, অর্থাৎ quantile regression, যার loss τ = ০.৮-এর pinball (পর্ব ২৪)। কেন ০.৮? এটি এখনো একটি অনুমান; অংশ ৬-এর simulation আর পরে A/B test এটি যাচাই করবে। আরেকটি বিকল্প ছিল পরিসর দেখানো (“২০ থেকে ৩২ ঘণ্টা”), যার জন্য পর্ব ৫৮-এর conformal পদ্ধতি কাজে লাগে; কিন্তু ছোট পর্দায় একটি সংখ্যা বেশি পরিষ্কার, তাই প্রথম সংস্করণে একটি সংখ্যা।

কখন ML নয়? শুরুর সংস্করণ হতে পারে একটি টেবিল: প্রতিটি zone-এর গত মাসের ৮০% quantile. পর্ব ০২-এর নিয়মে এটিই baseline, আর অংশ ৭-এ এটিই fallback হবে। ML তখনই যোগ করবেন, যখন এই টেবিলকে মাপা যায় এমন পার্থক্যে হারানো যায়, আর সেই পার্থক্য রক্ষণাবেক্ষণের খরচের চেয়ে বেশি।

৩ · খামের পেছনের হিসাব — অনুরোধ, latency আর storage

System Design কোর্সের পর্ব ০৩-এর back-of-the-envelope নিয়মে, প্রতিটি অনুমান আলাদা করে লিখে। সংখ্যাগুলো বাজারঘরের জন্য ধরে নেওয়া, কোনো আসল দোকানের পরিসংখ্যান নয়: দিনে ৫০,০০০ অর্ডার; একটি অর্ডারের আগে গড়ে চারবার checkout পাতা খোলা হয় (অনেকে না কিনে ফেরেন); প্রতিবার দুটি অনুমান (সাধারণ আর পরের দিনের ডেলিভারি); সন্ধ্যার ভিড় গড়ের তিন গুণ (peak factor), আর বড় sale-এর দিন তার আরও পাঁচ গুণ।

একই হিসাব একটি ছোট function-এ, যাতে অনুমান বদলে সঙ্গে সঙ্গে ফল দেখা যায়। শেষ লাইনে অর্ডার দশ গুণ করে দেখা হয়েছে।

# বাজারঘরের checkout-এ ডেলিভারির সময়: খামের পেছনের হিসাব (সব সংখ্যা ধরে নেওয়া)
def capacity(orders_day=50_000, views_per_order=4, preds_per_view=2,
             peak=3, sale_day=5, budget_ms=300, eta_share=0.2,
             log_bytes=1_000, row_bytes=200, years=1):
    views = orders_day * views_per_order          # checkout পাতা খোলা, দিনে
    avg_rps = views / 86_400
    peak_rps = avg_rps * peak                     # সন্ধ্যার ভিড়
    sale_rps = peak_rps * sale_day                # বড় sale-এর দিনের ভিড়
    eta_ms = budget_ms * eta_share                # পুরো checkout API-র ভাগ
    split = {"network": 0.15, "features": 0.35, "model": 0.35, "spare": 0.15}
    logs_gb = views * log_bytes * 365 * years / 1e9      # প্রতিটি অনুমানের লগ
    train_gb = orders_day * row_bytes * 365 * years / 1e9  # label-সহ training সারি
    return {"checkout views/day": views,
            "avg req/s": round(avg_rps, 1), "peak req/s": round(peak_rps, 1),
            "sale-day req/s": round(sale_rps, 1),
            "predictions/s at sale peak": round(sale_rps * preds_per_view, 1),
            "ETA budget ms": eta_ms,
            "budget split ms": {k: round(v * eta_ms, 1) for k, v in split.items()},
            "prediction logs GB/year": round(logs_gb, 1),
            "training rows/year": orders_day * 365,
            "training data GB/year": round(train_gb, 2)}

for k, v in capacity().items():
    print(f"{k:28s} {v}")
print("10x orders, sale-day req/s:", capacity(orders_day=500_000)["sale-day req/s"])

checkout views/day           200000
avg req/s                    2.3
peak req/s                   6.9
sale-day req/s               34.7
predictions/s at sale peak   69.4
ETA budget ms                60.0
budget split ms              {'network': 9.0, 'features': 21.0, 'model': 21.0, 'spare': 9.0}
prediction logs GB/year      73.0
training rows/year           18250000
training data GB/year        3.65
10x orders, sale-day req/s: 347.2

৪ · ডেটা, label আর feature — feature store-এর ধারণা

Label job. প্রতিদিন একটি job অর্ডারের ঘটনা থেকে label বানায়: “নিশ্চিত” থেকে “হাতে পৌঁছানো” পর্যন্ত ঘণ্টা। প্রশ্নগুলো ছোট নয়: ক্রেতা বাড়িতে না থাকলে দ্বিতীয় চেষ্টার সময় কি গোনা হবে? ফেরত অর্ডারের label কী? পর্ব ০৫-এর মতো, এই নিয়মগুলো লিখে রাখতে হয় আর label-এর একটি এলোমেলো নমুনা হাতে মিলিয়ে দেখতে হয়, কারণ courier-এর app-এ “পৌঁছেছে” চাপার সময় আর আসল পৌঁছানোর সময় সবসময় এক নয়।

Feature. চারটি দল: অর্ডার (zone, hub থেকে দূরত্ব, পণ্যের সংখ্যা), hub-এর বর্তমান চাপ (গত এক ঘণ্টার অর্ডার ÷ courier-সংখ্যা), আবহাওয়া (বৃষ্টি), আর সময় (ঘণ্টা, সপ্তাহের দিন, ঈদের আগের সপ্তাহ কি না)। নিয়ম পর্ব ০২-এর: শুধু point-in-time feature, অর্থাৎ checkout-এর মুহূর্তে যা জানা যায়। “ওই দিনের মোট অর্ডার” training-এ সহজে পাওয়া যায়, কিন্তু checkout-এর সময় দিন শেষ হয়নি: এটি ভবিষ্যতের তথ্য, আর একে ব্যবহার করলে offline ফল মিথ্যা ভালো দেখায় (AI-এর ভিত্তি কোর্সের পর্ব ৫৬)।

Training-serving skew. সবচেয়ে নীরব ভুল: training-এ hub-এর চাপ হিসাব হয়েছে data warehouse-এর SQL-এ (পর্ব ৬১), আর online-এ app-এর কোডে, একটু আলাদা সংজ্ঞায় (ধরুন একটিতে বাতিল অর্ডার গোনা হয়, অন্যটিতে হয় না)। Model একটি সংখ্যা শিখেছে, পায় আরেকটি। এর নাম training-serving skew. প্রতিকার: একটি সংজ্ঞা, দুই জায়গায় একই কোড, আর online-এ লগ করা feature-এর সঙ্গে offline-এ আবার হিসাব করা feature-এর নিয়মিত তুলনা। একই preprocessing-কে model-এর সঙ্গে একটি pipeline-এ বাঁধা (AI-এর ভিত্তি কোর্সের পর্ব ৬৪) এর একটি অংশ সমাধান করে; packaging-এর বিস্তার পর্ব ৬৮ (Model serving — FastAPI, batch scoring আর ONNX)-এ।

Feature store-এর ধারণা. যখন অনেক model একই feature ব্যবহার করে, প্রতিষ্ঠানগুলো প্রায়ই একটি feature store বানায়: feature-এর সংজ্ঞা এক জায়গায়, আর দুটি ভান্ডার। Offline ভান্ডার প্রতিটি মানের পুরো ইতিহাস সময়সহ রাখে, যাতে training-এর প্রতিটি সারির জন্য “তখন যা জানা ছিল” তা জোড়া যায় (point-in-time join). Online ভান্ডার শুধু সর্বশেষ মান রাখে, key দিয়ে কয়েক ms-এ পড়া যায় (যেমন hub_id → load). বাজারঘরের প্রথম সংস্করণে আলাদা টুল লাগবে না: একটি টেবিল আর একটি cache-ই যথেষ্ট (System Design কোর্সের পর্ব ২৮)। তবে ধারণাটি, অর্থাৎ এক সংজ্ঞা আর সময়সহ ইতিহাস, প্রথম দিন থেকেই মানা ভালো।

Cold start. বাজারঘর একটি নতুন জেলায় hub খুলল; সেখানে কোনো ডেলিভারির ইতিহাস নেই। Cold start-এর সাধারণ পথ: কাছের অনুরূপ zone-এর rule আর দূরত্বের feature দিয়ে শুরু, প্রথম কয়েক সপ্তাহ বাড়তি buffer (যেমন ০.৯-quantile), আর নতুন zone-এর coverage আলাদা করে প্রতিদিন দেখা। যথেষ্ট label জমলে সেই zone model-এ সাধারণ zone হয়ে যায়।

৫ · Baseline, model আর training pipeline — পুরো নকশার ছবি

Baseline: zone-এর ৮০% quantile. প্রথম model: tabular ডেটা, কয়েক হাজার থেকে কয়েক কোটি সারি, ২১ ms-এর budget, তাই quantile loss-সহ একটি ছোট histogram gradient boosting (পর্ব ৩৮, পর্ব ৩৬)। Deep learning-এর কোনো বিশেষ কারণ এখানে নেই। একাধিক quantile একসঙ্গে লাগলে সেগুলো যেন একে অপরকে না কাটে, তা দেখতে হবে (quantile crossing).

Training pipeline প্রতি সপ্তাহে একবার: (১) গত ছয় মাসের label-সহ অর্ডার, শেষ সাত দিন বাদ (তাদের label এখনো অসম্পূর্ণ); (২) point-in-time join; (৩) ডেটার মৌলিক যাচাই (সারির সংখ্যা, missing, অসম্ভব মান); (৪) সময় ধরে ভাগ: পুরোনো অংশে শেখা, সর্বশেষ দুই সপ্তাহে মূল্যায়ন (পর্ব ৫২-এর backtest-এর মতো); (৫) baseline আর চালু model-এর পাশে pinball, coverage আর zone-ভিত্তিক coverage; (৬) সীমা পার হলে model registry-তে version, metric, ডেটার সময়কাল আর কোডের commit-সহ জমা। পর্ব ০৪-এর seed আর config-এর নিয়ম এখানে বাধ্যতামূলক, কারণ ছয় মাস পরে “এই model কোন ডেটায় শেখা?” প্রশ্নের উত্তর লাগবেই। এসব test-এর বিস্তার পর্ব ৬৯ (ML system-এর test আর নজরদারি — data test, model test আর drift)-এ।

Batch না online? সব ঠিকানা আর ঝুড়ির জন্য আগে থেকে ETA হিসাব করে রাখা (batch) সম্ভব নয়, কারণ hub-এর চাপ আর বৃষ্টি প্রতি মুহূর্তে বদলায়, আর ঠিকানা-ঝুড়ির জোড়া অসংখ্য। তাই অনুমান online. তবে একটি মাঝামাঝি পথ আছে: zone-এর rule-এর টেবিল রাতে batch-এ হিসাব হয়, আর সেটিই fallback. Serving-এর ধরনগুলোর বিস্তার পর্ব ৬৮-এ, আর অনেক বড় ডেটায় training পর্ব ৭০ (বড় ডেটায় ML — out-of-core, incremental learning আর Polars/DuckDB)-এ।

৬ · Offline বনাম online — সেরা MAE কেন সেরা ব্যবসা নয়

একটি offline metric পুরোনো ডেটায় model-এর মান মাপে; একটি online metric চালু অবস্থায় ব্যবসার ফল মাপে। দুটি এক দিকে চলবে, এমন কোনো নিশ্চয়তা নেই। নিচের module কাল্পনিক বাজারঘরের অর্ডার বানায়: zone (০ ঢাকা, ১ কাছের জেলা, ২ দূরের জেলা), দূরত্ব, বৃষ্টি, hub-এর চাপ আর পণ্যের সংখ্যা; ডেলিভারির ঘণ্টা ডানে-হেলানো, দূরের zone-এ অনিশ্চয়তা বেশি। online_value একটি simulated ব্যবসার নিয়ম: প্রতিশ্রুতি zone-এর স্বাভাবিক সময়ের (৮, ২৪, ৪৮ ঘণ্টা) চেয়ে যত লম্বা, ক্রেতার কেনার সম্ভাবনা তত কমে; আর আসল সময় প্রতিশ্রুতি ছাড়ালে ৩৫% অর্ডার বাতিল বা ফেরত হয়। এই সংখ্যাগুলো উদাহরণের জন্য বানানো, কোনো গবেষণার ফল নয়।

# বাজারঘর (কাল্পনিক দোকান): checkout-এ দেখানো ডেলিভারির সময়, seeded ডেটা
import numpy as np
import pandas as pd

FEATS = ["zone", "dist", "rain", "load", "n_items"]

def base_hours(df):                              # আসল (অজানা) গড় প্রক্রিয়া, ঘণ্টায়
    return ((5 + 0.06 * df.dist + np.array([0, 14, 30])[df.zone])
            * (1 + 0.3 * df.rain) * df.load * (1 + 0.03 * df.n_items))

def orders(n, seed=71):
    rng = np.random.default_rng(seed)
    zone = rng.choice(3, n, p=[0.5, 0.3, 0.2])   # 0 ঢাকা, 1 কাছের জেলা, 2 দূরের জেলা
    dist = rng.gamma(2 + 2 * zone, np.array([3, 10, 30])[zone])
    df = pd.DataFrame({"zone": zone, "dist": dist.round(1),
                       "rain": rng.binomial(1, 0.2, n),
                       "load": rng.normal(1, 0.15, n).clip(0.6, 1.6).round(2),
                       "n_items": rng.integers(1, 6, n)})
    noise = rng.lognormal(0, 0.25 + 0.1 * df.zone, n)   # দূরে অনিশ্চয়তা বেশি
    df["hours"] = (base_hours(df) * noise).round(1)
    return df

def online_value(promise, actual, zone):         # simulated ব্যবসার ফল, ১,০০০ checkout-এ
    buy = 0.92 * np.exp(-0.012 * (promise - np.array([8, 24, 48])[zone]).clip(0))
    late = actual > promise
    done = buy * (1 - 0.35 * late)              # দেরি হলে ৩৫% বাতিল বা ফেরত
    return 1000 * done.mean(), 100 * late.mean()

ছয়টি প্রার্থী: zone-এর median (rule), squared loss-এর linear regression, আর চারটি histogram gradient boosting: squared loss, absolute loss (median), quantile ০.৮ আর quantile ০.৯৫. সবার অনুমান পূর্ণ ঘণ্টায় ওপরে গোল করে প্রতিশ্রুতি বানানো হয়েছে, আর ৩,০০০টি নতুন অর্ডারে offline MAE আর simulated online ফল পাশাপাশি।

import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
from sklearn.ensemble import HistGradientBoostingRegressor as HGB
from sklearn.linear_model import LinearRegression
from bazar_eta import orders, online_value, FEATS

tr, te = orders(3000, seed=71), orders(3000, seed=710)
X, y = tr[FEATS], tr.hours
rule = tr.groupby("zone").hours.median()          # baseline: zone-এর median
cands = {"rule: zone median": rule[te.zone].to_numpy(),
         "linear (squared)": LinearRegression().fit(X, y).predict(te[FEATS])}
for name, kw in [("HGB squared", {}), ("HGB median", {"loss": "absolute_error"}),
                 ("HGB q=0.8", {"loss": "quantile", "quantile": 0.8}),
                 ("HGB q=0.95", {"loss": "quantile", "quantile": 0.95})]:
    m = HGB(max_iter=150, learning_rate=0.1, random_state=0, **kw).fit(X, y)
    cands[name] = m.predict(te[FEATS])
rows = []
for name, p in cands.items():
    p = np.ceil(p)                                 # ক্রেতাকে পূর্ণ ঘণ্টায় প্রতিশ্রুতি
    value, late = online_value(p, te.hours.to_numpy(), te.zone.to_numpy())
    rows.append({"model": name, "MAE_h": np.abs(p - te.hours).mean(),
                 "late_%": late, "done_per_1000": value})
t = pd.DataFrame(rows).set_index("model").round(2)
print(t)
print("best offline:", t.MAE_h.idxmin(), "| best online:", t.done_per_1000.idxmax())
fig, ax = plt.subplots(figsize=(6, 4))
ax.scatter(t.MAE_h, t.done_per_1000)
for name, r in t.iterrows():
    ax.annotate(name, (r.MAE_h, r.done_per_1000), fontsize=8)
ax.set_xlabel("offline MAE (hours, lower is better)")
ax.set_ylabel("simulated completed orders per 1000")
ax.set_title("Best offline model is not best online")

                   MAE_h  late_%  done_per_1000
model
rule: zone median   7.51   40.17         781.08
linear (squared)    7.80   44.00         741.67
HGB squared         7.48   36.63         767.56
HGB median          6.95   42.40         762.44
HGB q=0.8           9.44   19.17         785.71
HGB q=0.95         14.70    8.00         765.91
best offline: HGB median | best online: HGB q=0.8

তাহলে offline-এ কী মাপবেন? যে metric ব্যবসার ফলের সঙ্গে একই দিকে চলে বলে যুক্তি আর অতীতের পরীক্ষা দেখায়। নিচের stepper metric বাছাইয়ের ধাপগুলো সাজায়।

A/B test-এর আগে দুটি নিরাপদ ধাপ। Shadow deployment: নতুন model আসল অনুরোধে পাশাপাশি চলে, অনুমান লগ হয়, কিন্তু ক্রেতা দেখেন পুরোনোটি; এতে latency, ত্রুটি আর feature-এর অমিল ধরা পড়ে, কোনো ঝুঁকি ছাড়া। তারপর canary: ১–৫% ক্রেতার কাছে চালু, guardrail দেখে ধাপে ধাপে বাড়ানো (Cloud & DevOps কোর্সের পর্ব ৫৯)। মনে রাখুন, shadow-তে latency আর সঠিক feature যাচাই হয়, কিন্তু ক্রেতার আচরণ নয়: প্রতিশ্রুতি না দেখালে তার প্রভাব মাপা যায় না।

৭ · Serving আর fallback — model না পারলে কী

ETA service প্রতিটি অনুরোধে দুটি কাজ করে: online feature store থেকে hub-এর চাপ আর বৃষ্টি পড়া, তারপর model চালানো। দুটিরই লেজ আছে: বেশিরভাগ অনুরোধ দ্রুত, কিন্তু কিছু অনেক ধীর, আর কখনো model আটকে যায় (memory-র চাপ, নতুন version লোড হওয়া)। সমাধান System Design কোর্সের পর্ব ৪৮-এর: একটি timeout, আর সময় পেরোলে একটি fallback, এখানে zone-এর ৮০% quantile টেবিল, যা memory-তে থাকে আর প্রায় ১ ms নেয়। নিচের ব্লক simulated latency (feature-এর জন্য median ৮ ms, model-এর জন্য ১৫ ms, ২% অনুরোধে ২ সেকেন্ড আটকে থাকা) দিয়ে পাঁচটি timeout তুলনা করে।

import numpy as np
import pandas as pd
from sklearn.ensemble import HistGradientBoostingRegressor as HGB
from bazar_eta import orders, online_value, FEATS

tr, te = orders(3000, seed=71), orders(5000, seed=711)
q80 = HGB(loss="quantile", quantile=0.8, max_iter=150, random_state=0)
model_p = np.ceil(q80.fit(tr[FEATS], tr.hours).predict(te[FEATS]))
rule_p = np.ceil(tr.groupby("zone").hours.quantile(0.8)[te.zone].to_numpy())
y, z = te.hours.to_numpy(), te.zone.to_numpy()

rng = np.random.default_rng(42)                  # প্রতিটি অনুরোধের latency (ms), simulated
feat_ms = rng.lognormal(np.log(8), 0.5, len(te))            # feature store থেকে পড়া
model_ms = rng.lognormal(np.log(15), 0.6, len(te))          # model চালানো
model_ms[rng.random(len(te)) < 0.02] = 2000                 # ২% অনুরোধে model আটকে যায়
need = feat_ms + model_ms
rows = []
for timeout in [25, 40, 60, 100, np.inf]:
    fb = need > timeout                          # সময় পেরোলে rule-এর উত্তর
    p = np.where(fb, rule_p, model_p)
    ms = np.where(fb, timeout + 1, need)         # rule প্রায় ১ ms নেয়
    done, late = online_value(p, y, z)
    rows.append({"timeout_ms": timeout, "fallback_%": 100 * fb.mean(),
                 "p50_ms": np.percentile(ms, 50), "p99_ms": np.percentile(ms, 99),
                 "MAE_h": np.abs(p - y).mean(), "late_%": late, "done_per_1000": done})
print(pd.DataFrame(rows).round(1).to_string(index=False))
for name, p in [("model only", model_p), ("rule only", rule_p)]:
    done, late = online_value(p, y, z)
    print(f"{name:10s} MAE {np.abs(p - y).mean():.1f}  late {late:.1f}%  done {done:.1f}")

 timeout_ms  fallback_%  p50_ms  p99_ms  MAE_h  late_%  done_per_1000
       25.0        48.0    24.4    26.0   10.2    19.5          780.1
       40.0        14.5    24.4    41.0    9.9    19.1          783.7
       60.0         4.1    24.4    61.0    9.9    19.2          783.6
      100.0         2.0    24.4   101.0    9.8    19.2          783.8
        inf         0.0    24.4  2007.7    9.8    19.1          784.3
model only MAE 9.8  late 19.1%  done 784.3
rule only  MAE 10.9  late 19.1%  done 776.0

মানুষের হাত. কিছু ঘটনা কোনো model আগে দেখেনি: বন্যায় একটি জেলার রাস্তা বন্ধ, হরতাল, বড় সড়কে দুর্ঘটনা। তখন operations দলের হাতে একটি সুইচ থাকা উচিত: একটি zone-এ নির্দিষ্ট ঘণ্টা যোগ করা, বা সেই zone-এ ETA দেখানো বন্ধ রাখা। এটি human-in-the-loop-এর সরল রূপ; প্রতারণা ধরার model-এ এর রূপ হলো সন্দেহজনক অর্ডারের একটি সারি, যা একজন মানুষ যাচাই করেন। প্রতিটি হস্তক্ষেপ লগ হবে, যাতে পরে সেই সময়ের label training থেকে আলাদা রাখা যায়।

৮ · Feedback loop, নজরদারি আর পুনরাবৃত্তি

চালু model নিজের ভবিষ্যৎ training ডেটা বদলাতে পারে (feedback loop). পর্ব ৫৩-এ দেখেছেন, যা সুপারিশ হয় তা-ই বেশি বিক্রি হয়; পর্ব ৬০-এ, যাঁরা বাকি পান না তাঁদের label কখনো আসে না (selective labels). ETA-র ক্ষেত্রে একটি সূক্ষ্ম রূপ: hub-এর কর্মীরা checkout-এর প্রতিশ্রুতি দেখেন। প্রতিশ্রুতিতে হাতে সময় থাকলে তাঁরা অন্য জরুরি অর্ডার আগে পাঠান, তাই অর্ডারটি একটু দেরিতে পৌঁছায়। পরের সপ্তাহের label-এ সেই দেরি ঢোকে, model আরও লম্বা প্রতিশ্রুতি শেখে, আর চক্র চলে। নিচের simulation-এ hub বাড়তি সময়ের ৬০% খরচ করে ফেলে, আর প্রতিশ্রুতি হলো model-এর অনুমানের ১.২ গুণ। তুলনার কৌশল: এলোমেলো ১০% অর্ডারে hub প্রতিশ্রুতি দেখে না (holdout), আর model শেখে শুধু সেই অংশে।

import numpy as np
import pandas as pd
from sklearn.linear_model import LinearRegression
from bazar_eta import orders

def design(df):                                  # সরল feature: zone one-hot আর দূরত্ব
    return np.c_[df.zone == 1, df.zone == 2, df.dist, df.rain, df.load]

def run(strategy, rounds=6, slack=0.6, buffer=1.2):
    hist = orders(4000, seed=7100)               # শুরুর ডেটা: প্রতিশ্রুতি দেখানোর আগের যুগ
    model = LinearRegression().fit(design(hist), hist.hours)
    out = []
    for r in range(rounds):
        week = orders(4000, seed=7101 + r)
        t0 = week.hours.to_numpy()               # প্রতিশ্রুতি না থাকলে যা লাগত
        promise = buffer * model.predict(design(week))
        blind = np.random.default_rng(r).random(len(week)) < 0.10   # ১০% hub প্রতিশ্রুতি দেখে না
        seen = (strategy == "no holdout") | ~blind
        # hub প্রতিশ্রুতি দেখলে হাতে সময় থাকলে ঢিলে দেয়: বাড়তি সময়ের ৬০% খরচ হয়
        actual = t0 + seen * slack * np.clip(promise - t0, 0, None)
        out.append({"round": r, "promise_h": promise.mean(), "actual_h": actual.mean(),
                    "on_time_%": 100 * (actual <= promise).mean()})
        train = blind if strategy == "train on blind 10%" else np.ones(len(week), bool)
        model = LinearRegression().fit(design(week)[train], actual[train])
    return pd.DataFrame(out).set_index("round").round(1)

for s in ["no holdout", "train on blind 10%"]:
    print(s); print(run(s))

no holdout
       promise_h  actual_h  on_time_%
round
0           27.8      27.5       67.9
1           33.0      29.9       79.1
2           35.5      31.2       82.2
3           37.0      31.7       85.3
4           37.8      32.2       87.3
5           39.7      33.5       87.2
train on blind 10%
       promise_h  actual_h  on_time_%
round
0           27.8      27.0       67.9
1           28.7      27.2       71.1
2           26.8      26.6       66.1
3           25.7      25.7       66.6
4           27.1      26.2       69.4
5           27.8      27.0       66.6

এই simulation-এর বানানো নিয়ম (৬০% ঢিলেমি) বাস্তবে কতটা সত্য, তা জানা নেই; প্রশ্নটি হলো আপনার system-এ এমন একটি পথ আছে কি না। একই নকশা বহু জায়গায় খাটে: প্রতারণার model যে অর্ডার আটকায়, তার label আসে না, তাই একটি ছোট এলোমেলো অংশ নিয়ম ছাড়াই যাচাই হয়; সুপারিশে কিছু অংশে নতুন পণ্য দেখানো হয় (exploration). প্রতিটি সিদ্ধান্তের সম্ভাবনা লগ করলে পরে inverse probability weighting দিয়ে সংশোধনও সম্ভব (পর্ব ৬৪)।

নজরদারি চার স্তরে: (১) service: অনুরোধের হার, p99, ত্রুটি, fallback-এর হার; (২) ডেটা: feature-এর missing আর বণ্টন (PSI-এর হিসাব পর্ব ৫৯-এ, আবার শেখানোর দরকার নেই); (৩) অনুমান: গড় প্রতিশ্রুতি zone-ভেদে, যা label আসার আগেই পাওয়া যায় (prediction drift); (৪) মান: label আসার পর zone-ভিত্তিক coverage আর pinball, holdout অংশে আলাদা করে। ঋতুর জন্য আলাদা reference: ঈদের সপ্তাহকে সাধারণ সপ্তাহের সঙ্গে তুলনা করলে প্রতিবছর ভুয়া সতর্কতা। Alert, dashboard আর rollback-এর বিস্তার পর্ব ৬৯-এ; incident-এর সময় কাজের ধারা Cloud & DevOps কোর্সের পর্ব ৬৭-এ, আর dashboard বানানো পর্ব ৬৬-এ।

পুনরাবৃত্তি আর খরচ. প্রথম সংস্করণ চালুর পর পরের ধাপ বাছতে হয় দাম দেখে: নতুন feature (courier-এর অবস্থান) কি latency আর রক্ষণাবেক্ষণের দাম মেটাবে? প্রতি সপ্তাহের retrain-এর বদলে মাসে একবার যথেষ্ট কি না, তা অতীতের ডেটায় backtest করে দেখা যায়। প্রতিটি নতুন অংশ (feature store, স্বয়ংক্রিয় retrain, আলাদা model প্রতি zone) একটি স্থায়ী দায়িত্ব যোগ করে। D. Sculley ও সহকর্মীরা ২০১৫ সালে NeurIPS-এ “Hidden Technical Debt in Machine Learning Systems” প্রবন্ধে যুক্তি দেন, বাস্তব ML system-এ model-এর কোড একটি ছোট অংশ, আর আশপাশের ডেটা, configuration আর নজরদারির কোডেই বেশিরভাগ ঋণ জমে।

৯ · দ্বিতীয় নকশা: পণ্যের সুপারিশ, আর ইন্টারভিউর চেকলিস্ট

একই দশ ধাপ একটি ভিন্ন সমস্যায়: বাজারঘরের home পাতায় “আপনার জন্য” ২০টি পণ্য। তুলনা করলে বোঝা যায়, কোন সিদ্ধান্ত সমস্যা থেকে আসে আর কোনটি পদ্ধতি থেকে।

সবচেয়ে বড় পার্থক্য label-এ। ETA-র label প্রায় নিরপেক্ষ (যদি feedback loop সামলানো হয়); সুপারিশের label পুরোপুরি model-এর আগের সিদ্ধান্তে বাঁধা, কারণ ক্রেতা শুধু দেখানো পণ্যেই click করতে পারেন। তাই সুপারিশে offline মূল্যায়ন আরও দুর্বল, আর online test বেশি জরুরি। পর্ব ৫৩-এর matrix factorization আর two-tower ধারণা candidate generation-এ, আর পর্ব ৩৬-এর boosting ranking-এ বসে।

ইন্টারভিউর ধরন

ML system design ইন্টারভিউ সাধারণত ৪৫ থেকে ৬০ মিনিটের একটি খোলা আলোচনা: “একটি ডেলিভারির সময়ের অনুমান নকশা করুন”। একটি কাজের সময়-ভাগ: প্রশ্ন আর পরিধি ৫–৮ মিনিট; framing আর metric ৮–১০; ডেটা, label আর feature ১০; model আর training ৮; serving, fallback আর হিসাব ৮; মূল্যায়ন, নজরদারি আর feedback loop ৮; শেষে ঝুঁকি আর পরের ধাপ। পরীক্ষক সাধারণত দেখেন আপনি প্রশ্ন জিজ্ঞাসা করেন কি না, সংখ্যা দিয়ে যুক্তি দেন কি না, আর trade-off নিজে থেকে বলেন কি না। পূর্ণ walkthrough-সহ অনুশীলন পর্ব ৭৭ (ML ধারণা আর system design ইন্টারভিউ — গভীর প্রশ্ন আর আলোচনা)-এ।

পুনরায় ব্যবহারযোগ্য চেকলিস্ট

• সিদ্ধান্ত, ব্যবহারকারী, পরিধির বাইরে কী, আর ML ছাড়া সরল উত্তর লিখেছি
• Target, অনুমানের মুহূর্ত, loss আর label কখন জানা যায়, তা ঠিক করেছি
• Offline metric, online metric, guardrail আর লঞ্চের নিয়ম আগে লিখেছি
• অনুরোধের হার, peak, latency budget আর storage হিসাব করেছি
• প্রতিটি feature অনুমানের মুহূর্তে পাওয়া যায় আর training-এ একই সংজ্ঞায় হিসাব হয়
• Baseline, প্রথম model আর কেন সেটি, latency-র মধ্যে
• Training pipeline-এ যাচাই, সময় ধরে ভাগ, version আর registry
• Timeout, fallback, মানুষের সুইচ আর cold start
• Shadow, canary, A/B test আর slice-ভিত্তিক মূল্যায়ন
• Feedback loop-এর পথ আর holdout; চার স্তরের নজরদারি আর retrain-এর নিয়ম

১০ · AI-এর যুগে — AI-এর বানানো ML নকশা যাচাই

“একটি ETA prediction system নকশা করো” বললে AI assistant প্রায়ই সুন্দর দেখতে একটি তালিকা দেয়: Kafka, feature store, deep learning model, Kubernetes, real-time retraining. তাতে প্রায়ই অনুপস্থিত থাকে প্রশ্ন, সংখ্যা, fallback আর feedback loop; আর অনেক সময় চোখে পড়ে এমন বড় সরঞ্জাম, যা দিনে ৫০,০০০ অর্ডারের দোকানের দরকার নেই। নিচের ভুলগুলো প্রায়ই দেখা যায়।

AI-এর দেওয়া ML নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি সংখ্যা নিজে আবার হিসাব করেছি, আর কোনগুলো ধরে নেওয়া তা আলাদা করেছি
• Loss আর offline metric যে পরিসংখ্যান মাপে, তা ব্যবসার সিদ্ধান্তের সঙ্গে মেলে কি না দেখেছি
• প্রতিটি feature-এর সময় যাচাই করে leakage খুঁজেছি
• একটি সরল baseline-এর সঙ্গে কয়েকটি seed বা সময়ের ভাগে তুলনা আছে
• Fallback, feedback loop আর holdout-এর কথা না থাকলে নিজে যোগ করেছি
• কোনো আসল ক্রেতার নাম, ঠিকানা বা অর্ডারের তথ্য AI-তে পেস্ট করিনি