লার্জ ল্যাঙ্গুয়েজ মডেলগুলো তখনই হোঁচট খায় যখন আপনি তাদের একসাথে অনেক কিছু করতে বলেন। একটি চ্যাট উইন্ডোতে পঞ্চাশ পৃষ্ঠার একটি PDF দিয়ে একটি কাঠামোগত বিশ্লেষণ, একটি ঝুঁকি মূল্যায়ন এবং একটি এক্সিকিউটিভ সামারি একই সাথে করতে বলুন। এর ফলাফল সাধারণত অগভীর, বিভ্রান্তিকর বা সম্পূর্ণ ভুল হয়। একটি উন্নত পদ্ধতি হলো যান্ত্রিক। কাজটিকে আলাদা আলাদা ধাপে ভাগ করুন। প্রথম ধাপের আউটপুট সরাসরি দ্বিতীয় ধাপে ইনপুট হিসেবে দিন, এবং এভাবে চলতে থাকুন। Anthropic এই প্যাটার্নটিকে 'প্রম্পট চেইনিং' (prompt chaining) বলে। Google একে 'সিকোয়েন্সিয়াল পাইপলাইন' (sequential pipeline) হিসেবে অভিহিত করে। উভয় নামই একই জিনিস বর্ণনা করে: একটি অ্যাসেম্বলি লাইন যেখানে প্রতিটি স্টেশন একটি নির্দিষ্ট রূপান্তর সম্পন্ন করে।
এটি বাস্তবে দেখতে কেমন
একটি বিশাল প্রম্পটের পরিবর্তে, আপনি ছোট এবং সুনির্দিষ্ট কতগুলো ধাপ তৈরি করেন। একটি কমপ্লায়েন্স টিমের কথা কল্পনা করুন যারা ভেন্ডর সিকিউরিটি অ্যাসেসমেন্ট প্রসেস করে। প্রথম ধাপটি একটি স্ক্যান করা PDF থেকে কাঁচা টেক্সট (raw text) বের করে আনে। দ্বিতীয় ধাপটি এনক্রিপশন স্ট্যান্ডার্ড এবং অ্যাক্সেস কন্ট্রোলের প্রতিটি উল্লেখ শনাক্ত করে। তৃতীয় ধাপটি সেই প্রাপ্ত তথ্যগুলোকে একটি অভ্যন্তরীণ চেকলিস্টের সাথে মিলিয়ে দেখে। চতুর্থ ধাপটি সিকিউরিটি লিডের জন্য একটি সংক্ষিপ্ত মেমো তৈরি করে। একটি এজেন্ট PDF-কে টেক্সটে রূপান্তর করে। পরবর্তী এজেন্ট সেই টেক্সট থেকে নির্দিষ্ট ডেটা সংগ্রহ করে। শেষ এজেন্ট সেই ডেটার ভিত্তিতে একটি সারাংশ লেখে। এই ধাপগুলোর কোনোটিই খুব জাঁকজমকপূর্ণ নয় এবং কোনোটিই একসাথে একাধিক কাজ (multitask) করে না। প্রতিটি অংশ একটি কাজ খুব ভালোভাবে সম্পন্ন করে।
এই কারণেই অ্যাসেম্বলি লাইনের রূপকটি এখানে কার্যকর। একটি কারখানায় একজন কর্মী পুরো গাড়িটি অ্যাসেম্বল করেন না। বিশেষীকরণ (Specialization) গুণমান বজায় রাখে এবং ত্রুটির সম্ভাবনা কমিয়ে দেয়। ল্যাঙ্গুয়েজ মডেলের ক্ষেত্রেও একই যুক্তি প্রযোজ্য। একটি প্রম্পট যা শুধুমাত্র JSON এক্সট্রাকশন করতে বলে, সেটি এমন একটি প্রম্পটের তুলনায় কম ভুল (hallucinate) করার সম্ভাবনা রাখে যা একই অনুরোধে মতামত এবং ফরম্যাটিংও করতে বলে।
অনুমান নয়, গেট তৈরি করুন
যেকোনো চেইনের সবচেয়ে দুর্বল দিক হলো হ্যান্ডঅফ (handoff)। একটি মডেল বিনয়ী প্রত্যাখ্যান, JSON-এর পরিবর্তে একটি মার্কডাউন ব্লক বা একটি অসম্পূর্ণ রেসপন্স দিতে পারে। যদি সেই ভুল তথ্য দ্বিতীয় ধাপে চলে যায়, তবে পুরো চেইনটি ভেঙে পড়ে। এর সমাধান হলো একটি 'গেট' (gate)।
গেট কোনো মডেল কল নয়। এটি একটি সাধারণ কোড। আপনি ধাপগুলোর মাঝে চালানোর জন্য একটি ছোট স্ক্রিপ্ট লিখবেন। এটি আউটপুটের দৈর্ঘ্য পরীক্ষা করতে পারে যাতে নিশ্চিত হওয়া যায় যে এটি খালি নয়। এটি একটি JSON স্কিমা ভ্যালিডেশন চালাতে পারে যাতে নিশ্চিত করা যায় যে কী (keys) গুলো তৃতীয় ধাপের প্রত্যাশার সাথে মিলে যাচ্ছে। পরবর্তী প্রম্পট তৈরি করার আগেই একটি রেজেক্স (regex) চেক যাচাই করতে পারে যে একটি ইমেল ঠিকানা বা তারিখের ফিল্ড আসলে উপস্থিত আছে কি না। এটি ভুল আউটপুটের পেছনে অর্থ অপচয় করার আগেই ত্রুটিগুলো থামিয়ে দেয়। একটি গেট চালাতে কম্পিউট ক্ষমতার মাত্র কয়েক মাইক্রোসেকেন্ড খরচ হয়। কিন্তু একটি ব্যর্থ ডাউনস্ট্রিম LLM কল টোকেন, ল্যাটেন্সি এবং আপনার মানসিক শান্তি নষ্ট করে।
এটিকে কারখানার ফ্লোরে একটি কোয়ালিটি চেকপয়েন্ট হিসেবে ভাবুন। উইজেট গণনার জন্য আপনার এআই (AI) প্রয়োজন নেই। আপনার প্রয়োজন একটি স্কেল বা রুলার।
কখন চেইন করবেন এবং কখন থামবেন
প্রম্পট চেইনিং প্রতিটি সমস্যার জন্য উপযুক্ত নয়। যখন কাজের ধাপগুলো নির্দিষ্ট এবং পুনরাবৃত্তিযোগ্য হয়, তখন এটি ব্যবহার করুন। মাসিক আর্থিক প্রতিবেদন, মানসম্মত চুক্তি পর্যালোচনা এবং লগ অ্যানালাইসিস পাইপলাইন এর ভালো উদাহরণ। আপনি যদি পদ্ধতিটিকে একটি চেকলিস্ট হিসেবে লিখতে পারেন, তবে সম্ভবত আপনি এটি চেইন করতে পারবেন। জটিল কাজের জন্য উচ্চ নির্ভুলতা প্রয়োজন হলেও চেইনিং ব্যবহার করা উচিত। একটি সমস্যাকে ধাপে ধাপে ভাগ করলে মডেলটি প্রতিটি লজিক্যাল লেয়ার একটি করে সামলাতে বাধ্য হয়। পরিশেষে, মনোলিথিক প্রম্পটের চেয়ে চেইনগুলো ডিবাগ করা সহজ। যখন সারাংশটি ভুল হয়, তখন আপনি এক্সট্রাকশনটি পরীক্ষা করেন। যখন এক্সট্রাকশন ভুল হয়, তখন আপনি মূল টেক্সটটি পরীক্ষা করেন। আপনার কাছে পরীক্ষা করার জন্য মধ্যবর্তী আর্টিফ্যাক্ট (intermediate artifacts) থাকে।
যখন আপনি ধাপগুলো আগে থেকে জানেন না, তখন প্রম্পট চেইনিং এড়িয়ে চলুন। অনুসন্ধানমূলক গবেষণা (exploratory research), উন্মুক্ত মগজমন্থন (open-ended brainstorming) বা তদন্তমূলক কাজগুলো কোনো সরলরেখা অনুসরণ করে না। যদি গতি আপনার একমাত্র অগ্রাধিকার হয়, তবে এটি বাদ দিন। চেইনগুলো সিরিয়াল বা ক্রমানুসারে কাজ করে; প্রথম ধাপ শেষ না হওয়া পর্যন্ত দ্বিতীয় ধাপ শুরু হতে পারে না। যদি আপনার ধাপগুলো একে অপরের ওপর নির্ভরশীল না হয়, তবে পরিবর্তে সেগুলো প্যারালালে (parallel) চালান। একই ডকুমেন্টের তিনটি স্বাধীন অনুবাদের জন্য চেইন করার কোনো প্রয়োজন নেই।
অনমনীয়তার ফাঁদ
এই সমস্ত কাঠামোর বিনিময়ে যে ত্যাগ করতে হয় তা হলো অনমনীয়তা (rigidity)। একটি নির্দিষ্ট চেইন নতুন পরিস্থিতির সাথে খাপ খাইয়ে নিতে পারে না। যদি একজন ভেন্ডর ছয়টি ফিল্ডের একটি ফর্ম পাঠায় এবং আপনার স্কিমা ভ্যালিডেশন গেট পাঁচটি ফিল্ড প্রত্যাশা করে, তবে লাইনটি থেমে যাবে। যদি একজন ব্যবহারকারী PDF-এর পরিবর্তে একটি Word ডকুমেন্ট আপলোড করেন, তবে প্রথম ধাপটি ভেঙে পড়বে এবং বাকি চেইনের কাজ করার মতো কিছু থাকবে না।
আরও খারাপ বিষয় হলো, ত্রুটিগুলো ছড়িয়ে পড়ে (propagate)। শুরুতে ঘটে যাওয়া একটি ভুল পুরো চেইন জুড়ে প্রবাহিত হয়। যদি PDF এক্সট্রাক্টর একটি আর্থিক সংখ্যার থেকে নেতিবাচক চিহ্ন (-) বাদ দিয়ে দেয়, তবে প্রতিটি ডাউনস্ট্রিম ধাপ সেই ভুল সংখ্যাটিকে...