টুল ইউজ প্রম্পটিং
এই পাঠে যা শিখবেন
- "পরামর্শ দাও" বনাম "কাজ করো" — প্রম্পটের এক শব্দ কীভাবে এজেন্টের আচরণ বদলে দেয়
- প্রোঅ্যাক্টিভনেস নিয়ন্ত্রণের দুটি প্যাটার্ন — action-first এবং confirmation-first
- কেন অতিরিক্ত জোরালো নির্দেশনা (CRITICAL, MUST) আধুনিক মডেলে পাল্টা ফল দেয়
- প্যারালাল টুল কলিং কী, এবং কখন এটা চান বা চান না
১ · এজেন্ট মানে শুধু চ্যাটবট নয়
এখন পর্যন্ত এই কোর্সে আমরা মূলত এমন প্রম্পট নিয়ে আলোচনা করেছি যেখানে মডেল টেক্সট উৎপন্ন করে আর মানুষ সেটা পড়ে। কিন্তু বাস্তব প্রোডাকশন সিস্টেমে LLM প্রায়ই একটি টুল / ফাংশন (Tool / Function)Tool / Functionমডেলকে দেওয়া একটি নির্দিষ্ট ক্ষমতা — যেমন ফাইল পড়া, কোড এডিট করা, ডেটাবেসে কোয়েরি চালানো, বা কোনো API কল করা। মডেল টুলের নাম ও প্যারামিটার নির্বাচন করে, আসল এক্সিকিউশন সাধারণত একটি বাহ্যিক সিস্টেম চালায়। -এর সাথে যুক্ত থাকে — কোড এডিটর, ফাইল সিস্টেম, সার্চ ইঞ্জিন, ডেটাবেস, অন্য কোনো API। এই সেটআপে মডেলকে বলা হয় এজেন্ট (Agent) — এমন একটি সিস্টেম যা শুধু উত্তর দেয় না, বরং নিজের সিদ্ধান্তে টুল ব্যবহার করে বাস্তব কাজ সম্পন্ন করে।
এই পাঠ থেকে আমরা মডিউল ৫-এ ঢুকছি — কোর্সের এই অংশটা এজেন্টিক প্রম্পটিং নিয়ে, অর্থাৎ যেখানে মডেল শুধু কথা বলে না, বরং কাজ করে। এটাই আজকের সবচেয়ে বাস্তব প্রোডাকশন ব্যবহার — কোডিং অ্যাসিস্ট্যান্ট, কাস্টমার সাপোর্ট বট যা টিকিট আপডেট করে, রিসার্চ এজেন্ট যা একাধিক ওয়েবসাইট ভিজিট করে — সবগুলোই টুল ইউজ প্রম্পটিং-এর উপর নির্ভর করে।
২ · "পরামর্শ দাও" বনাম "কাজ করো"
একটি এজেন্টিক সিস্টেম তৈরির সময় সবচেয়ে সাধারণ ভুল হলো — প্রম্পটে অস্পষ্ট রেখে দেওয়া যে মডেল আসলে টুল ব্যবহার করে কাজটা করবে, নাকি শুধু কী করা উচিত তা বলবে। মডেল ভাষাগতভাবে দুটোকেই বৈধ ব্যাখ্যা হিসেবে দেখতে পারে।
Can you suggest some changes to improve this function?এই বাক্যে "suggest" শব্দটাই মডেলকে বলে দিচ্ছে — শুধু পরামর্শ দাও, কোড এডিট করার টুল কল করার দরকার নেই। ফলে মডেল একটা ব্যাখ্যা লিখে দেবে, কিন্তু আসল ফাইলে কোনো পরিবর্তন হবে না — এমনকি যদি তার কাছে edit করার টুল থাকেও।
Change this function to improve its performance.এখানে ক্রিয়াপদ সরাসরি — "change" মানে সরাসরি কাজ, ফলে মডেল নিজের এডিট-টুল কল করে বাস্তবে ফাইলটা বদলে দেয়। এই পার্থক্যটা এতটাই সূক্ষ্ম যে বেশিরভাগ ডেভেলপার প্রথমবার খেয়ালই করেন না — অথচ এটাই ঠিক করে দেয় এজেন্ট আসলে কাজ করবে নাকি শুধু আলোচনা করবে।
এজেন্টিক প্রম্পটে ক্রিয়াপদ বেছে নেওয়াটাই সিদ্ধান্ত। "suggest / could / might" জাতীয় শব্দ মডেলকে passive রাখে; "do / change / fix / implement" জাতীয় সরাসরি নির্দেশ মডেলকে active রাখে। কোনটা চান তা আগে ঠিক করুন, তারপর সেই অনুযায়ী শব্দ বাছুন।
৩ · প্রোঅ্যাক্টিভনেস নিয়ন্ত্রণের দুটি প্যাটার্ন
একটা এজেন্ট কতটা প্রোঅ্যাক্টিভ হবে — সব পরিস্থিতিতে এক রকম হওয়া উচিত নয়। কোডিং টাস্কে হয়তো আপনি চান মডেল নিজে থেকেই এগিয়ে গিয়ে কাজ শেষ করুক; কিন্তু গ্রাহক-মুখী একটি সাপোর্ট বটে হয়তো চান প্রতিটি বড় পদক্ষেপের আগে অনুমতি নিক। এই দুই প্রান্তের জন্য সিস্টেম প্রম্পটে দুটি ভিন্ন ব্লক ব্যবহার করা যায়।
<default_to_action>
When the user's request is clear, take the action directly using
the available tools rather than only describing what you would do.
Ask for confirmation only when the action is destructive, ambiguous,
or outside the scope of what was requested.
</default_to_action>এই ব্লক মডেলকে ডিফল্টভাবে "করে ফেলো" মোডে রাখে — যেমন একটা কোডিং এজেন্ট যাকে দ্রুত ইটারেট করতে হয়, প্রতিটি ছোট পরিবর্তনে থেমে অনুমতি চাওয়া বিরক্তিকর ও অদক্ষ হয়ে যায়।
<do_not_act_before_instructions>
Do not call any tool that modifies data, sends a message, or changes
state until the user has explicitly confirmed the specific action.
Describe what you plan to do first, then wait for approval.
</do_not_act_before_instructions>এই ব্লক ঠিক উল্টো — মডেলকে রক্ষণশীল রাখে, প্রতিটি state-পরিবর্তনকারী পদক্ষেপের আগে ব্যাখ্যা ও অনুমোদন চাইতে বাধ্য করে। কাস্টমার-মুখী সিস্টেম, আর্থিক লেনদেন, বা যেকোনো জায়গায় ভুলের মূল্য বেশি — সেখানে এই প্যাটার্ন নিরাপদ।
৪ · কেন "CRITICAL: you MUST" এখন পাল্টা ফল দেয়
কয়েক বছর আগে পর্যন্ত অনেক প্রম্পট ইঞ্জিনিয়ার বিশ্বাস করতেন — নির্দেশনা যত জোরালো ভাষায় লেখা হবে (সব ক্যাপিটাল, "CRITICAL", "MANDATORY", "you MUST"), মডেল তত বেশি মনোযোগ দেবে। কিন্তু আধুনিক মডেলগুলোতে এই কৌশল প্রায়ই উল্টো ফল দেয়।
CRITICAL: you MUST ALWAYS use the search_docs tool before answering
ANY question. This is MANDATORY and NON-NEGOTIABLE.Use the search_docs tool when the user asks about product features,
pricing, or policies that you're not certain about.দ্বিতীয় সংস্করণে কোনো জোরালো শব্দ নেই — শুধু কখন টুলটা ব্যবহার করতে হবে তার স্পষ্ট শর্ত। এটাই আধুনিক মডেলে বেশি নির্ভরযোগ্য ফল দেয়, কারণ মডেল নির্দেশটাকে একটা স্বাভাবিক নিয়ম হিসেবে পড়ে, জরুরি সতর্কসংকেত হিসেবে নয়।
জোরালো ভাষা এক সময় দরকার ছিল কারণ পুরনো মডেলগুলো নির্দেশনা উপেক্ষা করত। আধুনিক মডেল ইতিমধ্যেই নির্দেশনার প্রতি যথেষ্ট মনোযোগী — তাই এখন দরকার স্বাভাবিক, স্পষ্ট শর্তসাপেক্ষ ভাষা, চিৎকার-করা ভাষা নয়।
৫ · প্যারালাল টুল কলিং
যখন একটি টাস্কে একাধিক টুল কল লাগে যেগুলো একে অপরের উপর নির্ভরশীল নয় — যেমন তিনটি ভিন্ন ফাইল পড়া, বা দুটো ভিন্ন API থেকে তথ্য আনা — আধুনিক মডেলগুলো ডিফল্টভাবে এই কলগুলো প্যারালাল টুল কলিং (Parallel Tool Calling)Parallel Tool Callingএকাধিক স্বাধীন টুল কল একসাথে (sequentially একটার পর একটা না করে) পাঠানো, যাতে সেগুলো সমান্তরালে এক্সিকিউট হতে পারে এবং সামগ্রিক সময় কমে। -এর মাধ্যমে একসাথে পাঠায়, একটার পর একটা অপেক্ষা না করে। এতে সামগ্রিক সময় অনেকটাই কমে যায়।
<use_parallel_tool_calls>
When multiple independent pieces of information are needed, issue all
the relevant tool calls together in the same turn rather than one at
a time and waiting for each result before starting the next.
</use_parallel_tool_calls>এই ব্লক ব্যবহার করে আপনি এই আচরণ জোরদার করতে পারেন — বিশেষ করে যদি দেখেন মডেল অপ্রয়োজনীয়ভাবে একটার পর একটা সিরিয়ালি টুল কল করছে। কিন্তু সব পরিস্থিতিতে প্যারালাল কলিং ভালো নয়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একটি কোডিং এজেন্টকে "fix the bug in this function" বলা হলো, কিন্তু এজেন্ট শুধু বাগটা কোথায় তা ব্যাখ্যা করে থেমে গেল, ফাইল এডিট করল না। সম্ভাব্য কারণ কী হতে পারে?
সম্ভবত সিস্টেম প্রম্পটে বা প্রসঙ্গে এমন কিছু আছে যা মডেলকে "suggest" মোডে ঠেলে দিচ্ছে — হয়তো আগের কথোপকথনে ব্যবহারকারী শুধু ব্যাখ্যা চেয়েছিলেন, অথবা সিস্টেম প্রম্পটে "explain issues" জাতীয় ভাষা আছে যা "fix" নির্দেশের সাথে সাংঘর্ষিক। এমনও হতে পারে এজেন্টের কাছে এডিট-টুল অ্যাক্সেসই নেই।
সমাধান — একটি <default_to_action> ব্লক যোগ করে স্পষ্ট করে দিন যে পরিষ্কার নির্দেশের ক্ষেত্রে মডেলের
সরাসরি কাজ করা উচিত, শুধু বর্ণনা দেওয়া নয়। এবং নিশ্চিত করুন প্রয়োজনীয় টুল আসলেই মডেলকে দেওয়া আছে।
প্র ০২ একটি টিম তাদের এজেন্ট প্রম্পটে "CRITICAL: you MUST verify EVERY answer" লিখে দেখল মডেল প্রতিটি সাধারণ প্রশ্নেও অপ্রয়োজনীয় ভেরিফিকেশন টুল কল করছে, এমনকি সহজ প্রশ্নেও। কেন এমন হলো, এবং কীভাবে ঠিক করবেন?
এটাই ঠিক সেই overtriggering সমস্যা — জোরালো ভাষা ("CRITICAL", "MUST", "EVERY") মডেলকে শর্তহীনভাবে নির্দেশ পালনে ঠেলে দিচ্ছে, ফলে যেসব ক্ষেত্রে ভেরিফিকেশন আসলে দরকার নেই সেখানেও মডেল সেটা চালাচ্ছে — বাড়তি লেটেন্সি ও খরচ তৈরি করছে।
সমাধান — জোরালো ভাষা সরিয়ে শর্তসাপেক্ষ, স্বাভাবিক নির্দেশনায় ফিরে যান, যেমন — "Verify the answer against the test criteria when the question involves calculations, code correctness, or factual claims that could be checked." এতে মডেল কখন ভেরিফাই করবে তার স্পষ্ট শর্ত পাবে, সবসময় নয়।
প্র ০৩ একটি এজেন্টকে একই সাথে তিনটি আলাদা ফাইল থেকে তথ্য পড়তে হবে যেগুলো একে অপরের উপর নির্ভর করে না, অথচ মডেল সেগুলো একটার পর একটা ক্রমান্বয়ে পড়ছে। প্রম্পটে কী যোগ করবেন?
এখানে সমস্যাটা নির্ভরতার নয়, বরং মডেল হয়তো ডিফল্ট প্যারালাল আচরণ প্রয়োগ করছে না — একটা
<use_parallel_tool_calls> ব্লক যোগ করে স্পষ্ট করে দিন যে স্বাধীন তথ্য-সংগ্রহের কাজগুলো একসাথে,
একই টার্নে পাঠাতে হবে।
তবে যদি টাস্কের প্রকৃতি এমন হয় যে একটা ফলাফলের উপর ভিত্তি করে পরের পদক্ষেপ নির্ধারিত হয় (যেমন প্রথম ফাইল থেকে খুঁজে বের করা নাম দিয়ে দ্বিতীয় ফাইল সার্চ করা), তাহলে প্যারালাল করা ঠিক হবে না — সেক্ষেত্রে নির্ভরতা স্পষ্ট করে বলাটাই ভালো সমাধান।
অনুশীলন
-
রিরাইট করুন: "Can you check if there are any issues with the database schema?" বাক্যটিকে এমনভাবে
রিরাইট করুন যাতে এজেন্ট শুধু চেক না করে, সমস্যা পেলে সরাসরি ফিক্সও করে ফেলে।
উদাহরণ: "Review the database schema and fix any issues you find — for example missing indexes, inconsistent naming, or nullable columns that should be required." এখানে "review... and fix" ক্রিয়াপদজোড়া সরাসরি কাজের নির্দেশ দিচ্ছে, শুধু পর্যালোচনার নির্দেশ নয়।
-
বিশ্লেষণ করুন: একটি গ্রাহক-সাপোর্ট এজেন্ট যে রিফান্ড প্রসেস করতে পারে, তার জন্য
<default_to_action>নাকি<do_not_act_before_instructions>— কোনটা বেশি উপযুক্ত মনে হয়, এবং কেন?সাধারণত
<do_not_act_before_instructions>-ই বেশি উপযুক্ত — রিফান্ড প্রসেস করা একটি আর্থিক, হার্ড-টু-রিভার্স পদক্ষেপ, তাই ব্যবহারকারীর স্পষ্ট নিশ্চয়তা ছাড়া তা কার্যকর করা উচিত নয়। এটা আগামী পাঠে (দীর্ঘ-মেয়াদী এজেন্ট নিরাপত্তা) আরও বিস্তারিত আলোচনা করা হবে। -
ডিবাগ করুন: একটি এজেন্ট প্রম্পটে লেখা আছে "IMPORTANT!!! You MUST ALWAYS call the calculator
tool for ANY numeric question, no exceptions!!!" — এই নির্দেশনার কী সমস্যা হতে পারে, এবং কীভাবে রিরাইট করবেন?
এই নির্দেশনা অতিরিক্ত জোরালো ভাষা ও নিরঙ্কুশ শর্ত ("ANY", "no exceptions") ব্যবহার করছে, যা আধুনিক মডেলে overtriggering ঘটাতে পারে — এমনকি "আমার বয়স কত?" জাতীয় প্রশ্নেও ক্যালকুলেটর টুল কল হতে পারে। রিরাইট: "Use the calculator tool when the question requires a numeric calculation beyond simple arithmetic you can do reliably yourself." এটা শর্তসাপেক্ষ ও স্বাভাবিক ভাষায় লেখা।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ — লং-কনটেক্সট প্রম্পটিং পাঠ ২১ দীর্ঘ ডকুমেন্ট ও মাল্টি-ডকুমেন্ট প্রম্পটে কীভাবে কাঠামো ও ক্রম মডেলের নির্ভুলতা বাড়ায়।
- সব 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-এর নতুন মডেল ও আপডেট নিয়ে।