এই পর্বে যা শিখবেন
- Architecture, ডেটা বনাম model আর training-এর ভুলের প্রশ্নে প্রমাণসহ উত্তর দেওয়া
- Prompt, RAG আর fine-tuning-এর মধ্যে কাজ, খরচ আর ঝুঁকি দেখে বাছাই করা
- LLM অ্যাপের মূল্যায়ন, hallucination আর নিরাপত্তার প্রশ্নে n, CI আর সীমা বলা
- Token, latency, KV cache আর বাংলার বাড়তি token হিসাব করে নকশায় বসানো
- ৪৫ মিনিটে একটি GenAI ব্যবস্থা নকশা করা, rubric জেনে; নিজের প্রকল্প সৎভাবে বলা
এই পাতা সম্পর্কে: প্রশ্নগুলো কোনো নির্দিষ্ট প্রতিষ্ঠান, পরীক্ষা বা নিয়োগ থেকে নেওয়া নয়; ML engineer, NLP বা LLM engineer আর AI engineer-এর আলাপে এ ধরনের প্রশ্ন প্রায়ই আসে। বাজারঘর কাল্পনিক দোকান। উত্তরের সংখ্যাগুলো এই কোর্সের পর্বগুলোর সত্যিকারের run থেকে, প্রতিটি একটি ছোট model আর একটি বা কয়েকটি run-এর মাপ, সাধারণ সত্য নয়; mock-এর ট্রাফিক ধরে নেওয়া। ব্লকগুলো ব্রাউজারের Python-এ চলে (NumPy 2.4.6, SciPy). মৌলিক প্রশ্ন আগের দুই কোর্সে আছে: AI-এর ভিত্তি কোর্সের ইন্টারভিউ, MCQ, numerical ও লিখিত-মৌখিক পাতা, আর মেশিন লার্নিং কোর্সের ধারণার ইন্টারভিউ, coding ইন্টারভিউ, MCQ, numerical ও লিখিত-মৌখিক পাতা। এই মডিউলের পাশের পাতা: পর্ব ৮৭ (Numerical সমস্যার অনুশীলন), পর্ব ৮৮ (MCQ প্রশ্নব্যাংক), পর্ব ৮৯ (লিখিত ও মৌখিক প্রশ্ন) আর পর্ব ৯০ (Deep learning coding ইন্টারভিউ)।
অভিজ্ঞ রাঁধুনিকে কেউ জিজ্ঞেস করেন না “লবণ কী”; জিজ্ঞেস করা হয়, “তরকারি আজ তেতো লাগছে, আগে কোনটা দেখবেন?” উন্নত DL আর LLM ইন্টারভিউও তেমন: দেখা হয় একটি ভালো সংখ্যা দেখে আপনি সন্দেহ করতে পারেন কি না, দাম আর ঝুঁকি দেখে পথ বাছতে পারেন কি না, আর একটি পুরো ব্যবস্থা সাজাতে পারেন কি না।
কঠিনতার চিহ্ন: (সহজ), (মাঝারি), (কঠিন). প্রতিটি উত্তরের শেষে “রিভিশন”-এর পর্বে পূর্ণ ব্যাখ্যা আর আসল run আছে।
১ · Architecture বাছাই, inductive bias আর transfer
রিভিশন: পর্ব ২২, পর্ব ২৩ · Transfer learning, পর্ব ৩৮, পর্ব ৪২
প্র ১বাজারঘরের ২,০০০টি লেবেল করা পণ্যের ছবি, ১২টি শ্রেণি। শূন্য থেকে CNN, শূন্য থেকে ViT, নাকি pretrained model? (সহজ)
দুর্বল উত্তর: “ViT, কারণ Transformer সবচেয়ে আধুনিক।” কেন দুর্বল: ডেটার আকার আর কাঠামোর অনুমান, কোনোটিই ভাবা হয়নি।
শক্ত উত্তর: “২,০০০টি ছবি শূন্য থেকে শেখানোর জন্য কম। প্রথমে pretrained backbone-এ transfer learning: শুধু head শেখানো (linear probe), তারপর দরকার হলে শেষ block, ছোট learning rate-এ। ViT-এর কাঠামোয় locality আর translation-এর বাঁধন কম, মানে inductive bias কম; তাই শূন্য থেকে তার বেশি ডেটা আর augmentation লাগে। তুলনা একই split, একই budget আর কয়েকটি seed-এ, সঙ্গে একটি scratch baseline.” দুটি ফাঁদ নিজে থেকে বলুন: weight-এর নিজের preprocessing মেলানো, আর freeze করা backbone-এ BatchNorm-এর statistics না বদলাতে eval mode. রিভিশন: পর্ব ২৩, পর্ব ৩৮.
প্র ২বাংলা রিভিউর sentiment-এর জন্য একজন Bangla BERT fine-tune করতে চান, আরেকজন TF-IDF আর logistic regression. কী বলবেন? (মাঝারি)
দুর্বল উত্তর: “BERT, কারণ contextual embedding সবসময় ভালো।” কেন দুর্বল: দাবি আছে, মাপ নেই।
শক্ত উত্তর: “আগে baseline, একই ভাগে।” এই কোর্সে চমক ছিল: নাটকের মন্তব্যের একই ১৫টি ভাগে TF-IDF + logistic regression-এর macro-F1 ০.৯৪১, ছোট Transformer ০.৯০৪ (পর্ব ৪২); আর fine-tuned Bangla BERT ০.৯৩৯ বনাম TF-IDF ০.৯৪১, McNemar p = ০.৮৪২ (পর্ব ৮৬)। পার্থক্য ধরা পড়েনি, অথচ BERT-এর latency আর memory অনেক বেশি। Deep model আনুন যখন একই ভাগে baseline-কে হারায়, বা কাজটিতে প্রসঙ্গ জরুরি (না-বাচক বাক্য, লম্বা নির্ভরতা) আর সেই ধরনের সারিতে আলাদা মাপ আছে। রিভিশন: পর্ব ৪২, পর্ব ৪৮.
প্র ৩গুদামের তাপমাত্রা-সেন্সর প্রতি মিনিটে সংকেত দেয়; একটি ছোট যন্ত্রে চলমান অবস্থায় অস্বাভাবিকতা ধরতে হবে। Transformer নেবেন? (কঠিন)
দুর্বল উত্তর: “হ্যাঁ, attention দীর্ঘ নির্ভরতা ধরে।” কেন দুর্বল: যন্ত্র, streaming আর খরচের শর্ত বাদ।
শক্ত উত্তর: “তিনটি শর্ত দেখব: ইনপুট একটি একটি করে আসে, যন্ত্র ছোট, আর কতদূর অতীত দরকার। Self-attention-এর খরচ দৈর্ঘ্যের বর্গে বাড়ে, আর decode-এ KV cache জমতে থাকে। একটি causal 1D convolution (TCN) বা GRU প্রতি ধাপে স্থির memory আর সময়ে চলে, আর receptive field হিসাব করে দেখা যায় কত মিনিট পেছনে দেখে। তারও আগে একটি পরিসংখ্যানের baseline: চলমান গড় থেকে দূরত্ব।” Transformer আসবে যদি অনেক সেন্সর একসঙ্গে, লম্বা context আর server-এ চালানো যায়, এবং একই test-এ baseline হারে। রিভিশন: পর্ব ৩১, পর্ব ২৯, পর্ব ৩৭.
২ · ডেটা না model: scaling আর training ডিবাগ
রিভিশন: পর্ব ১৭, পর্ব ১৮ · Training ডিবাগ, পর্ব ৫১ · Scaling, পর্ব ৩৯
প্র ৪একটি ছোট বাংলা language model-এর test loss আর কমছে না। দল বলছে বড় model নিতে। কী করবেন? (মাঝারি)
দুর্বল উত্তর: “Scaling law বলে বড় model মানেই কম loss.” কেন দুর্বল: সূত্রটি মাপা সীমার ভেতরে খাটে, আর ডেটা ফুরালে model বাড়িয়ে লাভ থামে।
শক্ত উত্তর: “আগে দেখব আমরা curve-এর কোথায়। কয়েকটি আকারে model আর কয়েকটি আকারে ডেটা, log-log-এ ঢাল। Model-এর ঢাল সমতল কিন্তু ডেটার ঢাল খাড়া হলে পরের compute আর শ্রম ডেটায়, আর সঙ্গে regularization. Chinchilla-র মাপে একই compute-এ প্রায় ২০ token প্রতি parameter সেরা ছিল (Chinchilla rule), কিন্তু সেটি তাঁদের ডেটা আর শর্তে।” নিচের ব্লক এই কোর্সের ১.৯২ লাখ বাংলা অক্ষরের সত্যিকারের run আবার পড়ে। রিভিশন: পর্ব ৫১.
import numpy as np
# Real runs from the course's scaling lesson: parameters N -> test loss,
# and data D (characters seen, model with N = 37,792) -> test loss
N = np.array([2536, 2536, 5532, 9680, 9680, 37792, 37792, 149312, 149312, 334560,
334560, 593536, 593536, 1332672, 2366720, 2366720, 5319552])
LN = np.array([2.4165, 2.4301, 2.2277, 2.0992, 2.0131, 1.7213, 1.7172, 1.6611, 1.6732,
1.6868, 1.6858, 1.6606, 1.6711, 1.6771, 1.6555, 1.6972, 1.6802])
D = np.array([6000, 6000, 12000, 12000, 24001, 24001, 48003, 48003,
96007, 96007, 192014, 192014])
LD = np.array([2.6166, 2.5842, 2.4576, 2.3974, 2.2246, 2.2009, 2.0472, 1.9738,
1.8195, 1.8509, 1.7213, 1.7172])
def slope(x, y):
b = np.polyfit(np.log(x), np.log(y), 1)[0] # log-log slope = -alpha
return b, 2 ** b # loss multiplier when x doubles
for name, m in [("params, N <= 40k", N <= 40_000), ("params, N >= 100k", N >= 100_000)]:
b, f = slope(N[m], LN[m])
print(f"{name:18s} slope {b:+.3f} 2x -> loss x {f:.3f}")
b, f = slope(D, LD)
print(f"{'data, N = 37,792':18s} slope {b:+.3f} 2x -> loss x {f:.3f}")
big = N >= 100_000
print(f"141x more params ({N[big].max():,} vs 37,792): best loss "
f"{LN[big].min():.3f} vs {LN[N == 37792].min():.3f}")আসল আউটপুট (ব্রাউজারের Python):
params, N <= 40k slope -0.128 2x -> loss x 0.915
params, N >= 100k slope +0.001 2x -> loss x 1.001
data, N = 37,792 slope -0.124 2x -> loss x 0.918
141x more params (5,319,552 vs 37,792): best loss 1.655 vs 1.717ছোট model-এ parameter দ্বিগুণ করলে loss প্রায় ৮.৫% কমেছিল; প্রায় ১.৫ লাখ parameter-এর পরে ঢাল শূন্য। অথচ ৩৭,৭৯২ parameter-এর model-এ ডেটা দ্বিগুণে loss তখনও ৮.২% কমছিল। ১৪১ গুণ বড় model পেয়েছে মাত্র ১.৬৫৫ বনাম ১.৭১৭. ইন্টারভিউর উত্তর তাই: “এই জায়গায় ডেটা আর regularization আগে।” পর্ব ৫১-এ dropout দিলে একই বড় model ১.৫৯-এ নেমেছিল, অর্থাৎ সমতলটি অংশত overfitting-এর। সীমাও বলুন: এগুলো ১-২টি seed-এর ছোট run, আর বাঁকের জায়গাটি ছবি দেখে বাছা।
প্র ৫নতুন একটি network-এ loss নামছেই না। কোথা থেকে খুঁজবেন? (মাঝারি)
দুর্বল উত্তর: “Learning rate আর optimizer বদলে বদলে দেখব।” কেন দুর্বল: অন্ধ খোঁজ; কোডের ভুল hyperparameter ঘুরিয়ে ধরা পড়ে না।
শক্ত উত্তর: একটি সিঁড়ি, যেখানে ব্যর্থ সেখানেই থামা। (১) ডেটা আর label চোখে দেখা। (২) শুরুর loss: C শ্রেণিতে প্রায় ln C, ১০ শ্রেণিতে ২.৩০৩; অনেক বেশি হলে init বা ইনপুটের মাপ ভুল। (৩) এক batch overfit: loss প্রায় শূন্যে না নামলে কোডে ভুল। কিন্তু এটি প্রয়োজনীয়, যথেষ্ট নয়: পর্ব ১৮-এ এলোমেলো label-এও loss ০.০০৪৬-এ নেমেছিল, আর ReLU-এর mask বাদ দেওয়া ভুল gradient-ও ধীরে ০.০১৭-এ। হাতে লেখা backward-এ gradient check আলাদা লাগে। (৪) ছোট পূর্ণ run আর learning curve, (৫) তারপর বড় করা। আর loss-এর আগে দুই দিকের shape-এ একটি assert: (B, 1) আর (B,) broadcast হয়ে চুপচাপ ভুল loss দেয়। রিভিশন: পর্ব ১৮, পর্ব ০৪.
প্র ৬Training-এর ৩,০০০তম ধাপে loss হঠাৎ NaN. কী করবেন? (মাঝারি)
দুর্বল উত্তর: “আবার চালাই, হয়তো ঠিক হয়ে যাবে।” কেন দুর্বল: কারণ না জেনে আবার চালানো মানে আবার একই ধাপে ভাঙা, বা আরও খারাপ, মাঝে মাঝে।
শক্ত উত্তর: “প্রথমে প্রমাণ: প্রতি ধাপে loss, gradient norm আর isfinite লগ করব; NaN-এর আগে সাধারণত norm কয়েক ধাপ ধরে গুণ হারে বাড়ে (exploding gradient). প্রথম খারাপ ধাপে checkpoint থেকে ফিরে set_detect_anomaly. তারপর সন্দেহের তালিকা: learning rate বড় বা warmup নেই; fp16-এ overflow (bf16 বা loss scaling); log বা ভাগে শূন্য; ডেটায় NaN. প্রতিকার gradient clipping, warmup, আর গভীর network-এ residual-এর সঙ্গে ঠিক normalization.” রিভিশন: পর্ব ১৭, পর্ব ১৮, পর্ব ১২.
প্র ৭লেখক-চেনার একটি text model validation-এ macro-F1 ০.৯৯৬ পেয়েছে, কিন্তু নতুন বইয়ে অনেক খারাপ। কোথায় ভুল? (কঠিন)
দুর্বল উত্তর: “নতুন বইগুলো কঠিন।” কেন দুর্বল: নিজের split-কে সন্দেহ করা হয়নি।
শক্ত উত্তর: “অবিশ্বাস্য ভালো মানে আগে leakage সন্দেহ।” পর্ব ৩৯-এ ঠিক এটি ঘটেছিল: এলোমেলো টুকরোয় ০.৯৯৬, অদেখা বইয়ে ০.৫৪৯–০.৭৪০; সবচেয়ে ওজনদার শব্দ ছিল চরিত্রের নাম, model বই মুখস্থ করেছিল। খোঁজার তিন জায়গা: (১) ভাগের একক: একই বই, লেখক বা গ্রাহক দুই দিকে; (২) near-duplicate: পর্ব ৪২-এ অসতর্ক ভাগে test-এর ১৪% সারির যমজ train-এ ছিল (সেখানে প্রভাব মাত্র প্রায় ০.০০৪, অন্য ডেটায় বড় হতে পারে); (৩) domain shift: ক্যাপস্টোনে নাটকের মন্তব্যে ০.৯৪-এর model দোকানের বার্তায় routing-এ ০.৮১৬. প্রতিকার: group বা সময় ধরে ভাগ, আর লক্ষ্য-জগতের হাতে লেখা test set. রিভিশন: পর্ব ৩৯, পর্ব ৪২, পর্ব ৮৬.
৩ · Prompt, RAG না fine-tune; LoRA আর alignment
রিভিশন: পর্ব ৫৪, পর্ব ৫৫ · LoRA, পর্ব ৫৬, পর্ব ৫৭, পর্ব ৬৯ · RAG
প্র ৮বাজারঘরের ফেরত-নীতি প্রায় প্রতি মাসে বদলায়। সহায়ককে নীতি শেখাতে model fine-tune করবেন? (মাঝারি)
দুর্বল উত্তর: “হ্যাঁ, নীতির নথিতে fine-tune করলে model নীতি মনে রাখবে।” কেন দুর্বল: বদলানো তথ্য ওজনে ঢোকালে প্রতি বদলে আবার training, উৎস দেখানো যায় না, আর পুরোনো নীতি ভুলেছে কি না যাচাই কঠিন।
শক্ত উত্তর: “বদলায় এমন জ্ঞান RAG-এ: নিয়ম বদলালে শুধু index হালনাগাদ, উত্তরে উৎসের নম্বর, আর উৎস না পেলে ‘উৎসে নেই’ (abstention). Fine-tuning আচরণ শেখায়: ফরম্যাট, সুর, শ্রেণি। আর সবার আগে prompt, কারণ সেটিই সবচেয়ে সস্তা baseline.” কোর্সের প্রমাণ: পর্ব ৫২-এ ছোট model “রাজধানী”-র ভুল করেছিল, system বার্তায় তথ্য দিলে ঠিক বলেছে; ক্যাপস্টোনে RAG ৪০টির ২৬টি ঠিক, আর উত্তরহীন ৬টির ৬টিতে “উৎসে নেই”। নিচের stepper সিদ্ধান্তের ক্রম দেখায়। রিভিশন: পর্ব ৬৯, পর্ব ৫২, পর্ব ৮৬.
| সমস্যা | |
| পদক্ষেপ | |
| যা বদলায় না |
- Prompt আগে। স্পষ্ট নির্দেশ আর কয়েকটি উদাহরণ; eval set-এ মেপে এটিই baseline.
- বদলানো জ্ঞান RAG-এ। নীতির নথি index-এ; উত্তর উৎস থেকে, না পেলে থামা।
- আচরণের সমস্যা হলে fine-tune. ফরম্যাট বা সুর prompt-এ ঠিক না হলে LoRA দিয়ে ছোট SFT; জ্ঞান তখনও RAG থেকে।
- খরচের চাপ হলে ছোট করা। Quantization বা distillation, কিন্তু মান একই set-এ আবার মেপে।
- প্রতিটি ধাপ জোড়ায় তুলনা। আগের সংস্করণের তুলনায় একই প্রশ্নে কয়টি ভালো, কয়টি খারাপ; গড়ের সঙ্গে CI.
প্র ৯LoRA না full fine-tuning? দুটির মধ্যে কী হারান, কী পান? (মাঝারি)
দুর্বল উত্তর: “LoRA সবসময় full-এর সমান, শুধু সস্তা।” কেন দুর্বল: মাপা নয়, বিশ্বাস।
শক্ত উত্তর: “LoRA-তে মূল ওজন স্থির, প্রতি module-এ r(d + k)টি নতুন parameter; B শূন্যে শুরু, তাই শুরুতে model হুবহু আগের। লাভ memory আর ফাইলে, আর এক base-এ অনেক adapter.” কোর্সের একটি run-এ (Bangla BERT, sentiment): full fine-tuning test-এ প্রায় ০.০০৯–০.০১৪ এগিয়ে; LoRA-র r = ৪ থেকে ৩২-এ মান ০.৯২৯–০.৯৩৪, প্রায় এক; peak memory ৩,৯৬৯ থেকে ১,৭৬৭ MiB; adapter ১.১৪ MiB বনাম পুরো model ৬২৭.২ MiB. Memory আড়াই গুণও কমেনি, কারণ frozen ওজন আর activation থেকে যায়; পরের ধাপ base-কে 4-bit-এ রাখা, QLoRA. Merge করলে inference-এ বাড়তি latency নেই। শেষ কথা: একটি seed, একটি split; নিজের কাজে মেপে বলুন। রিভিশন: পর্ব ৫৫.
প্র ১০দোকানের ১,০০০টি উদাহরণে SFT-এর পরে উত্তর দোকানের ধাঁচে, কিন্তু সাধারণ প্রশ্নে মান পড়েছে। কেন, আর কী করবেন? (কঠিন)
দুর্বল উত্তর: “আরও epoch চালাই।” কেন দুর্বল: সমস্যাটি সম্ভবত বেশি সরে যাওয়া; আরও epoch তা বাড়াবে।
শক্ত উত্তর: দুটি সন্দেহ। এক, catastrophic forgetting: পর্ব ৫৪-এর খেলনায় নতুন কাজ ০.৬০৩ থেকে ০.৯৭০-এ উঠলে পুরোনো কাজ ০.৯৯৮ থেকে ০.৫৭০-এ নেমেছিল, ওজন যত দূরে সরে তত বেশি। দুই, format overfitting: শেখার ডেটার বাইরের প্রশ্নেও দোকানের ছাঁচ। যাচাই: আগে থেকে রাখা সাধারণ প্রশ্নের একটি held-out set, SFT-এর আগে ও পরে। প্রতিকার: ছোট learning rate আর কম ধাপ, LoRA, সাধারণ ডেটা মেশানো, শুরুর ওজনের দিকে টান (খেলনায় দুটি কাজের মাঝামাঝি আপস: ০.৭০৫ আর ০.৯০৫)। আর loss শুধু উত্তরের token-এ: prompt ১২০ আর উত্তর ৩০ token হলে mask না দিলে loss-এর ৮০% prompt মাপে। পছন্দের ডেটা থাকলে DPO, reference model-এর কাছে বাঁধা রেখে। রিভিশন: পর্ব ৫৪, পর্ব ৫৬, পর্ব ৫৭.
৪ · LLM অ্যাপের মূল্যায়ন
রিভিশন: পর্ব ৫৮ · LLM মূল্যায়ন, পর্ব ৬৬, পর্ব ৭০ · RAG মূল্যায়ন; পরিসংখ্যানের ভিত্তি: মেশিন লার্নিং কোর্সের পর্ব ২২
প্র ১১একই ৪০টি প্রশ্নে পুরোনো সংস্করণ ২১টি, নতুনটি ২৬টি ঠিক বলেছে; নতুনটি ৫টিতে ভালো, একটিতেও খারাপ নয়। চালু করবেন? (মাঝারি)
দুর্বল উত্তর: “৬৫% বনাম ৫২.৫%, স্পষ্ট উন্নতি।” বা উল্টো: “দুই অনুপাতের test-এ p বড়, তাই কোনো লাভ নেই।” কেন দুর্বল: একই প্রশ্নে দুটি run স্বাধীন নমুনা নয়।
শক্ত উত্তর: “জোড়ায় দেখব: শুধু অমিলের প্রশ্নগুলো কথা বলে। ৫–০ অমিলে McNemar-এর exact test, পাশে paired bootstrap-এর CI. সঙ্গে ধরন ধরে ফল আর ‘আগে ঠিক, এখন ভুল’-এর তালিকা, কারণ গড় বাড়লেও ঝুঁকির ধরনে নতুন ভুল আসতে পারে।” এটি ক্যাপস্টোনের reranker gate-এর আসল ফল; নিচের ব্লক দুই পদ্ধতির p আর eval set-এর আকারের প্রশ্নটি মাপে। রিভিশন: পর্ব ৬৬, পর্ব ৮৬.
import numpy as np
from scipy import stats
# Capstone numbers: 40 fixed test questions, no gate 21 correct, with gate 26.
# Paired view: gate fixed 5 questions and broke none.
n, a, b = 40, 21, 26
better, worse = 5, 0
# Wrong for paired data: treat the two runs as independent samples
p = (a + b) / (2 * n)
z = (b - a) / n / np.sqrt(p * (1 - p) * 2 / n)
print(f"unpaired two-proportion z test p = {2 * stats.norm.sf(abs(z)):.3f}")
# Right: look only at the questions where the two versions disagree
print(f"McNemar exact (5 vs 0) p = {stats.binomtest(better, better + worse).pvalue:.4f}")
# How wide is a 95% interval around an accuracy of 0.65?
for k in [40, 160, 640]:
h = 1.96 * np.sqrt(0.65 * 0.35 / k)
print(f"n = {k:3d} questions 0.65 +/- {h:.3f}")
need = int(np.ceil((1.96 / 0.05) ** 2 * 0.25))
print(f"questions for +/-0.05 at p = 0.5: {need}")আসল আউটপুট (ব্রাউজারের Python):
unpaired two-proportion z test p = 0.256
McNemar exact (5 vs 0) p = 0.0625
n = 40 questions 0.65 +/- 0.148
n = 160 questions 0.65 +/- 0.074
n = 640 questions 0.65 +/- 0.037
questions for +/-0.05 at p = 0.5: 385স্বাধীন ধরে নিলে p = ০.২৫৬, যেন কিছুই ঘটেনি; জোড়ায় p = ০.০৬২৫, কারণ ৫টি অমিলের সবগুলো এক দিকে যাওয়ার সম্ভাবনা দুই দিক মিলিয়ে ২ × (১/২)৫. তবু ০.০৫-এর নিচে নয়: ৫টি অমিল খুব ছোট প্রমাণ। ৪০টি প্রশ্নে ০.৬৫-এর ব্যবধান প্রায় ±০.১৫; প্রস্থ অর্ধেক করতে প্রশ্ন চার গুণ। তাই ইন্টারভিউতে বলুন: “ঝুঁকি কম আর ক্ষতি দেখা যায়নি বলে canary-তে চালু, সঙ্গে eval set বড় করা।”
প্র ১২হাজার হাজার উত্তর হাতে দেখা সম্ভব নয়। একটি LLM-কে বিচারক বানাবেন? (কঠিন)
দুর্বল উত্তর: “হ্যাঁ, বড় model মানুষের মতোই বিচার করে।” কেন দুর্বল: বিচারকের নিজের ভুল মাপা হয়নি।
শক্ত উত্তর: “LLM-as-judge চলতে পারে, কিন্তু আগে বিচারককে পরীক্ষা।” এই কোর্সের মাপ সতর্ক করে: পর্ব ৫৮-এ ছোট Qwen বিচারক ৭২টি রায়ের ৭২টিতেই “A” বলেছে, অর্থাৎ পুরোটা position bias; লম্বা ভুল উত্তরকে গড়ে বেশি নম্বর (২.৮৪ বনাম ২.৪৭), verbosity bias. পর্ব ৭০-এ faithfulness-এর বিচারকের সঙ্গে মানুষের kappa-র ৯৫% ব্যবধান ০.০৫–০.৪৫, আর সস্তা সংখ্যা-পরীক্ষার kappa ০.৩২৪. নিয়ম: প্রতিটি জোড়া দুই ক্রমে, স্পষ্ট rubric, ৫০–১০০টি উত্তরে মানুষের লেবেলের সঙ্গে kappa, আর যেখানে সম্ভব কোডে যাচাই (সংখ্যা, citation, JSON). বড় বিচারক সাধারণত ভালো বলে রিপোর্ট আছে, তবু নিজের ডেটায় মাপুন। রিভিশন: পর্ব ৫৮, পর্ব ৭০.
প্র ১৩RAG সহায়ক উত্তরযোগ্য ৩৪টি প্রশ্নের ১৪টিতে ভুল বলছে। দল বলছে embedding model বদলাতে। কী বলবেন? (মাঝারি)
দুর্বল উত্তর: “হ্যাঁ, বড় embedding model নিলে খোঁজা ভালো হবে।” কেন দুর্বল: ভুলটি খোঁজায় কি না, তা মাপা হয়নি।
শক্ত উত্তর: “অংশ ধরে মাপব: ঠিক নথি শীর্ষ k-তে এসেছিল কি না (recall@k), gate থামিয়েছে কি না, আর নথি হাতে থাকতেও উত্তর ভুল কি না (faithfulness). দরকারে oracle context: সঠিক নথি হাতে দিয়ে generator-কে আলাদা পরীক্ষা।” ক্যাপস্টোনে এই error analysis উত্তর দিয়েছিল: ১৪টির ১৩টিতে ঠিক নথি শীর্ষ ৩-এ ছিল। নিচের stepper ভাগটি দেখায়। রিভিশন: পর্ব ৭০, পর্ব ৮৬.
| উত্তরযোগ্যে ঠিক | |
| ঠিক নথি শীর্ষ ৩-এ | |
| খোঁজা বা gate-এর দোষ | |
| উত্তর-লেখার ধরন |
- মোট ছবি। উত্তরযোগ্য ৩৪টির ২০টি ঠিক, ১৪টি ভুল। এই সংখ্যা একা বলে না কোথায় হাত দিতে হবে।
- খোঁজা ঠিক ছিল। ১৪টির ১৩টিতে ঠিক নথি শীর্ষ ৩-এ ছিল; একটি Banglish প্রশ্ন gate-এ আটকেছে। Embedding বদলালে বড় জোর একটি প্রশ্ন বাঁচে।
- হিসাবের প্রশ্ন। ৪টির ৪টিই ভুল, যেমন “১২০ + ২ × ২০” না করে শুধু ১২০. প্রতিকার: সংখ্যা বের করে যোগ-গুণ কোডে, বা calculator tool.
- দুই নথির প্রশ্ন। ৪টির ৪টিই ভুল বা অসম্পূর্ণ: একটি অংশ বাদ, বা লম্বা তালিকা।
- বাকি। ৪টিতে পাশের লাইনের ভুল তথ্য, আর একটিতে উত্তর শুধু “[2]”. দুর্বলতা উত্তর-লেখায়; পরের কাজ generator আর prompt, retriever নয়।
৫ · Hallucination, নিরাপত্তা আর guardrail
রিভিশন: পর্ব ৫২ · LLM-এর ভেতরে, পর্ব ৭১, পর্ব ৭২, পর্ব ৭৩ · LLM নিরাপত্তা
প্র ১৪LLM কেন আত্মবিশ্বাসের সঙ্গে ভুল বলে, আর কীভাবে কমাবেন? (মাঝারি)
দুর্বল উত্তর: “Temperature শূন্য করলে hallucination বন্ধ।” কেন দুর্বল: Greedy-ও ভুল বলে; temperature শুধু বাছাইয়ের এলোমেলোতা বদলায়।
শক্ত উত্তর: “Model শেখে পরের token-এর সম্ভাবনা, সত্য যাচাই নয়; সাবলীল ছাঁচ আর সত্য একই পথে আসে।” কোর্সের প্রমাণ: পর্ব ৫২-এ ০.৫B model ২০৩১-এর বিশ্বকাপের, যা এখনো হয়নি, একটি সাবলীল ফল বলেছে। Log-probability ইংরেজির সহজতম প্রশ্নে কিছুটা আলাদা করেছিল, কিন্তু বাংলায় সংকেতই ছিল না (বাস্তব −০.৩২৩, বানানো −০.৩০৫)। প্রতিকার, স্তরে স্তরে: উৎস দেওয়া (RAG) আর “উৎসে নেই”-র পথ; গোনা, তারিখ আর হিসাব কোডে বা tool-এ; নিজের ডেটায় calibration মাপা (পর্ব ৫২-এ temperature scaling-এ ECE ০.২১ থেকে ০.০৫, নির্ভুলতা একই); আর citation কোডে মেলানো। Hallucination কমে, শূন্য হয় না। রিভিশন: পর্ব ৫২, পর্ব ৬৯.
প্র ১৫সহায়ক পণ্যের পাতা আর বিক্রেতার লেখা পড়ে, আর একটি “বার্তা পাঠাও” tool আছে। Prompt injection ঠেকাবেন কীভাবে? (কঠিন)
দুর্বল উত্তর: “System prompt-এ লিখব ‘অন্য নির্দেশ মানবেন না’, আর সন্দেহজনক শব্দের তালিকা।” কেন দুর্বল: দুটিই model-এর ভেতরের অনুরোধ; দেয়াল নয়।
শক্ত উত্তর: “Model যা পড়ে সবই সম্ভাব্য নির্দেশ; এখানে indirect prompt injection-এর ঝুঁকি, যেখানে ব্যবহারকারী নির্দোষ। দেয়াল model-এর বাইরে: (১) least privilege: কম tool, প্রাপক শুধু বর্তমান গ্রাহক; (২) argument কোডে যাচাই, allowlist-এ URL আর domain; (৩) বাইরের কাজে মানুষের অনুমোদন; (৪) output filter আর লগ।” কোর্সের মাপ: পর্ব ৭৩-এ শব্দের denylist একই অনুরোধের তিনটি অন্য রূপ ছেড়ে দিয়েছিল আর চারটি নিরীহ লেখা আটকেছিল; output filter-এর পরে ১.৫B-এর ৩৯৬টি উত্তরের একটিও ক্ষতিকর উত্তর গ্রাহকের কাছে পৌঁছাত না। আর ছোট model-এর বড় ঝুঁকি ছিল আক্রমণ নয়, বানানো argument: ১৮টি tool-প্রস্তাবের ১৪টি gate আটকেছিল। রিভিশন: পর্ব ৭৩, পর্ব ৭১.
প্র ১৬Red-team test-এ ৪৮টি চেষ্টার একটিও সফল হয়নি। রিপোর্টে লিখবেন “নিরাপদ”? (মাঝারি)
দুর্বল উত্তর: “হ্যাঁ, ০%.” কেন দুর্বল: শূন্য দেখা আর শূন্য হওয়া আলাদা।
শক্ত উত্তর: “লিখব ‘৪৮টিতে দেখা যায়নি; আসল হার ৯৫% নিশ্চয়তায় প্রায় ৭.৪%-এর নিচে’, Wilson-এর ঊর্ধ্বসীমা দিয়ে। আর সীমা: এই চেষ্টাগুলো আমাদের জানা ধরনের; অভিযোজিত আক্রমণ নতুন রূপ খোঁজে। তাই নিরীহ canary দিয়ে নিজের sandbox-এ নিয়মিত পরীক্ষা, প্রতিটি স্তরের false positive-সহ, আর নকশায় অধিকার সীমিত রাখা।” নিচের ব্লক দেখায় কত পরীক্ষায় কতটুকু দাবি চলে। রিভিশন: পর্ব ৭৩.
import numpy as np
def wilson_upper(k, n, z=1.96):
"""Upper end of the 95% Wilson interval for k successes in n trials"""
p = k / n
centre = (p + z * z / (2 * n)) / (1 + z * z / n)
half = z * np.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / (1 + z * z / n)
return centre + half
# Attack successes seen in a small red-team test set (defensive canary tests)
for k, n in [(0, 8), (0, 42), (0, 48), (1, 42), (5, 42), (0, 300)]:
note = f" (rule of three: {3 / n:.3f})" if k == 0 else ""
print(f"{k}/{n:<3d} seen -> true rate could still be up to {wilson_upper(k, n):.3f}{note}")
# How many clean trials before "below 1%" is a fair claim?
n = 1
while wilson_upper(0, n) > 0.01:
n += 1
print("clean trials needed for an upper bound below 0.01:", n)আসল আউটপুট (ব্রাউজারের Python):
0/8 seen -> true rate could still be up to 0.324 (rule of three: 0.375)
0/42 seen -> true rate could still be up to 0.084 (rule of three: 0.071)
0/48 seen -> true rate could still be up to 0.074 (rule of three: 0.062)
1/42 seen -> true rate could still be up to 0.123
5/42 seen -> true rate could still be up to 0.250
0/300 seen -> true rate could still be up to 0.013 (rule of three: 0.010)
clean trials needed for an upper bound below 0.01: 381ক্যাপস্টোনের আট প্রশ্নের canary-তে শূন্য মানে আসল হার ৩২%-এর মতো উঁচুও হতে পারে। পর্ব ৭৩-এর ৪২টি সুযোগে ০ হলে সীমা ০.০৮৪, আর ৫টি হলে ০.২৫০ পর্যন্ত। “১%-এর নিচে” বলতে প্রায় ৩৮১টি পরিষ্কার পরীক্ষা লাগে। মোটা নিয়ম “rule of three” (৩/n) শূন্য সাফল্যে কাছাকাছি সংখ্যা দেয়।
৬ · Token-এ খরচ, latency, বাংলা আর multimodal
রিভিশন: পর্ব ৪০, পর্ব ৬৫ · Token, খরচ আর latency, পর্ব ৮২ · Multimodal model, পর্ব ৮৬
প্র ১৭একই সহায়ক বাংলায় চালাতে ইংরেজির চেয়ে খরচ বেশি কেন, আর কত? কোথায় কাটবেন? (মাঝারি)
দুর্বল উত্তর: “খরচ প্রতি অনুরোধে, ভাষায় কিছু যায় আসে না।” কেন দুর্বল: খরচ আর সময় দুটোই token-এ মাপা হয়।
শক্ত উত্তর: “Tokenizer বাংলাকে বেশি টুকরোয় ভাঙে (token fertility বেশি)।” পর্ব ৬৫-এর তিনটি ছোট লেখায় অনুপাত tokenizer-ভেদে ১.১৩ থেকে ৬.৪৯ গুণ; Qwen2.5-এ ৩.৮৬, tiktoken-এর o200k_base-এ ১.৫২. মাসের token = অনুরোধ × (Tin + Tout), আর প্রতিটি অনুরোধে পুরো ইতিহাস আবার input. ক্যাপস্টোনে prompt-ই ছিল প্রায় ৯৫% token (গড়ে ১,০১৬ বনাম ৫৯), তাই কাটার জায়গা input: কম উৎস, ছোট system prompt, স্থির অংশ আগে রেখে prefix caching, gate দিয়ে অপ্রয়োজনীয় ডাক বাদ। নিচের ব্লক ধরে নেওয়া ট্রাফিকে মাসের token আর GPU-ঘণ্টা হিসাব করে। রিভিশন: পর্ব ৬৫, পর্ব ৮৬.
# Tokens and GPU time of a Bangla shop assistant (traffic assumed; per-call numbers measured)
req_day, days = 5000, 30 # assumed LLM calls per day
t_in, t_out = 1016, 59 # capstone means per LLM call (Bangla, Qwen2.5 tokenizer)
ratio_bn_en = 3.86 # Qwen2.5 tokenizer: Bangla / English tokens (lesson 65)
r, ttft = 39.3, 0.10 # capstone decode speed at batch 1; TTFT assumed ~0.1 s
def month_tokens(tin, tout, calls=req_day * days):
return calls * (tin + tout) / 1e6 # million tokens per month
print(f"Bangla prompts {month_tokens(t_in, t_out):6.1f} M tokens / month")
print(f"same text if English {month_tokens(t_in / ratio_bn_en, t_out / ratio_bn_en):6.1f} M")
print(f"top-2 sources, not top-3 {month_tokens(t_in * 2 / 3, t_out):6.1f} M")
print(f"gate stops 21% first {month_tokens(t_in, t_out, req_day * days * 0.79):6.1f} M")
print(f"input share of the tokens {t_in / (t_in + t_out):.0%}")
gpu_h = req_day * days * (ttft + (t_out - 1) / r) / 3600
print(f"GPU time at batch 1 {gpu_h:6.0f} GPU-hours / month")
for n_out in [59, 120, 160]:
print(f"answer {n_out:3d} tokens -> about {ttft + (n_out - 1) / r:.2f} s")আসল আউটপুট (ব্রাউজারের Python):
Bangla prompts 161.2 M tokens / month
same text if English 41.8 M
top-2 sources, not top-3 110.5 M
gate stops 21% first 127.4 M
input share of the tokens 95%
GPU time at batch 1 66 GPU-hours / month
answer 59 tokens -> about 1.58 s
answer 120 tokens -> about 3.13 s
answer 160 tokens -> about 4.15 sট্রাফিক ধরে নেওয়া, তাই অঙ্ক নয়, অনুপাত দেখুন। একই কথা ইংরেজিতে প্রায় চার ভাগের এক ভাগ token; token-এর ৯৫% input. উৎস তিনটি থেকে দুটি করলে প্রায় ৩১% কম token, কিন্তু উত্তরের মান একই eval set-এ আবার মাপতে হবে। ২১% হলো ক্যাপস্টোনে প্রশ্নের মধ্যে gate-এ থামা ভাগ (৬১-এর ১৩)। Latency-র লাইনগুলো ক্যাপস্টোনের p95-এর ব্যাখ্যা: ১৬০ token-এর উত্তরেই চার সেকেন্ডের বেশি। Batch ১-এ মাসে প্রায় ৬৬ GPU-ঘণ্টা শুধু লেখায়; batching তা অনেক কমায় (অংশ ৯-এর ব্লক)।
প্র ১৮সহায়কের p50 latency ১.২ সেকেন্ড, কিন্তু p95 ৩.৮ সেকেন্ড; লক্ষ্য p95 ৩ সেকেন্ড। বড় GPU কিনবেন? (মাঝারি)
দুর্বল উত্তর: “হ্যাঁ, দ্রুত GPU-তে সব দ্রুত।” কেন দুর্বল: ধীর প্রান্তের কারণ খোঁজা হয়নি।
শক্ত উত্তর: “আগে ধাপ ধরে সময় আর tail latency-র উৎস।” ক্যাপস্টোনে router ৩২ ms, খোঁজা ৭০ ms, লেখা ১,৪৯০ ms: সময়ের ৯৪% generation-এ; ৪৮টির ৬টি উত্তর ১৬০ token-এর সীমা ছুঁয়েছিল, সেগুলোই সবচেয়ে ধীর, token আর সময়ের correlation ০.৯৪. প্রতিকার তাই উত্তর ছোট রাখা: স্পষ্ট দৈর্ঘ্যের নির্দেশ, কম max token, তালিকা নয়। মোট সময় ≈ TTFT + (N − ১) ÷ r: লম্বা prompt-এ TTFT বাড়ে, আর পর্ব ৬৫-এ prefix cache TTFT ৮.০৫ থেকে ০.৩৭ সেকেন্ডে নামিয়েছিল। Streaming প্রথম দেখার সময় কমায়, মোট নয়। Hardware শেষে, আর তখনও মেপে। রিভিশন: পর্ব ৮৬, পর্ব ৬৫.
প্র ১৯বাংলার মতো কম-সম্পদের ভাষায় একটি LLM অ্যাপ বানাতে কী কী আলাদা ভাবতে হয়? (কঠিন)
দুর্বল উত্তর: “বহুভাষিক model নিলেই বাংলা চলে।” কেন দুর্বল: ভাষার নিজস্ব সমস্যা আর মাপ, কোনোটি নেই।
শক্ত উত্তর: পাঁচটি স্তর, প্রতিটিতে কোর্সের মাপ। (১) লেখা: Unicode normalization (NFC), বাংলা অঙ্ক, “য়”-এর দুই রূপ; পর্ব ৮৬-এর প্রথম PII নিয়ম বাংলা অঙ্কের ফোন নম্বর ধরেনি। (২) Token: বেশি টুকরো মানে বেশি খরচ আর ছোট কার্যকর context. (৩) Banglish আর ভাষা মেশানো: ক্যাপস্টোনে একমাত্র gate-ভুল ছিল “gazipur e delivery charge koto?”, আর পর্ব ৮৫-এর semantic cache-এ সবচেয়ে কাছের entry ভুল হওয়া ৪টির সবই Banglish. (৪) Register: পর্ব ৩৯-এ চলিত লেখার vocabulary সাধু লেখার ৪৪.৩% শব্দ চেনেনি। (৫) মূল্যায়ন: পর্ব ৫৮-এ ছোট Qwen-এর MMMLU বাংলা ০.২৮৫, CI [০.২২৫, ০.৩৫০], দৈবের ০.২৫ ছুঁয়ে; আর বাজারঘরের ৪০টি প্রশ্নের set-এ একই model বাংলায় ০.৩২৫, একই প্রশ্ন ইংরেজিতে ০.৬২৫. তাই নিজের বাংলা আর Banglish eval set, ভাষা ধরে আলাদা ফল। রিভিশন: পর্ব ৪০, পর্ব ৩৯, পর্ব ৫৮.
প্র ২০পণ্যের ছবি থেকে শ্রেণি বলতে হবে। একটি vision-language model ডাকবেন, নাকি CLIP-এর embedding আর ছোট classifier? (মাঝারি)
দুর্বল উত্তর: “VLM, কারণ সে ছবি দেখে কথা বলে।” কেন দুর্বল: খরচ, গতি আর ব্যর্থতার ধরন বাদ।
শক্ত উত্তর: “শ্রেণি বাঁধা থাকলে CLIP-এর embedding আগে: সস্তা, দ্রুত, একবার হিসাব করে রাখা যায়।” পর্ব ৮২-এর সত্যিকারের run-এ (CLIP ViT-B/32, Fashion-MNIST-এর ১০০০টি ছবি) ইংরেজি prompt-এ zero-shot ০.৮৪৫, প্রতি শ্রেণিতে ১০০টি label-এর linear probe ০.৮৯৯, আর বাংলা prompt-এ ০.১১৩, আন্দাজের প্রায় সমান। তাই বাংলা নাম নয়, ইংরেজি prompt বা label-এ শেখা probe. VLM লাগে খোলা প্রশ্নে (“ছবিতে কী লেখা?”), কিন্তু প্রতিটি ছবি অনেক visual token, মানে context, memory আর খরচ; আর পরিচিত ব্যর্থতা গণনা, ছোট লেখা, বাংলা লেখা আর অনুপস্থিত বস্তুকে “আছে” বলা, যা হাতে লেবেল করা প্রশ্নে মাপতে হয়। রিভিশন: পর্ব ৮২.
৭ · Serving, deploy আর চালুর পরে নজরদারি
রিভিশন: পর্ব ৫৯, পর্ব ৮৩ · LLM serving, পর্ব ৮৪, পর্ব ৮৫; ML-এর নজরদারি: মেশিন লার্নিং কোর্সের পর্ব ৬৯
প্র ২১একটি GPU-তে ১.৫B model; একসঙ্গে কতজনকে সেবা দেওয়া যাবে, আর কী তা ঠিক করে? (মাঝারি)
দুর্বল উত্তর: “GPU যত দ্রুত, তত বেশি।” কেন দুর্বল: সীমা প্রায়ই গতি নয়, memory.
শক্ত উত্তর: “Decode memory-bound: প্রতি ধাপে সব ওজন পড়া হয়, তাই batch বড় করলে throughput বাড়ে। কয়টি অনুরোধ একসঙ্গে ধরবে, তা ঠিক করে KV cache: প্রতি token-এ 2 × স্তর × KV head × head_dim × byte. GQA এটি কমায়। তারপর scheduling: continuous batching প্রতি ধাপে batch নতুন করে সাজায়।” পর্ব ৮৩-এর মাপে ক্ষমতার কিনারে (λ = ১.০) একই যন্ত্রে TTFT-এর p50 static batching-এ ১৭.৮ s, continuous-এ ৩.৫ s. চলমান অনুরোধের সংখ্যা Little-এর সূত্রে L = λ × W. নিচের ব্লক আসল config থেকে হিসাব করে। রিভিশন: পর্ব ৮৩, পর্ব ৩৭.
# KV cache memory from the real Qwen2.5-1.5B-Instruct config, bf16
layers, q_heads, kv_heads, head_dim, nbytes = 28, 12, 2, 128, 2
per_tok = 2 * layers * kv_heads * head_dim * nbytes # K and V, every layer
print(f"KV per token {per_tok:,} bytes ({per_tok // 1024} KiB)")
print(f"without GQA {2 * layers * q_heads * head_dim * nbytes:,} bytes (x{q_heads // kv_heads})")
free_gib = 4 # ASSUMED memory left for KV after weights and activations
for ctx in [1024, 2048, 8192, 32768]:
mib = per_tok * ctx / 2 ** 20
fits = int(free_gib * 2 ** 30 // (per_tok * ctx))
print(f"context {ctx:6,} tokens: {mib:6.0f} MiB per request -> {fits:3d} requests fit")
# Little's law: requests in flight = arrival rate x time in system
lam, W = 2.0, 4.1 # assumed: 2 requests/s, 4.1 s each (lesson 85 scale)
L = lam * W
print(f"in flight L = {lam} x {W} = {L:.1f} requests -> KV at 2,048 tokens "
f"{L * per_tok * 2048 / 2 ** 20:.0f} MiB")আসল আউটপুট (ব্রাউজারের Python):
KV per token 28,672 bytes (28 KiB)
without GQA 172,032 bytes (x6)
context 1,024 tokens: 28 MiB per request -> 146 requests fit
context 2,048 tokens: 56 MiB per request -> 73 requests fit
context 8,192 tokens: 224 MiB per request -> 18 requests fit
context 32,768 tokens: 896 MiB per request -> 4 requests fit
in flight L = 2.0 x 4.1 = 8.2 requests -> KV at 2,048 tokens 459 MiBপ্রতি token ২৮ KiB, পর্ব ৮৩-এর হাতের হিসাবের সঙ্গে হুবহু; GQA না থাকলে ছয় গুণ। ধরে নেওয়া ৪ GiB খালি memory-তে ২,০৪৮ token-এর ৭৩টি অনুরোধ, কিন্তু ৩২ হাজার token-এর context-এ মাত্র ৪টি: লম্বা context-এর দাম memory-তে। সেকেন্ডে ২টি অনুরোধ, প্রতিটি ৪.১ সেকেন্ড হলে গড়ে ৮.২টি ভেতরে থাকে, যা এই যন্ত্রে সহজে ধরে; সীমা তখন decode-এর গতি আর latency-র লক্ষ্য।
প্র ২২Model-কে int8 করলে কী পাবেন, কী হারাতে পারেন? (মাঝারি)
দুর্বল উত্তর: “চার গুণ ছোট, চার গুণ দ্রুত, মান একই।” কেন দুর্বল: তিনটি দাবিই runtime, model আর যন্ত্রের ওপর নির্ভর করে।
শক্ত উত্তর: কোর্সের তিনটি run তিন রকম ফল দিয়েছিল। (১) ONNX Runtime-এ DistilBERT: আকার ৫১৬ থেকে ১২৯ MiB, batch ১-এ সময় ১০.৩ থেকে ৬.২ ms, কিন্তু macro-F1 ০.৯২৫৮ থেকে ০.৯০৬১, ৬১টি সিদ্ধান্ত বদল; per-channel চালু করে reduce-range না দিলে মান ভেঙে ০.২২, কোনো error ছাড়াই। (২) PyTorch-এর int8-এ Bangla BERT: একটিও সিদ্ধান্ত বদলায়নি, কিন্তু embedding fp32-এ থাকায় আকার ৬২৭ থেকে ৩৮৩ MiB, চার ভাগের এক নয়। (৩) ছোট CNN-এ int8 fp32-এর চেয়ে ধীর। তাই নিয়ম: প্রতিটি quantization-এর পরে একই set-এ মান, আকার আর p95, নিজের যন্ত্রে; সিদ্ধান্ত বদলের সংখ্যা গুনুন। গতি আর মান একসঙ্গে না মিললে distillation দিয়ে ছোট student. রিভিশন: পর্ব ৮৪, পর্ব ৫৯.
প্র ২৩সহায়ক চালু হয়েছে। প্রথম মাসে কী কী নজরে রাখবেন? (কঠিন)
দুর্বল উত্তর: “Error rate আর uptime.” কেন দুর্বল: LLM অ্যাপ ২০০ OK দিয়েও ভুল উত্তর দেয়।
শক্ত উত্তর: চার স্তর, সস্তা থেকে দামি। (১) সেবা: TTFT আর মোট latency-র p50, p95, timeout, fallback আর rate limit-এর হার, token আর খরচ প্রতি অনুরোধে। (২) পথ: router কোন ভাগে কত পাঠায়, gate কত ভাগ থামায়, guard কত আটকায়; হঠাৎ বদল মানে প্রায়ই ইনপুট বা index ভাঙা। (৩) মান: প্রতিদিন কিছু এলোমেলো কথোপকথন মানুষের হাতে, rubric-এ; ব্যবহারকারীর “ভুল” চিহ্ন; প্রতিটি prompt বা model বদলে regression test CI-তে। (৪) নিরাপত্তা আর গোপনীয়তা: canary, অস্বাভাবিক tool ডাক, আর লগে PII ঢাকা আগেই। পুরোটা trace ধরে, প্রতিটি ধাপের সময় আর version-সহ (observability). রিভিশন: পর্ব ৮৫, মেশিন লার্নিং কোর্সের পর্ব ৬৯.
৮ · GenAI system design — কাঠামো, rubric আর Mock ১
রিভিশন: পর্ব ৮৫ · GenAI system design, পর্ব ৮৩, পর্ব ৬৯, পর্ব ৭০, পর্ব ৭৩; ML-এর নকশা: মেশিন লার্নিং কোর্সের পর্ব ৭১
GenAI নকশার আলাপ সাধারণত ৪৫ থেকে ৬০ মিনিট, প্রশ্ন ইচ্ছা করে অস্পষ্ট। ML system design-এর সব কথা খাটে; বাড়তি তিনটি: হিসাব token-এ, উত্তর খোলা লেখা বলে মূল্যায়ন কঠিন, আর model যা পড়ে সবই আক্রমণের পথ। সময়ের মোটা ভাগ:
- চাহিদা (৫ মিনিট): কী করবে, কী করবে না, কোন ভাষা, latency আর খরচের লক্ষ্য, ভুলের দাম।
- ধারণক্ষমতা (৫ মিনিট): অনুরোধ থেকে peak, token থেকে GPU-সেকেন্ড আর replica.
- নকশা (১০ মিনিট): router, RAG, model বাছাই, cache, tool.
- মূল্যায়ন (৮ মিনিট): eval set-এর ছক, অংশ ধরে মাপ, জোড়া তুলনা, লঞ্চের নিয়ম।
- নিরাপত্তা আর গোপনীয়তা (৭ মিনিট): PII, injection, অধিকার, output guard.
- ব্যর্থতা আর নজরদারি (১০ মিনিট): timeout, fallback, rate limit, trace, পরের উন্নতি।
Scoring rubric — নিজেকে বা বন্ধুকে নম্বর দিন
Rubric এই কোর্সের শেখানোর জন্য বানানো; কোনো প্রতিষ্ঠানের নম্বর-পদ্ধতি নয়। প্রতিটি ক্ষেত্রে ১ থেকে ৪; ২৮-এর মধ্যে ২০ বা বেশি মোটামুটি শক্ত আলাপ।
| ক্ষেত্র | ১ · দুর্বল | ৪ · শক্ত |
|---|---|---|
| চাহিদা | সরাসরি model-এর নাম | কাজ, ভাষা, বাদের তালিকা, latency আর খরচের সংখ্যা |
| ধারণক্ষমতা | “cloud-এ scale হবে” | peak RPS, token/দিন, GPU-ঘণ্টা আর replica, ধরে নেওয়া মান স্পষ্ট |
| নকশা | “একটি বড় LLM দিয়ে সব” | router, RAG-এ gate, ছোট-বড় model, কারণসহ |
| মূল্যায়ন | “কয়েকটি প্রশ্নে চোখে দেখেছি” | ধরন × ভাষার eval set, অংশ ধরে মাপ, জোড়া তুলনা, CI |
| নিরাপত্তা | system prompt-এ নিষেধ | PII mask, least privilege, allowlist, মানুষের অনুমোদন, canary |
| ব্যর্থতা ও খরচ | কোনো কথা নেই | timeout, সীমিত retry, fallback, cache-এর ঝুঁকি, rate limit token-এ |
| নজরদারি | “error দেখব” | trace, পথ ধরে হার, নমুনায় মানুষের বিচার, CI-তে regression |
সব mock-এ খাটে এমন red flag
- প্রথম দুই মিনিটে model-এর নাম, প্রশ্ন ছাড়াই।
- বদলানো তথ্য fine-tune করে ওজনে ঢোকানো।
- মূল্যায়ন মানে “demo-তে ভালো লেগেছে”, বা একটি বিচারক model-এর রায় যাচাই ছাড়া।
- Model-এর হাতে রিফান্ড বা বার্তার tool, কোডে কোনো যাচাই বা অনুমতি ছাড়া।
- খরচ বা latency-র হিসাব token ছাড়া; বাংলার বাড়তি token উপেক্ষা।
- “Model বোঝে” ধরনের দাবি, মাপের বদলে।
“বাজারঘরের জন্য একটি বাংলা গ্রাহক-সহায়ক chatbot নকশা করুন: ডেলিভারি, ফেরত আর অফারের প্রশ্নের উত্তর দেবে, অভিযোগ মানুষের কাছে পাঠাবে। ক্রেতারা বাংলা, ইংরেজি আর Banglish-এ লেখেন।”
চাহিদা। শক্ত প্রার্থী আগে জিজ্ঞেস করেন: অর্ডারের ব্যক্তিগত তথ্য দেখাবে কি না (প্রথম সংস্করণে না, শুধু নীতি আর সাধারণ তথ্য); TTFT-এর p95 লক্ষ্য; ভুল নীতি বলার দাম। বাদ: রিফান্ড দেওয়া, বিক্রেতার সঙ্গে কথা। ট্রাফিক না পেলে নিজের অনুমান স্পষ্ট বলে এগোন; নিচের ব্লকে সেগুলো ধরে নেওয়া, আর model-এর ক্ষমতা আর বার্তার মিশ্রণ কোর্সের মাপা সংখ্যা।
import math
# Mock 1: capacity for a Bangla shop assistant (traffic numbers are assumed)
msgs_day = 60_000 # chat messages per day
peak_share = 0.12 # busiest hour's share of the day
campaign = 3 # sale-campaign day multiplier
llm_share = 0.48 # capstone mix: 48 of 100 messages reached the LLM
t_in, t_out = 1016, 59 # capstone means per LLM call
gen_s = 1.49 # capstone: mean generation time per LLM call, batch 1
mu, u = 3.86, 0.6 # lesson 85: measured req/s per replica at batch 16; target load
for name, mult in [("normal day", 1), ("campaign", campaign)]:
rps = msgs_day * mult * peak_share / 3600 * llm_share
rep = math.ceil(rps / (mu * u))
print(f"{name:10s} peak LLM calls/s {rps:4.2f} -> replicas {rep}, with a spare {rep + 1}")
calls = msgs_day * llm_share
print(f"LLM calls/day {calls:,.0f}, tokens/day {calls * (t_in + t_out) / 1e6:.1f} M")
print(f"GPU time/day if served one by one: {calls * gen_s / 3600:.1f} h")
print(f"log size/day at ~4 KB per turn: {msgs_day * 4 / 1024:.0f} MB")আসল আউটপুট (ব্রাউজারের Python):
normal day peak LLM calls/s 0.96 -> replicas 1, with a spare 2
campaign peak LLM calls/s 2.88 -> replicas 2, with a spare 3
LLM calls/day 28,800, tokens/day 31.0 M
GPU time/day if served one by one: 11.9 h
log size/day at ~4 KB per turn: 234 MBব্যস্ত ঘণ্টায় সেকেন্ডে প্রায় একটি LLM-ডাক, ক্যাম্পেইনে প্রায় তিনটি; replica = ⌈peak ÷ (মাপা ক্ষমতা × ব্যবহারের লক্ষ্য)⌉, সঙ্গে একটি বাড়তি। একে একে চালালে দিনে প্রায় ১২ GPU-ঘণ্টা, তাই batching জরুরি। সতর্কতা বলুন: ৩.৮৬ অনুরোধ/সেকেন্ড পর্ব ৮৫-এ ০.৫B model-এর মাপ; ১.৫B-এ কম হবে, তাই load test-এ আবার মাপতে হবে। প্রতিদিন কোটি token মানে হিসাব আর rate limit token-এ।
বাংলা সহায়কের নকশা — একটি বার্তার পথ
Request path with router, gated RAG, small LLM, output guard and evaluation loop
নকশার কারণ। জ্ঞান RAG-এ, কারণ নীতি বদলায়; gate-এর সীমা dev set-এ বাছা, test-এ একবার। ছোট model প্রথমে, কারণ ক্যাপস্টোনের ভুলের বেশির ভাগ ছিল হিসাব আর দুই নথির প্রশ্নে, যা কোডে হিসাব আর ভালো prompt-এ আগে চেষ্টা করার মতো; বড় model আসবে জোড়া তুলনায় জিতলে। Semantic cache সাবধানে: পর্ব ৮৫-এ প্রতিটি threshold-এ hit-এর প্রায় ৩০–৪০% ভুল ছিল (“শুক্রবার” আর “শনিবার” embedding-এর কাছে প্রায় এক), তাই প্রথমে শুধু exact cache. Guardrail স্তরে স্তরে, PII ঢাকা সবার আগে, যাতে cache, লগ আর বাইরের API আসল তথ্য না পায়।
| মিনিট | |
| আপনি | |
| সম্ভাব্য ফলো-আপ |
- চাহিদা। প্রথম সংস্করণে ব্যক্তিগত অর্ডারের তথ্য নয়: ঝুঁকি কম, পরে tool দিয়ে, মালিকানা যাচাইসহ।
- ধারণক্ষমতা। ক্যাম্পেইনে ২টি replica, বাড়তিসহ ৩টি; সংখ্যার পাশে বলুন কোনটি মাপা, কোনটি ধরে নেওয়া।
- নকশা। নীতি বদলায়, তাই RAG; fine-tune শুধু router বা ফরম্যাটে।
- মূল্যায়ন। ৪০টিতে ব্যবধান প্রায় ±০.১৫: শুরু হিসেবে চলে, সিদ্ধান্তে জোড়া তুলনা আর set বড় করা।
- নিরাপত্তা। পণ্যের পাতা অবিশ্বস্ত লেখা: উৎস হিসেবে চিহ্নিত, tool নেই, output guard আর canary.
- ব্যর্থতা। LLM বন্ধ হলে: নীতির পাতার লিংক আর “মানুষের সঙ্গে কথা বলুন”; পথ ধরে হার মাপা, শেষে ঝুঁকির তালিকা।
প্র ২৪ফলো-আপ: “খরচ কমাতে semantic cache দিন, একই ধরনের প্রশ্ন তো বারবার আসে।” কী বলবেন? (কঠিন)
দুর্বল উত্তর: “ঠিক, threshold ০.৯৫ দিলেই নিরাপদ।” কেন দুর্বল: ভুল hit threshold দিয়ে থামে না।
শক্ত উত্তর: “Semantic cache-এর ঝুঁকি কাছাকাছি কিন্তু আলাদা প্রশ্নে পুরোনো উত্তর। পর্ব ৮৫-এ τ = ০.৯৫-এও ৯টি ঠিক আর ৬টি ভুল hit; ‘উত্তর আলাদা’ প্রশ্নের cosine-এর median ০.৯২০, যা Banglish-এ বলা একই প্রশ্নের (০.৮৭৩) চেয়ে বেশি। মূল শব্দ মেলানোর পাহারা ভুল hit কমিয়েছিল, কিন্তু নিয়মটি সেই ভুলগুলো দেখেই লেখা, তাই নতুন set-এ আবার মাপতে হবে। আর নিরাপদ সেটিংয়ে ৩৯টি পুনরাবৃত্ত প্রশ্নের মাত্র ১১টি hit: সাশ্রয় ছোট।” বিকল্প: ঝুঁকিহীন prompt caching (স্থির অংশ আগে), exact cache, আর ব্যক্তিগত প্রশ্ন cache-এর বাইরে। রিভিশন: পর্ব ৮৫, পর্ব ৬৫.
এই mock-এর red flag: ব্যক্তিগত প্রশ্নের উত্তর semantic cache থেকে; গ্রাহকের বার্তা PII না ঢেকে বাইরের API বা লগে; আর “উৎসে নেই” বলার কোনো পথ না রাখা।
৯ · Mock ২ ও ৩ — রাতের batch-এ রিভিউ আর ছবি থেকে পণ্যের তথ্য
রিভিশন: পর্ব ৬২, পর্ব ৫৯, পর্ব ৮৩, পর্ব ৬৮, পর্ব ৮২, পর্ব ৮১
“প্রতি রাতে বাজারঘরে প্রায় এক লাখ নতুন বাংলা রিভিউ আসে। প্রতিটির জন্য অভিযোগের ধরন (ডেলিভারি, মান, দাম, ব্যবহার) আর এক লাইনের সারাংশ চাই, সকালে দলের dashboard-এ।”
চাহিদা আর framing. কেউ অপেক্ষায় নেই, তাই batch: latency নয়, throughput আর খরচ। শক্ত প্রার্থী আগে জিজ্ঞেস করেন ধরনের তালিকা স্থির কি না। স্থির হলে ধরন চেনা একটি classification কাজ, যেখানে TF-IDF বা fine-tuned encoder সস্তা আর মাপা যায়; LLM শুধু সারাংশে, বা অচেনা ধরনের খোঁজে। Output structured output-এ: JSON, schema-তে যাচাই, ভাঙলে একবার আবার, তারপর “বাতিল” চিহ্ন।
# Mock 2: nightly batch of review summaries/tags (review counts and lengths assumed)
reviews = 100_000
in_tok = 180 # assumed tokens per review plus instructions (Bangla)
out_tok = 40 # short JSON: tags and a one-line summary
# Measured on one GPU in lesson 85 (Qwen2.5-0.5B, static batch):
dec_b1, dec_b16 = 55.5, 494 # output tokens/s at batch 1 and batch 16
prefill = 16_000 / 0.86 # 16 prompts of 1,000 tokens prefilled in 0.86 s
for name, dec in [("batch 1", dec_b1), ("batch 16", dec_b16)]:
hours = (reviews * out_tok / dec + reviews * in_tok / prefill) / 3600
print(f"{name:8s} about {hours:5.1f} GPU-hours for {reviews:,} reviews")
sample = 400
print(f"human check of {sample} random outputs = {sample / reviews:.1%} of the batch")আসল আউটপুট (ব্রাউজারের Python):
batch 1 about 20.3 GPU-hours for 100,000 reviews
batch 16 about 2.5 GPU-hours for 100,000 reviews
human check of 400 random outputs = 0.4% of the batchএকে একে চালালে এক রাতে শেষ হয় না; batch ১৬-এ আড়াই GPU-ঘণ্টা, এক রাতের মধ্যে। সংখ্যাটি ০.৫B model-এর মাপ থেকে; বড় model বা লম্বা রিভিউয়ে বাড়বে, তাই ১,০০০টি রিভিউয়ে ছোট পরীক্ষা চালিয়ে মেপে নিন। গুণগত মানের জন্য প্রতি রাতে প্রায় ৪০০টি এলোমেলো উত্তর হাতে দেখা: ±০.০৫-এর মতো ব্যবধানে হার জানতে কয়েকশো নমুনা লাগে, যা ব্লক ২-এর হিসাব।
ফলো-আপ: “বড় hosted model নয় কেন?” (ব্যক্তিগত রিভিউ বাইরে যায়, আর রাতে কোটি token বাইরে পাঠাতে হয়; ছোট local model জোড়া তুলনায় যথেষ্ট হলে সেটিই, আর quantize করার আগে-পরে একই set-এ মাপ)। “সারাংশে বানানো কথা ঢুকলে?” (সারাংশের প্রতিটি সংখ্যা আর পণ্যের নাম মূল লেখায় আছে কি না কোডে মেলানো; নমুনায় faithfulness). Red flag: মূল্যায়নে শুধু ROUGE বা একটি বিচারক model; ভাঙা JSON চুপচাপ বাদ দেওয়া; আর অভিযোগের হার বদলালে তা model-এর বদল না ক্রেতার বদল, আলাদা না করা।
“বিক্রেতারা পণ্যের ছবি তোলেন, বিবরণ লেখেন অল্প। ছবি থেকে শ্রেণি, রং আর লেবেলের লেখা বের করে ক্যাটালগ ভরাতে হবে, আর ক্রেতা যেন ছবি দিয়ে খুঁজতে পারেন।”
কাঠামো. তিনটি আলাদা কাজ, তিনটি আলাদা হাতিয়ার। খোঁজা: CLIP-এর ছবির embedding একবার হিসাব, vector index-এ (কয়েক লাখ পর্যন্ত Flat প্রায়ই যথেষ্ট, তারপর IVF বা HNSW, recall মেপে)। শ্রেণি আর রং: স্থির তালিকা, তাই embedding-এর ওপর linear probe, ইংরেজি label-এ। লেবেলের লেখা: VLM বা OCR, কিন্তু বাংলা লেখায় দুর্বলতা জানা, তাই বিক্রেতাকে দেখিয়ে নিশ্চিত করানো, মানুষ লুপে (human in the loop). মূল্যায়ন ধরন ধরে: হাতে লেবেল করা কয়েকশো ছবি, শ্রেণি অনুযায়ী ফল, আর অনুপস্থিত বৈশিষ্ট্যে “আছে” বলার হার।
প্রায় নিশ্চিত ফলো-আপ: “বাংলায় খুঁজলে?” পর্ব ৮২-এ বাংলা prompt-এ CLIP আন্দাজের কাছে ছিল, তাই query আগে ইংরেজি শ্রেণিতে বা অনুবাদে, বা বহুভাষিক text encoder, মেপে। “AI-তে বানানো বা নকল ছবি?” পর্ব ৮১-এর সতর্কতা: watermark আর detector একা যথেষ্ট নয় (সেই run-এ crop-এ দুই পদ্ধতিই ব্যর্থ), তাই প্রমাণপত্রের মান আর মানুষের যাচাই একসঙ্গে। Red flag: প্রতিটি ছবিতে VLM ডাকা, visual token-এর খরচ না ভেবে; আর ছবির ভেতরের লেখাকে নির্দেশ হিসেবে model-এ পাঠানো।
১০ · ক্যাপস্টোন নিয়ে আচরণগত প্রশ্ন, কোর্সের সমাপ্তি আর পরের পথ
রিভিশন: পর্ব ৮৬ · ক্যাপস্টোন; পুরো কোর্সের মানচিত্র: পর্ব ০১
আচরণগত প্রশ্নে STAR: Situation, Task, Action, Result, শেষে একটি শিক্ষা, দুই মিনিটে। DL আর LLM-এর গল্পে খোঁজা হয়: খারাপ সংখ্যা লুকাননি তো, আর model “বোঝে” বলেননি তো?
সততার নিয়ম: নিচের উত্তরগুলো এই কোর্সের ক্যাপস্টোনে সত্যিই যা এসেছে, সেই সংখ্যায় লেখা, শুধু কাঠামো দেখাতে। নিজে চালালে নিজের সংখ্যা বলুন; যা করেননি, তা নয়। দোকান কাল্পনিক, প্রশ্নগুলো হাতে লেখা; প্রথম বাক্যেই তা বলুন।
প্র ২৫“আপনার প্রকল্পটি তিন মিনিটে বলুন।” (সহজ)
দুর্বল উত্তর: “RAG chatbot বানিয়েছি, LangChain, vector DB, LLM, FastAPI সব আছে।” কেন দুর্বল: টুলের তালিকা; মানদণ্ড, মাপ বা ব্যর্থতা নেই।
শক্ত উত্তর: “একটি কাল্পনিক দোকানের বাংলা সহায়ক, সব model খোলা লাইসেন্সের, সব সংখ্যা নিজের run থেকে। কাজের আগে সাতটি মানদণ্ড লিখেছিলাম। Router: নিয়ম আর fine-tuned Bangla BERT. RAG: multilingual-e5-small-এ শীর্ষ ১০, bge-reranker-v2-m3-এ শীর্ষ ৩, reranker-এর score-এ gate, তারপর Qwen2.5-1.5B-Instruct. ৪০টি স্থির প্রশ্নে ২৬টি ঠিক, উত্তরহীন ৬টির ৬টিতে ‘উৎসে নেই’। Gate জোড়ায় ৫টি ভালো, ০টি খারাপ, exact p = ০.০৬২. সাতটির পাঁচটি মানদণ্ড পাস; ফেল দুটি, routing (০.৮১৬) আর p95 (৩.৮ s), model card-এ লেখা আর পরের কাজের তালিকায়।” শেষে একটি সীমা: ৪০টি প্রশ্নে ব্যবধান প্রায় ±০.১৫. রিভিশন: পর্ব ৮৬.
প্র ২৬“এমন একটি সময়ের কথা বলুন, যখন আপনার model validation-এ ভালো করেও আসল কাজে ব্যর্থ হয়েছিল।” (মাঝারি)
দুর্বল উত্তর: “আমার model-এ এমন হয়নি, validation-এ ০.৯৪ ছিল।”
শক্ত উত্তর: S: “বার্তা ভাগ করার router-এর জন্য দোকানের লেবেল করা ডেটা ছিল না; শেখালাম নাটকের মন্তব্যের একটি খোলা sentiment ডেটায়।” T: “validation-এর সংখ্যা যথেষ্ট নয়, লক্ষ্য-জগতে মাপা দরকার ছিল।” A: “run-এর আগে ৬০টি দোকানের বার্তা হাতে লিখে লেবেল দিলাম, বাংলা, Banglish আর ইংরেজি মিশিয়ে।” R: “macro-F1 ০.৮১৬, মানদণ্ড ০.৮৫ ফেল। ভুলগুলো এলোমেলো ছিল না: ‘এত দ্রুত ডেলিভারি আশা করিনি’-র মতো প্রশংসাকে প্রায় নিশ্চিত negative, আর ২০টি প্রশ্নের ১৭টিতে P(negative) ≥ ০.৫.” শিক্ষা: “লক্ষ্য-জগতের ছোট test set আগে; পরের কাজ দোকানের লেবেল করা বার্তায় router আবার শেখানো।” রিভিশন: পর্ব ৮৬.
প্র ২৭“আপনার সহায়ক ৬৫% প্রশ্নে ঠিক; এটি কতটা বিশ্বাস করব, আর গ্রাহকের ডেটা নিরাপদ তো?” (কঠিন)
দুর্বল উত্তর: “পুরোপুরি; canary test-এ একটিও ফাঁস হয়নি।” কেন দুর্বল: ছোট n থেকে বড় দাবি।
শক্ত উত্তর: “৬৫% এই ৪০টি হাতে লেখা প্রশ্নের মাপ, ৯৫% ব্যবধান মোটামুটি ±০.১৫; আসল গ্রাহকের প্রশ্নের মিশ্রণ আলাদা হবে, তাই এটি সাধারণ সত্য নয়। ভুলগুলোর ধরনও জানি: হিসাব আর দুই নথির প্রশ্নে। নিরাপত্তায় দুটি বিষাক্ত পণ্য-পাতা ৬ বার prompt-এ ঢুকেছিল, model একবারও মানেনি, গ্রাহকের কাছে শূন্য; কিন্তু আট প্রশ্নের শূন্যের ঊর্ধ্বসীমা প্রায় ৩২%. Guard বানানো তিনটি ঝুঁকির উত্তরই আটকায়, তবে ভুল উত্তর ধরে না। আর model প্রশ্ন ‘বোঝে’ বলার ভিত্তি নেই; আমরা মেপেছি উত্তরে প্রত্যাশিত তথ্য এল কি না।” রিভিশন: পর্ব ৮৬, পর্ব ৭৩.
আপনি ডিপ লার্নিং, NLP আর Generative AI কোর্সের ৯১টি পর্ব পেরিয়ে এসেছেন: NumPy-তে হাতে লেখা neuron আর backpropagation, PyTorch আর training-এর শৃঙ্খলা, CNN আর ছবি, sequence model, attention আর Transformer, বাংলা NLP, LLM-এর ভেতর, fine-tuning আর LoRA, prompt engineering, RAG আর agent, LLM নিরাপত্তা, VAE, GAN আর diffusion, multimodal model, serving আর deploy, আর একটি পূর্ণ বাংলা সহায়ক। সবচেয়ে বড় অর্জন কোনো architecture-এর নাম নয়, একটি অভ্যাস: যেকোনো চমকপ্রদ ফল দেখে জিজ্ঞেস করা, “কোন ভাগে মাপা, কয়টি নমুনায়, কার তুলনায়, কোন ভাষায় খারাপ, আর এর দাম কত token?”
এরপর কী করবেন
- আবার ঝালিয়ে নিন: যে প্রশ্নে আটকেছেন, তার রিভিশনের পর্বে ফিরুন; পাশাপাশি এই মডিউলের পর্ব ৮৭–৯০.
- নিজের একটি প্রকল্প, ক্যাপস্টোনের শৃঙ্খলায়: আগে লেখা মানদণ্ড, লক্ষ্য-জগতের test set, জোড়া তুলনা, model card আর সৎ ব্যর্থতার তালিকা।
- পরের AI কোর্স (প্রস্তুত হচ্ছে): computer vision, reinforcement learning, MLOps, data engineering আর AI ethics. পাশের সম্পূর্ণ কোর্স: System Design, Cloud আর DevOps, Cybersecurity, Full-Stack Web Frameworks.
এই পাতা কোনো চাকরির নিশ্চয়তা দেয় না; আপনার হাতে আছে যাচাই করা যায় এমন কাজ, আর তা সীমাসহ সৎভাবে বলতে পারা।
AI-এর যুগে DL আর LLM ইন্টারভিউর প্রস্তুতি
AI assistant একজন ধৈর্যশীল নকল ইন্টারভিউয়ার হতে পারে, কিন্তু এই বিষয়ে তার ভুলগুলো পরিচিত: পুরোনো বা বানানো library API (transformers, peft বা trl-এর সরানো argument, বাদ পড়া torch function); tensor-এর shape, dim আর dtype গুলিয়ে ফেলা; model.eval(), torch.no_grad() বা zero_grad ভুলে যাওয়া; test ডেটা ফাঁস; একটি ভাগ্যবান run-কে ফল বলা; LLM কী “বোঝে” তা বাড়িয়ে বলা; আর বিশ্বাসযোগ্য কিন্তু ভুল derivation বা citation. System design-এ সে টুলের তালিকা দেয়, token-এর হিসাব আর মূল্যায়ন বাদ দেয়। তাই তাকে উত্তর লিখতে না বলে আপনাকে চেপে ধরতে বলুন।
কোনো আসল প্রতিষ্ঠানের ডেটা, কোড, API key বা মানুষের তথ্য কখনো দেবেন না।
আরও গভীরে: Patrick Lewis ও সহকর্মীদের RAG প্রবন্ধ (NeurIPS ২০২০) খুঁজে আনা নথির ওপর উত্তর তৈরির ধারণাটি জনপ্রিয় করে, আর Hoffmann ও সহকর্মীদের Chinchilla প্রবন্ধ (২০২২) একই compute-এ model আর ডেটার ভাগ নিয়ে প্রশ্ন ৪-এর ভিত্তি। LLM-কে বিচারক বানানোর অবস্থান আর দৈর্ঘ্যের পক্ষপাত নিয়ে Lianmin Zheng ও সহকর্মীদের ২০২৩ সালের MT-Bench প্রবন্ধ প্রায়ই উদ্ধৃত হয়। Indirect prompt injection-এর প্রথম দিকের বিশদ বিশ্লেষণ Kai Greshake ও সহকর্মীদের (২০২৩)।
নিজেকে যাচাই করুন
ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।
ক্রমএকটি GenAI system design ইন্টারভিউতে আলাপের ধাপগুলো সঠিক ক্রমে সাজান (▲▼ চেপে সরান)
- কাজ, ভাষা, বাদের তালিকা আর latency ও খরচের লক্ষ্য জিজ্ঞেস করে ঠিক করা
- Peak অনুরোধ আর token থেকে ধারণক্ষমতা ও খরচের হিসাব
- Router, RAG আর gate, model বাছাই আর cache-এর নকশা
- Eval set, অংশ ধরে মাপ আর জোড়া তুলনায় লঞ্চের নিয়ম
- PII, injection, অধিকারের সীমা, fallback আর নজরদারি
(মাঝারি) একটি ছোট language model-এ parameter দ্বিগুণ করলে loss প্রায় একই থাকে (log-log ঢাল প্রায় ০), কিন্তু training ডেটা দ্বিগুণে loss প্রায় ৮% কমে। পরের compute আর শ্রম কোথায় যাবে?
- আরও বড় model-এ
- শুধু learning rate খুঁজতে
- বেশি ডেটা আর regularization-এ
- কোথাও নয়, model তার সীমায় পৌঁছেছে
(মাঝারি) একটি দোকানের ফেরত-নীতি প্রতি মাসে বদলায়, আর সহায়ককে উৎস দেখিয়ে উত্তর দিতে হবে। প্রথম পছন্দ কোনটি?
- নীতির নথিতে full fine-tuning
- RAG, উৎসের নম্বর আর “উৎসে নেই”-এর পথসহ
- কোনো উৎস ছাড়া বড় model-কে সরাসরি জিজ্ঞেস করা
- প্রতি মাসে নতুন LoRA adapter
(মাঝারি) একই ৪০টি প্রশ্নে পুরোনো prompt ২১টি, নতুন prompt ২৬টি ঠিক; নতুনটি ৫টিতে ভালো, ০টিতে খারাপ। সবচেয়ে উপযুক্ত পরীক্ষা কোনটি?
- স্বাধীন দুই অনুপাতের z test
- শুধু গড় তুলনা: ৬৫% বনাম ৫২.৫%
- দুটি আলাদা CI একে অপরকে ছোঁয় কি না দেখা
- McNemar-এর exact test বা paired bootstrap
(কঠিন) একটি RAG সহায়কের উত্তরযোগ্য ভুলগুলোর বেশির ভাগে সঠিক নথি শীর্ষ ৩-এ ছিল। কোথায় কাজ করা সবচেয়ে যুক্তিসংগত?
- উত্তর-লেখার অংশে: হিসাব কোডে, prompt আর generator বদলে জোড়ায় মাপা
- বড় embedding model নেওয়া
- Chunk-এর আকার বদলানো
- শীর্ষ ৩-এর বদলে শীর্ষ ১০টি নথি দেওয়া
(মাঝারি) একটি model-এর config: ২৮টি স্তর, ১২টি query head, ২টি KV head, head_dim ১২৮, bf16. প্রতি token-এ KV cache কত byte?
- ১৪,৩৩৬
- ১,৭২,০৩২
- ২৮,৬৭২
- ৫৭,৩৪৪
(কঠিন) ৪৮টি prompt injection-এর চেষ্টায় একটিও সফল হয়নি। রিপোর্টে কোন বাক্যটি সবচেয়ে সৎ?
- “সহায়ক prompt injection থেকে নিরাপদ।”
- “৪৮টি জানা ধরনের চেষ্টায় দেখা যায়নি; আসল হার ৯৫% নিশ্চয়তায় প্রায় ৭.৪%-এর নিচে।”
- “আসল সফলতার হার ঠিক ৬.২%.”
- “এই পরীক্ষা থেকে কিছুই বলা যায় না।”
শব্দকোষ
লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব শব্দ এখানে একসাথে:
মনে রাখুন
- প্রতিটি দাবির পাশে baseline, ভাগের নাম, n আর CI; একই ভাগে না হারালে deep model নয়।
- “বড় model না বেশি ডেটা” log-log-এর ঢাল বলে দেয়; মাপা সীমার বাইরে সূত্রে ভরসা নয়।
- বদলানো জ্ঞান RAG-এ, আচরণ fine-tune-এ, আর সবার আগে prompt-এর baseline.
- দুই সংস্করণ জোড়ায় তুলনা; বিচারক model-কে আগে মানুষের সঙ্গে মেলানো; শূন্য সাফল্য মানে একটি ঊর্ধ্বসীমা.
- খরচ, latency আর memory token-এ: বাংলায় বেশি token, prompt-ই বড় অংশ, KV cache ঠিক করে কয়টি অনুরোধ একসঙ্গে।
- নকশায় দেয়াল model-এর বাইরে: PII ঢাকা, least privilege, output guard, fallback আর trace.
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- ডিপ লার্নিং, NLP আর Generative AI · কোর্স হোম৯১টি পর্বপুরো রোডম্যাপ। যে মডিউলে দুর্বল মনে হলো, সেখানে ফিরে যান।
- পর্ব ৮৫ · GenAI system designনকশাধারণক্ষমতা, cache, guardrail আর fallback; অংশ ৮–৯-এর ভিত্তি।
- পর্ব ৮৬ · ক্যাপস্টোনআবার করুনঅংশ ১০-এর STAR গল্পের উৎস; নিজে চালিয়ে নিজের সংখ্যা বানান।
- মেশিন লার্নিং · ধারণার ইন্টারভিউভিত্তিCalibration, drift, A/B test আর ML system design-এর mock.
- System Design · Mock ইন্টারভিউপাশের ট্র্যাকবড় distributed ব্যবস্থার নকশার আলাপে হাত ঝালাই।
- Cloud আর DevOps · DevOps ইন্টারভিউপাশের ট্র্যাকDeploy, canary, নজরদারি আর incident-এর প্রশ্ন।