GitHub ReviewBench-এ ২১৯ pull request—score নয়, ভুল মন্তব্যও মাপবে

৫ অক্টোবর ২০২৬ GitHub ReviewBench-এর গবেষণা পর্যায়ের সংস্করণ প্রকাশ করে: ১৮৭টি উন্মুক্ত রিপোজিটরির ১৯ ভাষার ২১৯টি পুল রিকোয়েস্টে এআই কোড রিভিউ এজেন্টের সমস্যা শনাক্ত করা ও ভুল মন্তব্য করার প্রবণতা আলাদাভাবে মাপা যায়। নমুনার ধরন ঠিক করতে প্রতিষ্ঠানটি ১০ কোটি ৩৯ লাখ পুল রিকোয়েস্টের বণ্টন বিশ্লেষণ করেছে; ওই বড় সংখ্যাটি পরীক্ষার ডেটাসেটের আকার নয়।

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

নমুনা কেন দৈনন্দিন রিভিউয়ের হুবহু প্রতিচ্ছবি নয়

ReviewBench ভাষা ও রিপোজিটরির আকারের বণ্টন GitHub-এর সামগ্রিক ব্যবহারের কাছাকাছি রেখেছে। কিন্তু পরিবর্তনের আকারে মাঝারি ও বড় পুল রিকোয়েস্টকে ইচ্ছাকৃতভাবে বেশি গুরুত্ব দিয়েছে, যাতে ছোট এক ফাইলের সম্পাদনাই পরীক্ষার ফল নিয়ন্ত্রণ না করে। এতে একাধিক ফাইলের সম্পর্ক বুঝে মন্তব্য করা এজেন্টকে যাচাই করার সুযোগ বাড়ে। যেসব দলে কাজের বড় অংশ ক্ষুদ্র পরিবর্তন, তাদের রিভিউয়ের ধরন এই নমুনায় সমানভাবে প্রতিফলিত হবে ধরে নেওয়া ঠিক নয়।

সমস্যার রেফারেন্স তালিকা গড়তে বাস্তব মানব পর্যালোচকের মন্তব্য, লেখকের পরবর্তী সংশোধন থেকে অনুমিত সমস্যা, নির্ধারিত নিয়মে চলা বিশ্লেষণী সরঞ্জাম এবং একাধিক মডেল পরিবারের পর্যবেক্ষণ নেওয়া হয়েছে। একই মূল সমস্যার পুনরাবৃত্ত বর্ণনা এক করা হয়। তারপর একটি মন্তব্য সত্য, সংশ্লিষ্ট পরিবর্তনের সঙ্গে প্রাসঙ্গিক এবং তুচ্ছ নয় কি না, অভিন্ন নিয়মে বিচার করা হয়। ফলে মানুষের লেখা মন্তব্যও শুধু তার উৎসের কারণে স্বয়ংক্রিয়ভাবে সঠিক ধরা হয় না।

বিচারক মডেল Claude Sonnet 5; রেফারেন্স সমস্যার সত্য-মিথ্যা নিয়ে বেঞ্চমার্ক নির্মাণে অংশ না নেওয়া জ্যেষ্ঠ প্রকৌশলীদের নতুন করে দেওয়া রায়ের সঙ্গে Conectado-এর প্রতিবেদনে উল্লেখিত মিল ছিল ৯৬.৬ শতাংশ। এটি রেফারেন্স তালিকার অভ্যন্তরীণ নিরীক্ষার ফল, কোনো রিভিউ এজেন্টের নির্ভুলতার হার নয়। একই বিচারক সব জমা দেওয়া মন্তব্য মূল্যায়ন করলে তুলনার নিয়ম এক থাকে, তবে বিচারকের ভুলও ফলকে প্রভাবিত করতে পারে।

প্রিসিশন ও রিকল আলাদা করলে ভুল মন্তব্য ধরা পড়ে

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

ReviewBench-এর গ্রাউন্ডেড মাপে প্রতিটি এজেন্টকে একই স্থির রেফারেন্স সমস্যার সঙ্গে তুলনা করা হয়। গ্রাউন্ডেড প্রিসিশন বলে তার মন্তব্যের কত অংশ পরিচিত সমস্যার সঙ্গে মিলে; গ্রাউন্ডেড রিকল বলে পরিচিত সমস্যার কত অংশ সে পেয়েছে। অগমেন্টেড মাপে রেফারেন্স তালিকার বাইরে ওঠা দাবিও সত্য-মিথ্যা বিচার করা হয়। তাতে নতুন বৈধ সমস্যা খুঁজে পাওয়া এজেন্টের কৃতিত্ব অগ্রাহ্য হয় না, কিন্তু অগমেন্টেড রিকলের ভিত্তি এজেন্টভেদে বদলায়। তাই সরাসরি তুলনার প্রধান রিকল মাপ হিসেবে স্থির ভিত্তিটিই বেশি উপযোগী।

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

Copilot পরীক্ষায় কোন ফল মিলেছে

Copilot code review-এর হালকা স্তরে একাধিক মডেলের স্বতন্ত্র রিভিউ একত্র করার একটি বিন্যাস পরীক্ষা করা হয়েছে। ReviewBench-এর অফলাইন মূল্যায়নে ওই বিন্যাসের প্রিসিশন, রিকল ও মন্তব্যের পরিমাণ বাড়ার এবং প্রতি রিভিউয়ের খরচ কমার দিক দেখা যায়। উৎপাদন পরিবেশের নিয়ন্ত্রিত তুলনায় প্রকাশিত পরীক্ষার বিশ্লেষণ অনুযায়ী মন্তব্যের পর কোড বদলানোর হার ৮ শতাংশ, রিকল প্রায় ১৩.৬ শতাংশ বেড়েছে এবং প্রতি রিভিউয়ের খরচ ৮ শতাংশ কমেছে। মন্তব্যের সংখ্যাও বেড়েছে। ফলটি ওই নির্দিষ্ট বহুমডেল বিন্যাসের সঙ্গে আগের একক রিভিউ বিন্যাসের তুলনা।

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

মন্তব্যের পরিমাণ হলো প্রতি রিভিউতে এজেন্ট কতটি দাবি পাঠায়; সঠিক মন্তব্য বাড়লেও প্রতিটি দাবি পড়া, মিলিয়ে দেখা এবং উত্তর দেওয়ার কাজ বাড়তে পারে। প্রতি রিভিউয়ের খরচ বোঝায় একটি পরিবর্তন পরীক্ষা চালাতে গড় ব্যয়, কিন্তু তাতে মানুষের যাচাইয়ের সময় স্বয়ংক্রিয়ভাবে ধরা পড়ে না। এ কারণেই কম মডেল ব্যয় ও বেশি মন্তব্য একসঙ্গে ঘটলে মোট কর্মপ্রবাহের লাভ জানতে আলাদা মানব সময়ের হিসাব প্রয়োজন।

মার্জের আগে দলের সীমা কোথায় বসবে

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

• গুরুতর সমস্যার জন্য ন্যূনতম রিকল স্থির করুন: জানা সমস্যার কত অংশ না ধরলে এজেন্ট গ্রহণযোগ্য হবে না।
• সব মন্তব্যে ন্যূনতম প্রিসিশন এবং প্রতি রিভিউতে সহনীয় মন্তব্যসংখ্যা ঠিক করুন; ভুল মন্তব্য যাচাইয়ের গড় মানব সময়ও লিখে রাখুন।
• প্রতি রিভিউয়ের মডেল ব্যয়ের সীমা নির্ধারণ করুন এবং তার সঙ্গে মানব যাচাইয়ের ব্যয় আলাদা করে মিলিয়ে দেখুন।
• সীমিত উৎপাদন পরীক্ষায় অ্যাড্রেসড রেটের পাশাপাশি পরে মানব পর্যালোচনায় পাওয়া গুরুতর মিস গুনুন।

এই সীমাগুলো ফল দেখার আগে ঠিক করলে শুধু পছন্দের এজেন্টের স্কোর অনুযায়ী শর্ত বদলানোর সুযোগ কমে। প্রকাশ্য পরীক্ষার রেফারেন্স তালিকা ও বিচারের নিয়ম দলকে তুলনার ভাষা দেয়; নিজস্ব মার্জ প্রক্রিয়ায় সিদ্ধান্তের জায়গায় থাকে বাস্তবে বাদ পড়া সমস্যা এবং মন্তব্য যাচাইয়ে মানুষের সময়।

আরও পড়ুন:

• Custom agent eval-এ trace গেলেও ভুল field দিলে score হবে না
• GitHub pull request খুঁজতে scroll নয়—AND, OR ও nested filter লিখুন
• Pull request-এ secret থাকলে merge বন্ধ—push protection-এর পরেও নতুন জাল