Saya ingin melihat apakah menjalankan pertanyaan yang sama sebanyak 51 kali akan membuat jawabannya lebih andal. Saya mengambil LLM lokal, memberinya potongan kode produksi, dan meminta tinjauan. Lalu saya melakukannya lagi. Dan lagi. Total lima puluh satu kali, menggunakan voting mayoritas untuk memilih respons "terbaik". Idenya sederhana: jika model tersandung pada satu kali jalan, mungkin kebijaksanaan kolektif dari 51 generasi akan meniadakan noise dan memunculkan analisis yang benar. Ternyata tidak demikian. Eksperimen tersebut menunjukkan bahwa voting mayoritas tidak memilih kebenaran. Ia memilih apa pun yang paling keras kepala dilakukan oleh model tersebut.
Perbedaan ini penting karena voting mayoritas telah menjadi trik populer dalam pipeline LLM. Polanya lugas. Anda menjalankan model beberapa kali pada prompt yang sama, mengumpulkan output-nya, dan menyimpan jawaban yang paling sering muncul. Dalam bidang seperti pencitraan medis atau deteksi spam, metode ensemble berfungsi karena model yang berbeda, atau pandangan yang berbeda terhadap data, menghasilkan kesalahan independen yang benar-benar dapat saling meniadakan. Model bahasa besar bukanlah pemilih yang independen. Mereka adalah satu sistem dengan satu riwayat pelatihan, satu set bobot, dan satu semesta bias. Saat Anda mengajukan pertanyaan yang sama kepada model yang sama sebanyak lima puluh satu kali, Anda tidak sedang mengumpulkan komite. Anda sedang melakukan jajak pendapat terhadap responden yang sama dalam suasana hati yang sedikit berbeda.
Masalah Persistensi
Masalah intinya adalah bahwa kesalahan LLM jarang bersifat acak. Kesalahan tersebut adalah pola yang tertanam dalam data pelatihan dan arsitekturnya. Model yang salah membaca dekorator Python tertentu dalam satu kali jalan kemungkinan besar akan salah membacanya lagi pada sesi berikutnya. Model yang berhalusinasi tentang kerentanan keamanan karena nama variabel terlihat seperti kata sandi kemungkinan besar akan berhalusinasi lagi pada percobaan keempat puluh tujuh. Noise yang Anda coba rata-ratakan biasanya hanyalah variasi permukaan dalam pemilihan kata atau pemformatan. Penalaran yang mendasarinya sering kali tetap terkunci di tempatnya.
Pertimbangkan contoh konkret. Bayangkan sebuah fungsi yang mengurai file log menggunakan ekspresi reguler (regex). Regex tersebut ketat dan aman. Namun string r'...' mengandung karakter yang, dalam konteks berbeda, mungkin mengundang injeksi. Mintalah LLM untuk meninjau ini. Jika model telah melihat ribuan postingan Stack Overflow yang memperingatkan terhadap injeksi regex dalam pengurai log, ia mungkin menandai cuplikan aman ini sebagai risiko. Jalankan sekali, Anda mendapatkan positif palsu. Jalankan 51 kali, dan ada kemungkinan besar Anda mendapatkan 51 positif palsu, atau setidaknya mayoritas yang kuat. Voting mayoritas sekarang memperkuat halusinasi tersebut. Model itu persisten, sehingga "konsensus" tersebut juga persisten.
Hal ini terjadi karena pengaturan temperature dan trik sampling tidak mengubah apa yang diketahui model. Mereka hanya mengatur ulang cara model berbicara. Temperature yang tinggi mungkin membuat penjelasan menjadi cerewet atau singkat. Ia mungkin menukar sinonim. Ia tidak tiba-tiba mengajari model bahwa regex tersebut sebenarnya tidak berbahaya. Variasi yang Anda pilih melalui voting hanyalah kosmetik. Kesalahannya bersifat struktural.
Apa yang Terungkap dari 51 Kali Percobaan
Ketika saya menyebarkan 51 output tersebut di meja saya, polanya sangat jelas. Model tersebut tidak mengeksplorasi 51 interpretasi berbeda dari kode tersebut. Ia hanya melatih interpretasi yang sama dengan suara yang sedikit berbeda. Segelintir percobaan keluar dari skrip, menyarankan perbaikan edge-case atau menyadari masalah gaya yang tidak terkait. Namun klaster dominan, mayoritas yang jelas, terus kembali ke klaim sentral yang salah yang sama. Klaim itu tidak benar. Itu hanya terasa akrab.
Matematika dari voting mayoritas mengasumsikan percobaan Bernoulli yang independen. Anda memerlukan kesalahan yang tidak terkait agar mayoritas dapat mengungguli individu. Dalam eksperimen saya, kesalahan-kesalahan tersebut sangat terkait. Mereka berbagi akar penyebab yang sama: distribusi pelatihan model terlalu menitikberatkan pada kiasan pengkodean tertentu. Oleh karena itu, voting mayoritas tidak mengurangi kesalahan. Ia justru memperkuat bias mayoritas. Ia memberikan rasa kepastian palsu pada analisis yang cacat.
Ini sangat berbahaya dalam peninjauan kode karena pengembang memperlakukan output AI yang bulat atau hampir bulat sebagai sesuatu yang otoritatif. Satu saran yang ragu-ragu mudah untuk diabaikan. Sebuah rekomendasi yang tetap teguh di lima puluh satu kali percobaan terasa seperti ground truth. Padahal tidak. Itu adalah ground loop.
Di Mana Pemungutan Suara Benar-benar Berhasil
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