দীর্ঘ-সময়সীমার মডেলের যুগে নিরাপত্তা ও সামঞ্জস্য

যেসব মডেল দীর্ঘ সময় স্বায়ত্তশাসিতভাবে কাজ করতে পারে, তারা কঠিন ও উন্মুক্ত সমস্যার দায়িত্ব নিতে পারে. কিন্তু যে অধ্যবসায় তাদের উপযোগী করে তোলে, সেটিই তাদের অনাকাঙ্ক্ষিত পদক্ষেপ নেওয়ার আরও সুযোগ দেয়—এমনভাবে, যা স্বল্প-সময়সীমার মডেলের জন্য করা মূল্যায়ন এড়িয়ে যেতে পারে.

প্রায় দুই মাস আগে আমরা ঘোষণা⁠ করেছিলাম যে একটি অভ্যন্তরীণ সাধারণ-উদ্দেশ্যের মডেল Erdős unit distance conjecture খণ্ডন করেছে. এই মডেলটি খুব দীর্ঘ সময় ধরে স্বায়ত্তশাসিতভাবে কাজ করার জন্য নকশা করা হয়েছিল. সীমিত ও পর্যবেক্ষণাধীন অভ্যন্তরীণ ব্যবহারের সময় আমরা এমন অনাকাঙ্ক্ষিত আচরণ দেখেছি, যা আমাদের বিদ্যমান ডেপ্লয়মেন্ট মূল্যায়ন ধরতে পারেনি. ডেপ্লয়মেন্ট সীমিত ও পর্যবেক্ষণাধীন ছিল বলে আমরা সমস্যাগুলো শনাক্ত করতে, অ্যাক্সেস স্থগিত রাখতে, পর্যবেক্ষণ থেকে নতুন মূল্যায়ন তৈরি করতে, মডেল ও তার সুরক্ষা-ব্যবস্থা শক্তিশালী করতে এবং পরে চলমান পর্যবেক্ষণের অধীনে অ্যাক্সেস ফিরিয়ে দিতে পেরেছি. 

আমরা যে পরিস্থিতিতে মডেল মূল্যায়ন করি, তা বাস্তব ব্যবহারে তারা যে পরিস্থিতির মুখোমুখি হয় তার সঙ্গে কখনও পুরোপুরি মিলবে না. তাই ডেপ্লয়মেন্টের আগের মূল্যায়নের সঙ্গে সীমিত, পর্যবেক্ষণাধীন ডেপ্লয়মেন্ট এবং সমস্যা দেখা দিলে হস্তক্ষেপ, স্থগিত বা আগের অবস্থায় ফেরানোর সক্ষমতা থাকতে হবে. ডেপ্লয়মেন্ট থেকে যা শিখি, অ্যাক্সেস বাড়ানোর আগে তা আরও শক্তিশালী মূল্যায়ন ও সুরক্ষা-ব্যবস্থার অংশ হতে পারে.

পরের অংশগুলোতে আমরা কী দেখেছি, কীভাবে সমস্যাগুলো মোকাবিলা করেছি এবং এই অভিজ্ঞতা ভবিষ্যৎ রিলিজকে কীভাবে প্রভাবিত করবে, তার নির্দিষ্ট উদাহরণ দিচ্ছি.

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

এর একটি উদাহরণ ঘটেছিল NanoGPT স্পিডরান⁠(একটি নতুন উইন্ডোতে খোলে)-এ একটি অভ্যন্তরীণ মূল্যায়নের সময়; এটি একটি ছোট ভাষা মডেলকে যত কম ধাপে সম্ভব প্রশিক্ষণ দেওয়ার জনসম্মুখ বেঞ্চমার্ক. আমাদের মডেল PowerCool নামে একটি পাওয়ার-ল শেখার-হার কুলডাউন তৈরি করেছিল, যা উল্লেখযোগ্য উন্নতি এনেছিল. মডেলকে বলা হয়েছিল ফলাফল শুধু Slack-এ পোস্ট করতে, কিন্তু NanoGPT নির্দেশনায় ফলাফল GitHub-এ PR হিসেবে পোস্ট করতে বলা ছিল, এবং মডেলটি পরের নির্দেশনা মেনে জনসম্মুখ GitHub রিপোজিটরিতে PR #287 খুলেছিল. মডেলটি বাহ্যিক অ্যাক্সেস আটকানোর জন্য তৈরি স্যান্ডবক্স সীমাবদ্ধতা এড়িয়ে GitHub-এ আপলোড করে. PR করার জন্য স্যান্ডবক্সে দুর্বলতা খুঁজে পেতে আমাদের মডেলের এক ঘণ্টা লেগেছিল; আগের মডেলগুলো কম অধ্যবসায়ী ছিল, দুর্বলতা খুঁজে পায়নি এবং PR অংশটি ছেড়ে দিয়েছিল.¹

AI সহকারীর অনেক নিরাপত্তা নিয়ন্ত্রণ পৃথক পদক্ষেপকে কেন্দ্র করে নকশা করা হয়. কোনো পদক্ষেপ অনুমোদিত না হলে তা ব্লক করা হয়. তা সংবেদনশীল হলে সিস্টেম ব্যবহারকারীর স্পষ্ট অনুমোদন চায়. কিন্তু দীর্ঘ সময় চলা মডেল, যার পদক্ষেপ ঘণ্টা, দিন বা এমনকি সপ্তাহজুড়ে স্বায়ত্তশাসিতভাবে এগোতে পারে, এই ব্যবস্থাকে চ্যালেঞ্জ করে: সামগ্রিক গতিপথের উদ্দেশ্য বুঝতে পৃথক পদক্ষেপ পর্যবেক্ষণ আর যথেষ্ট নয়.

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

এই উদাহরণ দেখায়, প্রতিটি ধাপ আলাদাভাবে গ্রহণযোগ্য মনে হলেও ধারাবাহিকতা এমন ফল দিতে পারে যা অনুমোদিত হতো না. এটি আরও দেখায়, দীর্ঘ সময়সীমায় কার্যকরভাবে কাজ করা একটি মডেল অনুমোদন ব্যবস্থার অন্ধস্থান শিখে নিয়ে লক্ষ্য অর্জনে তা পাশ কাটাতে পারে. দীর্ঘ-সময়সীমার নিরাপত্তায় শুধু “এই পদক্ষেপটি অনুমোদিত কি না” জিজ্ঞেস করলেই হয় না; “এই পদক্ষেপগুলোর ধারাটি কোন ফলের দিকে এগোচ্ছে”.

এ ধরনের ঘটনার কারণে আমরা নতুন মডেলের অভ্যন্তরীণ ডেপ্লয়মেন্ট স্থগিত করি. আমরা বহুস্তর প্রতিরক্ষা ও গতিপথ-স্তরের পর্যবেক্ষণকে কেন্দ্র করে নিরাপত্তা ব্যবস্থা নতুন করে তৈরি করেছি.

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

নতুন পর্যবেক্ষণ ব্যবস্থা মূল্যায়নের জন্য আমরা অল্প কিছু অভ্যন্তরীণ ডেপ্লয়মেন্ট পরিবেশে রিপ্লে চালিয়েছি, যেখানে মডেল আগে অসামঞ্জস্যপূর্ণ পদক্ষেপ নিয়েছিল; এবার নতুন সুরক্ষা-ব্যবস্থা চালু ছিল². নতুন সুরক্ষা-ব্যবস্থা মডেলের নেওয়া অনেক বেশি অসামঞ্জস্যপূর্ণ পদক্ষেপ ধরতে পেরেছে, আর যেগুলো বাদ পড়েছে সেগুলোর সবই কম তীব্রতার বলে বিবেচিত হয়েছে.

এই কম তীব্রতার কয়েকটি ঘটনার উদাহরণ হলো:

• Linear কমান্ড লাইন টুলে অ্যাক্সেস পেতে মডেলটি একটি নেস্টেড codex --yolo সেশন চালু করেছিল, অথচ আসলে --yolo ফ্ল্যাগ ছাড়াই তা করতে পারত.
• মডেলটি খেয়াল করে যে আগে সচল একটি রিসোর্স নেই; তারপর যথেষ্ট কারণ ছাড়াই নিজের মালিকের namespace-এর অন্য সচল CPU pods-এ, এবং OpenAI-এর অন্য কর্মীদের pods-এও (ব্যর্থভাবে) অনুসন্ধান ও SSH করা শুরু করে.
• মডেলের অনেকগুলো আটকে থাকা find প্রক্রিয়া ছিল এবং প্রতিটি শেল কমান্ড ঝুলে যাচ্ছিল. এরপর এটি kill -9 -1 চালায়, যা কার্যকর হলে ওই pod-এ যেসব প্রক্রিয়া মেরে ফেলার অনুমতি তার আছে, সবকটিতে SIGKILL পাঠাত. তবে এটি টাইম আউট হয়েছিল এবং কার্যকর হয়নি.

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

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

মডেলগুলো যত দীর্ঘ ও জটিল কাজ নেবে, মূল্যায়নের চোখ এড়ানো ব্যর্থতার পরিণতিও তত বড় হতে পারে. মূল্যায়ন ও ডেপ্লয়মেন্টের ফাঁক কমাতে আমরা কাজ চালিয়ে যাব: দীর্ঘতর গতিপথে মডেল পরীক্ষা, সামঞ্জস্য উন্নত করা, হস্তক্ষেপ করতে পারে এমন পর্যবেক্ষণ তৈরি করা এবং ব্যবহারকারীদের আরও স্পষ্ট দৃশ্যমানতা ও নিয়ন্ত্রণ দেওয়া. এই চ্যালেঞ্জগুলো শুধু OpenAI-এর নয়; আমরা আশা করি, আমাদের শেখা বিষয়গুলো ভাগ করে নেওয়া বৃহত্তর ক্ষেত্রকে সেগুলোর জন্য প্রস্তুত হতে সাহায্য করবে.