AI এজেন্ট ডেমোর পেছনের গোপন রহস্য
LinkedIn-এ যে অসংখ্য AI-এজেন্ট ডেমো দেখা যাচ্ছে, তার বেশিরভাগই প্রকৃত এজেন্ট নয়। আমি সারাদিন রিসার্চ পেপার পড়ি এবং যারা প্রোডাক্ট শিপ করেন এমন ইঞ্জিনিয়ারদের সাথে কথা বলি; আমি দেখতে পাচ্ছি চাকচিক্যময় ডেমো এবং প্রোডাকশন-রেডি সিস্টেমের মধ্যে ব্যবধান দিন দিন বাড়ছে। যারা কেবল হাইপ বা উত্তেজনার পেছনে ছোটে, তারা শেষ পর্যন্ত ভঙ্গুর এবং অতিরিক্ত জটিল (over-engineered) টুল তৈরি করে।
কেন এই হাইপ বা উত্তেজনা গুরুত্বপূর্ণ
“Agent” শব্দটি এখন এমন একটি বহুল ব্যবহৃত শব্দ (buzzword) হয়ে দাঁড়িয়েছে যা যে কেউ একটি স্ক্রিপ্ট, একটি চ্যাটবট বা একটি সাধারণ ফাংশনের সাথে জুড়ে দিতে পারে যা কোনো এক্সটার্নাল টুল কল করে। এর ফলাফল হলো: এমন সব ডেমো যা স্ক্রিনে দেখতে খুব আকর্ষণীয় মনে হলেও একটি স্বয়ংক্রিয় সিস্টেমের মূল গুণাবলি—একটি স্পষ্ট লক্ষ্য, পরবর্তী পদক্ষেপ নির্ধারণের ক্ষমতা এবং বিল্ট-ইন ফেইলিওর হ্যান্ডলিং (failure handling)—সেগুলোতে অনুপস্থিত। যখন টিমগুলো একটি পালিশ করা ডেমোকে একটি তৈরি সমাধান হিসেবে ভুল করে, তখন তারা হয় সাধারণ কাজের জন্য অপ্রয়োজনীয় কাঠামো (scaffolding) তৈরিতে শ্রম অপচয় করে, অথবা জটিল কাজের জন্য অত্যন্ত ভঙ্গুর পাইপলাইন তৈরি করে।
আসল এবং চাকচিক্যময়কে আলাদা করার চেকলিস্ট
এই বিশ্লেষণটি তিনটি দ্রুত প্রশ্ন প্রস্তাব করে যা একজন ডেভেলপারকে একটি প্রকৃত এজেন্ট চিনতে সাহায্য করবে:
সিস্টেমটির কি প্রতিটি পদক্ষেপের জন্য মানুষের নির্দেশনার প্রয়োজন হয়? যদি উত্তর 'হ্যাঁ' হয়, তবে এটি কেবল একটি চ্যাট ইন্টারফেস, কোনো স্বয়ংক্রিয় এজেন্ট নয়।
সিস্টেমটি কি একটি ব্যর্থ টুল কল (tool call) থেকে পুনরুদ্ধার করতে পারে? একটি এজেন্টের অবশ্যই ব্যর্থতা শনাক্ত করতে হবে এবং সিদ্ধান্ত নিতে হবে যে এটি পুনরায় চেষ্টা (retry) করবে কি না, বিকল্প কোনো উপায়ে কাজ করবে কি না, নাকি মার্জিতভাবে প্রক্রিয়াটি বন্ধ করে দেবে।
সিস্টেমটি কি একটি উচ্চ-স্তরের লক্ষ্যকে উপ-কাজে (subtasks) বিভক্ত করতে পারে? প্রকৃত এজেন্টরা একটি নির্দিষ্ট স্ক্রিপ্ট অনুসরণ করার পরিবর্তে লক্ষ্যগুলোকে ছোট ছোট ভাগে ভাগ করে এবং কাজের সময়সূচী নির্ধারণ করে।
সফল দলগুলো আসলে কোন বিষয়গুলোতে মনোযোগ দেয়
আমি লক্ষ্য করেছি যে, উচ্চ-দক্ষতাসম্পন্ন ইঞ্জিনিয়ারিং গ্রুপগুলো নতুন মডেল রিলিজের পেছনে না ছুটে তিনটি ডিজাইনের মূল স্তম্ভের ওপর জোর দেয়:
টুল ডিজাইন (Tool design)
এজেন্টরা সুসংজ্ঞায়িত ইন্টারফেসের মাধ্যমে এক্সটার্নাল সার্ভিসগুলোর সাথে যোগাযোগ করে। একটি পরিষ্কার API সারফেস এজেন্টের জন্য ইনপুট, আউটপুট এবং এরর কোড নিয়ে কাজ করা সহজ করে তোলে। ফ্রেমওয়ার্কের পছন্দ—LangChain, CrewAI, বা নিজস্ব কোনো লাইব্রেরি—তার চেয়ে বেশি গুরুত্বপূর্ণ হলো ডিটারমিনিস্টিক (deterministic) এবং ভার্সনড এন্ডপয়েন্ট (versioned endpoints) প্রকাশ করার শৃঙ্খলা।
ফেইলিওর হ্যান্ডলিং (Failure handling)
প্রতিটি এক্সটার্নাল কল ব্যর্থ হতে পারে। একটি এজেন্টের অবশ্যই টাইমআউট, রিট্রাই, সার্কিট-ব্রেকিং এবং ফলব্যাক স্ট্র্যাটেজির জন্য নীতিমালা থাকতে হবে। এগুলো ছাড়া, একটি ছোট সমস্যাও পুরো কথোপকথনকে একটি ডেড-এন্ডে পরিণত করতে পারে, যা সিস্টেমের সমস্যার চেয়ে মডেলের সীমাবদ্ধতা হিসেবে বেশি প্রতীয়মান হয়।
অবজারভেবিলিটি (Observability)
যখন একটি এজেন্ট কোনো সিদ্ধান্ত নেয়, তখন ডেভেলপারদের এমন একটি ট্রেস (trace) প্রয়োজন যা রিজনিং স্টেপ, কল করা টুল এবং ফলাফল প্রদর্শন করে। স্ট্রাকচার্ড লগ বা ইভেন্ট স্ট্রিম অপারেটরদের একটি সেশন পুনরায় প্লে করতে, ভুল উত্তরের উৎস খুঁজে বের করতে এবং প্রম্পটিং বা টুল কনফিগারেশন উন্নত করতে সাহায্য করে।
যে প্যাটার্নগুলো যেকোনো ফ্রেমওয়ার্কের চেয়ে বেশি টিকে থাকে
ফ্রেমওয়ার্কগুলো দ্রুত পরিবর্তিত হয়—LangChain এবং CrewAI প্রায় প্রতি মাসেই ব্রেকিং চেঞ্জেস (breaking changes) রিলিজ করে। এই বিশ্লেষণটি যুক্তি দেয় যে, লাইব্রেরির পরিবর্তে প্যাটার্নের ওপর মনোযোগ দেওয়া উচিত। নিচে এমন কিছু পুনরাবৃত্তিমূলক কাঠামো দেওয়া হলো যা ভার্সন আপগ্রেডের পরেও টিকে থাকে:
পরিকল্পনা তারপর বাস্তবায়ন (Plan-then-execute) রিজনিং পর্যায় (যেমন, "আমার পরবর্তী পদক্ষেপ কী হওয়া উচিত?") এবং অ্যাকশন পর্যায় (যেমন, "billing API কল করো") আলাদা করুন। এটি প্রম্পটের দৈর্ঘ্য কমায় এবং মডেলের আউটপুটকে ডিটারমিনিস্টিক রাখে।
রিজনিং থেকে রিট্রিভালকে আলাদা করা (Separate retrieval from reasoning) কনটেক্সট সংগ্রহ করা (যেমন, নলেজ বেস সার্চ করা বা ডকুমেন্ট লোড করা) একটি ভিন্ন কাজ, যা সেই কনটেক্সট ব্যবহার করে প্রশ্নের উত্তর দেওয়ার কাজ থেকে আলাদা। এই দুটিকে মিশ্রিত করলে প্রম্পটের আকার বেড়ে যায় এবং ব্যর্থতা শনাক্ত করা কঠিন হয়ে পড়ে।
স্পষ্ট হ্যান্ডঅফ (Explicit handoffs) যখন একটি এজেন্ট অন্য একটি এজেন্টের কাছে কাজ হস্তান্তর করে—ধরা যাক, একজন প্ল্যানার একজন ডেটা-ফেচারকে একটি সাবটাস্ক দিচ্ছে—তখন একটি স্ট্রাকচার্ড হ্যান্ডঅফ ফরম্যাট (JSON বা একটি নির্দিষ্ট স্কিমা) ব্যবহার করুন। গ্রহণকারী এজেন্ট কাজ করার আগে পেলোডটি যাচাই করতে পারে, যা সিস্টেমের স্থায়িত্ব বৃদ্ধি করে।
একটি সাধারণ ভুল: RAG চাঙ্কিং
রিট্রিভাল-অগমেন্টেড জেনারেশন (RAG) সিস্টেমগুলোতে উত্তরগুলো যখন অপ্রাসঙ্গিক হয়, তখন প্রায়ই ল্যাঙ্গুয়েজ মডেলকে দোষারোপ করা হয়। কিন্তু এই বিশ্লেষণটি বলছে যে, আসল অপরাধী প্রায়ই হলো চাঙ্কিং স্ট্র্যাটেজি (chunking strategy)। একটি ডকুমেন্টকে এমনভাবে ছোট ছোট অংশে ভাগ করা যা বাক্যকে মাঝপথে কেটে ফেলে বা অর্থগত সীমানা (semantic boundaries) হারিয়ে ফেলে, তা মডেলকে প্রয়োজনীয় কনটেক্সট থেকে বঞ্চিত করে। মেটাডেটা ট্যাগ, ওভারল্যাপ উইন্ডো এবং চাঙ্ক সাইজ ঠিক করে ফেললে মডেল পরিবর্তন না করেই পারফরম্যান্স পুনরুদ্ধার করা সম্ভব।
মূল কথা
আপনি যদি এমন একটি AI সিস্টেম তৈরি করেন যা নিজে থেকে কাজ করার ক্ষমতা রাখে, তবে LinkedIn-এ ডেমোটি দেখতে কতটা চাকচিক্যময় তা দিয়ে সাফল্য পরিমাপ করা বন্ধ করুন। নিশ্চিত করুন যে আপনার কোড লক্ষ্যগুলোকে উপ-কাজে বিভক্ত করতে পারে, টুল ফেইলিওর মোকাবিলা করতে পারে এবং ডিবাগিংয়ের জন্য একটি স্পষ্ট পথ (breadcrumb trail) রেখে যায়। এই তিনটি ইঞ্জিনিয়ারিং অভ্যাস—সুচিন্তিত টুল ডিজাইন, সুশৃঙ্খল ফেইলিওর হ্যান্ডলিং এবং ফুল-স্ট্যাক অবজারভেবিলিটি—একটি চাকচিক্যময় প্রোটোটাইপকে একটি নির্ভরযোগ্য এজেন্টে রূপান্তরিত করে।