আপনার এজেন্টের ডেমো কাজ করে। আপনার এজেন্ট কাজ করে না।
বেশিরভাগ এজেন্ট আর্কিটেকচার বাস্তব কাজে ব্যর্থ হয়।
একটি ডেমো একটি মাত্র কাজ এবং দ্রুত রেসপন্সের ক্ষেত্রে ভালো দেখায়। বাস্তব কাজ বলতে ইন্স্যুরেন্স ক্লেইম, সেলস সিকোয়েন্স বা ডেটা রিকনসিলিয়েশন বোঝায়। এই কাজগুলোতে অনেক সময় এবং অনেকগুলো ধাপ প্রয়োজন হয়।
সমস্যাটি হলো স্টেটলেসনেস (statelessness)। বেশিরভাগ এজেন্ট প্রতিবার ইন্টারঅ্যাক্ট করার সময় শূন্য থেকে কনটেক্সট তৈরি করে। তারা রিজনিং চেইন (reasoning chain) এবং কাজের অগ্রগতি হারিয়ে ফেলে। এর ফলে আপনি এমন একটি ভদ্র AI পান যা পরিস্থিতি জানার ভান করে।
Google Cloud বিশেষজ্ঞ Addy Osmani এবং Shubham Saboo এটি সমাধানের জন্য পাঁচটি প্যাটার্ন শেয়ার করেছেন। নিচে তার বিস্তারিত দেওয়া হলো:
Checkpoint-and-Resume আপনার এজেন্টকে একটি সার্ভারের মতো বিবেচনা করুন। কাজের প্রতি কয়েকটি ধাপ পর পর প্রগ্রেস সেভ করুন। যদি একটি এজেন্ট ১,০০০টি কাজের মধ্যে ২০১ নম্বর ধাপে ব্যর্থ হয়, তবে এটি ২০১ নম্বর ধাপ থেকে পুনরায় শুরু করবে। শূন্য থেকে শুরু করবেন না।
Delegated Approval মানুষের অনুমোদনের জন্য Slack বা ইমেল ব্যবহার করা বন্ধ করুন। এই টুলগুলো কনটেক্সট নষ্ট করে দেয়। এজেন্টকে সেই মুহূর্তেই থামিয়ে দিন। সম্পূর্ণ স্টেট (state) অক্ষত রাখুন যাতে একজন মানুষ রেসপন্স করার সাথে সাথে এটি তাৎক্ষণিকভাবে পুনরায় শুরু করতে পারে। রিকোয়েস্ট এবং এররগুলোর জন্য একটি স্ট্রাকচার্ড ইনবক্স ব্যবহার করুন।
Memory-Layered Context ওয়ার্কিং মেমরি থেকে লং-টার্ম মেমরিকে আলাদা করুন। লং-টার্ম মেমরি বিভিন্ন সেশনের জ্ঞান সংরক্ষণ করে। ওয়ার্কিং মেমরি বর্তমান কাজটি পরিচালনা করে। আপনাকে মেমরি ড্রিফট (memory drift) প্রতিরোধ করতে হবে, যেখানে এজেন্টরা এজ কেস (edge cases) থেকে খারাপ অভ্যাস শিখে ফেলে। খারাপ ডেটা ব্লক করতে আইডেন্টিটি ম্যানেজমেন্ট এবং একটি গভর্নেন্স লেয়ার ব্যবহার করুন।
Ambient Processing এমন এজেন্ট তৈরি করুন যা সাপোর্ট টিকিট বা ডেটাবেস পরিবর্তনের মতো ডেটা স্ট্রিমগুলো পর্যবেক্ষণ করে। এজেন্টের ভেতরে সরাসরি রুলস হার্ডকোড করবেন না। রুলসগুলোকে একটি এক্সটার্নাল গভর্নেন্স লেয়ারে রাখুন। এভাবে, আপনি এক জায়গায় রুলস আপডেট করলে পুরো ফ্লিট (fleet) তা অনুসরণ করবে।
Fleet Orchestration স্পেশালিস্ট এজেন্টদের পরিচালনা করতে একটি কোঅর্ডিনেটর এজেন্ট ব্যবহার করুন। প্রতিটি স্পেশালিস্টের নিজস্ব টুলস এবং আইডেন্টিটি রয়েছে। এটি ডিস্ট্রিবিউটেড সিস্টেমে ব্যবহৃত ওয়ার্কার প্যাটার্ন অনুসরণ করে। পুরো সিস্টেম নষ্ট না করেই আপনি একটি স্পেশালিস্টকে আপডেট করতে পারেন।
সবচেয়ে বড় ঝুঁকি হলো মেমরি ড্রিফট।
মানুষ প্রম্পটের দিকে মনোযোগ দেয় কিন্তু সময়ের সাথে সাথে এজেন্টের আচরণ কীভাবে পরিবর্তিত হয় তা উপেক্ষা করে। যদি একটি এজেন্ট খারাপ বা অদ্ভুত ইন্টারঅ্যাকশন থেকে কিছু শেখে, তবে এটি আপনার লেখা কোডের মতো আচরণ করা বন্ধ করে দেয়।
আপনাকে এজেন্টদের মাইক্রোসার্ভিসের মতো বিবেচনা করতে হবে। তাদের আইডেন্টিটি, একটি রেজিস্ট্রি এবং কঠোর পলিসি এনফোর্সমেন্ট প্রয়োজন।
নিজেকে প্রশ্ন করুন: আমার এজেন্টকে থামানো ছাড়াই সবচেয়ে দীর্ঘতম কোন কাজটি করতে হবে? যদি উত্তরটি কয়েক ঘণ্টা বা কয়েক দিন হয়, তবে আপনার এই প্যাটার্নগুলো প্রয়োজন।
আপনার এজেন্টের ডেমো কাজ করে, কিন্তু আপনার এজেন্ট কাজ করে না
আপনি আপনার এজেন্টটিকে নিখুঁত করতে সপ্তাহ পার করেছেন। আপনি প্রম্পটগুলো টিউন করেছেন, সঠিক টুলগুলো নির্বাচন করেছেন এবং হাতে বেছে নেওয়া কিছু কুয়েরি দিয়ে এটি পরীক্ষা করেছেন। আপনার লোকাল এনভায়রনমেন্টে এটি একজন জিনিয়াস। এটি জটিল কাজ সমাধান করে, নিখুঁতভাবে টুল কল করে এবং নির্দেশাবলী অক্ষরে অক্ষরে পালন করে।
তারপর, আপনি এটি ডেপ্লয় করেন।
হঠাৎ করেই এজেন্টটি হ্যালুসিনেশন (hallucinating) করতে শুরু করে। এটি ইনফিনিট লুপে (infinite loops) আটকে যায়। এটি ভুল আর্গুমেন্ট দিয়ে টুল কল করে। পরীক্ষার সময় যে কাজগুলো খুব সহজ মনে হয়েছিল, সেগুলো এখন ব্যর্থ হচ্ছে।
এই ব্যবধান কেন?
ডেমোর ফাঁদ
আমরা যখন ডেমো তৈরি করি, আমরা অবচেতনভাবে সেগুলোকে "হ্যাপি পাথ" (happy path)-এর জন্য ডিজাইন করি। আমরা এজেন্টকে নিখুঁত কনটেক্সট, সবচেয়ে নির্ভরযোগ্য টুল এবং এমন সব কুয়েরি প্রদান করি যা আমরা জানি সে হ্যান্ডেল করতে পারবে। আমরা মূলত এজেন্টের সফল হওয়ার ক্ষমতা পরীক্ষা করছি, ব্যর্থতা মোকাবিলা করার ক্ষমতা নয়।
১. এরর হ্যান্ডলিং (Error Handling) একটি afterthought হিসেবে বিবেচিত হয়
ডেমোতে, যদি একটি টুল এরর (error) প্রদান করে, আমরা হয়তো সেশনটি পুনরায় শুরু করি বা প্রম্পটটি কিছুটা পরিবর্তন করি। প্রোডাকশনে, একটি এরর হলো একটি বাস্তব ঘটনা।
- টুল ফেইলিওর (Tool Failures): একটি API ডাউন থাকলে কী হবে?
- ম্যালফর্মড আউটপুট (Malformed Output): যদি LLM এমন JSON রিটার্ন করে যা পুরোপুরি সঠিক নয়?
- অপ্রত্যাশিত ইনপুট (Unexpected Input): যদি ব্যবহারকারী এমন কিছু জিজ্ঞাসা করেন যা সীমার বাইরে?
প্রোডাকশন-রেডি এজেন্টের জন্য শক্তিশালী এরর-হ্যান্ডলিং লজিক প্রয়োজন। এর জানা উচিত কীভাবে:
- একটি ব্যর্থ টুল কল পুনরায় চেষ্টা (retry) করতে হয়।
- ব্যবহারকারীর কাছে স্পষ্টীকরণ (clarification) চাইতে হয়।
- কোনো টুল অনুপলব্ধ থাকলে মার্জিতভাবে (gracefully) কাজ চালিয়ে যেতে হয়।
২. টুলের নির্ভরযোগ্যতার বিভ্রম
আমরা ধরে নিই আমাদের টুলগুলো সবসময় প্রত্যাশা অনুযায়ী কাজ করবে। আমরা এমন কোড লিখি যেখানে ধরে নেওয়া হয় API সবসময় 200 OK রিটার্ন করবে।
বাস্তবে, টুলগুলো অগোছালো। সেগুলোর ল্যাটেন্সি (latency) আছে, রেট লিমিট (rate limits) আছে এবং বাগ (bugs) আছে। একটি এজেন্ট যা টুলের ল্যাটেন্সি বা রেট লিমিটিংয়ের কথা মাথায় রাখে না, সেটি প্রোডাকশনে ব্যর্থ হবে।
৩. কনটেক্সট এবং মেমরি ম্যানেজমেন্ট
ডেমোগুলো সাধারণত ছোট হয়। কনটেক্সট উইন্ডো পরিষ্কার থাকে।
প্রোডাকশনে, ব্যবহারকারীদের দীর্ঘ এবং জটিল কথোপকথন থাকে। কনটেক্সট উইন্ডো পূর্ণ হয়ে যায়। এজেন্ট তার মূল লক্ষ্য হারিয়ে ফেলতে শুরু করে। এটি পুরনো তথ্যের ভিত্তিতে হ্যালুসিনেশন করতে শুরু করে।
স্টেট (state) ম্যানেজ করা এবং হিস্ট্রি সামারাইজ করা কেবল একটি "nice-to-have" ফিচার নয়; এটি প্রোডাকশন এজেন্টের জন্য একটি মূল প্রয়োজনীয়তা।
কীভাবে এই ব্যবধান কমিয়ে আনা যায়?
- সফলতার বদলে ব্যর্থতার জন্য পরীক্ষা করুন: আপনার এজেন্টকে ভেঙে ফেলার চেষ্টা করুন। অ্যাডভারসারিয়াল ইনপুট (adversarial inputs) ব্যবহার করুন।
- শক্তিশালী এরর হ্যান্ডলিং ইমপ্লিমেন্ট করুন: প্রতিটি টুল কলকে একটি সম্ভাব্য ব্যর্থতার বিন্দু হিসেবে বিবেচনা করুন।
- সবকিছু মনিটর করুন: টুল কল, LLM ইনপুট/আউটপুট এবং এজেন্টের রিজনিং স্টেপগুলো লগ (log) করুন।
- আপনার এজেন্টে অবজারভেবিলিটি (observability) তৈরি করুন: আপনি যা দেখতে পাবেন না, তা আপনি ঠিক করতে পারবেন না।