প্রোডাকশনে যাওয়ার আগে একটি AI Agent Playground তৈরি করা
একবার একটি কোডিং এজেন্ট একটি ক্লিনআপ স্ক্রিপ্ট চালিয়েছিল যা সে একটি স্টেজিং ডাটাবেস হিসেবে ভেবেছিল। কিন্তু আসলে সেটি ছিল প্রোডাকশন ডাটাবেস। ভুল ক্রেডেনশিয়াল (credentials) ব্যবহার করে এজেন্টটি ঠিক সেটাই করেছিল যা তাকে বলা হয়েছিল, যার ফলে সে চার মাসের কাস্টমার অর্ডার মুছে ফেলেছিল।
এই ব্যর্থতা এজেন্ট ব্যবহার না করার কারণ নয়। বরং এটি একটি প্লেগ্রাউন্ড (playground) তৈরি করার কারণ।
আপনি একজন নতুন ইঞ্জিনিয়ারকে তার প্রথম দিনেই প্রোডাকশন ডাটাবেসের অ্যাক্সেস দেবেন না। আপনি তাকে একটি স্টেজিং এনভায়রনমেন্ট, রিড-অনলি (read-only) অ্যাক্সেস এবং তদারকি করা কাজ দেবেন। এজেন্টদেরও একই ধরনের অনবোর্ডিং প্রয়োজন। তারা প্রতি মিনিটে হাজার হাজার কাজ করতে পারে, তাই প্লেগ্রাউন্ড বাদ দেওয়ার ঝুঁকি বা খরচ হাজার গুণ বেশি।
একটি প্রকৃত প্লেগ্রাউন্ডকে অবশ্যই তিনটি কাজ করতে হবে:
- এজেন্টকে তার সম্পূর্ণ ডিসিশন লুপ (decision loop) চালানোর সুযোগ দেওয়া।
- সমস্ত সাইড ইফেক্ট (side effects) যাতে আসল সিস্টেমে না পৌঁছায় তা নিশ্চিত করা।
- পরিদর্শনের জন্য সবকিছু রেকর্ড করা।
শুধু প্রম্পট (prompt) টেস্ট করবেন না। প্রম্পট টেস্ট করা মানে হলো একটি প্রশ্ন করা এবং একটি উত্তর পড়া। একটি এজেন্টের আচরণ হলো টুল কলের (tool calls) একটি ধারাবাহিকতা। আসল ব্যর্থতাগুলো লুপের মাঝখানে ঘটে যখন কোনো টুল অপ্রত্যাশিত ডেটা প্রদান করে।
আপনার মডেলকে স্যান্ডবক্স (sandbox) করার প্রয়োজন নেই। আপনার এক্সিকিউটরকে (executor) স্যান্ডবক্স করা প্রয়োজন।
যেখানে টুল কলগুলো অ্যাকশনে রূপান্তরিত হয়, সেখানে একটি সংযোগস্থল বা 'সিম' (seam) তৈরি করুন। লাইভ এক্সিকিউটরের পরিবর্তে মক (mock) ব্যবহার করে একটি প্লেগ্রাউন্ড এক্সিকিউটর ব্যবহার করুন। এজেন্ট লুপের কাছে এই পার্থক্যটি বোঝা উচিত নয়। যদি আপনার এজেন্ট সরাসরি একটি ডাটাবেস ক্লায়েন্ট কল করে, তবে আপনার কাছে কোনো সুরক্ষা বা সংযোগস্থল থাকবে না।
তিনটি নির্দিষ্ট ক্ষেত্র পরীক্ষা করুন:
- আচরণ (Behavior): এজেন্ট কি সঠিক ক্রমে সঠিক টুলটি বেছে নিচ্ছে?
- টুল কল (Tool calls): আর্গুমেন্টগুলো কি সঠিক এবং নিরাপদ সীমার মধ্যে আছে?
- ব্যর্থতার ধরন (Failure modes): যখন কোনো API টাইম-আউট হয় বা ভুল ডেটা (garbage) প্রদান করে তখন কী ঘটে?
একটি মক যা সবসময় সফল হয়, তা এজেন্টকে কিছুই শেখায় না। আপনার প্লেগ্রাউন্ডে নেটওয়ার্ক টাইম-আউট বা ত্রুটিপূর্ণ ডেটার (malformed data) মতো ব্যর্থতাগুলো ইনজেক্ট করার সুযোগ থাকতে হবে। এর মাধ্যমেই আপনি বুঝতে পারবেন এজেন্টটি বুদ্ধিমত্তার সাথে পুনরায় চেষ্টা (retry) করছে নাকি হ্যালুসিনেশন (hallucinating) শুরু করছে।
যদি আপনার এজেন্ট কোড রান করে, তবে আপনার শক্তিশালী আইসোলেশন (isolation) প্রয়োজন। অনির্ভরযোগ্য কোডের জন্য microVMs ব্যবহার করুন। শুধুমাত্র সহজ বলে সাধারণ কন্টেইনার দিয়ে শুরু করবেন না। একটি সহজ সেটআপ বড় ধরনের নিরাপত্তা দুর্ঘটনার কারণ হতে পারে।
মনে রাখবেন যে এজেন্টগুলো নন-ডিটারমিনিস্টিক (non-deterministic)। একটি টেস্ট একবার পাস করার মানে এই নয় যে এজেন্টটি নির্ভরযোগ্য। আপনাকে একই কাজ বারবার চালাতে হবে। যদি একটি এজেন্ট ১০ বারের মধ্যে ৭ বার সফল হয়, তবে এটি আপনার আসল ব্যবহারকারীদের প্রায় ৩০% ক্ষেত্রে ব্যর্থ হবে। ধারাবাহিকতা (Consistency) হলো আপনার সবচেয়ে গুরুত্বপূর্ণ মেট্রিক।
পরিশেষে, অ্যাডভারসারিয়াল (adversarial) টুল আউটপুট থেকে সুরক্ষা নিশ্চিত করুন। একটি এজেন্ট টুল ডেটাকে নির্দেশ হিসেবে গণ্য করে। একজন ক্ষতিকারক ব্যবহারকারী প্রম্পট ইনজেকশন (prompt injection) ব্যবহার করে ডাটাবেসে এমন কিছু ডেটা রাখতে পারে যা এজেন্টকে ভুল পথে পরিচালিত করবে। প্লেগ্রাউন্ডে ক্ষতিকারক পেলোড (hostile payloads) দিয়ে আপনার এজেন্টকে পরীক্ষা করুন।
একটি লঞ্চ বাটন নয়, বরং একটি গ্র্যাজুয়েশন পাথ (graduation path) তৈরি করুন:
- মক এবং পূর্ণ স্যান্ডবক্সিং দিয়ে শুরু করুন।
- অনেকবার চালানোর মাধ্যমে ধারাবাহিকতা পরীক্ষা করুন।
- অ্যাডভারসারিয়াল ইনপুটগুলোর বিরুদ্ধে পরীক্ষা করুন।
- প্রোডাকশন-সদৃশ ডেটার বিপরীতে ড্রাই-রান (dry-run) মোডে যান।
- কেবল তখনই নির্দিষ্ট সীমার মধ্যে (scoped), নিয়ন্ত্রিত (gated) এবং পর্যবেক্ষণ করা (monitored) অ্যাক্সেস প্রদান করুন।
আপনার এজেন্টকে কম খরচে ভুল করার একটি জায়গা দিন। তাহলেই এটি গুরুত্বপূর্ণ ক্ষেত্রে সঠিক হতে পারবে।
Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh
Optional learning community: https://t.me/GyaanSetuAi