LLM Yargıc: Kendisiyle Aynı Fikri Savunan Sistem

Çoklu ajanlı bir sistemimiz vardı.

Bir ajan, kullanıcının doğal dil sorusundan SQL sorgusu oluştururken, ikinci bir ajan – “yargıç” – bu sorgunun otomatik olarak yürütülmek için güvenli ve doğru olup olmadığına karar veriyordu. İnsan tarafından onaylanması gereken durumlarda ise çalışmayı durduruyordu.

Birkaç hafta boyunca sistem iyi çalışıyordu, bu yüzden dikkatle izlemeyi bıraktık. Ancak bir süre sonra, kullanıcının sorusunda açıkça belirtilen bir filtre koşulunu sessizce ortadan kaldıran bir sorgu onaylandı ve yürütüldü. Neyse ki büyük bir felaket yaşanmadı, veri kaybolmadı, yanlış tabloya yazma olmadı, ancak döndürülen sonuç tamamen yanlıştı. Bu durum, analistin yarım saatlik kafa karışıklığına neden oldu ve verilen sayının aslında yanlış olduğunu fark ettik. Yargıcın tereddüt etmeden onayladığı, ancak aslında doğru olmayan bir sonucu güvenle sunduğu ortaya çıktı.

Bu olay, “LLM yargıcının onayı” ifadesinin “doğru” anlamına gelmediğini anlamamızı sağladı ve yargıcın kendisinin de test edilmesi gereken bir bileşen olduğunu fark ettik.

İlk varsayımım, yargıcın rastgele bir hata yaptığını düşünmekti. LLM’ler mükemmel değildir, hatalar olabilir, ancak devam edilir. Bu nedenle aynı sorguyu ve aynı yargıç istemini izole olarak tekrar çalıştırdım. Beklentim ya hatanın tekrarlanması ya da düzeltilmesiydi. Ancak sorgu aynı eksik filtre ile tekrar onaylandı. Bu durum, rastgele bir hata değil, yargıcın tutarlı bir şekilde tekrarlayacağı yapısal bir sorunun olduğunu gösteriyordu.

Sorunun kökenine inmek için, yargıcın geçmiş kararlarını inceledim ve bunları, aynı sorgular hakkında insan değerlendiricilerin ne söyleyeceğini karşılaştırdım. Bu sayede bir örüntü ortaya çıktı. Yargıç, kendi model ailesinin ürettiği çıktılara daha yüksek puan veriyordu. Bu durum, “perpleksite aşinalığı” olarak bilinir ve LLM’lerin kendi ürettikleri metinlere daha yüksek puan vermesiyle sonuçlanır.

Yargıç ve üretici (generator) model aynı temel modele dayanıyordu. Bu, bir tasarım tercihi değildi, ancak tüm boru hattında standartlaştırdığımız modeldi. Farklı bir modelle – aynı görev ve şema ile oluşturulmuş – sorguları test ettiğimde, yargıcın tutumu önemli ölçüde değişti. Diğer modelin sorgularındaki sorunları tespit ederken, kendi modelinin sorgularındaki sorunları gözden kaçırıyordu.

Bu durum, “öz-tercih yanlılığı” olarak bilinir ve LLM’lerin yargıç rolünde kullanılmasıyla ilgili araştırmalarda belgelenmiştir. Bu durum, yalnızca bizim kurulumumuzla sınırlı değildir. Yargıcın rastgele bir hata yapmadığını, aynı zamanda kendi ürettiği çıktılara özel bir eğilim gösterdiğini fark ettim.

Bu istemde, yargıcın herhangi bir çıktıya karşı hoşgörülü olması istenmiyor. Yanlılık, istemin içeriğinden değil, yargıcın “doğru bir sorgunun nasıl yazıldığına” dair olan tanıdık özelliklerinden kaynaklanıyordu. Üretici modelin ürettiği aynı tarz ve yapıdaki çıktılar, yargıcın öncelikli olarak onaylama eğilimini artırıyordu.

Yargıcın öz-tercih yanlılığına sahip olduğunu fark ettikten sonra, yargıcın başka sistematik hatalar yapıp yapmadığını araştırmaya başladım. İşte bulgularım:

• Öz-tercih yanlılığı: Bir LLM, kendi çıktılarının veya kendi model ailesinin çıktılarına daha yüksek puan verebilir. Bu durum, “perpleksite aşinalığı” olarak bilinir ve LLM’lerin kendi ürettikleri metinlere daha yüksek puan vermesiyle sonuçlanır.
• Ayrıntı yanlılığı: İki çıktıyı karşılaştırdığınızda – bunlardan biri doğru ve özlü, diğeri ise daha uzun ve ayrıntılıyse – genellikle daha uzun çıktı daha yüksek puan alır. Bu durum, özellikle rubriğinizde “kapsamlılık” gibi bir unsur varsa ortaya çıkar.
• Pozisyon yanlılığı: İki çıktıyı karşılaştırdığınızda (örneğin, “hangisi daha iyi?”), çıktıların sunulma sırası sonucu etkileyebilir. Aynı şeyleri koruyarak sadece sıralamayı değiştirmek bile kararı değiştirebilir.

Bu durumlar, yargıcın kullanımını tamamen imkansız kılmaz. Ancak, bir ölçüm cihazı olarak değil, tutarlı ancak önyargılı bir değerlendiricinin görüşü olarak ele alınmasını gerektirir.

İlk çözüm, yargıcın üretici modelden farklı bir aileye ait bir model kullanmaktı. Bu, öz-tercih sorununu doğrudan çözdü ve aynı zamanda daha kapsamlı bir çözüm gerektiren diğer sorunları da ortadan kaldırdı.

İkinci olarak, rubriği yeniden yazarak, yargıcın gereksiz uzunluğu cezalandırmasını ve aynı doğru sonucu daha az kelimeyle ödüllendirmesini sağladım. Yargıcın istemine doğrudan bir örnek ekleyerek, kısa ve doğru sorgunun daha uzun ve karmaşık sorgulardan üstün olduğunu gösterdim.

Son olarak, geçmişte yargıcın onayladığı sorguları inceledik ve bir değerlendiricinin aynı sorgular hakkında ne düşüneceğini karşılaştırdık. Bu sayede, yargıcın tutarsız olduğu durumları belirleyebildik ve bu durumlardaki sorguları otomatik olarak insan incelemesine yönlendirdik.

Bu sayede, sadece “yargıcın onayı” ifadesinin güvenli olmadığına değil, aynı zamanda hangi durumlarda güvenilir olduğunu da belirleyebildik. Bu, sistemin daha güvenilir hale gelmesini sağladı.

Bu olaydan çıkarılacak en önemli ders, bir LLM yargıcının kullanımının, yeni bir ekip üyesinin kendi kod değişikliklerini onaylama yetkisi kazanması gibi, dikkatli bir süreç gerektirmesidir. Yargıcın hatalarını anlamak ve hangi durumlarda güvenilir olduğunu belirlemek önemlidir.