সবাই প্রম্পট নিয়ে পড়ে থাকে। তারা সম্ভাষণটি নিখুঁত করার চেষ্টা করে, টোন বা সুর পরিবর্তন করে এবং মডেলটি যথেষ্ট আন্তরিক শোনাচ্ছে কি না তা নিয়ে দুশ্চিন্তা করে। এটি আসলে একটি বিভ্রান্তি। যখন একটি AI এজেন্ট প্রকৃত ব্যবহারকারীদের কাছে প্রকৃত ইমেইল পাঠাতে শুরু করে, তখন বিপদ এটি নয় যে এটি "Best regards"-এর পরিবর্তে "Cheers" লিখল। বিপদ হলো, এজেন্টের সিদ্ধান্ত এবং ইনবক্সে মেসেজটি পৌঁছানোর মধ্যবর্তী সময়ে ঠিক কী ঘটেছিল, তা আপনি নিশ্চিতভাবে বলতে পারবেন না। আমি প্রথমে সীমানা বা বাউন্ডারিটি দেখি। সেখানেই প্রোডাকশন সিস্টেমগুলো নিঃশব্দে ব্যর্থ হয়।
কন্ট্রাক্ট বা চুক্তিটিই হলো দুর্বলতম দিক
AI ডেমো বা প্রদর্শনীগুলো বেশ সহনশীল। একটি ব্রাউজার উইন্ডোতে মসৃণ কথোপকথন অনেক অস্পষ্ট ধারণাকে আড়াল করে রাখে। প্রোডাকশনে আসল দুর্বলতা লুকিয়ে থাকে তিনটি বিষয়ের মধ্যকার কন্ট্রাক্টে: এজেন্টের সিদ্ধান্ত, কাজটি সম্পাদনকারী টুল এবং ফলাফল যাচাইকারী ধাপ। যদি সেই সীমানা অস্পষ্ট হয়, তবে সিস্টেমটি ততক্ষণ পর্যন্ত চমৎকারভাবে কাজ করবে যতক্ষণ না সেটি হঠাৎ অচল হয়ে যায়। তারপর এটি নিঃশব্দে ব্যর্থ হয়, পুরো কাস্টমার সেগমেন্টের কাছে ডুপ্লিকেট মেসেজ পাঠিয়ে দেয়, অথবা কেন পাঠালো তার কোনো স্পষ্ট রেকর্ড ছাড়াই ভুল সময়ে মেসেজ পাঠিয়ে দেয়। প্রম্পটটি হয়তো কবিতার মতো সুন্দর হতে পারে, কিন্তু এর নিচের আর্কিটেকচারটি তখনও সুতো দিয়ে বেঁধে রাখা সম্ভব।
এজেন্টকে অবাধে লিখতে দেবেন না
সবচেয়ে সাধারণ ভুল হলো এজেন্টকে একটি ফাঁকা পৃষ্ঠা দিয়ে দেওয়া। টিমগুলো এজেন্টকে একটি ইমেইল র）」 টেক্সট হিসেবে বর্ণনা করতে দেয় এবং তারপর একটি ডাউনস্ট্রিম টুলের ওপর ভরসা করে যে সেটি গদ্য থেকে উদ্দেশ্য (intent) বুঝে নেবে। এটি অত্যন্ত ভঙ্গুর একটি পদ্ধতি। একটি LLM হয়তো একটি যুক্তিসঙ্গত উদ্দেশ্য প্রস্তাব করতে পারে, কিন্তু আপনার ইনফ্রাস্ট্রাকচারের সৃজনশীলতার প্রয়োজন নেই। এর প্রয়োজন একটি কন্ট্রাক্ট। এর প্রয়োজন নির্দিষ্ট কিছু ফিল্ড যা একটি মেশিন কোনো অস্পষ্টতা ছাড়াই যাচাই করতে পারে।
যখন একটি এজেন্ট ইমেইল রিকোয়েস্ট প্রদান করে, তখন আউটপুটে ঠিক সেই বিষয়গুলো থাকা উচিত যা সিস্টেমের কাজের জন্য প্রয়োজন:
- Template version: ইমেইল বডির কোন ভার্সনটি ব্যবহার করা হচ্ছে, যাতে আপনি জানেন ব্যবহারকারী কী দেখেছেন।
- Recipient scope: কে এটি পাবে, যা ইউজার আইডি বা সেগমেন্ট রুল দ্বারা সংজ্ঞায়িত, "যে ইউজার মাত্র সাইন আপ করেছে" এর মতো ন্যাচারাল ল্যাঙ্গুয়েজ দিয়ে নয়।
- Trace ID: একটি ইউনিক আইডেন্টিফায়ার যা এজেন্টের মাধ্যমে আপনার এক্সিকিউটর, ইমেইল প্রোভাইডার এবং আপনার লগ পর্যন্ত এই রিকোয়েস্টটিকে অনুসরণ করে।
- Time window: এই সেন্ডটি কখন বৈধ, যাতে পুরনো এজেন্টের সিদ্ধান্ত কয়েক ঘণ্টা পর মাঝরাতে ইমেইল পাঠিয়ে না দেয়।
- Idempotency: একটি কী (key) যা নিশ্চিত করে যে এজেন্ট যদি পুনরায় চেষ্টা করে বা নেটওয়ার্কে সমস্যা হয়, তবে একই লজিক্যাল সেন্ড যেন দুবার না ঘটে।
কাঁচা টেক্সট (Raw text) একটি terrible API। এটি জরুরি অবস্থা, দর্শক এবং কাজের ধরন নিয়ে অস্পষ্টতা তৈরি করে। নির্দিষ্ট ফিল্ডগুলো মেশিন-রিডেবল, অডিটেবল এবং টেস্টযোগ্য। এগুলো একটি অস্পষ্ট নির্দেশকে একটি যাচাইযোগ্য কমান্ডে রূপান্তরিত করে।
গদ্য নয়, বরং অ্যাকশন
এজেন্টকে একটি অনির্দিষ্ট লেখার কাজ দেওয়ার পরিবর্তে, তাকে অনুমোদিত অ্যাকশনের একটি মেনুর মধ্যে সীমাবদ্ধ রাখুন। এটিকে একটি ফিক্সড enum সহ ইন্টারনাল API হিসেবে ভাবুন। এজেন্ট কোনো সাবজেক্ট লাইন ড্রাফট করে না বা সম্ভাষণ নিয়ে চিন্তা করে না। এটি send_review_request বা send_retry_notice-এর মতো একটি অ্যাকশন বেছে নেয়। এর সৃজনশীল স্বাধীনতার সীমা এখানেই।
একটি ডিটারমিনিস্টিক এক্সিকিউটর তখন সেই অ্যাকশন কী গ্রহণ করে, ভার্সন কন্ট্রোল থেকে সঠিক টেমপ্লেটটি তুলে আনে, সেটিকে sanitized ডেটা দিয়ে পূর্ণ করে, যাচাইকৃত উৎস থেকে প্রাপকের তালিকা সংগ্রহ করে এবং চূড়ান্ত কমান্ডটি তৈরি করে। এজেন্ট সিদ্ধান্ত নেয় কী করা প্রয়োজন। কিন্তু কীভাবে তা করা হবে, তা সিদ্ধান্ত নেয় বোরিং এবং প্রেডিক্টেবল কোড।
এই বিভাজন সিস্টেমটিকে পরীক্ষা করা সহজ করে তোলে। আপনি কোনো LLM ইনফারেন্স না চালিয়েই যাচাই করতে পারেন যে একটি নির্দিষ্ট ইনপুট স্টেট নির্ভরযোগ্যভাবে send_retry_notice ট্রিগার করছে কি না। আপনার ইউনিট টেস্টগুলো দ্রুত এবং ডিটারমিনিস্টিক হয়ে ওঠে কারণ সেগুলো মডেলের টেম্পারেচার নয়, বরং ম্যাপিং লজিক পরীক্ষা করে। আপনার ইন্টিগ্রেশন টেস্টগুলো মডেলের মেজাজ কেমন ছিল তা নয়, বরং এক্সিকিউটর সঠিকভাবে অ্যাকশনটিকে ইমেইল সার্ভিসের সাথে ম্যাপ করছে কি না তার ওপর ফোকাস করে।
পাঁচটি স্তরে তৈরি করুন
একটি মজবুত সিস্টেম কেবল একটি প্রম্পট থেকে তৈরি হয় না। এটি স্তরে স্তরে তৈরি করা হয় এবং প্রতিটি স্তর একটি নির্দিষ্ট ও স্পষ্ট দায়িত্ব পালন করে।
১. ব্যাকএন্ড ইভেন্টটিকে নিরাপদ ডেটাতে রূপান্তরিত করে।
ট্রিগারটি একটি webhook, ডাটাবেস পরিবর্তন বা একটি শিডিউল করা জব যাই হোক না কেন, এই স্তরটি ইনপুটগুলোকে sanitize করে, অপ্রত্যাশিত ফিল্ডগুলো সরিয়ে ফেলে এবং এজেন্টকে কেবল তার প্রয়োজনীয় অংশটুকু প্রদান করে। যদি একটি webhook পেলোড ২০টি ফিল্ড ধারণ করে কিন্তু এজেন্টের মাত্র দুটি প্রয়োজন হয়, তবে কেবল সেই দুটিই পাস করুন। কোনো কাঁচা ইউজার টেক্সট যেন যাচাই না করে সিদ্ধান্ত গ্রহণকারী স্তরে না পৌঁছায়।
২. এজেন্ট একটি ফিক্সড স্কিমা থেকে একটি অ্যাকশন বেছে নেয়।
এটি প্রেক্ষাপট দেখে, একটি সিদ্ধান্ত নেয় এবং প্রয়োজনীয় মেটাডেটা সহ পূর্বনির্ধারিত অ্যাকশন কীগুলোর মধ্যে একটি আউটপুট দেয়। এটি কোনো গদ্য ড্রাফট করে না। এটি প্রাপক নিয়ে অনুমান করে না। এটি একটি স্ট্রাকচার্ড পেলোড রিটার্ন করে যা পরবর্তী স্তরটি একটি JSON schema-র বিপরীতে যাচাই করতে পারে।
৩. টুলটি পারমিশন এবং প্রয়োজনীয় ফিল্ডগুলো যাচাই করে।
এই এজেন্ট কনটেক্সটটির কি এই ইউজারের জন্য send_review_request ট্রিগার করার অধিকার আছে? রিসিভিয়েন্ট স্কোপটি কি খালি নয় এবং অনুমোদিত সীমার মধ্যে আছে? আপনার লগে কি আইডেমপোটেন্সি কী (idempotency key) উপস্থিত এবং অনন্য? ট্রেস আইডিটি কি সঠিকভাবে গঠিত? কোনো ইমেল সার্ভিস ব্যবহারের আগেই এখানে স্পষ্টভাবে ব্যর্থতা প্রদর্শন করুন।
৪. ইমেল সার্ভিসটি একটি ট্রেস আইডি সহ পাঠানোর লগ রাখে।
আপনার সিস্টেম থেকে বেরিয়ে যাওয়া প্রতিটি মেসেজে প্রোভাইডারের API এবং আপনার অবজারভেবিলিটি স্ট্যাকের (observability stack) মাধ্যমে সেই ট্রেস আইডেন্টিফায়ারটি থাকা উচিত। যদি কোনো ইউজার অভিযোগ করেন যে তারা দুটি কপি পেয়েছেন, তবে আপনি একটি আইডি কুয়েরি করে দেখতে সক্ষম হতে হবে যে ডুপ্লিকেশনটি ঠিক কোথায় থেকে শুরু হয়েছে: একটি রিট্রাইড করা এজেন্ট কল, একটি ফ্ল্যাকি এক্সিকিউটর (flaky executor), নাকি একটি ভুলভাবে কাজ করা কলব্যাক।
৫. এন্ড-টু-এন্ড টেস্টটি কন্টেন্ট এবং প্রভাবের জন্য প্রকৃত ইনবক্স পরীক্ষা করে।
একটি প্রকৃত মেইলবক্সে রেন্ডার করা মেসেজটি ওপেন করুন। সাবজেক্ট লাইনটি কি সঠিকভাবে পূরণ করা হয়েছে? আনসাবস্ক্রাইব লিঙ্কটি কি কাজ করছে? প্রাইমারি কল-টু-অ্যাকশন (call-to-action) বাটনে ক্লিক করলে কি সঠিক ইউজার স্টেটসহ সঠিক পেজে পৌঁছানো যাচ্ছে? একটি সফল ইউনিট টেস্ট মানে কোডটি চলেছে। শুধুমাত্র একটি ইনবক্স টেস্টই আপনাকে বলবে যে ইমেলটি আসলে একজন মানুষের জন্য কাজ করছে।
অনুমানের চেয়ে প্রমাণ শ্রেয়
যখন এই পাইপলাইনে একটি টেস্ট ব্যর্থ হয়, তখন আপনার চারটি নির্দিষ্ট প্রমাণের প্রয়োজন। এর কম কিছু গ্রহণ করবেন না।
- এজেন্টের মূল সিদ্ধান্ত। এটি কোন অ্যাকশনটি বেছে নিয়েছিল এবং সম্পূর্ণ ইনপুট কনটেক্সট কী ছিল?
- টুল থেকে প্রাপ্ত নরমালাইজড কমান্ড। টেমপ্লেট, হাইড্রেশন লজিক এবং ভ্যালিডেশন রুলস প্রয়োগ করার পর ডিটারমিনিস্টিক এক্সিকিউটর কী তৈরি করেছিল?
- আইসোলেটেড ইনবক্সে থাকা মেসেজ। আপনি কী পাঠিয়েছেন বলে মনে করছেন তার লগ নয়, বরং একটি ডেডিকেটেড টেস্ট মেইলবক্সে ক্যাপচার করা প্রকৃত MIME মেসেজ, হেডার এবং সবকিছু।
- লিঙ্কে ক্লিক করার পরের চূড়ান্ত প্রভাব। ফলাফলস্বরূপ পেজ স্টেট, ডাটাবেস পরিবর্তন বা বাহ্যিক ঘটনা যা প্রমাণ করে যে ইমেলটি তার উদ্দেশ্য সফল করেছে।
যদি একটি অংশও অনুপস্থিত থাকে, তবে আপনার টিম অনুমানের মাধ্যমে সেই শূন্যতা পূরণ করবে। তারা অনুমান করবে। অটোমেশনে অনুমান করা ব্যয়বহুল। এটি ঘণ্টার পর ঘণ্টা সময় নষ্ট করে, বিশ্বাস নষ্ট করে এবং প্রতিটি ঘটনাকে একটি ফরেনসিক রহস্যে পরিণত করে, পরিবর্তে একটি