একটি ইন্টারনাল HCAI ডিজাইন চেকলিস্ট তৈরি করা
এই পাঠে যা শিখবেন
- কেন একটি সরল "হ্যাঁ/না" চেকলিস্টের চেয়ে একটি ওয়েটেড চেকলিস্ট বেশি বাস্তবসম্মত
- এই কোর্সের বিভিন্ন মডিউল থেকে একটি প্র্যাকটিক্যাল চেকলিস্ট কীভাবে তৈরি করতে হয়
- একটি সত্যিকারের Python কোড দিয়ে ওয়েটেড শতাংশ স্কোর কীভাবে গণনা করতে হয়
- স্কোর থেকে কীভাবে উচ্চ-অগ্রাধিকার দুর্বলতা (gap) খুঁজে বের করতে হয়
১ · কেন একটি ওয়েটেড চেকলিস্ট দরকার
একটি সরল "হ্যাঁ/না" চেকলিস্ট (যেমন "এক্সপ্লেইনেবিলিটি আছে? ☐") একটি সমস্যা তৈরি করে — এটি ধরে নেয় প্রতিটি আইটেম সমান গুরুত্বপূর্ণ। বাস্তবে তা সত্যি নয়: একটি উচ্চ-ঝুঁকির মেডিকেল বা আর্থিক ফিচারে হিউম্যান ওভারসাইট (M5) হয়তো এক্সপ্লেইনেবিলিটির চেয়েও বেশি জরুরি, আবার একটি কম-ঝুঁকির এন্টারটেইনমেন্ট রেকোমেন্ডেশন ফিচারে উল্টোটা সত্যি হতে পারে। একটি ওয়েটেড চেকলিস্টWeighted checklistএমন একটি চেকলিস্ট যেখানে প্রতিটি আইটেমের নিজস্ব গুরুত্ব-অনুপাত (ওজন) থাকে, এবং চূড়ান্ত স্কোর প্রতিটি আইটেমের স্কোর ও ওজনের গুণফল যোগ করে বের করা হয়। এই বাস্তবতাকে ধরতে পারে — প্রতিটি আইটেমের একটি ওজন থাকে, এবং চূড়ান্ত স্কোর সেই ওজন অনুযায়ী গণনা হয়।
২ · এই কোর্স থেকে আটটি চেকলিস্ট আইটেম
নিচের চেকলিস্টে এই কোর্সের এখন পর্যন্ত পড়া মডিউলগুলো থেকে আটটি আইটেম বাছাই করা হয়েছে, প্রতিটির একটি ওজন (মোট ১০০-এর মধ্যে ভাগ করা) সহ:
কনফিডেন্স/আনসার্টেইনটি সঠিকভাবে জানানো হয় কিনা (M3)।
প্রতিটি সাজেশনের কারণ বোঝা যায় কিনা (M4)।
ব্যবহারকারী সিদ্ধান্ত ওভাররাইড করতে পারে কিনা (M5)।
ভুল হলে সহজে বোঝা ও সংশোধন করা যায় কিনা (M6)।
WCAG কনট্রাস্ট, স্ক্রিন-রিডার সাপোর্ট ইত্যাদি (M7)।
ব্যবহারকারী সংশোধন করে সিস্টেমকে শেখাতে পারে কিনা (M6)।
সঠিক মানসিক মডেল শুরুতেই তৈরি হয় কিনা (M2, M6)।
একসাথে দেখানো সিদ্ধান্ত-সম্পর্কিত উপাদান কম রাখা হয় কিনা (M6)।
ওজনগুলো মোট ১০০-এ যোগ হয় — এটি বাধ্যতামূলক নয়, কিন্তু এতে চূড়ান্ত স্কোরকে সরাসরি একটি শতাংশ হিসেবে পড়া সহজ হয়। এই নির্দিষ্ট ওজন-বণ্টনটি একটি উদাহরণ মাত্র — বাস্তব টিমে প্রোডাক্টের ঝুঁকি ও প্রেক্ষাপট অনুযায়ী এই ওজনগুলো ভিন্ন হবে (M5-এর উচ্চ-ঝুঁকি প্রসঙ্গ, L33-এ বিস্তারিত)।
৩ · কোড দিয়ে একটি হাইপোথেটিক্যাল ফিচার স্কোর করা
ধরা যাক একটি ব্যাংকিং অ্যাপে একটি "AI-চালিত খরচ-বিশ্লেষণ ও বাজেট পরামর্শ" ফিচার রয়েছে — এটি ব্যবহারকারীর খরচের প্যাটার্ন বিশ্লেষণ করে বাজেট-পরামর্শ দেয়। নিচের কোডে প্রতিটি চেকলিস্ট আইটেমে এই ফিচারটিকে একটি স্কোর (০-১০০) দেওয়া হয়েছে (একটি ডিজাইন-রিভিউ টিমের হাইপোথেটিক্যাল মূল্যায়ন হিসেবে), এবং সত্যিকারভাবে ওয়েটেড শতাংশ গণনা করা হয়েছে।
checklist = [
{"item": "ট্রাস্ট ক্যালিব্রেশন ও কনফিডেন্স কমিউনিকেশন (M3)", "weight": 15, "score": 70},
{"item": "এক্সপ্লেইনেবিলিটি -- প্রতিটি সাজেশনের কারণ বোঝানো (M4)", "weight": 15, "score": 60},
{"item": "হিউম্যান ওভারসাইট ও ওভাররাইড অপশন (M5)", "weight": 15, "score": 90},
{"item": "এরর ডিজাইন ও গ্রেসফুল রিকভারি (M6)", "weight": 15, "score": 50},
{"item": "অ্যাক্সেসিবিলিটি -- WCAG কনট্রাস্ট ও স্ক্রিন-রিডার সাপোর্ট (M7)", "weight": 10, "score": 80},
{"item": "ফিডব্যাক লুপ -- ব্যবহারকারী সংশোধন করতে পারে (M6)", "weight": 10, "score": 40},
{"item": "অনবোর্ডিং ও সঠিক মেন্টাল মডেল তৈরি (M2, M6)", "weight": 10, "score": 65},
{"item": "কগনিটিভ লোড -- ইন্টারফেসে একসাথে সিদ্ধান্ত কম রাখা (M6)", "weight": 10, "score": 75},
]
total_weight = sum(i["weight"] for i in checklist)
weighted_sum = sum(i["weight"] * i["score"] for i in checklist)
overall_pct = weighted_sum / total_weight
print(f"মোট ওজন: {total_weight}")
print(f"ওয়েটেড HCAI চেকলিস্ট স্কোর: {overall_pct:.1f}%\n")
print("আইটেম-ভিত্তিক অবদান:")
for i in checklist:
contribution = i["weight"] * i["score"] / total_weight
label = i["item"].ljust(58)
print(f" {label} স্কোর {i['score']:>3} | অবদান {contribution:5.1f}")
if overall_pct >= 80:
verdict = "ভালো -- প্রোডাকশনের জন্য প্রস্তুত"
elif overall_pct >= 60:
verdict = "মাঝারি -- কিছু গুরুত্বপূর্ণ ক্ষেত্রে উন্নতি দরকার"
else:
verdict = "দুর্বল -- মূল ডিজাইন পুনর্বিবেচনা দরকার"
print(f"\nচূড়ান্ত রায়: {verdict}")
gaps = [i for i in checklist if i["score"] < 50]
print("\nউচ্চ-অগ্রাধিকার ঘাটতি (স্কোর ৫০-এর নিচে):")
if gaps:
for g in gaps:
print(f" - {g['item']} (স্কোর {g['score']})")
else:
print(" কোনো আইটেম ৫০-এর নিচে নেই।")
৪ · একটি ওয়েটেড স্কোর কী বলে না
একটি একক শতাংশ সংখ্যা (৬৬.৫%) সুবিধাজনক — এটি সহজে যোগাযোগ করা যায় ও সময়ের সাথে ট্র্যাক করা যায়। কিন্তু
এটি ভুলভাবে ব্যবহার করাও সহজ: একটি ৬৬.৫% স্কোরকে "মোটামুটি ভালো" ভেবে ফিডব্যাক-লুপের মতো একটি নির্দিষ্ট,
গুরুতর দুর্বলতা আড়াল হয়ে যেতে পারে যদি শুধু সারসংক্ষেপ সংখ্যাটাই দেখা হয়। তাই একটি ভালো ইন্টারনাল চেকলিস্ট
সবসময় সামগ্রিক স্কোরের পাশাপাশি আইটেম-ভিত্তিক ভাঙন (breakdown) ও নির্দিষ্ট গ্যাপগুলোও দেখাতে হবে — ঠিক
যেভাবে উপরের কোডে gaps তালিকাটি আলাদাভাবে বের করা হয়েছে।
একটি ইন্টারনাল HCAI চেকলিস্ট তৈরি করা মানে এই কোর্সে শেখা পৃথক ধারণাগুলোকে (ট্রাস্ট, এক্সপ্লেইনেবিলিটি, ওভারসাইট, এরর-ডিজাইন, অ্যাক্সেসিবিলিটি, ফিডব্যাক, অনবোর্ডিং, কগনিটিভ লোড) একটি একক, প্রোডাক্ট-নির্দিষ্ট, ওজন-ভিত্তিক টুলে একত্র করা — যা L44-L46-এ দেখা PAIR, HAX ও অন্যান্য ইন্ডাস্ট্রি গাইডলাইনের একই সাধারণ চেতনাকে অনুসরণ করে, কিন্তু আপনার নিজস্ব প্রোডাক্টের প্রেক্ষাপটে প্রয়োগযোগ্য করে তোলে। মডিউল ১১-এ আমরা এই ধরনের চিন্তা বিভিন্ন বাস্তব ডোমেইনে (হেলথকেয়ার, ক্রিয়েটিভ টুল, স্বায়ত্তশাসিত সিস্টেম) কীভাবে প্রয়োগ হয় তা দেখবো।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ উপরের চেকলিস্টে সব আইটেমের ওজন কে ঠিক করলো? বাস্তব জীবনে এই ওজনগুলো কে ঠিক করা উচিত বলে আপনার মনে হয়?
এই পাঠে ওজনগুলো একটি হাইপোথেটিক্যাল, শিক্ষামূলক উদাহরণ হিসেবে বাছাই করা হয়েছে। বাস্তব জীবনে এই ওজন নির্ধারণ একটি একক ব্যক্তির কাজ নয় — এটি সাধারণত একটি ক্রস-ফাংশনাল আলোচনা (ডিজাইনার, প্রোডাক্ট ম্যানেজার, ইঞ্জিনিয়ার, এবং উচ্চ-ঝুঁকির ডোমেইনে ডোমেইন-এক্সপার্ট বা লিগ্যাল/কমপ্লায়েন্স টিম) থেকে আসা উচিত, কারণ কোন ঝুঁকি সবচেয়ে গুরুত্বপূর্ণ তা প্রোডাক্টের প্রেক্ষাপটের উপর নির্ভর করে (M5, L33-এ বিস্তারিত)।
প্র ০২ একটি ৬৬.৫% ওয়েটেড স্কোর এবং একটি "ফিডব্যাক লুপ" আইটেমে মাত্র ৪০ স্কোর — এই দুটো তথ্যের মধ্যে কোনটি একটি প্রোডাক্ট টিমের জন্য বেশি কার্যকর, এবং কেন?
সারসংক্ষেপ স্কোরটি (৬৬.৫%) দ্রুত অগ্রগতি ট্র্যাক করার জন্য ভালো (যেমন প্রতি স্প্রিন্টে তুলনা করা), কিন্তু এটি একা কোনো নির্দিষ্ট অ্যাকশন বলে দেয় না। "ফিডব্যাক লুপ ৪০" তথ্যটি অনেক বেশি কার্যকর কারণ এটি সরাসরি বলে দেয় ঠিক কোথায় কাজ শুরু করতে হবে। একটি ভালো চেকলিস্ট দুটোই দেখাতে হবে — সামগ্রিক প্রবণতার জন্য সারসংক্ষেপ, এবং অ্যাকশনের জন্য আইটেম-ভিত্তিক ভাঙন।
প্র ০৩ উপরের চেকলিস্টে "কগনিটিভ লোড" ও "ফিডব্যাক লুপ" উভয়কেই M6-এর অধীনে রাখা হয়েছে, কিন্তু আলাদা আইটেম হিসেবে। এদের একত্রিত না করে আলাদা রাখার সুবিধা কী?
দুটো ধারণা সম্পর্কিত হলেও ভিন্ন জিনিস পরিমাপ করে — কগনিটিভ লোড দেখে একজন ব্যবহারকারীকে একসাথে কতটা সিদ্ধান্ত নিতে হচ্ছে, আর ফিডব্যাক লুপ দেখে ব্যবহারকারীর সংশোধন সিস্টেমে ফিরে যাচ্ছে কিনা। এদের একত্রিত করলে একটি ফিচার হয়তো একটিতে খুব ভালো আর অন্যটিতে খুব খারাপ হলেও গড় স্কোর একটি মাঝারি, বিভ্রান্তিকর সংখ্যা দেখাবে — আলাদা আইটেম রাখলে প্রতিটি সমস্যা আলাদাভাবে দৃশ্যমান থাকে।
অনুশীলন
-
চিন্তা করুন: উপরের কোড সেলে যদি "এক্সপ্লেইনেবিলিটি" আইটেমের score ৬০ থেকে ৯০-এ বাড়ানো
হয় (ওজন অপরিবর্তিত ১৫), চূড়ান্ত ওয়েটেড শতাংশ কত হবে বলে আপনার অনুমান? (ইঙ্গিত: ওজন ১৫ মোট ওজন ১০০-এর
১৫%।)
score ৩০ পয়েন্ট বাড়লে, আর ওজন মোট ওজনের ১৫% হওয়ায়, চূড়ান্ত শতাংশ প্রায়
30 * 0.15 = 4.5পয়েন্ট বাড়া উচিত — অর্থাৎ ৬৬.৫% থেকে বেড়ে প্রায় ৭১.০% হওয়া উচিত। -
পরীক্ষা করুন: কোড সেলে "এক্সপ্লেইনেবিলিটি" আইটেমের
"score": 60-কে"score": 90-এ পরিবর্তন করে Run চেপে আপনার অনুমান যাচাই করুন।পরিবর্তনের পর আউটপুটে "ওয়েটেড HCAI চেকলিস্ট স্কোর: ৭১.০%" দেখা যায় — ঠিক অনুমান অনুযায়ীই, কারণ ওয়েটেড-সমষ্টি (weighted sum) সূত্রটি প্রতিটি আইটেমের জন্য সরল রৈখিক (linear)। রায়ও এখনও "মাঝারি" থাকে কারণ ৭১.০% এখনও ৬০-৭৯% সীমার মধ্যে — তবে "ফিডব্যাক লুপ" এখনও একমাত্র উচ্চ-অগ্রাধিকার ঘাটতি হিসেবেই থেকে যায়, কারণ তার স্কোর অপরিবর্তিত (৪০) রয়ে গেছে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- ফিডব্যাক লুপ গভীরে দেখুন L27 এই পাঠের কোড ডেমোতে সবচেয়ে দুর্বল হিসেবে চিহ্নিত ক্ষেত্রটির পূর্ণ কভারেজ।
- পরবর্তী পাঠ — হেলথকেয়ার ডিসিশন সাপোর্টে HCAI L48 মডিউল ১১ শুরু — এখন পর্যন্ত শেখা নীতিগুলো একটি বাস্তব উচ্চ-ঝুঁকির ডোমেইনে প্রয়োগ।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ ব্যবহারকারী ও প্রেক্ষাপট, ট্রাস্ট ক্যালিব্রেশন, এক্সপ্লেইনেবিলিটি, হিউম্যান-ইন-দ্য-লুপ ডিজাইন, কগনিটিভ লোড, অ্যাক্সেসিবিলিটি, হিউম্যান-AI টিমিং, ইউজেবিলিটি ইভালুয়েশন, ইন্ডাস্ট্রি ফ্রেমওয়ার্ক ও ক্যাপস্টোন।