𝗔𝗜 𝗠𝗼𝗱𝗲𝗹 𝗙𝗮𝗶𝗹𝗼𝘃𝗲𝗿 𝗗𝗿𝗶𝗹𝗹𝘀: 𝗞𝗲𝗲𝗽 𝗔𝗴𝗲𝗻𝘁𝘀 𝗨𝘀𝗲𝗳𝘂𝗹 𝗪𝗵𝗲𝗻 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿𝘀 𝗕𝗿𝗲𝗮𝗸
একটি মডেল ফলব্যাক যা কেবল একটি ডায়াগ্রামে কাজ করে, তা স্থিতিস্থাপকতা (resilience) নয়। এটি কেবল উন্নত ব্র্যান্ডিং করা একটি পরিকল্পনা মাত্র।
আপনার প্রোডাক্ট যদি AI এজেন্ট ব্যবহার করে, তবে একটি ধীরগতির প্রোভাইডার বা রেট-লিমিট স্পাইক ব্যবহারকারীর অভিজ্ঞতা নষ্ট করে দিতে পারে। আসল বিপদ সম্পূর্ণ আউটটেজ (outage) নয়। আসল বিপদ হলো একটি আংশিক কার্যকর ফলব্যাক। এটি তখন ঘটে যখন একটি ব্যাকআপ মডেল ব্যবহারকারীকে না জানিয়ে নীরবে ডেটা ফরম্যাট পরিবর্তন করে, টুলের স্টেট (state) হারিয়ে ফেলে অথবা সাইটেশন (citation) বাদ দিয়ে দেয়।
প্রোডাকশন ট্রাফিক আপনাকে কঠিন অভিজ্ঞতার মুখোমুখি করার আগেই আপনাকে অবশ্যই ব্যবহারিক ফেইলওভার ড্রিল চালাতে হবে।
লক্ষ্য প্রতিটি মডেলকে একে অপরের পরিবর্তে ব্যবহারযোগ্য করা নয়। লক্ষ্য হলো প্রাইমারি মডেল ব্যর্থ হলে ওয়ার্কফ্লোটিকে নিরাপদ এবং নির্ভরযোগ্য রাখা।
বেশিরভাগ টিম একটি সাধারণ চেইন ব্যবহার করে: প্রথমে প্রাইমারি মডেলটি চেষ্টা করা, তারপর একটি ব্যাকআপ, এবং তারপর একটি এরর (error) দেখানো। এটি AI সিস্টেমের আসল সমস্যাগুলোকে এড়িয়ে যায়। AI সূক্ষ্ম উপায়ে ব্যর্থ হয়:
• একটি ব্যাকআপ মডেল ভিন্ন ফিল্ড অর্থসহ JSON রিটার্ন করে। • একটি সস্তা মডেল আপনার টুল পলিসিগুলো উপেক্ষা করে। • একটি প্রোভাইডার খুব ধীরগতিতে টোকেন স্ট্রিম করে। • একটি ফলব্যাক মডেলে একই ফাংশন-কলিং ফরম্যাট থাকে না। • এজেন্ট বারবার চেষ্টা (retry) করে এবং ব্যবহারকারীর বাজেট শেষ করে দেয়।
একটি AI মডেল ফেইলওভার ড্রিল হলো একটি পরিকল্পিত পরীক্ষা। প্রোডাক্টটি নিরাপদ থাকে কি না তা দেখার জন্য আপনি ইচ্ছাকৃতভাবে একটি মডেল পাথ (path) ভেঙে ফেলেন।
একটি ভালো ড্রিল যা পরীক্ষা করে:
- ওয়ার্কফ্লো কি চলতে থাকে?
- এটি কি স্কিমা (schema) এবং টুলের স্টেট বজায় রাখে?
- এটি কি খরচ এবং ল্যাটেন্সি (latency) বাজেটের মধ্যে থাকে?
- এটি কি পরবর্তী সময়ের জন্য একটি রিগ্রেশন টেস্ট তৈরি করে?
প্রতিটি প্রম্পটকে একাধিক প্রোভাইডারের সাথে কাজ করানোর মাধ্যমে শুরু করবেন না। সেই সব ওয়ার্কফ্লো দিয়ে শুরু করুন যেখানে ব্যর্থতা বিশ্বাস নষ্ট করে দেয়।
উচ্চ-অগ্রাধিকার সম্পন্ন ওয়ার্কফ্লো:
- কাস্টমার-ফেসিং চ্যাট
- রিপোর্ট জেনারেশন
- টুল কল করে এমন এজেন্ট ওয়ার্কফ্লো
- সাইটেশনসহ RAG উত্তর
- স্ট্রাকচার্ড ফিল্ডে ডেটা এক্সট্রাকশন
সেরা ডিজাইন শুরু হয় একটি কন্ট্রাক্ট (contract) দিয়ে, মডেলের নামের তালিকা দিয়ে নয়। একটি ফলব্যাক কন্ট্রাক্ট নির্ধারণ করে দেয় যে সকল প্রোভাইডারের ক্ষেত্রে কোন বিষয়গুলো অপরিবর্তিত থাকতে হবে। একটি সাপোর্ট এজেন্টের জন্য এতে অন্তর্ভুক্ত থাকতে পারে:
- ইনপুট এবং আউটপুট শেপ (shape)
- কনফিডেন্স লেভেল এবং সাইটেশন
- টুলের পারমিশন এবং অবশিষ্ট বাজেট
- কোয়ালিটি গেট এবং ভ্যালিডেশন রুলস
মাঝে মাঝে সঠিক ফলব্যাক অন্য কোনো মডেল নয়। এটি হতে পারে:
- ব্যবহারকারীর কাছে নিশ্চিতকরণ চাওয়া
- আংশিক ফলাফল প্রদান করা
- কাজটিকে পরে করার জন্য কিউ (queue) করা
- ওয়ার্কফ্লোটিকে মানুষের পর্যালোচনার (human review) জন্য পাঠানো
প্রতিটি ব্যর্থতাকে অন্য একটি মডেল চেষ্টা করার কারণ হিসেবে দেখা বন্ধ করুন। এরর এবং ফরম্যাটগুলোকে স্বাভাবিক করতে একটি model adapter ব্যবহার করুন। এটি আপনার ড্রিলগুলোকে সহজ করে তোলে কারণ আপনি আপনার মূল লজিক পরিবর্তন না করেই ব্যর্থতাগুলো সিমুলেট করতে পারেন।
শুরু করার জন্য এই তিনটি ড্রিল চালান:
- The Timeout Drill: প্রাইমারি মডেলটিকে স্লিপ (sleep) মোডে যেতে বাধ্য করুন। আপনার latency budget-এর মধ্যে fallback কাজ করছে কি না তা যাচাই করুন।
- The Rate Limit Drill: একটি 429 error তৈরি করুন। আপনার সিস্টেম backoff ব্যবহার করছে কি না এবং tenant budget রক্ষা করছে কি না তা যাচাই করুন।
- The Schema Drill: একটি মডেলকে ইনভ্যালিড JSON রিটার্ন করতে বাধ্য করুন। আপনার সিস্টেম আউটপুট যাচাই করছে কি না অথবা workflow-টি নিরাপদে থামিয়ে দিচ্ছে কি না তা নিশ্চিত করুন।
ব্যবহারকারীদের আপনার প্রোভাইডার সংক্রান্ত বিস্তারিত জানার প্রয়োজন নেই। তাদের প্রয়োজন স্বচ্ছ আচরণ।
খারাপ মেসেজ: কোনো সমস্যা হয়েছে। ভালো মেসেজ: আমি এখনও সাহায্য করতে পারি, তবে লাইভ অ্যাকশনগুলো সাময়িকভাবে সীমিত। আমি আপনার পর্যালোচনার জন্য পরবর্তী ধাপটি ড্রাফট করে দিতে পারি।
সবকিছু ঠিক আছে বলে ভান করে নয়, বরং স্পষ্ট সীমানা নির্ধারণের মাধ্যমে বিশ্বাস অর্জন করুন।
Optional learning community: https://t.me/GyaanSetuAi