“কোন মডেলটি আমরা ব্যবহার করব?”—এটি আগে একটি API-সংক্রান্ত প্রশ্নের মতো শোনাত। ক্রমবর্ধমান সংখ্যক প্রতিষ্ঠানে এটি এখন ক্রয়, কর্মদক্ষতা-প্রকৌশল এবং আর্কিটেকচার-সংক্রান্ত প্রশ্নের কাছাকাছি।
এই পরিবর্তনের পেছনে একটি সরল বিকাশ রয়েছে: এখন অনেক মডেল আছে, যেগুলো বহু প্রদানকারীর মাধ্যমে দেওয়া হয় এবং যাদের সক্ষমতা, দাম, লেটেন্সির ধরন, স্থাপনের বিকল্প ও চুক্তিগত শর্তে উল্লেখযোগ্য পার্থক্য রয়েছে। Stripe-এর OpenRouter অধিগ্রহণের ঘোষিত চুক্তিটি একটি গুরুত্বপূর্ণ ইঙ্গিত। OpenRouter-এর একক API 80-এরও বেশি প্রদানকারীর 400-এর বেশি মডেলকে সংযুক্ত করে; এর রাউটিং মানদণ্ডের মধ্যে রয়েছে কাজের জটিলতা, দাম, গতি, নির্ভরযোগ্যতা, লেটেন্সি, থ্রুপুট এবং প্রদানকারী-নির্দিষ্ট খরচ।
উদীয়মান এই কাজের জন্য নতুন কোনো পদবি থাকা আবশ্যক নয়। এটি AI প্ল্যাটফর্ম ইঞ্জিনিয়ারিং, আর্কিটেকচার, ক্রয়, ইনফারেন্স অপারেশনস বা প্রোডাক্ট ইঞ্জিনিয়ারিংয়ের মধ্যে বিস্তৃত হতে পারে। তবে এর দায়িত্ব ক্রমশ স্পষ্ট হয়ে উঠছে: কোন কাজ কোন মডেল করবে, কী সীমাবদ্ধতার মধ্যে করবে, কী ব্যাকআপ থাকবে এবং কোন প্রমাণের ভিত্তিতে সিদ্ধান্ত নেওয়া হবে—তা নির্ধারণ করা।
রাউটিং অবকাঠামোর ছদ্মবেশে একটি নীতিগত সিদ্ধান্ত
একজন সরলমনা রাউটার জিজ্ঞেস করে: “কোন মডেলটি সবচেয়ে সস্তা?” একটি কার্যকর রাউটার আরও নির্দিষ্ট প্রশ্ন করে: “এই অনুরোধের গুণমান, লেটেন্সি, নির্ভরযোগ্যতা, গোপনীয়তা ও পরিচালনাগত প্রয়োজনীয়তা পূরণ করে—এমন সবচেয়ে কম খরচের মডেল কোনটি?”
কাজভেদে এই প্রয়োজনীয়তাগুলো বদলে যায়। গ্রাহক-সহায়তা শ্রেণিবিন্যাসকারীর পূর্বানুমানযোগ্য কাঠামোবদ্ধ আউটপুট এবং কম লেটেন্সি প্রয়োজন হতে পারে। কঠিন কোডিংয়ের কাজ ধীরগতির কিন্তু বেশি সক্ষম কোনো মডেল ব্যবহারের যৌক্তিকতা তৈরি করতে পারে। বিপুল পরিমাণ সারসংক্ষেপ তৈরির পাইপলাইন ছোট কোনো মডেলকে অগ্রাধিকার দিতে পারে, বিশেষ করে পরীক্ষার পর তার মান যথেষ্ট হলে। নিয়ন্ত্রিত কোনো কর্মপ্রবাহে টোকেনের দাম যা-ই হোক, নির্দিষ্ট অঞ্চল, ডেটা সংরক্ষণ নীতি বা প্রদানকারীর চুক্তি প্রয়োজন হতে পারে।
এই কারণেই রাউটিং শুধু অ্যাপ্লিকেশন কোডের বিষয় নয়; আর্কিটেকচার পর্যালোচনায়ও এর স্থান রয়েছে। রুট নির্ধারণ করে শুধু একটি ইনভয়েস নয়। এটি ডেটা কোথায় সংরক্ষিত হবে, বিভ্রাটের ঝুঁকি, পর্যবেক্ষণযোগ্যতা, প্রতিক্রিয়ার সামঞ্জস্য, টুল ব্যবহারের আচরণ এবং পরবর্তী ধাপে কতটা মানবিক পর্যালোচনা প্রয়োজন—এসবকেও প্রভাবিত করতে পারে।
একটি গুরুতর রাউটিং কার্যক্রমের পেছনে থাকা চারটি শৃঙ্খলা
1. ক্রয়: শুধু শিরোনামে থাকা টোকেনের দাম নয়, পুরো পরিষেবার তুলনা করুন
মডেলের দাম তুলনা করা সহজ, কিন্তু ভুলভাবে করাও সহজ। ইনপুট ও আউটপুট টোকেনের হার ভিন্ন হতে পারে। ক্যাশ করা ইনপুট, ব্যাচ প্রসেসিং, অগ্রাধিকার পরিষেবা এবং দীর্ঘ-কনটেক্সটের অনুরোধ হিসাব বদলে দিতে পারে। কোনো প্রদানকারীর নামমাত্র দাম রিট্রাই, রেট লিমিট, সহায়তা, ন্যূনতম অঙ্গীকার, ইগ্রেস বা পরিবর্তনের প্রকৌশলগত খরচ সম্পর্কেও সামান্যই বলে।
রাউটিংয়ের দায়িত্বে থাকা ব্যক্তির এমন ক্ষেত্রসমৃদ্ধ একটি মডেল-ও-প্রদানকারী তালিকা বজায় রাখা উচিত:
- ইনপুট, আউটপুট, ক্যাশ করা এবং ব্যাচ মূল্য নির্ধারণ;
- কনটেক্সট ও আউটপুটের সীমা;
- নথিভুক্ত রেট লিমিট এবং পর্যবেক্ষিত থ্রুপুট;
- শুধু গড় লেটেন্সি নয়, লেটেন্সির বণ্টন;
- প্রাপ্যতা এবং টাইমআউটের আচরণ;
- ডেটা ব্যবহার, সংরক্ষণ, আবাসন এবং চুক্তিগত শর্ত;
- টুল কল, কাঠামোবদ্ধ আউটপুট, ভিশন এবং স্ট্রিমিংসহ সমর্থিত সক্ষমতা;
- ব্যাকআপ ও স্থানান্তরের বিকল্প।
ফলাফলটি মডেলের নামের তালিকার চেয়ে প্রযুক্তিগত উপকরণের বিল অব ম্যাটেরিয়ালের কাছাকাছি। দাম, নীতি, মডেলের সংস্করণ বা ব্যবসায়িক পরিমাণ বদলালে এটি পর্যালোচনা করা উচিত।
2. কর্মদক্ষতা প্রকৌশল: লিডারবোর্ড নয়, কাজের পরিমাপ করুন
সাধারণ বেঞ্চমার্ক দিকনির্দেশনার জন্য সহায়ক হতে পারে, কিন্তু রাউটিংয়ের সিদ্ধান্তের জন্য কাজভিত্তিক পরীক্ষা দরকার। কোনো মডেল প্রকাশ্য কোডিং বেঞ্চমার্কে ভালো করতে পারে, কিন্তু কোনো প্রতিষ্ঠানের অভ্যন্তরীণ রিপোজিটরি, নামকরণের রীতি, টুল স্কিমা বা নিরাপত্তা নিয়ন্ত্রণের জন্য সেটিই সেরা পছন্দ নাও হতে পারে।
বাস্তব অনুরোধ থেকে একটি প্রতিনিধিত্বশীল মূল্যায়ন সেট তৈরি করুন, যেখানে সংবেদনশীল উপাদান সরিয়ে ফেলা হয়েছে বা নিয়ন্ত্রিত রয়েছে। যে ফলাফলগুলো গুরুত্বপূর্ণ, সেগুলো লেবেল করুন: তথ্যগত সঠিকতা, বৈধ JSON, সফল টুল নির্বাচন, কোড-টেস্টে সাফল্য, প্রত্যাখ্যানের আচরণ, এস্কেলেশনের প্রয়োজন এবং গ্রহণযোগ্য শৈলী। এরপর খরচ, প্রথম টোকেন পেতে সময়, মোট লেটেন্সি, টাইমআউটের হার, রিট্রাইয়ের হার এবং সম্পূর্ণতার দৈর্ঘ্য নথিবদ্ধ করুন।
ফলাফলকে খুব তাড়াতাড়ি একটি মাত্র স্কোরে নামিয়ে আনবেন না। ওজনযুক্ত স্কোর গুরুতর কোনো ব্যর্থতার ধরন আড়াল করতে পারে। উদাহরণস্বরূপ, গড় মানে চমৎকার কিন্তু ঘন ঘন ভুলভাবে গঠিত টুল কল করে—এমন কোনো মডেল স্বয়ংক্রিয় কর্মপ্রবাহের জন্য অনুপযুক্ত হতে পারে। কোনো ধীরগতির মডেল অর্থনৈতিকভাবে বেশি উপযোগী হতে পারে, যদি তার উত্তর ব্যয়বহুল মানবিক পর্যালোচনার প্রয়োজন কমায়।
চ্যাম্পিয়ন-অ্যান্ড-চ্যালেঞ্জার প্রক্রিয়া ব্যবহার করুন: বর্তমানে অনুমোদিত একটি রুট বজায় রাখুন, একই করপাসের বিরুদ্ধে বিকল্পগুলো পরীক্ষা করুন এবং কোনো চ্যালেঞ্জারকে তখনই উন্নীত করুন, যখন সেটি স্পষ্ট গুণমান ও পরিচালনাগত সীমা অতিক্রম করে। প্রদানকারীর রিপোর্ট করা দাবিগুলোকে পরীক্ষা পরিকল্পনার উপাদান হিসেবে বিবেচনা করা উচিত, আপনার পরিবেশে কোনো মডেল একইভাবে কাজ করবে—এর প্রমাণ হিসেবে নয়।
৩. স্থাপত্য: মডেল নির্বাচন পরিবর্তনযোগ্য রাখুন
মডেল-নির্দিষ্ট অনুমানগুলো যখন একটি অ্যাপ্লিকেশনের সর্বত্র ছড়িয়ে পড়ে, তখন রাউটিং ব্যয়বহুল হয়ে ওঠে। একটি স্থিতিস্থাপক নকশা ব্যবসায়িক কাজকে প্রদানকারীর কল থেকে আলাদা রাখে।
একটি অভ্যন্তরীণ সক্ষমতা-চুক্তি সংজ্ঞায়িত করুন। এতে নির্দিষ্ট করা থাকতে পারে যে “শ্রেণিবিন্যাস” অপারেশন একটি নির্দিষ্ট স্কিমা, আত্মবিশ্বাস বা বিরত থাকার ফিল্ড, একটি মডেল শনাক্তকারী এবং একটি ট্রেস শনাক্তকারী ফেরত দেবে। “খসড়া উত্তর” অপারেশনে স্বরের সীমাবদ্ধতা, উদ্ধৃতির প্রয়োজনীয়তা এবং সর্বোচ্চ বিলম্বতার বাজেট নির্দিষ্ট করা থাকতে পারে। এরপর প্রদানকারী অ্যাডাপ্টারগুলো সেই চুক্তিকে পৃথক API-তে অনুবাদ করবে।
প্রম্পট, স্কিমা, টুলের সংজ্ঞা, নিরাপত্তা বিধি এবং রুট নীতিগুলো সংস্করণ-নিয়ন্ত্রিত রাখুন। প্রতিটি অনুরোধ কোন মডেল স্ন্যাপশট ও প্রদানকারী পরিবেশন করেছে তা নথিবদ্ধ করুন। সংবেদনশীল ব্যবহারকারীর কনটেন্ট অপ্রয়োজনীয়ভাবে সংরক্ষণ না করেও যাতে একটি সিদ্ধান্ত পুনরুৎপাদন করা যায়, সে জন্য পর্যাপ্ত তথ্য সংরক্ষণ করুন।
ফলব্যাকগুলো ভেবেচিন্তে নকশা করুন। ফলব্যাক হতে পারে অন্য কোনো প্রদানকারী, ছোট কোনো মডেল, সারিবদ্ধ কোনো ওয়ার্কফ্লো, অথবা মানব পর্যালোচনার পথ। এটি যেন নিঃশব্দে কাজটির অর্থ বদলে না দেয়। কাঠামোবদ্ধ আউটপুট বাধ্যতামূলক হলে, ফলব্যাককে একই চুক্তি সমর্থন করতে হবে অথবা একটি নিয়ন্ত্রিত এসকেলেশন শুরু করতে হবে।
৪. শাসনব্যবস্থা: কখন স্বয়ংক্রিয়ভাবে রাউট না করতে হবে তা নির্ধারণ করুন
কিছু অনুরোধ সবচেয়ে কম খরচের উপলব্ধ মডেলে—অথবা কোনো বাহ্যিক মডেলেই—পাঠানো উচিত নয়। রাউটিং নীতিতে গোপনীয় তথ্য, উচ্চ-প্রভাবসম্পন্ন সিদ্ধান্ত, অসমর্থিত ভাষা, অস্বাভাবিকভাবে দীর্ঘ কনটেক্সট, অথবা মানব অনুমোদনের ধাপ প্রয়োজন এমন কাজের জন্য বর্জন-নিয়ম থাকা দরকার।
দলগুলোর এটিও আলাদা করে দেখা উচিত যে কোনো মডেল প্রযুক্তিগতভাবে উপলব্ধ কি না এবং নির্দিষ্ট ব্যবহারের জন্য অনুমোদিত কি না। ব্যবসায়িক ইউনিটভেদে ক্রয় ও আইনি প্রয়োজনীয়তা ভিন্ন হতে পারে। কোনো মডেল মূল্যায়নে চমৎকার হতে পারে, তবু যে ওয়ার্কফ্লোর তথ্য-পরিচালনার শর্তগুলো প্রতিষ্ঠানের উপযোগী নয়, সেখানে সেটি ব্যবহারযোগ্য নাও হতে পারে।
একটি ব্যবহারিক রাউটিং টেবিল
একটি প্রাথমিক নীতি সহজ ও সুস্পষ্ট হতে পারে:
| কাজের শ্রেণি | প্রাথমিক উদ্দেশ্য | সম্ভাব্য রুট | এসকেলেশনের ট্রিগার |
|---|---|---|---|
| উচ্চ-পরিমাণের এক্সট্রাকশন | বৈধ স্কিমা এবং কম ইউনিট খরচ | কঠোর আউটপুট যাচাইসহ ছোট বা মাঝারি আকারের মডেল | স্কিমা ব্যর্থতা বা কম আত্মবিশ্বাস |
| জটিল বিশ্লেষণ | গুণমান এবং প্রমাণ ব্যবস্থাপনা | বৃহত্তর বিলম্বতা-বাজেটসহ অধিক সক্ষম মডেল | প্রমাণের ঘাটতি, অস্পষ্টতা, অথবা নীতি-সংক্রান্ত সতর্কসংকেত |
| ইন্টার্যাক্টিভ সহায়তা | দ্রুত অনুভূত প্রতিক্রিয়া | কম-বিলম্বতার মডেল, যার পরে প্রয়োজনে পরিমার্জন | কম আত্মবিশ্বাস বা ব্যবহারকারীর গভীরতার অনুরোধ |
| সংবেদনশীল কর্মপ্রবাহ | অনুমোদিত ডেটা ব্যবস্থাপনা ও নিরীক্ষাযোগ্যতা | চুক্তি-অনুমোদিত প্রদানকারী বা নিয়ন্ত্রিত স্থাপন | অননুমোদিত ডেটা, কার্যক্রম বা বিচারব্যবস্থা |
সঠিক টেবিলটি প্রতিষ্ঠানভেদে ভিন্ন হবে। গুরুত্বপূর্ণ বিষয় হলো, রাউটিংয়ের নিয়মগুলো যেন পণ্য, নিরাপত্তা, অর্থ এবং প্রকৌশল বিভাগের সংশ্লিষ্টরা সহজে পড়তে পারেন—কোনো শর্তসাপেক্ষ বিবৃতির আড়ালে চাপা না থাকে।
ক্যারিয়ার গড়ে তোলা মানুষের জন্য এর অর্থ কী
এই কাজের জন্য সবচেয়ে শক্তিশালী প্রার্থীরা কয়েক ধরনের দক্ষতার সমন্বয় ঘটাবেন। সক্ষমতা ও অবনতির বিষয়ে যুক্তি করার মতো মেশিন লার্নিং সম্পর্কে তাঁদের যথেষ্ট জ্ঞান থাকবে; লেটেন্সি, পুনঃচেষ্টা, রেট সীমা এবং ব্যর্থতার ধরন সামলানোর মতো সিস্টেম ইঞ্জিনিয়ারিং জ্ঞান থাকবে; মোট খরচ মডেল করার মতো অর্থসংক্রান্ত জ্ঞান থাকবে; এবং প্রদানকারীর প্রতিশ্রুতি ও বিধিনিষেধ মূল্যায়নের মতো প্রকিউরমেন্ট ও গভর্ন্যান্স সম্পর্কে যথেষ্ট ধারণা থাকবে।
তাঁরা সিদ্ধান্তের নথি লিখতেও স্বচ্ছন্দ হবেন। একটি কার্যকর নথিতে ব্যাখ্যা থাকে কেন কোনো রুট বেছে নেওয়া হয়েছে, কোন প্রমাণ সেটিকে সমর্থন করে, কী কী ঝুঁকি রয়ে গেছে এবং কোন ঘটনা পুনর্মূল্যায়নের সূচনা করবে। সর্বশেষ মডেলের নাম মুখস্থ করার চেয়ে এটি বেশি মূল্যবান, কারণ মডেলের নাম ও দাম পরিবর্তিত হতেই থাকবে।
বড় কোনো প্রোডাকশন সিস্টেমের প্রয়োজন ছাড়াই একটি সংক্ষিপ্ত পোর্টফোলিও প্রকল্প এই দক্ষতা প্রদর্শন করতে পারে। একটি কাজ নিন, অপসারিত-পরিচয়যুক্ত একটি মূল্যায়ন সেট তৈরি করুন, একটি সাধারণ ইন্টারফেসের আড়ালে তিনটি মডেল প্রদানকারী বা স্থানীয় মডেল সংযুক্ত করুন, এবং বিভিন্ন ভলিউমে গুণমান, স্কিমার বৈধতা, লেটেন্সির পার্সেন্টাইল, ব্যর্থতার হার ও আনুমানিক মাসিক খরচ তুলনা করুন। সংবেদনশীল ইনপুটের জন্য নীতিমালা-ভিত্তিক নিয়ম এবং একটি বিকল্প পথ যোগ করুন। পরীক্ষার পদ্ধতি ও সীমাবদ্ধতাগুলো প্রকাশ করুন।
প্রকল্পটি ঠিক কী প্রমাণ করে, সে বিষয়ে নির্ভুল থাকুন। এটি প্রমাণ করে না যে একটি মডেল সর্বজনীনভাবে সেরা। এটি প্রমাণ করে যে আপনি একটি অস্পষ্ট মডেল-বাছাইয়ের সমস্যাকে পরিমাপযোগ্য পরিচালন নীতিতে রূপ দিতে পারেন।
ক্যারিয়ারের সংকেত
মডেল রাউটিং কৌশলগতভাবে গুরুত্বপূর্ণ হয়ে উঠছে, কারণ বুদ্ধিমত্তা আর একক, নির্দিষ্ট নির্ভরতা নয়। এটি বিভিন্ন সমঝোতা ও পরিবর্তনশীল অর্থনীতিসম্পন্ন পরিষেবাগুলোর একটি পোর্টফোলিও। যে দলগুলো এই পোর্টফোলিওকে বিনিময়যোগ্য অবকাঠামো হিসেবে বিবেচনা করে, তারা খরচ কমাতে পারে, কিন্তু একই সঙ্গে গুণমান, কমপ্লায়েন্স ও নির্ভরযোগ্যতার গোপন সমস্যা তৈরি করতে পারে। আর যে দলগুলো এটিকে স্থায়ীভাবে একটি একক মডেলের প্রতি অঙ্গীকার হিসেবে দেখে, তারা আরও ভালো বিকল্পগুলো হাতছাড়া করতে পারে।
উদীয়মান এই শাস্ত্রটি ওই দুই প্রান্তের মাঝখানে অবস্থান করে: প্রদানকারী পরিবর্তনের জন্য যথেষ্ট বিমূর্ত, কাজের গুণমান বজায় রাখার জন্য যথেষ্ট নির্দিষ্ট, এবং পছন্দটিকে ন্যায্যতা দেওয়ার জন্য যথেষ্ট প্রমাণনির্ভর। এটাই মডেল-রাউটিংয়ে ক্যারিয়ারের সুযোগ—একবার কোনো API বেছে নেওয়া নয়, বরং এমন সিদ্ধান্তব্যবস্থা তৈরি করা, যা বারবার সঠিক পছন্দ করতে থাকে।
Tom Whitfield হলেন AI Career Brief-এর দায়বদ্ধ মানব সম্পাদক, যেখানে AI-এর যুগে কাজ করার জন্য প্রয়োজনীয় দক্ষতা, ভূমিকা ও বিচক্ষণ পদক্ষেপ নিয়ে আলোচনা করা হয়।