deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

LLM jürileri temperature 0'da bile RAG değerlendirme sonuçlarını değiştiriyor, bir top-k ayar sonucunu geçersiz kılıyor

Bir dev.to deneyi RAG değerlendirme puanlarındaki gürültüyü kaynağına göre ayırıyor: üretilen yanıtlar faithfulness ve relevancy sapmasını yönlendirirken, context precision ve recall neredeyse tamamen LLM jüriden kaynaklanan dalgalanma gösteriyor — temperature 0'da bile.

LLM jürileri temperature 0'da bile RAG değerlendirme sonuçlarını değiştiriyor, bir top-k ayar sonucunu geçersiz kılıyor

Kurulum

RAG değerlendirme pipeline'larından gelen puanlar, sistemde hiçbir şey değişmese bile çalıştırmalar arasında kayıyor. hualiphd'nin, daha önceki bir top-k taramasıyla ilgili bir okuru sorusu üzerine kaleme aldığı dev.no yazısına göre bu kaymanın iki farklı nedeni var: LLM jürinin aynı yanıtları farklı puanlaması ve üretecin farklı yanıtlar yazması. Bunlar zıt çözümler gerektirdiğinden yazar her birini izole olarak ölçtü.

Test edilen sistem bilinçli olarak küçüktü: 15 araştırma makalesinden oluşan bir corpus, 18 soru, üreteci olarak Groq üzerinde gpt-oss-20b, jüri olarak Gemini 3.5 Flash Lite ve faithfulness, answer relevancy, context precision ile context recall hesaplamak için bunları birbirine bağlayan RAGAS 0.2.15. Jüri, tekrarlanabilir değerlendirme için her zamanki ayar olan temperature 0'da çalıştı; üreteç ise sağlayıcısının varsayılanında kaldı.

İki deneme etkileri ayırdı. İlkünde tek bir yanıt seti üretildi, getirdiği chunk'larla birlikte kaydedildi ve üç kez puanlandı — prompt'lar tüm turlarda aynı hash'e sahipti, dolayısıyla herhangi bir fark jüriye aitti. İkincisinde aynı ayarlar altında üç yeni yanıt seti üretildi ve her biri bir kez değerlendirildi; böylece jüri ve üreteç gürültüsü birlikte yakalandı.

Jüri kendini tekrar etmiyor

Aynı sabit yanıtları üç kez puanlamak 18 soruluk ortalamaları epey hareket ettirdi: context precision 0.601 ile 0.686 arasında, faithfulness 0.611 ile 0.653 arasında, context recall 0.648 ile 0.694 arasında değişti. Yalnızca answer relevancy sabit kaldı ve yalnızca 0.003 oynadı.

Yazı her dalgalanmayı RAGAS'ın metriklerini oluşturma biçimine bağlıyor. Faithfulness, jüriden bir yanıtı claim'lere bölmesini ve her birini getirilen metinle karşılaştırmasını ister; jüri aynı yanıtları farklı sayıda claim'e böldü — bir yanıt üç turda 5, 10 ve 11 claim olarak çıktı — ve faithfulness, claim sayısının değiştiği 18 sorudan tam 11'inde değişti. Precision ve recall evet/hayır kararlarına dayanır ve 148 chunk kararından 5'i ile 22 referans ifade kararından 3'ü turlar arasında değişti. 18 referans yanıtın 14'ü tek cümle olduğundan, bu sorularda recall tek bir evet/hayır kararına indirgendi; tek bir karar değişimi bir soruyu 1'den 0'a taşıdı; bir soru özdeş turlarda 1, 0, 0 puan aldı. Relevancy istikrarlı kaldı çünkü jürinin ürettiği sorular bir embedding modeli aracılığıyla karşılaştırılıyor ve bu da ifade farklılıklarını yumuşatıyor.

Farklı metrikler, farklı gürültü kaynakları

Yazar bunun yerine yanıtları yeniden ürettiğinde ise retrieval her soru için her seferinde aynı 8 chunk'ı getirdi, ama üretilen metin çok değişti — içerik sorularına verilen yanıtların çoğu önceki üretimle sözcüklerinin beşte birinden azını paylaşıyordu.

Bu, varyansı net biçimde ayırdı. Çalıştırma ortalamasının standart sapması faithfulness için 0.021'den 0.054'e yükseldi; yani çalıştırmalar arası varyansının kabaca %85'i yanıtlardan geliyordu. Relevancy içinse 0.002'den 0.028'e çıktı ve bu metrik neredeyse tümüyle yanıt odaklı hale geldi. Context recall ve precision farklıydı: RAGAS bunları sorudan, getirilen chunk'lardan ve referans yanıtten hesaplar, üretilen yanıtı hiç kullanmaz; dolayısıyla deterministik retrieval ile tüm varyansları jüri gürültüsüdür. Yazar, önceden tersi bir bölünme tahmin ettiğini itiraf ediyor.

Bir farkın bir şey ifade etmesi için ne kadar büyük olması gerekir

Yazı bu ölçümlerden, iki tekil çalıştırma arasındaki bir farkın rapor etmeye değer olması için gereken minimum boşlukları çıkarıyor: faithfulness için yaklaşık 0.15, relevancy için 0.08, recall için 0.09 ve precision için 0.10; her biri kabaca fark üzerinde %95'lik bir aralık gibi davranıyor. 9 soruluk bir alt kümede bu eşikler yaklaşık %40 genişliyor. Yazar rakamların metrik başına yalnızca üç ya da dört çalıştırmaya dayandığını ve makul biçimde yarısı ya da iki katı olabileceğini belirtiyor; daha fazla çalıştırma maliyetle kısıtlandı — her tam çalıştırma günlük 500'lük ücretsiz katman limitine karşı yaklaşık 257 jüri çağrısı tüketiyordu.

Bunlar daha önceki top-k taramasına geriye dönük uygulandığında tablo üzücü: her tarama çalıştırmasının puanladığı dokuz soruda yedi çalıştırmanın tamamı jüri gürültüsü bandının içinde kalıyor; yani tarama k değerlerini hiç sıralayamamış ve k=8'deki raporlanan optimum, tekil çalıştırmalardan ve dengesiz soru kapsamından gelmiş — 0.833'lik o gözde recall rakamı gerçekte 18 sorudan 9'unu kapsıyordu.

Doğru şeyi tekrarla

Yazıya göre çözümler metriğe göre farklılaşıyor: recall ve precision için yanıtlar hiç puanlamaya girmediğinden kaydedilmiş sonuçları yeniden jürilemek; faithfulness ve relevancy içinse yanıtları yeniden üretmek gerekir, çünkü yalnızca yeniden jürilemek faithfulness'ı gerçekte olduğundan iki kattan fazla kararlı gösterecektir.

Neden önemli

Tekil çalıştırmaları karşılaştırarak RAG sistemi ayarlayan herkes muhtemelen gürültü okuyor. Bu yazı o riski somut eşiklere dönüştürüyor: iki yapılandırma, metriğe göre kabaca 0.08 ile 0.15 arasından az farkla ayrışıyorsa, bu fark hiçbir şeyin kanıtı değildir. Yazı ayrıca standart temperature-0 ayarının jüri tutarlılığı satın almadığını gösteriyor, çünkü kararsızlık sözcük seçiminde değil, claim bölme ve karar değişimlerinde yaşıyor. Pratik çıkarım, her metriğin pipeline'ın hangi yarısını gerçekten okuduğunu bilmek, jürinin tek başına yeniden oynatılabilmesi için ara sonuçları kaydetmek ve puanları soru kapsamlarıyla birlikte raporlamaktır — yeniden üretilebilir bir bulgu ile şanslı bir çalıştırma arasındaki fark budur.

  • #rag
  • #ragas
  • #llm-evaluation
  • #benchmarking
  • #retrieval