Fable 5, Opus 4.8 ve Sonnet 4.6: LLM'leri kendi kodunuzda nasıl dürüstçe karşılaştırırsınız

Yeni bir model çıktığında duyuru, "benchmark'larda ne kadar daha iyi" sorusunu yanıtlar — ama beni ilgilendiren tek soruyu yanıtlamaz: işimde neyi değiştirecek. Kontrollü bir deney yaptım: üç Claude modeli — Fable 5, Opus 4.8 ve Sonnet 4.6 — bu blogun kod tabanını denetlemek için kelimesi kelimesine aynı görevi aldı, her biri deponun izole bir kopyasında, önceden üzerinde anlaşılmış bir değerlendirme rubriğiyle. Makalede metodolojinin kendisi — herhangi bir projede tekrarlanabilir — sonuçlar ve ayrıca deneyin iki kez nasıl bozulduğu ve bunun ne öğrettiği var.

Benchmark'lar neden sorumu yanıtlamıyor

Herkese açık benchmark'ların iki sorunu var ve ikisi de temel. Birincisi veri kirlenmesi: test örnekleri eğitim kümelerine sızıyor ve model görevi çözmek yerine yanıtları kısmen "hatırlıyor". Bu marjinal bir şüphe değil, başlı başına bir araştırma alanının konusu: Xu ve arkadaşlarının derlemesi (2024) benchmark kirlenmesi araştırmalarını sistematikleştiriyor ve EMNLP 2025 derlemesi sektörün yanıtını kaydediyor — statik testlerden dinamik olarak üretilenlere geçiş.

İkinci sorun daha basit: benchmark benim görevimi ölçmüyor. Bana olimpiyat problemlerini en iyi çözen model gerekmiyor. Bana Laravel blogumda gerçek hataları bulacak, olmayanları uydurmayacak ve düzeltmesinin çalıştığını kanıtlayacak bir model gerekiyor.

Bundan basit bir fikir çıkıyor: modelleri karşılaştırmak için en iyi test düzeneği kendi projenizdir. Onun kodu bu kombinasyonda eğitim kümelerinde yok, üzerindeki görevler tam olarak para ödediğim görevler ve sonuçları elle doğrulayabilirim çünkü bu kodu biliyorum.

Deney tasarımı: tek istem, üç izole dünya

Üç model için de görev kelimesi kelimesine aynıydı — yalnızca dal adı ve sonuç klasörü farklıydı. Dört aşama: blogun iki dilli makale sisteminin denetimi, her bulgunun kod alıntısıyla birlikte файл:строка olarak kanıtlanması; üç ana bulgu için ödünleşimleri açıklayan çözüm seçimi; kendi kendini doğrulamayla tek bir düzeltmenin uygulanması; sonuçlar hakkında Rusça ve İngilizce not. İzole bir "soru-cevap" değil, tam bir mühendislik döngüsü — bu yaklaşımı Anthropic de öneriyor: ajanları gerçek üründen gelen görevlerle, çalıştırmadan önce üzerinde anlaşılmış bir rubriğe göre değerlendirin.

Üç kural karşılaştırmayı dürüst yaptı:

İzolasyon. Her model ayrı bir git worktree içinde çalıştı — kendi dalıyla kendi çalışma dizini kopyası. Modeller fiziksel olarak birbirlerinin sonuçlarını göremez veya birbirlerine engel olamazdı.

Halüsinasyona karşı koruma — istemin kendisinde. Görevin kilit satırı: "uydurulmuş bulgu (var olmayan kod, yanlış satır) bulgunun yokluğundan daha kötüdür". Bu teşvik olmadan, sorun bulması istenen model her durumda onları "bulma" eğilimindedir. Bununla — her bulgu elle doğrulamadan geçmek zorunda.

İpuçlarının değerlendirme dışı bırakılması. Depoda, projenin bilinen tuzaklarını açıklayan bir CLAUDE.md var — örneğin dil öneki içeren URL'lerde bozulan varlıklara giden göreli yollar. Üç model de bu dosyayı okuyor, dolayısıyla bu tür bulgular "bedava": özen için sayılır ama derinlik için sayılmaz.

Rubrik: yalnızca elle doğrulanabileni değerlendir

Çalıştırmadan önce beş puanlık altı eksen sabitledim: denetim doğruluğu (bulgu örnekleminin файл:строкаile elle doğrulanması), derinlik (ipuçlarında olmayan doğrulanmış bulgular), ödünleşimler hakkında akıl yürütme kalitesi, kod ve kendi kendini doğrulamanın gerçekliği, Rusça ve İngilizce metin kalitesi, disiplin (insana sıfır soru, kısıtlamaların tek bir ihlali bile yok). İlke iyi bir kod incelemesindekiyle aynı: bir eksen ne kadar az zevke ve ne kadar çok doğrulanabilir olguya dayanırsa, ona o kadar güvenilebilir.

Her şey ilk kez nasıl bozuldu

İlk çalıştırmayı yanlış yaptım — ve bu deneyin en taşınabilir kısmı olduğu ortaya çıktı. Aynı depo klasöründe paralel olarak üç etkileşimli oturum açtım. Birkaç dakika içinde çalışma ağacında atfedilemeyen commit'lenmemiş değişiklikler vardı: ortak checkout, bir oturum git checkout -byaptığında dalın üçünde de değiştiği ve değişiklikleriyle commit'lerinin karıştığı anlamına gelir. Oturumlardan biri ayrıca git stash yapıp içine her şeyi süpürdü — deneyle ilgisi olmayan kendi dosyalarım dahil.

“Aynı klasördeki paralel AI ajanları paralel bir deney değildir. Bu, üç yazarı olan tek büyük bir çatışmadır.”

– bana yeniden başlatmaya mal olan çıkarım

İki oturumun sonuçlarının kullanılamaz olduğunu kabul etmek zorunda kaldım: sonuna kadar götürseler bile, kimin düzeltmelerini değerlendirdiğimi dürüstçe söyleyemezdim. İkinci çalıştırma — bu kez izole worktree'lerde — tarife limitlerine takıldı: iki ajan başlangıçta öldü, üçüncüsü ise arayüzde «çalışıyor» görünmeye devam ederek askıda kaldı. Teşhisi durum göstergesi değil, dosya sistemi koydu: yirmi dakika içinde çalışma kopyasında tek bir dosya bile oluşmadı. Bu ikinci taşınabilir ders: ajanın canlılığı diskteki değişikliklerle doğrulanır. Yeniden başlatmanın ardından üç model de eşit koşullarda tam döngüyü tamamladı.

Sonuçlar: modellerin nerede aynı, nerede farklı olduğu

En önemli sonuç — gerçekleşmeyen şey: hiçbir modelde halüsinasyon yok. Her birinin üçer ve daha fazla bulgusunu elle kontrol ettim — tüm alıntılar ve satır numaraları karakterine kadar doğru. Denetim görevleri için bu, güvenin ana eşiğidir ve üçü de bunu geçti.

Sonra farklar başlıyor:

	Fable 5	Opus 4.8	Sonnet 4.6
Doğrulanmış bulgular	11	5	9
Önemsiz olmayan benzersiz	3	1	2
Düzeltmenin öz denetimi	geçici veritabanı üzerinde entegrasyon render'ı, xmllint, başkasının düşen testinin atfı	linter + render; kendi hatasını yakaladı	yalnızca linter ve rota listesi
Token / süre	164k / 21 dk	101k / 12 dk	131k / 12 dk
Rubrik toplamı (30 üzerinden)	30	24	25,5

Nitel farklar puanlardan daha bilgilendirici. Opus 4.8 — sitemap'teki bozuk başlığı Content-Type fark etmeyen tek modeldi (diğer ikisi buldu) ve onu kendi düzeltmesinde bıraktı; ayrıca Rusça metnine İngilizce bir kelime sızdı — «и even путь к картинке». Sonnet 4.6 doğru bir düzeltme yaptı, ancak öz denetimi beyan düzeyindeydi: çalıştırmak yerine linter. Fable 5 tam da öz denetimde öne çıktı: php benim makinemde ana dizine bağlanmış bir docker konteynerinin sarmalayıcısı olduğunu keşfetti, tüm kontrolleri tek kullanımlık konteynerler üzerinden yeniden kurdu ve düzeltmesini geçici bir veritabanında entegrasyon düzeyinde çalıştırdı. «Yaptım» ile «yaptığımı kanıtladım» arasındaki fark — ajan görevleri için en ayırt edici eksen tam da budur.

Bir başka faydalı sinyal — yakınsama: üç model de bağımsız olarak sitemap ile ilgili aynı sorunu ana bulgu olarak adlandırdı. Bağımsız denetçiler en önemli bulguda birleştiğinde, bu, uzmanlar arası tutarlılığın ucuz bir benzeridir: sorun neredeyse kesinlikle gerçektir.

Katılımcılardan biri olan yargıç

Rubrik değerlendirmesini Fable 5 yaptı — yani karşılaştırmaya katılan modelin ta kendisi. Bu metodolojik bir boşluk ve bunu açıkça söylemek gerek: LLM yargıçları kendi metinlerine sistematik olarak daha yüksek puan verir, üstelik bu eğilim model kendi metinlerini ne kadar iyi tanırsa o kadar güçlenir — bu, Panickssery ve arkadaşlarının NeurIPS 2024 çalışmasında. Yanlılığı iki şekilde hafifletebiliriz ve ben ikisini de kullandım: birincisi, rubriği zevk eksenlerinden mümkün olduğunca doğrulanabilir olgulara kaydırmak — satır doğruluğu, düzeltmenin bütünlüğü, sızan yabancı kelime yargıcın sempatisine bağlı değildir; ikincisi, çıkar çatışmasını açıkça beyan etmek ve tartışmalı eksenleri başka bir modele veya bir insana çapraz kontrol için vermek. Sonucumun öznel eksenleri — metin kalitesi, akıl yürütme kalitesi — bu düzeltmeyle okunmalı.

Dürüstlük sınırları

Model başına tek çalıştırma — bu n=1: bir-iki puanlık farklar hiçbir şey ifade etmez, yalnızca nitel uçurumlara güvenmek gerekir — kaçırılan bir hata, öz denetimin derinliği. Deney, tek bir alanda tek bir görevde üç modeli ölçüyor; bundan «Fable 5 genel olarak daha iyidir» sonucu çıkmaz. Ve maliyeti de unutmamak gerek: en üst model, en tutumlu katılımcıdan 1,6 kat daha fazla token ve neredeyse iki kat daha fazla zaman harcadı, üstelik token fiyatı da tek başına daha pahalı — düzenli görevler için bu, daha basit modeller lehine ağır bir argümandır.

Kendime aldığım dersler

Metodoloji, her proje ve her model için işleyen kısa bir kontrol listesine indirgendi:

• Test görevi — sentetik bir alıştırma değil, kendi kodunuz üzerinde gerçek işin tam döngüsü.
• Herkese tek prompt, ayrı worktree'lerle izolasyon, sonuçlar ayrı dallarda.
• Prompt'ta halüsinasyonun açık bedeli: uydurulmuş bir bulgu, bulgunun yokluğundan daha kötüdür.
• Herkese açık ipuçları (dokümantasyon, depodaki notlar) derinlik değerlendirmesinden çıkarılır.
• Rubrik çalıştırmadan önce sabitlenir ve izlenime değil, doğrulanabilir olgulara dayanır.
• Bulgulardan bir örneklem elle kontrol edilmeli; bağımsız modellerin ana bulgularda örtüşmesi, bunların gerçekliğinin sinyalidir.
• Katılımcı yargıç — beyan edilmiş bir çıkar çatışması: tartışmalı eksenler çapraz değerlendirmeye verilmeli.
• Ajanın canlılığı arayüzdeki göstergeyle değil, diskle doğrulanmalı.

Plana dahil olmayan bir bonus: deney kendi masrafını çıkardı. Üç bağımsız denetim blogda gerçek sorunlar buldu — İngilizce sayfaları olmayan sitemap'tan denetleyicideki ölü sorgulara kadar — ve iki hazır düzeltme şimdiden dallarda, üretime taşınmayı bekliyor. Modelleri kendi kodunuz üzerinde karşılaştırmak, benchmark okumaktan farklı olarak, geride yalnızca bir görüş bırakmaz.

Kaynaklar ve referanslar

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — benchmark kirlenmesi sorununun sistemleştirilmesi; kendi kodunuz üzerinde test yapma lehine ana argüman.
• Veri Kirliliği Altında LLM'lerin Kıyaslanması: Statik Değerlendirmeden Dinamik Değerlendirmeye (EMNLP 2025) — sektörün statik testlerden dinamik testlere nasıl geçtiği; benim deneyim dinamik bir testin özel bir durumu.
• AI ajanları için değerlendirmeleri anlaşılır kılmak (Anthropic Engineering, 2026) — ajan değerlendirme pratiği: gerçek üründen görevler, doğrulanabilir rubrikler, yörünge ile sonuç arasındaki ayrım.
• LLM Değerlendiricileri Kendi Üretimlerini Tanır ve Tercih Eder (NeurIPS 2024) — yargıç modelin neden kendine yüksek puan verdiği ve bu konuda ne yapılması gerektiği.
• Worktree'lerle paralel oturumlar çalıştırma (Claude Code Docs) — paralel ajan oturumlarını izole etmenin standart mekanizması; deneyin ilk çalıştırması bu olmadan çöktü.