Fable 5, Opus 4.8 এবং Sonnet 4.6: নিজের কোডে LLM-গুলোকে কীভাবে সৎভাবে তুলনা করবেন

যখন একটি নতুন মডেল আসে, ঘোষণাটি উত্তর দেয় «বেঞ্চমার্কে এটি কতটা ভালো» — কিন্তু আমার একমাত্র প্রশ্নের উত্তর দেয় না: এটি আমার কাজে কী বদলাবে। আমি একটি নিয়ন্ত্রিত পরীক্ষা করেছি: তিনটি Claude মডেল — Fable 5, Opus 4.8 এবং Sonnet 4.6 — এই ব্লগের কোডবেস অডিটের জন্য হুবহু একই কাজ পেয়েছে, প্রতিটি রিপোজিটরির আলাদা কপিতে, আগে থেকে সম্মত মূল্যায়ন রুব্রিকসহ। নিবন্ধে — পদ্ধতিটি নিজেই, যা যেকোনো প্রকল্পে পুনরাবৃত্তি করা যায়, ফলাফল, এবং আলাদাভাবে — পরীক্ষাটি কীভাবে দুইবার ভেঙে পড়েছিল এবং এটি কী শিখিয়েছে।

কেন বেঞ্চমার্ক আমার প্রশ্নের উত্তর দেয় না

পাবলিক বেঞ্চমার্কের দুটি সমস্যা, এবং দুটোই মৌলিক। প্রথমটি — ডেটা দূষণ: পরীক্ষার উদাহরণগুলো প্রশিক্ষণ সেটে চুইয়ে পড়ে, এবং মডেল আংশিকভাবে উত্তরগুলো «মনে করে» কাজটি সমাধান করার বদলে। এটি প্রান্তিক সন্দেহ নয়, বরং একটি সম্পূর্ণ গবেষণা ক্ষেত্রের বিষয়: Xu এবং সহলেখকদের পর্যালোচনা (2024) বেঞ্চমার্ক দূষণ গবেষণাকে পদ্ধতিগত করে, এবং EMNLP 2025 পর্যালোচনা শিল্পের প্রতিক্রিয়া নথিভুক্ত করে — স্ট্যাটিক পরীক্ষা থেকে গতিশীলভাবে উৎপন্ন পরীক্ষায় переход।

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

এখান থেকে একটি সহজ চিন্তা আসে: মডেল তুলনার জন্য সেরা পরীক্ষার মঞ্চ — নিজের প্রকল্প। এর কোড এই ধরনের সমন্বয়ে প্রশিক্ষণ সেটে নেই, এর কাজগুলো ঠিক সেগুলোই যেগুলোর জন্য আমি টাকা দিই, এবং ফলাফল আমি হাতে যাচাই করতে পারি, কারণ আমি এই কোড জানি।

পরীক্ষার নকশা: একটি প্রম্পট, তিনটি বিচ্ছিন্ন জগৎ

তিনটি মডেলের জন্য কাজটি হুবহু একই ছিল — শুধু ব্রাঞ্চের নাম এবং ফলাফলের ফোল্ডার আলাদা। চারটি ধাপ: ব্লগের দ্বিভাষিক নিবন্ধ ব্যবস্থার অডিট, প্রতিটি অনুসন্ধানের প্রমাণ файл:строка সহ কোড উদ্ধৃতিসহ; তিনটি প্রধান অনুসন্ধানের জন্য সমাধান নির্বাচন, আপসগুলোর বর্ণনাসহ; একটি ফিক্সের বাস্তবায়ন স্ব-যাচাইসহ; রুশ ও ইংরেজিতে ফলাফলের নোট। সম্পূর্ণ ইঞ্জিনিয়ারিং কাজের চক্র, বিচ্ছিন্ন «প্রশ্ন-উত্তর» নয় — এই পদ্ধতি Anthropic-ও সুপারিশ করে: বাস্তব পণ্যের কাজে এজেন্টদের মূল্যায়ন করুন, চালুর আগে সম্মত রুব্রিক অনুযায়ী।

তিনটি নিয়ম তুলনাটিকে সৎ করেছে:

বিচ্ছিন্নতা। প্রতিটি মডেল আলাদা git worktree -তে কাজ করেছে — নিজস্ব ব্রাঞ্চসহ কার্যকরী ডিরেক্টরির নিজস্ব কপি। মডেলগুলো শারীরিকভাবে একে অপরের ফলাফল দেখতে বা একে অপরকে বাধা দিতে পারত না।

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

সংকেতগুলোকে স্কোর থেকে বাদ দেওয়া। রিপোজিটরিতে CLAUDE.md আছে, যেখানে প্রকল্পের পরিচিত ফাঁদগুলো বর্ণিত — যেমন অ্যাসেটের আপেক্ষিক পাথ, যা ভাষা-প্রিফিক্সযুক্ত URL-এ ভেঙে পড়ে। তিনটি মডেলই এই ফাইল পড়ে, তাই এমন অনুসন্ধান «বিনামূল্যে»: সেগুলো নির্ভুলতার জন্য গণনা হয়, গভীরতার জন্য নয়।

রুব্রিক: শুধু হাতে যাচাইযোগ্য জিনিস মূল্যায়ন করুন

চালুর আগে আমি পাঁচ পয়েন্টে ছয়টি অক্ষ স্থির করেছি: অডিটের নির্ভুলতা (অনুসন্ধানের নমুনার হাতে যাচাই файл:строкаঅনুযায়ী), গভীরতা (সংকেতে নেই এমন নিশ্চিত অনুসন্ধান), আপস নিয়ে যুক্তির গুণমান, কোড এবং স্ব-যাচাইয়ের বাস্তবতা, রুশ ও ইংরেজি পাঠের গুণমান, শৃঙ্খলা (মানুষের কাছে শূন্য প্রশ্ন, সীমাবদ্ধতার একটিও লঙ্ঘন নয়)। নীতিটি ভালো কোড-রিভিউয়ের মতোই: অক্ষটি যত কম রুচির উপর এবং যত বেশি যাচাইযোগ্য তথ্যের উপর নির্ভর করে, তত বেশি তাকে বিশ্বাস করা যায়।

প্রথমবার কীভাবে সব ভেঙে পড়ল

প্রথম চালুটি আমি ভুলভাবে করেছিলাম — এবং এটিই পরীক্ষার সবচেয়ে বহনযোগ্য অংশ হয়ে উঠল। আমি একই রিপোজিটরি ফোল্ডারে সমান্তরালে তিনটি ইন্টারঅ্যাকটিভ সেশন খুলেছিলাম। কয়েক মিনিটের মধ্যে কার্যকরী ট্রি-তে আনকমিটেড পরিবর্তন পড়ে ছিল যা চিহ্নিত করা অসম্ভব ছিল: শেয়ার্ড checkout মানে যখন একটি সেশন git checkout -bকরে, ব্রাঞ্চ তিনটির জন্যই বদলে যায়, এবং তাদের পরিবর্তন ও কমিটগুলো মিশে যায়। একটি সেশন উপরন্তু git stash করেছে এবং তাতে সবকিছু ঝেঁটিয়ে নিয়েছে — আমার নিজের ফাইলসহ, যা পরীক্ষার সাথে সম্পর্কিত ছিল না।

“একই ফোল্ডারে সমান্তরাল AI-এজেন্ট মানে সমান্তরাল পরীক্ষা নয়। এটি তিনজন লেখকের সাথে একটি বড় সংঘাত।”

– যে উপসংহারটি আমাকে পুনরায় চালু করতে খরচ করিয়েছে

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

ফলাফল: কোথায় মডেলগুলো একই এবং কোথায় আলাদা

সবচেয়ে গুরুত্বপূর্ণ ফলাফল — যা ঘটেনি: কোনো মডেলেরই হ্যালুসিনেশন নেই. আমি প্রত্যেকের তিন বা তার বেশি আবিষ্কার হাতে যাচাই করেছি — সব উদ্ধৃতি ও লাইন নম্বর অক্ষর পর্যন্ত নির্ভুল। অডিট কাজের জন্য এটি আস্থার প্রধান সীমা, এবং তিনজনই তা পেরেছে।

এরপর শুরু হয় পার্থক্য:

	Fable 5	Opus 4.8	Sonnet 4.6
নিশ্চিত আবিষ্কার	11	5	9
অতুচ্ছ নয় এমন অনন্য	3	1	2
ফিক্সের স্ব-যাচাই	অস্থায়ী ডেটাবেসে ইন্টিগ্রেশন রেন্ডার, xmllint, অন্যের ব্যর্থ টেস্টের অ্যাট্রিবিউশন	লিন্টার + রেন্ডার; নিজের বাগ ধরেছে	শুধু লিন্টার এবং রুটের তালিকা
টোকেন / সময়	164k / 21 মিনিট	101k / 12 মিনিট	131k / 12 মিনিট
রুব্রিক অনুযায়ী মোট (30-এর মধ্যে)	30	24	25,5

গুণগত পার্থক্য স্কোরের চেয়ে বেশি তথ্যবহ। Opus 4.8 — একমাত্র যে sitemap-এ ভাঙা শিরোনাম Content-Type লক্ষ্য করেনি (অন্য দুটি তা পেয়েছে) এবং নিজের ফিক্সেও তা রেখে দিয়েছে; আর তার রুশ টেক্সটে ইংরেজি শব্দ ঢুকে পড়েছে — «и even путь к картинке»। Sonnet 4.6 সঠিক ফিক্স করেছে, কিন্তু তার স্ব-যাচাই ছিল ঘোষণামাত্র: চালানোর বদলে লিন্টার। Fable 5 স্ব-যাচাইয়েই আলাদা হয়েছে: আবিষ্কার করেছে যে php আমার মেশিনে মূল ডিরেক্টরিতে মাউন্ট করা docker-কন্টেইনারের একটি র‍্যাপার, এককালীন কন্টেইনারের মাধ্যমে সব যাচাই পুনর্গঠন করেছে এবং অস্থায়ী ডেটাবেসে তার ফিক্স ইন্টিগ্রেশনভিত্তিক চালিয়েছে। "আমি করেছি" আর "আমি প্রমাণ করেছি যে করেছি"-র মধ্যে পার্থক্যই এজেন্টিক কাজের সবচেয়ে বৈষম্যমূলক অক্ষ।

আরেকটি উপকারী সংকেত — অভিসৃতি: তিনটি মডেলই স্বতন্ত্রভাবে sitemap-এর একই সমস্যাকে প্রধান আবিষ্কার হিসেবে চিহ্নিত করেছে। যখন স্বতন্ত্র নিরীক্ষকরা শীর্ষ-আবিষ্কারে একমত হন, এটি আন্তঃ-বিশেষজ্ঞ সম্মতির একটি সস্তা সমতুল্য: সমস্যাটি প্রায় নিশ্চিতভাবেই বাস্তব।

অংশগ্রহণকারীদের মধ্য থেকে বিচারক

রুব্রিক অনুযায়ী মূল্যায়ন করেছেন Fable 5 — তুলনায় অংশগ্রহণকারী একই মডেল। এটি একটি পদ্ধতিগত ফাঁক, এবং এটি সরাসরি বলা উচিত: LLM-বিচারকরা পদ্ধতিগতভাবে নিজেদের লেখাকে বেশি নম্বর দেয়, এবং এই প্রবণতা ততই প্রবল হয় যত ভালোভাবে মডেল নিজের লেখা চিনতে পারে — এটি দেখানো হয়েছে Panickssery ও সহযোগীদের NeurIPS 2024-এর কাজে. পক্ষপাত প্রশমিত করার দুটি উপায় আছে, এবং আমি দুটোই ব্যবহার করেছি: প্রথমত, রুব্রিককে যতটা সম্ভব রুচির অক্ষ থেকে যাচাইযোগ্য তথ্যের দিকে সরিয়েছি — লাইনের নির্ভুলতা, ফিক্সের সম্পূর্ণতা, অনুপ্রবেশ করা বিদেশি শব্দ বিচারকের পছন্দের উপর নির্ভর করে না; দ্বিতীয়ত, দ্বন্দ্ব স্পষ্টভাবে ঘোষণা করা এবং বিতর্কিত অক্ষগুলো অন্য মডেল বা মানুষের ক্রস-যাচাইয়ে দেওয়া। আমার চূড়ান্ত ফলের বিষয়ভিত্তিক অক্ষগুলো — টেক্সটের গুণমান, যুক্তির গুণমান — এই সংশোধনসহ পড়া উচিত।

সততার সীমাবদ্ধতা

প্রতি মডেলে একটি রান মানে n=1: এক-দুই পয়েন্টের পার্থক্যের কোনো অর্থ নেই, শুধু গুণগত ব্যবধানেই আস্থা রাখা উচিত — মিস করা বাগ, স্ব-যাচাইয়ের গভীরতা। পরীক্ষাটি একটি ডোমেইনে একটি কাজে তিনটি মডেল পরিমাপ করে; «Fable 5 সামগ্রিকভাবে ভালো» এটি থেকে অনুসৃত হয় না। আর খরচের কথা মনে রাখা উচিত: শীর্ষ মডেল সবচেয়ে মিতব্যয়ী অংশগ্রহণকারীর চেয়ে ১.৬ গুণ বেশি টোকেন এবং প্রায় দ্বিগুণ সময় ব্যয় করেছে, আর তার টোকেনের দাম নিজেও বেশি — নিয়মিত কাজের জন্য এটি সহজ মডেলের পক্ষে একটি ভারী যুক্তি।

আমি নিজের জন্য যা নিচ্ছি

পদ্ধতিটি একটি সংক্ষিপ্ত চেকলিস্টে দাঁড়িয়েছে, যা যেকোনো প্রকল্প ও যেকোনো মডেলের জন্য কাজ করে:

• পরীক্ষামূলক কাজ — নিজের কোডে বাস্তব কাজের পূর্ণ চক্র, কৃত্রিম সমস্যা নয়।
• সবার জন্য একটি প্রম্পট, আলাদা worktree-এর মাধ্যমে বিচ্ছিন্নতা, ফলাফল — আলাদা ব্র্যাঞ্চে।
• প্রম্পটে হ্যালুসিনেশনের স্পষ্ট মূল্য: বানানো আবিষ্কার আবিষ্কার না থাকার চেয়ে খারাপ।
• সবার জন্য উপলব্ধ সংকেত (ডকুমেন্টেশন, রিপোজিটরির নোট) গভীরতার হিসাব থেকে বাদ।
• রুব্রিক চালুর আগে নির্ধারিত হয় এবং যাচাইযোগ্য তথ্যের উপর নির্ভর করে, ছাপের উপর নয়।
• আবিষ্কারের নমুনা হাতে যাচাই করা; স্বতন্ত্র মডেলদের শীর্ষ-আবিষ্কারের মিল তাদের বাস্তবতার সংকেত।
• বিচারক-অংশগ্রহণকারী — ঘোষিত দ্বন্দ্ব: বিতর্কিত অক্ষগুলো ক্রস-মূল্যায়নে দেওয়া।
• এজেন্টের সজীবতা ডিস্ক দিয়ে যাচাই করা, ইন্টারফেসের ইন্ডিকেটর দিয়ে নয়।

পরিকল্পনায় না থাকা বোনাস: পরীক্ষাটি নিজেই নিজের খরচ উঠিয়ে নিয়েছে। তিনটি স্বতন্ত্র অডিট ব্লগে বাস্তব সমস্যা পেয়েছে — ইংরেজি পৃষ্ঠাহীন sitemap থেকে কন্ট্রোলারে মৃত কোয়েরি পর্যন্ত — এবং দুটি প্রস্তুত ফিক্স ইতিমধ্যে ব্র্যাঞ্চে প্রোডাকশনে স্থানান্তরের অপেক্ষায় আছে। বেঞ্চমার্ক পড়ার বিপরীতে নিজের কোডে মডেল তুলনা শুধু মতামত রেখে যায় না।

উৎস ও দিকনির্দেশনা

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — বেঞ্চমার্ক দূষণ সমস্যার পদ্ধতিগতকরণ; নিজের কোডে পরীক্ষার পক্ষে প্রধান যুক্তি।
• ডেটা কনটামিনেশনের অধীনে LLM-দের বেঞ্চমার্কিং: স্ট্যাটিক থেকে ডাইনামিক মূল্যায়ন (EMNLP 2025) — কীভাবে শিল্প স্ট্যাটিক টেস্ট থেকে ডাইনামিক টেস্টের দিকে যাচ্ছে; আমার পরীক্ষা ডাইনামিক টেস্টের একটি বিশেষ উদাহরণ।
• AI এজেন্টদের জন্য eval-গুলোকে সহজবোধ্য করা (Anthropic Engineering, 2026) — এজেন্ট মূল্যায়নের অনুশীলন: বাস্তব পণ্যের কাজ, যাচাইযোগ্য রুব্রিক, ট্র্যাজেক্টরি ও ফলাফলের পার্থক্য।
• LLM মূল্যায়নকারীরা তাদের নিজস্ব জেনারেশন চিনতে পারে এবং পছন্দ করে (NeurIPS 2024) — কেন বিচারক মডেল নিজেকে বেশি নম্বর দেয় এবং এ নিয়ে কী করা উচিত।
• ওয়ার্কট্রি দিয়ে সমান্তরাল সেশন চালান (Claude Code Docs) — সমান্তরাল এজেন্ট সেশন আলাদা রাখার প্রমিত ব্যবস্থা, যা ছাড়া পরীক্ষার প্রথম রানই ভেঙে পড়েছিল।