পাঠ ১৬ · ৫৭-এর মধ্যে · মডিউল ৪
Home / AI Courses / Human-Centered AI / এক্সপ্লেইনেবিলিটি

কনফিডেন্স ও আনসার্টেইনটি কমিউনিকেশন ডিজাইন

Designing confidence & uncertainty communication
৮ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • কেন একটি raw কনফিডেন্স সংখ্যা প্রায়ই একজন সাধারণ ব্যবহারকারীর জন্য যথেষ্ট নয়
  • কীভাবে থ্রেশহোল্ড-ভিত্তিক একটি ফাংশন লিখে সংখ্যাসূচক স্কোরকে ভাষাগত ব্যান্ডে রূপান্তর করা যায়
  • ব্যান্ডের বাইরেও কনফিডেন্স/আনসার্টেইনটি কমিউনিকেট করার ভিজ্যুয়াল ও ভাষাগত ডিজাইন প্যাটার্ন
  • ভুলভাবে ডিজাইন করা কনফিডেন্স কমিউনিকেশনের ঝুঁকি এবং এটি ট্রাস্ট ক্যালিব্রেশনের সাথে কীভাবে যুক্ত

১ · কেন একটি raw সংখ্যা যথেষ্ট নয়

একটি AI মডেল প্রায়ই তার প্রতিটি পূর্বাভাসের সাথে একটি সংখ্যাসূচক কনফিডেন্স স্কোরকনফিডেন্স স্কোরমডেলটি নিজের পূর্বাভাসের সঠিকতা সম্পর্কে কতটা "নিশ্চিত" তার একটি সংখ্যাসূচক পরিমাপ, সাধারণত ০ থেকে ১-এর মধ্যে — তবে এটি সবসময় প্রকৃত নির্ভুলতার সাথে সামঞ্জস্যপূর্ণ (ক্যালিব্রেটেড) নাও হতে পারে। দিতে পারে (যেমন ০.৮৭)। কিন্তু বেশিরভাগ ব্যবহারকারীর কাছে এই সংখ্যাটি সরাসরি অর্থবহ নয় — ০.৮৭ কি "প্রায় নিশ্চিত" নাকি "মোটামুটি নিশ্চিত"? সবাই একইভাবে ব্যাখ্যা করবে না। এছাড়া, একটি একক সংখ্যা প্রায়ই অতিরিক্ত সুনির্দিষ্ট (false precision) মনে হয় — "৮৭.৩%" শুনে মনে হতে পারে সিস্টেমটি অনেক বেশি নিশ্চিত, যখন প্রকৃতপক্ষে এই সুনির্দিষ্টতা মডেলের প্রকৃত নির্ভরযোগ্যতার প্রতিফলন নাও হতে পারে (M3-এ ক্যালিব্রেশন নিয়ে বিস্তারিত)। তাই ডিজাইন সমস্যাটি হলো: এই সংখ্যাটিকে এমনভাবে কমিউনিকেট করা, যাতে ব্যবহারকারী তার সাথে সামঞ্জস্যপূর্ণ পরিমাণে বিশ্বাস করেন।

২ · কনফিডেন্স ব্যান্ড ম্যাপিং ফাংশন

একটি সাধারণ ও ব্যবহারিক কৌশল হলো সংখ্যাসূচক স্কোরকে কয়েকটি নির্দিষ্ট থ্রেশহোল্ড অনুযায়ী ভাষাগত ব্যান্ডে ভাগ করা। নিচের কোডে একটি বাস্তব থ্রেশহোল্ড ফাংশন কয়েকটি ভিন্ন উদাহরণ স্কোরে চালানো হয়েছে।

Python
def confidence_band(score):
    if score >= 0.90:
        return "উচ্চ নিশ্চয়তা (High confidence)"
    elif score >= 0.60:
        return "মাঝারি নিশ্চয়তা (Moderate confidence)"
    elif score >= 0.35:
        return "নিম্ন নিশ্চয়তা (Low confidence)"
    else:
        return "অত্যন্ত নিম্ন নিশ্চয়তা (Very low confidence)"

test_scores = [0.97, 0.88, 0.71, 0.60, 0.59, 0.42, 0.15]

print("স্কোর -> ব্যান্ড:")
for s in test_scores:
    print(f"  {s:.2f} -> {confidence_band(s)}")

    
লক্ষ্য করুন — ০.৬০ স্কোরটি "মাঝারি নিশ্চয়তা" পায় (থ্রেশহোল্ড >= 0.60 হওয়ায় এটি অন্তর্ভুক্ত), কিন্তু ০.৫৯ স্কোরটি এক ধাপ নিচে "নিম্ন নিশ্চয়তা"-এ নেমে যায় — মাত্র ০.০১ পার্থক্যে ভিন্ন ব্যান্ড। এটি একটি বাস্তব ডিজাইন চ্যালেঞ্জ দেখায়: থ্রেশহোল্ডের ঠিক কাছাকাছি স্কোরগুলোর জন্য ব্যান্ডিং কিছুটা "কৃত্রিম" সীমারেখা তৈরি করে — যা নিচে আরও আলোচনা করা হয়েছে।

৩ · ব্যান্ডের বাইরেও — ভিজ্যুয়াল ও ভাষাগত ডিজাইন প্যাটার্ন

রঙ ও আইকন
সবুজ/হলুদ/লাল বা একটি প্রগ্রেস-বার প্রায়ই সংখ্যার চেয়ে দ্রুত বোঝা যায় — তবে রঙ-অন্ধ ব্যবহারকারীদের জন্য শুধু রঙের উপর নির্ভর করা উচিত নয় (M7-এ অ্যাক্সেসিবিলিটি বিস্তারিত)।
হেজিং ভাষা
"সম্ভবত", "মনে হচ্ছে", "আনুমানিক" — এই ধরনের শব্দ স্বাভাবিকভাবেই অনিশ্চয়তা বোঝায়, সংখ্যার চেয়ে অনেক সময় বেশি স্বজ্ঞাতভাবে বোধগম্য।
অতিরিক্ত সুনির্দিষ্টতা এড়ানো
"৮৭.৩%" এর বদলে "প্রায় ৯০%" বা সরাসরি "উচ্চ নিশ্চয়তা" দেখানো ভালো — একটি দশমিক-বিন্দুসহ সংখ্যা যতটা নির্ভুল মনে হয়, মডেল আসলে ততটা নির্ভুলভাবে ক্যালিব্রেটেড নাও হতে পারে।
প্রয়োজনে raw সংখ্যাও রাখা
ব্যান্ড দেখানোর পাশাপাশি, আগ্রহী/বিশেষজ্ঞ ব্যবহারকারীর জন্য raw সংখ্যাটি একটি গভীর স্তরে রেখে দেওয়া যায় — এই ধারণাটিই L17-এ প্রোগ্রেসিভ ডিসক্লোজার হিসেবে বিস্তারিত আলোচনা করা হবে।

৪ · আনসার্টেইনটি কমিউনিকেশনের নিজস্ব ঝুঁকি

ব্যান্ডিং একটি দরকারী সরলীকরণ, কিন্তু এটি নিজেই ভুল সংকেত দিতে পারে। যদি একটি সিস্টেম প্রায় সবসময় "উচ্চ নিশ্চয়তা" দেখায় (কারণ এর থ্রেশহোল্ড খুব শিথিল), ব্যবহারকারী ধীরে ধীরে ব্যান্ডটিকে উপেক্ষা করতে শুরু করেন — এটি M3-এ আলোচিত অটোমেশন বায়াস-এর একটি নতুন রূপ। উল্টো দিকে, যদি থ্রেশহোল্ড খুব কঠোর হয় এবং বেশিরভাগ সময় "মাঝারি" বা "নিম্ন" দেখায়, ব্যবহারকারী পুরো সিস্টেমটির উপরই আস্থা হারাতে পারেন, এমনকি যেসব ক্ষেত্রে সিস্টেম আসলে নির্ভরযোগ্য। তাই থ্রেশহোল্ডগুলো নির্ধারণ করার সময় শুধু গাণিতিক সুবিধার উপর নয়, প্রকৃত পরিসংখ্যানগত ক্যালিব্রেশন ডেটার (মডেলটি যখন "উচ্চ নিশ্চয়তা" বলে, তখন বাস্তবে কত শতাংশ সঠিক হয়) উপর ভিত্তি করে সিদ্ধান্ত নেওয়া উচিত।

মূল কথা · Key takeaway

কনফিডেন্স/আনসার্টেইনটি কমিউনিকেশনের লক্ষ্য একটি সংখ্যা দেখানো নয় — লক্ষ্য হলো ব্যবহারকারীর মানসিক মডেলকে সিস্টেমের প্রকৃত নির্ভরযোগ্যতার সাথে সামঞ্জস্যপূর্ণ করা। একটি ভালোভাবে ডিজাইন করা ব্যান্ড/ভাষা/ভিজ্যুয়াল সমন্বয় সেই কাজটি সংখ্যার চেয়ে অনেক বেশি কার্যকরভাবে করতে পারে — কিন্তু শুধু তখনই, যখন ব্যান্ডের থ্রেশহোল্ডগুলো নিজেই প্রকৃত ক্যালিব্রেশনের সাথে মেলে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ উপরের কোডে ০.৬০ এবং ০.৫৯ দুটি খুব কাছাকাছি স্কোর হয়েও ভিন্ন ব্যান্ডে পড়েছে। এটি কি একটি ডিজাইন সমস্যা?

এটি একটি সহজাত সীমাবদ্ধতা, সম্পূর্ণ এড়ানো কঠিন — যেকোনো থ্রেশহোল্ড-ভিত্তিক সিস্টেমেই সীমারেখার ঠিক কাছাকাছি এই ধরনের "কৃত্রিম লাফ" ঘটবে। ডিজাইনের দিক থেকে এটি সম্পূর্ণ দূর করা যায় না, তবে প্রভাব কমানো যায় — যেমন সীমারেখার কাছাকাছি স্কোরের জন্য একটি ট্রানজিশনাল ভাষা ব্যবহার করে ("মাঝারি থেকে নিম্নের মাঝামাঝি") অথবা ব্যান্ডের পাশাপাশি একটি ভিজ্যুয়াল গ্রেডিয়েন্ট (ধারাবাহিক রঙ পরিবর্তন) দেখিয়ে।

প্র ০২ একটি সিস্টেম যদি প্রতিটি পূর্বাভাসেই "উচ্চ নিশ্চয়তা" দেখায়, তাহলে এই ফিচারটি আসলে কী সমস্যা তৈরি করতে পারে?

যদি সবসময় "উচ্চ নিশ্চয়তা" দেখানো হয়, তাহলে এই সংকেতটি তথ্যবহুল থাকে না — ব্যবহারকারী দ্রুত বুঝে যান যে এটি সবসময় একই কথা বলে, তাই এটিকে উপেক্ষা করা শুরু করেন। এটি ঠিক M3-এর অটোমেশন-বায়াস সমস্যার মতোই: একটি সিগন্যাল যা প্রকৃত পরিস্থিতির সাথে পরিবর্তিত হয় না, তা ব্যবহারকারীর জন্য কার্যত অকেজো হয়ে যায়, এমনকি যদি এর অন্তর্নিহিত সংখ্যা টেকনিক্যালি সঠিক থাকে।

প্র ০৩ আপনি কি এমন কোনো অ্যাপ/প্রোডাক্ট ব্যবহার করেছেন যা আনসার্টেইনটি ভালোভাবে (বা খারাপভাবে) কমিউনিকেট করে? কীভাবে?

একটি সাধারণ উদাহরণ হলো আবহাওয়া-পূর্বাভাস অ্যাপ — "৭০% বৃষ্টির সম্ভাবনা" এর পাশাপাশি প্রায়ই একটি আইকন ও রঙ ব্যবহার করে, এবং ভাষাটি সাধারণত হেজড থাকে ("বৃষ্টি হতে পারে")। এটি তুলনামূলক ভালো উদাহরণ, কারণ বেশিরভাগ মানুষ বহু বছর ধরে এই সংখ্যাগুলোর সাথে পরিচিত হয়ে সেগুলোর প্রকৃত অর্থ শিখেছেন — যা দেখায় যে ভালো আনসার্টেইনটি কমিউনিকেশন ডিজাইনের পাশাপাশি ধারাবাহিক, দীর্ঘমেয়াদী ব্যবহারও গুরুত্বপূর্ণ ভূমিকা রাখে।

অনুশীলন

  1. চিন্তা করুন: confidence_band(0.90) এবং confidence_band(0.35) — এই দুটি ঠিক থ্রেশহোল্ডের মানের উপর বসে থাকা কল করলে কোন ব্যান্ড ফেরত আসবে বলে আপনার ধারণা?

    যেহেতু কোডের শর্তগুলো >= (গ্রেটার-দ্যান-অর-ইকুয়াল) ব্যবহার করে, তাই ঠিক থ্রেশহোল্ডের মানটিও সেই উচ্চতর ব্যান্ডে পড়া উচিত — অর্থাৎ ০.৯০ "উচ্চ নিশ্চয়তা" এবং ০.৩৫ "নিম্ন নিশ্চয়তা" (নয় "অত্যন্ত নিম্ন") হওয়া উচিত বলে অনুমান করা যায়।

  2. পরীক্ষা করুন: উপরের কোডে test_scores-এর শেষে 0.90, 0.35 যোগ করে Run চেপে আপনার অনুমান যাচাই করুন।

    যাচাই করলে দেখা যায় অনুমানটি সঠিক: confidence_band(0.90) ফেরত দেয় "উচ্চ নিশ্চয়তা" এবং confidence_band(0.35) ফেরত দেয় "নিম্ন নিশ্চয়তা" (অত্যন্ত নিম্ন নয়)। এটি একটি গুরুত্বপূর্ণ ডিজাইন-সংক্রান্ত বিস্তারিত: থ্রেশহোল্ড >= নাকি > দিয়ে সংজ্ঞায়িত করা হয়েছে তা নির্ধারণ করে সীমারেখার ঠিক উপরে/নিচে থাকা মান কোন ব্যান্ডে পড়বে — এই সিদ্ধান্তটি ইচ্ছাকৃত ও সামঞ্জস্যপূর্ণভাবে নেওয়া উচিত, দুর্ঘটনাক্রমে নয়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
এক্সপ্লেনেশনের ধরন — গ্লোবাল, লোকাল, কন্ট্রাস্টিভ ও উদাহরণ-ভিত্তিক