What Evals Really Measure
Module 3 শেষ, আজ (Day 25) থেকে Module 4 (RAG & Systems) শুরু — একটা prompt না, একটা পুরো system মাপা শেখো। Reference-based, reference-free, আর LLM-as-a-judge — আর judge-কে নিজেই কীভাবে validate করবে।
- •Eval কেন লাগে — "মনে হচ্ছে ভালো" (vibes) কেন scale করে না, আর eval সেই জায়গায় কী দেয়।
- •একটাই মূল প্রশ্ন: gold answer আছে কি নেই — এটাই reference-based বনাম reference-free-র কাঁটা।
- •Reference-based metric চেনা: exact match, word overlap (BLEU/ROUGE), embedding similarity — কোনটা কখন, আর কোথায় ভাঙে।
- •Reference-free eval — gold ছাড়া output-এর নিজের গুণ মাপা (faithfulness, relevance, safety)।
- •LLM-as-a-judge: pointwise বনাম pairwise, আর তার তিনটা bias — position, verbosity, self-preference।
- •Judge ≠ সত্য — judge-কে human label-এর সাথে মিলিয়ে validate করা ("measure your measurer")।
- •Day 11 — eval harness: runner + assertions (exact_match) নিজে হাতে বানানো।
- •Day 12 — prompt versioning + pass rate over time; একটা change কীভাবে regression আনে।
- •Day 2 — embedding: কাছাকাছি অর্থ = কাছাকাছি vector (embedding similarity-র ভিত্তি)।
Why Eval, Not Vibes
Module 3-তে prompt আর tool শিখেছ। আজ থেকে Module 4 — একটা পুরো system বানানো আর মাপা।
Module 3-তে Claude Code চালিয়েছ, tool wire করেছ, guardrail বসিয়েছ, খরচ-গতি মেপেছ — একটা prompt নিয়ে কাজ। আজ (Day 25) থেকে Module 4 (RAG & Systems) শুরু — এখন prompt থেকে system-এ যাবে: বাইরের জ্ঞান যোগ করা, আর পুরো output সংখ্যায় বিচার করা। প্রথম ধাপ: eval আসলে কী মাপে। "মনে হচ্ছে ভালো" (vibes) দিয়ে দুটো prompt-এর তুলনা হয় না — আজ শিখবে output-কে ঠিক কীভাবে মাপতে হয়।
Eval, not vibesমাপা ছাড়া উন্নতি নেই
Output পড়ে "বাহ, ভালো লাগছে" — এটা vibes। দুটো prompt-এর কোনটা ভালো, ১০০টা case-এ কোনটা বেশি পাস করে, কাল কোন change জিনিসটা ভাঙল — vibes কিছুই বলতে পারে না। Eval = একটা মাপার ruler: input-এর একটা set, আর প্রতিটায় ভালো/খারাপ মাপার নিয়ম।
একটা common trap: বেশিরভাগ মানুষ শুধু prompt বদলায়, কখনো মাপে না — তাই কখনো demo-র বাইরে যেতে পারে না। যা মাপতে পারো না, তা উন্নত করতে পারো না। Day 4 থেকে এই সুর চলছে — আজ (Day 25) ঠিক কী মাপছি সেটাই খুলবো।
Eval settest case-এর সংগ্রহ
Eval-এর কাঁচামাল: কতগুলো input, আর (কখনো) তার expected output বা মাপার rubric। ছোট শুরু করো — ১০–৫০টা — তারপর প্রতিটা নতুন bug ধরা পড়লে সেটাকে একটা test case বানিয়ে যোগ করো। Set-টা জীবন্ত, বাড়তেই থাকে।
Day 11-এ তুমি হাতে ১০টা test case বানিয়েছিলে — ওটাই ছিল তোমার প্রথম eval set। আজকের প্রশ্ন: ঐ set-এর প্রতিটা case-এ "ঠিক হয়েছে" মাপবে কীভাবে? উত্তরটা task-এ gold answer আছে কি নেই তার উপর।
Gold answer?পুরো দিনের কাঁটা
একটাই প্রশ্ন সব ঠিক করে দেয় — এই input-এর কি একটা জানা সঠিক উত্তর (gold / ground truth) আছে? থাকলে: candidate-টাকে ঐ gold-এর সাথে মেলাও (reference-based)। না থাকলে: output-এর নিজের গুণ বিচার করো (reference-free)।
Classification, extraction, translation — gold আছে। Summary, খোলা chat reply, creative writing — কোনো single সঠিক উত্তর নেই। তাই eval-এর প্রথম সিদ্ধান্ত metric না, এই প্রশ্নটা। ভুল শাখায় গেলে পুরো মাপ ভুল হবে।
Reference-Based — Match The Gold
Gold answer আছে? candidate-টাকে তার সাথে মেলাও — কিন্তু কড়া থেকে নরম, তিন রকম মেলানো আছে।
Gold answer থাকলে কাজটা সহজ মনে হয় — মিললে ঠিক, না মিললে ভুল। কিন্তু "মেলা" মানে কী, তার তিনটা স্তর আছে: হুবহু string মেলা, শব্দ-জোড়া মেলা, আর অর্থ মেলা। একই জোড়া, তিন metric — নিচে চাপ দিয়ে দেখো কতটা আলাদা নম্বর আসে।
Reference-basedexact · overlap · embedding
Gold answer-এর সাথে candidate কতটা মেলে। তিনটা সিঁড়ি, কড়া থেকে নরম: exact match (হুবহু string), word overlap — BLEU (precision, translation) / ROUGE (recall, summary) (কয়টা n-gram মেলে), আর embedding similarity / BERTScore (অর্থ মেলে কিনা, শব্দ না)।
একই "ঠিক" উত্তর অনেকভাবে লেখা যায়। Exact match "Dhaka is the capital" আর "The capital is Dhaka"-কে আলাদা বলবে; overlap মাঝামাঝি দেবে; embedding প্রায় সমান বলবে। তাই metric বাছার আগে জানো — তোমার task কি single-string, নাকি "একই অর্থ ভিন্ন শব্দ" allow করে?
BLEU/ROUGE score বেশি মানেই উত্তরটা ভালো।
Reference-Free & Judge Models
Gold নেই — production-এর বেশিরভাগ কাজ এই ঘরে পড়ে। তখন output-এর নিজের গুণ মাপো।
Reference-freegold ছাড়া গুণ মাপা
Gold নেই, তাই কারো সাথে মেলানোর উপায় নেই। বদলে output-এর নিজস্ব গুণ মাপো: source-এর সাথে faithful? প্রশ্নের সাথে relevant? নিরাপদ (safe)? সুসংগত (coherent)? এগুলোর জন্য reference লাগে না — output আর (কখনো) তার source-ই যথেষ্ট।
Summary, RAG-এর উত্তর, chatbot reply — এদের কোনো answer key নেই। তবু মাপতে হবে। "এই summary কি মূল লেখার বাইরে কিছু বানিয়েছে (hallucination)?" — এটা reference ছাড়াই, শুধু summary আর source দেখে বিচার করা যায়। বেশিরভাগ production-এর কাজ এই ঘরেই পড়ে।
LLM-as-a-judgejudge model — rubric দিয়ে নম্বর
Reference-free মাপা automate করার সবচেয়ে জনপ্রিয় উপায়: একটা strong LLM-কে rubric দিয়ে অন্য একটা output-এ নম্বর দেওয়াও। দুই ধরন — pointwise (একটা output-কে একা 1–5 score) আর pairwise (A বনাম B, কোনটা ভালো)। Subjective মানে pairwise বেশি stable।
১০,০০০টা summary মানুষ দিয়ে রোজ মাপা অসম্ভব — judge সেটা সেকেন্ডে করে। কিন্তু judge মানুষের মতো রায় দেয় না, একটা model-এর রায় দেয় — তার নিজের পক্ষপাত নিয়ে। তাই এটা শক্তিশালী, তবে অন্ধভাবে বিশ্বাস করার জিনিস না।
একই task ভিন্ন পথে — নিচের widget-এ একেকটা কাজ বেছে দেখো gold আছে কিনা, আর তার উপর ভিত্তি করে কোন eval family সুপারিশ করা হয়।
Eval মানেই accuracy % — reference ছাড়া মাপা যায় না।
Judge Biases — Not The Truth
LLM judge সত্যের আয়না না — তার measured, predictable পক্ষপাত আছে।
Judge biasesposition · verbosity · self
LLM judge সত্যের আয়না না — তার মাপা যায় এমন পক্ষপাত আছে। Position bias: যে উত্তর আগে দেখানো হয় সেটাই বেশি বেছে নেয় (Claude-v1 ~৭০%)। Verbosity bias: লম্বা উত্তর বেশি পছন্দ, একই তথ্য থাকলেও (>৯০%)। Self-preference: নিজের model-এর লেখা উত্তর বেশি পছন্দ (GPT-4 +১০%, Claude-v1 +২৫%)।
এগুলো ছোট ভুল না — কখনো ৭০–৯০%। মানে judge-এর একটা score দেখে "B ভালো" ভাবলে, আসলে হয়তো B শুধু লম্বা বা আগে ছিল। এই তিনটা না জানলে judge তোমাকে আত্মবিশ্বাসের সাথে ভুল পথে নেবে।
LLM judge মানে objective, নিরপেক্ষ সত্য।
Measure Your Measurer
Judge নিজেই একটা মাপার যন্ত্র — আর প্রতিটা যন্ত্র calibrate করতে হয়।
Validate the judgemeasure your measurer
Judge নিজেই একটা মাপার যন্ত্র — আর প্রতিটা যন্ত্র calibrate করতে হয়। কয়েকটা (২০–৫০) example তুমি/মানুষ হাতে label করো, তারপর judge-এর রায় তার সাথে মেলাও। কত শতাংশ মিলল (agreement / Cohen's kappa)? কম মিললে rubric বদলাও, আবার মেলাও — judge-কে মানুষের কাছাকাছি আনো।
এটাই দিনের আসল মোচড়: judge-এর score বিশ্বাস করার আগে judge-টাকেই মাপো। বাস্তব ডেটায় ভালো judge-ও মানুষের তুলনায় পিছিয়ে থাকে (GPT-4 κ≈0.84, মানুষ-মানুষ 0.97)। "আমার eval বলছে ৯০%" — কিন্তু judge-ই যদি ৬৭% নির্ভরযোগ্য হয়, ঐ ৯০% ফাঁপা।
Which eval, whenসিদ্ধান্তের নকশা
Gold আছে + single string (classify, extract) → exact match। Gold আছে, কিন্তু wording নমনীয় (translate, paraphrase) → embedding similarity। Gold নেই (summary, chat, RAG) → reference-free, সাধারণত LLM-as-a-judge — আর judge-টাকে validate করো। বাস্তবে প্রায়ই কয়েকটা একসাথে: দ্রুত smoke test-এ overlap, গভীর মাপে embedding/judge, calibrate-এ মানুষ।
কোনো একটা metric "সেরা" না — task-এর সাথে মেলানোটাই skill। ভুল metric মানে সবুজ dashboard নিয়ে ভুল জিনিস ship করা। আজ থেকে যেকোনো eval দেখলে প্রথম প্রশ্ন করবে: এর gold answer আছে? judge হলে কি validate করা হয়েছে?
একটা ভালো judge prompt বানালে সেটা সব task-এ চলবে।
Judge হিসেবে সবচেয়ে strong model নিলেই নিশ্চিন্ত।
The Eval Flywheel
Eval একটা নম্বর না — একটা চক্র। এটাই demo-কে product বানায়।
আজকের সব টুকরো — reference-based, reference-free, judge, validate — একসাথে একটা চক্রে ঘোরে: মাপো, সবচেয়ে খারাপ failure পড়ো, ঐ pattern ধরে ঠিক করো, আবার মাপো। রাফির ticket-classifier-এ এই চক্রটা এক পাক ঘুরিয়ে দেখো।
এই চক্রটাই Module 4-র বাকি অংশের ভিত্তি — একটা RAG system বানানোর সময়ও একই প্রশ্ন ফিরে আসবে: gold আছে কি নেই, output-টা faithful কিনা, আর judge-টাকে validate করা হয়েছে কিনা।
Check Your Understanding
ভুল হলে সমস্যা নেই — প্রতিটার ব্যাখ্যা আছে।
Eval-এর প্রথম, সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত কী?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
"একই অর্থ, ভিন্ন শব্দ" উত্তরে কোন reference-based metric সবচেয়ে দুর্বল?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
৩ পাতার report-এর ৫-bullet summary মাপতে কোন family?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
Judge A আর B-র মধ্যে A আগে রাখলে A জেতে, B আগে রাখলে B জেতে — কোন bias?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
LLM judge-এর score trust করার আগে কী করতে হবে?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
Translation-এর জন্য classic overlap metric কোনটা, summarization-এর জন্য কোনটা?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
দুটো উত্তরে হুবহু একই তথ্য, কিন্তু judge লম্বাটা বেছে নিল — কোন bias, fix কী?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
Prove It To Yourself
চারটা takeaway মনে রাখো — আর Module 4-র প্রথম day শেষ।
চারটা জিনিস মনে রাখো — One fork rules eval: gold answer আছে? থাকলে reference-based (exact/overlap/embedding), না থাকলে reference-free। এই প্রশ্নটাই আগে। Overlap counts words, not meaning: BLEU/ROUGE paraphrase-এ ভাঙে — একই অর্থ ভিন্ন শব্দ হলে embedding বা judge ধরো। A judge has biases: position (~৭০%), verbosity (>৯০%), self-preference (+১০–২৫%) — LLM judge সত্যের আয়না না। Measure your measurer: judge-এর score বিশ্বাসের আগে কিছু human label-এর সাথে মিলিয়ে validate করো — নাহলে সবুজ dashboard ফাঁপা।
আজকের শব্দগুলো — eval set, ground truth, reference-based, reference-free, exact match, BLEU, ROUGE, embedding similarity, BERTScore, LLM-as-a-judge, pointwise, pairwise, rubric, position bias, verbosity bias, self-preference bias, agreement (Cohen's kappa) — এখন থেকে English-ই থাকবে; কাজের eval README পড়তে এভাবেই লাগবে। পুরো তালিকা নিচের glossary-তে। পরের lesson থেকে Module 4-র বাকি অংশ — prompt থেকে system, RAG দিয়ে বাইরের জ্ঞান যোগ করা।
শব্দার্থ — পরে ফিরে দেখার জন্য
একনজরে সব key term। কোনো শব্দ ভুলে গেলে এখানে এসে খুঁজে নিও।
- Agreement / Cohen's kappa
- Judge আর human label কতটা মেলে তার মাপ (chance বাদ দিয়ে)।
- BERTScore
- Embedding-ভিত্তিক similarity metric — paraphrase ধরে, overlap-এর চেয়ে human-এর কাছে।
- BLEU
- n-gram precision; machine translation-এর classic overlap metric।
- Embedding similarity
- দুটো লেখাকে vector-এ এনে অর্থের কাছাকাছি কিনা মাপা (শব্দ না)।
- Eval
- Model/prompt-এর output মাপার পদ্ধতি — input-এর set + ভালো/খারাপ মাপার নিয়ম।
- Eval set / test case
- যে input-গুলোতে মাপা হয় (+ কখনো expected output বা rubric); জীবন্ত, বাড়ে।
- Exact match
- হুবহু string মিললে ১, নাহলে ০ — কড়া reference-based metric।
- Ground truth / gold label
- জানা সঠিক উত্তর, যার সাথে candidate মেলানো হয়।
- LLM-as-a-judge
- একটা strong LLM দিয়ে rubric মেনে অন্য output-এ নম্বর দেওয়ানো।
- n-gram overlap
- candidate ও reference-এর মধ্যে কয়টা শব্দ-জোড়া মেলে তার মাপ।
- Pairwise
- দুটো output তুলনা করে কোনটা ভালো বলা — subjective-এ বেশি stable।
- Pass rate
- eval set-এ কত শতাংশ case পাস করল।
- Pointwise
- একটা output-কে একা score করা (যেমন 1–5)।
- Position bias
- Judge আগে দেখানো উত্তরকে বেশি বেছে নেওয়ার প্রবণতা।
- Reference-based
- Gold answer-এর সাথে মিলিয়ে মাপা।
- Reference-free
- Gold ছাড়া output-এর নিজের গুণ মাপা (faithful, relevant, safe)।
- ROUGE
- n-gram recall; summarization-এর classic overlap metric।
- Rubric
- Judge-কে দেওয়া স্পষ্ট মাপকাঠি — কী দেখে নম্বর দেবে।
- Self-preference bias
- Judge নিজের model-এর লেখা উত্তর বেশি পছন্দ করা।
- Verbosity bias
- Judge লম্বা উত্তরকে বেশি পছন্দ করা — একই তথ্য হলেও।
Sources consulted to author this lesson. Citation style is informal — follow the links if you want to dig deeper.
- Your AI Product Needs Evals — Hamel Husain (2024)
- LLM-evaluators (aka LLM-as-a-judge) — Eugene Yan (2024)
- LLM evaluation metrics, explained simply — Evidently AI (2025)
- LLM evaluation benchmarking — Beyond BLEU and ROUGE — Weights & Biases (2024)
- LLMs-as-Judges: A Comprehensive Survey on LLM-based Evaluation Methods — Li et al. (2024)
- Building Effective Agents — Anthropic (2024)
দুই বাক্যে নিজের ভাষায় লেখো
নিজের ভাষায় দুই বাক্যে লেখো — eval-এর সবচেয়ে গুরুত্বপূর্ণ প্রথম প্রশ্নটা কী (reference-based বনাম reference-free ঠিক করে), আর LLM judge-এর score বিশ্বাস করার আগে কী করতে হয়।