Module 2 · Day 4

Prompts as Engineering Artifacts

Module 1-এ শিখেছো LLM ভেতরে কী করে। আজ থেকে Module 2 — এখন শিখবে prompt আসলে কী: magic spell না, engineering artifact। Version করা যায়, test করা যায়, মাপা যায়, iterate করা যায়। রাফির complaint-categorizer দিয়ে পুরো flow — success criteria থেকে eval পর্যন্ত।

~120 min read5 learning objectives

What you'll learn

•একটা বাক্য মুখস্থ বলতে পারা: “একটা prompt হলো software — version করা যায়, test করা যায়, মাপা যায়, iterate করা যায়।” এই mental shift-টাই Module 2-এর gateway।
•prompt engineering-এর canonical ৫-ধাপ flowchart মনে রাখা: success criteria → test cases → preliminary prompt → iterate with measurement → ship।
•Grading-এর ৩টা tier আলাদা করতে পারা — code-based, human, LLM-based — আর তার নিচে ৪টা assertion type (equals, contains, regex, llm-rubric) কখন কোনটা।
•“Vibes-based iteration” vs “eval-based iteration”-এর পার্থক্য নিজের ভাষায় বলা — কেন প্রথমটায় regression লুকিয়ে থাকে।
•Day 4-এর English vocabulary মুখে আসা — success criteria, baseline, regression, eval, assertion, rubric, pass rate, edge case — যাতে team meeting আর PR review-এ confident-ভাবে বলতে পারো।

Before this

•Module 1 শেষ (Day 1–3) — token, embedding, attention-এর basic মাথায় আছে।
•ChatGPT বা Claude-এ অন্তত কয়েকবার prompt পাঠানোর অভিজ্ঞতা।
•আজ কোনো code লিখব না — কিন্তু একটা YAML eval config পড়ব। Coding background না থাকলেও চলবে।

The Big Picture

একটা prompt কীভাবে production-এ পৌঁছায় — একটা standard ৫-ধাপ loop দিয়ে শুরু।

Module 1-এর রাফিকে মনে আছে? একটা logistics কোম্পানির junior dev, যাকে ৩০০টা customer complaint category করতে বলা হয়েছিল। এবার ধরো রাফি একটা prompt লিখে ফেলেছে — ৩টা complaint-এ চালিয়ে দেখল, ঠিকঠাক লাগছে। Boss জিজ্ঞেস করল, “কতটা ভালো, আসলে?” রাফির কাছে কোনো সংখ্যা নেই — শুধু “ভালো লাগছে” একটা feeling। এই ফাঁকটাই আজকের lesson। আজ থেকে prompt লেখা মানে শুধু ভালো লেখা না — measure করে লেখা।

Prompts as softwarethe mental shift

Prompt কোনো magic spell না — engineering artifact। যেকোনো function-এর মতোই: version-এ থাকে, একটা কাজ আছে, test থাকে (eval), measurement-এর সাথে iterate হয়, PR-এ review হয়, production-এ ship হয়। আজকের পর থেকে “একবার লিখে ছেড়ে দিলাম” attitude বন্ধ। প্রতিটা serious prompt একটা ছোট module — যার নিজের lifecycle আছে।

Why it matters

Module 2-এর বাকি সব এই shift-এর ফল। Prompt structure, few-shot, structured output, CoT, eval harness — সব ধরে নেয় তুমি prompt-কে software ভাবছ। এটা না বুঝলে সামনের প্রতিটা lesson বিচ্ছিন্ন trick মনে হবে। ২০২৬-এ এটা আর metaphor না — “promptware engineering” রীতিমতো একটা গবেষণার নাম।

prompt engineering best-practice-এ একটা canonical ৫-ধাপ loop আছে — success criteria থেকে শুরু করে ship পর্যন্ত। নিচে এক এক ধাপ চেপে দেখো।

Interactive · prompt iteration flowchart

Prompt engineering loop — ৫ ধাপ

এই ৫টা box-ই canonical workflow — প্রতিটা serious prompt এই loop পেরিয়ে production-এ যায়। এক এক ধাপ চেপে দেখো — কোন order-এ কী হয়।

1Define success criteria
“Done” মানে কী — সেটা মেপে বলো। রাফির ক্ষেত্রে: ৩০০টা complaint-এর অন্তত ৮৫%-এ সঠিক category — এটাই pass। Vague হলে test বানানোই যায় না।
SMART: Specific, Measurable, Achievable, Relevant.
2Build test cases
১০–২০টা complaint + তাদের সঠিক label হাতে সাজাও। Typical + edge (sarcasm, খালি input) মিশিয়ে। এই set-ই তোমার ground truth — প্রতিটা future prompt change এর বিরুদ্ধে মাপা হবে।
10–20 cases. Mix typical + edge + adversarial.
3Write preliminary prompt
প্রথম reasonable চেষ্টা — এটাই তোমার baseline। কত % test pass হলো, সেটাই floor। সবকিছু এর থেকে মাপা শুরু।
v1 = baseline pass rate (e.g. 58%).
4Iterate with measurement
Fail-গুলো খোলো → prompt edit করো → আবার eval চালাও → নতুন pass rate লিখে রাখো। বাড়লে রাখো, কমলে revert। চোখে না — সংখ্যায় decide করো।
v2: 61%. v3: 86%. v4: 80% (revert). v5: 93%.
5Final validation + ship
Criteria পূরণ হলো? Edge case pass করলো? যে test cases দিয়ে iterate করোনি, সেই held-out set-এ আবার চালিয়ে confirm করো। তারপর version tag + deploy = ship।
Criteria met + held-out check = ship.

Step 4 loop: success criteria পূরণ না হওয়া পর্যন্ত iterate। সাধারণত ৩-১০ rounds-এ ship-ready হয়।

এই ৫টা box-এর প্রতিটার ভেতরে আরও কিছু concept আছে — success criteria আসলে কেমন দেখতে, test case কী দিয়ে বানে, edge case কেন জরুরি। পরের অংশে এক এক করে।

Core Concepts

Success criteria থেকে regression পর্যন্ত — prompt-কে software বানানোর ৭টা ধারণা।

Success criteria“done”-এর definition

Prompt লেখা শুরুর আগেই — “কাজ শেষ” মানে কী, সেটা মেপে লেখা। SMART: Specific (“accurate complaint categorization”), Measurable (৮৫%+ সঠিক label), Achievable (frontier model-এ বাস্তব), Relevant (তোমার আসল use case)। “Bot ভালো কাজ করবে” — too vague। “৩০০টা complaint-এর ৮৫%-এ সঠিক category” — কাজের। প্রায়ই একসাথে কয়েকটা মাত্রা লাগে — accuracy + latency + cost।

Why it matters

Vague criteria মানে vague evaluation মানে “vibes-এ ship করা।” যেসব AI product fail করে, তাদের প্রায় সবার এক মূল কারণ — robust evaluation system বানাতে না পারা। Criteria-ই সেই system-এর প্রথম ইট।

Test caseinput + expected output

একটা নির্দিষ্ট input + সেই input-এ যা output হওয়া উচিত। ১০–২০টা test case-এর একটা set = তোমার ground truth। Mix থাকা চাই — typical input (বেশিরভাগ user), edge case (কম আসে কিন্তু জরুরি), adversarial input (sarcasm, typo, খালি, খুব লম্বা)। YAML-জাতীয় eval tool এই test-গুলো এভাবেই লেখে।

Why it matters

canonical flowchart-টা test cases দিয়ে শুরু — preliminary prompt-এরও আগে। কারণ test না থাকলে prompt edit-এর কোনো feedback signal নেই — শুধু feeling। আর একটা মজার নিয়ম: “prioritize volume over quality” — ৫টা নিখুঁত hand-graded test-এর চেয়ে ২০টা rough automated test ভালো signal দেয়।

Test case লেখা হলে পরের প্রশ্ন — pass/fail কীভাবে ঠিক হবে? Grading-কে তিন tier-এ ভাগ করা যায় — code-based, human, LLM-based — fastest থেকে সবচেয়ে scalable পর্যন্ত order-এ। নিচের ৪টা assertion type ওই tier-এর ভেতরেই পড়ে। একটা ট্যাব বেছে দেখো — concrete example + কখন এটা সেরা choice।

Interactive · The 4 assertion types

কোন assertion কখন ব্যবহার করবে?

Grading-কে তিন tier-এ সাজানো যায়, “fastest, most reliable, most scalable” order-এ: code-based → human → LLM-based। নিচের ৪টা assertion ওই tier-এর ভেতরে পড়ে। একটা ট্যাব select করো — concrete example + কখন এটা সেরা choice, দেখাব।

equalsExact matchCode-based tier

Model-এর output হুবহু একটা known label-এর সাথে মিলতে হবে (case + space normalize করার পর)। সবচেয়ে strict, সবচেয়ে fast। Categorical answer-এর জন্য perfect।

When to use:Classification — output শুধু কয়েকটা নির্দিষ্ট label-এর একটা হওয়ার কথা।

Concrete example

Input:“অর্ডার ৩ দিন ধরে আসছে না”

Expected:delivery_delay

Assertion:type: equals, value: "delivery_delay"

What happens:

Output “delivery_delay” হলে pass। “Late delivery” — fail। “delivery delay” (underscore নাই) — fail। তাই strict prompt লাগে যেন model হুবহু label দেয়।

সোজা নিয়ম: সস্তাটা (equals/contains/regex) আগে try করো। না খাটলে তখন llm-rubric। Cost + speed-এর order: equals < contains < regex << llm-rubric।

Edge casethe rare but critical input

অস্বাভাবিক input যেটা production-এ আসবেই — খালি input, খুব লম্বা input, sarcastic tone, অন্য ভাষা, typo, “আসলে complaint-ই না” এমন message। Test set-এ এগুলো না থাকলে ৮০% pass দেখে “done” বলে ফেলবে — কিন্তু production-এ exactly এই ২০%-ই ভাঙবে। Edge case-গুলো বরং বেশি করে রাখো।

Why it matters

বেশিরভাগ prompt failure কোনো exotic জিনিসে না — boring edge case-এ। রাফির bot-এর সবচেয়ে বড় ফাঁদ “বাহ, দারুণ সার্ভিস!” — একটা sarcastic complaint, যেটা আসলে delivery_delay।

Baselinethe starting floor

প্রথম reasonable prompt-এর pass rate। সাধারণত ৫০–৭০%-এ থাকে। এটাই তোমার measurement floor — সব future change এই number-এর সাথে compare হবে। “v2-তে ৬১% থেকে ৮৬% হলো — improvement।” Baseline ছাড়া এই বাক্যটাই বলা যায় না।

Why it matters

Baseline না থাকলে team meeting-এ “আমি prompt improve করেছি” — এই দাবির পেছনে কোনো proof নেই। Pass rate before/after = যেকোনো AI team-এ PR review-এর standard মুদ্রা।

Regressionthe hidden danger

এমন change যেটা আগে-pass করা test fail করিয়ে দেয় — অর্থাৎ improvement ভেবে আসলে বিগড়ে দিলে। Eval ছাড়া regression অদৃশ্য — কারণ “কিছু একটা output” তো এসেছেই। Eval থাকলে report-এ লাল — “v4: pass rate ৮৬% → ৮০%” — তখন revert।

Why it matters

Software engineering-এর regression-এর মতোই। যেমন কোনো PR test fail করালে block হয় — তেমন prompt change eval fail করালে ship হবে না। “Prompts as software” বাস্তবে এটাই মানে।

Vibes vs evalsthe trap to avoid

“Vibes” — output পড়ে চোখে ভালো/খারাপ লাগা। “Evals” — মাপা pass rate, সংখ্যা। ফাঁদ: ছোট ছোট prompt change-এ vibes confidence দেয়, কিন্তু সংখ্যা উল্টোদিকে যায়। এই lesson-এর একটা round exactly তাই — চোখে “cleaner”, কিন্তু eval-এ pass rate নিচে। বড় scale-এ চোখ মিথ্যা বলে; সংখ্যা বলে না।

Why it matters

AI engineer হিসেবে তোমার সবচেয়ে দামি অভ্যাস এটাই — চোখে রায় দেওয়ার আগে eval চালাও। একবার শিখলে আর পেছনে ফিরবে না।

Versioning promptsgit for prompts

Prompt-গুলো `.txt`, `.md`, বা `.yaml` ফাইলে রেখে codebase-এর সাথে commit করা। তখন diff দেখা যায়, branch করা যায়, PR-এ review হয়, tag-এ release হয়। বাস্তব উদাহরণ — editor-জুড়ে চেনা project-instruction ফাইলের standard (যেমন `.cursorrules`, `AGENTS.md`)। ২০২৬-এর teams prompt-এর জন্যও dev/staging/prod environment রাখে — staging-এ eval pass করলে তবে prod-এ promote।

Why it matters

তিন সপ্তাহ পরের তুমি মনে রাখবে না কোন version-এ best pass rate ছিল। Git মনে রাখে। আর team-এর বাকিরা কী try করেছে — সেটাও history-তে দেখা যায়।

Try It Yourself

পড়া বন্ধ — রাফির complaint-categorizer দিয়ে নিজে eval পড়ো আর চালাও।

রাফির আসল data দিয়ে এবার হাতে-কলমে দেখা যাক — একটা real eval config কেমন দেখতে, আর দুটো prompt version পাশাপাশি চালালে সংখ্যা কী বলে।

Interactive · Eval config (YAML-style)

একটা real eval config — tap করে দেখো

এই config-টাই production team-এ একটা eval-এর চেহারা — ১টা prompt template + কয়েকটা test case + প্রতি test-এর assertion। নিচের ৫টা chip-এর একটা tap করো — YAML-এ matching অংশ highlight হবে, আর তার মানে ডানপাশে দেখাবে।

# eval.yaml — prompt + tests + assertions
prompt: |
  Categorize the customer complaint into exactly one of:
  delivery_delay, wrong_item, damaged, billing, other.
  Output only the label.
  
  Complaint: {{complaint}}
  Category:

tests:
  - vars: { complaint: "অর্ডার দিয়েছিলাম সোমবার, আজ বৃহস্পতিবার — এখনো হাতে পাইনি।" }
    assert: [{ type: equals, value: "delivery_delay" }]  # typical
  - vars: { complaint: "জুতা অর্ডার করেছিলাম, বক্সে এসেছে একটা বেল্ট।" }
    assert: [{ type: equals, value: "wrong_item" }]  # typical
  - vars: { complaint: "ফোনটা এসেছে কিন্তু স্ক্রিনে বড় ফাটল।" }
    assert: [{ type: equals, value: "damaged" }]  # typical
  - vars: { complaint: "ডেলিভারি হয়নি, অথচ bKash থেকে টাকা কেটে নিয়েছে।" }
    assert: [{ type: equals, value: "billing" }]  # edge — mixed signal
  - vars: { complaint: "বাহ, এক সপ্তাহ পরে ডেলিভারি — কী দারুণ সার্ভিস!" }
    assert: [{ type: equals, value: "delivery_delay" }]  # edge — sarcasm
  - vars: { complaint: "তোমাদের কাস্টমার কেয়ার নম্বরটা একটু দেবে?" }
    assert: [{ type: equals, value: "other" }]  # edge — not a complaint

What is this?

উপরের ৫টা chip-এর একটা tap করো — এখানে তার মানে আসবে।

খেয়াল করো: এটা একটা code file। Git-এ commit হয়, PR-এ diff হয়, CI-তে auto-run হয়। Prompt আর code-এর সীমানাটা মিলিয়ে গেছে।

Interactive · Live eval run

Run চেপে দেখো — v1 vs v2 প্রম্পট

রাফির ৬টা complaint-এ দুটো prompt চালিয়ে দেখো। উপরে v1/v2 switch করো, তারপর Run চাপো। প্রতিটা case-এর equals assertion এক এক করে pass/fail হবে। Complaint বাংলায়, label English — prompt-টাই English।

Categorize this complaint: {{complaint}}

“অর্ডার দিয়েছিলাম সোমবার, আজ বৃহস্পতিবার — এখনো পাইনি।”

typical · expected: delivery_delay

—

“জুতা অর্ডার করেছিলাম, বক্সে এসেছে একটা বেল্ট।”

typical · expected: wrong_item

—

“ফোনটা এসেছে কিন্তু স্ক্রিনে বড় ফাটল।”

typical · expected: damaged

—

“ডেলিভারি হয়নি, অথচ bKash থেকে টাকা কেটে নিয়েছে।”

edge — mixed signal · expected: billing

—

“বাহ, এক সপ্তাহ পরে ডেলিভারি — কী দারুণ সার্ভিস!”

edge — sarcasm · expected: delivery_delay

—

“তোমাদের কাস্টমার কেয়ার নম্বরটা একটু দেবে?”

edge — not a complaint · expected: other

—

Pass rate · prompt v1

Run চাপলে শুরু হবে।

—%

উপরের run-টা ছিল দুটো prompt version-এর এক-দফা তুলনা। রাফির আসল iteration ৫ round গিয়েছিল — প্রতি round-এ vibes আর eval কী বলেছিল, পাশাপাশি দেখো।

Interactive · Vibes vs evals

৫ rounds — কোন কোন change actually ভালো ছিল?

রাফির complaint-categorizer prompt ৫ বার iterate হলো। Vibes দিয়ে judge করলে কী মনে হয়, আর eval-এ আসল pass rate কী — পাশাপাশি দেখো। কখনো vibes ঠিক, কখনো ভুল। ওটাই trap।

Version

Vibes (gut feel)

Eval (numbers)

সঙ্গে নিয়ে যাও: pass rate before/after বলো, “feels better” বলো না।

Check Your Understanding

ভুল হলে সমস্যা নেই — প্রতিটার ব্যাখ্যা আছে।

Misconception check

আগে prompt লিখি, সময় থাকলে পরে test যোগ করব

Misconception check

Eval শুধু production-এর জন্য, আমি তো এখন experiment করছি

Misconception check

Playground-এ আমার prompt দারুণ লাগছে — done

Misconception check

Claude-কেই জিজ্ঞেস করি আমার prompt ভালো কিনা

Misconception check

LLM-as-judge reliable না — এড়িয়ে চলব

Misconception check

ছোট project-এ prompt version control overkill

Misconception check

৮০% pass rate মানে prompt done

Quick check