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

বেশিরভাগ ইঞ্জিনিয়ারিং টিম এখনও AI এজেন্টদের মূল্যায়ন করে ঠিক সেভাবেই যেভাবে তারা গণিতের হোমওয়ার্ক গ্রেড করে। তারা কেবল চূড়ান্ত আউটপুট দেখে। যদি উত্তরটি সঠিক হয়, তবে তারা রিলিজের অনুমতি দেয় এবং এগিয়ে যায়। এটি একটি বিপজ্জনক শর্টকাট। একটি সঠিক উত্তর একটি গভীরভাবে ত্রুটিপূর্ণ সিস্টেমকে লুকিয়ে রাখতে পারে।

আসল গল্পটি লুকিয়ে থাকে সেই পথে যা অনুসরণ করে এজেন্ট সেখানে পৌঁছায়। সেই পথটিকে বলা হয় agent trajectory। এতে প্রতিটি tool call, প্রতিটি routing decision এবং প্রতিটি বিরতি অন্তর্ভুক্ত থাকে যেখানে এজেন্ট পুনরায় চিন্তা করার জন্য থামে। আপনি এটিকে এজেন্টের ফেলে যাওয়া রুটির টুকরোর চিহ্নের (trail of breadcrumbs) মতো ভাবতে পারেন। আর আপনি যদি কেবল গন্তব্য পরীক্ষা করেন, তবে পথের মাঝে ছড়িয়ে থাকা সমস্ত সতর্ক সংকেতগুলো মিস করবেন।

অগোছালো পথের সমস্যা

একটি এজেন্ট একজন মাতাল চালকের মতো আচরণ করেও সঠিক উত্তরে পৌঁছাতে পারে। এটি ভুল tool ব্যবহার করে দিক পরিবর্তন করে, রাউটারে ফিরে আসে এবং অবশেষে কোনো একটি সঠিক উত্তরে পৌঁছানোর আগে বারবার redundant reasoning দিয়ে ঘুরপাক খেতে থাকে। ব্যবহারকারী একটি পরিষ্কার ফলাফল দেখেন। কিন্তু পর্দার আড়ালে, সিস্টেমটি প্রচুর রিসোর্স নষ্ট করছে এবং ঝুঁকি বাড়িয়ে তুলছে।

বাস্তবে এই বিশৃঙ্খলা দেখতে আসলে কেমন?

প্রথমত, রয়েছে redundant tool call। এজেন্ট আপনার কাস্টমার ডাটাবেস থেকে তথ্য নেয়, ফলাফল পায়, পাঁচ সেকেন্ড পরে তা ভুলে যায় এবং একই প্যারামিটার দিয়ে আবার সেই একই রেকর্ডটি অনুসন্ধান করে। এটি কোনো ডেটা সমস্যা নয়। এটি একটি trajectory সমস্যা। এজেন্ট তার state ধরে রাখতে ব্যর্থ হয়েছে, তাই এটি একই কাজ বারবার করছে।

এরপর রয়েছে wrong-tool-first প্যাটার্ন। একটি coding agent হয়তো এমন একটি function definition-এর জন্য ওয়েবে সার্চ করার চেষ্টা করতে পারে যা ইতিমধ্যে লোকাল রিপোজিটরিতে রয়েছে। অথবা একটি support agent billing API ব্যবহার করার চেষ্টা করতে পারে যখন ব্যবহারকারীর প্রশ্নের জন্য স্পষ্টতই account settings tool প্রয়োজন। প্রতিটি ভুল সিদ্ধান্ত টোকেন খরচ করে, latency বাড়ায় এবং আসল কাজ শুরু হওয়ার আগেই context limit অতিক্রম করার সম্ভাবনা বাড়িয়ে দেয়।

Router loops হলো আরেকটি রেড ফ্ল্যাগ। decision node কোনো সিদ্ধান্তে পৌঁছাতে পারে না। এটি টাস্কটি branch A-তে পাঠায়, তারপর সিদ্ধান্ত পরিবর্তন করে তা ফিরিয়ে নেয়, branch B-তে পাঠায় এবং কোনো কারণ ছাড়াই একটি general-purpose fallback node-এর মাধ্যমে রাউট করে। প্রতিটি লুপ একটি নেটওয়ার্ক হপ (network hop) যোগ করে এবং শেষ পর্যন্ত debug log-এ বিভ্রান্তির একটি নতুন স্তর তৈরি করে।

সবশেষে রয়েছে repeated analysis। এজেন্ট কোনো সিদ্ধান্তকে চূড়ান্ত হিসেবে না মেনে প্রতিটি ধাপে বারবার একই সিদ্ধান্তে পৌঁছানোর চেষ্টা করে। এটি অনেকটা একজন কাঠমিস্ত্রির মতো যে প্রতিটি কাটার আগে বোর্ডটি দশবার পরিমাপ করে। প্রথম পরিমাপটি ঠিক ছিল, কিন্তু পরের নয়টি পরিমাপই ছিল সময়ের অপচয়।

এই অতিরিক্ত ধাপগুলোর বাস্তব পরিণতি রয়েছে। Latency ক্রমাগত বাড়তে থাকে। একটি synchronous chat interface-এ অতিরিক্ত তিন সেকেন্ড যেন এক অনন্তকাল মনে হয়। বড় পরিসরে (at scale), এই কয়েক সেকেন্ড কম্পিউট খরচে হাজার হাজার ডলারের অপচয় ঘটায়। ব্যর্থতার ঝুঁকিও বৃদ্ধি পায়। প্রতিটি অপ্রয়োজনীয় হপ (hop) একটি এক্সটার্নাল API টাইম-আউট হওয়া, context window ওভারফ্লো হওয়া বা race condition দেখা দেওয়ার সুযোগ তৈরি করে। আর যখন কিছু ভেঙে পড়ে, তখন স্প্যাগেটির মতো দেখতে একটি trace ডিবাগ করা সত্যিই কঠিন। আপনি ঘণ্টার পর ঘণ্টা সময় ব্যয় করবেন কেন এজেন্ট সপ্তম ধাপটি নিল তা পুনর্গঠন করতে, শুধু এটি বুঝতে যে সপ্তম ধাপটির প্রয়োজনই ছিল না।

Convergence আসলে কী বোঝায়

যদি trajectory হয় পথ, তবে convergence হলো তার দক্ষতার পরিমাপ। Convergence আপনাকে বলে দেয় যে ব্যবহারকারীর অনুরোধ এবং সঠিক সমাধানের মধ্যে এজেন্ট কতটা নিখুঁতভাবে সংক্ষিপ্ততম সম্ভাব্য পথটি অনুসরণ করছে।

এটি accuracy-র মতো নয়। Accuracy হলো একটি স্থূল মাপকাঠি। এটি কেবল জিজ্ঞাসা করে যে চূড়ান্ত অবস্থাটি সঠিক কি না। Convergence জিজ্ঞাসা করে যে যাত্রাটি যুক্তিসঙ্গত ছিল কি না। উচ্চ accuracy কিন্তু নিম্ন convergence সম্পন্ন একটি এজেন্ট হলো সাফল্যের ছদ্মবেশে থাকা একটি বোঝা (liability)। উচ্চ convergence কিন্তু মাঝারি accuracy সম্পন্ন একটি এজেন্ট সাধারণত ঠিক করা সহজ হয়, কারণ এর reasoning পরিষ্কার এবং এর ভুলগুলো নির্দিষ্ট সীমার মধ্যে থাকে।

আপনি এজেন্টের নেওয়া প্রকৃত ধাপগুলোর সাথে সেই টাস্ক ক্লাসের জন্য আপনার নির্ধারিত সংক্ষিপ্ততম পথের তুলনা করে একটি আনুমানিক convergence score গণনা করতে পারেন। যদি একটি স্ট্যান্ডার্ড refund query-র জন্য ঠিক তিনটি tool call প্রয়োজন হয় এবং এজেন্ট নয়টি ব্যবহার করে, তবে আপনার convergence ratio কমে যাচ্ছে। আপনি বিভিন্ন ধরণের অপচয়কে গুরুত্ব (weighting) দিয়ে এটিকে আরও নিখুঁত করতে পারেন। টুলের latency এবং মূল্যের ওপর ভিত্তি করে একটি ভুল tool call একটি redundant call-এর চেয়ে বেশি খরচ করতে পারে। একটি router loop যা কোনো ভ্যালু যোগ করে না, তার জন্য সবচেয়ে বড় পেনাল্টি থাকতে পারে, কারণ এটি আর্কিটেকচারাল