RAG Sisteminizin İyi Olduğunu Nasıl Anlarsınız?

Demo Çalışıyor, Peki Bu Neyi Kanıtlıyor?

Bir RAG pilotu neredeyse her zaman iyi demo verir. Ekip, korpusun cevaplayabildiğini bildiği on soruyu seçer, erişim katmanı doğru pasajları getirir, model temiz bir paragraf yazar ve toplantı odasındaki herkes sistemin çalıştığı konusunda hemfikir olur. İki hafta sonra aynı sistem, kimsenin prova etmediği soruları soran iki yüz gerçek kullanıcının karşısına çıkar ve şikayetler gelmeye başlar. Herkesin varlığını bildiği bir belgeyi atlamıştır. İki kez değiştirilmiş bir politikanın 2019 sürümüne atıf yapmıştır. Korpusta hiç bulunmayan bir konuda kendinden emin biçimde cevap vermiştir. Kodda hiçbir şey değişmemiştir. Değişen tek şey, soru dağılımının artık seçilmiş olmamasıdır; demo hiçbir şey ölçmediği için hiçbir şeyi de öngörememiştir.

İşin rahatsız edici tarafı, çoğu ekibin canlının pilottan ne kadar kötü olduğunu söyleyememesidir, çünkü en başta ortada bir sayı üretilmemiştir. Pilot sırasında erişim recall değerinin ne olduğunu sorun, omuz silkme alırsınız. Geçen perşembe yapılan prompt değişikliğinin cevapları iyileştirip iyileştirmediğini sorun, kendinden emin bir kanaat alırsınız. Ölçüm olmadan sonraki her karar, daha büyük parçalar, farklı bir embedding modeli, yeniden sıralama eklemek, daha uzun bir sistem promptu, mühendislik kılığına girmiş bir yazı tura atışıdır. Altı hafta boyunca bir veri hattını ayarlayıp, ölçülebilir biçimde başladığı noktada bitiren ekipler gördük; çünkü odadaki tek geri bildirim döngüsü son üç cevabın nasıl hissettirdiğiydi.

Değerlendirme, canlıya çıkmadan önce bir kez koşulan bir aşama değildir. Sonraki her değişikliği denemeyi güvenli kılan gösterge panelidir. Yatırım gerçektir: orta ölçekli bir korpus için kullanılabilir bir değerlendirme kümesi hazırlamak tipik olarak üç ila altı kişi-gün alır, artı bunu canlı tutmak için ayda birkaç saat. Karşılığında, bir değişikliğin recall@10 değerini 0,71'den 0,84'e çıkardığını ve sadakati sabit bıraktığını söyleyebilirsiniz; bu, yönetim komitesine götürebileceğiniz bir cümledir. Bu yazı, model ailelerini kamuya açık kıyaslamalarda karşılaştıran genel model değerlendirmesi yazısından bilinçli olarak daha dardır. Burada test edilen sistem sizin veri hattınız, sizin belgeleriniz ve sizin kullanıcılarınızdır.

İki Sistem, İki Farklı Hata Türü

RAG sistemi, en az iki bağımsız aşamadan oluşan bileşik bir makinedir. Erişim katmanı hangi pasajların bağlam penceresine gireceğine karar verir. Üretim katmanı ise bu pasajlar verildiğinde ne söyleneceğine karar verir. Bu iki aşama tamamen farklı nedenlerle bozulur ve tamamen farklı düzeltmelere yanıt verir; yalnızca nihai cevabı ölçerseniz ikisini birbirinden ayıramazsınız. Aritmetik acımasızdır çünkü aşamalar çarpılır. Erişim katmanı yeterli pasajı bağlama zamanın yüzde 80'inde koyuyorsa ve model bu pasaj oradayken onu zamanın yüzde 90'ında sadakatle kullanıyorsa, tavanınız yüzde 72'dir ve hiçbir prompt mühendisliği sizi bu erişim sınırının ötesine taşımaz. Bu tavanı yükseltmenin tek yolu, hangi aşamanın kaybettirdiğini ayrı ayrı ölçmek ve düzeltmeyi doğru katmana uygulamaktır.

Bu çarpım, uçtan uca doğruluğun neden kötü bir ilk metrik olduğunu açıklar. Bir çarpım sonucudur; düşerse sistemin kötüleştiğini söyler ama hangi çarpanın hareket ettiğini söylemez. Daha kötüsü, iki çarpan sorunları gizleyecek biçimde birbiriyle takas edilir. Aday kümesini genişletmek recall değerini yükseltir ve kesinliği düşürür; bu genellikle uçtan uca kaliteyi biraz artırır ve sessizce sadakati zorlaştırır, çünkü model artık üzerine yaslanabileceği, makul görünen daha fazla alakasız metne sahiptir. Uçtan uca sayının sabit kaldığını görüp hiçbir şeyin değişmediği sonucuna varırsınız; oysa iki şey zıt yönlerde değişmiştir ve hangisini tutacağınıza dair fikriniz yoktur.

Bunun pratik sonucu, tek değil iki test düzeneği kurmanızdır. Erişim düzeneği hiçbir dil modeline ihtiyaç duymaz. Bir soru alır, erişim katmanını çalıştırır ve dönen parça kimliklerini etiketlenmiş ilgili parça kümesiyle karşılaştırır. Koşum başına maliyeti sıfırdır, birkaç yüz soruda saniyeler içinde biter ve bu nedenle her commit'te çalışabilir. Üretim düzeneği daha yavaştır ve çıkarım ile genellikle bir hakem modeli içerdiği için koşum başına para harcar; bu yüzden daha seyrek, daha küçük bir küme üzerinde ve erişim gürültüsünün üretim sinyalini kirletmemesi için sabitlenmiş bağlamlarla çalışır. Bu ayrımı kurmayan ekipler her regresyon koşumunda hem para hem zaman harcar ve birkaç ay içinde değerlendirmeyi tamamen bırakır.

Erişim Metrikleri: recall@k, precision@k, MRR ve NDCG

Recall@k, RAG için başlık sayısıdır ve tek bir erişim metriği takip edecekseniz bunu takip edin. Basit bir soru sorar: her test sorgusu için, etiketlenmiş ilgili parçalardan en az biri, çok adımlı durumlarda ise hepsi, ilk k sonuç içinde göründü mü? k değeri keyfi değildir. Yeniden sıralama sonrası bağlam penceresine gerçekten kaç parça koyduğunuza, tipik olarak beş ila sekize eşlenmeli ve ikinci bir ölçüm de yeniden sıralama öncesi aday derinliğinizde, tipik olarak 20 ila 100'de yapılmalıdır. recall@50 ile recall@5 arasındaki fark, tam olarak sıralama katmanınızın çöpe attığı kalite miktarıdır ve genellikle tüm sistemdeki en ucuz düzeltmedir.

Precision@k, yeni başlayanların sandığından daha az, deneyimlilerin kabul ettiğinden daha çok önemlidir. Daha az önemlidir çünkü modern bir model bir iki alakasız pasajı ciddi hasar almadan tolere eder. Daha çok önemlidir çünkü bağlam bir bütçedir ve geçirdiğiniz her alakasız parça token harcar, gecikme ekler ve modelin yanlış şeye yaslanması için bir yüzey açar. Kesinlik kaybı aynı zamanda uzun bağlam cazibesinin de mekanizmasıdır: ekipler erişimi ayarlamayı bırakıp daha fazla metin geçirir ki bu tam olarak uzun bağlam mı RAG mı karşılaştırmasında incelenen takastır. Altı parçanın yeteceği yerde altmış parça geçirmek dayanıklılık değil, ölçülmemiş bir maliyettir.

MRR ve NDCG, recall'ın yakalayamadığı bir şeyi yakalar: iyi pasajın listenin neresine düştüğünü. Ortalama karşılıklı sıra (mean reciprocal rank), ilk ilgili sonucu sekizinci sıraya değil birinci sıraya koymayı ödüllendirir. NDCG buna ek olarak dereceli ilgililiği ele alır, böylece soruyu tam cevaplayan bir parça, konuya sadece değinen bir parçadan daha çok sayılır ve konuma göre indirim uygular, dolayısıyla geç gelen isabetler daha az katkı verir. Recall iyi olsa bile sıra önemlidir, çünkü modeller uzun bir bağlamda dengesiz dikkat dağıtır ve on ikinci sıraya gömülmüş ilgili bir pasajın kullanılma ihtimali, aynı pasajın ikinci sıradaki halinden belirgin biçimde düşüktür.

Bağlam Kesinliği ve Bağlam Recall'ı: Sıraları Değil Pasajları Yargılamak

Sıra metrikleri, her parça-sorgu çifti için temiz bir ikili etiketiniz olduğunu varsayar; bunu üretmek pahalıdır ve parçalama stratejiniz değiştiğinde kırılgandır. Ragas gibi çerçevelerin yaygınlaştırdığı bağlam kesinliği ve bağlam recall'ı ikilisi, bunun yerine referans cevaptan çalışarak bu sorunu aşar. Bağlam recall'ı, doğru kabul edilen cevabı tek tek iddialara ayırır ve bu iddiaların ne kadarının getirilen bağlamda desteklendiğini sorar. Bağlam kesinliği ise destekleyici materyal taşıyan parçaların, taşımayanların önünde sıralanıp sıralanmadığını sorar. Her ikisi de metin eşleştirmesiyle değil bir hakem modeliyle hesaplanır; onları yeniden ifade etmeye ve parça sınırı değişikliklerine karşı dayanıklı kılan da budur.

Maliyet profili farklıdır ve bunları bir ikame değil ikinci kademe olarak görmelisiniz. Her biri beş parça içeren 300 soruluk hakemli bir bağlam recall koşumu kabaca 1.500 hakem çağrısı demektir; bu dakikalar sürer ve gerçek para harcar, dolayısıyla commit öncesi bir kancaya değil gecelik bir işe aittir. Karşılığında bu metrikler yeniden parçalamayı hayatta atlatır. Parça boyutunu 800 token'dan 400'e düşürdüğünüzde elle etiketlediğiniz parça kimlikleri bir gecede anlamsızlaşır ve recall@k yeniden etiketlenmek zorunda kalır; bağlam recall'ı ise en baştan parça kimliğine bağlı olmadığı için çalışmaya devam eder. Pratikte gecelik koşumu sürüm adaylarıyla da tetikliyoruz ki bir sürüm hiçbir zaman yalnızca ucuz metriklerle onaylanmış olmasın.

En faydalı sinyal, iki metrik ailesinin birbiriyle çeliştiği yerden gelir. recall@10 değeri 1,0 ama bağlam recall'ı 0,4 olan bir sorgu, referans cevabın üç kaynağa ihtiyaç duyduğu yerde sizin bir tanesini bulduğunuz anlamına gelir: ikili recall'ın başarı olarak işaretlediği bir çok adımlı kapsama hatası. Ters örüntü, yani düşük recall@k ve yüksek bağlam recall'ı, genellikle ilgililik etiketlerinizin eskidiğini veya fazla katı olduğunu gösterir, çünkü erişim katmanı hiç etiketlemediğiniz bir belge üzerinden cevabı destekleyen materyal bulmuştur. Her iki çelişki de elle okunmaya değer. Deneyimimizde incelediğiniz ilk on çelişki, sonraki yüz toplu koşumdan daha çok şey öğretir.

Üretim Metrikleri: Sadakat, İlgililik ve Atıflar

Sadakat, bazen dayanaklılık olarak da anılır, üretim tarafının başlık metriğidir. Ölçüm örüntüsü iddia ayrıştırmasıdır: üretilen cevabı atomik olgusal ifadelere bölün, sonra her ifadeyi getirilen bağlama karşı kontrol edin ve desteklenen oranı puanlayın. Beş cümlelik bir cevap sekiz iddiaya ayrışabilir, bunların yedisi dayanaklıysa puan 0,875 olur. Bu ayrıntı düzeyi önemlidir çünkü aksi halde doğru olan bir cevabın içindeki tek bir desteksiz yan cümle, kullanıcı güvenini yok eden hata biçiminin ta kendisidir ve cevabın tamamına verilen ikili bir puan bunu göremez. Yanlış bir ifadenin hukuki veya mali sonuç doğurduğu sistemlerde toplam sadakati 0,95'in altında olan hiçbir sürümü yayına almıyoruz ve ortalamaya değil dağılıma bakıyoruz.

Cevap ilgililiği ayrı bir eksendir ve ekipler bu ikisini sürekli birbirine karıştırır. Kusursuz dayanaklı bir cevap yine de komşu bir soruyu cevaplayarak, cevabı üç paragraflık girizgahın içine gömerek veya bağlam açıkça doğrudan bir ifadeyi desteklerken taahhütten kaçınarak başarısız olabilir. Olağan ölçüm, yanıtın sorulan spesifik soruyu ele alıp almadığını puanlayan bir hakemdir; tercihen birden ona kadar değil üç kademeli bir ölçekle, çünkü hakemler kaba ölçeklerde çok daha tutarlıdır. Bunu sadakatle birlikte izleyin, çünkü ikisi birbirini çeker: dayanaklılığı sert biçimde zorlayan promptlar çekingen, kaçamak ve düşük ilgililikli cevaplar üretme eğilimindedir ve bu takası görmek için iki sayıya da ihtiyacınız vardır.

Atıf doğruluğu aslında tek bir isim taşıyan üç ayrı ölçümdür. Birincisi, atıf yapılan bölüm getirilen bağlamda gerçekten var mı, yoksa model bir kaynak kimliği mi uydurdu? İkincisi, atıf yapılan pasaj bağlandığı iddiayı gerçekten destekliyor mu, yoksa yalnızca konu olarak mı yakın? Üçüncüsü, mevcut en iyi kaynak mı, yoksa yetkili hüküm de bağlamdayken model bir özete mi atıf yaptı? İlk ikisini atıf kesinliği ve atıf recall'ı olarak puanlıyor ve ayrı izliyoruz, çünkü uydurulmuş kimlikler sert bir engelken kaynak seçiminin yetersizliği bir ayar meselesidir. Düzenlemeye tabi alanlarda 0,98'in altındaki atıf kesinliği bir metrikten çok bir kusur olarak ele alınma eğilimindedir.

Reddetmeler ve Korpus Dışı Soru Kümesi

Hevesli bir ekip tarafından hazırlanmış gördüğümüz her değerlendirme kümesi yalnızca korpusun cevaplayabildiği soruları içeriyordu ve bu tür her küme kaliteyi geniş bir farkla olduğundan iyi gösteriyordu. Gerçek kullanıcılar hiç indekslemediğiniz şeyleri, silinmiş şeyleri, alanınıza komşu şeyleri ve alanınıza benzeyen ama olmayan şeyleri sorar. Bir olumsuz kümeye ihtiyacınız var: sistemin cevaplamayı reddetmesi gereken sorular. Değerlendirme kümesinin kabaca yüzde 15 ila 20'sinin tasarım gereği cevaplanamaz olmasını hedefliyoruz; bunu da açıkça kapsam dışı sorular ile kelime dağarcığı korpusla büyük ölçüde örtüşen ama cevabı gerçekten mevcut olmayan kıl payı sorular arasında bölüyoruz. Bu oranı bir kez belirledikten sonra sabit tutun; olumsuz kümeyi küçültmek raporlanan kaliteyi anında ve tamamen yapay biçimde yükseltir.

Olumsuz sorular, ayrı ayrı izlenmesi gereken iki hata oranı üretir, çünkü düzeltmeleri birbirinin tersidir. Yanlış cevap oranı, cevaplanamaz soruların sistem tarafından yine de cevaplanan kısmıdır; sosyal medyada ekran görüntüsü olarak dolaşan halüsinasyon yüzeyi budur. Aşırı reddetme oranı ise cevaplanabilir soruların sistem tarafından reddedilen kısmıdır; bu da insanların hiç şikayet kaydı açmadan sistemi kullanmayı bırakmasına yol açan sessiz hatadır. Promptu sıkılaştırmak veya bir benzerlik eşiğini yükseltmek bu ikisini neredeyse doğrusal biçimde takas eder ve iki sayıya birden sahip olmadan birini yerin dibine optimize edersiniz. Bu yüzden her sürüm notunda iki oranı yan yana yazıyoruz ve hangisinin bilinçli olarak takas edildiğini açıkça kaydediyoruz.

Asıl mühendislik kıl payı sorularda yaşanır ve bunları bilinçli olarak kurmaya değer. Tam zamanlı çalışanları kapsayan bir politikayı alın ve taşeron çalışanları sorun. A modelini belgeleyen bir şartnameyi alın ve B modelini sorun. Belirli bir tarihten itibaren geçerli olan bir düzenlemeyi alın ve öncesindeki dönemi sorun. Her durumda erişim katmanı yüksek benzerlikli pasajlar döndürecektir, çünkü kelime dağarcığı neredeyse kusursuz eşleşir; üretim katmanının ise getirilen metnin sorulan durumu aslında kapsamadığını fark etmesi gerekir. Standart sorularda yüksek puan alan sistemler burada sıklıkla çöker ve olgunlaşan bir değerlendirme kümesine eklediğimiz en verimli test bloğu budur.

Yaşayan Bir Varlık Olarak Altın Veri Kümesi

Önce boyut, çünkü bunu herkes soruyor. İlk canlı sürüm için 150 ila 300 etiketli kalem hedefliyoruz; bu, gerçek büyüklükteki bir değişiklik için metriği gürültü bandının dışına çıkarmaya yeter. Haftalık regresyon koşan olgun bir sistem 500 ila 1.000 ister. Kabaca 100 kalemin altında güven aralıklarınız o kadar geniştir ki beş puanlık bir hareket hiçbir şey ifade etmez ve gürültünün peşinde koşarsınız. Tekdüze örneklemek yerine katmanlandırın: belge türüne, soru türüne, zorluğa ve cevabın tek mi yoksa birden çok kaynak mı gerektirdiğine göre kovalara ayırın. Metrikleri toplamın yanı sıra katman bazında raporlayın, çünkü ortalama, politikalarda mükemmel ama tablolarda işe yaramaz olduğunuzu gizler.

Soruları hayal gücünden değil gerçeklikten toplayın. En iyi kaynaklar sırasıyla şunlardır: destek talepleri ve yardım masası kayıtları, bu sistemin yerini alacağı mevcut arama üzerinde zaten çalışan sorgular, kapsam belirleme sırasında yaptığınız görüşmelerin dökümleri ve beş ila on alan uzmanının kendilerine gerçekten sorulan soruları yazdığı yapılandırılmış oturumlar. Korpusun sessiz köşelerinin kapsamasını doldurmak için bir dil modeliyle soru üretmek kabul edilebilir; ancak kümenizin üçte birinden fazlası sentetikse, cevabı önce okumuş bir modelin yazdığı soruları sisteminizin ne kadar iyi cevapladığını ölçüyorsunuz demektir ve bu, gerçek görevden çok daha kolaydır. Sentetik soruların oranını da metadata olarak saklayın ki raporlarda gerçek ve üretilmiş sorular her zaman ayrı ayrı görülebilsin.

Etiketleme, genellikle gördüğünden daha fazla titizlik hak eder. Her kalem soruyu, bir referans cevabı, onu destekleyen pasajların kimliklerini ve bir zorluk ile kategori etiketini taşımalıdır. Kümenin örtüşen yüzde 20 ila 30'unu iki etiketleyiciye bağımsız olarak etiketletin ve hiçbirine güvenmeden önce uyumu ölçün. Cohen kappa değeri kabaca 0,6'nın altına düşerse, sorun etiketleyicilerin özensizliği değil ilgililik tanımınızın muğlaklığıdır ve çözüm daha fazla eğitim değil, işlenmiş örneklerle keskinleştirilmiş bir yönergedir. Anlaşmazlıkları kısa bir oturumda karara bağlayın ve varılan sonuçları yönergeye geri işleyin. Yönergenin her sürümünü de kümenin yanında sürümleyin, çünkü etiketlerin anlamı yönergeye bağlıdır ve yönerge sessizce değişirse eski etiketler karşılaştırılamaz hale gelir.

Sonra kümeyi sahibi olan yaşayan bir varlık gibi ele alın. Üst kademeye taşınan her canlı hatası bir hafta içinde, doğru cevabı ve doğru kaynakları eklenmiş biçimde bir test vakasına dönüşür. Korpusa eklenen her yeni belge türü beraberinde beş ila on yeni kalem getirir. Sağlıklı bir küme ilk yılda çeyrek başına kabaca yüzde 10 ila 20 büyür, sonra dengelenir. Kodla aynı depoda sürümleyin, değişiklikleri pull request içinde inceleyin ve bir kalemi yalnızca başarısız olmaya başladı diye sessizce silmeyin. Bir değerlendirme paketini güvenilir biçimde dekorasyona çeviren tek alışkanlık budur. Kümenin belirli bir sahibi olmalı; sahipsiz bir değerlendirme kümesi altı ay içinde güncelliğini kaybeder ve kimse fark etmez.

Hakem Olarak LLM ve Ona Nasıl Güvenilir?

Sadakat, ilgililik ve atıf desteği metin eşleştirmesiyle puanlanamaz ve ihtiyaç duyduğunuz sıklıkta her regresyon koşumunu insanlara puanlatmak sürdürülebilir değildir. Bu yüzden hakem olarak bir model kullanırsınız; bu, sezginin düşündürdüğünden çok daha iyi, satanların söylediğinden çok daha kötü çalışır. Önemli tasarım kuralları basittir. Hakeme soruyu, getirilen bağlamı ve cevabı verin ve genel bir kalite hükmü yerine her seferinde tek bir dar karar isteyin. Kaba ölçekler kullanın, ikili veya üç kademeli, çünkü hakemler bunlarda gözle görülür biçimde daha tutarlıdır. Etiketten önce kısa bir gerekçe isteyin ve bunu kaydedin, çünkü hakemin kendisinde hata ayıklamanızı sağlayan şey o gerekçelerdir.

Kalibrasyon, ekiplerin atlayıp sonra pişman olduğu adımdır. 50 ila 100 kalem alın, bir insan uzmana aynı yönergeye göre etiketletin ve hakemin ne sıklıkta hemfikir olduğunu ölçün. İkili bir kararda kabaca yüzde 80 uyumun altında hakem kullanılabilir değildir ve model değiştirilmesi değil yönergenin yeniden yazılması gerekir. Yaklaşık yüzde 90'ın üzerinde ise periyodik kontroller arasında gözetimsiz çalıştırabilirsiniz. Standart yanlılıklara dikkat edin: hakemler daha uzun cevapları ödüllendirir, sorunun ifadesini yankılayan cevapları ödüllendirir ve aynı model ailesinin yazdığı metne karşı daha cömerttir. İkili karşılaştırmalardaki konum yanlılığı, her iki sıralamayı da çalıştırıp ortalamayı almanızı gerektirecek kadar ciddidir.

Hakemler kayar ve kayan bir hakem, hakemsizlikten kötüdür çünkü sisteminizi hareket ettirmeden sayılarınızı hareket ettirir. Hakem modelini belirli bir sürüme sabitleyin ve sürüm değişikliğini yeniden kalibrasyon gerektiren bir kod değişikliği gibi ele alın. İnsan etiketli kalibrasyon kümesini dondurun ve hakem sürümü, yönerge veya prompt şablonu değiştiğinde yeniden koşun; uyum oranını raporlanan her metriğin yanında kaydedin ki kimse farklı hakemlerin ürettiği iki sayıyı karşılaştırmasın. Bu, sistemi kurmaktan çok işletmeye ait olan ve canlıda değerlendirme ve gözlemlenebilirlik yazısının konusunu oluşturan disiplinlerden yalnızca biridir. Kalibrasyon kümesini üretim verisinden de ayrı tutun ki hakem yönergesi zamanla o kümeye aşırı uyum sağlayıp gerçek dağılımı temsil etmeyi bıraksın.

Ayrıştırma ve CI'daki Regresyon Kapıları

Bir cevap yanlış olduğunda ilk soru hep aynıdır: erişim katmanı kanıtı sağlamayı mı beceremedi, yoksa üretim katmanı onu kullanmayı mı beceremedi? Kusursuz bağlam ayrıştırması bunu tek koşumda çözer. Başarısız soruları alın, getirilen bağlamı etiketlenmiş doğru pasajlarla değiştirin ve yeniden üretin. Cevaplar doğru hale geliyorsa darboğazınız erişimdir ve prompt çalışması boşa emektir. Elde kusursuz kanıt varken hâlâ yanlışsa sorun üretimdedir: prompt, talimat hiyerarşisi, model seçimi veya ilgili pasajın göz ardı edilmesine yol açacak kadar kalabalık bir bağlam penceresi. Bu ayrıştırmayı, herhangi birinin düzeltme önermesine izin verilmeden önce her hata partisinde çalıştırıyoruz.

Darboğaz erişimse, ikinci bir ayrıştırma sorunu daha da daraltır. Tam aday derinliğinizde, tipik olarak 50 veya 100, recall ölçün ve bunu beş ila sekizlik nihai derinliğinizdeki recall ile karşılaştırın. recall@100 yüksek ama recall@5 kötüyse doğru belge bulunuyor ve sonra sıralamayla eleniyor demektir; bu, hibrit arama ve yeniden sıralama yazısında doğrudan ele alınan bir sıralama ve birleştirme sorunudur. recall@100 de kötüyse belge aday kümesine hiç girmiyordur ve neden yukarıda, ayrıştırmada, parçalamada veya indekslemededir. Bu iki dal tamamen farklı haftalara giden işlerdir ve aralarında tahmin yürütmek, ekiplerin bir sprinti çöpe atmasının en yaygın yoludur.

Sonuçları CI'ya kapı olarak bağlayın. Erişim paketi ucuz ve belirlenimcidir, dolayısıyla erişim koduna, indeks yapılandırmasına veya parçalama hattına dokunan her pull request'te çalışır ve birkaç yüz soruda bir dakikanın altında biter. Üretim paketi geceleri ve sürüm adaylarında çalışır. İki tür eşik kullanın: işin ihtiyacını kodlayan mutlak tabanlar, örneğin recall@5 için 0,85 ve sadakat için 0,95, ve önceki sürüme kıyasla izlenen herhangi bir metrik iki üç puandan fazla düştüğünde derlemeyi başarısız kılan göreli regresyon deltaları; ikincisi, tabanların hiç fark etmediği yavaş aşınmayı yakalar. Kapıların çalışma süresini de izleyin; yavaşlayan bir paket, eninde sonunda atlanan bir pakete dönüşür.

Bir kapı ancak geçilememesi bir bedel doğuruyorsa işe yarar. Kimin bunu geçersiz kılabileceğine önceden karar verin, geçersiz kılmanın pull request içinde metriği ve gerekçeyi adlandırmasını zorunlu tutun ve buna kesin bir son kullanma tarihi koyun. En sık gördüğümüz hata biçimi kötü bir kapı değil, kararsız çalıştığı için herkesin atlamayı öğrendiği bir kapıdır; bunun nedeni de genellikle üretim paketinin sıfırdan farklı bir sıcaklıkla koşulmasıdır. Bunu, değerlendirme koşumlarında sıcaklığı sıfıra sabitleyerek, model ve prompt sürümlerini sabitleyerek ve sınırdaki her sonucu regresyon ilan etmeden önce üç kez tekrarlayarak düzeltin. İnsanların güvendiği bir kapı, teknik olarak daha katı olan bir kapıdan değerlidir.

HatsonTech'te RAG Değerlendirmesini Nasıl Yürütüyoruz?

Kendi ürünlerimizde değerlendirme kümesini erişim katmanından önce kuruyoruz. caseon.ai ve DiligenceAI tarafında bir erişim iş kolundaki ilk teslimat, referans cevapları ve etiketlenmiş kaynak pasajları olan katmanlandırılmış bir soru kümesidir ve bu küme, sistemi nasılsa sonunda yargılayacak olan alan uzmanlarıyla birlikte mutabık kalınarak hazırlanır. Yaklaşık bir hafta boyunca yavaş hissettirir, sonra kendini sürekli olarak amorti eder, çünkü o noktadan itibaren her mimari tartışmanın bir çözüm prosedürü vardır. Biri farklı bir embedding modeli önerir, kümeye karşı koştururuz ve tartışma iki hafta sürmek yerine bir öğleden sonrada biter. Bu erken yatırımın ikinci faydası, alan uzmanlarının projeye teslimattan aylar önce ve somut bir çıktı üzerinden dahil olmasıdır.

Tutarlı biçimde gördüğümüz şey, erişim düzeltmelerinin model yükseltmelerini geride bıraktığıdır. Özellikle Türkçe korpuslarda recall'daki en büyük tek sıçramalar, üreteci değiştirmekten değil ayrıştırma ve cümle bölütleme çalışmasından geldi; ölçekte belge parçalamayı birinci sınıf bir mühendislik problemi olarak ele almamızın ve Türkçe hukuk verisiyle RAG kurmakta anlatılan alana özgü işlemenin ayrı bir disiplin olarak var olmasının nedeni budur. İkinci en yaygın bulgu, daha geniş bir aday kümesi üzerinde çalışan mütevazı bir yeniden sıralama modelinin, işletme maliyetinin çok altında bir bedelle daha büyük bir üreteci geçtiğidir. Üçüncü tekrar eden bulgu ise metadata filtrelerinin, hiçbir model değişikliğinin çözemediği tarih ve sürüm hatalarını tek başına ortadan kaldırmasıdır.

Bir RAG projesi üstlendiğimizde değerlendirme altyapısı opsiyonel bir kalem değil kapsamın parçasıdır ve müşteride kalır: veri kümesi, test düzeneği, CI yapılandırması ve kalibrasyon kayıtları, hepsi kendi deposunda ve bizsiz çalıştırılabilir halde. 50.000 ila 200.000 belgelik bir korpusta ilk değerlendirme yapısı, veri hattı çalışmasıyla birlikte tipik olarak iki ila üç hafta sürer. Bugün canlıda bir RAG sistemi çalıştırıyor ve recall@5 değerini söyleyemiyorsanız, önce kapatılması gereken boşluk budur ve RAG ve anlamsal arama çözümlerimiz tam olarak bu boşluğu kapatmak üzere kurgulanmıştır. Bu devir teslim, ekibinizin bizden bağımsız olarak sistemi geliştirmeye devam edebilmesi için alınmış kasıtlı bir tasarım kararıdır.