পাঠ ০৬ · ২৮-এর মধ্যে
Home / AI Courses / প্রম্পট ইঞ্জিনিয়ারিং / প্রম্পট গঠন করা

প্রম্পট গঠন করা — XML ট্যাগ ও Markdown সেকশন

Structuring prompts — XML tags & Markdown
১০ মিনিট পড়া মধ্যম · Intermediate কোনো প্রস্তুতি দরকার নেই সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • Anthropic-এর XML ট্যাগ পদ্ধতি — সামঞ্জস্যপূর্ণ ট্যাগ-নাম ও nesting দিয়ে হায়ারার্কি তৈরি
  • OpenAI-এর Markdown-হেডার সেকশন পদ্ধতি — Identity/Instructions/Examples/Context
  • একই প্রম্পট দুই ভিন্ন idiom-এ পাশাপাশি — মিল ও পার্থক্য বোঝা
  • কখন গঠন সত্যিই দরকার, কখন এটা অপ্রয়োজনীয় ওভারহেড

১ · কেন জটিল প্রম্পটে গঠন প্রয়োজন হয়

পাঠ ০৫-এ আমরা few-shot উদাহরণে <example> ট্যাগ ব্যবহার করেছি — এটাই আসলে একটা বড় ধারণার একটা ছোট প্রয়োগ। যখন একটা প্রম্পটে একসাথে অনেক কিছু থাকে — নির্দেশনা, পটভূমির তথ্য, উদাহরণ, এবং ব্যবহারকারীর দেওয়া ভেরিয়েবল ইনপুট — তখন এগুলো একটানা গদ্যে লিখলে মডেলের জন্য (এবং মানুষের জন্যও) বোঝা কঠিন হয়ে যায় কোন অংশ ঠিক কী ভূমিকা পালন করছে।

এখানেই প্রম্পট স্ট্রাকচারিং (Prompt Structuring)Prompt Structuringএকটা প্রম্পটের বিভিন্ন অংশ (নির্দেশনা, প্রসঙ্গ, উদাহরণ, ইনপুট) স্পষ্টভাবে চিহ্নিত সীমানা দিয়ে আলাদা করার কৌশল, যাতে মডেল প্রতিটা অংশের ভূমিকা দ্ব্যর্থহীনভাবে বুঝতে পারে। কাজে আসে। Anthropic ও OpenAI দুটো ভিন্ন কিন্তু একই লক্ষ্যের idiom ব্যবহার করে — যথাক্রমে XML ট্যাগ ও Markdown হেডার।

২ · Anthropic-এর পদ্ধতি — XML ট্যাগ

Claude-এর প্রম্পটিং গাইডে সুপারিশ করা হয় সামঞ্জস্যপূর্ণ, বর্ণনামূলক ট্যাগ-নাম ব্যবহার করতে — যেমন <instructions>, <context>, <input> — এবং প্রয়োজনে এই ট্যাগগুলো নেস্ট (nest) করে স্বাভাবিক হায়ারার্কি তৈরি করতে। একাধিক ডকুমেন্ট থাকলে, প্রতিটাকে আলাদা <document> ট্যাগে index অ্যাট্রিবিউট সহ মোড়ানো হয় — <documents><document index="1">...</document></documents>।

Claude-style · XML tags
<instructions>
You are a support ticket triager. Read the customer message inside
<input> and assign it to exactly one team using the categories
described in <context>. Follow the pattern shown in <examples>.
</instructions>

<context>
Our teams are: Billing (payments, refunds, subscriptions), Technical
(bugs, crashes, errors), General (everything else, including
pre-sales questions).
</context>

<examples>
<example>
<input>I was charged twice this month.</input>
<output>Billing</output>
</example>
<example>
<input>The app crashes when I upload a photo.</input>
<output>Technical</output>
</example>
</examples>

<input>
Does your Pro plan include API access?
</input>

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

৩ · OpenAI-এর পদ্ধতি — Markdown হেডার সেকশন

OpenAI-এর প্রম্পটিং গাইড একটা কাঠামোগতভাবে কাছাকাছি কিন্তু ভিন্ন idiom সুপারিশ করে — প্রম্পটকে আলাদা, নামযুক্ত Markdown সেকশনে ভাগ করা: Identity (উদ্দেশ্য ও স্টাইল), Instructions (নিয়ম), Examples (input/output জোড়া), এবং Context (প্রাসঙ্গিক ডেটা)। প্রয়োজনে একটা সেকশনের ভেতরে কোনো নির্দিষ্ট কনটেন্টের সীমানা চিহ্নিত করতে XML ট্যাগও ব্যবহার করা যায় — দুটো পদ্ধতি পারস্পরিক exclusive নয়।

OpenAI-style · Markdown sections
# Identity
You are a support ticket triager for a SaaS product.

# Instructions
- Read the customer message under "Input".
- Assign it to exactly one team: Billing, Technical, or General.
- Respond with only the team name.

# Examples
Input: "I was charged twice this month."
Output: Billing

Input: "The app crashes when I upload a photo."
Output: Technical

# Context
Billing = payments, refunds, subscriptions.
Technical = bugs, crashes, errors.
General = everything else, including pre-sales questions.

# Input
Does your Pro plan include API access?

লক্ষ্য করুন — দুটো সংস্করণেই ঠিক একই চারটে উপাদান আছে (পরিচয়/নির্দেশনা, পটভূমি, উদাহরণ, ইনপুট), শুধু সীমানা চিহ্নিত করার idiom আলাদা। Claude-স্টাইলে কোণ বন্ধনী (angle brackets) দিয়ে সীমানা, OpenAI-স্টাইলে হেডার ও হাইফেন-বুলেট দিয়ে সীমানা। দুটোই একই সমস্যার সমাধান করছে — মডেলের জন্য অংশগুলো দ্ব্যর্থহীন করে তোলা।

ব্যবহারিক পরামর্শ — আপনি যদি মূলত Claude API ব্যবহার করেন, XML ট্যাগ idiom-টা বেছে নিন, কারণ Claude এই ফরম্যাটে বিশেষভাবে প্রশিক্ষিত। GPT মডেলে কাজ করলে Markdown-হেডার idiom স্বাভাবিকভাবেই ভালো ফল দেয়। তবে দুটো পদ্ধতিই উভয় প্রোভাইডারের মডেলেই মোটামুটি কাজ করে — এটা কঠোর নিয়ম নয়, বরং প্রতিটা প্রোভাইডারের নিজস্ব ডকুমেন্টেশনে যে idiom-এ বেশি উদাহরণ দেখানো হয়েছে, সেটাই অনুসরণ করা।

৪ · সততার সাথে বলা দরকার — এটা একটা বিবর্তনশীল ক্ষেত্র

এই বিষয়ে একটা সূক্ষ্ম কিন্তু গুরুত্বপূর্ণ আপডেট আছে। Anthropic-এর নিজস্ব ২০২৬ সালের ব্লগ পোস্টে বলা হয়েছে — আধুনিক Claude মডেলে, ছোট ও সহজ প্রম্পটের ক্ষেত্রে XML ট্যাগ আগের চেয়ে "কম প্রয়োজনীয়" হয়ে উঠেছে। মডেল এখন স্বাভাবিক গদ্য থেকেও নির্দেশনা ও প্রসঙ্গ যথেষ্ট ভালোভাবে আলাদা করতে পারে, বিশেষ করে যখন প্রম্পটে মাত্র একটা বা দুটো উপাদান থাকে।

কিন্তু এই একই গাইডলাইন স্পষ্ট করে বলে — জটিল, বহু-অংশের প্রম্পটে (নির্দেশনা + প্রসঙ্গ + উদাহরণ + ভেরিয়েবল ইনপুট একসাথে মিশ্রিত) XML ট্যাগ এখনো সুপারিশকৃত, কারণ জটিলতা বাড়ার সাথে সাথে দ্ব্যর্থতার ঝুঁকিও বাড়ে।

এই কোর্সের নির্দেশনা · Practical rule

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

৫ · কীভাবে সিদ্ধান্ত নেবেন — গঠন দরকার কিনা

নিজেকে জিজ্ঞেস করুন — এই প্রম্পটে কি একসাথে একাধিক ভিন্ন ধরনের উপাদান আছে (নিয়ম, পটভূমি তথ্য, উদাহরণ, পরিবর্তনশীল ইনপুট)? যদি উত্তর হ্যাঁ হয়, তাহলে গঠন যোগ করলে দ্ব্যর্থতা কমবে ও ফলাফল বেশি নির্ভরযোগ্য হবে। যদি প্রম্পটটা একটা সহজ, একরৈখিক অনুরোধ হয়, গঠন ছাড়াই ভালো ফলাফল পাওয়ার সম্ভাবনা বেশি — এবং সেক্ষেত্রে গঠন যোগ করলে শুধু প্রম্পট দীর্ঘ ও পড়তে কঠিন হয়ে যায়, কোনো বাস্তব সুবিধা ছাড়াই।

  • গঠন দরকার: একটা সিস্টেম প্রম্পট যাতে রোল-নির্দেশনা + few-shot উদাহরণ + একাধিক রেফারেন্স ডকুমেন্ট + ব্যবহারকারীর প্রশ্ন — সব একসাথে আছে।
  • গঠন অপ্রয়োজনীয়: "এই বাক্যটাকে আরও আনুষ্ঠানিক করে লিখে দাও" — একটা মাত্র নির্দেশনা, একটা মাত্র ইনপুট।
মূল কথা · Key takeaway

XML ট্যাগ ও Markdown হেডার — দুটোই একই সমস্যার সমাধান করে দুই ভিন্ন idiom-এ: জটিল প্রম্পটের অংশগুলো দ্ব্যর্থহীনভাবে আলাদা করা। কিন্তু গঠন নিজেই কোনো লক্ষ্য নয় — এটা তখনই মূল্যবান যখন প্রম্পটের জটিলতা সত্যিই তা দাবি করে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ যদি আধুনিক মডেল গদ্য থেকেও নির্দেশনা ভালোভাবে আলাদা করতে পারে, তাহলে XML ট্যাগ পুরোপুরি অপ্রচলিত (obsolete) হয়ে যাবে কি?

সম্ভবত না, অন্তত জটিল প্রম্পটের ক্ষেত্রে। মডেল যত উন্নত হোক, একটা প্রম্পটে যখন পাঁচ-ছয়টা ভিন্ন উপাদান (একাধিক ডকুমেন্ট, একাধিক উদাহরণ, নির্দেশনা, ভেরিয়েবল ইনপুট) একসাথে থাকে, স্পষ্ট সীমানা মডেলের জন্য দ্ব্যর্থতা কমানোর একটা সহজ, কম-খরচের উপায়ই থেকে যায়।

বাস্তবিক প্রবণতা হলো — সহজ প্রম্পটে গঠনের প্রয়োজনীয়তা কমছে, কিন্তু জটিল, বহু-অংশের এজেন্টিক ও প্রোডাকশন প্রম্পটে (যেমন RAG সিস্টেমে একাধিক ডকুমেন্ট পাঠানো — পাঠ ২৪) গঠন এখনো সুপারিশকৃত থাকবে বলেই মনে হয়।

প্র ০২ Claude-এর জন্য লেখা একটা XML-ট্যাগযুক্ত প্রম্পট কি GPT বা Gemini-তে ব্যবহার করলে কাজ করবে না?

সাধারণত কাজ করবে — XML ট্যাগ কোনো Claude-নির্দিষ্ট সিনট্যাক্স নয়, এটা শুধু টেক্সটের মধ্যে স্পষ্ট সীমানা তৈরির একটা প্রচলিত উপায়। GPT ও Gemini দুটোই XML-সদৃশ কাঠামো মোটামুটি ভালোভাবে বুঝতে পারে, কারণ প্রশিক্ষণ ডেটায় HTML/XML ফরম্যাটের প্রচুর উদাহরণ থাকে।

তবে যেহেতু OpenAI নিজস্ব ডকুমেন্টেশনে Markdown-হেডার idiom-কেই প্রধান উদাহরণ হিসেবে দেখায়, GPT মডেলে সেই idiom ব্যবহার করলে সম্ভবত সামান্য বেশি নির্ভরযোগ্য ফলাফল পাওয়া যাবে — কারণ মডেলটা সেই প্যাটার্নে বেশি উদাহরণ দেখেই প্রশিক্ষিত হয়েছে।

প্র ০৩ একটা প্রম্পটে কি XML ট্যাগ এবং Markdown হেডার — দুটোই একসাথে ব্যবহার করা যায়?

হ্যাঁ, এবং বাস্তবে এটা প্রায়ই কার্যকর। যেমন একটা Markdown # Context সেকশনের ভেতরেই একাধিক ডকুমেন্ট থাকলে সেগুলোকে <document index="1"> ট্যাগে ভাগ করা যায় — বাইরের কাঠামো Markdown হেডারে, ভেতরের সূক্ষ্ম সীমানা XML ট্যাগে। OpenAI-এর নিজস্ব গাইডলাইনেও এই মিশ্র পদ্ধতির কথা উল্লেখ আছে — দুটো idiom পারস্পরিক exclusive নয়, বরং সম্পূরক।

ব্যবহারিক পরামর্শ — যে idiom-ই বেছে নিন, পুরো প্রম্পট জুড়ে সামঞ্জস্যপূর্ণ থাকুন। মাঝপথে ফরম্যাট পাল্টানো (কিছু অংশে XML, কিছু অংশে র‍্যান্ডম বুলেট) দ্ব্যর্থতা আরও বাড়িয়ে দিতে পারে।

অনুশীলন

  1. গঠন যোগ করুন: নিচের গদ্য-প্রম্পটটাকে XML ট্যাগ ব্যবহার করে সুগঠিত করুন — "তুমি একজন আইনি সহকারী। নিচের চুক্তির ধারাগুলো পড়ে যেকোনো অস্পষ্ট শর্ত চিহ্নিত করো। এখানে একটা উদাহরণ আছে — 'পক্ষগণ যুক্তিসঙ্গত সময়ের মধ্যে অর্থ পরিশোধ করবে' এটা অস্পষ্ট কারণ 'যুক্তিসঙ্গত সময়' নির্দিষ্ট নয়। এখন এই চুক্তিটা দেখো — [চুক্তির টেক্সট]।"

    একটা সুগঠিত সংস্করণ হবে — <instructions> ট্যাগে রোল ও কাজের বর্ণনা, <example> ট্যাগে "যুক্তিসঙ্গত সময়" উদাহরণ, এবং <contract> বা <input> ট্যাগে আসল চুক্তির টেক্সট। এতে মডেলের জন্য স্পষ্ট হয়ে যায় কোনটা নির্দেশনা, কোনটা শুধু একটা উদাহরণ (যা বিশ্লেষণ করার বিষয় নয়), আর কোনটা আসল বিশ্লেষণযোগ্য চুক্তি।

  2. সিদ্ধান্ত নিন: "এই সংখ্যাটাকে বাংলা শব্দে রূপান্তর করো: ৪৫২" — এই প্রম্পটে কি XML ট্যাগ বা Markdown হেডার যোগ করা উচিত?

    না। এটা একটা অত্যন্ত সহজ, একরৈখিক প্রম্পট — একটামাত্র নির্দেশনা, একটামাত্র ইনপুট, কোনো একাধিক উপাদানের মিশ্রণ নেই। এখানে গঠন যোগ করা শুধু অপ্রয়োজনীয় দৈর্ঘ্য বাড়াবে, কোনো দ্ব্যর্থতা কমাবে না — এটাই এই পাঠের "গঠন কখন অপ্রয়োজনীয়" নীতির সরাসরি উদাহরণ।

  3. তুলনা করুন: একটা RAG (Retrieval-Augmented Generation) সিস্টেমে একসাথে ৩টা রেফারেন্স ডকুমেন্ট, ব্যবহারকারীর প্রশ্ন, এবং উত্তর দেওয়ার নিয়ম — এই তিনটে উপাদান পাঠাতে হবে। এখানে XML ট্যাগ পদ্ধতি নাকি Markdown হেডার পদ্ধতি কেন বেশি উপযোগী মনে হয়?

    এটা স্পষ্টভাবে জটিল প্রম্পটের উদাহরণ — একাধিক ডকুমেন্ট + নির্দেশনা + প্রশ্ন একসাথে মিশ্রিত, তাই গঠন স্পষ্টভাবে দরকার। XML ট্যাগ পদ্ধতি এখানে বিশেষভাবে উপযোগী কারণ Anthropic-এর <document index="n"> প্যাটার্নটা ঠিক এই ধরনের একাধিক-ডকুমেন্ট পরিস্থিতির জন্যই ডিজাইন করা — প্রতিটা ডকুমেন্ট আলাদাভাবে নম্বরযুক্ত ও চিহ্নিত থাকে, যা RAG-এর মতো সিস্টেমে অত্যন্ত গুরুত্বপূর্ণ (বিস্তারিত পাঠ ২৪-এ)।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

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