যখন আপনি একটি লার্জ ল্যাঙ্গুয়েজ মডেলকে (LLM) এমন একটি ওয়ার্কফ্লোর সাথে যুক্ত করেন যেখানে ইমেলের মাধ্যমে মানুষের অনুমোদনের প্রয়োজন হয়, তখন মডেলটি খুব কমই সমস্যার কারণ হয়। সমস্যাটি ঘটে ঠিক সেখানে যেখানে কোড শেষ হয় এবং ইনবক্স শুরু হয়। একটি স্বায়ত্তশাসিত রান (run) একটি অনুরোধ পাঠায়। তারপর প্রথমটি শেষ হওয়ার আগেই আরেকটি রান শুরু হয়। একটি শেয়ার্ড ইনবক্স বিভিন্ন প্রসেস থেকে আসা থ্রেডগুলো সংগ্রহ করে। কেউ একজন বারো ঘণ্টা দেরিতে আসা একটি মেসেজে 'approve' ক্লিক করে। এখন আপনার কাছে আউটপুট আছে। আপনার কাছে একটি সিদ্ধান্ত আছে। কিন্তু আপনি প্রমাণ করতে পারেন না কোন রানটি কী তৈরি করেছে, বা সেই অনুমোদনটি আদৌ এই জেনারেশনের জন্য ছিল কি না। আমি যথেষ্ট পরিমাণ ইন্টারনাল অটোমেশন পাইপলাইন পরিষ্কার করেছি যা থেকে আমি এই প্যাটার্নটি জানি। এটি বেশিরভাগ টিমের প্রত্যাশার চেয়ে দ্রুত বিভ্রান্তি থেকে একটি বড় সমস্যার (incident) দিকে ধাবিত হয়।
অপারেশনাল বাউন্ডারি
আপনার অর্কেস্ট্রেটর (orchestrator) এবং আপনার ইমেল প্রোভাইডারের মধ্যে সীমানাটি কেবল একটি নেটওয়ার্ক হপ নয়। এটি একটি স্টেট বাউন্ডারি (state boundary)। যখন LLM একটি ড্রাফট তৈরি করা শেষ করে, রানটি তখনও সচল থাকে। এটি অপেক্ষা করছে। যদি আপনার সিস্টেম 'send' করাকে একটি 'fire-and-forget' ইভেন্ট হিসেবে গণ্য করে, তবে আপনি ইতিমধ্যেই নিয়ন্ত্রণ হারিয়ে ফেলেছেন।
আমি এমন পাইপলাইন দেখেছি যেখানে একটি রিট্রাই পলিসি (retry policy) খুব বেশি আক্রমণাত্মক হওয়ার কারণে একটি মাত্র রান দুটি আলাদা অ্যাপ্রুভাল রিকোয়েস্ট তৈরি করে। আমি আরও দেখেছি যে একটি রান এমন একটি মেইলবক্স ব্যবহার করছে যা গত সপ্তাহের মেসেজগুলো তখনও ধরে রেখেছে। মানব অনুমোদনকারী (human approver) রান আইডি (run ID) দেখতে পান না। তারা কেবল একটি সাবজেক্ট লাইন এবং একটি বাটন দেখেন। কোনো কাঠামো ছাড়া, তারা সেই একই ইনবক্সে অনুমান করে কাজ করেন যেখানে মার্কেটিং নিউজলেটার এবং মনিটরিং অ্যালার্ট থাকে।
অবহেলিত ধাপ
টিমগুলো প্রম্পট টিউন করা, গার্ডরেল (guardrails) যোগ করা এবং আউটপুট বেঞ্চমার্ক করার জন্য সপ্তাহ ব্যয় করবে। তারপর তারা অ্যাপ্রুভাল ধাপটিকে একটি Slack চ্যানেল বা একটি শেয়ার্ড সাপোর্ট ইনবক্সের সাথে যুক্ত করে কাজ শেষ বলে ধরে নেয়। এটি তিনটি নিশ্চিত সমস্যা তৈরি করে:
- একটি শেয়ার্ড ইনবক্স একাধিক রান থেকে আসা ইভেন্টের ডাম্পিং গ্রাউন্ডে পরিণত হয়। কনটেক্সট বা প্রেক্ষাপট ভেঙে পড়ে। থ্রেডগুলো খুলে এবং ম্যানুয়ালি টাইমস্ট্যাম্প বিশ্লেষণ না করে আপনি বুঝতে পারবেন না কোন মেসেজটি কোন বিজনেস ট্রানজ্যাকশনের ছিল।
- রিট্রাই (Retries) প্রমাণ মুছে ফেলে। যদি একটি রান তার অ্যাপ্রুভাল রিকোয়েস্ট পুনরায় পাঠায়, তবে মূল মেসেজটি কোনো অতি-উৎসাহী ইমেল ক্লায়েন্ট দ্বারা চাপা পড়ে যেতে পারে, মুছে যেতে পারে বা ডুপ্লিকেট হিসেবে চিহ্নিত হতে পারে। অডিট ট্রেইল (audit trail) নষ্ট হয়ে যায়।
- মানুষের সিদ্ধান্তগুলো সিস্টেমের বাইরে থেকে আসে। কেউ একটি টিকিট বা সরাসরি মেসেজে "looks good" লিখে উত্তর দেয়। সেই মতামতটি ওয়ার্কফ্লোর ভেতরে কখনোই স্ট্রাকচার্ড ডেটা (structured data) হিসেবে রূপান্তরিত হয় না। এজেন্ট বা সিস্টেমের কাছে এটি যাচাই করার কোনো উপায় থাকে না যে কে কী বলেছে বা কখন বলেছে।
যখন কিছু ভুল হয় এবং আপনাকে তদন্ত করতে হয়, তখন আপনি কেবল শোনাকথার ওপর নির্ভর করতে হয়। "আমার মনে হয় ওটা সঠিক ইমেল ছিল।" স্মৃতি কোনো ট্রেসেবিলিটি (traceability) নয়। একটি অডিট লগ কোনো অনুমানের ওপর ভিত্তি করে কাজ করতে পারে না।
ডেলিভারি ডিটেইল থেকে চেকপয়েন্টে
এটি ঠিক করার জন্য ডিজাইনে পরিবর্তনের প্রয়োজন। ইমেলকে কেবল একটি ডেলিভারি ডিটেইল হিসেবে ভাবা বন্ধ করুন। এটিকে একটি সিস্টেম চেকপয়েন্ট (system checkpoint) হিসেবে বিবেচনা করা শুরু করুন। এর মানে হলো প্রতিটি মেসেজ একটি স্টেট ট্রানজিশন (state transition), এবং প্রতিটি স্টেট ট্রানজিশনের জন্য আইডেন্টিটি, অথরাইজেশন এবং প্রমাণের প্রয়োজন।
আপনি যখন এই মানসিকতা গ্রহণ করবেন, তখন প্রশ্নগুলো বদলে যাবে। আপনি আর জিজ্ঞেস করবেন না যে ইমেলটি সফলভাবে পাঠানো হয়েছে কি না। আপনি জিজ্ঞেস করতে শুরু করবেন কোন রানটি এটি পাঠিয়েছে, এটি কী প্রমাণ রেখে গেছে এবং কোন নিয়মটি ওয়ার্কফ্লোটি চালিয়ে যাওয়ার জন্য অনুমোদন দিয়েছে। এজেন্ট অবশ্যই ইমেল বডি লিখতে পারে। কিন্তু আপনার প্ল্যাটফর্মকে অবশ্যই আইডেন্টিটি এবং ভেরিফিকেশন পাথ (verification paths) নিশ্চিত করতে হবে। LLM হলো লেখক। ইনফ্রাস্ট্রাকচার হলো নোটারি (notary)।
একটি ন্যূনতম ডিজাইন
এটি তৈরি করতে আপনার প্রচুর অর্থের প্রয়োজন নেই। আমার ন্যূনতম কার্যকর (minimum viable) ভার্সনটি পাঁচটি সুনির্দিষ্ট অংশ ব্যবহার করে।
- ওয়ার্কফ্লো শুরু হওয়ার ঠিক মুহূর্তেই অর্কেস্ট্রেটর একটি
run_idতৈরি করে। এই আইডেন্টিফায়ারটি প্রতিটি পরবর্তী পদক্ষেপের মেরুদণ্ড। এটি কখনোই পরিবর্তিত হয় না এবং এটি কখনোই পুনরায় ব্যবহার করা হয় না। - প্রতিটি ইমেল অ্যাকশনে তিনটি ফিল্ড থাকে:
run_id, একটিmessage_typeলেবেল যেমন "approval_request" বা "evidence_notification," এবং একটিpolicy_versionস্ট্রিং যা নির্দেশ করে কোন গভর্নেন্স রুলগুলো সক্রিয় রয়েছে। এটি একটি সাধারণ মেসেজকে একটি টাইপড ইভেন্টে (typed event) পরিণত করে। - প্রমাণগুলো রানের মাধ্যমে আলাদা করা একটি ইনবক্সে থাকে। এর মানে সব সময় প্রতিটি রানের জন্য আলাদা ইমেল অ্যাকাউন্ট নয়। এর মানে হতে পারে একটি ডেডিকেটেড লেবেল, একটি সাবফোল্ডার, বা একটি রাউটিং রুল যা থ্রেডগুলোকে এমনভাবে বিভক্ত করে যাতে একটি রানের যোগাযোগ অন্যটির সাথে মিশে না যায়।
- অ্যাপ্রুভাল রেসপন্স অবশ্যই একটি স্ট্রাকচার্ড ইভেন্ট হতে হবে, কেবল একটি ফ্রি-টেক্সট "ok" নয়। মানুষ এখনও ক্লিক বা রিপ্লাই করবে, কিন্তু সিস্টেম সেই অ্যাকশনটিকে একটি মেশিন-রিডেবল পেলোড (machine-readable payload) হিসেবে অনুবাদ করবে যেখানে
run_id, সিদ্ধান্ত এবং টাইমস্ট্যাম্প উল্লেখ থাকবে। - প্রবাহটি কেবল তখনই চলতে পারে যদি প্রমাণ এবং সিদ্ধান্ত মিলে যায়। ওয়ার্কফ্লো বিচ্ছিন্নভাবে অ্যাপ্রুভালের ওপর বিশ্বাস করে না। এটি LLM-এর আউটপুট প্রোডাকশনে পৌঁছানোর আগে মূল রিকোয়েস্টের বিপরীতে অ্যাপ্রুভাল পেলোডটি যাচাই করে।
একটি কার্যকর চেকপয়েন্ট যা যাচাই করে
একটি কার্যকর চেকপয়েন্ট মানুষের সিদ্ধান্ত গ্রহণ করার আগে চারটি শর্ত আরোপ করে।
- প্রাপককে অবশ্যই রান কনটেক্সটের (run context) অন্তর্ভুক্ত হতে হবে। যদি অনুমোদনকারী এই নির্দিষ্ট ওয়ার্কফ্লো ইনস্ট্যান্সের জন্য নির্ধারিত রিভিউয়ার না হন, তবে সিস্টেম সিগন্যালটি প্রত্যাখ্যান করবে।
- সাবজেক্ট বা রাউটিং মেটাডেটা অবশ্যই বর্তমান ফ্লো স্টেটের (flow state) সাথে মিলতে হবে। তৃতীয় ধাপের অনুমোদন দ্বিতীয় ধাপকে বাইপাস করতে পারে না।
- টাইমস্ট্যাম্প অবশ্যই একটি প্রত্যাশিত সময়ের মধ্যে হতে হবে। টাইমআউটের পরে আসা কোনো সিদ্ধান্ত নতুনভাবে রিভিউ করার প্রক্রিয়া শুরু করবে, স্বয়ংক্রিয়ভাবে পাস হবে না।
- প্রমাণটি অন্য কোনো রান দ্বারা পুনরায় ব্যবহার করা যাবে না। যদি একই মেসেজ আইডি বা টোকেন দুটি আলাদা অনুমোদনের অনুরোধে দেখা যায়, তবে সেটি একটি কলিশন (collision) হিসেবে গণ্য হবে এবং সিস্টেমটি থেমে যাবে।
প্রকৃত খরচ
এই প্যাটার্নটি বিনামূল্যে পাওয়া যায় না। আপনাকে আরও বেশি মেটাডেটা সংরক্ষণ করতে হবে। আপনাকে একটি পলিসি লেয়ার যোগ করতে হবে যা কাউকে রক্ষণাবেক্ষণ করতে হবে। আপনাকে আপনার টিমকে অনানুষ্ঠানিক মন্তব্যের পরিবর্তে মানুষের সিদ্ধান্তগুলোকে স্ট্রাকচার্ড ডেটা হিসেবে লগ করতে বাধ্য করতে হবে। এটি আমলাতন্ত্রের মতো মনে হতে পারে। কিন্তু বাস্তবে, এটি একটি চমৎকার বিনিময়।
আপনি স্পষ্টতার জন্য গতি ত্যাগ করছেন।