Jylus benchmark'u: %98,77 daha az LLM input context, 528/528 strict doğruluk

Benchmark neyi ölçtü

Jylus kurucusu Josh Hodgetts'in bir dev.to yazısı, dört veri alanında yayılmış 528 soruluk, deterministik bir skorlayıcıyla puanlanan, dondurulmuş bir benchmark'ı anlatıyor; her soru aynı modele (Gemini 3.1 Flash Lite) özdeş ayarlarla soruldu. Tek değişken, kanıtın modele nasıl ulaştığıydı.

Üç yapılandırma karşılaştırıldı. Modele tam context vermek soru başına ortalama 205.129 input token tüketirken strict puanlamada %78,79 doğruluk sağladı. Yalnızca BM25 kullanan bir retrieval kurulumu ortalama girdiyi 8.128 token'a düşürdü, ama doğruluk %76,14'e geriledi. Üçüncü yapılandırma olan Jylus'ün kendi Context Pack'i ortalama 2.532 token kullandı — tam context'e göre %98,77 daha az girdi — ve aynı skorlayıcı altında 528 sorunun tamamını doğru cevapladı.

Hodgetts'in özellikle öne çıkardığı satır BM25 satırı. Prompt'u tek başına küçültmek işleri iyileştirmek yerine biraz kötüleştirdi: modele hâlâ örtüşen, kısmen çelişen kayıtlar verildi ve hangisinin geçerli olduğuna karar vermek modele bırakıldı.

Temeldeki sorun: Birbirini düzelten kayıtlar

Yazı, bu başarısızlık biçimini iki kayıtla örnekliyor. Olaydan dakikalar sonra girilen ilk kayıt, Çarşamba günü 09:00'da bir sıcaklık uyarısınot ediyor. Cuma günü girilen ikinci kayıt ise uyarının arızalı bir sensörden kaynaklandığını açıklıyor. "Şu anda bilinen her şey göz önüne alındığında Çarşamba'nın uyarısına ne yol açtı?" diye sorarsanız, Cuma düzeltmesi kullanılabilir. "Çarşamba günü uyarı hakkında ne biliniyordu?" diye sorarsanız, düzeltme cevabın dışında kalmalı; çünkü henüz var olmamıştı.

İki kaydı da geri döndürmek teknik olarak eksiksizdir, ama bir yargı kararı — hangi kanıtın sorulan soru için kabul edilebilir olduğu — modele yüklenir. Yazıya göre kendinden emin yanlış cevapların kaynağı tam da burasıdır ve bu örüntü destek geçmişlerine, abonelik değişikliklerine, olay incelemelerine ve sonraki bir kaydın önceki bir olayı yeniden çerçevelediği her veri kümesine genellenir.

Araç gerçekte ne yapıyor

Jylus, veri kaynağı ile model arasında durur. Aday kanıtları getirir (retrieve), durum ve ilişkileri çözer ve kaynak referanslarını taşıyan, ilgili çatışmaları ve boşlukları bilinçli olarak yumuşatmak yerine koruyan sınırlı bir pack derler. Model daha sonra bu hazırlanmış kanıt üzerinde akıl yürütür.

Geliştiriciye dönük çıktı, provenance'ın incelenebilir olmasını amaçlıyor: verili bir gerçeği hangi kaynak destekliyor, o gerçek sorunun ilgilendiği zaman noktasında geçerli mi, daha yeni bir kayıt onun yerini aldı mı, kaynaklar anlaşmıyor mu ve cevaplamak için yeterli kanıt var mı. Hodgetts, token bütçesini, kanıt hacmine ama yorumlamak için gerekli belirsizliği gizlememesi gereken bir kısıt olarak çerçeveliyor.

Sonucun sınırları

Yazı, rakamların neyi kanıtlamadığı konusunda açık sözlü. Benchmark, Jylus'ün kendi adversarial tasarımı ve dört veri alanını kapsıyor; bağımsız olarak tekrarlanmış değil. %100 rakamı, bu testin strict puanlaması altında 528'in 528'i anlamına geliyor, evrensel doğruluk değil. Yalnızca BM25'li retrieval, olası RAG mimarilerinin yalnızca bir dilimini temsil ediyor. Ayrıca deney, kanıt hazırlığının hangi parçasının — retrieval, durum çözümü, çatışma saklama mı yoksa token sınırı mı — iyileşmeyi gerçekten sağladığını yalıtmıyor. Metodoloji herkese açık ve bir playground, davranışı doğrudan test etmek isteyenler için hesap gerektirmeden sentetik kayıt kabul ediyor.

RAG ve prompt tasarımı için çıkarımlar

Temkinli yaklaşılsa bile sonuç, değiştirilebilir veri üzerinde retrieval sistemi kuran herkes için test edilebilir fikirler sunuyor:

• Daha fazla context her zaman daha iyi değil. Bir gerçeğin çelişen sürümleri, bilgi eklerken doğruluğu düşürebilir.
• İlgililik, kabul edilebilirlik demek değil. Getirilen bir kaydın, sorunun ilgilendiği zaman noktası için de geçerli olması gerekiyor.
• Provenance metadata'sı — kaynak, yerini alma, anlaşmazlık, boşluklar — doğruluk sorunlarını üretimden önce değil, üretime göre önce ortaya çıkarır.
• "Yeterli kanıt yok" sistemin gerçekten döndürebileceği bir cevap olmalı.

Neden önemli

Bu örüntü tek bir benchmark'ın ötesinde geçerli olursa, nadir görülen bir kombinasyona işaret ediyor: aynı değişiklikten hem büyük bir maliyet düşüşü hem de doğruluk kazanımı. Hedef aldığı başarısızlık biçimi — bir modelin bayat ve güncel kayıtları tek bir kendinden emin cevapta sessizce harmanlaması — değişen veri üzerindeki production sistemlerinde yaygındır. Bu yüzden bu, bir vendor tanıtımından çok somut bir tasarım hipotezi: prompt'lama öncesi kanıtı zamana ve çatışmaya göre hazırla, sonra doğruluğun korunduğunu ölç. Deneyi kendi verinizde tekrarlamak bariz bir sonraki adım.