AI এজেন্টকে কীভাবে নির্ভরযোগ্য করবেন: পরিমাপ থেকে স্বয়ংক্রিয় কাজ পর্যন্ত ধাপে ধাপে পরিকল্পনা

মডেল শক্তিশালী হলেও এজেন্ট কেন অনির্ভরযোগ্য

এজেন্টের নির্ভরযোগ্যতা পুরো ব্যবস্থার বৈশিষ্ট্য, শুধু মডেলের নয়। দীর্ঘ কাজ কয়েক ডজন ধাপের সমষ্টি, আর ভুল জমে: প্রতিটি ধাপে ৯৫% সঠিক হলে দশ ধাপের একটি শৃঙ্খল একটিও ভুল ছাড়া পার হয় প্রায় ৬০% চেষ্টায় (0.95^10 ≈ 0.60), আর পঞ্চাশ ধাপে ১০%-এরও কম। মডেলের নির্ভুলতা আপনার হাতে নেই, কিন্তু একই ধাপে ভুল ধরা এবং সেটিকে সস্তা করা আপনার হাতে আছে। harness এই কাজটিই করে: নির্দেশনা, টুল, পরিবেশ, অবস্থা ও প্রতিক্রিয়া দিয়ে মডেলকে ঘিরে রাখা।

নিচে এমন একটি পরিকল্পনা, যা «অনুভূতি» থেকে পরিমাপযোগ্য নির্ভরযোগ্যতায় এবং সেখান থেকে স্বয়ংক্রিয় কাজে নিয়ে যায়। ধাপগুলো প্রভাবের ক্রমে সাজানো: প্রতিটি পরবর্তী ধাপ আগেরটির ওপর দাঁড়িয়ে।

ধাপ ১. «অনুভূতি» দিয়ে মূল্যায়ন বন্ধ করুন

একজন ইঞ্জিনিয়ার নিশ্চিত যে নতুন prompt সবকিছু বদলে দিয়েছে, আরেকজন কোনো পার্থক্য দেখেন না, আর কেউ মেট্রিক গোনেনি। শুরু করুন ব্যর্থতার লগ দিয়ে: এজেন্ট আটকে গেলে, কিছু ভাঙলে, বা কাজ না-করা ফিচারকে «সম্পন্ন» বললে একটি লাইন লিখুন।

| তারিখ | কাজ               | কী ঘটল                        | উপাদান         |
|-------|-------------------|-------------------------------|----------------|
| 10/10 | কার্টে ছাড়        | «সম্পন্ন», e2e চালানো হয়নি   | প্রতিক্রিয়া   |
| 10/10 | পেমেন্ট webhook    | database চালু করতে পারেনি     | পরিবেশ         |
| 11/10 | API refactor      | আগে বাতিল সমাধান আবার নিল     | অবস্থা         |

«উপাদান» কলামটিই সবচেয়ে গুরুত্বপূর্ণ। এক সপ্তাহ পরে দেখা যাবে আটকানো কোথায়, আর আপনি সব একসঙ্গে নয়, সেই জায়গাটাই ঠিক করবেন। সফল চালানোর অনুপাত দিয়ে নির্ভরযোগ্যতা গোনা ভুল: এজেন্ট কোথায় পড়ে যায় তা বলে দেয় বাধার লগই।

ধাপ ২. দুটি মেট্রিক আনুন: MTBF ও MTTR

নির্ভরযোগ্যতা দুটি সংখ্যায় প্রকাশ পায়। MTBF (ব্যর্থতার মধ্যবর্তী গড় সময়) এজেন্টের ক্ষেত্রে: আটকানোর আগে সে কতগুলো ধাপ পার করে। MTTR (গড় পুনরুদ্ধার সময়) হলো ব্যর্থতার পর কাজের অবস্থায় ফিরতে কত সময় লাগে। প্রাপ্যতা বাড়ে প্রথমটি বাড়লে এবং দ্বিতীয়টি কমলে।

এমন এজেন্টের পেছনে ছোটা, যা কখনো ভুল করে না, এক অন্তহীন প্রতিযোগিতা। MTTR সাধারণত এক দিনে কমানো যায়। তাই দ্বিতীয় সংখ্যা থেকে শুরু করুন।

ধাপ ৩. ভুলকে সস্তা করুন

স্বয়ংক্রিয়তা গ্রহণযোগ্য তখন নয় যখন এজেন্ট ভুল বন্ধ করে, বরং যখন ভুলের খরচ প্রায় শূন্যের কাছে নেমে আসে। এর জন্য তিনটি জিনিস লাগে:

• ছোট, পরিষ্কার commit — যেকোনো পরিবর্তন এক কমান্ডে ফেরানো যায়।
• আইসোলেশন — এজেন্ট আলাদা branch বা কাজের কপিতে কাজ করে, যেমন git worktree দিয়ে, এবং উৎপাদনে প্রবেশাধিকারহীন sandbox-এ।
• পরিবেশ রিসেট স্ক্রিপ্ট — database, dependency ও সার্ভিস এক কমান্ডে আগের অবস্থায় ফেরে।

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # DB নতুন করে বানাও, migration চালাও, fixture লোড করো

স্টপওয়াচ দিয়ে মাপুন সম্পূর্ণ পুনরুদ্ধার কতক্ষণ নেয়। সেটাই আপনার MTTR। একই সঙ্গে ক্ষতির ব্যাসার্ধ সীমিত করুন: একটি কাজের diff-এর আকারের সীমা এবং কাজের এলাকার বাইরের ফাইল বদলানোর নিষেধ।

ধাপ ৪. প্রতিক্রিয়ার চক্র বন্ধ করুন

যাচাই ছাড়া এজেন্ট নিজেই নিজের একমাত্র বিচারক, এবং সে আন্তরিকভাবেই কাজ সম্পন্ন ধরে নেয়। তাকে এমন কমান্ড দিন যা দিয়ে সে নিজেকে যাচাই করতে পারে, এবং সেগুলো বাধ্যতামূলক করুন।

• Fail-fast: যাচাই প্রথম ভুলে স্পষ্ট বার্তা দিয়ে থেমে যায়, একশ লাইন আবর্জনা ছাড়ে না।
• প্রতিটি পরিবর্তনের পর দ্রুত যাচাই: এজেন্টের hook দিয়ে linter ও type check।
• রিডান্ডেন্সি: একই বৈশিষ্ট্যের জন্য দ্বিতীয়, স্বাধীন যাচাই — unit test-এর ওপরে E2E পরিস্থিতি। সবুজ unit test প্রমাণ করে না যে ফিচারটি ব্যবহারকারীর কাছে কাজ করে।

«সম্পন্ন» মানদণ্ড যাচাইযোগ্য শর্ত হিসেবে লিখুন: «কোড প্রয়োগসহ checkout E2E পরিস্থিতি পাস করে», «ছাড় প্রয়োগ হয়েছে» নয়।

ধাপ ৫. মেমরি ফাইলে সরান

এজেন্ট আগের সেশন মনে রাখে না। কাজ এগিয়ে নিতে যা দরকার তা repository-তে থাকতে হবে: লক্ষ্য, কী করা হয়েছে এবং কীভাবে যাচাই হয়েছে, কারণসহ সিদ্ধান্ত, বন্ধ পথ, এবং পরের ধাপ। ভালো লক্ষণ: নতুন সেশন যদি শুধু repository ও «চালিয়ে যাও» শব্দটি পায়, তবে সে সরাসরি কার্যকর কাজ শুরু করে।

সংকুচিত কথোপকথনের ইতিহাস ধারাবাহিকতার অনুভূতি দেয়, কিন্তু সবচেয়ে মূল্যবান জিনিসটি হারায় — বাতিল সিদ্ধান্তের কারণ। সম্পূর্ণ লিখিত অবস্থা সহ সেশন ইচ্ছাকৃতভাবে শেষ করা সাধারণত সস্তা।

ধাপ ৬. একবারে একটি কাজ

Little-এর সূত্র: একই সময়ে কাজের সংখ্যা = আগমনের হার × ব্যবস্থায় একটি কাজের সময়। নির্দিষ্ট ক্ষমতায় সমান্তরাল কাজ কাজকে দ্রুত করে না, প্রতিটি কাজকে শুধু দীর্ঘ করে। এজেন্টের ক্ষেত্রে এটি আরও কঠোর: তিনটি ফিচার মানে এক প্রসঙ্গ-জানালায় তিনটি ডোমেইন মডেল।

• WIP=1 রাখুন: একটি ফিচার যাচাইকৃত ফলাফল পর্যন্ত।
• কাজকে আকারে কাটুন: একটি যাচাইযোগ্য ব্যবহারকারী-সক্ষমতা, ১–৩টি ফাইল, এক মিনিটের কম যাচাই।
• BACKLOG.md রাখুন «সঙ্গে» কাজগুলোর জন্য। এজেন্ট পাশে কোনো ত্রুটি দেখলে সেটি backlog-এ এক লাইন, নিজে বদলানো নয়।

ধাপ ৭. সম্পাদক ও যাচাইকারীকে আলাদা করুন

এজেন্টের নিজের মূল্যায়ন দুর্বল ব্রেক: যে সেশন কোড লিখেছে, সে তাকে সঠিক ভাবতে ঝোঁকে। ফলাফল মূল্যায়ন করুক আলাদা subagent বা আলাদা সেশন, যা শুধু প্রয়োজনীয়তা, diff ও যাচাইয়ের ফলাফল পায়, সম্পাদকের যুক্তি নয়। মূল্যায়নকারীর রায় মেশিনের যাচাইয়ের ওপর দাঁড়াবে, «দেখতে ঠিক আছে»-এর ওপর নয়।

ধাপ ৮. এজেন্টকে স্বয়ংক্রিয় চক্রে ছাড়ুন

Harness এক বারের চালানোকে নির্ভরযোগ্য করে, চক্র চালানোর সারিকে স্বয়ংক্রিয় করে। দুর্বল harness-এর ওপর চক্র ভুলকে শুধু দ্রুত বাড়ায়, তাই এই ধাপ সবশেষে। সবচেয়ে সরল চক্র তিন লাইনে লেখা যায়:

লক্ষ্য:      ছাড় সহ payment E2E পরিস্থিতি পাস করে
যাচাই:      make lint && make test && make e2e
থামা:       লক্ষ্য অর্জিত হলে ট্র্যাক বা ১৫ চেষ্টা বা ২ ঘণ্টা → মানুষকে ডাকো

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

নিরাপদ স্বয়ংক্রিয়তার নিয়ম

• থামার শর্ত শুধু মেশিনে যাচাইযোগ্য হবে, সঙ্গে চেষ্টা ও বাজেটের সীমা।
• এসকেলেশন: আগে থেকে লিখুন চক্রকে কী বিশ্বাস করা হয় না (উৎপাদন migration, টাকা, ডেটা মুছে ফেলা)।
• কাজ আটকে থাকলে এবং অগ্রগতি সত্যিকারভাবে না বাড়লে সেটি মানুষের কাছে হস্তান্তরের সংকেত, ঘুরতে থাকার নয়।
• Diff পড়ুন। চক্রের গতি আপনার পড়ার গতির চেয়ে বেশি হওয়া উচিত নয়, নইলে আপনার কোডবেস আপনার বোধের বাইরে চলে যায়।

এই পথের সাধারণ ভুলগুলো

নির্দেশনা নতুন করে লেখা দিয়ে শুরু করা

এজেন্টের ব্যর্থতার সবচেয়ে জনপ্রিয় প্রতিক্রিয়া: AGENTS.md-এ একটি নিয়ম যোগ করা। কয়েক মাসে ফাইলটি শত শত লাইনে ফুলে ওঠে, আর গুরুত্বপূর্ণ নিয়ম তার মধ্যে হারিয়ে যায়। ব্যর্থতার লগ যদি দেখায় এজেন্ট যাচাই চালায়নি, তাহলে ঠিক করতে হবে প্রতিক্রিয়া: যাচাই-কমান্ড ও hook, আরেক অনুচ্ছেদ লেখা নয়।

সবকিছু একসঙ্গে ঠিক করা

Harness-এর পাঁচটি উপাদানই একসঙ্গে উন্নত করার ইচ্ছা হয়। ফলে বোঝা যায় না কোনটি আসলে সাহায্য করেছে। প্রতিটি উপাদানকে ১ থেকে ৫ স্কেলে মূল্যায়ন করুন, সবচেয়ে দুর্বলটির পেছনে আধ ঘণ্টা দিন, এবং একই পাঁচটি সাধারণ কাজ আগে ও পরে চালান। ব্যর্থতার লগের পার্থক্য দেখাবে কোনো প্রভাব হয়েছে কি না।

«Test সবুজ» আর «ফিচার কাজ করে» এক ভাবা

এজেন্ট এমন test লিখতে পারে, যা তার নিজের বাস্তবায়ন যাচাই করে, প্রয়োজনীয়তা নয়। সেই test সবসময় সবুজ থাকে। প্রতিরোধ: ব্যবহারকারীর স্তরে যাচাই (E2E পরিস্থিতি), যা বাস্তবায়নের আগে বা স্বাধীন যাচাইকারী লেখে, এবং নিয়ম যে এজেন্ট পাস করানোর জন্য test বদলাবে না।

গতির জন্য যাচাই বন্ধ করা

ধীর যাচাই «এবার বাদ দিই» প্রলোভন তৈরি করে। ভালো উপায় হলো ভাগ করা: দ্রুত linter ও type check প্রতিটি পরিবর্তনের পর, আর পূর্ণ test ও E2E «সম্পন্ন» বলার আগে। এতে প্রতিক্রিয়ার চক্র ছোট থাকে এবং কাজে বাধা দেয় না।

প্রথম ধাপ হিসেবে ablation ধরা

আপনি harness-এর উপাদান একটি একটি করে বন্ধ করে দেখতে পারেন মান কতটা কমে। এটি কার্যকর, কিন্তু ব্যয়বহুল এবং প্রথম ধাপ নয়: আগে ব্যর্থতার লগ দেখাবে বাধা কোথায়, ablation শুধু অনুমানটি নিশ্চিত করে। একটি উপাদান বন্ধ করলে শূন্য পতন মানেই উপাদানটি অপ্রয়োজনীয় নয় — হয়তো নির্বাচিত কাজগুলো সেটি ব্যবহারই করেনি।

পরিপক্কতার সিঁড়ি

সারসংক্ষেপ

AI এজেন্টকে নির্ভরযোগ্য করার উপায়: মাপুন, ব্যর্থতার লগ থেকে দুর্বল উপাদান খুঁজুন, ভুলকে সস্তা করুন, প্রতিক্রিয়ার চক্র বন্ধ করুন, মেমরি ফাইলে রাখুন, একবারে একটি কাজ রাখুন, এবং সম্পাদক ও যাচাইকারীকে আলাদা করুন। এরপর যাচাইযোগ্য থামার শর্তসহ স্বয়ংক্রিয় চক্র নিরাপদ হয়। এই পরিকল্পনার প্রতিটি ধাপ হাতে-কলমে harness engineering কোর্সে শেখানো হয়।