Agentic AI ROI-এর নীরব ঘাতক
আপনার Kubernetes pods গুলো সবুজ (green) দেখাচ্ছে। আপনার API latency কম। আপনার LLM provider ৯৯.৯% uptime দেখাচ্ছে।
তবুও, আপনার স্বয়ংক্রিয় লোন সিস্টেমটি মাত্র তিন ঘণ্টায় তার পুরো মাসের API বাজেট শেষ করে ফেলেছে। দুটি এজেন্ট একটি লুপে আটকে গেছে।
এটি হলো "Healthy but Hallucinating" প্যারাডক্স।
প্রথাগত সফটওয়্যারের ক্ষেত্রে, একটি সিস্টেম হয় সচল (up) থাকে অথবা অচল (down) থাকে। কিন্তু একটি agentic mesh-এ, একটি সিস্টেম দেখতে সুস্থ মনে হলেও পুরোপুরি ব্যর্থ হতে পারে। আপনি যদি এজেন্টদের জন্য প্রথাগত Site Reliability Engineering (SRE) ব্যবহার করেন, তবে আপনি ভুল সংকেত (signals) মনিটর করছেন। আপনি এমন একজন রোগীর হার্টবিট মাপছেন যিনি কার্যত মস্তিস্ক মৃত (brain-dead)।
কেন প্রথাগত অবকাঠামো (infrastructure) agentic collapse প্রতিরোধ করতে ব্যর্থ হয়?
প্রথাগত SRE তৈরি করা হয়েছে deterministic সিস্টেমের জন্য। যখন কোনো সার্ভিস ব্যর্থ হয়, তখন এটি একটি error দেয়। এটি বাইনারি (binary)। এজেন্টগুলোর ব্যর্থতা ভিন্ন। একটি এজেন্ট ক্র্যাশ করে না; এটি বিচ্যুত (drift) হয়। এটি টাইম-আউট হয় না; বরং এটি এমন একটি প্যারামিটার হ্যালুসিনেশন করে যা কয়েক ধাপ পরে একটি নীরব ব্যর্থতা (silent failure) ঘটায়।
সিঙ্গেল বট থেকে এন্টারপ্রাইজ এজেন্ট ফ্যাব্রিক (enterprise agent fabrics)-এ উত্তরণের সময় আমরা এই ব্যবধানটি দেখতে পাই। একটি টিম একটি বেঞ্চমার্কে ৯৫% নির্ভুলতা (accuracy) রিপোর্ট করে, কিন্তু প্রোডাকশনে সিস্টেমটি ব্যর্থ হয়। বেঞ্চমার্কগুলো পরিমাপ করে যে একটি মডেল কোনো প্রশ্নের উত্তর দিতে পারে কি না। কিন্তু চারটি এজেন্ট জড়িত একটি ১২-ধাপের ওয়ার্কফ্লোতে একটি সিস্টেম স্টেট (state) বজায় রাখতে পারে কি না, তা তারা পরিমাপ করে না।
আপনার প্রয়োজন Agent Reliability Engineering (ARE)।
প্রথাগত SRE বাইনারি স্টেট পরিচালনা করে। ARE পরিচালনা করে probability distributions। আপনি যদি কেবল CPU এবং memory ট্র্যাক করেন, তবে আপনি এজেন্টগুলোর ব্যর্থতা সম্পর্কে অন্ধ থাকবেন।
মাল্টি-এজেন্ট সিস্টেমের ত্রুটিগুলো কেবল যোগ হয় না, বরং সেগুলো গুণিতক হারে বৃদ্ধি পায়। যেহেতু এজেন্টরা অন্য এজেন্টদের আউটপুটকে সত্য হিসেবে ব্যবহার করে, তাই প্রথম ধাপে একটি ছোট ভুল পঞ্চম ধাপের মধ্যে একটি বিপর্যয়ে পরিণত হয়।
সাধারণ ব্যর্থতার ধরনগুলোর মধ্যে রয়েছে:
- Agentic infinite loops
- State drift
- Prompt injection cascades
- Tool-call hallucinations
একটি বিপজ্জনক উদাহরণ: একটি এজেন্ট একটি আপডেট টুল কল করে। এটি এমন একটি প্যারামিটার উদ্ভাবন করে যার কোনো অস্তিত্ব নেই। API অতিরিক্ত প্যারামিটারটি উপেক্ষা করে এবং একটি 200 OK রিটার্ন করে। এজেন্ট মনে করে এটি সফল হয়েছে, কিন্তু বিজনেস লজিকটি নীরবে ব্যর্থ হয়েছে।
ARE "intent-action-outcome" লুপের ওপর গুরুত্ব দেয়। আপনি কেবল এটি মনিটর করেন না যে একটি এজেন্ট কোনো টুল কল করেছে কি না; বরং আপনি মনিটর করেন যে সেই কলটি মূল উদ্দেশ্যের (intent) সাথে মিলেছে কি না এবং ফলাফলটি লক্ষ্য অর্জনে সক্ষম হয়েছে কি না।
Agent Reliability Engineer (ARE) পদের দায়িত্বগুলো হলো:
- Intent Analysis: এজেন্ট কখন লক্ষ্য থেকে বিচ্যুত হচ্ছে তা শনাক্ত করা।
- Guardrail Tuning: লুপ বন্ধ করতে সীমাবদ্ধতা (constraints) সমন্বয় করা।
- Dependability Mapping: কখন একজন এজেন্টের কাজ মানুষের কাছে হস্তান্তর করতে হবে তা নির্ধারণ করা।
- Audit Architecture: অভ্যন্তরীণ যুক্তি (reasoning) এবং স্টেট পরিবর্তনগুলো ক্যাপচার করা।
নির্ভুলতা (accuracy) নিয়ে কথা বলা বন্ধ করুন। সিস্টেমের নির্ভরযোগ্যতা (System Dependability) নিয়ে কথা বলা শুরু করুন।
আপনি মানুষের হস্তক্ষেপের (human intervention) খরচ পরিমাপ করে একজন CFO-এর কাছে এটি যৌক্তিক প্রমাণ করতে পারেন। প্রতিবার যখন একজন মানুষ একটি এজেন্টের ভুল সংশোধন করেন, সেটি একটি রিলায়েবিলিটি ফেইলর বা নির্ভরযোগ্যতার ব্যর্থতা। সেই ঘণ্টাগুলোকে আপনার বিশেষজ্ঞদের বেতনের সাথে গুণ করুন। তখন অনির্ভরযোগ্যতার খরচ স্পষ্ট হয়ে উঠবে।
Agentic Error Budgets ব্যবহার করুন। একটি সাধারণ ইমেল সামারাইজারের জন্য আপনার এরর বাজেট (error budget) বেশি হতে পারে। কিন্তু যে সিস্টেম ১০ মিলিয়ন ডলার স্থানান্তর করে, তার জন্য এরর বাজেট শূন্য।
AI-কে কেবল একটি সফটওয়্যার ফিচার হিসেবে গণ্য করবেন না। এটিকে একটি সিস্টেমিক রিস্ক (systemic risk) হিসেবে বিবেচনা করুন। এই যুগের বিজয়ীরা সবচেয়ে স্মার্ট মডেলের অধিকারী হবে না; বরং তাদের কাছে থাকবে সবচেয়ে নির্ভরযোগ্য সিস্টেম।
Optional learning community: https://t.me/GyaanSetuAi