OpenAI-তে ডিপ্লয়মেন্ট ইঞ্জিনিয়ারের ভূমিকা কী

Codex আসার পর দলের একজন আমাকে জিজ্ঞেস করলেন, “যেসব কাজের সমাধান তৈরি করতে আমাদের গত কয়েক মাস লেগেছে, Codex যদি এক চেষ্টাতেই সেগুলো করে দিতে পারে, তাহলে আমরা কী করব?”

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

এটাই অগ্রগতি. প্রতি দু-এক মাস পরপর যদি নিজেদের আর প্রয়োজন না থাকার পরিস্থিতি তৈরি করতে পারি, তাহলে বুঝতে হবে আমাদের ডিপ্লয়মেন্ট ইঞ্জিনিয়ার দল তার কাজ ঠিকমতো করছে.

আমরা যাকে “প্রয়োগের ব্যবধান” বলি, তা দূর করতে আমি ২০২৫ সালের শুরুর দিকে দলটি গড়ে তুলি. এটি হলো মডেলকে যা করতে সক্ষম বলে মনে হয় এবং মানুষ নিজের কাজে নির্ভরযোগ্যভাবে যা ব্যবহার করতে পারে, তার মধ্যকার দূরত্ব.

মডেলগুলোকে কাজে লাগানোর জন্য প্রয়োজনীয় ব্যবস্থা ও প্রক্রিয়ার তুলনায় মডেলের সক্ষমতা দ্রুত এগিয়েছে. কখনো ঘাটতি থাকে একটি পণ্যের. কখনো কোনো মডেল মানদণ্ডভিত্তিক পরীক্ষায় ভালো করলেও বাস্তব জীবনের পরিবর্তনশীল পরিস্থিতি ও সীমাবদ্ধতার মধ্যে কাজটি করতে পারে না.

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

তবে সমস্যাগুলো প্রায়ই অনির্দিষ্ট থাকে, সঠিক উত্তর যাচাইয়ের প্রতিষ্ঠিত ভিত্তি না-ও থাকতে পারে, আর অনুসরণের মতো প্রস্তুত কোনো পদ্ধতিও থাকে না. সবাই এমন কিছু তৈরি করতে চায়, যা আগে কখনো ছিল না. কিন্তু সেখানে পৌঁছাতে যা করা দরকার, তা করতে আগ্রহী মানুষ কম.

প্রতিভাবান ডিপ্লয়মেন্ট ইঞ্জিনিয়ার খুঁজে পাওয়ার পাশাপাশি “যথেষ্ট ভালো”-র ন্যূনতম মান বাড়াতে আমাদের নিরন্তর পরীক্ষা-নিরীক্ষা ও বাস্তব প্রয়োগ করতে হয়েছে.

ডিপ্লয়মেন্ট ইঞ্জিনিয়ার দলের প্রতিটি বৈঠকের শুরুতে আমি একটি মূল মূল্যবোধ লেখা স্লাইড দেখাই: “কাঙ্ক্ষিত ফলাফলকে সামনে রেখে শুরু করুন, সফল হতে যা দরকার তা-ই করুন, তারপর পরিসর বাড়ান”.

একটি চমকপ্রদ প্রদর্শনী অনেক দূর এগিয়ে যেতে পারে, কেউ বাস্তবে সেটি কাজ করে কি না প্রশ্ন তোলার আগেই.

আমাদের কাজ হলো গ্রাহকের সমস্যার এমন মানের সমাধান করা, বাস্তবে চালু হলে যার দায় আমরা নিতে পারি.

আমাদের ডিপ্লয়মেন্ট ইঞ্জিনিয়ারদের প্রথম দিনেই সংশ্লিষ্ট খাত সম্পর্কে জানতে হয় না, তবে তা শিখে নেওয়া তাদের দায়িত্ব.

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

সঠিক বিচার-বিবেচনার জন্য যথেষ্ট জ্ঞান দরকার, আর দরকার প্রচলিত ব্যবস্থা নিয়ে ধরে নেওয়া ধারণাগুলোকে প্রশ্ন করার মতো কৌতূহল.

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

আমরা দেখিয়েছিলাম যে এসব কাজের ধারা সুফল দিতে পারে. কিন্তু প্রতিটিকে অন্য দলে সম্প্রসারণ করতে তখনও অনেক বেশি আলাদা সমন্বয়ের কাজ করতে হতো. পরবর্তী চ্যালেঞ্জ ছিল সেই ফলাফল ধরে রেখে সফটওয়্যার চালু করা ও রক্ষণাবেক্ষণ সহজ করা.

তত দিনে Codex-এর সক্ষমতা বেড়েছিল. একজন ডিপ্লয়মেন্ট ইঞ্জিনিয়ার পরীক্ষামূলকভাবে Codex-কে কেন্দ্র করে তাদের অ্যাপ্লিকেশন নতুন করে তৈরি করেন. এরপর দলের সঙ্গে মিলে প্রয়োগক্ষেত্রগুলোকে একটি অভিন্ন কার্যপরিধিতে নিয়ে যান, যার কেন্দ্রে ছিল Codex.

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

আমরা প্রতিটি প্রকল্প থেকে বিশেষভাবে লেখা কোডের প্রায় ৯০% সরিয়ে ফেলতে পেরেছি. এতে এসব কাজের ধারা তৈরি, রক্ষণাবেক্ষণ ও সম্প্রসারণের ধরন বদলে গেছে:

• Codex-এ কেন্দ্রীয়ভাবে করা উন্নয়নের সুবিধা আমরা পেতাম, ফলে প্রতিটি পৃথক প্রয়োগক্ষেত্রে বিভিন্ন অংশ জোড়ার জন্য কম কোড দরকার হতো

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

• ২০২৬ সালের আগস্টের একটি উদাহরণে, প্রথমবার ব্যবস্থা চালু করতে দুই মাস লেগেছিল. দ্বিতীয় দলে সমাধানটি সম্প্রসারণ করতে লেগেছিল এক দিন. পরিসর বাড়ার সঙ্গে পরবর্তী দলগুলো আরও দ্রুত যুক্ত হয়েছে. এই ধারা অব্যাহত থেকেছে: ২০২৬ সালের আগস্টে একটি প্রয়োগক্ষেত্রে প্রথমবার ব্যবস্থা চালু করতে ২ মাস লাগলেও দ্বিতীয় দলে চালু করতে লেগেছিল ১ দিন.

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

এ কারণেই কাজের ক্রম গুরুত্বপূর্ণ. LLM দিয়ে আমরা দ্রুত তৈরি করতে পারি. সেই গতি কাজে লাগিয়ে ব্যবহারকারীদের হাতে কার্যকর কিছু তুলে দিন, বাস্তবে কোনটি টিকে থাকে তা শিখুন, তারপর যা কাজ করে তার পরিসর বাড়ান.

গ্রাহকদের সঙ্গে সব কাজেই একই নীতি প্রযোজ্য.

কখনো আরও ভালো পণ্যের সাহায্যে আমাদের তৈরি ব্যবস্থা সহজ করা যায়, আবার কখনো মডেল নিজেই তখনও কাজটি করতে পারে না.

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

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

নিজেদের আর প্রয়োজন না থাকার পরিস্থিতি তৈরির এটি আরেকটি উপায়: আজকের মডেল যে সমস্যা সমাধান করতে পারে না, ভবিষ্যতের মডেল যেন তা পারে, সেই সক্ষমতা গড়ে তুলতে সাহায্য করা. আমাদের কাজের সুফল কোনো এক গ্রাহকের সঙ্গে কাটানো সময়ের মধ্যেই সীমাবদ্ধ থাকে না.

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

লক্ষ্য হলো, প্রতিটি কাজ যেন পরবর্তী কাজকে আরও ভালো করে তোলে: এমন পণ্য যা চালু করা সহজ, এমন মডেল যা আরও কঠিন কাজ সামলাতে পারে, অথবা পরবর্তী গ্রাহকের জন্য আলাদাভাবে কম কাজ করার প্রয়োজন.

আপনি যদি কোনো কঠিন সমস্যার সমাধান করতে চান, আমরা আপনার সঙ্গে কাজ করতে আগ্রহী. আর এসব সমস্যা সমাধানে সাহায্য করতে চাইলে, আমাদের দলে আপনাকে স্বাগত.

তাহলে যে কাজের ব্যবস্থা তৈরি করতে আমাদের মাসের পর মাস লেগেছে, Codex যখন সেটি সামলাতে পারে, তখন আমরা কী করি?

আরও কঠিন সমস্যা খুঁজে নিই.