GenAI system design — chatbot, RAG app আর guardrail

এই পর্ব আগের অনেকগুলো পর্বের টুকরো জোড়া দেয়: পর্ব ৬৫-এর token আর latency, পর্ব ৬৯-এর RAG, পর্ব ৭০-এর মূল্যায়ন, পর্ব ৭৩-এর নিরাপত্তা। Load balancing, cache, rate limiting আর observability-র সাধারণ তত্ত্ব সিস্টেম ডিজাইন কোর্সে আছে; এখানে শুধু LLM-এর বেলায় যা আলাদা, সেটুকু। Desktop run: Python 3.12, torch 2.15.0, transformers 5.22.2, sentence-transformers 6.2.0, লেখার সময়ে। Model দুটি, token ছাড়া নামানো যায়: intfloat/multilingual-e5-small (MIT) cache আর খোঁজায়, Qwen/Qwen2.5-0.5B-Instruct (Apache 2.0) throughput মাপায়। বাজারঘরের নীতি, প্রশ্ন, নম্বর আর অর্ডার সম্পূর্ণ কাল্পনিক। সব সংখ্যা একটি স্থানীয় run-এর, ছোট model আর ছোট ডেটায়; সাধারণ ফল নয়।

১ · প্রয়োজন আগে — সহায়ক কী করবে, কত দ্রুত, কতটা নিরাপদ

System design-এর প্রথম ধাপ প্রয়োজন লেখা (সিস্টেম ডিজাইন কোর্সের পর্ব ২)। GenAI পণ্যে প্রয়োজনের তালিকায় কয়েকটি নতুন লাইন যোগ হয়: উত্তর কতটা নির্ভুল হবে, না জানলে কী বলবে, আর কোন তথ্য model-এর কাছে যাবেই না। বাজারঘরের বাংলা help chatbot-এর জন্য আমাদের লেখা প্রয়োজন:

দুটি জিনিস লক্ষ করুন। প্রথমত, availability-তে “কোনো না কোনো উত্তর”: বড় model বন্ধ থাকলে ছোট model বা “প্রতিনিধির কাছে পাঠানো হলো”-ও গ্রহণযোগ্য। এটি graceful degradation, §৭-এ মাপা হবে। দ্বিতীয়ত, প্রতিটি প্রয়োজনের পাশে একটি মাপ আছে। “ভালো উত্তর দেবে” প্রয়োজন নয়; “এই ৪১টি প্রশ্নের eval set-এ এত শতাংশ, উত্তরহীন প্রশ্নে এত শতাংশ abstain” প্রয়োজন।

২ · Token-এ ধারণক্ষমতার হিসাব — দিনে কত অনুরোধ, কয়টি GPU

সাধারণ back-of-the-envelope হিসাব (সিস্টেম ডিজাইন কোর্সের পর্ব ৩) চার ধাপে: দিনে অনুরোধ → ব্যস্ততম সময়ে প্রতি সেকেন্ডে অনুরোধ (RPS) → প্রতি সেকেন্ডে token → মাপা ক্ষমতা দিয়ে ভাগ। সূত্রে:

peak RPS = R_day × p ÷ ৩,৬০০  ·  replica = ⌈peak RPS ÷ (μ × u)⌉

এখানে R_day দিনে মোট অনুরোধ, p ব্যস্ততম ঘণ্টায় তার অংশ (peak-এর ভাগ), μ (মিউ) একটি replica প্রতি সেকেন্ডে কতগুলো অনুরোধ শেষ করে (নিজের prompt-দৈর্ঘ্যে মাপা), আর u ব্যবহারের লক্ষ্য, যেমন ০.৬: পুরো ক্ষমতায় চালালে queue লম্বা হয়, তাই কিছু ফাঁকা রাখা। শেষে একটি বাড়তি replica (N+1). Input (prefill) আর output (decode) GPU-র কাছে আলাদা কাজ, hosted API-তে দামও আলাদা (পর্ব ৬৫), তাই token দুই ভাগে গোনা।

μ কোথা থেকে? মুখস্থ সংখ্যা থেকে নয়, নিজের যন্ত্রে নিজের ধরনের prompt চালিয়ে। নিচে Qwen2.5-0.5B-Instruct, GPU-তে bf16, HF transformers-এর সাধারণ generate দিয়ে: বাজারঘরের তিনটি নথিসহ RAG prompt (প্রায় ১,০০০ token), প্রতিটি উত্তরে ঠিক ১২৮টি নতুন token, greedy, batch ১ থেকে ৩২.

~/bazarghar-dl$ uv run python tput.py   # সত্যিকারের run, GPU-তে
torch 2.15.0+cu132 transformers 5.22.2 | bf16, greedy, new tokens 128
batch  1  input    948 tok/req  prefill   46.8 ms (  20264 in-tok/s)  generate  2.31 s  ->   55.5 out-tok/s,  0.43 req/s
batch  4  input   1003 tok/req  prefill  217.8 ms (  18422 in-tok/s)  generate  2.85 s  ->  179.5 out-tok/s,  1.40 req/s
batch 16  input   1000 tok/req  prefill  862.0 ms (  18561 in-tok/s)  generate  4.14 s  ->  494.1 out-tok/s,  3.86 req/s
batch 32  input   1000 tok/req  prefill 2001.2 ms (  15990 in-tok/s)  generate  7.87 s  ->  520.3 out-tok/s,  4.06 req/s
peak GPU memory allocated: 2.63 GiB

নিচের কোড একই হিসাব কয়েকটি অবস্থায় চালায়: সাধারণ দিন, cache-এ ১৯% ঠিক hit (§৫-এর সবচেয়ে নিরাপদ সেটিংয়ে মাপা হার), আর ক্যাম্পেইনের দিনে তিন গুণ traffic. শেষ কলামে Little-এর সূত্র L = λW: গড়ে একসঙ্গে কতগুলো অনুরোধ GPU-তে চলছে, যা batch-এর slot-এর সঙ্গে মেলাতে হয়।

import math
MU = 3.86       # মাপা: একটি replica, batch 16, ~1000 input + 128 output token-এ অনুরোধ/সেকেন্ড
W = 4.14         # মাপা: সেই অবস্থায় একটি অনুরোধের মোট সময় (সেকেন্ড)

def plan(name, per_day, peak_share=0.12, tin=1000, tout=128, hit=0.0, util=0.6):
    rps = per_day * peak_share / 3600            # ব্যস্ততম ঘণ্টার গড় অনুরোধ/সেকেন্ড
    llm = rps * (1 - hit)                        # cache-এ ঠিক hit বাদে যা LLM-এ যায়
    n = math.ceil(llm / (MU * util))             # ব্যবহারের লক্ষ্য util রেখে replica
    inflight = llm * W                           # Little's law: L = λW
    print(f"{name}: peak {rps:.2f} req/s, in {rps*tin:.0f} tok/s, out {rps*tout:.0f} tok/s")
    print(f"   LLM {llm:.2f} req/s -> {n} replica (+1 = {n+1}), in-flight {inflight:.1f}")
    return n

plan("সাধারণ দিন", 60_000)
plan("cache 19%", 60_000, hit=0.19)
plan("ক্যাম্পেইন x3", 180_000)
plan("ক্যাম্পেইন+cache", 180_000, hit=0.19)
# বাংলা prompt-এ token বেশি হলে MU কমে; সেটি নতুন করে মাপতে হয়, অনুপাতে ভাগ করে নয়
for util in (0.5, 0.6, 0.8):
    print(f"util {util}: capacity per replica {MU*util:.2f} req/s")

সাধারণ দিন: peak 2.00 req/s, in 2000 tok/s, out 256 tok/s
   LLM 2.00 req/s -> 1 replica (+1 = 2), in-flight 8.3
cache 19%: peak 2.00 req/s, in 2000 tok/s, out 256 tok/s
   LLM 1.62 req/s -> 1 replica (+1 = 2), in-flight 6.7
ক্যাম্পেইন x3: peak 6.00 req/s, in 6000 tok/s, out 768 tok/s
   LLM 6.00 req/s -> 3 replica (+1 = 4), in-flight 24.8
ক্যাম্পেইন+cache: peak 6.00 req/s, in 6000 tok/s, out 768 tok/s
   LLM 4.86 req/s -> 3 replica (+1 = 4), in-flight 20.1
util 0.5: capacity per replica 1.93 req/s
util 0.6: capacity per replica 2.32 req/s
util 0.8: capacity per replica 3.09 req/s

৩ · পুরো নকশা — একটি অনুরোধের যাত্রা

নিচের ছবিতে বাজারঘরের সহায়কের অংশগুলো। ওপর থেকে নিচে একটি অনুরোধের পথ; ডান দিকে cache hit-এর সংক্ষিপ্ত পথ আর fallback; নিচে সব অংশ থেকে log আর trace.

প্রতিটি অংশের কাজ এক লাইনে। Gateway (সিস্টেম ডিজাইন পর্ব ১১) লগইন যাচাই করে, trace id দেয়। Rate limiter একজন গ্রাহক বা একটি ক্লায়েন্টের অনুরোধের হার বাঁধে; LLM-এ সীমা শুধু অনুরোধে নয়, token-এও রাখা যায়, কারণ একটি লম্বা অনুরোধ দশটি ছোটর সমান খরচ করে (সিস্টেম ডিজাইন পর্ব ৪৯)। Input guard PII ঢাকে, যাতে cache, log বা hosted API আসল নম্বর না পায়। Cache (§৫), router (§৪) আর RAG (পর্ব ৬৯)-এর পরে LLM serving GPU-তে অনেক অনুরোধ একসঙ্গে batch করে চালায় (পর্ব ৮৩ · LLM serving). Output guard শেষ পরীক্ষা (§৬), আর log ছাড়া কিছুরই মান মাপা যায় না (§৮)।

নিচের stepper-এ একটি সত্যিকারের অনুরোধ এই পথে যায়। PII ঢাকা, cache-এর cosine, খোঁজার ফল, token-এর সংখ্যা আর উত্তর desktop run থেকে; rate limiter-এর অবস্থা আর span-এর সময় উদাহরণ হিসেবে বসানো (নমুনা)।

৪ · Model routing আর fallback — ছোট model, বড় model, আর না পারলে কী

Model routing মানে প্রতিটি অনুরোধের জন্য উপযুক্ত model বা পথ বেছে নেওয়া। বাজারঘরে তিনটি সহজ নিয়ম যথেষ্ট শুরুতে: (ক) অর্ডার id থাকলে অর্ডার-tool-এর পথ, cache বাদ; (খ) সাধারণ এক-তথ্যের নীতি প্রশ্ন ছোট model-এ; (গ) দুই নথির, হিসাবের বা অভিযোগের প্রশ্ন বড় model-এ। Router নিজে হতে পারে নিয়ম, একটি ছোট classifier (পর্ব ৪২, পর্ব ৪৮) বা একটি ছোট LLM. পর্ব ৮৬ · ক্যাপস্টোনে এই router-এর classifier আপনি নিজে বানাবেন।

গবেষণায় এর দুটি পরিচিত রূপ আছে। Cascade: আগে ছোট model, তার উত্তরের আত্মবিশ্বাস কম হলে বড় model; Chen, Zaharia ও Zou-র ২০২৩ সালের FrugalGPT প্রবন্ধ এভাবে খরচ কমানোর কথা রিপোর্ট করে। আগে থেকে route: প্রশ্ন দেখেই একটি শেখা router ঠিক করে কোন model; ২০২৪ সালের RouteLLM প্রবন্ধ এমন router শেখানোর একটি উপায় দেখায়। তাদের সাশ্রয়ের সংখ্যা সেই প্রবন্ধের ডেটার; বাজারঘরে নিজের eval set-এ মাপতে হবে।

Fallback হলো পরিকল্পিত দ্বিতীয় পথ, যখন প্রথম পথ সময়মতো উত্তর দেয় না। ক্রমটি সাধারণত: বড় model → (timeout বা ত্রুটি) → ছোট model → (তাও না হলে) নির্দিষ্ট বার্তা আর মানুষের কাছে টিকিট। এখানে মাপা তথ্য মনে রাখুন: পর্ব ৬৯-এ Qwen2.5-1.5B RAG-সহ ৩৩টি উত্তরযোগ্য প্রশ্নের ১৯–২০টি ঠিক করেছিল, আর উত্তরহীন ৮টির মাত্র ১–২টিতে “নেই” বলেছিল। ছোট model-এ fallback মানে মান কমানো; তাই fallback-এর উত্তরেও output guard চলবে, আর সেই পথের মান আলাদা করে মাপতে হবে। Circuit breaker (সিস্টেম ডিজাইন পর্ব ৪৮) বড় model বারবার ব্যর্থ হলে কিছুক্ষণ সরাসরি fallback-এ পাঠায়, যাতে প্রতিটি অনুরোধ timeout পর্যন্ত অপেক্ষা না করে।

৫ · Cache — exact আর semantic, আর ভুল hit-এর দাম

সাধারণ cache-এর তত্ত্ব (cache-aside, TTL, invalidation) সিস্টেম ডিজাইন কোর্সের পর্ব ২৮ আর পর্ব ২৯-এ। LLM ব্যবস্থায় তিন রকম cache থাকে, আর এরা আলাদা জিনিস:

Semantic cache-এর ধারণা সহজ: আগের প্রশ্নগুলোর embedding রাখা, নতুন প্রশ্নের সবচেয়ে কাছেরটি খোঁজা (পর্ব ৬৭), আর cosine একটি সীমা τ (tau) ছাড়ালে তার উত্তর ফেরত দেওয়া। GPTCache-এর মতো open-source project এই নকশা জনপ্রিয় করেছে। প্রশ্ন হলো, বাংলা help desk-এ τ কত হবে, আর তাতে কতটা ভুল hit (false hit) আসে। মাপার জন্য হাতে লেখা: পর্ব ৬৯-এর প্রশ্ন থেকে ১৬টি cache entry আর ৫৯টি নতুন প্রশ্ন; model card-এর কথামতো symmetric কাজে দুই পাশেই "query: " prefix. এর ৩৯টির উত্তর কোনো একটি entry-র সঙ্গে হুবহু এক (২টি হুবহু পুনরাবৃত্তি, ১৬টি বাংলায় অন্যভাবে বলা, ১৩টি Banglish, ৮টি ইংরেজি)। বাকি ২০টি দেখতে কাছাকাছি, কিন্তু উত্তর আলাদা: “ঢাকা সিটিতে ফ্রিজের ডেলিভারি চার্জ কত?” (৫০০ টাকা, ৬০ নয়), “শনিবার কাস্টমার কেয়ার কখন খোলে?” (সকাল ৯টা, বিকেল ৩টা নয়)।

~/bazarghar-dl$ uv run python cache_run.py   # সত্যিকারের run, CPU, ছোট করে দেখানো
torch 2.15.0 transformers 5.22.2 sentence-transformers 6.2.0 | CPU threads 3
cache entries 16, incoming 59 (should-hit 39, near-miss 20); embed per query 7.4 ms (CPU, batch 1)
exact cache (normalised text): hits 2/59, wrong 0
nearest entry is the right one for 35/39 should-hit queries
tau   hit-rate  right-hits  false-hits  false-hit-share
0.84  0.915     34/39       20          0.370
0.88  0.746     26/39       18          0.409
0.92  0.441     16/39       10          0.385
0.95  0.254      9/39        6          0.400
0.97  0.119      5/39        2          0.286
repeat    n= 2 cos min 0.976 median 0.986 max 0.996
bn        n=16 cos min 0.861 median 0.947 max 0.989
banglish  n=13 cos min 0.791 median 0.873 max 0.914
en        n= 8 cos min 0.869 median 0.897 max 0.927
near      n=20 cos min 0.835 median 0.920 max 0.976

নিচের stepper-এ একই cache entry (“ঢাকা সিটিতে ডেলিভারি চার্জ কত?”, উত্তর ৬০ টাকা) আর τ = ০.৯৫-এ তিনটি সত্যিকারের প্রশ্ন।

তাহলে উপায়? তিনটি পথ। (ক) শুধু cosine নয়, অর্থের মূল শব্দও মেলানো: জায়গা, পণ্য, দিন আর পেমেন্টের শব্দ দুই প্রশ্নে একই থাকলেই hit. (খ) প্রশ্ন নয়, intent ধরে cache: router-এর classifier প্রশ্নকে “ঢাকার ডেলিভারি চার্জ”-এর মতো একটি নির্দিষ্ট FAQ-id দেয়, আর cache-এর key সেই id; ভুল hit তখন classifier-এর ভুলের সমান। (গ) Cache শুধু স্থির উত্তরে, নীতি বদলালে পুরো cache মোছা। নিচের কোড সত্যিকারের run-এর ৫৯টি cosine (পাতায় cache_rows.tsv হিসেবে রাখা) নিয়ে sweep করে, আর পথ (ক)-এর একটি ছোট নিয়ম যোগ করে দেখায়। প্রথমবার চালাতে pandas আর matplotlib নামতে কয়েক সেকেন্ড লাগে।

import numpy as np, pandas as pd
import matplotlib.pyplot as plt
df = pd.read_csv("cache_rows.tsv", sep="\t")     # সত্যিকারের run-এর cosine, ৫৯টি প্রশ্ন
# ok = 1: সবচেয়ে কাছের cache entry-র উত্তর এই প্রশ্নেও হুবহু ঠিক
SLOTS = [("ঢাকা", "dhaka"), ("গাজীপুর", "gazipur"), ("চট্টগ্রাম",), ("ভারত", "india"),
         ("ফ্রিজ", "বড় পণ্য"), ("express",), ("কার্ড",), ("bkash", "বিকাশ"), ("রিফান্ড", "refund"),
         ("শুক্রবার", "friday"), ("শনিবার",), ("১২ মাস",), ("ব্যাটারি", "battery"), ("ফ্রি", "free")]
def same_slots(a, b):                 # দুই প্রশ্নে একই জায়গা, পণ্য, দিন, পেমেন্টের শব্দ আছে কি
    a, b = a.lower(), b.lower()
    return all(any(w in a for w in g) == any(w in b for w in g) for g in SLOTS)
df["slot_ok"] = [same_slots(q, c) for q, c in zip(df["query"], df["cached"])]

rows = []
for tau in np.arange(0.84, 0.985, 0.02):
    hit = df["cos"] >= tau - 1e-9
    g = hit & df["slot_ok"]
    rows.append([round(tau, 2), hit.mean(), int((hit & (df.ok == 1)).sum()), int((hit & (df.ok == 0)).sum()),
                 int((g & (df.ok == 1)).sum()), int((g & (df.ok == 0)).sum())])
t = pd.DataFrame(rows, columns=["tau", "hit_rate", "right", "false", "right+slot", "false+slot"])
print(t.round(3).to_string(index=False))
print(df.groupby("kind")["cos"].median().round(3).to_dict())

plt.figure(figsize=(5.2, 3.4))
plt.plot(t.tau, t.right, "o-", label="right hits")
plt.plot(t.tau, t["false"], "s-", label="false hits")
plt.plot(t.tau, t["false+slot"], "s--", label="false hits + slot guard")
plt.xlabel("similarity threshold (tau)"); plt.ylabel("queries (of 59)")
plt.title("Semantic cache: e5-small, one local run"); plt.legend(); plt.grid(alpha=.3)
plt.show()

 tau  hit_rate  right  false  right+slot  false+slot
0.84     0.915     34     20          34           6
0.86     0.881     33     19          33           6
0.88     0.746     26     18          26           6
0.90     0.644     21     17          21           6
0.92     0.458     16     11          16           2
0.94     0.305     11      7          11           0
0.96     0.203      7      5           7           0
0.98     0.068      4      0           4           0
{'banglish': 0.873, 'bn': 0.947, 'en': 0.897, 'near': 0.921, 'repeat': 0.986}

৬ · Guardrail — input আর output-এর পাহারা, PII ঢাকা

Guardrail হলো model-এর বাইরে বসানো পরীক্ষা, যা model-কে বিশ্বাস না করেই নিয়ম প্রয়োগ করে। পর্ব ৭৩-এ মাপা শিক্ষাটি এখানে নকশার নিয়ম: নিয়মভিত্তিক input detector চেনা আক্রমণ ধরে কিন্তু নতুন শব্দের আক্রমণ ছাড়ে, আর output filter (canary নিয়ম আর URL allowlist) ১.৫B-এর ৩৯৬টি উত্তরের সব ১০টি ক্ষতিকর উত্তর থামিয়েছিল। তাই ভারী কাজ output-এর দিকে, আর কোনো একটি স্তরের ওপর পুরো ভরসা নয় (defense in depth).

PII masking শুরু হয় সবচেয়ে সস্তা স্তর দিয়ে: regex. বাংলাদেশের মোবাইল নম্বর সাধারণত ০১ দিয়ে শুরু ১১ অঙ্ক, সামনে +৮৮০ থাকতে পারে; বাংলা অঙ্কে লেখাও সাধারণ। নিচের কোড তিন ধরনের PII ঢাকে আর হাতে লেখা ১০টি বানানো লেখায় precision আর recall মাপে (AI-এর ভিত্তি কোর্সের পর্ব ৬০)। সব নম্বর ইচ্ছে করে বানানো (০০০০০-এ ভরা), email-এর domain .invalid, যা কখনো আসল ঠিকানা হয় না। কোনো বাক্য যেমন ইনভয়েস নং 01800000006 ইচ্ছে করে ফাঁদ।

import re
from collections import Counter
B2E = str.maketrans("০১২৩৪৫৬৭৮৯", "0123456789")   # এক অক্ষরে এক অক্ষর: অবস্থান বদলায় না
RULES = {"PHONE": r"(?<!\d)(?:\+?880[\s-]?|0)1[3-9]\d{2}[\s-]?\d{3}[\s-]?\d{3}(?!\d)",
         "EMAIL": r"[A-Za-z0-9._%+-]+@[A-Za-z0-9-]+(?:\.[A-Za-z0-9-]+)+",
         "ORDER": r"(?i)\bBG-?\d{4}-?\d{6}\b"}
def mask(text):
    t = text.translate(B2E)
    found = [(m.start(), m.end(), k) for k, p in RULES.items() for m in re.finditer(p, t)]
    for s, e, k in sorted(found, reverse=True):     # পেছন থেকে বদলালে আগের অবস্থান ঠিক থাকে
        text = text[:s] + f"[{k}]" + text[e:]
    return text, Counter((k, t[s:e]) for s, e, k in found)
P, O, E = "PHONE", "ORDER", "EMAIL"                 # সব লেখা আর নম্বর বানানো; GOLD = যা ঢাকা উচিত
DATA = [("আমার নম্বর ০১৭০০-০০০০০১, অর্ডার BG-2026-004817 এখনো আসেনি।", [(P, "01700-000001"), (O, "BG-2026-004817")]),
 ("call me at +880 1800 000 002 or mail rahim.k@example.invalid", [(P, "+880 1800 000 002"), (E, "rahim.k@example.invalid")]),
 ("order bg2026004817 er status ki? phone 8801500000003", [(O, "bg2026004817"), (P, "8801500000003")]),
 ("ট্র্যাকিং নম্বর 01900000000008 দিয়ে খুঁজুন", []),
 ("বিকাশ নম্বর 019 0000 0004, টাকা পাঠিয়েছি", [(P, "019 0000 0004")]),
 ("মেইল: karim_bd(at)example.invalid", [(E, "karim_bd(at)example.invalid")]),
 ("ইনভয়েস নং 01800000006, দাম ১,২৫০ টাকা", []),
 ("অর্ডার BG-2026-118204 আর BG-2026-118205 দুটোই ভাঙা", [(O, "BG-2026-118204"), (O, "BG-2026-118205")]),
 ("nadia.h+orders@shop.example.invalid-এ রসিদ, ফোন ০১৩০০০০০০০৫", [(E, "nadia.h+orders@shop.example.invalid"), (P, "01300000005")]),
 ("রেফারেন্স 017000000007, সময় 10:30", [])]
tp, fp, fn = Counter(), Counter(), Counter()
for text, gold in DATA:
    masked, pred = mask(text); g = Counter(gold)
    for (k, v), n in pred.items(): tp[k] += min(n, g[(k, v)]); fp[k] += max(0, n - g[(k, v)])
    for (k, v), n in g.items(): fn[k] += max(0, n - pred[(k, v)])
    print(masked)
for k in RULES:
    pr = tp[k] / (tp[k] + fp[k]) if tp[k] + fp[k] else 0.0
    print(f"{k:5} TP {tp[k]} FP {fp[k]} FN {fn[k]}  precision {pr:.2f}  recall {tp[k] / (tp[k] + fn[k]):.2f}")

আমার নম্বর [PHONE], অর্ডার [ORDER] এখনো আসেনি।
call me at [PHONE] or mail [EMAIL]
order [ORDER] er status ki? phone [PHONE]
ট্র্যাকিং নম্বর 01900000000008 দিয়ে খুঁজুন
বিকাশ নম্বর 019 0000 0004, টাকা পাঠিয়েছি
মেইল: karim_bd(at)example.invalid
ইনভয়েস নং [PHONE], দাম ১,২৫০ টাকা
অর্ডার [ORDER] আর [ORDER] দুটোই ভাঙা
[EMAIL]এ রসিদ, ফোন [PHONE]
রেফারেন্স 017000000007, সময় 10:30
PHONE TP 4 FP 1 FN 1  precision 0.80  recall 0.80
EMAIL TP 1 FP 1 FN 2  precision 0.50  recall 0.33
ORDER TP 4 FP 0 FN 0  precision 1.00  recall 1.00

৭ · ব্যর্থতার নকশা — timeout, retry, rate limit আর degraded mode

LLM ব্যবস্থায় ব্যর্থতা রোজকার ঘটনা: GPU-র slot ভরা, hosted API-র rate limit, vector store-এর বিরতি। প্রতিটি অংশের জন্য চারটি প্রশ্ন আগে থেকে ঠিক রাখুন: কতক্ষণ অপেক্ষা (timeout), আবার চেষ্টা কি না (retry), না পারলে বিকল্প কী (fallback), আর কখন অনুরোধ নেওয়াই বন্ধ (load shedding). বাজারঘরে মোট সময়ের সীমা ৮ সেকেন্ড; তার ভেতরে RAG-এর ভাগ ০.৫ সেকেন্ড, বড় model-এর প্রথম token-এর ২ সেকেন্ড। Retry শুধু এক স্তরে, একবার, backoff-সহ (ভাবনার প্রশ্ন ৪)। ক্রমটি এমন: বড় model → ছোট model → “আপনার প্রশ্নটি একজন প্রতিনিধির কাছে পাঠানো হলো” আর টিকিট। Rate limiter-এর token bucket ছোট burst দেয়, কিন্তু গড় হার বাঁধে।

নকশাটি কাজ করে কি না, আগে simulator-এ দেখা সস্তা। নিচের কোড ক্যাম্পেইনের আধা ঘণ্টা চালায়: প্রতি সেকেন্ডে গড়ে ৬.০টি অনুরোধ (এলোমেলো, seed ৭), একটি ক্লায়েন্ট সব অনুরোধের ৪% পাঠায় (ভুল কোড বা অপব্যবহার), প্রতিটি replica-তে ১৬টি slot, প্রতিটি অনুরোধের সময় §২-এর মাপা ৪.১৪ সেকেন্ডের ±২০%. মোট সময় ৮ সেকেন্ড পেরোবে মনে হলে অনুরোধ ছোট model-এ যায় (ধরা হয়েছে ১.৫ সেকেন্ড)। এটি একটি সরল মডেল (নমুনা অনুমানসহ), আসল serving engine নয়: batch বড় হলে প্রতিটি অনুরোধ ধীর হয়, এখানে তা ধরা নেই।

import numpy as np
SVC, SLOTS = 4.14, 16            # মাপা: batch 16-এ একটি অনুরোধের সময় (সে.), replica প্রতি slot
TOK, BUDGET, LAM = 1000 + 128, 8.0, 6.0   # token/অনুরোধ, মোট সময়ের সীমা, ক্যাম্পেইনের peak req/s

def run(replicas, p_hit, seed=7, T=1800):
    rng = np.random.default_rng(seed)
    t = np.cumsum(rng.exponential(1 / LAM, int(LAM * T * 1.2))); t = t[t < T]
    user = rng.integers(0, 3000, t.size)
    user[rng.random(t.size) < 0.04] = 7                 # একটি ক্লায়েন্ট সব traffic-এর ৪%
    free, bucket, res = np.zeros(SLOTS * replicas), {}, []
    for ti, u in zip(t, user):
        tok, last = bucket.get(u, (5.0, ti))            # token bucket: burst ৫, প্রতি ২০ সে. ১টি
        tok = min(5.0, tok + (ti - last) / 20)
        if tok < 1:
            bucket[u] = (tok, ti); res.append(("429", 0.0, 0)); continue
        bucket[u] = (tok - 1, ti)
        if rng.random() < p_hit:
            res.append(("cache", 0.05, 0)); continue
        k = free.argmin(); wait = max(0.0, free[k] - ti); svc = SVC * rng.uniform(0.8, 1.2)
        if wait + svc > BUDGET:                         # সীমা পেরোবে: ছোট model-এ fallback
            res.append(("fallback", 1.5, TOK)); continue
        free[k] = ti + wait + svc; res.append(("big", wait + svc, TOK))
    kind = np.array([r[0] for r in res]); lat = np.array([r[1] for r in res])
    ok = kind != "429"
    p50, p95 = np.percentile(lat[ok], [50, 95])
    c = {k: int((kind == k).sum()) for k in ["big", "fallback", "cache", "429"]}
    big_tok = sum(r[2] for r in res if r[0] == "big") / 1e6
    print(f"replica {replicas}, hit {p_hit:.2f}: {c}")
    print(f"   p50 {p50:.2f}s  p95 {p95:.2f}s  big-model tokens {big_tok:.2f}M")

for rep, h in [(1, 0.0), (1, 0.19), (2, 0.0), (2, 0.19)]:
    run(rep, h)

replica 1, hit 0.00: {'big': 7300, 'fallback': 3139, 'cache': 0, '429': 312}
   p50 7.01s  p95 7.90s  big-model tokens 8.23M
replica 1, hit 0.19: {'big': 7117, 'fallback': 1355, 'cache': 1967, '429': 312}
   p50 6.45s  p95 7.83s  big-model tokens 8.03M
replica 2, hit 0.00: {'big': 10439, 'fallback': 0, 'cache': 0, '429': 312}
   p50 4.16s  p95 4.91s  big-model tokens 11.78M
replica 2, hit 0.19: {'big': 8472, 'fallback': 0, 'cache': 1967, '429': 312}
   p50 3.94s  p95 4.87s  big-model tokens 9.56M

৮ · Observability, CI-তে eval আর ডেটার গোপনীয়তা

সাধারণ সেবায় observability মানে log, metric আর trace (সিস্টেম ডিজাইন পর্ব ৫০)। LLM সেবায় প্রতিটি trace-এ আরও কয়েকটি ক্ষেত্র লাগে: কোন model আর কোন prompt-সংস্করণ, input আর output token, TTFT, কোন নথি এল (id আর score), cache hit বা miss, কোন guard আটকাল, আর কোন পথ (বড় model, fallback, মানুষ)। খরচ টাকায় না লিখে token আর GPU-সেকেন্ডে লিখলে দাম বদলালেও হিসাব টেকে। অভিযোগ এলে trace id ধরে দেখা যায়: ভুল নথি এসেছিল, না model ভুল পড়েছিল (পর্ব ৭০)।

CI-তে eval. Prompt, model, chunking বা threshold বদলানো মানে কোড বদলানো; প্রতিটি বদল একটি স্থির eval set-এ চলবে, ঠিক unit test-এর মতো (পর্ব ৬৬)। বাজারঘরের জন্য তিনটি set: (ক) RAG-এর প্রশ্ন, উত্তরহীন প্রশ্নসহ (পর্ব ৭০); (খ) নিরাপত্তার canary আর red-team লেখা (পর্ব ৭৩); (গ) cache আর PII-এর set, এই পর্বের মতো। নতুন সংস্করণ কোনো set-এ উল্লেখযোগ্যভাবে খারাপ হলে merge নয় (CI দেখে)। তারপর traffic-এর ছোট অংশে canary release আর মানুষের পর্যালোচনা (মেশিন লার্নিং কোর্সের পর্ব ৬৯)।

গোপনীয়তা আর ডেটা রাখা. Data minimisation-এর নীতি এখানে সরাসরি নকশা: log-এ শুধু ঢাকা লেখা; trace-এ গ্রাহকের id-এর বদলে একটি ছদ্ম-id; পুরো কথোপকথন রাখলে নির্দিষ্ট দিনের পর মুছে ফেলা (data retention-এর নিয়ম), আর eval বা fine-tuning-এ ব্যবহারের আগে আলাদা অনুমতি আর আবার ঢাকা। Hosted API-র প্রদাতা লেখা কতদিন রাখে, তা তাঁদের নথি আর চুক্তিতে, তারিখসহ পড়ুন (ভাবনার প্রশ্ন ৫)। বাংলাদেশে ২০২৬ সালে ব্যক্তিগত উপাত্ত সুরক্ষা আইন ২০২৬ (৬৩ নং), জাতীয় উপাত্ত ব্যবস্থাপনা আইন ২০২৬ (৮০ নং) আর সাইবার সুরক্ষা আইন ২০২৬ (৮১ নং) হয়েছে। এগুলো প্রাসঙ্গিক হতে পারে; কোন ধারা কীভাবে প্রযোজ্য, তা নিয়ে আইনজ্ঞের পরামর্শ নিন। সাধারণ privacy engineering সাইবার নিরাপত্তা কোর্সের পর্ব ৭০-এ।

৯ · নিজে চালানো, নাকি hosted API — build বনাম buy

LLM-এর দুটি মূল পথ: hosted API, অথবা নিজের GPU-তে open-weight model (Qwen, Llama-র মতো)। দাম বদলায়, তাই এখানে তুলনা দায়িত্বের, দামের নয়।

অনেক দল দুটি একসঙ্গে রাখে: সহজ প্রশ্ন নিজের ছোট model-এ, কঠিনগুলো hosted API-তে, বা উল্টো দিকে fallback. দুই পথেই নিজের eval set লাগে: বাংলা প্রশ্নে মান আপনাকেই মাপতে হবে। Container আর Kubernetes-এ নিজের serving চালানোর ভিত্তি ক্লাউড ও DevOps কোর্সের পর্ব ৩৬ থেকে; model export আর deploy-এর পথ পর্ব ৮৪ · Deep learning model deploy-এ।

১০ · AI-এর যুগে — GenAI নকশার দাবি যাচাই

AI assistant একটি “production-ready chatbot architecture” কয়েক সেকেন্ডে এঁকে দেয়: বাক্স, তির, সব নাম ঠিক। ভুলগুলো থাকে সংখ্যায় আর অনুমানে:

GenAI নকশার চেকলিস্ট

• প্রতিটি প্রয়োজনের পাশে একটি মাপ আর লক্ষ্য লেখা আছে
• GPU সংখ্যা নিজের prompt-দৈর্ঘ্যে মাপা throughput থেকে, headroom-সহ
• Semantic cache-এর ভুল hit উত্তর-আলাদা প্রশ্নসহ set-এ মাপা; ব্যক্তিগত প্রশ্ন cache-এর বাইরে
• PII ঢাকা হয় সবার আগে; detector-এর precision/recall জানা
• Timeout, সীমিত retry, fallback আর মানুষের পথ আছে; প্রতিটি পথের হার মাপা হয়
• Eval set CI-তে চলে; log-এ শুধু ঢাকা লেখা, মেয়াদসহ