ব্লক হওয়া মানেই ব্যর্থতা নয়: এজেন্টদের সীমানা সংক্রান্ত ফিডব্যাক প্রয়োজন

বেশিরভাগ এজেন্ট সেটআপ একটি ব্লক করা কাজকে টুলের ব্যর্থতা হিসেবে গণ্য করে।

একটি এজেন্ট একটি টুল কল করে। অনুরোধটি একটি নিয়ম লঙ্ঘন করে। সিস্টেম একটি সাধারণ (generic) এরর প্রদান করে। টুল কলটি ব্যর্থ হয়।

প্রথম দেখায় এটি ঠিক মনে হতে পারে। অনিরাপদ কাজটি থামানো হয়েছে। কিন্তু এটি সমস্যার অর্ধেক সমাধান করে।

একটি সাধারণ এরর এজেন্টকে তার সীমার মধ্যে কাজ করতে সাহায্য করে না। এটি একটি পলিসি সিদ্ধান্তকে কেবল একটি নয়েজ (noise) বা অপ্রাসঙ্গিক তথ্যে পরিণত করে। এজেন্ট হয়তো কোনো সমাধান অনুমান করার চেষ্টা করতে পারে। এটি একই ভুল বারবার করতে পারে বা ভিন্ন কোনো পেলোড (payload) চেষ্টা করতে পারে। এটি নিরর্থক প্রচেষ্টার একটি চক্র তৈরি করে।

একটি ব্লক করা কাজ হওয়া উচিত একটি সুসংগঠিত সিদ্ধান্ত, কোনো অপ্রত্যাশিত ক্র্যাশ নয়।

যখন একটি অনুরোধ ব্লক করা হয়, তখন বাহ্যিক সিস্টেমের পরিবর্তন হওয়া উচিত নয়। তবে, রেসপন্সটি এজেন্টকে অবশ্যই বলে দিতে হবে কীভাবে নিরাপদে পরবর্তী পদক্ষেপ নিতে হবে।

একটি সাধারণ এরর এর পরিবর্তে, একটি সুসংগঠিত রেসপন্স ব্যবহার করুন।

কল্পনা করুন একটি এজেন্ট এমন একটি ফাইলে লেখার চেষ্টা করছে যা তার পরিকল্পনা করার সময় পরিবর্তিত হয়ে গেছে। একটি সাধারণ এরর বলবে "failed"। একটি সুসংগঠিত রেসপন্স বলবে:

  • Decision status: conflict
  • Outcome status: no impact
  • Reason: stale state
  • Next action: re-read target state

এখন এজেন্ট জানে যে লক্ষ্যটি অসম্ভব নয়। তাকে শুধু তার তথ্য আপডেট করতে হবে। এটি অনুমান করা বন্ধ করে সঠিক পরবর্তী পদক্ষেপটি গ্রহণ করে।

এটি অনেক পরিস্থিতির জন্য কার্যকর:

  • যদি কোনো পথ স্কোপের বাইরে হয়, তবে একটি অনুমোদিত পথের পরামর্শ দিন।
  • যদি কোনো প্রভাব ইতিমধ্যে বিদ্যমান থাকে, তবে ফলাফলটি পুনরায় ব্যবহারের পরামর্শ দিন।
  • যদি প্রভাব খুব বেশি হয়, তবে মানুষের পর্যালোচনার (human review) জন্য অপেক্ষা করার পরামর্শ দিন।

এটি সীমানাকে শিথিল করে না। কাজটি ব্লক অবস্থাতেই থাকে। সিস্টেম নিরাপদ থাকে। আপনি কেবল একটি ডেড এন্ডকে (dead end) একটি নির্দেশিত পথে রূপান্তরিত করছেন।

আপনাকে নিরাপত্তার সাথে এর ভারসাম্য বজায় রাখতে হবে। সুনির্দিষ্ট ফিডব্যাক একটি খারাপ এজেন্টকে আপনার সীমানা পরীক্ষা করার সুযোগ করে দিতে পারে।

stale data বা malformed inputs-এর মতো অপারেশনাল ঘর্ষণের জন্য স্পষ্ট reason code ব্যবহার করুন। যদি এজেন্ট সন্দেহজনক আচরণ করে বা ইঙ্গিত উপেক্ষা করে, তবে সাধারণ প্রত্যাখ্যান (generic rejection) বা মানুষের পর্যালোচনার (human review) দিকে ফিরে যান।

এজেন্টের ফিডব্যাককে অডিট স্কোর থেকে আলাদা রাখুন। এজেন্টকে জানতে হবে কীভাবে নিয়ম মেনে (compliant) চলতে হয়। সিস্টেমকে জানতে হবে এজেন্ট খারাপ আচরণ করছে কি না। এই দুটি কাজকে মিশ্রিত করবেন না।

বাউন্ডারি বা সীমানাগুলো বিদ্যমান কারণ এজেন্টরা এখন বাস্তব সিস্টেমে কাজ করার মতো যথেষ্ট কার্যকর হয়ে উঠছে। বাস্তব কাজের নিয়ম এবং সীমাবদ্ধতা থাকে।

যে বাউন্ডারি কেবল ব্যর্থতা (failure) দেখায় তা একটি দেয়াল। যে বাউন্ডারি নির্দেশনা প্রদান করে তা একটি টুল।

Blocked বলতে বোঝানো উচিত:

  • কাঙ্ক্ষিত প্রভাবটি ঘটেনি।
  • কারণটি জানা আছে।
  • পরবর্তী নিরাপদ পদক্ষেপটি স্পষ্ট।

উৎস: https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg

ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi