AI সিস্টেমের জন্য ইউজেবিলিটি টেস্টিং
এই পাঠে যা শিখবেন
- AI সিস্টেমে ইউজেবিলিটি টেস্টিং সাধারণ সফটওয়্যার থেকে কীভাবে আলাদা
- টাস্ক-সাকসেস রেট, টাইম-অন-টাস্ক, এরর রেট ও থিংক-অ্যালাউড প্রোটোকল কী এবং কেন দরকার
- একটি সেশন-লগ ডেটাসেট থেকে সত্যিকারের সামারি স্ট্যাটিস্টিক্স (mean, median) গণনা করা
- ফলাফল থেকে "রেড ফ্ল্যাগ" (সমস্যার লক্ষণ) কীভাবে শনাক্ত করবেন
১ · কেন AI সিস্টেমের ইউজেবিলিটি টেস্টিং আলাদা
ইউজেবিলিটি টেস্টিংUsability Testingবাস্তব ব্যবহারকারীদের একটি প্রোডাক্ট বা ফিচার দিয়ে সত্যিকারের টাস্ক সম্পন্ন করতে দিয়ে পর্যবেক্ষণ করা তারা কতটা সহজে ও কার্যকরভাবে তা করতে পারেন। একটি প্রতিষ্ঠিত UX পদ্ধতি — বাস্তব ব্যবহারকারীদের একটি নির্দিষ্ট টাস্ক দিয়ে দেখা হয় তারা প্রোডাক্টটি দিয়ে কতটা সহজে কাজ শেষ করতে পারেন। AI-ফিচারযুক্ত প্রোডাক্টে এই একই পদ্ধতি ব্যবহার হয়, কিন্তু কয়েকটি বাড়তি চ্যালেঞ্জ যোগ হয়:
একটি বাটনের অবস্থান সবসময় একই থাকে, কিন্তু একটি জেনারেটিভ সাজেশন বা রিকমেন্ডেশন প্রতিবার ভিন্ন হতে পারে — তাই একটিমাত্র সেশনে "ফিচারটি ভালো কি খারাপ" বলা কঠিন।
শুধু "টাস্ক শেষ হলো কি না" যথেষ্ট নয় — ব্যবহারকারী কি বুঝতে পারলেন AI কখন ভুল করছে? সে কি ভুল আউটপুটের উপর নির্ভর করে ফেলল (M3-এ বিস্তারিত)?
একই AI আউটপুট এক ব্যবহারকারীর জন্য দারুণ, আরেকজনের জন্য অপ্রাসঙ্গিক হতে পারে — তাই স্যাম্পলে বিভিন্ন প্রেক্ষাপট ও ব্যবহারকারী-প্রোফাইল থাকা জরুরি (M2-এ ইউজার রিসার্চ বিস্তারিত)।
২ · মূল মেট্রিক্স ও মেথড
একটি AI ফিচারের ইউজেবিলিটি টেস্টে সাধারণত নিচের মেট্রিক্সগুলো মাপা হয়:
- টাস্ক-সাকসেস রেট — অংশগ্রহণকারীদের মধ্যে কত শতাংশ নির্ধারিত টাস্কটি সফলভাবে শেষ করতে পারলেন।
- টাইম-অন-টাস্ক — টাস্ক শেষ করতে কত সময় লাগলো (mean ও median দুটোই দরকারি, কারণ কয়েকজন অংশগ্রহণকারী অনেক বেশি সময় নিলে mean একাই বিভ্রান্তিকর হতে পারে)।
- এরর রেট — টাস্কের মাঝে কতবার ভুল পদক্ষেপ নেওয়া হলো (যেমন AI-এর ভুল সাজেশন গ্রহণ করে পরে বাতিল করা)।
- থিংক-অ্যালাউড প্রোটোকল — অংশগ্রহণকারীকে টাস্ক করার সময় জোরে চিন্তা প্রকাশ করতে বলা হয়, যাতে গবেষক বুঝতে পারেন তিনি AI-এর আউটপুট নিয়ে কী ভাবছেন — এটি সংখ্যার বাইরে গুণগত (qualitative) অন্তর্দৃষ্টি দেয়।
ইউজার রিসার্চ (M2) আপনাকে বলে কাদের জন্য এবং কোন প্রেক্ষাপটে ডিজাইন করছেন। ইউজেবিলিটি টেস্টিং সেই ডিজাইন বাস্তবে বানানোর পর যাচাই করে সেটি সত্যিই কাজ করে কি না। দুটো একসাথে একটি চক্র তৈরি করে — রিসার্চ থেকে ডিজাইন, ডিজাইন থেকে টেস্ট, টেস্ট থেকে আবার ডিজাইনে ফেরত।
৩ · সত্যিকারের ডেমো — সেশন লগ থেকে সামারি স্ট্যাটিস্টিক্স
ধরা যাক ১২ জন অংশগ্রহণকারী একটি ইমেইল অ্যাপের "স্মার্ট রিপ্লাই সাজেশন" ফিচার ব্যবহার করে একটি নির্দিষ্ট টাস্ক (একটি উপযুক্ত উত্তর বেছে/সম্পাদনা করে পাঠানো) সম্পন্ন করার চেষ্টা করেছেন। প্রতিটি সেশনের লগে আছে — টাস্কটি সফল হয়েছিল কি না, এবং কত সেকেন্ড সময় লেগেছিল। নিচের কোড সেলে সত্যিকারের গণনা দেখা যাক।
# প্রতিটি এন্ট্রি একজন অংশগ্রহণকারীর সেশন লগ -- একটি "স্মার্ট রিপ্লাই সাজেশন" ফিচার
# ব্যবহার করে একটি টাস্ক সম্পূর্ণ করার চেষ্টা
sessions = [
{"user": "P01", "success": True, "time": 42},
{"user": "P02", "success": True, "time": 58},
{"user": "P03", "success": False, "time": 95},
{"user": "P04", "success": True, "time": 37},
{"user": "P05", "success": True, "time": 64},
{"user": "P06", "success": False, "time": 88},
{"user": "P07", "success": True, "time": 49},
{"user": "P08", "success": True, "time": 52},
{"user": "P09", "success": True, "time": 71},
{"user": "P10", "success": False, "time": 110},
{"user": "P11", "success": True, "time": 45},
{"user": "P12", "success": True, "time": 55},
]
def task_success_rate(sessions):
successes = sum(1 for s in sessions if s["success"])
return successes, len(sessions), successes / len(sessions) * 100
def mean_time(sessions):
times = [s["time"] for s in sessions]
return sum(times) / len(times)
def median_time(sessions):
times = sorted(s["time"] for s in sessions)
n = len(times)
mid = n // 2
if n % 2 == 0:
return (times[mid - 1] + times[mid]) / 2
return times[mid]
successes, total, rate = task_success_rate(sessions)
print(f"টাস্ক-সাকসেস রেট: {successes}/{total} = {rate:.1f}%")
print(f"গড় (mean) টাইম-অন-টাস্ক: {mean_time(sessions):.2f} সেকেন্ড")
print(f"মিডিয়ান টাইম-অন-টাস্ক: {median_time(sessions):.1f} সেকেন্ড")
# সফল ও ব্যর্থ সেশনগুলো আলাদা করে সময়ের পার্থক্য দেখা
successful = [s for s in sessions if s["success"]]
failed = [s for s in sessions if not s["success"]]
print(f"\nসফল সেশনের গড় সময়: {mean_time(successful):.2f} সেকেন্ড ({len(successful)}টি সেশন)")
print(f"ব্যর্থ সেশনের গড় সময়: {mean_time(failed):.2f} সেকেন্ড ({len(failed)}টি সেশন)")
৪ · ফলাফল ব্যাখ্যা করা — কী দেখতে হবে
একা সাকসেস রেট বা একা mean time কখনোই যথেষ্ট নয়। কয়েকটি জিনিস সবসময় একসাথে দেখা উচিত:
- Mean বনাম Median — mean আর median অনেক দূরে থাকলে বোঝা যায় কিছু আউটলায়ার (খুব বেশি সময় নেওয়া সেশন) ফলাফলকে টেনে ধরছে।
- সফল বনাম ব্যর্থ সেশনের সময় — উপরের ডেমোর মতো, ব্যর্থ সেশন অনেক বেশি সময় নিলে সেটি "আটকে যাওয়া" (confusion) নির্দেশ করে, নিছক দুর্ভাগ্য নয়।
- থিংক-অ্যালাউড নোট — সংখ্যা বলে কী ঘটেছে, থিংক-অ্যালাউড বলে কেন ঘটেছে — দুটো ছাড়া ডিজাইন-সিদ্ধান্ত নেওয়া কঠিন।
ইউজেবিলিটি টেস্টিং এর সংখ্যাগুলো নিজে থেকে কিছু বলে না — আসল কাজ হলো সংখ্যাগুলোর মধ্যে প্যাটার্ন খুঁজে বের করা (যেমন সফল ও ব্যর্থ সেশনের সময়ের ফারাক) এবং সেই প্যাটার্নকে থিংক-অ্যালাউড ফিডব্যাকের সাথে মিলিয়ে বোঝা কোথায় ডিজাইন পরিবর্তন দরকার। পরের পাঠে (L40) আমরা দেখব একটি একক টেস্টের বাইরে গিয়ে কীভাবে বড় স্কেলে, অনলাইনে A/B টেস্টিং দিয়ে এই একই প্রশ্নগুলো যাচাই করা যায়।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ উপরের ডেমোতে সাকসেস রেট ৭৫% — এটা কি "ভালো" ফলাফল? এই একটি সংখ্যা থেকে কী বলা যায় না?
৭৫% "ভালো" না "খারাপ" তা নির্ভর করে বেসলাইন (আগের ফিচার বা কম্পিটিটরের রেট) এবং টাস্কের ঝুঁকির উপর — একটি কম-ঝুঁকির সাজেশন ফিচারে ৭৫% গ্রহণযোগ্য হতে পারে, কিন্তু উচ্চ-ঝুঁকির প্রেক্ষাপটে (M5-এ বিস্তারিত) তা যথেষ্ট নাও হতে পারে। এই একটি সংখ্যা এটাও বলে না কেন বাকি ২৫% ব্যর্থ হলেন — সেজন্য থিংক-অ্যালাউড নোট বা এরর লগ দরকার।
প্র ০২ মাত্র ১২ জন অংশগ্রহণকারীর ডেটা থেকে কি নিশ্চিতভাবে বলা যায় ফিচারটি "ভালো"? কেন বা কেন না?
না — ১২ জন একটি ছোট, কোয়ালিটেটিভ ইউজেবিলিটি টেস্টের জন্য স্বাভাবিক স্যাম্পল সাইজ (সাধারণত এত অংশগ্রহণকারী থেকেই বেশিরভাগ বড় ইউজেবিলিটি সমস্যা ধরা পড়ে), কিন্তু এটি নিশ্চিত পরিমাণগত সিদ্ধান্তের (যেমন "ফিচার B ফিচার A-এর চেয়ে উল্লেখযোগ্যভাবে ভালো") জন্য যথেষ্ট নয় — তার জন্য অনেক বড় স্যাম্পলে A/B টেস্টিং দরকার, যা L40-এ কভার করা হয়েছে।
প্র ০৩ থিংক-অ্যালাউড প্রোটোকলে ব্যবহারকারীকে জোরে চিন্তা প্রকাশ করতে বলা হলে তার আচরণ কি স্বাভাবিক আচরণ থেকে বদলে যেতে পারে? এটি কি সমস্যা?
হ্যাঁ, জোরে চিন্তা প্রকাশ করা কিছুটা টাস্ক-স্পিড কমাতে পারে এবং আচরণকে সামান্য বদলাতে পারে (এটি একটি পরিচিত ট্রেড-অফ, "reactivity" নামে পরিচিত সাধারণ গবেষণা-পদ্ধতির সমস্যা)। তাই সময়ের সংখ্যা তুলনা করার সময় (যেমন প্রতিদ্বন্দ্বী ডিজাইনের মধ্যে) সাধারণত একই প্রোটোকল দুই ক্ষেত্রেই ব্যবহার করা হয়, যাতে তুলনাটি অন্তত সামঞ্জস্যপূর্ণ থাকে।
অনুশীলন
-
চিন্তা করুন: যদি একটি ১৩তম সেশন যোগ করা হয় যেখানে টাস্ক ব্যর্থ হয়েছে এবং সময় লেগেছে
১৫০ সেকেন্ড, তাহলে আপনার ধারণায় সাকসেস রেট ও গড় সময় কীভাবে বদলাবে?
সাকসেস রেট কমবে (আরেকজন ব্যর্থ ব্যবহারকারী যোগ হচ্ছে), এবং যেহেতু নতুন সেশনটি সবচেয়ে বেশি সময় নিয়েছে, গড় সময়ও বাড়বে। তবে ঠিক কতটা বাড়বে তা অনুমান করা কঠিন — সেটা পরের ধাপে চালিয়ে যাচাই করা যাক।
-
যাচাই করুন: উপরের কোডে
sessionsলিস্টে{"user": "P13", "success": False, "time": 150}যোগ করে Run চেপে আপনার অনুমান যাচাই করুন।নতুন ফলাফল: সাকসেস রেট কমে ৯/১৩ = ৬৯.২%-এ নেমে আসে, গড় সময় বেড়ে ৭০.৪৬ সেকেন্ড হয়, আর মিডিয়ান বদলে ৫৮.০ সেকেন্ড হয়। লক্ষ্য করুন মাত্র একটি বাড়তি ব্যর্থ-ও-ধীর সেশন পুরো সামারি সংখ্যাগুলোকে চোখে-পড়ার মতো বদলে দিতে পারে — এটাই ছোট স্যাম্পল সাইজের সাথে কাজ করার সময় সতর্ক থাকার কারণ।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- AI ফিচারের জন্য A/B টেস্টিং ও অনলাইন ইভালুয়েশন পরবর্তী পাঠ একক ইউজেবিলিটি টেস্টের বাইরে গিয়ে বড় স্কেলে দুটো ভ্যারিয়েন্ট তুলনা করার ম্যানুয়াল পরিসংখ্যান।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ ট্রাস্ট ক্যালিব্রেশন, এক্সপ্লেইনেবিলিটি, হিউম্যান-ইন-দ্য-লুপ ডিজাইন, ইভালুয়েশন পদ্ধতি ও ইন্ডাস্ট্রি ফ্রেমওয়ার্ক — সব একসাথে।
- AI Ethics কোর্স সহোদর কোর্স নৈতিক ফ্রেমওয়ার্ক ও বায়াস-ফেয়ারনেস মূল্যায়নের গভীর কভারেজ — এই কোর্স তার উপর ইন্টারঅ্যাকশন-ডিজাইন ইভালুয়েশনের দিকটি যোগ করে।