AI model card-এ score দেখেই সিদ্ধান্ত নয়—আগে পাঁচটি ঘর মিলিয়ে নিন

AI model card পড়ার মূল নিয়ম হলো score-কে চূড়ান্ত সিদ্ধান্ত না ধরে একটি নির্দিষ্ট পরীক্ষার ফল হিসেবে দেখা। মডেলটি বাস্তব কাজে উপযুক্ত কি না বুঝতে আগে পাঁচটি ঘর মিলিয়ে নিন: intended use, training data, evaluation source, subgroup breakdown এবং limitations। কোনো ঘরের তথ্য না থাকলে মডেলটি অযোগ্য প্রমাণিত হয় না, তবে score-টি আপনার কাজের উপযুক্ততা একা প্রমাণও করে না।

শুরুতেই দুটি প্রশ্ন করুন: মডেলটি যে কাজের জন্য তৈরি, আপনার কাজ কি ঠিক সেটিই; আর প্রকাশিত ফলটি কোন dataset, metric ও evaluator-এর? Hugging Face-এর model card নির্দেশিকা intended use, সম্ভাব্য limitation, training information, ব্যবহৃত dataset ও evaluation result নথিভুক্ত করতে বলে। তথ্যগুলো শুধু উপস্থিত কি না দেখলে হবে না—এগুলোর পারস্পরিক সম্পর্কও আপনার ব্যবহারের পরিস্থিতির সঙ্গে মিলতে হবে।

পাঁচ ঘরের worksheet পূরণ করুন

Model card, সংশ্লিষ্ট paper এবং প্রকাশিত evaluation record থেকে প্রতিটি ঘরের উত্তর এক লাইনে লিখুন। অনুমান করে শূন্যস্থান পূরণ করবেন না; প্রয়োজনীয় তথ্য না পেলে “উল্লেখ নেই” লিখুন। এই অনুপস্থিতিই বলে দেবে কোন দাবির প্রমাণ অসম্পূর্ণ এবং কোথায় নিজস্ব পরীক্ষা প্রয়োজন।

1. Intended use: মডেলটি কোন task, input, ভাষা, domain ও ব্যবহারকারীর জন্য তৈরি—সেগুলো লিখুন। পাশাপাশি out-of-scope use বা নিষিদ্ধ ব্যবহারও নোট করুন। আপনার কাজ বা ঝুঁকির মাত্রা আলাদা হলে প্রকাশিত score সরাসরি প্রযোজ্য ধরে নেওয়া যাবে না।
2. Training data: প্রকাশিত উৎস, সময়কাল, ভাষা, domain ও coverage লিখুন; filtering বা deduplication সম্পর্কে তথ্য থাকলে সেটিও রাখুন। Dataset-এর নাম দেখেই আপনার ধরনের input যথেষ্ট ছিল ধরে নেবেন না। ব্যক্তিগত, সংবেদনশীল বা লাইসেন্স-সীমাবদ্ধ data সম্পর্কে অস্পষ্টতাও আলাদা ঝুঁকি।
3. Evaluation source: test dataset, metric, model version, prompt বা decoding setup এবং কে evaluation চালিয়েছে—সব শনাক্ত করুন। Model author, স্বাধীন গবেষক এবং community leaderboard-এর ফলের উৎস এক নয়।
4. Subgroup breakdown: ভাষা, অঞ্চল, জনসমষ্টি, domain, input quality বা প্রাসঙ্গিক operating condition অনুযায়ী আলাদা ফল আছে কি না দেখুন। আপনার ব্যবহারকারীদের প্রতিনিধিত্বকারী slice অনুপস্থিত হলে aggregate score স্থানীয় performance জানায় না।
5. Limitations: known failure mode, বাদ দেওয়া use case, দুর্বল ভাষা বা domain, safety caveat এবং human review-এর প্রয়োজন লিখুন। এরপর দেখুন সীমাবদ্ধতাটি আপনার deployment-এ ঘটার বাস্তব সুযোগ আছে কি না।

Score তুলনার আগে একই পরীক্ষার পরিচয় নিশ্চিত করুন

দুটি score পাশাপাশি রাখার আগে task, dataset, metric ও evaluator একই বা যথেষ্ট সমতুল্য কি না যাচাই করুন। নাম এক হলেও dataset split, prompt, shots, preprocessing, model version কিংবা metric aggregation আলাদা হতে পারে। এসব শর্ত না মিললে সংখ্যাগুলো একই ক্ষমতা মাপছে—এমন সিদ্ধান্তের ভিত্তি থাকে না।

Evaluator-এর পরিচয় আলাদাভাবে লিখুন। Hugging Face-এর evaluation documentation অনুযায়ী model card-এর score community বা model author—দুই পক্ষের evaluation থেকেই আসতে পারে, আর leaderboard-এর বিপরীতে card-এর score প্রায়ই author তৈরি করেন। তাই “benchmark score” লেখার বদলে কে পরীক্ষা চালিয়েছে, কোন result record দেওয়া আছে এবং ফলটি স্বাধীনভাবে পুনরুৎপাদিত হয়েছে কি না লিখুন। Author-reported ফল বাতিল করার দরকার নেই, কিন্তু স্বাধীনভাবে পুনরুৎপাদিত ফলের সমান provenance ধরে নেওয়াও ঠিক নয়।

Training data ও evaluation data আলাদা রাখুন

Training data থেকে মডেল pattern শেখে; evaluation data দিয়ে প্রকাশিত performance মাপা হয়। Worksheet-এ দুই dataset-এর নাম, ভাষা ও domain coverage এবং প্রকাশিত split আলাদা ঘরে নোট করুন। Test data training বা tuning-এ ব্যবহৃত হয়েছে কি না বোঝা না গেলে সেই score-কে অদেখা বাস্তব input-এর নিশ্চয়তা হিসেবে পড়বেন না।

একটি কাল্পনিক উদাহরণ ধরা যাক: বাংলা voice transcription model-এর সামগ্রিক word error rate ভালো, কিন্তু card-এ বাংলা training coverage, বাংলাদেশের বিভিন্ন কথ্য উচ্চারণের test sample বা কোলাহলপূর্ণ audio-র আলাদা ফল নেই। এখানে score-টি ভুল—এমন প্রমাণ নেই; বরং নির্দিষ্ট deployment context-এর প্রমাণ অসম্পূর্ণ। সিদ্ধান্ত নেওয়ার আগে বাস্তব ব্যবহারের প্রতিনিধিত্বকারী audio দিয়ে সীমিত local evaluation চালানো তখন যুক্তিসঙ্গত।

Aggregate score-এর নিচের ফল দেখুন

একটি গড় score বিভিন্ন গোষ্ঠী বা operating condition-এর performance gap আড়াল করতে পারে। কোন breakdown দরকার, তা use case-ই নির্ধারণ করবে: speech model-এর ক্ষেত্রে ভাষা, উচ্চারণ ও background noise; vision model-এর ক্ষেত্রে আলো, camera condition বা প্রাসঙ্গিক জনসমষ্টি; moderation model-এর ক্ষেত্রে ভাষা, উপভাষা ও content category প্রাসঙ্গিক হতে পারে। তাই সব মডেলে একই subgroup তালিকা বসিয়ে যাচাই শেষ করা যায় না।

Model Cards for Model Reporting গবেষণাপত্র intended application-এর সঙ্গে সম্পর্কিত cultural, demographic, phenotypic ও intersectional group অনুযায়ী evaluation ভেঙে দেখানো এবং evaluation procedure প্রকাশের প্রস্তাব করে। আপনার deployment-এর গুরুত্বপূর্ণ subgroup অনুপস্থিত থাকলে worksheet-এ “পরীক্ষিত নয়” লিখুন। তথ্য না থাকলে সেই গোষ্ঠীর performance ভালো বা খারাপ—কোনোটিই অনুমান করা যাবে না।

Limitations থেকে সিদ্ধান্তের শর্ত বানান

Limitations অংশকে সাধারণ সতর্কবার্তা হিসেবে না পড়ে deployment condition-এ রূপ দিন। “দীর্ঘ input-এ দুর্বল” লেখা থাকলে আপনার input length-এর সঙ্গে সীমাটি মেলান; কোনো ভাষায় পরীক্ষা না হলে সেই ভাষার evaluation রাখুন; human review প্রয়োজন হলে সম্পূর্ণ স্বয়ংক্রিয় workflow-কে উপযুক্ত ধরে নেবেন না। Limitation অস্পষ্ট হলে সেটিকেও “প্রমাণ অসম্পূর্ণ” হিসেবে নথিভুক্ত করুন।

শেষে পাঁচটি ঘরের প্রতিটিকে তিন অবস্থার একটিতে রাখুন: মিলে গেছে, প্রমাণ অসম্পূর্ণ অথবা সরাসরি অমিল। সব ঘর মেলার পরও পূর্ণ deployment-এর আগে pilot প্রয়োজন হতে পারে; অসম্পূর্ণ ঘরে targeted test দরকার। Intended use বা গুরুত্বপূর্ণ limitation-এর সঙ্গে সরাসরি অমিল থাকলে উঁচু score দিয়েও সেই ব্যবহারের পক্ষে যুক্তি তৈরি হয় না।

• আমার task, ভাষা, domain ও ঝুঁকির স্তর intended use-এর মধ্যে কি?
• Training data আমার input-এর প্রতিনিধিত্ব করে—এমন প্রকাশিত তথ্য আছে কি?
• Score-এর dataset, metric, setup, model version ও evaluator শনাক্ত করা যাচ্ছে কি?
• আমার গুরুত্বপূর্ণ subgroup বা operating condition-এর আলাদা ফল আছে কি?
• প্রাসঙ্গিক limitation সামলাতে test, human review বা ব্যবহার-সীমা নির্ধারিত হয়েছে কি?

এই worksheet কোনো নতুন ranking বানায় না; একটি score-এর পেছনে কী প্রমাণ আছে এবং আপনার ব্যবহারের সঙ্গে কোথায় অমিল রয়েছে, তা দৃশ্যমান করে। পাঁচটি ঘর না মিললে সিদ্ধান্তও স্থগিত রাখুন—কারণ headline score পরীক্ষার ফল জানায়, কিন্তু deployment-এর উপযুক্ততা নিজে থেকে নিশ্চিত করে না।

আরও পড়ুন:

• ভারতে GPT‑5.6 চালালেই data দেশে থাকে না—model ID-তেই সিদ্ধান্ত
• UGC rate card-এ ‘full rights’ লিখবেন না—এক কথায় আয় অর্ধেক হতে পারে
• AI model distillation সবসময় চুরি নয়—অনুমতির সীমা বুঝুন