স্বয়ংক্রিয় যানবাহন, শিল্পকারখানার রোবট এবং ড্রোন বহর সেই কঠোর, হাতে লেখা নিয়মাবলী অনুসরণ করে না যা পুরনো অটো-পাইলট সিস্টেমগুলোকে চালিত করত। তারা বিশাল পরিমাণ ডেটা থেকে শেখে, যার অর্থ তাদের আচরণ সম্ভাব্য (probabilistic), নিশ্চিত (deterministic) নয়। একটি প্রথাগত বিমানের অটো-পাইলট স্পষ্টভাবে কোড করা লজিকের মাধ্যমে সেন্সর ইনপুটের প্রতিক্রিয়া জানায়। একটি মেশিন লার্নিং মডেল প্রশিক্ষণের সময় প্রাপ্ত প্যাটার্নের মাধ্যমে প্রতিক্রিয়া জানায়। এই পার্থক্য যাচাইকরণ প্রক্রিয়াকে অনেক বেশি কঠিন করে তোলে, আর ঠিক এই কারণেই মেশিন লার্নিং কমিউনিটি অ্যাড-হক (ad-hoc) টেস্টিংয়ের পরিবর্তে কাঠামোগত অ্যাসিউরেন্স ফ্রেমওয়ার্কের (assurance frameworks) দিকে ঝুঁকেছে।
কেন মেশিন লার্নিং অ্যাসিউরেন্স অপরিহার্য
যখন একটি স্বয়ংক্রিয় সিস্টেম ভুল করে, তখন তার ফলাফল কেবল একটি সার্ভার ত্রুটি বা একটি ফ্রিজ হয়ে যাওয়া অ্যাপ্লিকেশনের মধ্যেই সীমাবদ্ধ থাকে না। একটি গুদামের রোবট যদি কোনো বাধা ভুলভাবে শনাক্ত করে, তবে তা ইনভেন্টরি ধ্বংস করতে পারে বা কোনো কর্মীকে আহত করতে পারে। একটি ডেলিভারি ড্রোন যদি পাওয়ার লাইনকে খোলা আকাশ হিসেবে শনাক্ত করে, তবে তা অবকাঠামোতে ধাক্কা খেয়ে বিধ্বস্ত হতে পারে। যেহেতু এই সিস্টেমগুলো জটিল নিউরাল নেটওয়ার্ক এবং স্ট্যাটিস্টিক্যাল মডেলের ওপর নির্ভর করে, তাই এদের ব্যর্থতার ধরনগুলো অত্যন্ত সূক্ষ্ম হয়। এগুলো খুব কমই সরাসরি বা স্পষ্ট উপায়ে ভেঙে পড়ে। পরিবর্তে, প্রশিক্ষণের সময় দেখা ডেটা ডিস্ট্রিবিউশনের বাইরে কোনো ইনপুট পেলে এগুলো নিঃশব্দে কার্যক্ষমতা হারাতে থাকে।
স্বয়ংক্রিয় মেশিন লার্নিংয়ের ত্রুটিগুলো সবসময় স্পষ্ট কোনো খারাপ কোড থেকে উদ্ভূত হয় না। এগুলো ট্রেনিং ডেটার ঘাটতি, অপ্রত্যাশিত পরিবেশগত পরিবর্তন বা এজ কেসগুলোতে (edge cases) অতিরিক্ত আত্মবিশ্বাসী পূর্বাভাসের কারণে তৈরি হতে পারে। যেসব সংস্থা ML কম্পোনেন্টগুলোকে সাধারণ সফটওয়্যার মডিউলের মতো বিবেচনা করে এবং মনে করে যে একটি ইউনিট টেস্ট স্যুটই যথেষ্ট, তারা অনেক দেরিতে বুঝতে পারে যে ল্যাবরেটরির নির্ভুলতা বাস্তব জগতের নিরাপত্তার গ্যারান্টি দেয় না। আপনার এমন একটি পদ্ধতিগত মানদণ্ড প্রয়োজন যা শেখা আচরণের (learned behavior) অনন্য ঝুঁকিগুলো মোকাবিলা করতে পারে। AMLAS ফ্রেমওয়ার্কটি ঠিক এই শূন্যতা পূরণ করার জন্যই তৈরি করা হয়েছে।
AMLAS আসলে কী কী কভার করে
AMLAS, যার পূর্ণরূপ হলো Assurance of Machine Learning for use in Autonomous Systems, এটি নিশ্চিত করার জন্য একটি এন্ড-টু-এন্ড পদ্ধতি প্রদান করে যে শেখা কম্পোনেন্টগুলো উচ্চ-ঝুঁকিপূর্ণ ব্যবহারের (high-stakes deployment) জন্য উপযুক্ত কি না। এটি নিরাপত্তাকে কেবল রিলিজের আগের কোনো শেষ ধাপ বা afterthought হিসেবে দেখে না। পরিবর্তে, এটি সিস্টেমের লাইফসাইকেলের সাথে অ্যাসিউরেন্স কার্যক্রমগুলোকে গেঁথে দেয়।
ফ্রেমওয়ার্কটি তিনটি ব্যবহারিক স্তম্ভের ওপর গুরুত্ব দেয়:
ML মডেলের জন্য যাচাইকরণ পদ্ধতি। এটি অ্যাকুরেসি (accuracy) বা F1 স্কোরের মতো সাধারণ ট্রেইন-টেস্ট স্প্লিট মেট্রিক্সের অনেক বাইরে গিয়ে কাজ করে। AMLAS-এর অধীনে অ্যাসিউরেন্স প্রশ্ন করে যে মডেলটি ডিসিশন বাউন্ডারিতে (decision boundaries) অনুমানযোগ্যভাবে আচরণ করে কি না, আউট-অফ-ডিস্ট্রিবিউশন (out-of-distribution) ইনপুটের প্রতি এটি কীভাবে প্রতিক্রিয়া জানায় এবং এর কনফিডেন্স স্কোরগুলো প্রকৃত অনিশ্চয়তার নির্ভরযোগ্য সূচক কি না। ইঞ্জিনিয়ারদের কাছ থেকে আশা করা হয় যে তারা অ্যাডভারসারিয়াল উদাহরণ (adversarial examples) দিয়ে মডেলটিকে পরীক্ষা করবেন এবং ট্রেনিং সেটের কিছুটা বাইরের ডোমেইন থেকে আসা ইনপুট দিয়ে স্ট্রেস-টেস্ট করবেন। লক্ষ্য নিখুঁত হওয়া নয়; বরং পর্যাপ্ত প্রমাণ সংগ্রহ করা যাতে জানা যায় কখন মডেলটিকে বিশ্বাস করা যায় এবং কখন করা যায় না।
স্বয়ংক্রিয় কাজের জন্য নিরাপত্তা প্রোটোকল। একটি শেখা পারসেপশন মডেল প্ল্যানিং এবং কন্ট্রোল সফটওয়্যারে ডেটা সরবরাহ করে যা ফিজিক্যাল হার্ডওয়্যারকে পরিচালনা করে। AMLAS দাবি করে যে এই ডাউনস্ট্রিম অ্যাকশনগুলোতে গার্ডরেল (guardrails) অন্তর্ভুক্ত থাকতে হবে। এমনকি যদি একটি নিউরাল নেটওয়ার্ক কোনো বস্তুকে ভুলভাবে ক্লাসিফাই করে, তবুও যানবাহন বা রোবটটি এমন কোনো ট্র্যাজেক্টরি (trajectory) অনুসরণ করতে সক্ষম হওয়া উচিত নয় যা কঠোর সীমাবদ্ধতা (hard constraints) লঙ্ঘন করে। এর অর্থ হতে পারে রোবোটিক আর্মের টর্ক লিমিট, ড্রোনের জন্য জিওফেন্সিং (geofencing), অথবা স্থল যানবাহনের জন্য বাধ্যতামূলক ব্রেকিং করিডোর। স্বয়ংক্রিয় সিস্টেমের এমন আর্কিটেকচারাল লেয়ার প্রয়োজন যা একটি মাত্র মডেল ত্রুটিকে একটি অনিয়ন্ত্রিত শারীরিক ঘটনায় পরিণত হওয়া থেকে রক্ষা করবে।
অনিশ্চয়তা কমানোর পদ্ধতি। মেশিন লার্নিংয়ে অনিশ্চয়তা বিভিন্ন রূপে আসে। এখানে রয়েছে অ্যালিয়েটোরিক অনিশ্চয়তা (aleatoric uncertainty), যা সেন্সর রিডিং বা পরিবেশে বিদ্যমান সহজাত নয়েজ এবং এপিস্টেমিক অনিশ্চয়তা (epistemic uncertainty), যা মডেলটি এখনও কী জানে না তা প্রতিফলিত করে। AMLAS এমন অনুশীলনগুলোকে উৎসাহিত করে যা এই উভয়কেই পরিমাপ এবং পরিচালনা করতে পারে। এর কৌশলগুলোর মধ্যে এনসেম্বল মেথড (ensemble methods) অন্তর্ভুক্ত থাকতে পারে, যেখানে একাধিক মডেলের মধ্যে মতপার্থক্যকে সতর্ক সংকেত হিসেবে চিহ্নিত করা হয়, অথবা ইনপুট ভ্যালিডেশন লেয়ার থাকতে পারে যা বিশৃঙ্খল আচরণ সৃষ্টি করতে পারে এমন ডেটা প্রত্যাখ্যান করে। আপনি হয়তো অনিশ্চয়তা পুরোপুরি দূর করতে পারবেন না, কিন্তু আপনি সিস্টেমটিকে এর ওপর ভিত্তি করে অন্ধভাবে কাজ করা থেকে বিরত রাখতে পারেন।
বিশ্বাস তৈরির একটি ব্যবহারিক পথ
ফ্রেমওয়ার্কগুলো তখনই গুরুত্বপূর্ণ যখন দলগুলো সেগুলো বাস্তবে প্রয়োগ করে। যখন সংস্থাগুলো একটি সুশৃঙ্খল অনুক্রম অনুসরণ করে, তখনই AMLAS সবচেয়ে কার্যকরভাবে কাজে লাগে।
একটি মাত্র ডেটাসেট সংগ্রহ করার আগেই আপনার নিরাপত্তা লক্ষ্যগুলো নির্ধারণ করুন। প্রথাগত সফটওয়্যার ইঞ্জিনিয়ারিংয়ে প্রয়োজনীয়তাগুলো আগে আসে। মেশিন লার্নিং প্রজেক্টগুলো প্রায়শই এর উল্টোটা করে, যেখানে মডেল প্রশিক্ষিত হওয়ার পরে নিরাপত্তাকে একটি সমস্যা হিসেবে সমাধান করার চেষ্টা করা হয়। এই অভ্যাসটি পরিবর্তন করুন। একটি স্পষ্ট অপারেশনাল ডিজাইন ডোমেইন দিয়ে শুরু করুন। কোন পরিস্থিতিতে সিস্টেমটি চলবে? প্রতিটি বিপদের জন্য গ্রহণযোগ্য ব্যর্থতার হার কত হবে? কোন ব্যর্থতাগুলোর জন্য তাৎক্ষণিক মানুষের হস্তক্ষেপ প্রয়োজন? এই প্রশ্নগুলোর উত্তর শুরুতেই দিলে ডেটা সংগ্রহ থেকে শুরু করে মডেল আর্কিটেকচার পর্যন্ত সবকিছুই সঠিক পথে পরিচালিত হয়।
আপনার মডেলগুলোকে এমন ডেটার মাধ্যমে পরীক্ষা করুন যা প্রকৃত অপারেশনাল জটিলতা প্রতিফলিত করে। ল্যাব বেঞ্চমার্কগুলো আশ্বস্ত করতে পারে, কিন্তু সেগুলো মিথ্যা কথা বলে। একটি ওয়্যারহাউস রোবট যদি শুধুমাত্র নিখুঁত বারকোড ইমেজের ওপর প্রশিক্ষিত হয়, তবে লেবেল কুঁচকে গেলে, আলো কম হলে বা ময়লা দিয়ে ঢাকা থাকলে সেটি ব্যর্থ হবে। একটি অটোনোমাস ড্রোন যদি শুধুমাত্র পরিষ্কার আবহাওয়ায় পরীক্ষা করা হয়, তবে সেটি আলোর প্রতিফলন এবং বাতাসের ঝাপটার সাথে লড়াই করতে হিমশিম খাবে। আপনার প্রকৃত ডেপ্লয়মেন্ট এনভায়রনমেন্ট থেকে লগ প্রয়োজন, যার মধ্যে সেই বিরক্তিকর 'এজ কেস' গুলোও অন্তর্ভুক্ত থাকবে যা কিউরেটেড ডেটাসেটে কখনোই দেখা যায় না। শ্যাডো মোড ট্রায়াল চালান যেখানে অটোনোমাস সিস্টেমটি মানুষের পাশাপাশি সিদ্ধান্ত নেবে কিন্তু হার্ডওয়্যার নিয়ন্ত্রণ করবে না। লগগুলো কঠোরভাবে তুলনা করুন।
ডেপ্লয়মেন্টের পর ক্রমাগত পারফরম্যান্স পর্যবেক্ষণ করুন। পৃথিবী স্থির নয়। ঋতুভেদে আলোর পরিবর্তন, রাস্তার ক্ষয়প্রাপ্ত উপরিভাগ, নতুন প্যাকেজিং ডিজাইন এবং পরিবর্তনশীল নেটওয়ার্ক ট্রাফিক প্যাটার্ন—সবকিছুই এমন একটি মডেলের কার্যকারিতা কমিয়ে দিতে পারে যা একসময় চমৎকার পারফর্ম করেছিল। এমন টেলিমিতি সেটআপ করুন যা প্রেডিকশন কনফিডেন্স, ইনপুট ডিস্ট্রিবিউশন ড্রিফট এবং দুর্ঘটনার হার ট্র্যাক করে। আচরণের পরিবর্তন হলে মানুষের পর্যালোচনা বা সাময়িক অপারেশনাল সীমাবদ্ধতা কার্যকর করার জন্য থ্রেশহোল্ড নির্ধারণ করুন। একটি মডেল কোনো স্থির পণ্য নয় যা আপনি শিপ করে ভুলে যাবেন। এটি এমন একটি উপাদান যা বাস্তব জগতের সংস্পর্শে আসার মুহূর্ত থেকেই পুরনো হতে শুরু করে।
বাস্তব-বিশ্বের যাচাইকরণ সম্পর্কে কঠিন সত্য
অনেক টিম নিজেদের বোঝায় যে একটি উচ্চ ভ্যালিডেশন স্কোর প্রস্তুতির সংকেত। কিন্তু তা নয়। বাস্তব-বিশ্বের যাচাইকরণের জন্য অস্বস্তিকে গ্রহণ করতে হয়। এর মানে হলো দমকা হাওয়ার মধ্যে ড্রোন উড়ানো, রাতে ওয়্যারহাউস রোবট চালানো যখন বাল্বগুলো টিমটিম করে, এবং রাস্তার সাইনে থাকা অ্যাডভারসারিয়াল স্টিকারের মাধ্যমে পারসেপশন মডেলগুলোকে পরীক্ষা করা। যদি আপনার টেস্টিং এনভায়রনমেন্ট খুব পরিপাটি এবং অনুমানযোগ্য মনে হয়, তবে আপনি পরীক্ষা করছেন না; আপনি কেবল মহড়া দিচ্ছেন।
এই প্রক্রিয়াটি ব্যয়বহুল এবং ধীরগতির। এর জন্য মেশিন লার্নিং ইঞ্জিনিয়ার, সেফটি স্পেশালিস্ট এবং ডোমেইন অপারেটরদের মধ্যে সমন্বয় প্রয়োজন যারা ভৌত পরিবেশ সম্পর্কে বোঝেন। এর প্রতিদান হলো প্রমাণের একটি ভাণ্ডার। আপনি যখন শেষ পর্যন্ত ডেপ্লয় করবেন, তখন আপনি নির্দিষ্ট টেস্ট কন্ডিশন, পরিচিত ব্যর্থতার ধরন এবং প্রতিটি ঝুঁকির সাথে সম্পর্কিত প্রশমন ব্যবস্থাগুলো উল্লেখ করতে সক্ষম হবেন। এই ডকুমেন্টেশনই একটি প্রোটোটাইপ এবং মানুষের কাছাকাছি অনির্ভরযোগ্যভাবে পরিচালনা করা যায় এমন সিস্টেমের মধ্যে পার্থক্য তৈরি করে।
সময়ের সাথে সিস্টেমের সততা বজায় রাখা
ডেপ্লয়মেন্টের পরবর্তী পর্যবেক্ষণ হলো সেই জায়গা যেখানে অনেক অ্যাসুরেন্স প্রোগ্রাম নিঃশব্দে ভেঙে পড়ে। টিমগুলো লঞ্চ উদযাপন করে এবং পরবর্তী ফিচারের জন্য সম্পদ পুনর্নির্ধারণ করে। এদিকে, ডেপ্লয় করা মডেলটি এমন ইনপুটের সম্মুখীন হয় যা এর ট্রেনিং অভিজ্ঞতার থেকে সূক্ষ্মভাবে বিচ্যুত হয়। সক্রিয় পর্যবেক্ষণের অভাবে, এই ড্রিফট ততক্ষণ জমে থাকে যতক্ষণ না একটি গুরুতর ঘটনা প্রতিকারমূলক তদন্ত করতে বাধ্য করে।
সুসংগঠিত ফিডব্যাক লুপ সেটআপ করুন। মডেল যেখানে কম কনফিডেন্স প্রকাশ করে বা যেখানে মানুষের হস্তক্ষেপ প্রয়োজন হয়, এমন প্রতিটি ঘটনা লগ করুন। এই লগগুলো ব্যবহার করে পর্যায়ক্রমে মডেলটি রিট্রেন বা ফাইন-টিউন করুন, তবে প্রতিটি আপডেটকে সেই একই অ্যাসুরেন্স গেটের মাধ্যমে যাচাই করুন যা মূল রিলিজের ক্ষেত্রে প্রযোজ্য ছিল। মডেল আপডেটকে সেই একই সতর্কতার সাথে বিবেচনা করুন যা আপনি একটি যান্ত্রিক ব্রেক সিস্টেম পরিবর্তন করে নতুন ডিজাইনের ক্ষেত্রে প্রয়োগ করবেন।
আসল শিক্ষা
অটোনোমাস সিস্টেমে মেশিন লার্নিং কোনো রিসার্চ স্যান্ডবক্স নয়। এটি এমন একটি ইনফ্রাস্ট্রাকচার যা ভৌত ঝুঁকি বহন করে, এবং এটি সেই একই কঠোরতা দাবি করে যা অ্যারোস্পেস এবং মেডিকেল ডিভাইস ইঞ্জিনিয়াররা হার্ডওয়্যারের ক্ষেত্রে প্রয়োগ করেন। AMLAS সেই কঠোরতার জন্য একটি শব্দভাণ্ডার এবং ওয়ার্কফ্লো প্রদান করে। এটি আপনার জন্য স্বয়ংক্রিয়ভাবে বিশ্বাস অর্জন করে দেবে না, তবে এটি আপনাকে বিশ্বাস অর্জনের একটি পুনরাবৃত্তিযোগ্য উপায় দেবে। সততার সাথে নিরাপত্তা লক্ষ্য দিয়ে শুরু করুন। নোংরা এবং আসল ডেটার বিরুদ্ধে যাচাই করুন। সিস্টেমটি লাইভ হওয়ার পর একজন সংশয়বাদী হিসেবে এটি পর্যবেক্ষণ করুন। ফ্রেমওয়ার্কগুলো বিদ্যমান। বাকিটা হলো শৃঙ্খলা।
AMLAS নির্দেশিকার সম্পূর্ণ প্রযুক্তিগত বিশ্লেষণের জন্য, এখানে মূল বিবরণ পড়ুন: https://dev.to/paperium/guidance-on-the-assurance-of-machine-learning-in-autonomous-systems-amlas-f9
আপনি যদি অ্যাসুরেন্স কৌশল নিয়ে আলোচনা করতে চান এবং একই ধরণের সমস্যা নিয়ে কাজ করা একটি কমিউনিটির সাথে ব্যবহারিক নোট বিনিময় করতে চান, তবে এখানে যোগ দিন: https://t.me/GyaanSetuAi