চূড়ান্ত প্রকল্প — প্রোডাকশন-মানের প্রম্পট অপ্টিমাইজেশন

০ · প্রকল্পের শুরু — মামুলি প্রম্পটটি

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

You are a customer support agent. Reply to the customer's complaint below.

Complaint: {{complaint_text}}

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

১ · স্বচ্ছতা ও সরাসরি ভাব (পাঠ ০৩)

প্রথম ধাপ সবসময় একই — পাঠ ০৩-এর "সোনালী নিয়ম" প্রয়োগ করুন। v0 প্রম্পটে "Reply to the complaint" নির্দেশটি অস্পষ্ট — কী টোনে, কত দীর্ঘ, কী কী অন্তর্ভুক্ত থাকা উচিত তার কিছুই বলা নেই। আমরা এখন স্পষ্ট, সরাসরি নির্দেশনা যোগ করি।

You are a customer support agent. Draft a reply to the customer's
complaint below. The reply must acknowledge the specific issue,
apologize sincerely, explain the next concrete step the company
will take, and end with a clear timeline. Keep it under 150 words.

Complaint: {{complaint_text}}

২ · প্রসঙ্গ ও কারণ যোগ করা (পাঠ ০৪)

শুধু নিয়ম বললে মডেল নিয়ম মানে, কিন্তু কেন ব্যাখ্যা করলে মডেল নতুন, অদেখা পরিস্থিতিতেও সঠিকভাবে সাধারণীকরণ করতে পারে (পাঠ ০৪-এর মূল ধারণা)। যেমন — শুধু "১৫০ শব্দের মধ্যে রাখো" না বলে, কেন এই সীমা দরকার তা বলুন।

...Keep it under 150 words, because this draft will be read and
possibly edited by a human agent on a tight schedule — a long
draft slows them down more than it helps. Never promise a refund
amount or a specific compensation, because only a senior agent is
authorized to approve those — your job is to draft an empathetic,
accurate response, not make binding commitments.

৩ · Few-shot উদাহরণ যোগ করা (পাঠ ০৫)

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

<examples>
<example>
Complaint: "My order arrived a week late and the box was crushed."
Reply: "I'm really sorry your order arrived late and damaged —
that's not the experience we want for you. I've flagged this
order for a replacement shipment, which should reach you within
3 business days. You'll get a tracking update by email within
the hour."
</example>
<example>
Complaint: "I was charged twice for the same order!"
Reply: "Thank you for flagging this — a duplicate charge is
completely understandable to be upset about. I've escalated
this to our billing team, who will review and reverse the extra
charge within 2 business days. You'll receive a confirmation
email once it's processed."
</example>
</examples>

৪ · XML ট্যাগ ও Markdown দিয়ে গঠন করা (পাঠ ০৬)

এখন পর্যন্ত প্রম্পটে নির্দেশনা, প্রসঙ্গ, উদাহরণ ও ভেরিয়েবল ইনপুট সব মিশে আছে। পাঠ ০৬-এর কৌশল অনুযায়ী, এগুলোকে স্পষ্ট XML ট্যাগে ভাগ করলে মডেল কোনটা নির্দেশনা আর কোনটা ইনপুট তা দ্ব্যর্থহীনভাবে বুঝতে পারে।

<instructions>
Draft a reply to the customer's complaint. Acknowledge the
specific issue, apologize sincerely, explain the next concrete
step, and end with a clear timeline. Keep it under 150 words...
</instructions>

<examples>...</examples>

<complaint>
{{complaint_text}}
</complaint>

৫ · হালকা সিস্টেম-প্রম্পট রোল (পাঠ ০৭)

পাঠ ০৭-এ আমরা দেখেছি — একটি সংক্ষিপ্ত, হালকা রোল ভালো কাজ করে, একটি অতিরিক্ত বিস্তারিত ব্যক্তিত্ব-বর্ণনার চেয়ে। তাই system prompt-এ শুধু এক বাক্যে ভূমিকা বেঁধে দিন, বাকি সব নির্দেশনা user/instructions অংশে রাখুন।

You are a customer support reply-drafting assistant for an
e-commerce company. Your drafts are reviewed by a human agent
before sending.

৬ · Thinking/reasoning প্রয়োজন কিনা সিদ্ধান্ত (পাঠ ০৮)

এই কাজ — একটি সহানুভূতিশীল, কাঠামোবদ্ধ উত্তর খসড়া করা — জটিল বহু-ধাপের যুক্তির কাজ নয়। পাঠ ০৮-এর নির্দেশনা অনুযায়ী, এখানে ধাপে-ধাপে-চিন্তা করার জন্য জোরালো নির্দেশনা (`<thinking>` ট্যাগ ইত্যাদি) প্রয়োজন নেই — এটি শুধু অপ্রয়োজনীয় টোকেন ও লেটেন্সি বাড়াবে। আমরা thinking effort কম/ডিফল্ট রাখার সিদ্ধান্ত নিই এবং এই ধাপে প্রম্পটে নতুন কিছু যোগ করি না — এটাই এই ধাপের সিদ্ধান্ত: কম চিন্তার প্রয়োজন, তাই কিছু যোগ না করাই সঠিক পদক্ষেপ।

৭ · আউটপুট ফরম্যাট নিয়ন্ত্রণ (পাঠ ০৯)

যেহেতু এই খসড়া একটি ইন্টারনাল টুলে দেখানো হবে (শুধু ইমেইল বডি নয়, বরং একটি রিভিউ প্যানেলে), স্ট্রাকচার্ড আউটপুট ব্যবহার করা ভালো — যাতে ফ্রন্টএন্ড নির্ভরযোগ্যভাবে প্রতিটি অংশ আলাদা করে দেখাতে পারে।

Respond with JSON matching this schema:
{
  "reply_draft": string,      // the full customer-facing reply
  "next_step": string,        // one-line internal summary of the action promised
  "confidence": "high" | "medium" | "low"
}

৮ · অনিশ্চয়তা প্রকাশের অনুমতি (পাঠ ১০)

প্রতিটি অভিযোগ স্পষ্ট হবে না — কখনো গ্রাহক ঠিক কী চান তা অস্পষ্ট থাকতে পারে। পাঠ ১০-এর কৌশল অনুযায়ী মডেলকে একটি নির্দিষ্ট "বের হওয়ার পথ" দিন, যাতে সে অনিশ্চিত পরিস্থিতিতে কিছু বানিয়ে না ফেলে।

If the complaint is ambiguous about what resolution the customer
wants, do not guess a specific compensation — instead set
"confidence": "low" and write a reply that asks one clarifying
question before promising a next step.

৯ · প্রোভাইডার-নির্দিষ্ট টিউনিং (পাঠ ১৪)

এখন পর্যন্ত আমরা একটি প্রোভাইডার-নিরপেক্ষ, প্রায়-সম্পূর্ণ প্রম্পট তৈরি করেছি। পাঠ ১৪-এর তুলনা অনুযায়ী, একই মূল প্রম্পট তিনটি প্রোভাইডারের জন্য সামান্য ভিন্নভাবে চূড়ান্ত করা উচিত।

System: You are a customer support reply-drafting assistant for
an e-commerce company. Your drafts are reviewed by a human agent
before sending.

<instructions>...</instructions>
<examples>...</examples>
<complaint>{{complaint_text}}</complaint>

Use the structured output schema provided. Verify your draft
against the instructions before finalizing.

Developer message:
# Identity
Customer support reply-drafting assistant for an e-commerce
company. Drafts are reviewed by a human agent before sending.

# Instructions
...(same rules)...

# Examples
...(same two examples)...

User message:
# Context
{{complaint_text}}

(Standard, non-reasoning model — instructions stay explicit and
logic-heavy rather than high-level, per পাঠ ১৪.)

System instruction: You are a customer support reply-drafting
assistant for an e-commerce company. Drafts are reviewed by a
human agent before sending. thinking_level: LOW — this task does
not need deep reasoning, respond directly and efficiently.

...(same instructions, examples, complaint, schema)...

লক্ষ্য করুন — মূল বিষয়বস্তু (নির্দেশনা, উদাহরণ, স্কিমা) তিনটিতেই প্রায় অভিন্ন; পার্থক্য শুধু কাঠামোগত সম্মেলন (developer/system বিভাজন) এবং thinking/effort নিয়ন্ত্রণের মতো প্রোভাইডার-নির্দিষ্ট প্যারামিটারে।

১০ · ক্যাশ-বান্ধব পুনর্বিন্যাস (পাঠ ১৬)

পাঠ ১৬-এর সার্বজনীন নিয়ম — স্ট্যাটিক (অপরিবর্তনীয়) কনটেন্ট শুরুতে, ভেরিয়েবল (প্রশ্ন-নির্দিষ্ট) কনটেন্ট শেষে। এই প্রম্পটে system prompt, instructions, ও examples প্রতিটি রিকোয়েস্টে অভিন্ন থাকে — শুধু `{{complaint_text}}` বদলায়। তাই আমরা নিশ্চিত করি এই ক্রম মেনে চলা হচ্ছে (system → instructions → examples → schema → complaint) — ঠিক এটাই আমরা ইতিমধ্যে ধাপ ৯-এ করেছি, কিন্তু এখানে সচেতনভাবে যাচাই করছি যে ভেরিয়েবল অংশ (`{{complaint_text}}`) একদম শেষে আছে, যাতে প্রতিটি নতুন রিকোয়েস্টে স্ট্যাটিক prefix ক্যাশ থেকে পুনরায় ব্যবহার করা যায়।

১১ · লিন প্রম্পটিং — অপ্রয়োজনীয় অংশ ছেঁটে ফেলা (পাঠ ১৭)

পাঠ ১৭-এর নীতি — প্রতিটি নির্দেশনা ঠিক একবার বলুন, পুনরাবৃত্তি এড়ান। এই প্রম্পটে খেয়াল করলে দেখা যায় "acknowledge the specific issue" এবং উদাহরণগুলোতে একই ধারণা দুইবার বলা হয়েছে (একবার নির্দেশনায়, একবার প্রসঙ্গ-ব্যাখ্যায়)। আমরা পুনরাবৃত্ত বাক্য ছেঁটে ফেলি এবং শুধু একটি জায়গায় প্রতিটি নিয়ম রাখি।

❌ আগে (পুনরাবৃত্তি):
"Acknowledge the specific issue. Apologize sincerely for the
issue. Make sure you address what went wrong specifically..."

✅ পরে (লিন):
"Acknowledge the specific issue and apologize sincerely."

১২ · উপযুক্ত মডেল ও effort/thinking_level বাছাই (পাঠ ১৮)

পাঠ ১৮-এর নির্দেশনা অনুযায়ী — এই কাজটি (একটি টেমপ্লেট-সদৃশ, মাঝারি-জটিলতার লেখা কাজ, যার প্রতিটি আউটপুট একজন মানুষ যাচাই করবেন) একটি ছোট/মাঝারি, দ্রুত মডেলের জন্য যথেষ্ট — একটি ফ্ল্যাগশিপ, সর্বোচ্চ-ক্ষমতার মডেল এখানে অপ্রয়োজনীয় খরচ। একইভাবে thinking effort/thinking_level কম বা ডিফল্ট রাখাই যথেষ্ট, যেহেতু ধাপ ৬-এ আমরা ইতিমধ্যে সিদ্ধান্ত নিয়েছি এই কাজে গভীর reasoning দরকার নেই।