প্রসঙ্গ ও কারণ যোগ করা

১ · একটা নিয়ম, একটা কারণ

ধরুন আপনি একটা LLM-কে বলছেন এমন টেক্সট লিখতে যা পরে টেক্সট-টু-স্পিচ (Text-to-Speech) ইঞ্জিন দিয়ে জোরে পড়ে শোনানো হবে। আপনি জানেন যে এই টেক্সটে ... (ellipsis) থাকলে সমস্যা হবে, কারণ TTS ইঞ্জিন এটা ঠিকভাবে উচ্চারণ করতে পারে না। এটা বলার দুটো উপায় আছে — এবং দুটোর ফলাফল আলাদা।

❌ কম কার্যকর (Less effective):

NEVER use ellipses.

✅ বেশি কার্যকর (More effective):

Your response will be read aloud by a text-to-speech engine, so never use
ellipses since the text-to-speech engine will not know how to pronounce
them.

প্রথম নজরে দুটো নির্দেশনাই একই ফলাফল দেবে বলে মনে হতে পারে — দুটোতেই লেখা আছে ellipsis ব্যবহার না করতে। কিন্তু Anthropic-এর প্রম্পটিং গাইড অনুযায়ী, দ্বিতীয় সংস্করণ বাস্তবে অনেক বেশি নির্ভরযোগ্য — কারণ এটা মডেলকে শুধু একটা নিয়ম দেয়নি, একটা বোঝাপড়া দিয়েছে।

২ · কেন শুধু-নিয়ম নির্দেশনা ভঙ্গুর

"NEVER use ellipses" — এই বাক্যটা একটামাত্র সুনির্দিষ্ট নিয়ম বর্ণনা করে, যার পেছনে কোনো ব্যাখ্যা নেই। মডেল এই নিয়মটা মেনে চলবে, কিন্তু এর পেছনের উদ্দেশ্য না জানার কারণে, এর সাথে সম্পর্কিত কিন্তু ঠিক একই রকম নয় এমন পরিস্থিতিতে মডেল ভুল করতে পারে। যেমন —

• মডেল হয়তো ellipsis এড়িয়ে যাবে, কিন্তু em-dash (—) বা অন্য কোনো চিহ্ন ব্যবহার করবে যা TTS ইঞ্জিনের জন্য একই রকম সমস্যা তৈরি করে — কারণ নিয়মে শুধু ellipsis-এর কথা বলা ছিল।
• মডেল হয়তো সংখ্যাসূচক তালিকায় বা কোড ব্লকে ellipsis ব্যবহার করে ফেলবে, ভেবে নেবে যে নিয়মটা শুধু সাধারণ বাক্যের জন্য প্রযোজ্য।

অর্থাৎ, শুধু-নিয়ম নির্দেশনা ঠিক সেই একটা কেসকেই কভার করে যা স্পষ্টভাবে লেখা আছে — এর বাইরে যেকোনো কাছাকাছি পরিস্থিতিতে মডেলকে নতুন করে অনুমান করতে হয়, ঠিক যেমনটা পাঠ ০১-এ আমরা দেখেছি খালি জায়গায় মডেল নিজের মতো পূরণ করে।

৩ · কেন কারণ-সহ নির্দেশনা সাধারণীকরণযোগ্য

দ্বিতীয় সংস্করণে — "your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them" — মডেলকে দেওয়া হয়েছে আসল কারণ: টেক্সট পড়ে শোনানো হবে, এবং TTS ইঞ্জিন কিছু চিহ্ন উচ্চারণ করতে পারে না।

এখন মডেল আর শুধু একটা নিয়ম অনুসরণ করছে না — এটা একটা উদ্দেশ্য বুঝে কাজ করছে। ফলে মডেল স্বাভাবিকভাবেই এই একই যুক্তি প্রয়োগ করবে অন্য পরিস্থিতিতেও — em-dash, বা অন্য কোনো উচ্চারণ-অসুবিধাজনক চিহ্ন এড়িয়ে চলবে, কারণ এগুলোও একই সমস্যায় ফেলবে। Anthropic-এর ভাষায়, Claude যথেষ্ট বুদ্ধিমান যে ব্যাখ্যা থেকে সাধারণীকরণ করতে পারে ("Claude is smart enough to generalize from the explanation")।

৪ · আরও একটা উদাহরণ — গ্রাহক-সেবা প্রম্পট

একই নীতি অন্য একটা বাস্তব পরিস্থিতিতে দেখা যাক — একটা কাস্টমার-সাপোর্ট চ্যাটবটের সিস্টেম প্রম্পট।

❌ কম কার্যকর (Less effective):

Never promise a refund date to the customer.

✅ বেশি কার্যকর (More effective):

Never promise a specific refund date to the customer, because refund
processing depends on the payment provider and our team cannot guarantee
timelines — an incorrect promise damages trust when it's not met.

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

৫ · কখন কারণ ব্যাখ্যা করা মূল্যবান

এর মানে এই নয় যে প্রতিটা নির্দেশনার সাথে একটা রচনা লিখে দিতে হবে। কারণ ব্যাখ্যা করা সবচেয়ে মূল্যবান যখন —

• নিয়মটা সম্ভাব্য একাধিক পরিস্থিতিতে প্রযোজ্য — যেমন উপরের উদাহরণে "প্রতিশ্রুতি না দেওয়া" শুধু রিফান্ডে নয়, যেকোনো অনিশ্চিত বিষয়ে প্রযোজ্য।
• নিয়মটা প্রথম দেখায় অস্বাভাবিক বা প্রতি-স্বজ্ঞাত মনে হতে পারে — কেন এই নিয়ম, সেটা না জানলে মডেল ভুল বুঝে পুরো প্রম্পটের অন্য অংশের সাথে সামঞ্জস্যহীন সিদ্ধান্ত নিতে পারে।
• আপনি প্রতিটা সম্ভাব্য এজ-কেস আগে থেকে তালিকা করতে পারবেন না — একটা ভালো ব্যাখ্যা একবারে অনেক না-লেখা এজ-কেস কভার করে দেয়।

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