AI এজেন্ট মূল্যায়ন: evals কীভাবে বানাবেন এবং অনুভূতির বদলে নির্ভরযোগ্যতা মাপবেন

দেখা যায় তবু মূল্যায়ন কেন দরকার

দেখা যাওয়াটাই সবচেয়ে খারাপভাবে কাজ করে। এজেন্ট এক সপ্তাহে প্রম্পট বদলানোর পরে একবারও আটকায়নি: এটা কি সমাধান, নাকি শুধু একটি সহজ সপ্তাহ? একজন ইঞ্জিনিয়ার নিশ্চিত যে নতুন টেমপ্লেট সবকিছু বদলেছে, অন্যজন একই লগ দেখেও কোনো পার্থক্য পায়নি। দুজনেই ততটুকুই ঠিক, যতটুকু তারা কিছু গোনেনি।

AI এজেন্ট মূল্যায়ন (evals) অনুভূতিকে একটি সংখ্যায় বদলায়। আপনি একটি স্থির কাজের সেট নেন, এজেন্টকে চালান, ফলাফল স্বয়ংক্রিয়ভাবে যাচাই করেন, এবং পরিবর্তনের আগে ও পরে মেট্রিক তুলনা করেন। তখন «আগের চেয়ে ভালো হয়েছে কি না» এই তর্ক টেবিল দেখে মেটে, কর্তৃত্ব দিয়ে নয়।

মূল্যায়ন ছাড়া হারনেসের যেকোনো বদল, প্রম্পট, AGENTS.md, টুলের সেট বা মডেল, অন্ধভাবে বাজি ধরার মতো। মূল্যায়ন থাকলে সেটি মাপা যায় এমন একটি পরীক্ষা।

কেন «অনুভূতি» ঠকায়

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

• সার্ভাইভরশিপ বায়াস। সফল চালনা মনে থাকে ও সহকর্মীদের দেখানো হয়, ব্যর্থ চালনা আবার চালানো হয় ও ভুলে যাওয়া হয়। শুধু সফল চালনা থেকে নির্ভরযোগ্যতা হিসাব করলে সেটি বলে না এজেন্ট আসলে কোথায় ভাঙে।
• ছোট নমুনা। পরপর তিনটি সফল কাজ এমন এজেন্টের জন্যও স্বাভাবিক ঘটনা, যে অর্ধেক ক্ষেত্রে সফল হয়। এর সম্ভাবনা 0,5³ = 12,5%, অর্থাৎ প্রায় প্রতি আটটি ধারায় একবার।
• নিশ্চিত সুর। এজেন্ট «হয়ে গেছে, সব টেস্ট পাস করছে» একই আত্মবিশ্বাসে বলে, ঠিক থাকুক বা না থাকুক। মডেলের আত্মবিশ্বাস ক্যালিব্রেটেড নয়: উত্তরের সুর সঠিকতার সংকেত নয়।

সেখান থেকে নিয়ম: যা লেখা হয়নি ও পুনর্গণনা হয়নি, তা অমাপিত ধরা হয়।

pass@k ও pass^k: দুটি মেট্রিক যাদের গুলিয়ে ফেলা হয়

এজেন্ট নির্ধারক নয়: একই কাজ আবার চালালে একবার পাস করতে পারে, আবার ফেল করতে পারে। তাই একটি কাজ কয়েকবার চালানো হয় এবং দুটি মেট্রিকের একটি গণনা করা হয়।

pass@k: k-এর মধ্যে অন্তত একটি চেষ্টা সফল

এই মেট্রিক এসেছে কোড-জেনারেশনের মূল্যায়ন থেকে। এটি উত্তর দেয় «কয়েকটি চেষ্টা দিলে সিস্টেম কাজটি মূলত পারে কি না»। যেখানে মানুষ কয়েকটি বিকল্পের সেরাটি বাছে, অথবা যেখানে নির্ভরযোগ্য স্বয়ংক্রিয় যাচাই খারাপ ফলগুলো বাতিল করে, সেখানে এটি সৎ মেট্রিক।

pass^k: k-এর সব চেষ্টা সফল

এই মেট্রিক অন্য প্রশ্নের উত্তর দেয়: «এজেন্ট কাজটি কতটা স্থিরভাবে করে»। এটি তদারকি ছাড়া চলা কাজের মাপ, যেখানে এজেন্ট বহুবার চলে এবং প্রতিটি ব্যর্থতার খরচ টাকা বা সময়।

দুটির পার্থক্য বিশাল। ধরা যাক এজেন্ট এক চেষ্টায় একটি কাজ ৭০% সম্ভাবনায় সমাধান করে, এবং চেষ্টাগুলো স্বাধীন:

pass@5 দেখে এজেন্টকে প্রায় নিখুঁত মনে হয়, pass^5 দেখে অনির্ভরযোগ্য। দুটি সংখ্যাই ঠিক, শুধু ভিন্ন জিনিস বর্ণনা করে। আপনি যদি এজেন্টকে স্বাধীনভাবে কাজ করতে দিতে চান, pass^k দেখুন: বাস্তব কাজে আপনি যা দেখবেন, সেটির কাছাকাছি এটি।

হাতে-কলমে গণনা

প্রতিটি কাজ n বার চালান (যেমন 5) এবং সফলতার সংখ্যা c লিখুন। pass^k আনুমানিকভাবে সেই চালনার ভাগ, যেখানে k-টি একটানা সবই সফল; সহজ উপায় হলো সফলতার সম্ভাবনা p = c / n ধরে তাকে ঘাতে তোলা। কাজের সেটের জন্য কাজগুলোর গড় নিন।

import json
from statistics import mean

# results.jsonl: {"task": "add-pagination", "runs": [true, true, false, true, true]}
rows = [json.loads(line) for line in open("results.jsonl")]

def pass_at_k(runs, k):
    p = sum(runs) / len(runs)
    return 1 - (1 - p) ** k

def pass_pow_k(runs, k):
    p = sum(runs) / len(runs)
    return p ** k

for k in (1, 3, 5):
    print(k,
          round(mean(pass_at_k(r["runs"], k) for r in rows), 3),
          round(mean(pass_pow_k(r["runs"], k) for r in rows), 3))

p-এর ঘাতে হিসাবটি কম n-এ মোটা, কিন্তু হারনেসের দুটি সংস্করণের তুলনায় সাধারণত যথেষ্ট। আরও গুরুত্বপূর্ণ: তুলনার মাঝখানে n এবং কাজের সেট বদলানো চলবে না।

মূল্যায়নের কাজের সেট কীভাবে বানাবেন

কাজের সেট হলো প্রধান সম্পদ। ভালো মেট্রিকও খারাপ কাজের ওপর হলে ভুল জিনিস মাপে।

নিজের বাস্তবতা থেকে কাজ নিন

SWE-bench-এর মতো পাবলিক বেঞ্চমার্ক মডেল তুলনার জন্য কাজে লাগে, কিন্তু তার কাজগুলো বাছাই করা: স্পষ্ট বিবরণ, তৈরি টেস্ট। আপনার রিপোজিটরিতে প্রয়োজনীয়তা অস্পষ্ট, কোথাও টেস্টই নেই, তাই বেঞ্চমার্কের সংখ্যা প্রায় সবসময় আপনার এজেন্টের বাস্তব ফলের চেয়ে বেশি দেখায়। সবচেয়ে ভালো উৎস: বন্ধ হওয়া টিকেট এবং লগে জমা এজেন্টের আসল ব্যর্থতা।

সেটের গঠন

• শুরুতে ২০–৫০টি কাজ। কম হলে শব্দ (noise) সংস্করণের পার্থক্য খেয়ে ফেলে। বেশি হলে চালানো দামি হয়, আর তা কেউ আর চালাতে চায় না।
• বিভিন্ন ধরন: নতুন ফিচার, বাগ ঠিক করা, রিফ্যাক্টর, অন্যের মডিউলে কাজ, আর ফাঁদের কাজ (যেখানে সঠিক উত্তর «এভাবে করা যাবে না» বা «স্পষ্টীকরণ দরকার»)।
• কাজে ব্যর্থ হওয়া প্রতিটি কাজ একটি টেস্ট হয়ে যায়। এভাবে সেট বাড়ে এজেন্ট কোথায় দুর্বল তার বোঝার সঙ্গে, এবং রিগ্রেশন অলক্ষ্যে ফিরে আসে না।
• স্থির শুরুর অবস্থা: নির্দিষ্ট কমিট, আটকানো নির্ভরতা, একই পরিবেশ। নইলে আপনি এজেন্ট নয়, পরিবেশের বিচ্যুতি মাপছেন।

কাজের ফরম্যাট

প্রতিটি কাজ হলো একটি বিবরণ, একটি শুরুর অবস্থা এবং এমন একটি সাফল্যের মানদণ্ড, যা মানুষ ছাড়া যাচাই করা যায়।

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  GET /payments-এ পেজিনেশন যোগ করো: পরামিতি limit (ডিফল্ট 20, সর্বোচ্চ 100)
  এবং cursor। উত্তরে থাকবে next_cursor।
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

লক্ষ করুন: সাফল্যের মানদণ্ড হলো Definition of Done, যা কমান্ড দিয়ে লেখা। কোনো কাজের মানদণ্ড লেখা না গেলে সেটি সংকেত যে এজেন্টকে কাজটি অস্পষ্টভাবে দেওয়া হয়েছে।

স্বয়ংক্রিয় যাচাই, নাকি LLM-বিচারক

ফলাফল কোড দিয়েও যাচাই করা যায়, অন্য একটি মডেল দিয়েও। প্রতিটি উপায়ের নিজস্ব এলাকা আছে।

নিয়ম: আগে কোড, বিচারক তার ওপরে

যা নির্ধারকভাবে যাচাই করা যায়, তা নির্ধারকভাবেই যাচাই করুন। LLM-বিচারককে শুধু সেই বৈশিষ্ট্যের জন্য যোগ করুন যা কোড প্রকাশ করতে পারে না, এবং কখনো টেস্টের বদলে নয়।

LLM-বিচারককে কার্যকর করার উপায়

• জেনারেটর থেকে আলাদা প্রসঙ্গ। বিচারক এজেন্টের যুক্তি দেখবে না, শুধু কাজ, মানদণ্ড ও চূড়ান্ত diff দেখবে। নইলে সে একই ভুল পুনরাবৃত্তি করবে। এটিই স্বাধীন দুই দৃষ্টিভঙ্গি, একটির বদলে।
• ১০-বিন্দুর স্কেলের বদলে রুব্রিক। হ্যাঁ/না উত্তরের নির্দিষ্ট প্রশ্ন: «limit > 100-এর জন্য যাচাই আছে কি?», «app/payments-এর বাইরের ফাইল বদলেছে কি?»।
• হাতে-লেখা লেবেল দিয়ে ক্যালিব্রেশন। ২০–৩০টি ফল হাতে চিহ্নিত করে বিচারকের রায়ের সঙ্গে মেলান। মিল কম হলে রুব্রিক বদলান, বিচারককে আরও বিশ্বাস করবেন না।
• ভুলের অসমতা। ভুল «হয়ে গেছে» ভুল «হয়নি»-র চেয়ে দামি: প্রথমটি উৎপাদনে চলে যায়, দ্বিতীয়টির খরচ একবার পুনরায় চালানো। সন্দেহ হলে বিচারক যেন প্রত্যাখ্যান করে, সেভাবে সেট করুন।

সফলতার হার ছাড়া কোন মেট্রিক গুনবেন

সমাধান হওয়া কাজের হার শুধু উপরের স্তর। কোথায় ঠিক করতে হবে তা জানতে ক্লাসিক্যাল ইঞ্জিনিয়ারিংয়ের নির্ভরযোগ্যতা-মেট্রিক লাগে।

• MTBF — এজেন্ট আটকানোর আগে কতগুলো ধাপ বা কাজ পার করে। দেখায় সে কত বিরল ভাঙে।
• MTTR — ব্যর্থতার পরে কার্যকর অবস্থায় ফিরতে কত সময় লাগে। এটি কমানো প্রায় সবসময় MTBF বাড়ানোর চেয়ে সস্তা: ভালো অগ্রগতি-ফাইল ও পুনরুৎপাদনযোগ্য পরিবেশ পুনরুদ্ধার কয়েক গুণ দ্রুত করে।
• ক্ষতির ব্যাসার্ধ — একটি ব্যর্থ ধাপ কতটুকু কোড নষ্ট করে। diff-সীমা ও কার্যকরী কপির বিচ্ছিন্নতা দিয়ে একে আটকানো হয়।
• মিথ্যা «হয়ে গেছে»-র হার — যে কাজে এজেন্ট সফলতা ঘোষণা করেছে, কিন্তু যাচাই ফেল করেছে। এটি সবচেয়ে বিপজ্জনক মেট্রিক: এজেন্টের রিপোর্ট বিশ্বাস করা যায় কি না, তা এটিই দেখায়।
• খরচ ও সময় — কাজ প্রতি টোকেন ও মিনিট। যে হারনেস সফলতা ৫% বাড়ায় কিন্তু খরচ দ্বিগুণ করে, সে সবসময় জেতে না।

ব্যর্থতার লগ: প্রতিদিনের কাজ থেকে evals

সবাই তৎক্ষণাৎ মাপার ব্যবস্থা বানাতে পারে না। ন্যূনতম সংস্করণ হলো তিন কলামের ব্যর্থতার লগ।

| কাজ                     | ফলাফল                              | স্তর          |
|-------------------------|------------------------------------|---------------|
| /payments-এ পেজিনেশন    | «হয়ে গেছে», 2টি টেস্ট লাল         | যাচাই         |
| webhook-এর টাইমআউট ঠিক  | pip install-এ 30 মিনিট             | পরিবেশ        |
| refunds রিফ্যাক্টর      | পুরনো ORM সিনট্যাক্স                | প্রসঙ্গ       |

স্তর মানে এজেন্ট যে পাঁচটি জায়গায় ভাঙে তার একটি: কাজের বিবরণ, প্রসঙ্গ, চালানোর পরিবেশ, যাচাইয়ের ফিডব্যাক, অবস্থা ব্যবস্থাপনা। বিশটি লেখার পরে আসল বাধা কোথায় তা দেখা যায়, এবং প্রায় কখনোই সেখানে নয় যেখানে আপনি ভেবেছিলেন। লগের প্রতিটি লাইন evals-এর কাজের সেটের সম্ভাব্য প্রার্থী।

কেন শক্তিশালী মডেলও যথেষ্ট নয়

এজেন্টের ব্যর্থতায় প্রথম প্রতিক্রিয়া: দামি মডেল নেওয়া। কখনো এটি সাহায্য করে, কিন্তু প্রায়ই বেঞ্চমার্ক ও আপনার বাস্তবতার মধ্যের ফাঁক বন্ধ করে মডেল নয়, তার চারপাশের পরিবেশ।

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

Evals দিয়ে এটি সৎভাবে যাচাই করা যায়। বর্তমান মডেল দিয়ে সেট চালান, তারপর দামি মডেল দিয়ে; তারপর বর্তমান মডেল আর AGENTS.md-তে যাচাই-কমান্ড যোগ করে। প্রায়ই দ্বিতীয় বদলটি প্রথমটির চেয়ে বেশি লাভ দেয়, শূন্য খরচে। তবে কথাটি শুধু বিশ্বাস করবেন না: এই ধরনের তুলনার জন্যই সেট দরকার।

এক সপ্তাহের পরিকল্পনা: AI এজেন্ট মূল্যায়ন

1. দিন ১। ব্যর্থতার লগ খুলুন এবং এজেন্টের প্রতিটি ব্যর্থতা স্তরসহ লিখুন।
2. দিন ২। বন্ধ টিকেট ও লগ থেকে ২০টি কাজ বাছুন। প্রতিটির জন্য কমিট ঠিক করুন এবং সাফল্যের মানদণ্ড কমান্ড দিয়ে লিখুন।
3. দিন ৩। একটি রানার লিখুন: পরিষ্কার কার্যকরী কপি, এজেন্টকে কাজের প্রম্পট দিয়ে চালানো, যাচাই চালানো, ফল JSONL-এ লেখা।
4. দিন ৪। প্রতিটি কাজ ৩–৫ বার চালান। pass@1, pass^3, মিথ্যা «হয়ে গেছে»-র হার, গড় খরচ গুনুন।
5. দিন ৫। হারনেসের একটি জিনিস বদলান এবং আবার চালান। শুধু একই সেট ও একই পুনরাবৃত্তি-সংখ্যায় তুলনা করুন।

একবারে একটি পরিবর্তনশীল বদলান। একটি পরীক্ষায় মডেল, প্রম্পট ও টুল একসঙ্গে বদলালে বুঝবেন না কোনটি কাজ করেছে।

মূল্যায়নে সাধারণ ভুল

• প্রতি কাজে একবার চালানো। এজেন্টের নির্ধারকহীনতার কারণে ফল লটারির মতো হয়। অন্তত তিনবার চালান।
• তুলনার মাঝখানে সেট বদলানো। নতুন কাজ যোগ করলেন এবং একই সঙ্গে প্রম্পটও বদলালেন, তখন সংখ্যাগুলো তুলনীয় থাকে না।
• এজেন্ট যাচাই-টেস্ট দেখতে পাচ্ছে। টেস্ট রিপোজিটরিতে থাকলে এজেন্ট কোড সেগুলোর সঙ্গে মানিয়ে নিতে পারে, বা টেস্টই বদলে ফেলতে পারে। গোপন যাচাই কার্যকরী কপির বাইরে রাখুন এবং যাচাই করুন এজেন্ট টেস্ট ফাইল ছোঁয়নি।
• যাচাইয়ের বদলে এজেন্টের রিপোর্ট। মডেলের উত্তরে «সব টেস্ট পাস করেছে» কোনো ফল নয়। ফল হলো রানারের চালানো কমান্ডের রিটার্ন কোড।
• শুধু pass@k। উপস্থাপনার জন্য সুন্দর সংখ্যা, কিন্তু স্বাধীন কাজের জন্য দুর্বল পূর্বাভাস।

সংক্ষেপে

AI এজেন্ট মূল্যায়ন মানে স্থির বাস্তব কাজের সেট, স্বয়ংক্রিয় যাচাই এবং মেট্রিক, যা হারনেসের প্রতিটি বদলের পরে আবার গণনা হয়। pass@k দেখায় এজেন্ট কী পারে, pass^k দেখায় তাকে তদারকি ছাড়া বিশ্বাস করা যায় কি না। স্বয়ংক্রিয় যাচাই সত্যি বলে, রুব্রিকসহ আলাদা প্রসঙ্গের LLM-বিচারক সেখানে যোগ দেয় যেখানে কোড অক্ষম। আর ব্যর্থতার লগ দেখায় আগে কী ঠিক করতে হবে, এবং বেশিরভাগ সময় সেটি মডেল নয়। মূল্যায়ন ও নির্ভরযোগ্যতার মেট্রিক এবং ডায়াগনস্টিক লুপ কোর্সে একটি বাস্তব প্রকল্পের উদাহরণে বিস্তারিত দেখানো হয়েছে।