AdversarialDebate v0.2.1, sessiz join çöküşünün ardından fail-fast satır sayısı kontrolleri ekliyor

Çalışan bir motor ve işlevsiz tartışmalar

AdversarialDebate, iki LLM değerlendiricinin birbirinin çalışması üzerinden yapılandırılmış bir tartışma yürüttüğü açık kaynaklı bir çerçeve; 28 Ağustos 2026'da 0.2.1 sürümünü yayımladı. Bu sürüm, değerlendirme hattının beş birleşim noktasının tümüne satır sayısı invariant doğrulamaları ekliyor; böylece satırlar sessizce kaybolduğunda çalışma anında duruyor. Sürüm ayrıca projenin ilk yanlış-negatif ölçümlerini ve 55 yeni birim testini içeriyor. Geliştirici, dev.to'daki yazısında sürümü iki bölümlük bir hata ayıklama öyküsünün kapanış bölümü olarak çerçeveliyor: önce bir prompt tasarım hatası, sonra da düzeltmeyi ölçmesi gereken veri bütünlüğü hatası.

Proje sert mimari garantiler üzerine kurulmuştu: ikinci modelin ilk modelin cevabını görememesi için yalıtılmış değerlendirici oturumları, tartışmanın ancak iki değerlendirme de kesinleştikten sonra başlamasını sağlayan bir açığa çıkarma kapısı, iddia ve taviz takibi, yakınsama puanlaması,transkript kaydı ve bir SQLite denetim izi. Yazarın anlattığına göre bu invariant'ların hepsi doğru çalışıyordu — yine de ilk gerçek tartışmalar etkisizdi. İlk dokuz tartışmalık denemede sekizi sıfır taviz üretti, ortalama yakınsama puanı 0.02 oldu ve hiçbiri karar üretmedi. Transkriptler hareketli görünürken argüman durumu zar zor ilerliyordu; yazarın bu örüntü için kullandığı terim "tartışma tiyatrosu" ve yazar bu küçük denemede %89 oranında rapor ediyor.

Hata ayıklama içgüdüsü önce motora yöneldi: oturum yalıtımı, açığa çıkarma kapısı, yeniden oynatılan değerlendirme metni, kanıt takibi, yakınsama matematiği. Hepsi iyiydi. Modeller talimatları izliyordu — ve sorun talimatların kendisiydi.

Bedava CARRIED seçeneği

Orijinal tartışma protokolü her tarafın bir itiraza üç şekilde yanıt verebilmesine izin veriyordu: taviz vermek, karşı kanıtla çürütmek ya da itirazı kabul edip orijinal konumu korumak — protokolün CARRIED dediği hamle. Bu üçüncü seçenek yetersiz tanımlanmıştı ve hiçbir maliyeti yoktu. Bir iddiayı korumak için modelden kanıt isteyen bir şey yoktu ve karşı tarafın kanıtı daha güçlüyken taviz vermeye zorlayan da yoktu — modeller ucuz hamleyi seçtiler ve tur sınırı konuşmayı bitirene kadar turları atlatıp gittiler.

Bu boşluğu kapatacak şekilde prompt'u yeniden yazmak, sistemin davranışını ölçekte değiştirdi. Düzeltmeden sonra yazar, küçük denemede sıfır tiyatro vakası ve 411 tam korpus tartışmasında bir vaka (%0.2) rapor ediyor. Ortalama yakınsama küçük denemede 0.445'e, korpus genelinde 0.65'e yükseldi; 411 tartışmanın 410'unda en az bir taviz vardı ve toplamda 8.894 taviz, 152 karar ve 259 ihtilaflı sonuç üretildi.

Sonra hata bir katman aşağı indi

Prompt düzeltildikten sonra v0.2.0'daki hatalar tartışma teşviklerinden, değerlendirme hattının sistemin gerçekten yaptığını sadakatle kaydedip kaydetmediğine kaydı. Yazar üç sorun sıralıyor. Betikler, korpus karma etki alanlı artifact kimliklerine geçtikten sonra hâlâ yalnızca pull request kimlikleri varsıyordu. PR olmayan bazı artifactler sabitlenmiş kaynak belgeler yerine indeks sayfalarıydı; ham HTML olarak alındılar ve çöp değerlendirici girdileriyle bad-request hataları ürettiler. En dikkat çekici olarak, çalışanlarının 2.333 satırı doğru değerlendirdiği bir LLM-as-judge birleştirme adımının birleştirme mantığı yanlış kimliğe göre eşleşiyordu ve çıktıyı 359 satıra indiriyordu.

Hiçbir şey çökmedi. Hat, değerlendirilen satırların kabaca %15'ini kapsayan sonuçlar üretti ve bunları bulgu olarak sundu.

v0.2.1 neyi değiştiriyor

Sürüm 0.2.1, hattın beş birleşim noktasının tümüne satır sayısı invariant doğrulamaları ekliyor; yazar bunun 2.333'ten 359'a tarzındaki çöküşü yapısal olarak engellediğini söylüyor: satırlar aşamalar arasında kaybolursa, çalışma kendinden emin bir yanlış sayı üretmek yerine hızlıca başarısız oluyor. Sürüm ayrıca yanlış-negatif ölçümü getiriyor — projenin bugüne dek bildirdiği ilk hatırlama rakamları olan %1.7–3.4 aralığında kaçırılmış sorun oranı — ve 55 yeni birim testi. Paket PyPI'da mevcut.

Neden önemli

Bu, çok aktörlü veya LLM değerlendirme sistemleri kuran herkes için iki ayrı nedenden dolayı yararlı bir vaka çalışması. Birincisi, bir hat tüm mekanik kontrolleri geçebilir — oturumlar yalıtılmış, JSON ayrıştırılmış, transkriptler yazılmış, raporlar oluşturulmuş — çekirdek etkileşim hiçbir değerli şey yapmazken; bu olduğunda hata mimaride değil protokolün teşvik yapısında olma olasılığı daha yüksektir ve önce motoru hata ayıklamak size zaman kaybettirir. İkincisi, sessiz satır kaybı değerlendirme altyapısının karakteristik hatasıdır: yanlış kimliğe göre eşleşen bir join hata fırlatmaz, sadece metriklerinizin yalan söylemesini sağlar. Hat birleşim noktalarındaki ucuz satır sayısı doğrulamaları, yalnızca baş davranışı ölçmek yerine hatırlamayı da ölçme isteğiyle birleştiğinde, bir sistemin çalıştığını bilmek ile yalnızca çalışıyormuş gibi görünen bir şeyi göndermek arasındaki farktır.