গবেষকরা খুব কমই সফটওয়্যারের অভাব নিয়ে অভিযোগ করেন। বরং, তারা উল্টো সমস্যার সম্মুখীন হন: অনেক বেশি বিচ্ছিন্ন

গবেষকরা খুব কমই সফটওয়্যারের অভাব নিয়ে অভিযোগ করেন। বরং তারা এর উল্টো সমস্যার সম্মুখীন হন: shell scripts এবং আশার ওপর ভিত্তি করে জোড়া লাগানো অনেকগুলো বিচ্ছিন্ন টুল। OpenScience নামক একটি নতুন ওপেন-সোর্স প্রজেক্ট সেই অগোছালো ব্যবস্থার পরিবর্তে বৈজ্ঞানিক আবিষ্কারের জন্য বিশেষভাবে ডিজাইন করা একটি একক AI workbench তৈরি করতে চায়। TypeScript-এ তৈরি এই প্রজেক্টটি ইতিমধ্যে GitHub-এ ২,১৬৭টিরও বেশি স্টার অর্জন করেছে। এর লক্ষ্য হলো ল্যাবগুলোকে একটি অভিন্ন পরিবেশ প্রদান করা যেখানে কৃত্রিম বুদ্ধিমত্তা (AI) workflows স্বয়ংক্রিয় করতে, পরীক্ষামূলক ডেটা পরিচালনা করতে এবং সহযোগীদের কাজের মধ্যে সামঞ্জস্য বজায় রাখতে সাহায্য করবে। এর উচ্চাকাঙ্ক্ষা স্পষ্ট। তবে এটি ওপেন-সোর্স রক্ষণাবেক্ষণ এবং তীব্র প্রতিযোগিতার বাস্তবতায় টিকে থাকতে পারবে কি না, তা অন্য প্রশ্ন।

কেন গবেষণার নিজস্ব একটি Workbench প্রয়োজন

বৈজ্ঞানিক অগ্রগতি নির্ভর করে reproducibility-র ওপর। যদি অন্য কোনো দল একই বিশ্লেষণ চালাতে এবং একই সিদ্ধান্তে পৌঁছাতে না পারে, তবে একটি ফলাফলের কোনো মূল্য নেই। তবুও আধুনিক machine learning pipelines গুলো অত্যন্ত অগোছালো। Preprocessing ধাপগুলো ছড়িয়ে ছিটিয়ে থাকা Jupyter সেলগুলোর ভেতরে লুকিয়ে থাকে। Hyperparameters গুলো নথিবদ্ধহীন স্ক্রিপ্টে hard-coded করা থাকে। Datasets গুলো shared drives-এ কপি করা হয়, নাম পরিবর্তন করা হয় এবং হারিয়ে যায়। যখন একজন গ্র্যাজুয়েট শিক্ষার্থী চলে যান, তখন তাদের workflow প্রায়শই তাদের সাথেই চলে যায়।

OpenScience সরাসরি সেই বিশৃঙ্খলা দূর করার লক্ষ্য রাখে। লাইব্রেরির একটি বিচ্ছিন্ন সংগ্রহের পরিবর্তে একটি সমন্বিত প্ল্যাটফর্ম প্রদানের মাধ্যমে, এটি পরীক্ষাগুলো কীভাবে সেট আপ, ট্র্যাক এবং শেয়ার করা হবে তার মধ্যে ধারাবাহিকতা বজায় রাখতে চায়। এই প্রস্তাবের মূলে রয়েছে সহযোগিতা। কোড আদান-প্রদান করতে ইমেল করা বা version control-এর সাথে লড়াই করার পরিবর্তে, গবেষকরা একটি সাধারণ পরিবেশের মধ্যে কাজ করতে পারবেন যা রেকর্ড করবে কে, কী এবং কখন পরিবর্তন করেছে। যেসব ক্ষেত্রে একটি মাত্র পরীক্ষা সম্পন্ন করতে কয়েক সপ্তাহের computation প্রয়োজন, সেখানে এই ধরনের স্বচ্ছতা কোনো বিলাসিতা নয়; এটি একটি প্রয়োজনীয়তা।

বৈজ্ঞানিক কোডের জন্য TypeScript-এর ওপর বাজি ধরা

এটি TypeScript-এ তৈরি করার সিদ্ধান্তটি অপ্রত্যাশিত। Machine learning চলে Python-এ। এটাই বাস্তবতা। TensorFlow, PyTorch এবং গবেষণার অধিকাংশ codebase এতে লেখা। বিজ্ঞানীরা সাধারণত Python বা R-এ স্ক্রিপ্ট লেখেন, এবং অনেকে কেবল ওয়েব ভিজ্যুয়ালাইজেশন পরিবর্তনের জন্য সামান্য JavaScript জানেন। তাহলে কেন TypeScript?

ডেভেলপমেন্ট টিম যুক্তি দেয় যে static typing কোডকে সুসংগঠিত এবং নির্ভরযোগ্য রাখে। বৈজ্ঞানিক কাজে একটি মাত্র নীরব type error মাসের পর মাস করা ল্যাব ওয়ার্ককে বাতিল করে দিতে পারে। TypeScript দীর্ঘ সময় ধরে চলা training job-এর ভেতরে bug বিস্ফোরণ ঘটার পরিবর্তে compile time-এ পুরো ক্লাসের bug গুলো শনাক্ত করে ফেলে। যে প্ল্যাটফর্ম reproducibility নিশ্চিত করতে চায়, তার জন্য এই কঠোরতা অত্যন্ত আকর্ষণীয়।

এখানে কিছু বাস্তব trade-offs রয়েছে। TypeScript সেইসব ডেভেলপারদের আকর্ষণ করে যারা পেশাদার টুলের গুরুত্ব বোঝেন, কিন্তু এটি সেই গবেষকদের দূরে সরিয়ে দিতে পারে যাদের সেবা করার জন্য OpenScience কাজ করছে। একজন জীববিজ্ঞানী যিনি survey data ফরম্যাট করার জন্য প্রাথমিক JavaScript শিখেছিলেন, তাকে এখন interfaces, generics এবং একটি build pipeline-এর সাথে লড়াই করতে হবে। এর শেখার ধাপটি বেশ কঠিন। যদি প্ল্যাটফর্মটি প্রতিটি ব্যবহারকারীকে একটি model প্রশিক্ষণের আগে একজন software engineer হতে বাধ্য করে, তবে এর গ্রহণ করার হার কমে যাবে। এখানে বাজি ধরা হয়েছে যে, স্থিতিশীলতার দীর্ঘমেয়াদী সুবিধা অনবোর্ডিংয়ের স্বল্পমেয়াদী জটিলতার চেয়ে বেশি হবে।

OpenScience যা প্রতিশ্রুতি দেয়

প্রজেক্টটি বর্তমানে যে দুটি কাজে প্রচুর মানসিক শ্রম ব্যয় হয় সেগুলোকে সহজ করতে চায়: model training এবং experiment tracking। গবেষকদের অর্ধেক ডজন command-line utilities একসাথে যুক্ত করতে বলার পরিবর্তে, OpenScience একটি সুসংগত ইন্টারফেস প্রদানের পরিকল্পনা করছে। এটি এই ক্ষেত্রের প্রধান টুলগুলোর সাথে, বিশেষ করে TensorFlow এবং PyTorch-এর সাথে integrate করার পরিকল্পনা করছে, যাতে বিজ্ঞানীদের পরিচিত লাইব্রেরিগুলো ত্যাগ করতে না হয়।

AI নিজেই কিছু কঠিন কাজ সম্পন্ন করবে বলে আশা করা হচ্ছে। Workbench-টির লক্ষ্য হলো পুনরাবৃত্তিমূলক workflows গুলো স্বয়ংক্রিয় করা। স্বয়ংক্রিয়ভাবে তৈরি data cleaning pipelines, পূর্ববর্তী রানের ওপর ভিত্তি করে hyperparameters-এর বুদ্ধিমান পরামর্শ, অথবা স্বয়ংক্রিয় logging যা রেকর্ড করবে ডেটাসেটের ঠিক কোন সংস্করণটি একটি নির্দিষ্ট ফলাফল তৈরি করেছে—এসবের কথা ভাবুন। যদি এই স্বপ্ন বাস্তবে রূপ নেয়, তবে এটি গবেষকদের অবকাঠামোর পরিবর্তে hypotheses-এর ওপর মনোযোগ দিতে সাহায্য করবে।

Integration Bloat-এর ঝুঁকি

প্রতিটি পরিকল্পিত integration একটি প্রতিশ্রুতি যা রক্ষণাবেক্ষণের প্রয়োজন হয়। TensorFlow এবং PyTorch ঘন ঘন আপডেট প্রকাশ করে। একটি core dependency-র একটি মাত্র পরিবর্তন OpenScience-এর abstraction layers-গুলোর মাধ্যমে ছড়িয়ে পড়তে পারে এবং ব্যবহারকারীদের পরীক্ষা চালানোর পরিবর্তে cryptic stack traces দেখতে বাধ্য করতে পারে। আরও বেশি লাইব্রেরি মানে আরও বেশি security patches, আরও বেশি version conflicts এবং প্ল্যাটফর্মটি যে টুলগুলোর সেবা করার কথা তার সাথে তাল মিলিয়ে না চলার আরও বেশি সুযোগ।

সেটআপের জটিলতা হলো গবেষণামূলক সফটওয়্যারের নীরব ঘাতক। যদি OpenScience ইনস্টল করার জন্য CUDA ড্রাইভার, নির্দিষ্ট Node.js ভার্সন এবং পরস্পরবিরোধী Python এনভায়রনমেন্ট নিয়ে লড়াই করতে হয়, তবে ব্যস্ত গবেষকরা সরাসরি একটি Google Colab ট্যাব খুলে ফেলবেন যেখানে রানটাইম আগে থেকেই কনফিগার করা থাকে। গবেষণা হয় অত্যন্ত সীমিত সময়ের মধ্যে। কোনো টুলচেইন ডিবাগ করতে তিন সপ্তাহ ব্যয় করে কেউ গবেষণা প্রকাশ করতে পারে না।

ডেভেলপাররা এই দ্বন্দ্ব সম্পর্কে সচেতন বলে মনে হয়। তাদের চ্যালেঞ্জ হলো এমন পর্যাপ্ত কার্যকারিতা প্রদান করা যা কার্যকর হবে, আবার এটি এত বেশি ভারী বা জটিলও হবে না যে টুলটি নিজেই অচল হয়ে পড়ে।

ওপেন সোর্সের স্থায়িত্ব

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

বৈজ্ঞানিক ওপেন-সোর্স টুলগুলো ভিন্ন এক বাস্তবতার সম্মুখীন হয়। সেই ২,১৬৭টি GitHub স্টার আশাব্যঞ্জক মনে হতে পারে, কিন্তু স্টার রক্ষণাবেক্ষণকারীদের অর্থায়ন করে না। অনুদানের চক্র শেষ হয়ে যায়। গবেষকরা অন্য কাজে চলে যান। কোনো স্থিতিশীল প্রাতিষ্ঠানিক সমর্থন বা নিবেদিত মূল দল না থাকলে এমনকি মেধাবী প্রজেক্টগুলোও স্থবির হয়ে পড়ে। রিপোজিটরিটি এক বছর অলস পড়ে থাকে, ডিপেন্ডেন্সিগুলো অকেজো হয়ে যায় এবং প্রাথমিক ব্যবহারকারীরা এমন পরিত্যক্ত কোড নিয়ে পড়ে থাকেন যা আধুনিক হার্ডওয়্যারের সাথে আর কাজ করে না। যে প্ল্যাটফর্মটি পুনরুৎপাদনযোগ্য বিজ্ঞান হোস্ট করতে চায়, তার জন্য অস্তিত্বহীন হওয়ার চেয়ে পরিত্যক্ত হওয়া অনেক বেশি খারাপ। OpenScience যদি শিরোনামের বাইরে টিকে থাকতে চায়, তবে বিশ্ববিদ্যালয়, ল্যাব বা অর্থায়নকারী সংস্থাগুলোর কাছ থেকে দীর্ঘমেয়াদী সমর্থন প্রয়োজন।

Jupyter, Colab এবং MATLAB-এর সাথে প্রতিযোগিতা

OpenScience একটি অত্যন্ত প্রতিযোগিতামূলক ক্ষেত্রে প্রবেশ করছে। পাইথনে অনুসন্ধানমূলক গবেষণার জন্য Jupyter Notebooks হলো ডিফল্ট মাধ্যম। Google Colab ব্রাউজার ট্যাবের ভেতরে বিনামূল্যে GPU প্রদানের মাধ্যমে হার্ডওয়্যারের বাধা দূর করেছে। MATLAB এখনও সেই সব ইঞ্জিনিয়ারিং বিভাগগুলোতে আধিপত্য বিস্তার করে আছে যারা এর ওয়ারেন্টিযুক্ত টুলবক্স এবং কয়েক দশকের প্রাতিষ্ঠানিক জ্ঞানকে গুরুত্ব দেয়।

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

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

আসল পরীক্ষা: কোডের চেয়ে শাসন কাঠামো বেশি গুরুত্বপূর্ণ

ক্লিন TypeScript এবং একটি উচ্চাভিলাষী ফিচার তালিকা প্রজেক্টটিকে খুব বেশিদূর নিয়ে যেতে পারবে না। বৈজ্ঞানিক সফটওয়্যারের ইতিহাস এমন অনেক সুন্দর কোডবেস দিয়ে ভরা যা ব্যর্থ হয়েছে কারণ সেগুলো ডেভেলপারদের দ্বারা ডেভেলপারদের জন্যই তৈরি করা হয়েছিল। একজন ল্যাবরেটরি বিজ্ঞানীর চটকদার ইউজার ইন্টারফেসের প্রয়োজন নেই যদি CSV ইম্পোর্টার বাস্তব জগতের ডেটার ক্ষেত্রে ক্র্যাশ করে। তাদের এমন টুল প্রয়োজন যা গবেষণার প্রকৃত কঠিন বাস্তবতাকে সম্মান করে: ফিল্ড স্টেশনে অনিয়মিত ইন্টারনেট, পুরানো যন্ত্রপাতির অগোছালো ফাইল ফরম্যাট এবং একজন সন্দিহান রিভিউয়ারের কাছে ঠিক কোন কোডটি কোন চিত্র তৈরি করেছে তা প্রমাণ করার নিরঙ্কুশ প্রয়োজনীয়তা।

সাফল্য নির্ভর করে কমিউনিটি শাসনের ওপর। কী তৈরি করা হবে তা নির্ধারণ করার ক্ষেত্রে প্রিন্সিপাল ইনভেস্টিগেটর, ল্যাব ম্যানেজার এবং স্নাতক শিক্ষার্থীদের প্রকৃত মতামত বা কণ্ঠস্বর থাকা প্রয়োজন। OpenScience-কে বিজ্ঞানীদের সেখানে গিয়ে সাহায্য করতে হবে যেখানে তারা বর্তমানে আছেন, যেখানে ডেভেলপাররা মনে করেন তাদের থাকা উচিত সেখানে নয়।

মূল কথা

OpenScience সত্যিই একটি আকর্ষণীয় পরীক্ষা। এটি বৈজ্ঞানিক আবিষ্কারের অগোছালো ও পুনরাবৃত্তিমূলক জগতে টাইপড সফটওয়্যার ইঞ্জিনিয়ারিংয়ের কঠোরতা প্রয়োগ করে। দ্রুত পাইথন স্ক্রিপ্টের আধিপত্য থাকা এই ক্ষেত্রে এই সমন্বয়টি বিরল। কিন্তু প্রযুক্তিগত পছন্দগুলো ঝুঁকি বহন করে, প্রতিযোগিতা তীব্র এবং GitHub স্টার থেকে টেকসই অবকাঠামো পর্যন্ত পথটি অত্যন্ত কঠিন। কোডটি উন্মুক্ত। স্টারগুলো জমা হচ্ছে। আসল চ্যালেঞ্জ এখন হলো তৈরি করা...