আমি দেখতে চেয়েছিলাম একই প্রশ্ন ৫১ বার করলে উত্তরটি আরও নির্ভরযোগ্য হবে কি না। আমি একটি লোকাল LLM নিয়েছিলাম, তাকে প্রোডাকশন কোডের একটি অংশ দিয়েছিলাম এবং একটি রিভিউ করতে বলেছিলাম। তারপর আমি এটি আবারও করলাম। বারবার। মোট ৫১ বার, এবং 'সেরা' উত্তরটি বেছে নিতে মেজরিটি ভোটিং (majority voting) ব্যবহার করলাম। ধারণাটি ছিল সহজ: মডেলটি যদি একবার কোনো ভুল করে, তবে ৫১টি জেনারেশনের সম্মিলিত জ্ঞান হয়তো সেই নয়েজ (noise) কাটিয়ে সঠিক বিশ্লেষণটি সামনে নিয়ে আসবে। কিন্তু বাস্তবে তা ঘটেনি। পরীক্ষাটি দেখিয়েছে যে মেজরিটি ভোটিং সঠিকতা বেছে নেয় না। এটি কেবল সেই বিষয়টিকে বেছে নেয় যে বিষয়ে মডেলটি সবচেয়ে বেশি জেদি।
এই পার্থক্যটি গুরুত্বপূর্ণ কারণ মেজরিটি ভোটিং বর্তমানে LLM পাইপলাইনে একটি জনপ্রিয় কৌশল (hack) হয়ে দাঁড়িয়েছে। এর পদ্ধতিটি খুব সহজ। আপনি একই প্রম্পটে মডেলটিকে কয়েকবার চালান, আউটপুটগুলো সংগ্রহ করেন এবং যে উত্তরটি সবচেয়ে বেশিবার আসে সেটি রেখে দেন। মেডিকেল ইমেজিং বা স্প্যাম ডিটেকশনের মতো ক্ষেত্রে এনসেম্বল মেথড (ensemble methods) কাজ করে কারণ বিভিন্ন মডেল বা ডেটার ভিন্ন ভিন্ন দৃষ্টিভঙ্গি এমন স্বাধীন ভুল (independent errors) তৈরি করে যা একে অপরকে বাতিল করে দিতে পারে। লার্জ ল্যাঙ্গুয়েজ মডেলগুলো স্বাধীন ভোটার নয়। তারা একটি একক সিস্টেম যার একটি নির্দিষ্ট ট্রেনিং হিস্ট্রি, এক সেট ওয়েটস (weights) এবং একগুচ্ছ বায়াস (biases) রয়েছে। যখন আপনি একই মডেলকে ৫১ বার একই প্রশ্ন করেন, তখন আপনি কোনো কমিটি ডাকছেন না। বরং আপনি সামান্য ভিন্ন মেজাজে থাকা একই উত্তরদাতার মতামত নিচ্ছেন।
স্থায়িত্বের সমস্যা
মূল সমস্যা হলো LLM-এর ভুলগুলো খুব কমই আকস্মিক বা র্যান্ডম হয়। এগুলো ট্রেনিং ডেটা এবং আর্কিটেকচারের মধ্যে গেঁথে থাকা কিছু প্যাটার্ন। একটি মডেল যদি একবার কোনো নির্দিষ্ট Python decorator ভুলভাবে পড়ে, তবে পরের বারও সেটি ভুল করার সম্ভাবনা প্রবল। একটি মডেল যদি ভ্যারিয়েবল নামটি পাসওয়ার্ডের মতো দেখতে বলে কোনো সিকিউরিটি ভালনারেবিলিটি (security vulnerability) কল্পনা করে (hallucinate), তবে সম্ভবত ৪৭তম বারও সেটি একই ভুল করবে। আপনি যে নয়েজ বা বিশৃঙ্খলা দূর করার চেষ্টা করছেন, তা সাধারণত শব্দচয়ন বা ফরম্যাটিংয়ের উপরিভাগের পরিবর্তন মাত্র। কিন্তু মূল যুক্তি বা রিজনিং (reasoning) প্রায়ই একই জায়গায় আটকে থাকে।
একটি বাস্তব উদাহরণ বিবেচনা করুন। মনে করুন একটি ফাংশন আছে যা রেগুলার এক্সপ্রেশন (regular expression) ব্যবহার করে লগ ফাইল পার্স (parse) করে। রেজেক্সটি (regex) কঠোর এবং নিরাপদ। কিন্তু r'...' স্ট্রিংটিতে এমন কিছু ক্যারেক্টার আছে যা ভিন্ন প্রেক্ষাপটে ইনজেকশন (injection) ঘটাতে পারে। একটি LLM-কে এটি রিভিউ করতে বলুন। যদি মডেলটি লগ পার্সারে রেজেক্স ইনজেকশন সম্পর্কে সতর্ক করা হাজার হাজার Stack Overflow পোস্ট দেখে থাকে, তবে এটি এই নিরাপদ কোডটিকেও ঝুঁকির হিসেবে চিহ্নিত করতে পারে। একবার চালালে আপনি একটি ফলস পজিটিভ (false positive) পাবেন। ৫১ বার চালালে বড় সম্ভাবনা আছে যে আপনি ৫১টিই ফলস পজিটিভ পাবেন, অথবা অন্তত একটি বিশাল সংখ্যাগরিষ্ঠতা পাবেন। মেজরিটি ভোটিং এখন সেই হ্যালুসিনেশনকেই (hallucination) আরও পাকাপোক্ত করে তোলে। মডেলটি জেদি, তাই তার 'ঐকমত্যও' (consensus) জেদি।
এটি ঘটে কারণ টেম্পারেচার (temperature) এবং স্যাম্পলিং ট্রিকস মডেলটি কী জানে তা পরিবর্তন করে না। এগুলো কেবল মডেলটি কীভাবে কথা বলছে তার বিন্যাস পরিবর্তন করে। উচ্চ টেম্পারেচার ব্যাখ্যাটিকে অনেক বেশি আলাপচারী বা সংক্ষিপ্ত করতে পারে। এটি সমার্থক শব্দ পরিবর্তন করতে পারে। কিন্তু এটি হঠাৎ করে মডেলটিকে শেখাতে পারে না যে রেজেক্সটি আসলে ক্ষতিকারক নয়। আপনি যে পরিবর্তনগুলোর ওপর ভোট দিচ্ছেন সেগুলো কেবল বাহ্যিক বা কসমেটিক (cosmetic); কিন্তু ভুলটি হলো কাঠামোগত (structural)।
৫১টি রান যা প্রকাশ করে
যখন আমি সেই ৫১টি আউটপুট আমার টেবিলের ওপর ছড়িয়ে দিলাম, প্যাটার্নটি স্পষ্ট হয়ে উঠল। মডেলটি কোডের ৫১টি ভিন্ন ভিন্ন ব্যাখ্যা খুঁজে বের করেনি। বরং এটি সামান্য ভিন্ন স্বরে একই ব্যাখ্যা বারবার আওড়ে গেছে। হাতেগোনা কয়েকটি রান মূল ধারা থেকে বিচ্যুত হয়েছিল, যেখানে এজ-কেস (edge-case) ফিক্স বা অপ্রাসঙ্গিক স্টাইল সংক্রান্ত সমস্যার কথা বলা হয়েছিল। কিন্তু প্রধান অংশ বা স্পষ্ট সংখ্যাগরিষ্ঠতা বারবার একই ভুল কেন্দ্রীয় দাবির দিকে ফিরে আসছিল। সেই দাবিটি সঠিক ছিল না; এটি কেবল পরিচিত ছিল।
মেজরিটি ভোটিংয়ের গণিত ধরে নেয় যে এগুলো স্বাধীন বার্নোলি ট্রায়াল (Bernoulli trials)। সংখ্যাগরিষ্ঠতা যাতে একক ফলাফলের চেয়ে ভালো করতে পারে, তার জন্য আপনার প্রয়োজন असंबंधित বা স্বাধীন ভুল। আমার পরীক্ষায় ভুলগুলো ছিল গভীরভাবে সম্পর্কিত। তাদের মূল কারণ ছিল একই: মডেলের ট্রেনিং ডিস্ট্রিবিউশন (training distribution) নির্দিষ্ট কিছু কোডিং ট্রোপকে (coding tropes) অতিরিক্ত গুরুত্ব দেয়। ফলে মেজরিটি ভোটিং ভুল কমায়নি, বরং সংখ্যাগরিষ্ঠতার বায়াসকে (majority bias) আরও বাড়িয়ে দিয়েছে। এটি একটি ত্রুটিপূর্ণ বিশ্লেষণের ওপর মিথ্যে নিশ্চয়তার অনুভূতি তৈরি করেছে।
কোড রিভিউয়ের ক্ষেত্রে এটি বিশেষভাবে বিপজ্জনক কারণ ডেভেলপাররা সর্বসম্মত বা প্রায় সর্বসম্মত AI আউটপুটকে চূড়ান্ত বা অথরিটেটিভ (authoritative) বলে ধরে নেন। একটি দ্বিধাগ্রস্ত পরামর্শ সহজেই এড়িয়ে যাওয়া যায়। কিন্তু ৫১টি রানেও যে সুপারিশটি একইভাবে বজায় থাকে, সেটি সত্য বলে মনে হয়। কিন্তু তা সত্য নয়। এটি আসলে একটি গ্রাউন্ড লুপ (ground loop)।
যেখানে ভোটিং আসলে কাজ করে
None of this means you should never run a model more than once. Majority voting can help in narrow situations where the task is shallow and the errors are truly random. Asking a model to pick between two syntactic formats, to choose a variable naming convention, or to extract a date string from a log line—these low-stakes tasks sometimes benefit from repeated sampling. The variation is genuine noise, and a quick vote cleans it up.
The trouble starts when the task requires reasoning about intent. Does this auth check belong here? Is this async call safe? Is this cache key collision actually exploitable? These questions demand an understanding of context, not just pattern matching. A model's pattern matcher is deterministic in its bias. It will reach for the most common answer from its training data, not the most accurate answer for your codebase.
Smarter Ways to Spend Your Compute
Fifty-one runs of a local model cost real time and electricity. There are better ways to invest that compute. If you want to improve reliability, diversity beats volume. Run two different models with