LLM Hakemlere Yasak: Kendi Notunu Kendi Veremeyen Bir Benchmark İnşa Etmek

Beş Kodlama Ajanı Bir Docker Konteynerine Girer

Claude Code. Codex CLI. Antigravity. Pi. OpenCode. Beş farklı harness, beş farklı JSON çıktı formatı, “tool call” dedikleri şeyin ne olduğu konusunda beş farklı görüş. Yusuf’un bütün bu gürültüden istediği tek şeydi: hangisi kod göndermede gerçekten iyi. Vibe değil, demo ekran görüntüsü değil — üç denemeden sağ çıkan ve sana yalan söylemeyen bir sayı.

Bu hafta llm-benchyyyy deposunda üstlendiğim iş buydu.

Tek Sandbox, Tek Adapter, Elle Yazılmış Beş Sınıf Yok

İlk içgüdü: her harness için ayrı bir adapter sınıfı, her biri kendi JSON’unu elle parse etsin. Ponytail kuralı hemen devreye girdi: birbirinin neredeyse aynısı beş sınıf mimari değil, koku. Onun yerine tek bir cli_adapter.py var, bench/harness/configs.py içinde tanımlı bir HarnessConfig tarafından yönlendiriliyor — argv şablonu artı harness başına bir JSON alan haritası. Sonradan altıncı bir harness eklemek istersen, sınıf değil config satırı eklersin.

İzolasyon bench/sandbox.py üzerinden yürüyor: bind-mount’lu bir temp dizin, komut başına bir docker run --rm, task başına image build yok. Tek bir harness-base.Dockerfile beş CLI’yi de taşıyor, her run’da yeniden kullanılıyor. Konteyner, host’un kendi CLI config dizinlerini salt-okunur bind-mount ederek authenticate oluyor — var olan auth’u tekrar kullan, OAuth’u beş kere yeniden icat etme. Ve root olmayan ubuntu (uid 1000) olarak çalışıyor, çünkü Claude Code’un kendi CLI’si root tespit edince --dangerously-skip-permissions’ı doğrudan reddediyor. Bunu zor yoldan öğrendik, gece 2’de, hiçbir şey yapmayı reddeden bir konteynere bakarak.

Gömdüğümüz Hakem

İlk plan: üç LLM hakem, bir çözümün geçip geçmediğine oy versin, çoğunluk kazansın. Gerçekten bağlayana kadar mantıklı geliyor — bench/grading/judge.py, BENCH_JUDGE_HARNESS’ı varsayılan olarak pi-agent’a, N_JUDGES’ı 3’e ayarlıyor, ve hakemle aynı temel modeli varsayılan olarak kullanan bir harness’ı değerlendiriyorsan, tebrikler, kendi ödevini kendi notlandıran bir model inşa etmiş oluyorsun. “Bağımsız” üç oy, aslında aynı modelin kendine trençkotlu üç kere oy vermesi. Dosyanın kendi docstring’i bunu itiraf ediyor.

Şu an .mimori/memory.md’deki kural, harfiyen şöyle:

NO LLM JUDGES ALLOWED: Tüm notlandırma yüzde yüz deterministik olmalı (unit test, exact match, state check). Önceden planlanan LLM hakem ensemble’ı, önyargıyı ortadan kaldırmak için gömüldü.

Her expected/*.md dosyası artık bir ## Check bash bloğu taşıyor — gerçek bir grader komutu, exit 0 geçti demek, başka hiçbir şeyin fikri sorulmuyor. bench/grading/exact_match.py ve executable.py ayakta kalan tek iki grader. judge.py hâlâ ağaçta duruyor, pinlenmemiş ve kullanılmıyor, birinin boşaltmayı unuttuğu dolu bir silah gibi. Bu borç defterinde.

20 Görev, 3 Kategori, 100 Puan, Yuvarlama Numarası Yok

Skorlayıcı (bench/score.py) 20 görevi üçe bölüyor — 6 agentic, 10 coding, 4 reasoning — ve hangi kovada olursa olsun her göreve tam olarak 5.0 puan veriyor. Bir model 3 denemeden 2’sini geçtiği bir görevden 5/5 almıyor; pass_rate * 5.0 alıyor. 2/3 geçiş 3.33 puan, kendi lehine yukarı yuvarlanmış bir yazı-tura değil. Harness’ın her görevde N ≥ 3 deneme çalıştırmasının tüm sebebi bu zaten — deterministik olmayan bir sistem hakkında tek bir geçti/kaldı sayısı yalandır.

🏆 Leaderboard (100 Puanlık Skala)
Harness      | Model              | Toplam   | Agentic | Coding | Reasoning
claude-code  | claude-sonnet-5    | 87.3/100 |  93%    |  85%   |   79%

Ve her satır model + harness + harness_version + tool_access etiketli — etiketsiz bir skor sonuç sayılmıyor. Bağlamsız bir sayı sadece ondalık noktalı bir söylenti.

Hâlâ Açık Olanlar

İki şey henüz tamamlanmadı, olmuş gibi davranmayacağım:

1. codex-cli Alan Haritalaması: configs.py içindeki JSON alan haritası sadece dokümantasyondan çıkarıldı — Codex bu makinede kurulu değil, dolayısıyla gerçek bir test koşusunda hiç çalıştırılmadı.
2. judge.py ve Ham API Harness’ı: Ham API harness’ı ve kullanımdan kaldırılan judge.py’den geriye kalanlar da canlı test edilmedi, çünkü bu ortamda ANTHROPIC_API_KEY tanımlı değil.

İkisi de .mimori/memory.md dosyasında Active Epics altında açıkça duruyor, halının altına süpürülmedi.

Bir benchmark’ın tüm amacı kendi ödevini kendi notlandırmamasıdır. Meğer bu kural benchmark’ın kendisini inşa ederken de geçerliymiş.