Home » Blog » AI/ML Engineer সিরিজ » Series 08 » Episode 06

RAG Evaluation: 'ভালো RAG' কীভাবে মাপব? (faithfulness, relevance)

RAG মাপার পদ্ধতি (Series 08, Episode 06)

🔴 ADVANCED Series 08 — Generative AI Engineering Episode 06 / 09

📑 এই পর্বে যা যা আছে

১. গল্প: "ভালো হয়েছে" — কিন্তু কতটা?
২. সমস্যা: চোখে দেখা evaluation স্কেল করে না
৩. RAG-এর দুই অংশ আলাদা করে মাপা
৪. মূল metric: faithfulness, answer relevance, context relevance
৫. তিন স্তরে বোঝা
৬. Retrieval metric: recall@k, precision@k, MRR
৭. Code: একটা ছোট eval harness
৮. LLM-as-a-judge — সাবধানতাসহ
৯. Golden dataset কীভাবে বানাবেন
১০. বাস্তব উদাহরণ: বাংলাদেশের context
১১. Boss Question
১২. Job Requirement Decoder
১৩. সাধারণ ভুল
১৪. Interview Prep
১৫. হাতে-কলমে
১৬. Project Connection
১৭. সারসংক্ষেপ ও পরবর্তী পর্ব

🧩 ১. গল্প: "ভালো হয়েছে" — কিন্তু কতটা?

Rahim reranking যোগ করার পর boss-কে বলল "এখন RAG অনেক ভালো"। Boss পাল্টা জিজ্ঞেস করলেন — "কতটা ভালো? আগের চেয়ে ২০% ভালো, নাকি ২%? কোন প্রশ্নে খারাপ করছে? তুমি প্রমাণ কী দেখাবে?" Rahim চুপ। তার কাছে "মনে হচ্ছে ভালো" ছাড়া কোনো সংখ্যা নেই।

Maya: "এটাই junior আর senior-এর সবচেয়ে বড় পার্থক্য। যে RAG মাপতে পারে না, সে RAG উন্নত করতে পারে না — কারণ কোন পরিবর্তন সাহায্য করল আর কোনটা ক্ষতি করল, সে জানবে না। RAG evaluation শেখো — interview-তেও এই একটা প্রশ্ন তোমাকে আলাদা করে দেবে।"

❓ ২. সমস্যা: চোখে দেখা evaluation স্কেল করে না

৫টা প্রশ্নের উত্তর চোখে পড়ে "ঠিক আছে" বলা যায়। কিন্তু ৫০০টা প্রশ্ন? বা reranker বদলালে পুরো system আবার যাচাই? manual eval ধীর, subjective ও পুনরাবৃত্তিহীন। দরকার — পরিমাপযোগ্য, পুনরাবৃত্তিযোগ্য metric, যাতে প্রতিটা পরিবর্তনের প্রভাব সংখ্যায় দেখা যায়।

মূল দর্শন: "তুমি যা মাপতে পারো না, তা উন্নত করতে পারো না।" RAG evaluation = আপনার system-এর report card।

🧩 ৩. RAG-এর দুই অংশ আলাদা করে মাপা

RAG দুটো ধাপ — retrieval আর generation। উত্তর খারাপ হলে দোষ কার? আলাদা না মাপলে বোঝা যায় না।

প্রশ্ন → [ Retrieval ] → context → [ Generation ] → উত্তর │ │ Retrieval মাপো: Generation মাপো: সঠিক chunk এল কি? context মেনে উত্তর দিল কি?

উত্তর খারাপ + retrieval খারাপ → chunking/rerank ঠিক করুন। উত্তর খারাপ + retrieval ঠিক → prompt/generation ঠিক করুন। এই diagnosis-ই evaluation-কে মূল্যবান করে।

📊 ৪. মূল metric: faithfulness, answer relevance, context relevance

Metric	কী মাপে	কম হলে সমস্যা
Faithfulness	উত্তর কি শুধু context থেকে? (বানায়নি তো?)	hallucination হচ্ছে
Answer relevance	উত্তর কি আসলে প্রশ্নের উত্তর দিল?	এড়িয়ে/অপ্রাসঙ্গিক উত্তর
Context relevance	retrieved chunk কি প্রশ্নের সাথে প্রাসঙ্গিক?	retrieval দুর্বল

এই তিনটা হলো RAG eval-এর হৃদয় (ragas-এর মতো tool এগুলোই মাপে)। faithfulness হলো hallucination-এর উল্টো — উচ্চ faithfulness মানে model context-এর বাইরে যায়নি।

🪜 ৫. তিন স্তরে বোঝা

Level 1 — সহজ intuition

একটা open-book পরীক্ষার খাতা দেখা ভাবুন। তিনটা প্রশ্ন করবেন: (১) ছাত্র কি বইয়ের বাইরে থেকে বানিয়ে লিখেছে? (faithfulness) (২) আসল প্রশ্নের উত্তর দিয়েছে, নাকি ঘুরিয়ে? (answer relevance) (৩) সে যে পৃষ্ঠা খুলেছিল, সেটা কি ঠিক পৃষ্ঠা? (context relevance)।

Level 2 — technical ভাবে কী হচ্ছে

প্রতিটা metric ০-১ স্কেলে স্কোর দেয়। faithfulness = উত্তরের claim গুলোর কত অংশ context দিয়ে সমর্থিত। answer relevance = উত্তর ও প্রশ্নের semantic মিল। context relevance = retrieved chunk-এর কত অংশ আসলে কাজে লেগেছে।

Level 3 — engineer perspective

Engineer একটা golden dataset (প্রশ্ন + expected তথ্য) বানিয়ে CI-তে eval চালায় — প্রতিটা কোড/prompt পরিবর্তনে স্কোর ওঠানামা track করে। এটা RAG-কে "vibe check" থেকে "engineering discipline"-এ নিয়ে যায়।

🎯 ৬. Retrieval metric: recall@k, precision@k, MRR

যদি জানা থাকে কোন chunk "সঠিক" (labeled), তাহলে retrieval-কে সরাসরি মাপা যায়:

Recall@k: সঠিক chunk গুলোর কত অংশ top-k-এ এল। (সঠিকটা কি ধরা পড়ল?)
Precision@k: top-k-এর কত অংশ আসলে প্রাসঙ্গিক। (অপ্রাসঙ্গিক ঢুকছে কি?)
MRR (Mean Reciprocal Rank): প্রথম সঠিক chunk গড়ে কত নম্বরে আসে। (সেরাটা কি উপরে?)

RAG উন্নত করার সময় প্রথমে retrieval metric দেখুন — কারণ retrieval খারাপ হলে generation যতই ভালো হোক, উত্তর খারাপই থাকবে।

💻 ৭. Code: একটা ছোট eval harness

কেন নিজের harness? — বড় tool-এর আগে ধারণাটা হাতে বোঝা দরকার। এখানে একটা golden set-এ retrieval recall@k মাপছি (কোনো external service ছাড়াই, তাই junior-রা সহজে চালাতে পারে)।

# golden set: প্রতিটা প্রশ্নের জন্য কোন chunk_id সঠিক তা জানা golden = [ {"q": "Python job আছে?", "relevant_ids": {3, 7}}, {"q": "remote FastAPI role?", "relevant_ids": {12}}, {"q": "junior ML salary?", "relevant_ids": {5, 9}}, ] def recall_at_k(retrieved_ids, relevant_ids): if not relevant_ids: return 0.0 hit = len(set(retrieved_ids) & relevant_ids) return hit / len(relevant_ids) def evaluate(retrieve_fn, k=5): scores = [] for item in golden: ids = retrieve_fn(item["q"], k=k) # list[int] r = recall_at_k(ids, item["relevant_ids"]) scores.append(r) print(f"{item['q']:30s} recall@{k} = {r:.2f}") avg = sum(scores) / len(scores) print(f"\nAverage recall@{k} = {avg:.2f}") return avg # baseline বনাম reranked তুলনা করুন: # evaluate(vector_only_retrieve) # evaluate(retrieve_and_rerank)

এই একই harness দিয়ে "reranking যোগ করার আগে ও পরে" average recall তুলনা করলেই boss-এর প্রশ্নের সংখ্যাগত উত্তর হাতে চলে আসে।

⚖️ ৮. LLM-as-a-judge — সাবধানতাসহ

faithfulness/answer-relevance-এর মতো subjective metric-এ প্রায়ই একটা শক্তিশালী LLM-কে "বিচারক" বানানো হয় — সে উত্তর ও context দেখে ০-১ স্কোর দেয়। এটা দ্রুত ও scalable, কিন্তু নিখুঁত নয়।

সতর্কতা: LLM judge-ও ভুল করে, bias থাকে, আর নিজের ঘরানার উত্তরকে বেশি নম্বর দিতে পারে। তাই — (১) judge prompt স্পষ্ট রাখুন, (২) কিছু নমুনা মানুষ দিয়ে verify করুন, (৩) শুধু judge-এর উপর চূড়ান্ত সিদ্ধান্ত না নিয়ে retrieval metric-এর সাথে মিলিয়ে দেখুন।

🗂️ ৯. Golden dataset কীভাবে বানাবেন

২০-৫০টা বাস্তব প্রশ্ন সংগ্রহ করুন (user log বা domain expert থেকে)।
প্রতিটার জন্য লিখুন: expected উত্তর/মূল তথ্য, এবং কোন chunk/source সঠিক।
সহজ, কঠিন ও "উত্তর নেই" — তিন ধরনের প্রশ্ন রাখুন (grounding যাচাই করতে)।
এটা version control-এ রাখুন; system বদলালে এর বিপরীতে re-run করুন।

ছোট কিন্তু যত্নে বানানো golden set বড় কিন্তু এলোমেলো set-এর চেয়ে অনেক বেশি কার্যকর। ৩০টা ভালো উদাহরণ দিয়েই শুরু করা যায়।

🇧🇩 ১০. বাস্তব উদাহরণ: বাংলাদেশের context

একটা bank assistant deploy করার আগে ৪০টা বাস্তব policy প্রশ্নের golden set-এ faithfulness যাচাই — ভুল উত্তর মানে regulatory ঝুঁকি।
একটা edtech "উত্তর নেই" প্রশ্ন দিয়ে যাচাই করে assistant বানিয়ে বলছে কিনা।
দুটো embedding model-এর মধ্যে কোনটা Bangla-তে ভালো — recall@k তুলনা করে সিদ্ধান্ত।

💼 ১১. Boss Question

Boss: "evaluation-এ সময় দিলে তো নতুন feature দেরি হবে। দরকার কী?"

উত্তর: eval ছাড়া প্রতিটা "improvement" আসলে অন্ধকারে ঢিল। একটা পরিবর্তন হয়তো একদিকে ভালো করছে, অন্যদিকে ভাঙছে — eval না থাকলে জানবই না, আর একদিন production-এ ভুল উত্তর গিয়ে সম্মান ও টাকা দুটোই যাবে। ছোট eval harness একবার বানালে প্রতিটা future পরিবর্তন সেকেন্ডে যাচাই হয় — এটা দীর্ঘমেয়াদে গতি বাড়ায়, কমায় না।

🔎 ১২. Job Requirement Decoder

JD: "Experience evaluating LLM / RAG systems"।

১. কী বোঝায়? RAG-এর quality metric দিয়ে মাপা ও উন্নত করার ক্ষমতা।
২. কেন চায়? production LLM system unreliable হলে বিপদ; মাপতে না পারলে বিশ্বাসযোগ্য করা অসম্ভব।
৩. কোন সমস্যা সমাধান করে? "মনে হচ্ছে ভালো" থেকে সংখ্যাভিত্তিক, পুনরাবৃত্তিযোগ্য মান নিয়ন্ত্রণ।
৪. junior-এর কী জানা লাগে? faithfulness/answer/context relevance, recall@k, golden set, LLM-as-judge-এর সীমা।
৫. এখনই কী master লাগে না? বড় automated eval pipeline, human-annotation ops, custom metric গবেষণা।
৬. GitHub-এ কীভাবে দেখাবে? RAG repo-তে একটা eval/ ফোল্ডার — golden set + recall script + before/after table।
৭. interview প্রশ্ন? "RAG কীভাবে evaluate করবে?", "faithfulness মানে?", "retrieval ভালো কিনা কীভাবে মাপবে?"

⚠️ ১৩. সাধারণ ভুল

ভুল ১: শুধু final উত্তর দেখা, retrieval আলাদা না মাপা। → দোষ কোথায় বোঝা যায় না।

ভুল ২: golden set না রাখা। → প্রতিবার নতুন করে চোখে যাচাই, inconsistent।

ভুল ৩: LLM-judge-কে অভ্রান্ত ভাবা। → নমুনা মানুষ দিয়ে verify করুন।

ভুল ৪: "উত্তর নেই" কেস eval-এ না রাখা। → hallucination ধরা পড়ে না।

ভুল ৫: একটাই metric-এ সব বিচার। → faithfulness + relevance + retrieval একসাথে দেখুন।

🎤 ১৪. Interview Prep

প্র: RAG system কীভাবে evaluate করবে?
উ: golden set-এ retrieval (recall@k) + generation (faithfulness, answer relevance) আলাদা মাপি; before/after তুলনা করি।

প্র: Faithfulness কী?
উ: উত্তরের claim গুলো কতটা retrieved context দিয়ে সমর্থিত — hallucination-এর উল্টো।

প্র: retrieval ভালো কিনা কীভাবে জানবে?
উ: labeled relevant chunk-এর বিপরীতে recall@k, precision@k, MRR।

প্র: LLM-as-judge-এর ঝুঁকি?
উ: bias ও ভুল করতে পারে; মানুষ দিয়ে spot-check ও অন্য metric-এর সাথে মিলিয়ে দেখা দরকার।

✍️ ১৫. হাতে-কলমে

আপনার RAG-এর জন্য ১০টা প্রশ্নের golden set বানান (২টা যেন "উত্তর নেই" ধরনের হয়)। প্রতিটার সঠিক chunk id চিহ্নিত করুন। evaluate() চালিয়ে baseline recall@5 বের করুন। তারপর chunk-size বদলে আবার চালান — recall বাড়ল না কমল, নোট করুন।

🚀 ১৬. Project Connection

flagship assistant-এ এখন একটা eval/ ফোল্ডার যোগ হলো — golden প্রশ্ন, recall script আর একটা before/after table। এটা P8-কে সত্যিকারের engineering project বানায়, এবং interview-তে "তুমি quality কীভাবে নিশ্চিত করলে?" প্রশ্নের শক্ত উত্তর দেয়। পরের episode-এ আমরা RAG থেকে সরে agents-এ যাব — যখন শুধু retrieve নয়, action নিতে হয়।

📌 ১৭. সারসংক্ষেপ ও পরবর্তী পর্ব

✓ যা মাপা যায় না, তা উন্নত করা যায় না
✓ retrieval ও generation আলাদা করে মাপুন
✓ মূল metric: faithfulness, answer relevance, context relevance
✓ retrieval metric: recall@k, precision@k, MRR
✓ golden dataset + ছোট harness = পুনরাবৃত্তিযোগ্য eval
✓ LLM-as-judge কাজের, কিন্তু verify করে ব্যবহার করুন

পরবর্তী Episode: "AI Agents" — RAG তথ্য এনে উত্তর দেয়, কিন্তু যদি assistant-কে হিসাব করতে, API কল করতে বা কয়েক ধাপ পরিকল্পনা করতে হয়? tools, function calling, memory আর agent বনাম workflow-এর পার্থক্য।

⬅ পূর্ববর্তী: RAG Quality পরবর্তী: AI Agents ➡