একটি প্রাথমিক লার্জ ল্যাঙ্গুয়েজ মডেল (LLM) নির্বাচন করতে একটি বিকেল লেগে যেতে পারে। কিন্তু এটি ব্যর্থ হলে কী হবে তা সামলানোই হলো আসল ইঞ্জিনিয়ারিং কাজ।
বেশিরভাগ টিমই 'হ্যাপি পাথ' (happy path) বা সফল পথের জন্য অপ্টিমাইজ করে। তারা পরিষ্কার ডেটাসেটের ওপর নির্ভুলতা যাচাই করে, আদর্শ ইনপুটের বিপরীতে প্রম্পট উন্নত করে এবং আত্মবিশ্বাসের সাথে ডেপ্লয় করে। তারপর প্রোডাকশন ট্রাফিক আসে। পিক আওয়ারের সময় মডেলটি টাইম-আউট হতে শুরু করে, শুক্রবার সন্ধ্যায় ত্রুটিপূর্ণ JSON রিটার্ন করে, অথবা প্রাইসিং আপডেটের পরে হঠাৎ তিনগুণ খরচ হতে শুরু করে। আপনার যত্ন সহকারে ডিজাইন করা AI ফিচারটি একটি বোঝা হয়ে দাঁড়ায় কারণ মডেলটি ভেঙে পড়বে বলে কেউ পরিকল্পনা করেনি।
যেকোনো সিরিয়াস মাল্টি-মডেল অ্যাপ্লিকেশনে, ফলব্যাক রুলস (fallback rules) কোনো অতিরিক্ত চিন্তা নয়। এগুলো হলো মূল অবকাঠামো। প্রাথমিক মডেলটি হোঁচট খেলে আপনার সিস্টেম কীভাবে আচরণ করে, তার ওপর নির্ভর করে ব্যবহারকারীরা আপনার সাথে থাকবেন নাকি চলে যাবেন।
স্পষ্ট ফেইলর সিগন্যাল (Failure Signals) দিয়ে শুরু করুন
আপনি ঠিক কীসের বিপরীতে প্রতিক্রিয়া জানাচ্ছেন তা না জেনে একটি ফলব্যাক কৌশল তৈরি করতে পারবেন না। প্রতিটি আউটবাউন্ড মডেল কল মনিটর করা শুরু করুন এবং ব্যর্থতাগুলোকে নির্দিষ্ট ও কার্যকর সিগন্যালে শ্রেণীবদ্ধ করুন।
প্রোভাইডারের এন্ডপয়েন্ট হ্যাং করলে API টাইম-আউটের দিকে নজর রাখুন। রেট লিমিট এরর — সাধারণত HTTP 429 — খেয়াল করুন, যা ঘটে যখন আপনি হঠাৎ ট্রাফিক বাড়িয়ে দেন বা মাসিক কোটা শেষ করে ফেলেন। আপনার পার্সার পাইপলাইন ক্র্যাশ করতে পারে এমন ইনভ্যালিড JSON আউটপুটের দিকে নজর রাখুন। খালি বা অসম্পূর্ণ রেসপন্সের দিকে নজর রাখুন যা HTTP লেয়ারে সফল মনে হলেও কোনো ব্যবহারযোগ্য কন্টেন্ট নেই। কোনো হার্ড টাইম-আউট হওয়ার আগেই চ্যাট অভিজ্ঞতা কমিয়ে দেয় এমন উচ্চ ল্যাটেন্সির দিকে নজর রাখুন। ইউজার ইনপুট যখন মডেলের উইন্ডোর বাইরে চলে যায় তখন কনটেক্সট লেন্থ ওভারফ্লো খেয়াল করুন। এবং কোয়ালিটি রিগ্রেশনের (quality regression) দিকে নজর রাখুন, যা সবথেকে সূক্ষ্ম ব্যর্থতা: প্রোভাইডার-সাইড আপডেটের পরে মডেলটি রেসপন্স করে ঠিকই, কিন্তু এর উত্তরগুলো এলোমেলো হয়ে যায়, অস্পষ্ট হয়ে যায় বা ফরম্যাটিং নির্দেশাবলী উপেক্ষা করে।
এই প্রতিটি সিগন্যাল আলাদা প্রতিক্রিয়া ট্রিগার করা উচিত। একটি টাইম-আউটের জন্য রিট্রাই (retry) করা উচিত। খারাপ JSON-এর জন্য মডেল পরিবর্তন করা উচিত। রেট লিমিট মানে হতে পারে আপনার সম্পূর্ণ ভিন্ন একজন প্রোভাইডারের সাহায্য নেওয়া প্রয়োজন।
ওয়ার্কফ্লোর সাথে ফলব্যাক মেলান
প্রতিটি কাজের জন্য একই ফলব্যাক রুল ব্যবহার করা বিপর্যয়ের কারণ হতে পারে। একটি চ্যাটবট এবং ব্যাকগ্রাউন্ড ডেটা এক্সট্রাকশন জবের প্রয়োজন সম্পূর্ণ ভিন্ন। আপনার ওয়ার্কফ্লোর ওপর ভিত্তি করে ফলব্যাক ডিজাইন করুন।
Chatbots-এর প্রয়োজন গতি এবং কথোপকথনের ছন্দ। ব্যবহারকারীরা কিছুটা সাধারণ উত্তর মেনে নেবেন, কিন্তু তারা পাঁচ সেকেন্ডের বিরতি মেনে নেবেন না। যদি আপনার প্রাথমিক মডেল ধীর হয়ে যায়, তবে দ্রুত একটি ব্যাকআপে চলে যান — প্রায়শই একই মডেল ফ্যামিলির একটি ছোট ভেরিয়েন্ট, অথবা অন্য কোনো প্রোভাইডারের স্পিড-টিয়ার অফার। কথোপকথন চালিয়ে যান।
RAG systems-এর প্রয়োজন নির্ভুলতা। আপনি ইতিমধ্যে রিট্রিভাল (retrieval) — ভেক্টর সার্চ, র র্যাঙ্কিং, এমনকি ওয়েব ক্রলিং — এর জন্য খরচ করেছেন। যদি জেনারেটর প্রদত্ত কনটেক্সট মেনে চলতে ব্যর্থ হয়, তবে সেই সমস্ত কাজ বৃথা যাবে। একটি মডেল যা নির্ভুলভাবে নির্দেশ অনুসরণ করতে এবং দীর্ঘ কনটেক্সট বুঝতে সক্ষম, তার ওপর ফলব্যাক করুন, এমনকি সেটি ধীরগতির হলেও।
Coding tools-এর প্রয়োজন লজিক। ডেভেলপাররা বাগলা ভরা ব্যাখ্যার চেয়ে সঠিক সিনট্যাক্স এবং বৈধ API কল চান। যদি প্রাথমিক মডেল ফাংশন নিয়ে ভুল তথ্য (hallucinating) দিতে শুরু করে বা এজ কেসগুলো (edge cases) বাদ দিয়ে দেয়, তবে কোডে ফাইন-টিউন করা একটি মডেলে সুইচ করুন। কম্পাইল-রেডি আউটপুটের বিনিময়ে কিছুটা উচ্চ ল্যাটেন্সি মেনে নিন।
JSON extraction-এর প্রয়োজন স্ট্রাকচার। স্ট্রাকচার্ড জেনারেশন বেশ নাজুক। একটি মিসিং ব্র্যাকেট বা ভুলভাবে এস্কেপ করা কোট পরবর্তী ডেটাবেস রাইটকে নষ্ট করে দিতে পারে। যদি আপনার প্রাথমিক মডেল স্কিমা মেনে চলার ক্ষেত্রে বিচ্যুত হয়, তবে একবার রিট্রাই করুন, তারপর উচ্চ ফরম্যাটিং নির্ভরযোগ্যতা সম্পন্ন একটি মডেলে সুইচ করুন। অদ্ভুতভাবে, বাধ্যতা বা অবিডিয়েন্সের (obedience) জন্য টিউন করা ছোট মডেলগুলো প্রায়শই এই নির্দিষ্ট কাজে সৃজনশীল বড় মডেলগুলোকে ছাড়িয়ে যায়।
Automation and batch jobs-এর প্রয়োজন খরচ নিয়ন্ত্রণ। ব্যাকগ্রাউন্ড ক্লাসিফায়ার, লগ সামারাইজার এবং নোটিফিকেশন জেনারেটরগুলো নিরবচ্ছিন্নভাবে চলে। আপনার প্রাথমিক মডেলে দামের হঠাৎ বৃদ্ধি একটি সামঞ্জস্যপূর্ণ দৈনিক বিলকে বাজেটের সংকটে পরিণত করতে পারে। এই নন-ক্রিটিক্যাল পাথগুলোর জন্য একটি সস্তা ও স্থিতিশীল মডেল স্ট্যান্ডবাই রাখুন। যদি আউটপুট কোয়ালিটি সামান্য কমে যায়, তবে ব্যবসায়িক প্রভাব সাধারণত নগণ্য হয়।
সুইচ করার আগে আপনার সীমাবদ্ধতাগুলো জানুন
অন্ধভাবে মডেল পরিবর্তন করা নতুন সমস্যা তৈরি করে। আপনি যদি একটি শক্তিশালী মডেল থেকে দুর্বল মডেলে নেমে যান, তবে ব্যাকআপ মডেলটি সূক্ষ্ম প্রম্পটগুলো ভুল বুঝতে পারে এবং এমন আবর্জনা (garbage) তৈরি করতে পারে যা পরবর্তী ধাপের ত্রুটির কারণ হয়ে দাঁড়ায়। আপনি যদি একটি বড় মডেলে উন্নীত হন, তবে আপনি কোয়ালিটির সমস্যা সমাধান করতে পারেন কিন্তু কয়েক ঘণ্টার মধ্যেই আপনার বাজেট শেষ করে ফেলতে পারেন।
কোনো মডেলকে ফলব্যাক স্ট্যাটাসে উন্নীত করার আগে, ছয়টি ফ্যাক্টরের ভিত্তিতে সেটি অডিট করুন।
- মডেলের সক্ষমতা: এটি কি প্রকৃতপক্ষে প্রম্পটটি সামলাতে পারবে, নাকি ভিন্নভাবে ব্যর্থ হবে?
- ভাষার সমর্থন: আপনার ব্যাকআপ মডেলটি ইংরেজিতে পারদর্শী হতে পারে কিন্তু হিন্দি, স্প্যানিশ বা জাপানি ভাষায় ভুল তথ্য (hallucinate) দিতে পারে।
- কনটেক্সট উইন্ডো সাইজ: আপনার ইনপুট যদি ৫০,০০০ টোকেন হয়, তবে ১৬,০০০ টোকেন লিমিট থাকা একটি ফলব্যাক মডেল তথ্য কেটে ফেলবে এবং নীরবে অর্থহীন করে তুলবে।
- ল্যাটেন্সি: আপনার অঞ্চলের জন্য কিছু প্রোভাইডার অন্যদের তুলনায় ধারাবাহিকভাবে দ্রুততর।
- প্রতি অনুরোধের খরচ: একটি নির্দিষ্ট সীমা নির্ধারণ করুন। সর্বোচ্চ ব্যবহারের সময় ফলব্যাক মডেলের খরচ কত হবে তা জেনে রাখুন।
- আউটপুট নির্ভরযোগ্যতা: এটি কি প্রতিবার আউটপুট ফরম্যাট অনুসরণ করবে, নাকি কেবল বিশেষ সময়ে?
কার্যকর চারটি ফলব্যাক প্যাটার্ন
প্রতিটি ব্যর্থতার জন্য একই প্রতিকার প্রয়োজন হয় না। বিভিন্ন ধরণের ফলব্যাকের একটি টুলকিট তৈরি করুন এবং সেগুলো সুচিন্তিতভাবে প্রয়োগ করুন।
রিট্রাই ফলব্যাক (Retry fallback)। সাময়িক নেটওয়ার্ক ত্রুটি এবং প্রোভাইডারের স্বল্পস্থায়ী বিভ্রাটের জন্য, এক্সপোনেনশিয়াল ব্যাকঅফ (exponential backoff) সহ একই মডেলটি পুনরায় চেষ্টা করুন। ভুল ফরম্যাটের আউটপুট বা কনটেক্সট ওভারফ্লোর ক্ষেত্রে পুনরায় চেষ্টা করবেন না — একই ভুল প্রম্পট দুবার পাঠানো খুব কমই কাজে দেয়।
সমতুল্য ফলব্যাক (Equivalent fallback)। যখন আপনার প্রাথমিক প্রোভাইডার ডাউন থাকে বা কাজের গতি কমিয়ে দেয় (throttled), তখন অন্য প্রোভাইডারের একটি সমতুল্য মডেলে চলে যান। একটি ফ্রন্টিয়ার মডেল থেকে মোটামুটি একই শ্রেণির অন্য একটি মডেলে পরিবর্তন করতে সাধারণত প্রম্পট খুব সামান্য পরিবর্তন করলেই চলে এবং আউটপুটের মান বজায় থাকে।
সাশ্রয়ী ফলব্যাক (Cheaper fallback)। কম গুরুত্বপূর্ণ কাজের জন্য একটি স্বল্পমূল্যের মডেল সংরক্ষণ করুন। যদি সাশ্রয়ী বিকল্পটি হিমশিম খায়, তবে কম গুরুত্বপূর্ণ কাজে প্রিমিয়াম টোকেন খরচ না করে ফিচারটির কার্যকারিতা কিছুটা কমিয়ে দিন (degrade gracefully)।
শক্তিশালী ফলব্যাক (Stronger fallback)। এটি শুনতে উল্টো মনে হতে পারে, কিন্তু এটি অপরিহার্য। যখন একটি মিড-টিয়ার মডেল জটিল যুক্তি, বহু-ধাপের গণিত বা সূক্ষ্ম আইনি বিশ্লেষণে বারবার ব্যর্থ হয়, তখন আরও সক্ষম একটি মডেলে উন্নীত (escalate) করুন। এটি কেবল উচ্চ-মূল্যের ইউজার পাথগুলোর জন্য সীমিতভাবে ব্যবহার করুন যেখানে নির্ভুলতা রাজস্ব বা নিরাপত্তা নিশ্চিত করে।
আপনার আর্কিটেকচারে লজিকটি অন্তর্ভুক্ত করুন
অ্যাপ্লিকেশন কোডের ডজন ডজন try-catch ব্লকের মধ্যে ফলব্যাক লজিক ছড়িয়ে দেবেন না। রাউটিংকে অবকাঠামো (infrastructure) হিসেবে বিবেচনা করুন। একটি মিডলওয়্যার লেয়ার তৈরি করুন যা টাস্কের ধরন অনুযায়ী মডেলের একটি ক্রমানুসারী তালিকা তৈরি করবে, যেখানে প্রতিটি মডেলের নিজস্ব টাইমআউট থ্রেশহোল্ড, রিট্রাই পলিসি এবং সার্কিট ব্রেকার থাকবে।
ফলব্যাক ইভেন্টগুলোকে প্রথম শ্রেণির মেট্রিক (first-class metrics) হিসেবে ট্র্যাক করুন। এরর রেট আপনাকে জানায় কখন একটি মডেল ডাউন আছে; আর ফলব্যাক রেট আপনাকে জানায় কখন একটি মডেল কাজের জন্য অনুপযুক্ত। যদি আপনার সিস্টেম ৩০ বা ৪০ শতাংশ সময় ফলব্যাক ব্যবহার করে, তবে বুঝতে হবে আপনার প্রাথমিক মডেলটি কাজের চাপের সাথে সামঞ্জস্যপূর্ণ নয়। এটি কেবল এরর হ্যান্ডলিং নয়, বরং আপনার মডেল নির্বাচনের পুনরায় মূল্যায়ন করার একটি সংকেত।
সুনির্দিষ্ট বাজেট নির্ধারণ করুন। ফলব্যাক কখনোই সীমাহীন হওয়া উচিত নয়। লোড বাড়লে যদি আপনি প্রিমিয়াম মডেলে উন্নীত হন, তবে প্রতি মিনিটে সেই অনুরোধের সংখ্যা সীমিত (cap) করে রাখুন। আপনার আপটাইম রক্ষার মতোই কঠোরভাবে আপনার খরচও নিয়ন্ত্রণ করুন।
আসল পরীক্ষা
আপনি ডেমোর জন্য এটি তৈরি করছেন না। আপনি এটি তৈরি করছেন মঙ্গলবার দুপুর ৩টার জন্য, যখন এপিআই ধীরগতির হবে, ব্যবহারকারী অপেক্ষা করবেন এবং ফিন্যান্স টিম জিজ্ঞাসা করবে কেন এআই বিল দ্বিগুণ হয়ে গেল। একটি পরিপক্ক ফলব্যাক কৌশল পণ্যটিকে সচল রাখে, ব্যবহারকারীর অভিজ্ঞতাকে সামঞ্জস্যপূর্ণ রাখে এবং আপনার খরচকে অনুমানযোগ্য রাখে।
আপনার প্রাথমিক মডেলটি সাবধানে নির্বাচন করুন। তবে সেটি যখন আপনাকে হতাশ করবে, তখন কী হবে তা ডিজাইন করতে দ্বিগুণ সময় ব্যয় করুন।
উৎস: How to Design AI Model Fallback Rules for Multi-Model Apps
কমিউনিটি: GyaanSetu AI on Telegram