আউটপুট ফরম্যাট নিয়ন্ত্রণ
এই পাঠে যা শিখবেন
- কেন নেতিবাচক নির্দেশনার বদলে ইতিবাচক নির্দেশনা বেশি কার্যকর
- প্রম্পট-স্টাইল কীভাবে আউটপুট-স্টাইলকে প্রভাবিত করে
- Structured Outputs / JSON mode ধারণাগতভাবে কীভাবে কাজ করে
- কেন prefilled response থেকে schema-constrained আউটপুটে স্থানান্তর ঘটেছে
১ · কী করতে হবে বলুন, কী করতে হবে না তা নয়
একটি সাধারণ ভুল হলো মডেলকে নেতিবাচক নির্দেশনা দিয়ে আউটপুট নিয়ন্ত্রণ করার চেষ্টা করা — "মার্কডাউন ব্যবহার করো না," "বুলেট পয়েন্ট দিও না," "ভূমিকা লিখো না।" এই ধরনের নির্দেশনা প্রায়ই কাজ করে না, কারণ এটি মডেলকে শুধু বলে দেয় কী এড়াতে হবে — কিন্তু তার বদলে ঠিক কী করতে হবে তার কোনো স্পষ্ট লক্ষ্য দেয় না।
সমাধান — নেতিবাচক নির্দেশনাকে ইতিবাচক নির্দেশনায় রূপান্তর করুন। "মার্কডাউন ব্যবহার করো না" না বলে বলুন "স্বাভাবিক, প্রবহমান প্যারাগ্রাফে লেখো।" এটি মডেলকে একটি স্পষ্ট, ইতিবাচক লক্ষ্য দেয় — এবং সেই লক্ষ্যের দিকে পরবর্তী টোকেন অনুমান করা মডেলের জন্য অনেক সহজ, কারণ এটি এখন কী করতে হবে তা "জানে", শুধু কী এড়াতে হবে তা নয়।
❌ কম কার্যকর (Less effective) — নেতিবাচক নির্দেশনা:
Don't use markdown formatting. Don't use bullet points. Don't
write a long introduction.✅ বেশি কার্যকর (More effective) — ইতিবাচক নির্দেশনা:
Write your response in flowing prose paragraphs, as if explaining
it to a colleague in conversation. Start directly with the main
point.এই নীতিটি শুধু ফরম্যাটিং-এর জন্য নয় — এটি একটি সাধারণ প্রম্পট ইঞ্জিনিয়ারিং সূত্র। যেকোনো "X কোরো না" নির্দেশনাকে "এর বদলে Y করো" আকারে রূপান্তর করার চেষ্টা করুন। এটি Gemini-এর গাইডলাইনেও প্রতিফলিত হয় — বড় নেতিবাচক নিয়ন্ত্রণ ("do not infer," "do not guess") মডেলকে সেই নিয়মের উপর অতিরিক্ত মনোযোগ দিতে বাধ্য করে এবং সাধারণ যুক্তি বা তথ্য সংশ্লেষণেও ব্যর্থ করতে পারে — বরং স্পষ্ট, ইতিবাচক নির্দেশনা (যেমন "শুধু দেওয়া তথ্যের ভিত্তিতে উত্তর দাও") অনেক নিরাপদ।
২ · প্রম্পটের স্টাইল আউটপুটের স্টাইল ঠিক করে দেয়
একটি কম আলোচিত কিন্তু শক্তিশালী কৌশল — আপনার প্রম্পট নিজেই যেভাবে লেখা, মডেল প্রায়ই সেই স্টাইল "প্রতিফলিত" করে। যদি আপনার প্রম্পট আনুষ্ঠানিক, সংক্ষিপ্ত বুলেট-পয়েন্ট আকারে লেখা হয়, মডেল প্রায়ই বুলেট-পয়েন্ট আকারেই উত্তর দেয়। যদি প্রম্পট প্রবহমান, কথোপকথনমূলক গদ্যে লেখা হয়, উত্তরও প্রায়ই সেই স্টাইল অনুসরণ করে।
এটা হয় কারণ — পাঠ ০১-এর ধারণা মনে করুন — মডেল প্রতিটি টোকেনের পরবর্তী সম্ভাব্য টোকেন অনুমান করে পুরো প্রম্পটের প্রেক্ষাপট বিবেচনা করে। প্রম্পটের নিজস্ব শব্দচয়ন, বাক্যগঠন ও ফরম্যাট — সবকিছুই সেই প্রেক্ষাপটের অংশ, এবং মডেল তার প্রশিক্ষণ ডেটা থেকে শেখা প্যাটার্ন অনুযায়ী প্রায়ই "মিলে যাওয়া" স্টাইলে সাড়া দেয়।
ব্যবহারিক প্রভাব — যদি আপনি চান আউটপুট প্রবহমান প্রবন্ধের মতো হোক, প্রম্পটও তেমন প্রবহমান বাক্যে লিখুন, শুধু একটি নির্দেশনা যোগ করবেন না। বিপরীতভাবে, যদি আপনি একটি নির্দিষ্ট কাঠামোবদ্ধ আউটপুট চান, প্রম্পটেই সেই কাঠামো (হেডিং, নাম্বারিং) ব্যবহার করে দেখান — যা পাঠ ০৬-এর XML/Markdown গঠন-কৌশলের সাথে সরাসরি সম্পর্কিত।
৩ · কড়া স্ট্রাকচার্ড আউটপুট দরকার হলে — Structured Outputs
কখনো কখনো "স্টাইল মেলানো" বা "ভদ্রভাবে অনুরোধ করা" যথেষ্ট নয় — বিশেষত যখন আউটপুটটি একটি প্রোগ্রামে সরাসরি পার্স হবে (যেমন একটি API রেসপন্স, একটি ডেটাবেসে সেভ হওয়া রেকর্ড)। এমন ক্ষেত্রে শুধু "please respond in JSON" জাতীয় অনুরোধ যথেষ্ট নির্ভরযোগ্য নয় — মডেল মাঝে মাঝে অতিরিক্ত ব্যাখ্যা, ভুল কী-নাম, বা সামান্য ভুল সিনট্যাক্স যোগ করে দিতে পারে।
এই সমস্যার আধুনিক সমাধান — Structured OutputsStructured Outputsএকটি API ফিচার যেখানে আপনি একটি স্কিমা (যেমন JSON Schema) নির্দিষ্ট করে দেন, এবং প্রোভাইডার নিশ্চিত করে যে মডেলের আউটপুট সবসময় ঠিক সেই স্কিমা মেনে চলবে — অনুরোধের উপর নয়, প্রযুক্তিগত বাধ্যবাধকতার উপর ভিত্তি করে। — যেখানে আপনি একটি স্কিমা (কোন ফিল্ড, কোন টাইপ, কোনটা আবশ্যক) সরবরাহ করেন, এবং প্রোভাইডার মডেলের আউটপুট সেই স্কিমার সাথে মেলে কি না তা প্রযুক্তিগতভাবে নিশ্চিত করে।
সহজভাবে বললে — "please respond in JSON" হলো মডেলকে ভদ্রভাবে অনুরোধ করা, যা মডেলের ইচ্ছার উপর নির্ভরশীল। Structured Outputs হলো মডেলের আউটপুট-উৎপাদন প্রক্রিয়াতেই একটি প্রযুক্তিগত সীমাবদ্ধতা বসিয়ে দেওয়া — মডেল এমন কোনো টোকেন বসাতেই পারে না যা স্কিমা লঙ্ঘন করে। এটাই কেন এটি "ভদ্র অনুরোধের" চেয়ে অনেক বেশি নির্ভরযোগ্য।
উদাহরণস্বরূপ, যদি আপনি একটি গ্রাহক-রিভিউ বিশ্লেষণ টুল বানান, আপনি একটি স্কিমা দিতে পারেন যেখানে বলা আছে — আউটপুটে অবশ্যই `sentiment` (নির্দিষ্ট তিনটি মানের একটি: positive/negative/neutral), `summary` (স্ট্রিং), এবং `key_issues` (স্ট্রিং-এর একটি তালিকা) থাকতে হবে। Structured Outputs ব্যবহার করলে মডেল আউটপুট প্রায় প্রতিবারই ঠিক এই কাঠামোয় আসবে — কোনো অতিরিক্ত টেক্সট, কোনো ভুল ফিল্ড-নাম ছাড়াই।
৪ · প্রিফিলড রেসপন্স থেকে Structured Outputs-এ স্থানান্তর
আগে একটি জনপ্রিয় কৌশল ছিল "prefilling" — অ্যাসিস্ট্যান্টের উত্তরের প্রথম কয়েকটি টোকেন আগে থেকেই বসিয়ে দেওয়া (যেমন `{` দিয়ে শুরু করিয়ে দেওয়া) যাতে মডেল বাধ্য হয়ে সরাসরি JSON দিয়ে উত্তর শুরু করে, কোনো ভূমিকা বা ব্যাখ্যা ছাড়াই।
এই স্থানান্তরের যুক্তিটা বোঝা জরুরি — prefilling ছিল একটি "কৌশলগত হ্যাক" যা মডেলের টোকেন-উৎপাদন প্রক্রিয়ার একটি দুর্বলতা কাজে লাগাত (জোর করে প্রথম টোকেন বসিয়ে দেওয়া)। Structured Outputs একই লক্ষ্য অর্জন করে, কিন্তু একটি পরিষ্কার, প্রথম-শ্রেণীর API ফিচার হিসেবে — যা বেশি নির্ভরযোগ্য, বেশি রক্ষণাবেক্ষণযোগ্য এবং ভবিষ্যতের মডেল আপডেটের সাথে বেশি সামঞ্জস্যপূর্ণ।
আউটপুট ফরম্যাট নিয়ন্ত্রণে তিনটি স্তর মনে রাখুন — (১) সাধারণ প্রবাহের জন্য পজিটিভ নির্দেশনা ও স্টাইল-ম্যাচিং যথেষ্ট; (২) মাঝারি কড়াকড়ির জন্য প্রম্পটে স্পষ্ট কাঠামো (হেডিং, XML ট্যাগ) দেখানো যথেষ্ট; (৩) যখন আউটপুট প্রোগ্রামে পার্স হবে, তখন Structured Outputs ব্যবহার করুন — এটি একমাত্র পদ্ধতি যা প্রায় ১০০% নিশ্চয়তা দেয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ "মার্কডাউন ব্যবহার করো না" নির্দেশনা কেন মডেলের জন্য একটি অস্পষ্ট লক্ষ্য তৈরি করে, অথচ "প্রবহমান প্যারাগ্রাফে লেখো" স্পষ্ট?
পাঠ ০১-এর টোকেন-অনুমান ধারণা মনে করুন — প্রতিটি ধাপে মডেল ভাবছে "পরবর্তী সবচেয়ে সম্ভাব্য টোকেন কী?" "মার্কডাউন ব্যবহার করো না" শুধু একটি সম্ভাব্য পথ (বুলেট, হেডিং) বাদ দেয়, কিন্তু বাকি অসংখ্য সম্ভাব্য পথের মধ্যে কোনটা বেছে নিতে হবে তা বলে না।
"প্রবহমান প্যারাগ্রাফে লেখো" সরাসরি একটি নির্দিষ্ট, ইতিবাচক লক্ষ্য দেয় — এখন মডেলের পরবর্তী-টোকেন-অনুমান সেই একটি নির্দিষ্ট প্যাটার্নের দিকে পরিচালিত হয়, বহু অস্পষ্ট "না" এর মধ্যে থেকে একটা বেছে নেওয়ার বদলে।
প্র ০২ যদি Structured Outputs এত নির্ভরযোগ্য, তাহলে এটা কি সবসময় "ভদ্রভাবে JSON চাওয়া"-র চেয়ে ব্যবহার করা উচিত?
প্রায় সবসময়, যখন আউটপুট প্রোগ্রামে পার্স হবে — হ্যাঁ। কিন্তু Structured Outputs-এর একটি খরচ আছে — স্কিমা ডিজাইন ও রক্ষণাবেক্ষণের বাড়তি কাজ, এবং কিছু ক্ষেত্রে সামান্য বেশি latency বা সীমিত নমনীয়তা (মডেল স্কিমার বাইরে সৃজনশীল কিছু যোগ করতে পারে না, এমনকি যদি সেটা দরকারী হতো)।
একটি এক-বারের এক্সপ্লোরেটরি কাজে, বা যেখানে আউটপুট শুধু মানুষ পড়বে, সেখানে স্কিমা তৈরির বাড়তি খরচ অপ্রয়োজনীয় — সেখানে সাধারণ নির্দেশনাই যথেষ্ট।
প্র ০৩ প্রম্পটের নিজস্ব স্টাইল আউটপুট স্টাইলকে প্রভাবিত করে — এটা কি সবসময় কাজে লাগানো উচিত, নাকি এর কোনো সীমাবদ্ধতা আছে?
এটা একটি শক্তিশালী সিগন্যাল, কিন্তু একমাত্র নিয়ন্ত্রণ পদ্ধতি নয় — স্টাইল-ম্যাচিং প্রায়ই কাজ করে কিন্তু ১০০% নিশ্চয়তা দেয় না, কারণ এটি এখনো "সম্ভাবনা-ভিত্তিক" অনুমানের উপর নির্ভরশীল, প্রযুক্তিগত বাধ্যবাধকতার উপর নয়।
তাই ব্যবহারিক নিয়ম — কম কড়াকড়ির কাজে (একটি ব্লগ পোস্টের টোন) স্টাইল-ম্যাচিং যথেষ্ট; কিন্তু যেখানে ফরম্যাট ভুল হলে সিস্টেম ভেঙে পড়বে (যেমন একটি JSON API রেসপন্স), সেখানে Structured Outputs-এর মতো কড়া নিয়ন্ত্রণ প্রয়োজন।
অনুশীলন
-
রূপান্তর করুন: নিচের তিনটি নেতিবাচক নির্দেশনাকে ইতিবাচক নির্দেশনায় রূপান্তর করুন — "উত্তরে ইমোজি
ব্যবহার কোরো না," "অতিরিক্ত বিনয়ী ভাষা লিখো না," "প্রযুক্তিগত পরিভাষা এড়িয়ে যেও না।"
সম্ভাব্য রূপান্তর — "শুধু সাধারণ টেক্সটে উত্তর দাও," "সরাসরি ও সংক্ষিপ্ত ভাষায় লেখো," "যেখানে প্রাসঙ্গিক, সঠিক প্রযুক্তিগত পরিভাষা ব্যবহার করো।" প্রতিটি ক্ষেত্রেই লক্ষ্য একটাই — মডেলকে কী এড়াতে হবে তা নয়, বরং কী করতে হবে তা স্পষ্টভাবে বলা।
-
ডিজাইন করুন: একটি রেস্টুরেন্ট রিভিউ থেকে তথ্য বের করার জন্য একটি সাধারণ স্কিমা কল্পনা করুন — কোন
তিন-চারটি ফিল্ড থাকা উচিত, এবং প্রতিটির টাইপ কী হবে?
একটি যুক্তিসঙ্গত স্কিমা — `restaurant_name` (স্ট্রিং), `rating` (সংখ্যা, ১-৫), `sentiment` (নির্দিষ্ট মান: positive/negative/mixed), এবং `mentioned_dishes` (স্ট্রিং-এর তালিকা)। Structured Outputs ব্যবহার করলে প্রতিটি রিভিউ থেকে এই কাঠামোই নির্ভরযোগ্যভাবে বের হবে।
-
চিন্তা করুন: prefilled response (মডেলের উত্তর `{` দিয়ে জোর করে শুরু করানো) কেন একটি "ভঙ্গুর"
(fragile) কৌশল হিসেবে বিবেচিত হতে পারে, যা মডেল আপডেটের সাথে ভেঙে যেতে পারে?
কারণ prefilling একটি অনানুষ্ঠানিক "হ্যাক" — এটি কোনো অফিসিয়াল, ডকুমেন্টেড ফিচার হিসেবে গ্যারান্টিযুক্ত নয়, বরং মডেলের টেক্সট-জেনারেশন আচরণের একটি বৈশিষ্ট্য কাজে লাগায়। যখন প্রোভাইডার মডেলের অভ্যন্তরীণ আচরণ পরিবর্তন করে (যেমন নতুন Claude মডেলে prefilling বন্ধ করে দেওয়া), এই ধরনের হ্যাক ভেঙে যায় — যেখানে Structured Outputs-এর মতো ফার্স্ট-ক্লাস ফিচার দীর্ঘমেয়াদে স্থিতিশীল থাকার প্রতিশ্রুতি দেয়।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ — অনিশ্চয়তা প্রকাশের অনুমতি পাঠ ১০ কেন মডেলকে "আমি জানি না" বলার অনুমতি দিলে hallucination কমে — বিস্তারিত পরবর্তী পাঠে।
- সব AI Courses দেখুন ABCL TECH AI Foundations, Python for AI, Machine Learning, Deep Learning, NLP ও LLM, Prompt Engineering — সব এক জায়গায়।
- AI সংবাদ ও সাম্প্রতিক ঘটনাবলি Blog ABCL TECH-এর বাংলা AI সংবাদ — Claude, GPT, Gemini-এর নতুন মডেল ও আপডেট নিয়ে।