পাঠ ০২ · ৫৭-এর মধ্যে · মডিউল ১
Home / Courses / Ethics in Computing & AI Safety / ফাউন্ডেশন

কম্পিউটিং এথিক্সের ব্যর্থতার সংক্ষিপ্ত ইতিহাস ও শিক্ষা

A brief history of computing ethics failures & lessons
৮ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

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

  • কম্পিউটিং এথিক্সের ব্যর্থতাগুলো কেন বিচ্ছিন্ন দুর্ঘটনা হিসেবে না দেখে পুনরাবৃত্ত প্যাটার্ন হিসেবে দেখা উচিত
  • Therac-25, Boeing 737 MAX/MCAS, এবং COMPAS/ProPublica তদন্তের সংক্ষিপ্ত, তথ্যনির্ভর পরিচিতি
  • এই তিনটি ভিন্ন ডোমেইনের ঘটনার মধ্যেও সাধারণ দুটি রুট-কজ প্যাটার্ন চিহ্নিত করা
  • Python দিয়ে একটি ছোট্ট প্যাটার্ন-ট্যালি — সংখ্যা দিয়ে দেখা কোন প্যাটার্নটি সবচেয়ে বেশি পুনরাবৃত্ত হয়

১ · কেন অতীতের ব্যর্থতা পড়া জরুরি

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

২ · তিনটি সুপরিচিত ঘটনার সংক্ষিপ্ত সময়রেখা

Therac-25 ১৯৮৫-৮৭ রেডিয়েশন ওভারডোজ (সফটওয়্যার সেফটি) COMPAS ২০১৬ · ProPublica রিসিডিভিজম প্রেডিকশন (অ্যালগরিদমিক ফেয়ারনেস) Boeing 737 MAX ২০১৮-১৯ · MCAS ফ্লাইট কন্ট্রোল সফটওয়্যার (সফটওয়্যার সেফটি) L25-এ বিস্তারিত L17-এ বিস্তারিত L26-এ বিস্তারিত
তিনটি ভিন্ন দশক, ভিন্ন ডোমেইন (সফটওয়্যার সেফটি বনাম অ্যালগরিদমিক ফেয়ারনেস) — তবু নিচের সেকশনে দেখা যাবে, এদের মধ্যে কাঠামোগত মিল আছে।
Therac-25
একটি কম্পিউটার-নিয়ন্ত্রিত রেডিয়েশন থেরাপি মেশিন। আগের মডেলগুলোতে থাকা হার্ডওয়্যার সেফটি ইন্টারলক সরিয়ে শুধু সফটওয়্যার চেকের উপর নির্ভর করা হয়েছিল। অপারেটর দ্রুত একটি নির্দিষ্ট ক্রমে প্যারামিটার এডিট করলে একটি রেস কন্ডিশনের কারণে সেফটি চেক এড়িয়ে যেত, আর মেশিনটি উদ্দিষ্ট মাত্রার প্রায় ১০০ গুণ বেশি রেডিয়েশন বিম দিতে পারত। কয়েকজন রোগী মারা যান বা গুরুতর, বিকৃতকারী আঘাত পান।
Boeing 737 MAX / MCAS
MCAS নামের একটি ফ্লাইট-কন্ট্রোল সফটওয়্যার ফিচার প্লেনের নাক স্বয়ংক্রিয়ভাবে নিচে ঠেলে দিতে পারত, শুরুতে একটিমাত্র অ্যাঙ্গেল-অফ-অ্যাটাক সেন্সরের উপর নির্ভর করে, দ্বিতীয় সেন্সরের সাথে কোনো ক্রস-চেক ছাড়াই। পাইলটদের ট্রেনিং উপকরণে MCAS সম্পর্কে পর্যাপ্ত তথ্য ছিল না। প্রায় পাঁচ মাসের ব্যবধানে দুটি প্রাণঘাতী দুর্ঘটনা ঘটে (লায়ন এয়ার ফ্লাইট ৬১০ ও ইথিওপিয়ান এয়ারলাইন্স ফ্লাইট ৩০২), একত্রে ৩০০-র বেশি মানুষ মারা যান, আর পুরো ৭৩৭ ম্যাক্স ফ্লিট বিশ্বব্যাপী দীর্ঘ সময়ের জন্য গ্রাউন্ডেড হয়।
COMPAS / ProPublica
COMPAS একটি ঝুঁকি-মূল্যায়ন অ্যালগরিদম যা যুক্তরাষ্ট্রের ফৌজদারি বিচার ব্যবস্থার কিছু অংশে আসামির পুনরায় অপরাধ করার সম্ভাবনা প্রেডিক্ট করতে ব্যবহৃত হয়। ২০১৬ সালের একটি বহুল-উদ্ধৃত ProPublica তদন্ত ("Machine Bias") দেখায় — সামগ্রিক নির্ভুলতা ও ক্যালিব্রেশন গোষ্ঠীভেদে প্রায় সমান থাকলেও, প্রকৃত এরর রেট (কে ভুলভাবে "উচ্চ-ঝুঁকি" চিহ্নিত হলো, কে "নিম্ন-ঝুঁকি") জাতিগত গোষ্ঠীভেদে ভিন্ন ছিল।

৩ · পুনরাবৃত্ত প্যাটার্ন

উপরের তিনটি ঘটনা সম্পূর্ণ ভিন্ন ডোমেইনের (দুটি সফটওয়্যার সেফটি, একটি অ্যালগরিদমিক ফেয়ারনেস) — অথচ কাঠামোগতভাবে অন্তত দুটি প্যাটার্ন এখানে বারবার দেখা যায়:

  • একটিমাত্র সেফগার্ডের উপর অতিরিক্ত নির্ভরতা — Therac-25-এ হার্ডওয়্যার ইন্টারলক সরিয়ে শুধু সফটওয়্যারের উপর, আর Boeing-এ শুধু একটি সেন্সরের উপর, কোনো স্বাধীন দ্বিতীয় যাচাই ছাড়াই নির্ভর করা।
  • সামগ্রিক মেট্রিক্সের আড়ালে বৈষম্য লুকিয়ে থাকা — COMPAS-এ সামগ্রিক নির্ভুলতা "ঠিক আছে" দেখানো সত্ত্বেও গোষ্ঠীভেদে এরর রেটের বৈষম্য চাপা পড়ে গিয়েছিল।

নিচের কোড সেলে এই তিনটি ঘটনাকে সহজ বুলিয়ান ট্যাগ দিয়ে চিহ্নিত করে দেখা যাক — সংখ্যায় দেখলে কোন প্যাটার্নটি সবচেয়ে বেশি পুনরাবৃত্ত হয়।

Python
# তিনটি সুপরিচিত, সুপ্রতিষ্ঠিত (well-documented) কম্পিউটিং এথিক্স ব্যর্থতার ঘটনা --
# পূর্ণাঙ্গ কেস স্টাডি পরে আসবে (Therac-25: L25, Boeing 737 MAX: L26, COMPAS: L17)।
# এখানে শুধু পুনরাবৃত্ত রুট-কজ প্যাটার্ন চিহ্নিত করার জন্য একটি সহজ ট্যালি।

cases = [
    {
        "name": "Therac-25 (1985-1987)",
        "domain": "সফটওয়্যার সেফটি",
        # হার্ডওয়্যার ইন্টারলক সরিয়ে শুধু সফটওয়্যার চেকের উপর নির্ভরতা
        "over_reliance_on_single_safeguard": True,
        "aggregate_metric_hid_disparate_harm": False,
    },
    {
        "name": "Boeing 737 MAX / MCAS (2018-2019)",
        "domain": "সফটওয়্যার সেফটি",
        # একটিমাত্র অ্যাঙ্গেল-অফ-অ্যাটাক সেন্সর, কোনো রিডানডেন্সি ছাড়াই
        "over_reliance_on_single_safeguard": True,
        "aggregate_metric_hid_disparate_harm": False,
    },
    {
        "name": "COMPAS / ProPublica (2016)",
        "domain": "অ্যালগরিদমিক ফেয়ারনেস",
        "over_reliance_on_single_safeguard": False,
        # সামগ্রিক accuracy/ক্যালিব্রেশন সমান হলেও গোষ্ঠীভেদে এরর রেট ভিন্ন ছিল
        "aggregate_metric_hid_disparate_harm": True,
    },
]

pattern_keys = ["over_reliance_on_single_safeguard", "aggregate_metric_hid_disparate_harm"]
pattern_counts = {key: 0 for key in pattern_keys}

for case in cases:
    for key in pattern_keys:
        if case[key]:
            pattern_counts[key] += 1

for case in cases:
    flags = [key for key in pattern_keys if case[key]]
    print(f"{case['name']} ({case['domain']}): {', '.join(flags) if flags else 'কোনো ট্যাগ নেই'}")

print()
for key, count in pattern_counts.items():
    print(f"'{key}' প্যাটার্নটি {count}/{len(cases)}টি ঘটনায় উপস্থিত")

most_common = max(pattern_counts, key=pattern_counts.get)
print(f"\nএই তিনটি ভিন্ন ডোমেইনের ঘটনার মধ্যেও সবচেয়ে সাধারণ প্যাটার্ন: '{most_common}'")

    
লক্ষ্য করুন কোডে ব্যবহৃত বুলিয়ান ট্যাগগুলো একটি সরলীকৃত শ্রেণিবিন্যাস — বাস্তব ঘটনাগুলোর পূর্ণাঙ্গ জটিলতা (মানবিক, প্রাতিষ্ঠানিক, নিয়ন্ত্রক — সব দিক) এখানে ধরা পড়ে না। উদ্দেশ্য হলো এই তিনটি ঘটনার মধ্যে একটি কাঠামোগত সাদৃশ্য সংখ্যায় দেখানো, বাস্তব ঘটনাগুলোর সম্পূর্ণ বিবরণ প্রতিস্থাপন করা নয়।
মূল কথা · Key takeaway

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

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

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

প্র ০১ Therac-25 ও Boeing 737 MAX একটি সফটওয়্যার সেফটি ব্যর্থতা, কিন্তু COMPAS একটি অ্যালগরিদমিক ফেয়ারনেস সমস্যা — তবু এই পাঠে তিনটিকে একসাথে কেন আলোচনা করা হলো?

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

প্র ০২ Therac-25-এ হার্ডওয়্যার ইন্টারলক সরিয়ে ফেলা কেন বিপজ্জনক ছিল, যেখানে সফটওয়্যার চেক তাত্ত্বিকভাবে একই কাজ করতে পারে?

কারণ সফটওয়্যারেও বাগ থাকতে পারে — এক্ষেত্রে একটি রেস কন্ডিশন, যেখানে অপারেটর দ্রুত একটি নির্দিষ্ট ক্রমে প্যারামিটার এডিট করলে সেফটি চেকটি এড়িয়ে যেত। হার্ডওয়্যার ইন্টারলক একটি স্বাধীন, সফটওয়্যারের বাগ থেকে প্রভাবিত না-হওয়া দ্বিতীয় স্তরের সুরক্ষা দিতো। সেই স্বাধীন দ্বিতীয় স্তরটি সরিয়ে ফেলায় সফটওয়্যারের একটি একক বাগই সরাসরি রোগীর ক্ষতির কারণ হতে পেরেছিল — এটিই "একটিমাত্র সেফগার্ডের উপর নির্ভরতা"-র বিপদ।

প্র ০৩ উপরের কোড সেলে যদি একটি চতুর্থ কেস যোগ করা হয় যার over_reliance_on_single_safeguard এবং aggregate_metric_hid_disparate_harm — দুটোই True, তাহলে pattern_counts ও most_common কীভাবে বদলাবে?

pattern_counts["over_reliance_on_single_safeguard"] ২ থেকে বেড়ে ৩ হবে, আর pattern_counts["aggregate_metric_hid_disparate_harm"] ১ থেকে বেড়ে ২ হবে। যেহেতু ৩ এখনও ২-এর চেয়ে বড়, most_common অপরিবর্তিত থাকবে ("over_reliance_on_single_safeguard")। প্যাটার্নটি তখনও সবচেয়ে বেশি (৪টির মধ্যে ৩টি) কেসে উপস্থিত থাকবে।

অনুশীলন

  1. চিন্তা করুন: আপনি নিয়মিত ব্যবহার করেন এমন একটি প্রযুক্তির কথা ভাবুন। এটি কি কোনো একটি মাত্র "সেফগার্ড" (একটি সেন্সর, একটি মেট্রিক্স, একটি রিভিউ ধাপ) এর উপর নির্ভর করে, যা ব্যর্থ হলে কোনো স্বাধীন দ্বিতীয় যাচাই নেই?

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

  2. পরীক্ষা করুন: উপরের কোড সেলে cases লিস্টে একটি নতুন, কাল্পনিক চতুর্থ কেস যোগ করুন যার দুটো ট্যাগই False — Run চেপে দেখুন pattern_counts ও most_common কীভাবে বদলায়।

    দুটো ট্যাগই False হওয়া একটি নতুন কেস যোগ করলে pattern_counts-এর কোনো মান বদলাবে না (কারণ নতুন কেসে কোনো True ট্যাগ নেই), কিন্তু len(cases) ৩ থেকে ৪ হয়ে যাবে — তাই প্রতিটি প্যাটার্নের "X/৪" অনুপাত কমে যাবে (২/৪ এবং ১/৪), যদিও most_common অপরিবর্তিত থাকবে।

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

আগের পাঠ
কম্পিউটিং এথিক্স কী ও কেন গুরুত্বপূর্ণ