লুপ ইঞ্জিনিয়ারিং এখন বেশ আলোচনার কেন্দ্রে রয়েছে। যেকোনো টেকনিক্যাল ফোরাম স্ক্রল করলেই আপনি এমন কণ্ঠস্বর পাবেন যারা যুক্তি দিচ্ছেন যে, আমাদের এআই এজেন্টদের চতুর প্রম্পট দিয়ে প্রশিক্ষণ দেওয়া চ্যাটবট হিসেবে দেখা বন্ধ করা উচিত। পরিবর্তে, তারা বলছেন, আমাদের লুপ ডিজাইন করা উচিত: এমন স্বয়ংক্রিয় চক্র যা একজন এজেন্টকে পরিকল্পনা করতে, সম্পাদন করতে, নিজের কাজ যাচাই করতে এবং আমরা ঘুমিয়ে থাকলেও পুনরাবৃত্তি (iterate) করতে সাহায্য করবে। এই প্রস্তাবটি বেশ আকর্ষণীয়। যদি লুপটি সঠিকভাবে তৈরি করা হয়, তবে এজেন্টটি ক্রমাগত মানুষের তত্ত্বাবধান ছাড়াই সঠিক পথে থাকে এবং রাতারাতি একটি কাঁচা উদ্দেশ্যকে চূড়ান্ত আউটপুটে রূপান্তর করে।
এই প্রতিশ্রুতিটি তাত্ত্বিকভাবে চমৎকারভাবে কাজ করে। বাস্তবে, বেশিরভাগ এজেন্ট ইতিমধ্যেই লুপ ব্যবহার করে। তারা কোড তৈরি করে, কম্পাইলার এরর বা টেস্ট ফেইলিউর পরীক্ষা করে, কোড প্যাচ করে এবং পুনরায় স্যুটটি চালায়। এই মৌলিক ফিডব্যাক চক্রটি নতুন কিছু নয়। যা নিয়ে এখন প্রবক্তারা দাবি করছেন তা আরও উচ্চাভিলাষী: একটি আউটলুপ যা শুধুমাত্র সিনট্যাক্স এরর নয়, বরং পুরো কাজটিকে নিয়ন্ত্রণ করবে। সেই আউটলুপ তৈরি করাই হলো আসল কঠিন কাজ, কারণ সফটওয়্যার ইঞ্জিনিয়ারিং খুব কমই নির্দিষ্ট নিয়মে চলা একটি বদ্ধ সিস্টেম (closed system)।
লুপ ডিজাইনের সমস্যা
প্রোডাক্টের লক্ষ্যগুলো প্রায়ই অগোছালো হয়। আপনি খুব কমই কাজ শেষ হওয়ার একটি নিখুঁত সংজ্ঞা (definition of done) দিয়ে শুরু করেন। বরং, অনেক ক্ষেত্রে দেখা যায় যে আপনি যখন কাজের গভীরে ডুবে আছেন, তখনই আসল লক্ষ্যটি বুঝতে পারছেন। হোয়াইটবোর্ডে যা সহজ মনে হয়েছিল, একটি রিকোয়ারমেন্ট বাস্তবে এমন সব এজ কেস (edge cases) তৈরি করতে পারে যা সমাধানের ধরনটি সম্পূর্ণ বদলে দেয়। যখন আপনি একটি এজেন্টের চারপাশে একটি অনমনীয় লুপ তৈরি করেন, তখন সেই অনমনীয়তা একটি বোঝা হয়ে দাঁড়ায়। লুপটি ক্রমাগত এমন একটি লক্ষ্যের দিকে আঘাত করতে থাকে যা হয়তো ভুল। আরও খারাপ বিষয় হলো, একটি নমনীয় লুপ কখনও কখনও লক্ষ্যটি পরিবর্তন করে দিয়ে ডেডলক সমাধান করার চেষ্টা করে যাতে এটি যে আউটপুটটি তৈরি করেছে তার সাথে মিলে যায়। কোনো ফলাফলই এখানে কার্যকর নয়। একটি কম্পিউটেশনাল শক্তি অপচয় করে; অন্যটি আত্মবিশ্বাসের সাথে আবর্জনা (garbage) ডেলিভারি করে।
আরও গভীর সমস্যাটি হলো স্পেসিফিকেশন খরচ (specification cost)। আপনি যদি চান একটি লুপ কোনো তত্ত্বাবধান ছাড়াই চলুক, তবে আপনাকে এমন একটি স্পেক (spec) লিখতে হবে যা প্রায় সবকিছুই আগে থেকে অনুমান করতে পারে। এজেন্ট ঠিক কী পরিবর্তন করবে? কোন বিদ্যমান আচরণটি অপরিবর্তিত রাখা আবশ্যক? কোন সুনির্দিষ্ট শর্তে এজেন্টের পুনরাবৃত্তি (iteration) বন্ধ করা উচিত? কোন ঝুঁকিগুলো গ্রহণযোগ্য, এবং কোন পার্শ্বপ্রতিক্রিয়াগুলো দেখা দিলে অবিলম্বে কাজ থামিয়ে দেওয়া উচিত? এই ডকুমেন্টটি লিখতে হয়তো এজেন্টের সাথে বসে রিয়েল-টাইমে কাজ পরিচালনা করার চেয়েও বেশি সময় লেগে যেতে পারে। আপনি অটোমেশনের বিনিময়ে একটি বড় ধরনের অগ্রিম খরচ দিচ্ছেন, যা কেবল তখনই লাভজনক হবে যদি যাচাইকরণ (verification) প্রক্রিয়াটি কাজ করার চেয়ে অনেক বেশি সাশ্রয়ী হয়।
যেখানে লুপগুলো প্রকৃতপক্ষে কার্যকর হয়
এর মানে এই নয় যে লুপ ইঞ্জিনিয়ারিং নিরর্থক। এর মানে হলো এটি একটি বিশেষায়িত টুল, কোনো সর্বজনীন কৌশল নয়। লুপগুলো তখনই সবচেয়ে ভালো কাজ করে যখন যাচাইকরণের খরচ বাড়তে থাকে এবং সাফল্যের মানদণ্ড অস্পষ্ট থাকে না। এমন তিনটি ক্ষেত্র রয়েছে যেখানে এটি সত্য প্রমাণিত হয়।
রুটিনমাফিক যান্ত্রিক কাজ। সেই কাজগুলোর কথা ভাবুন যা সিনিয়র ইঞ্জিনিয়ারদের অবসরে যেতে প্ররোচিত করে: একটি নির্দিষ্ট ক্রমে অ্যাপ্লিকেশন শুরু করা, প্রতিটি ধাপ নিশ্চিত করতে একটি ডেপ্লয়মেন্ট ইউআই-তে ক্লিক করা, রিলিজের পর পরিচিত এরর স্ট্রিং খোঁজার জন্য লগ গ্রিপ (grepping logs) করা, অথবা একটি কনফিগারেশন ফাইল সব সঠিক নোডে লেখা হয়েছে কিনা তা যাচাই করা। এই ধাপগুলো মানুষের জন্য বিরক্তিকর কিন্তু যাচাই করা খুবই সহজ। একটি লুপ এই পুরো প্রক্রিয়াটি তদারকি করতে পারে, প্রতিটি রিস্টার্টের পর হেলথ এন্ডপয়েন্ট পরীক্ষা করতে পারে এবং সামান্যতম সমস্যা দেখলেই রোলব্যাক করতে পারে। মানুষটি তখনও রোলারউট প্ল্যানটি নির্ধারণ করে দেয়। লুপটি কেবল রাত দুটোর সময় একটি মেশিনের ধৈর্যের সাথে সেটি কার্যকর করে।
পরিমাপযোগ্য অপ্টিমাইজেশন লক্ষ্য। যখন সাফল্য একটি সংখ্যায় প্রকাশ করা যায়, তখন লুপগুলো অবিশ্বাস্যভাবে কার্যকর হয়। p99 ল্যাটেন্সি ১৫০ মিলিসেকেন্ডের নিচে নামিয়ে আনা। মেমরি ফুটপ্রিন্ট বিশ শতাংশ কমানো। একটি হট পাথ পাইথন থেকে রাস্টে (Rust) মাইগ্রেট করা এবং নিশ্চিত করা যে সমস্ত বিদ্যমান ইউনিট টেস্ট এখনও পাস করছে। লুপটি একটি পরিবর্তন তৈরি করতে পারে, সেটি বেঞ্চমার্ক করতে পারে, যে সংস্করণটি ফলাফল পরিবর্তন করেছে সেটি রেখে দিতে পারে এবং বাকিগুলো বাদ দিতে পারে। যেহেতু যাচাইকরণ স্বয়ংক্রিয় এবং সার্চ স্পেস অনেক বড়, তাই ম্যানুয়াল রিভিউয়ের ক্রমবর্ধমান খরচ লুপ ছাড়া এই কাজটিকে অবাস্তব করে তুলত। লক্ষ্যটি স্থির। পথটি অজানা। এটাই হলো লুপের সেরা ব্যবহারের ক্ষেত্র।
অপারেশনাল প্লেবুক। ইনসিডেন্ট রেসপন্স এবং সাপোর্ট টিকিটগুলো প্রায়ই এমন প্যাটার্ন অনুসরণ করে যা মানুষ ইতিমধ্যে সমাধান করে ফেলেছে। প্রোডাকশন এররের একটি নির্দিষ্ট ধরন সবসময় একটি ক্রেডেনশিয়াল রোটেশন এবং ক্যাশ ক্লিয়ার করার প্রয়োজন হয়। একটি নির্দিষ্ট ক্যাটাগরির সাপোর্ট রিকোয়েস্ট তিনটি নির্দিষ্ট শর্ত পূরণ করলে রিফান্ড দিয়ে সমাধান করা যেতে পারে। একটি লুপ সেই ট্রিগারগুলোর জন্য অপেক্ষা করতে পারে এবং প্লেবুকটি কার্যকর করতে পারে, এবং প্যাটার্নটি ভেঙে পড়লে তবেই বিষয়টি উচ্চতর স্তরে পাঠাতে পারে (escalating)। এটি সিদ্ধান্ত নেয় না যে প্লেবুকটি সঠিক কি না; এটি কেবল এমন স্কেল এবং গতিতে ধারাবাহিকতা বজায় রাখে যা অন-কল ইঞ্জিনিয়ারদের পক্ষে সম্ভব নয়।
রেগুলেটর, রেফারেন্স-সেটার নয়
বর্তমান আলোচনার একটি বড় অংশ থেকে একটি গুরুত্বপূর্ণ পার্থক্য বাদ পড়ে যাচ্ছে। লুপ (Loops) হলো নিয়ন্ত্রক। এগুলো একটি সিস্টেমকে পূর্বনির্ধারিত লক্ষ্যের সাথে সামঞ্জস্যপূর্ণ রাখে, ঠিক যেমন একটি থার্মোস্ট্যাট একটি রুমের তাপমাত্রা বাহাত্তর ডিগ্রিতে বজায় রাখে। কিন্তু থার্মোস্ট্যাট নিজে বাহাত্তর ডিগ্রি বেছে নেয় না। আগে কাউকে ঠিক করতে হয়েছিল যে এটাই সঠিক তাপমাত্রা।
সফটওয়্যারের ক্ষেত্রে এর অর্থ হলো, একটি লুপের ভেতরে থাকা একটি এজেন্ট সারাদিন বাগ ঠিক করতে পারে, ফাংশন রিফ্যাক্টর করতে পারে বা প্যারামিটার টিউন করতে পারে। তবে, এটি সিদ্ধান্ত নিতে পারে না যে কোন ফিচারটি আসলে গ্রাহককে সাহায্য করবে অথবা পরবর্তী রিলিজের আগে একটি বাগ ঠিক করা আদৌ প্রয়োজন কি না। এই সিদ্ধান্তগুলোর জন্য ব্যবসায়িক প্রেক্ষাপট, ব্যবহারকারীর সমস্যা এবং কৌশলগত অগ্রাধিকার সম্পর্কে বিচারবুদ্ধির প্রয়োজন হয়। এজেন্টরা কাজ সম্পাদন করে। মানুষ সিদ্ধান্ত নেয়। এই দুটির মধ্যে বিভ্রান্তি তৈরি হওয়ার কারণেই দলগুলো এমন সব চমৎকারভাবে অপ্টিমাইজ করা সিস্টেম তৈরি করে ফেলে যা আসলে ভুল সমস্যার সমাধান করে।
লুপ ইঞ্জিনিয়ারিং (Loop engineering) দরকারী, কিন্তু এটি একটি সংকীর্ণ বিষয়। এটি আপনাকে শৃঙ্খলা ও দ্রুততার সাথে মেশিন চালাতে সাহায্য করে। এটি সিদ্ধান্ত নেয় না যে কোন মেশিনটি তৈরি করতে হবে, এটি কার জন্য, অথবা মানুষের দৃষ্টিতে সাফল্যের সংজ্ঞা কী। কোন ফিচারটি গুরুত্বপূর্ণ, কোন ঝুঁকি গ্রহণ করা সম্ভব এবং কখন লক্ষ্যটি নিজেই পরিবর্তন করা প্রয়োজন—এই বিচারবুদ্ধি আপনার সাথেই থাকতে হবে। যে কাজগুলো আপনি স্বয়ংক্রিয়ভাবে যাচাই করার মতো যথেষ্ট ভালোভাবে বোঝেন, সেগুলোর জন্য লুপ তৈরি করুন। বাকি সবকিছুর নিয়ন্ত্রণ নিজের হাতে রাখুন।
এই নিবন্ধটি মূলত Isaac Hagoel-এর “Loop Engineering Minus The Hype.” আলোচনায় আলোচিত ধারণাগুলোর ওপর ভিত্তি করে লেখা। আরও ইঞ্জিনিয়ারিং সংক্রান্ত আলোচনার জন্য, Telegram-এ আমাদের লার্নিং কমিউনিটিতে যোগ দিন।