Recall Değerimiz 0.087 İdi ve Model Masumdu: Alana Özgü Yeniden Oynatma (Domain-Scoped Replay) Skoru Nasıl İkiye Katladı?
Kaynak: dev.to
İçindekiler 5 başlık
CauterRule v0.3.0 ve Takılı Kalan Metrik Problemi#
Yapay zeka ajanlarının tekrarlayan çalışma hatalarından kalıcı kurallar çıkaran açık kaynaklı sidecar çözümü CauterRule, v0.3.0 sürümüyle GitHub ve PyPI üzerinde yayınlandı. pip install cauterule komutuyla kurulan bu araç; ajanların çalışma yörüngelerinden (trajectory) ders çıkarma, bunları yeniden oynatarak test etme (replay-test) ve başarılı olanları kalıcı kurallara yükseltme yaşam döngüsünü yönetir.
Sürüm öncesinde 2 bulut modeli, 40 farklı külliyat ve 4.768 yörünge çalıştırması üzerinden kapsamlı bir saha testi gerçekleştirildi. Ancak ardışık iki test boyunca kritik bir metrik değişmeyi reddetti: Golden recall değeri 0.087 seviyesinde saplanıp kalmıştı. Raporlar sorunun kural eşleştirici (matcher) kalibrasyonunda olduğunu işaret ediyordu. Ancak mühendislik ekibi eşleştiriciye odaklandığında asıl gerçeği fark etti: Sorun modelde veya eşleştiricide değil, hesaplamadaki paydada (denominator) gizliydi.
Belirti: Faydalı Bir Kuralın Sıfıra Yakın Puan Alması#
Yeniden oynatma mekanizması, aday kuralları referans hata yörüngelerine karşı iki temel metrikle değerlendirir:
precision = prevented / (prevented + broken)recall = prevented / total_failures
Saha testlerinde 3 gerçek hatayı başarıyla önleyen oldukça faydalı bir kural adayı incelendiğinde, bu kuralın 3 / ~200 = 0.015 gibi yok denecek bir recall skoru aldığı görüldü. Hiçbir filtreleme eşiği sistemi gürültüye boğmadan 0.015 değerini kabul edemezdi. Metriğin gerçekte yanıtladığı soru hatalıydı: "Bu Git kuralı aynı zamanda Docker, Python ve Terraform arızalarını da önlüyor mu?" Kural zayıf değildi; payda tüm külliyatı kapsadığı için anlamsız bir kıyaslama yapılıyordu.
Hatalı Varsayım ve Yanıltıcı Değerlendirme#
Sistem şu örtük ve hatalı varsayım üzerine inşa edilmişti:
- Varsayım: Referans havuzundaki her başarısızlık, her kural adayı için geçerli ve adil bir test senaryosudur.
Alana özgü (domain-specific) çalışan kural motorlarında bu varsayım tamamen geçersizdir. Yanıltıcı metrikler sistemde gürültü yaratmaz; aksine kaliteli kuralları tüm modeller genelinde değersiz göstererek asıl mimari problemleri maskeler.
Çözüm: Referans Havuzunu Kaynak Alana Daraltmak#
v0.3.0 ile birlikte test havuzu küçülmedi (230'dan 444 referansa çıktı), ancak her adayın sınandığı kesit kendi etki alanıyla sınırlandırıldı (t.domain == candidate.source_domain):
- Git alanı: ~200 yerine 19 referans
- Python alanı: ~200 yerine 30 referans
- Docker alanı: ~200 yerine 30 referans
Böylece 3 Git hatasını engelleyen kural 3 / 19 ≈ 0.16 puanına ulaştı. Doğru hesaplamanın ardından geçme eşiği de 0.8'den gerçekçi olan 0.5 seviyesine çekildi.
Yazılım Geliştiriciler İçin Pratik Çıkarım#
Otonom ajanlar ve LLM değerlendirme süreçlerinde düşük metriklerle karşılaştığınızda doğrudan promptlara veya modele müdahale etmeyin. Önce ölçüm yaptığınız veri havuzunun bağlamını (scope) ve paydasını sorgulayın. Yanlış tasarlanmış bir kıyaslama metriği, en yetenekli modelleri bile başarısız gösterebilir.
Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.
Kaynak ve atıf
Bu yazı, dev.to üzerinde yayımlanan içerikten yararlanılarak Edumints tarafından yapay zekâ desteğiyle Türkçe hazırlandı. Ayrıntılar ve yazarların kendi anlatımı için orijinaline bakabilirsin:
- dev.to/debashish_ghosal/our-recall-was-0087-and-the-model-was-innocent-how-domain-scoped-replay-doubled-it-4ci4