পাঠ ২০ · ৫৭-এর মধ্যে · মডিউল ৫
Home / AI Courses / AI Ethics / মেনি হ্যান্ডস সমস্যা

অ্যাকাউন্টেবিলিটি ও "মেনি হ্যান্ডস" সমস্যা

Accountability & the problem of many hands
৬ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

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

  • "the problem of many hands" ধারণাটি কী এবং কেন এটি AI সিস্টেমে বিশেষভাবে প্রকট
  • একটি AI পাইপলাইনের কোন কোন পক্ষ দায়বদ্ধতার সম্ভাব্য অংশীদার হতে পারে
  • দায় "বিতরিত" হওয়া আর দায় "শূন্য" হওয়া — এই দুটোর মধ্যকার গুরুত্বপূর্ণ পার্থক্য
  • একটি সত্যিকারের, চলমান ডেমো — একটি ঘটনার জন্য ওজন-ভিত্তিক দায়-বণ্টন স্কোরিং

১ · "মেনি হ্যান্ডস" সমস্যা কী

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

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

২ · একটি সত্যিকারের দায়-বণ্টন গণনা

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

Python
# একটি কাল্পনিক হায়ারিং-AI ঘটনার জন্য ওজন-ভিত্তিক দায়-বণ্টন গণনা
# প্রতিটি মাত্রা ০ (নেই) থেকে ৩ (সর্বোচ্চ) স্কেলে -- এই স্কোরগুলো ইলাস্ট্রেটিভ, বাস্তব কোনো তদন্তের ফল নয়

contributors = [
    {
        "role": "ডেটা ভেন্ডর (ঐতিহাসিক, বায়াসড রিজিউমে ডেটা সংগ্রহ করেছে)",
        "control": 2, "foreseeability": 1, "proximity": 1,
    },
    {
        "role": "ML ডেভেলপমেন্ট টিম (বায়াস-টেস্টিং ছাড়াই মডেল তৈরি করেছে)",
        "control": 3, "foreseeability": 3, "proximity": 2,
    },
    {
        "role": "ডিপ্লয়কারী প্রতিষ্ঠান (কোনো অডিট ছাড়াই প্রোডাকশনে চালু করেছে)",
        "control": 2, "foreseeability": 2, "proximity": 3,
    },
    {
        "role": "হায়ারিং ম্যানেজার (মডেলের সুপারিশ প্রশ্নহীনভাবে মেনে নিয়েছেন)",
        "control": 1, "foreseeability": 1, "proximity": 3,
    },
]

# ওজনগুলো যোগফলে ১.০ -- নিয়ন্ত্রণকে সবচেয়ে বেশি গুরুত্ব দেওয়া হয়েছে
WEIGHTS = {"control": 0.40, "foreseeability": 0.35, "proximity": 0.25}
assert abs(sum(WEIGHTS.values()) - 1.0) < 1e-9

for c in contributors:
    c["raw_score"] = sum(c[dim] * WEIGHTS[dim] for dim in WEIGHTS)

total_score = sum(c["raw_score"] for c in contributors)
for c in contributors:
    c["share_pct"] = c["raw_score"] / total_score * 100

print("দায়বদ্ধতা বণ্টন (weighted responsibility allocation):\n")
for c in sorted(contributors, key=lambda c: -c["share_pct"]):
    print(f"{c['role']}")
    print(f"  control={c['control']}, foreseeability={c['foreseeability']}, proximity={c['proximity']}")
    print(f"  raw score = {c['raw_score']:.2f}  ->  দায়ের ভাগ: {c['share_pct']:.1f}%\n")

print(f"মোট: {sum(c['share_pct'] for c in contributors):.1f}%")
print("লক্ষ্য করুন -- কোনো একক পক্ষের ভাগ ১০০% নয়, আবার কোনো পক্ষের ভাগই ০% নয়।")
print("দায় বিতরিত (distributed), কিন্তু অস্তিত্বহীন নয় -- এটাই 'problem of many hands'-এর মূল কথা।")

    
লক্ষ্য করুন — উপরের গণনায় ML ডেভেলপমেন্ট টিম সর্বোচ্চ ভাগ পায় (কারণ তাদের নিয়ন্ত্রণ ও পূর্বানুমানযোগ্যতা উভয়ই বেশি — তারাই বায়াস-টেস্ট এড়িয়ে গিয়েছিল), কিন্তু বাকি তিন পক্ষও শূন্য নয়। এই সংখ্যাগুলো (control, foreseeability, proximity স্কোর, ওজন) সম্পূর্ণ ইলাস্ট্রেটিভ — বাস্তব জীবনে এই ধরনের স্কোরিং একটি আনুষ্ঠানিক তদন্ত, আইনি প্রক্রিয়া, বা প্রাতিষ্ঠানিক পর্যালোচনার মাধ্যমে নির্ধারিত হয়। এখানকার মূল শিক্ষা হলো — দায়বদ্ধতাকে একটি বাইনারি (হয় ১০০%, নয় ০%) প্রশ্ন হিসেবে না দেখে, একটি বিতরিত কিন্তু বাস্তব প্রশ্ন হিসেবে কাঠামোগতভাবে বিশ্লেষণ করা সম্ভব।
মূল কথা · Key takeaway

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

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

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

প্র ০১ উপরের কোড সেলে যদি WEIGHTS-এ proximity-কে সবচেয়ে বেশি গুরুত্ব দেওয়া হতো (যেমন ০.৫), তাহলে কোন পক্ষের ভাগ সবচেয়ে বেশি বাড়তো বলে আপনার ধারণা?

হায়ারিং ম্যানেজার ও ডিপ্লয়কারী প্রতিষ্ঠান — উভয়েরই proximity = 3 (ক্ষতির সবচেয়ে কাছাকাছি)। এটি দেখায় দায়-বণ্টনের ফলাফল সরাসরি নির্ভর করে "কোন মাত্রাকে কতটা গুরুত্ব দেওয়া হচ্ছে" তার উপর — বাস্তব জীবনেও এই বিতর্ক থাকে: "যে সরাসরি সিদ্ধান্ত নিয়েছে সে বেশি দায়ী, নাকি যে মূল ত্রুটিটি তৈরি করেছে সে বেশি দায়ী?" কোনো একক "সঠিক" ওজন নেই — এটি একটি নৈতিক/নীতিগত বিচার, শুধু গাণিতিক সমস্যা নয়।

প্র ০২ একজন ডিপ্লয়কারী প্রতিষ্ঠানের কর্মকর্তা বলছেন, "আমরা তো মডেলটি বানাইনি, শুধু কিনেছি — তাই দায় সম্পূর্ণ ভেন্ডরের।" উপরের ডেমোর আলোকে এই দাবিতে কী সমস্যা?

সমস্যা হলো, "কে তৈরি করেছে" আর "কে ডিপ্লয় করেছে ও কীভাবে ব্যবহার করেছে" — এই দুটো ভিন্ন প্রশ্ন। উপরের ডেমোতে ডিপ্লয়কারী প্রতিষ্ঠানের proximity স্কোর সবচেয়ে বেশি (৩) কারণ তারাই সিদ্ধান্ত নিয়েছে কোনো অডিট ছাড়া সিস্টেমটি প্রোডাকশনে চালু করতে — এটি তাদের নিজস্ব, স্বাধীন সিদ্ধান্ত, ভেন্ডরের কাছ থেকে মডেল কেনা মাত্রই সেই সিদ্ধান্তের দায় থেকে মুক্তি দেয় না। ক্রয়কৃত সিস্টেম ব্যবহার করাও নিজস্ব দায়িত্বশীল ব্যবহারের (due diligence) বাধ্যবাধকতা তৈরি করে।

প্র ০৩ বাস্তব জীবনে একটি প্রতিষ্ঠান কীভাবে আগে থেকেই "মেনি হ্যান্ডস" সমস্যা কমাতে পারে, ক্ষতি হওয়ার আগেই?

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

অনুশীলন

  1. চিন্তা করুন: উপরের কোড সেলে যদি একটি পঞ্চম পক্ষ যোগ করা হয় — "রেগুলেটর (কোনো বায়াস-নিরীক্ষা বাধ্যতামূলক করেনি)" — control=1, foreseeability=2, proximity=0 সহ — তাহলে বাকি চার পক্ষের শতাংশ ভাগের কী হবে বলে আপনার ধারণা?

    বাকি চার পক্ষের প্রতিটির শতাংশ ভাগ কিছুটা কমে যাবে, কারণ total_score (হর) বেড়ে যাবে নতুন পক্ষের raw_score যোগ হওয়ায়, কিন্তু প্রতিটি পুরনো পক্ষের raw_score (লব) অপরিবর্তিত থাকবে — ভাগফল তাই স্বাভাবিকভাবেই ছোট হবে। মোট যোগফল তবুও ১০০%-ই থাকবে, শুধু এখন পাঁচ পক্ষের মধ্যে ভাগ হবে।

  2. পরীক্ষা করুন: উপরের কোড সেলে contributors তালিকায় নতুন পক্ষটি যোগ করে Run চেপে আপনার অনুমান যাচাই করুন।

    নতুন পক্ষ যোগ করলে আউটপুটে ৫টি পক্ষের শতাংশ দেখাবে, প্রতিটি পুরনো পক্ষের শতাংশ আগের চেয়ে সামান্য কম হবে, এবং সবগুলোর যোগফল এখনও প্রায় ১০০.০% থাকবে (রাউন্ডিং-এর কারণে সামান্য ওঠানামা হতে পারে)। এটি নিশ্চিত করে যে গণনাটি সত্যিই ডায়নামিক — নতুন কোনো পক্ষ যোগ করলে বণ্টন স্বয়ংক্রিয়ভাবে পুনর্গণনা হয়।

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

  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ নৈতিক ফ্রেমওয়ার্ক, বায়াস-ফেয়ারনেস, প্রাইভেসি, ট্রান্সপারেন্সি, AI অ্যালাইনমেন্ট, জেনারেটিভ AI/LLM এথিক্স, সামাজিক প্রভাব, গভর্নেন্স ও রেগুলেশন, সেক্টর-স্পেসিফিক এথিক্স ও এক্সিস্টেনশিয়াল রিস্ক বিতর্ক — বাকি পাঠগুলো দেখুন।
  • Ethics in Computing & AI Safety কোর্স সহোদর কোর্স সাধারণ কম্পিউটিং এথিক্স, প্রফেশনাল এথিক্স ও সেফটি-ক্রিটিক্যাল কেস স্টাডির একটি বিস্তৃত সার্ভে — এই কোর্স সম্পূর্ণভাবে AI-তে ফোকাস করে গভীরে যায়।
  • সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, Machine Learning, Deep Learning, System Design, Cybersecurity, Cloud Computing & DevOps, এবং আরও অনেক কোর্স — সব এক জায়গায়।
আগের পাঠ
এক্সপ্লেইনেবল AI (XAI) টেকনিক — LIME ও SHAP-এর ধারণা