উদাহরণ দিয়ে শেখানো — Few-shot Prompting

১ · Few-shot Prompting আসলে কী?

আগের পাঠগুলোতে আমরা দেখেছি কীভাবে নির্দেশনা স্বচ্ছ করা যায় (পাঠ ০৩) এবং কারণ ব্যাখ্যা করা যায় (পাঠ ০৪)। কিন্তু কিছু কাজ আছে যেখানে শুধু কথায় বর্ণনা করার চেয়ে উদাহরণ দেখানো অনেক বেশি কার্যকর — বিশেষ করে যখন ফরম্যাট, টোন বা কাঠামো নির্দিষ্ট হওয়া দরকার। একে বলা হয় Few-shot PromptingFew-shot / Multishot Promptingনির্দেশনার সাথে একাধিক input/output উদাহরণ জুড়ে দেওয়া, যাতে মডেল উদাহরণ থেকে প্যাটার্নটা নিজে ধরে নিতে পারে — শুধু বর্ণনা পড়ে অনুমান না করে। বা multishot prompting।

OpenAI-এর নিজস্ব প্রম্পটিং গাইডে এটাকে বর্ণনা করা হয়েছে এভাবে — বৈচিত্র্যময় input/output উদাহরণ-জোড়া অন্তর্ভুক্ত করলে মডেল সেই প্যাটার্নটা implicitly ধরে নেয় এবং নতুন ইনপুটেও প্রয়োগ করে — এটা একটা মডেলকে নতুন করে fine-tune করার একটা হালকা, দ্রুত বিকল্প।

২ · ভালো উদাহরণের তিনটে মানদণ্ড

যেকোনো উদাহরণ দিলেই কাজ হয় না। Anthropic-এর গাইডলাইন অনুযায়ী কার্যকর উদাহরণ তিনটে গুণ পূরণ করে —

• প্রাসঙ্গিক (Relevant): উদাহরণগুলো আপনার আসল ব্যবহারের ক্ষেত্র (use case) প্রতিফলিত করে — একটা কোড-রিভিউ প্রম্পটের উদাহরণে রান্নার রেসিপি থাকলে চলবে না।
• বৈচিত্র্যময় (Diverse): উদাহরণগুলো বিভিন্ন এজ-কেস কভার করে এবং যথেষ্ট ভিন্ন — যাতে মডেল অনিচ্ছাকৃতভাবে ভুল প্যাটার্ন (যেমন সবসময় একই দৈর্ঘ্য বা একই ধরনের ইনপুট) শিখে না নেয়।
• সুগঠিত (Structured): প্রতিটা উদাহরণ স্পষ্টভাবে চিহ্নিত — সাধারণত <example> ট্যাগে মোড়ানো, একাধিক উদাহরণ থাকলে সবগুলো <examples>-এর ভেতরে।

কতগুলো উদাহরণ লাগবে? সাধারণত ৩ থেকে ৫টা উদাহরণই সবচেয়ে ভালো ফলাফল দেয় — এর কম হলে প্যাটার্ন স্পষ্ট নাও হতে পারে, আর অনেক বেশি হলে প্রম্পট অপ্রয়োজনীয়ভাবে লম্বা হয়ে যায় (মনে করুন পাঠ ০২-এর "ন্যূনতম প্রয়োজনীয় গঠন" নীতি)।

৩ · বাস্তব উদাহরণ — কাস্টমার সাপোর্ট টিকিট শ্রেণীবিভাগ

ধরুন আপনি একটা LLM ব্যবহার করে আসা কাস্টমার সাপোর্ট টিকিটগুলোকে স্বয়ংক্রিয়ভাবে শ্রেণীবিভাগ করতে চান — Billing, Technical, বা General। প্রথমে দেখি একটা zero-shot (উদাহরণ ছাড়া) প্রম্পট কেমন হয়।

❌ Zero-shot (উদাহরণ ছাড়া):

Classify the following customer support ticket into one category:
Billing, Technical, or General. Respond with only the category name.

Ticket: "I was charged twice for my subscription this month."

এটা এই একটা সহজ ক্ষেত্রে ঠিকঠাক কাজ করবে ("Billing" উত্তর আসবে)। কিন্তু বাস্তব টিকিট প্রায়ই একাধিক বিষয় মিশিয়ে ফেলে, বা ভিন্নভাবে শ্রেণীবিভাগ করা যেতে পারে এমন অস্পষ্ট ভাষা ব্যবহার করে — সেখানে zero-shot প্রম্পট অসামঞ্জস্যপূর্ণ সিদ্ধান্ত নিতে পারে, কারণ মডেলের কাছে ঠিক কোন যুক্তিতে শ্রেণীবিভাগ করতে হবে তার কোনো নমুনা নেই।

✅ Few-shot (উদাহরণ সহ):

Classify each customer support ticket into exactly one category:
Billing, Technical, or General. Respond with only the category name.

<examples>
<example>
Ticket: "I was charged twice for my subscription this month."
Category: Billing
</example>
<example>
Ticket: "The app crashes every time I try to upload a photo."
Category: Technical
</example>
<example>
Ticket: "I can't log in, and it also charged my card for a plan I
cancelled last week."
Category: Billing
</example>
<example>
Ticket: "What are your customer support hours?"
Category: General
</example>
</examples>

Ticket: "My export keeps failing halfway through with no error message."

লক্ষ্য করুন — তৃতীয় উদাহরণটা ইচ্ছাকৃতভাবে জটিল (লগইন সমস্যা + বিলিং সমস্যা একসাথে), এবং তার সমাধান "Billing" দেখানো হয়েছে কারণ আর্থিক চার্জই আসল অগ্রাধিকারের বিষয়। এই একটা উদাহরণই মডেলকে শেখায় কীভাবে মিশ্র টিকিটে অগ্রাধিকার ঠিক করতে হয় — এই তথ্যটা শুধু "নিয়ম" বলে বোঝানো কঠিন, কিন্তু একটা উদাহরণ দিয়ে তাৎক্ষণিকভাবে স্পষ্ট।

৪ · আরেকটা প্যাটার্ন — টেক্সট থেকে স্ট্রাকচার্ড ডেটা বের করা

Few-shot prompting শুধু শ্রেণীবিভাগেই সীমাবদ্ধ নয় — এটা টেক্সট থেকে গঠিত (structured) তথ্য বের করার ক্ষেত্রেও সমানভাবে কার্যকর। ধরুন আপনি প্রোডাক্ট রিভিউ থেকে একটা নির্দিষ্ট JSON ফরম্যাটে তথ্য বের করতে চান।

Extract the product name, sentiment (positive/negative/neutral), and
any mentioned defect from each review, formatted as JSON.

<examples>
<example>
Review: "The SoundMax headphones sound great, but the left earpiece
stopped working after two weeks."
Output: {"product": "SoundMax headphones", "sentiment": "negative",
"defect": "left earpiece stopped working"}
</example>
<example>
Review: "Love my new BrewFast kettle, boils water in under two minutes!"
Output: {"product": "BrewFast kettle", "sentiment": "positive",
"defect": null}
</example>
</examples>

Review: "The FitTrack band's screen is nice but the battery barely
lasts a day."

এখানে দুটো উদাহরণ একসাথে তিনটে জিনিস শিখিয়ে দিচ্ছে — আউটপুট JSON ফরম্যাটে থাকবে, কী-নামগুলো ঠিক কী হবে, এবং যখন কোনো ত্রুটি উল্লেখ নেই তখন defect-এর মান null হবে। এই তিনটে নিয়ম আলাদাভাবে গদ্যে লিখলে প্রম্পট অনেক লম্বা হয়ে যেত, এবং তবুও এতটা স্পষ্ট হতো না।