নতুন মডেল বেঞ্চমার্ক চালানো বন্ধ করুন এবং আপনার এজেন্ট কীভাবে একটি সাবস্ক্রিপশন বাতিল করার চেষ্টা করছে তা দেখা শুরু করুন। এই দুটি কাজের মধ্যবর্তী ব্যবধানেই প্রোডাকশন সিস্টেমগুলো ব্যর্থ হয়। একটি সিঙ্গেল-টার্ন টেস্ট আপনাকে বলতে পারে যে একটি রেসপন্স শুনতে মনোরম কি না। কিন্তু এটি আপনাকে বলতে পারবে না যে এজেন্ট ভুল গ্রাহককে রিফান্ড করেছে কি না, ক্যালেন্ডার API-তে চৌদ্দবার লুপ করেছে কি না, অথবা ফ্রড চেক পুরোপুরি এড়িয়ে যাওয়ার সিদ্ধান্ত নিয়েছে কি না। টেক্সট হলো এজেন্টের তৈরি করা সবচেয়ে কম বিপজ্জনক জিনিস। আসল ঝুঁকিগুলো লুকিয়ে থাকে সেই টুলগুলোর মধ্যে যা এটি ব্যবহার করে, সেই ডেটার মধ্যে যা এটি পরিবর্তন করে, এবং সেই মুহূর্তগুলোতে যখন এর সাহায্য চাওয়া উচিত ছিল কিন্তু এটি কাজ চালিয়ে গেছে।
কেন প্রোডাকশনে টেক্সট বেঞ্চমার্ক ব্যর্থ হয়
স্ট্যান্ডার্ড বেঞ্চমার্কে উচ্চ স্কোর পাওয়া এখন একটি বিভ্রান্তিকর স্বস্তির কারণ হয়ে দাঁড়িয়েছে। একটি এজেন্ট যে চমৎকার গদ্য লিখতে পারে, সেটিও অপারেশনাল ঝুঁকির কারণ হতে পারে। যখন আপনার সিস্টেম অ্যাপয়েন্টমেন্ট বুক করে, ডাটাবেস রেকর্ড এডিট করে বা সাপোর্ট টিকিট ফাইল করে, তখন জেনারেট করা টেক্সটটি ওয়ার্কফ্লোর কেবল দৃশ্যমান অংশ মাত্র। এর গভীরে, এজেন্ট কোন এন্ডপয়েন্ট ব্যবহার করবে, কী পেলোড পাঠাবে এবং কখন থামবে সে সম্পর্কে সুনির্দিষ্ট সিদ্ধান্ত নিচ্ছে। এটি রিডিং-কমপ্রিহেনশন লিডারবোর্ডে শীর্ষে থাকতে পারে, অথচ রিসোর্স ডাবল-বুকিং করে, ভুল রো (row) পরিবর্তন করে বা লগ ফাইলে সেনসিটিভ স্টেট ফাঁস করে আপনার আর্থিক ক্ষতি করতে পারে। আপনার কাজের মেকানিক্স যাচাই করা প্রয়োজন, কেবল আউটপুটের চাকচিক্য নয়। যদি একটি এজেন্ট অফলাইন QA টেস্টে ভালো স্কোর করেও লুপ করা বা কোনো টুল ভুলভাবে ব্যবহারের মাধ্যমে আপনার ওয়ার্কফ্লোতে ব্যর্থ হয়, তবে বুঝতে হবে আপনার মূল্যায়ন ভুল সংকেতের দিকে নজর দিচ্ছে।
পাঁচটি ডিপেন্ডেন্সি ম্যাপ করা
Van Data Team-এর টিম প্রতিটি মূল্যায়ন শুরু করে পাঁচটি নির্দিষ্ট কন্ট্রোল পয়েন্ট ম্যাপ করার মাধ্যমে। এটি প্রশ্নটি সম্পূর্ণ বদলে দেয়। আপনি আর এটা জিজ্ঞেস করেন না যে একটি মডেল অন্যটির চেয়ে বেশি বুদ্ধিমান কি না। আপনি জিজ্ঞেস করতে শুরু করেন যে এজেন্ট আপনার বাস্তব সীমাবদ্ধতার মধ্যে একটি প্রোডাকশন টাস্ক আসলে শেষ করতে পারে কি না।
বিজনেস আউটকাম (Business outcomes)। ডলার এবং গ্রাহকের ওপর প্রভাবের ভিত্তিতে "সম্পন্ন" (done) হওয়ার অর্থ কী তা সংজ্ঞায়িত করুন। এজেন্ট একটি সামারি প্রদান করেছে বলেই একটি টাস্ক সম্পন্ন হয়েছে বলে ধরে নেওয়া যাবে না। এটি তখনই সম্পন্ন হয় যখন ইনভেন্টরি রেকর্ড সঠিক হয়, অ্যাপয়েন্টমেন্ট নিশ্চিত হয় এবং গ্রাহক একটি বৈধ ট্র্যাকিং নম্বর পান।
মিউটেবল স্টেট (Mutable state)। এজেন্ট ঠিক কী পরিবর্তন করার অনুমতি পায় তা জানুন। কোন টেবিল, কোন স্ট্যাটাস, কোন অ্যাকাউন্ট ফ্ল্যাগ? যদি এজেন্ট রিফান্ড দিতে পারে, জব রিস্কডিউল করতে পারে বা বিলিং অ্যাড্রেস আপডেট করতে পারে, তবে এটি যে প্রতিটি ফিল্ড স্পর্শ করে তার একটি তালিকা আপনার প্রয়োজন।
টুল পারমিশন (Tool permissions)। কোন API এন্ডপয়েন্ট এবং ফাংশনগুলো স্কোপের মধ্যে আছে তা স্পষ্টভাবে উল্লেখ করুন। একটি সার্চ টুল, একটি রাইট টুল এবং একটি নোটিফিকেশন টুলের অ্যাক্সেস থাকা এজেন্ট যদি সীমানা অস্পষ্ট থাকে তবে সেগুলোকে গুলিয়ে ফেলতে পারে। প্রতিটি পারমিশনকে একটি নির্দিষ্ট অপারেশনাল প্রয়োজনের সাথে ম্যাপ করুন।
ফেইলর রিকভারি (Failure recovery)। ক্যালেন্ডার API টাইম আউট হলে, ৫০০ এরর রিটার্ন করলে বা ভুল ফরম্যাটের JSON দিলে কী হবে তা ঠিক করে নিন। এজেন্টের আতঙ্কিত হওয়া, সাফল্যের মেসেজ হ্যালুসিনেশন করা বা অনন্তকাল ধরে রিট্রাই করা উচিত নয়। এর একটি স্পষ্ট ফলব্যাক পাথ (fallback path) প্রয়োজন।
হিউম্যান রিভিউ গেটস (Human review gates)। এজেন্ট এগিয়ে যাওয়ার আগে একজন মানুষকে স্বাক্ষর বা অনুমোদন দিতে হবে এমন মুহূর্তগুলো চিহ্নিত করুন। এটি অটোমেশনের দুর্বলতা নয়। এটি উচ্চ-প্রভাবশালী পরিবর্তনের জন্য একটি সেফটি ভালভ এবং আপনার রুব্রিকের জন্য গ্রাউন্ড-ট্রুথ লেবেলের একটি উৎস।
একটি প্রকৃত মূল্যায়ন পরিকল্পনা দেখতে কেমন হয়
একবার ডিপেন্ডেন্সিগুলো ম্যাপ হয়ে গেলে, আপনার এমন একটি মূল্যায়ন পরিকল্পনা প্রয়োজন যা প্রোডাকশনের জটিলতার সাথে সামঞ্জস্যপূর্ণ। স্লাইড-ডেকের মেট্রিক্স এখানে আপনাকে সাহায্য করবে না।
সিন্থেটিক প্রশ্ন ব্যাংক থেকে নয়, বরং বাস্তব প্রোডাকশন ফেইলর থেকে টেস্ট সেট তৈরি করুন। যদি আপনার এজেন্ট গত মঙ্গলবার দুটি কাছাকাছি SKU গুলিয়ে ফেলে ব্যর্থ হয়ে থাকে, তবে সেই নির্দিষ্ট বিভ্রান্তিটি একটি স্থায়ী টেস্ট কেস হওয়া উচিত। প্রতিটি ইনসিডেন্ট থেকে নতুন কিছু শেখার সাথে সাথে আপনার ইভ্যালুয়েশন স্যুট বৃদ্ধি পাওয়া উচিত।
অপারেশনাল পরিভাষায় সফল সমাপ্তি সংজ্ঞায়িত করে এমন রুব্রিক লিখুন। "সহায়ক" বা "সঠিক"-এর মতো অস্পষ্ট মানদণ্ড অকেজো। একটি কার্যকর রুব্রিক বলে যে একটি রিফান্ড টাস্ক তখনই সফল হবে যদি মূল পেমেন্ট আইডিটি রেফার করা হয়, টাকার পরিমাণ অনুরোধের সাথে মিলে যায়, একটি কনফার্মেশন ইমেল কিউতে রাখা হয় এবং ট্রানজ্যাকশন আইডি লগ করা হয়।
টুল কল এবং রিট্রাইয়ের জন্য ট্রেস স্পেকস (trace specs) সংজ্ঞায়িত করুন। এজেন্ট কী পরিকল্পনা করেছিল, এটি আসলে কী কল করেছিল, কতবার রিট্রাই করেছিল এবং রিট্রাই কৌশলটি উপযুক্ত ছিল কি না, সে সম্পর্কে আপনার অবজারভেবিলিটি প্রয়োজন। টুল-লেভেল গ্র্যানুলারিটি ছাড়া একটি ট্রেস কেবল একটি সুন্দর গল্পের মতো।
কখন একজন মানুষকে সতর্ক করতে হবে তার জন্য নীতিমালা নির্ধারণ করুন। এজেন্টের নিজের সীমানা জানা উচিত। যদি কোনো অনুরোধ একটি ডলার থ্রেশহোল্ড অতিক্রম করে, কোনো VIP অ্যাকাউন্টের উল্লেখ করে বা এমন কোনো অবস্থার সম্মুখীন হয় যা এটি আগে কখনও দেখেনি, তবে এর অনুমান করার পরিবর্তে বিষয়টি এসক্যালেশন (escalate) করা উচিত।
খারাপ মডেল আপগ্রেড ঠেকানোর জন্য রিলিজ গেট (release gates) ইনস্টল করুন। একটি নতুন মডেল তখনই আপগ্রেড হিসেবে গণ্য হবে যদি এটি আপনার নির্দিষ্ট ফলাফলগুলোকে উন্নত করে। যদি এটি টুলের আর্গুমেন্ট নিয়ে বেশি হ্যালুসিনেশন (hallucinate) করে, ল্যাটেন্সি (latency) বাড়িয়ে দেয়, অথবা নতুন কোনো নিরাপত্তার ঝুঁকি তৈরি করে, তবে সেটি শিপ (ship) করা উচিত নয়। বেস মডেল ভেন্ডর যখনই নতুন ভার্সন রিলিজ করে, এই গেটটি প্রোডাকশনকে স্থিতিশীল রাখতে সাহায্য করে।
রানটাইম গ্রেডিং (Runtime Grading): এজেন্টের কাজ পর্যবেক্ষণ করা
Anthropic ইন্ডাস্ট্রিকে অফলাইন টেস্টের গণ্ডি পেরিয়ে রানটাইম গ্রেডিংয়ের (runtime grading) দিকে এগিয়ে যাওয়ার জন্য উৎসাহিত করছে। কোনো ট্রান্সক্রিপ্ট শেষ হওয়ার পর তা বিচার করার পরিবর্তে, রানটাইম গ্রেডিং সিস্টেমকে টাস্ক চলাকালীনই এজেন্টের কাজ বিচার করার সুযোগ দেয়। এটি ভুলগুলো বড় কোনো সমস্যায় পরিণত হওয়ার আগেই তা ধরার সুযোগ তৈরি করে।
একটি গ্রেডার যোগ করলে টোকেন এবং ল্যাটেন্সি খরচ বাড়ে। আপনি প্রতিটি ছোটখাটো ধাপ গ্রেড করতে পারবেন না। প্রতিটি গ্রেডারের অবস্থান নির্ধারণ করা একটি গুরুত্বপূর্ণ ডিজাইনের সিদ্ধান্ত। যেখানে ভুল করার ফলে বড় ক্ষতি হতে পারে, সেখানেই গ্রেডার বসান। সবচেয়ে মূল্যবান চেকপয়েন্টগুলো হলো—ডেটাবেসে কোনো স্টেট পরিবর্তন (state change) করার ঠিক আগে, পেমেন্ট গ্রহণ করার ঠিক আগে, এবং কাস্টমারকে মেসেজ পাঠানোর ঠিক আগে। এগুলোই সেই মুহূর্ত যখন একটি ভুল সিদ্ধান্ত অপরিবর্তনীয় কাজে পরিণত হতে পারে।
একটি নির্দিষ্ট অন্ধবিন্দু (blind spot) সম্পর্কে সতর্ক থাকুন। যদি একই মডেল কাজ সম্পন্ন করে এবং সেই কাজের গ্রেডিংও করে, তবে সেটি একই ভুলগুলো এড়িয়ে যেতে পারে। যে যুক্তির কারণে ভুলটি হয়েছে, রিভিউ করার সময় সেই একই যুক্তি দিয়ে ভুলটিকে সহজেই সঠিক বলে চালিয়ে দেওয়া হতে পারে। উচ্চ-প্রভাবশালী (high-impact) কাজের ক্ষেত্রে মানুষের রিভিউ বা পর্যবেক্ষণ প্রক্রিয়াটি যুক্ত রাখুন। বিশেষ করে যখন অর্থ বা কাস্টমারের বিশ্বাস জড়িত থাকে, তখন মানুষের মাধ্যমে গ্রেডারের বিচার বা সিদ্ধান্ত যাচাই করে নিন।
এখানকার মূল লক্ষ্য হলো অপারেশনাল কন্ট্রোল (operational control)। আপনার ইনসিডেন্ট ডেটা, আপনার টাস্ক রুব্রিক (task rubrics) এবং আপনার রানটাইম ট্রেসগুলোকে একটি ফিডব্যাক সাইকেলে যুক্ত করুন। পুরো প্রক্রিয়াটি মূল্যায়ন করুন: পরিকল্পনা, টুলের ব্যবহার, রিকভারি বিহেভিয়ার এবং চূড়ান্ত ফলাফল। রিলিজ করার আগে পরিচিত এবং পুনরায় ঘটাနိုင် এমন ভুলগুলো ধরার জন্য অফলাইন টেস্ট ব্যবহার করুন। অপ্রত্যাশিত নতুন ব্যর্থতাগুলো খুঁজে পেতে রানটাইম ট্রেস ব্যবহার করুন। আপনার রুব্রিকগুলো কোথায় অপরিপক্ক এবং আরও কঠোর করা প্রয়োজন, তা বুঝতে মানুষের রিভিউ ব্যবহার করুন।
তাই নিজেকে প্রশ্ন করুন: আপনার ওয়ার্কফ্লোতে আপনি রানটাইম গ্রেডার কোথায় রাখবেন? একটি টুল কল করার আগে, টুল কল করার পরে, নাকি শুধুমাত্র কোনো ঝুঁকিপূর্ণ পরিবর্তনের আগে? বেশিরভাগ টিমই সবকিছু গ্রেড করার মাধ্যমে খুব বড় পরিসরে শুরু করে এবং পরে খরচের চাপে কাজ স্থবির হয়ে পড়ে। ছোট পরিসরে শুরু করুন। এমন একটি কাজ বেছে নিন যা ভুল হলে সবচেয়ে বেশি ক্ষতি হবে। প্রথমে সেখানেই একটি গ্রেডার বসান।
একটি ব্যয়বহুল ভুল দিয়ে শুরু করুন
অপারেশনাল ইভালুয়েশন (Operational evaluation) কোনো গবেষণার বিষয় নয়। এটি এজেন্ট লাইভ হওয়ার পর নিশ্চিন্তে ঘুমানোর একটি উপায়। প্রথম দিনেই আপনার একটি নিখুঁত ফ্রেমওয়ার্কের প্রয়োজন নেই। আপনার প্রয়োজন একটি সুনির্দিষ্ট ওয়ার্কফ্লো, সহজ ব্যবসায়িক ভাষায় লেখা একটি রুব্রিক এবং এমন একটি মুহূর্তে একটি গ্রেডার যা যেখানে একটি ভুল অত্যন্ত ব্যয়বহুল হয়ে দাঁড়ায়। এটি সঠিকভাবে করতে পারলে আপনি এমন একটি ভিত্তি পাবেন যা আপনি সত্যিই বিশ্বাস করতে পারবেন।
আপনি যদি প্র্যাকটিশনারদের একটি কমিউনিটির সাথে এজেন্ট ইভালুয়েশন এবং রানটাইম গ্রেডিং সম্পর্কে আরও গভীরভাবে জানতে চান, তবে আপনি GyaanSetu লার্নিং কমিউনিটি খুঁজে পেতে পারেন https://t.me/GyaanSetuAi-তে।