দুটি AI এজেন্ট একই ফাইল এডিট করতে পারে, উভয়ই “success” স্বীকৃতি বা অ্যাকনলেজমেন্ট পেতে পারে, তবুও তাদের পরিবর্তনের মধ্যে কেবল একটি টিকে থাকে। পাঁচটি সমসাময়িক (concurrent) এজেন্টের একটি সাধারণ পরীক্ষায়, পাঁচটি রাইটের মধ্যে চারটি কোনো ত্রুটি বা লগ এন্ট্রি ছাড়াই অদৃশ্য হয়ে গেছে—এটি একটি ক্লাসিক lost-update anomaly, যা হারিয়ে যাওয়া কাজের জন্য পরিশোধিত টোকেনগুলো অপচয় করে।

কেন এই সমস্যাটি গুরুত্বপূর্ণ

যখন একটি AI এজেন্ট কোনো ফলাফল লিখে দেয়, তখন মূল পরিষেবাটি জেনারেট করা প্রতিটি টোকেনের জন্য চার্জ করে। যদি রাইটটি নিঃশব্দে ওভাররাইট হয়ে যায়, তবুও প্রোভাইডার সেই কম্পিউটেশনের জন্য বিল পাঠাবে যা দিয়ে বাদ পড়া আউটপুটটি তৈরি করা হয়েছিল। মাল্টি-এজেন্ট পাইপলাইন—এজেন্ট সোয়ার্ম (agent swarms), প্যারালাল ডেটা-ক্লিনিং ওয়ার্কার্স, বা এমন যেকোনো সিস্টেম যেখানে একাধিক বট একটি প্ল্যান ফাইল বা স্ক্র্যাচপ্যাড শেয়ার করে—সেখানে এই লুকানো ক্ষতিগুলো বড় ধরনের খরচের অপচয়ে (cost leak) পরিণত হতে পারে। এই অ্যানোমালিটি ডেটা ইন্টিগ্রিটিকেও হুমকির মুখে ফেলে: পরবর্তী ধাপগুলো অসম্পূর্ণ বা পুরনো তথ্যের ওপর ভিত্তি করে কাজ করতে পারে, যা ধারাবাহিক ত্রুটি (cascading errors) সৃষ্টি করতে পারে।

কীভাবে এই অ্যানোমালিটি ঘটে

এর মূল কারণ হলো একটি race condition:

১. দুই (বা তার বেশি) এজেন্ট একটি রিসোর্সের একই ভার্সন পড়ে, যেমন একটি JSON প্ল্যান ফাইল। ২. প্রতিটি এজেন্ট সেই স্ন্যাপশটের ওপর ভিত্তি করে নিজস্ব রিজনিং বা ট্রান্সফরমেশন সম্পন্ন করে। ৩. উভয় এজেন্টই শেয়ার্ড স্টোরেজে একটি রাইট অপারেশন (write operation) পাঠায়। ৪. স্টোরেজ সিস্টেম কোনো কনফ্লিক্ট ডিটেকশন ছাড়াই দ্বিতীয় রাইটটি গ্রহণ করে এবং প্রথমটিকে ওভাররাইট করে দেয়। ৫. উভয় এজেন্টই একটি “ACK” পায় যা নিশ্চিত করে যে রাইটটি সফল হয়েছে, যদিও প্রথম অবদানটি হারিয়ে গেছে।

স্টোরেজ সিস্টেমের স্বীকৃতি কেবল এটিই প্রমাণ করে যে একটি রাইট হয়েছে; এটি নিশ্চিত করে না যে রাইটটি অন্যান্য সমসাময়িক আপডেটের সাপেক্ষে নিরাপদ ছিল। একটি append-only log, যা প্রায়ই সুরক্ষা হিসেবে প্রচার করা হয়, সেটিও একইভাবে কাজ করে: এটি রেকর্ড করে যে একটি রাইট ঘটেছে কিন্তু পরবর্তী রাইটগুলো যেন আগেরগুলোকে মুছে না ফেলে তা প্রতিরোধ করতে পারে না।

একটি compare-and-set গেট কী করে

একটি compare-and-set (CAS) গেট রাইট গ্রহণ করার আগে একটি ভার্সন চেক যোগ করে:

  • Read: এজেন্ট ফাইলের বর্তমান ভার্সন নম্বর (বা হ্যাশ) সংগ্রহ করে।
  • Compute: এজেন্ট তার কাজ সম্পন্ন করে ফাইলের একটি নতুন ভার্সন তৈরি করে।
  • Write: এজেন্ট তার কাছে থাকা মূল ভার্সন নম্বরসহ নতুন কন্টেন্ট পাঠায়।
  • Validate: স্টোরেজ লেয়ার সরবরাহকৃত ভার্সনটির সাথে বর্তমান ভার্সনটি তুলনা করে। যদি তারা ভিন্ন হয়, তবে রাইটটি প্রত্যাখ্যান করা হয়; অন্যথায়, এটি সম্পন্ন হয় এবং ভার্সনটি বৃদ্ধি করে।

যদি ভার্সন পরিবর্তিত হয়ে থাকে, তবে এজেন্ট বুঝতে পারে যে তার কাছে থাকা তথ্যটি পুরনো (stale) ছিল এবং তাকে নতুন ভার্সন ব্যবহার করে পুরো চক্রটি—read, compute, write—পুনরায় করতে হবে। এটি একটি অদৃশ্য ওভাররাইটকে একটি স্পষ্ট ব্যর্থতায় রূপান্তরিত করে যা লগ করা যায়, পুনরায় চেষ্টা (retry) করা যায় এবং হিসাব রাখা যায়।

নিরাপত্তার মূল্য

CAS গেটটি বিনামূল্যে পাওয়া যায় না। একই পাঁচটি-এজেন্ট সিমুলেশনে:

পরিস্থিতি রাইট করার চেষ্টা সফল অবদান টোকেন খরচ
কোনো CAS গেট নেই ৫ ১ ৫ ইউনিট
CAS গেট সহ ৫ ৫ (রিট্রাই করার পর) ৯ ইউনিট

গেটটি ভার্সন কনফ্লিক্ট হওয়া এজেন্টদের জন্য অতিরিক্ত read-compute-write সাইকেল যোগ করে, যা টোকেন খরচ বাড়িয়ে দেয়। এখানে ট্রেড-অফটি স্পষ্ট: গেট ছাড়া আপনি নিঃশব্দে ডেটা হারাবেন; গেট থাকলে আপনি সামান্য অতিরিক্ত খরচ করবেন কিন্তু প্রতিটি কনফ্লিক্ট সম্পর্কে স্বচ্ছ ধারণা পাবেন।

এই ব্যর্থতা কতটা সাধারণ?

মাত্র দুটি এজেন্ট থাকলেও, পরীক্ষায় দেখা গেছে যে রাইট হারানোর সম্ভাবনা ৭৫%। পাঁচটি এজেন্টের ক্ষেত্রে, ডেটা হারানোর হার ১০০%-এর কাছাকাছি পৌঁছেছে। এই সংখ্যাগুলো নির্দেশ করে যে, যেকোনো প্রোডাকশন-লেভেল মাল্টি-এজেন্ট ওয়ার্কফ্লোর জন্য “সাধারণত ঠিক থাকবে” এমন ধারণা নেওয়া বিপজ্জনক।

পাল্টা যুক্তি: কখন গেট এড়িয়ে চলবেন

যদি একটি সিস্টেমে প্রতিটি রিসোর্সের জন্য একটি মাত্র এজেন্ট চলে বা উচ্চতর স্তরে কঠোর সিরিয়ালাইজেশন (serialisation) প্রয়োগ করা হয়, তবে অতিরিক্ত CAS চেক অপ্রয়োজনীয় হতে পারে। তবে, ঝুঁকি গণনার ক্ষেত্রে ব্যর্থ কাজের পুনরায় চালানোর লুকানো খরচ এবং ডেটা হারিয়ে যাওয়ার ফলে পরবর্তী ধাপগুলোতে সম্ভাব্য প্রভাব অবশ্যই অন্তর্ভুক্ত করতে হবে।

পরবর্তীতে যা খেয়াল রাখবেন

  • Tooling support: এমন স্টোরেজ API খুঁজুন যা ভার্সন নম্বর বা ETag প্রকাশ করে এবং সরাসরি অ্যাটমিক CAS অপারেশন প্রদান করে।
  • Metrics: ভার্সন অমিলের কারণে কতবার রাইট প্রত্যাখ্যান হচ্ছে তা রেকর্ড করার জন্য আপনার এজেন্টগুলোকে প্রস্তুত করুন। কনফ্লিক্ট রেট বৃদ্ধি পাওয়া মানে হলো আপনার রিসোর্স স্কেল করা বা ওয়ার্কফ্লো নতুন করে ডিজাইন করা প্রয়োজন।
  • Retry strategies: সিম্পল এক্সপোনেনশিয়াল ব্যাক-অফ (exponential back-off) ভালো কাজ করে, তবে মনে রাখবেন যে বারবার রিট্রাই করলে টোকেন খরচ বেড়ে যায়। গ্রহণযোগ্য ডেটা লস এবং রিট্রাই লিমিটের মধ্যে ভারসাম্য বজায় রাখুন।
  • Hybrid approaches: কিছু টিম অডিটেবিলিটির জন্য append-only log এবং কনসিস্টেন্সির জন্য CAS গেট ব্যবহার করে, যা কী ঘটেছে তার রেকর্ড এবং ওভাররাইট থেকে সুরক্ষা—উভয়ই নিশ্চিত করে।

মূল কথা (Takeaway)

Lost-update anomalies টোকেন-চালিত AI পাইপলাইনগুলোকে অর্থ ক্ষয়কারী ব্ল্যাক হোলে পরিণত করে। একটি compare-and-set ভার্সন গেট সামান্য টোকেন ওভারহেড যোগ করলেও এটি নিঃশব্দ ডেটা লসকে একটি দৃশ্যমান এবং পুনরায় চেষ্টাযোগ্য (retryable) ঘটনায় রূপান্তরিত করে। যে কোনো সিস্টেম যেখানে একাধিক এজেন্ট স্টেট শেয়ার করে—যেমন ডাটাবেস, প্ল্যান ফাইল বা স্ক্র্যাচপ্যাড—সেখানে রাইট করার আগে একটি ভার্সন চেক যুক্ত করা হলো লুকানো খরচ এবং ক্ষতিগ্রস্ত ওয়ার্কফ্লোর বিরুদ্ধে সবচেয়ে সাশ্রয়ী বিমা।