RAG nedir, hata ayıklama neden gerekir?
Bir kurum içi bilgi asistanı yanlış yanıt verdiğinde sorun her zaman dil modelinde değildir. Güncel belge dizine alınmamış, bir paragraf eksik çıkarılmış veya doğru kaynak kullanıcı yetkisi nedeniyle aramadan elenmiş olabilir. RAG, yani retrieval augmented generation, ilgili belgelerden getirilen bilgiyi dil modelinin girdisine ekleyerek yanıt üretme yöntemidir. Microsoft'un RAG açıklaması bu akışı getirme, bağlama ekleme ve üretim olarak ayırır. Hata ayıklama da aynı ayrımı izlemelidir: yanlış bilginin zincire ilk nerede girdiğini bulun.
Örneğin bir çalışan seyahat masrafı sınırını sorar, asistan eski tutarı söyler. Yanıt eski belgeye sadıksa üretim doğru çalışmış olabilir; iş açısından sonuç yine yanlıştır. Başka bir olayda güncel tutar bağlamda vardır ama model istisna koşulunu atlar. İki olayın ekranda görünen belirtisi benzer, düzeltmesi farklıdır. İlki belge sürümü ve alım hattı, ikincisi bağlam kullanımı üzerinden incelenir.
RAG hata ayıklama, tek bir başarısız soruyu kanıtlarıyla yeniden çalıştırıp alım, yetki, arama, sıralama, bağlam, üretim ve atıf aşamalarını ayrı sınamaktır. Bu yaklaşım, rastgele parça boyutu veya model değiştirme döngüsünü kısaltır. Başarıyı akıcı bir metinle ölçmeyin: yanıt soruyu karşılamalı, geçerli kaynağa dayanmalı ve kullanıcının erişim sınırını korumalıdır.
Hatalı yanıt için arama ve üretim hata ağacı
Aşağıdaki tabloyu bir olay kaydının karar aracı olarak kullanın. Üstten başlayın ve ilk başarısız kontrolde o aşamanın kanıtını saklayın. Sonraki aşamalar da hatalı olabilir; ancak henüz dizine ulaşmamış bir cümleyi sıralama ayarıyla bulmaya çalışmayın. “Kaynak var mı?” sorusu, dosyanın ortak sürücüde bulunmasını değil, geçerli sürümünün aranabilir metin ve kimlikle dizinde bulunmasını anlatır.
| Kontrol | Başarısızlık kanıtı | İlk inceleme |
|---|---|---|
| Kaynak dizinde mi? | Güncel belge veya gerekli cümle eksik | Alım, çıkarılan metin, belge sürümü |
| Kullanıcı kaynağa yetkili mi? | İzinli pasaj filtreyle eleniyor | Kimlik, grup, kiracı, yetki sürümü |
| Arama doğru pasajı buluyor mu? | Aday listesinde yok veya sırası düşük | Sorgu, parça sınırı, arama türü |
| Pasaj son bağlama giriyor mu? | Sıralandıktan sonra kesiliyor veya özetleniyor | Bağlam bütçesi, birleştirme, özet |
| Yanıt kanıtı doğru kullanıyor mu? | Tarih, koşul veya istisna atlanıyor | Sabit kanıtla üretim testi |
| Atıf iddiayı destekliyor mu? | Başka sayfa veya komşu bölüm gösteriliyor | İddia, pasaj ve bağlantı eşleşmesi |
Ağacın dallanma kuralı şudur: doğru ve izinli kanıt son bağlamda yoksa getirme zincirine, varsa üretim ve atıf zincirine gidin. Kullanıcının belgeyi okumaya yetkisi yoksa bulunamaması beklenen davranıştır. Böyle bir vakayı arama başarısızlığı diye işaretlemeyin. Aynı soru için hem yetkili hem yetkisiz test kimliği oluşturun; birinin düzeltmesi diğerine bilgi sızdırmamalıdır. Düzeltilecek aşamayı belirledikten sonra diğer ayarları sabit tutun.
Tekrar üretilebilir bir RAG kaydı nasıl tutulur?
Üretim hatasını incelemeden önce isteğe kalıcı bir iz kimliği verin. Bu kimlik sorguyu, arama çağrılarını ve son model girdisini birbirine bağlasın. Kayıt şeması yalnızca son yanıtı tutarsa sorunun kaynağı sonradan anlaşılamaz. Her olay için şu alanları ayırın:
- Soru ve konuşma: Özgün soru, kullanılan önceki mesajlar, dil ve varsa yeniden yazılmış arama sorgusu.
- Yetki kapsamı: Test kullanıcısı, etkin gruplar, kiracı, uygulanan filtre ve yetki eşitleme zamanı.
- Belge kökeni: Kaynak kimliği, sürüm, geçerlilik tarihi, alım zamanı ve çıkarılan metnin sürümü.
- Arama izi: Aday pasaj kimlikleri, arama türü, sıralar, puanlar ve yeniden sıralama sonrası liste.
- Üretim girdisi: Modele gerçekten gönderilen pasajlar, sıraları, istem sürümü, model sürümü ve ayarlar.
- Çıktı ve değerlendirme: Yanıt, atıflar, beklenen kanıt, hata sınıfı, gecikme ve yapılan düzeltme.
İstemci ekranındaki kaynak listesiyle modelin aldığı bağlamı aynı sanmayın. Uygulama arada pasajları kısaltmış veya birleştirmiş olabilir. Yeniden oynatma için gereken içeriği yetkili bir alanda, belirlenmiş saklama süresiyle tutun; paylaşılacak örnekten kişisel veriyi çıkarın. Maskeleme, sorunun anlamını değiştirmemelidir. Müşteri adını tutarlı bir yer tutucuyla değiştirmek uygundur; karar için gerekli tarih veya tutarı silmek testi geçersiz kılabilir. Eski olayı yeniden çalıştırırken o günün dizin ve yetki sürümünü kullanın; güncel erişimle eski erişimi karıştırmayın.
Arama hatası mı, model hatası mı?
Önce beklenen pasajı belge kimliğiyle bulun ve çıkarılan metni özgün dosyayla karşılaştırın. PDF'de yan yana duran sütunlar metinde karışmışsa veya tablo başlığı kaybolmuşsa embedding, yani metnin sayısal anlam temsili, eksik girdiden üretilmiştir. Arama ayarı bu metni onaramaz. Microsoft'un belge parçalama rehberi cümle yapısını, bölüm bağlamını ve parçalar arası örtüşmeyi dikkate alır. Parça boyutunu değiştirmeden önce gerekli koşulun kendi cümlesiyle birlikte kaldığını doğrulayın.
Metin sağlamsa aynı sorguyu aynı filtreyle anahtar sözcük, vektör ve hibrit aramada çalıştırın. Ürün kodu veya politika numarası vektör aramada geri düşerken tam eşleşmeyle bulunabilir. Azure AI Search hibrit arama açıklaması, metin ve vektör sonuçlarını paralel getirip RRF ile birleştirdiğini belirtir. Farklı yöntemlerin ham puanlarını tek eşik gibi yorumlamayın; beklenen pasajın sırasını ve son bağlama girip girmediğini karşılaştırın.
Sonra yalnızca doğrulanmış, izinli pasajı üreticiye verin; soru, istem ve model ayarları aynı kalsın. Yanıt düzelirse arama, sıralama veya bağlam paketleme aşamasına dönün. Düzelmezse modelin tarihi, olumsuz ifadeyi veya istisnayı neden atladığını sınayın. Bu deney kusuru daraltır; az pasajlı girdinin başarılı olması, daha uzun bağlamdaki model davranışını tek başına açıklamaz.
Üçüncü karşılaştırmada özgün bağlamı aynı sıra ve bütçeyle yeniden verin. Doğru pasajla birlikte çelişkili eski bir sürüm varsa geçerlilik alanlarını ve sürüm seçimini inceleyin. İstemi değiştiriyorsanız beklenen davranışı açıklaştırın: koşulları korumak, çelişkiyi belirtmek ve yeterli kanıt yoksa yanıt vermemek. Atıfları da ayrı değerlendirin; doğru tutara ulaşan ama başka sayfayı gösteren yanıt tamamlanmış sayılmamalıdır.
Örnek: seyahat politikasındaki eski tutarı teşhis etmek
Varsayımsal bir kurumda 100 soruluk değerlendirme kümesi ve 1.200 belge olduğunu düşünün. Yeni seyahat politikası şehir içi konaklama sınırını 1.500 TL'den 2.000 TL'ye çıkarmış olsun. Bu tutarlar ve aşağıdaki sonuçlar yalnızca örnektir. Asistan 100 sorunun 70'inde hem doğru yanıt hem doğru atıf verir. Kalan 30 vaka aynı “yanlış yanıt” başlığı altında toplanırsa ekip doğrudan daha büyük modele geçmeyi önerebilir.
Hata ağacıyla incelemede 10 sorunun güncel belgesi dizine alınmamıştır. Sekiz soruda doğru pasaj adaylar arasındadır ama ilk beşin dışında kalır. Yedi soruda gerekli kanıt son bağlamdadır, fakat model “yalnızca şehir içi” koşulunu atlar. Beş soruda tutar doğrudur; atıf eski politikanın sayfasına gider. İlk iki grup birlikte 18 vaka, yani hataların %60'ıdır. Model değiştirmek bu grubun temel nedenini çözmez.
Önce alım hattındaki eksik belgeleri tamamlayın; ardından sıralama değişikliğini yalnızca sekiz vakada ve diğer 92 soruda sınayın. Yedi üretim vakasını sabit kanıtla, beş atıf vakasını iddia ve sayfa eşleşmesiyle test edin. Her düzeltmenin kazanımını kendi hata sınıfında ölçün. Daha çok pasaj eklemenin gecikmeyi artırıp doğru yanıtları bozmadığını da kontrol edin. Bu sayıların hiçbiri bir ürünün başarı oranı veya Hatson müşteri sonucu değildir.
Düzeltme RAG değerlendirme metrikleriyle nasıl ölçülür?
LangSmith RAG değerlendirme rehberi yanıt doğruluğu, soruya uygunluk, kanıta bağlılık ve getirilen belgelerin uygunluğunu ayrı değerlendirir. Tek toplam puan yerine şu gerileme planını uygulayın:
- Beklenen kanıtı etiketleyin: Her soruya izinli belge sürümlerini, gerekli pasajları ve kabul edilecek yanıtı yazın; koşul içeren soruda yalnızca ana cümle yeterli değildir.
- Aramayı ölçün: İlk beş sonuçta gerekli pasajların kaçının bulunduğunu hesaplayın. İki gerekli pasajdan biri gelirse o soru için kanıt kapsamı %50'dir; bunu yanıt doğruluğundan ayrı tutun.
- Üretimi ölçün: Yanıtın tarih, tutar ve istisnaları korumasını, her iddianın son bağlamla desteklenmesini ve atıf eşleşmesini ayrı puanlayın.
- Olumsuz vakaları ekleyin: Kaynağı olmayan, çelişkili sürümlü ve yetkisiz sorularda beklenen davranışı yazın. Yanıt vermemesi gereken durumda akıcı cevap başarı değildir.
- Sürüm karşılaştırması yapın: Aynı sabit kümede yalnızca bir ayarı değiştirin; Türkçe, İngilizce, yeni belge ve erişim rollerindeki farkları ayrıca raporlayın.
- Yayın kapısı koyun: Kabul sınırlarını testten önce belirleyin, sızıntıda yayını durdurun ve kaliteyle birlikte gecikme ile maliyeti izleyin. Modelle puanlanan örneklerin bir bölümünü insanla denetleyin.
Sık yapılan hatalar
- Son yanıtı saklayıp modele gönderilen gerçek bağlamı kaybetmek; böylece aynı olayı yeniden üretememek.
- Modeli, parça boyutunu ve sıralamayı aynı denemede değiştirmek; iyileşmenin hangi adımdan geldiğini bilememek.
- Doğru belgeyi bulmak için yetki filtresini kapatmak ve güvenli aramayı bir sızıntı riskiyle değiştirmek.
- Yanıt doğruluğunu atıf doğruluğuyla birleştirmek; yanlış kaynak gösteren metni başarılı kabul etmek.
- Yalnızca bozulan soruyu sınamak; diğer dillerdeki ve belge sürümlerindeki gerilemeleri kaçırmak.
Hatson Tech bunu nasıl kuruyor?
RAG ve anlamsal arama çözümlerimizde işe kaynak envanteri, erişim kapsamı ve doğrulanmış sorularla başlıyoruz. Arama izini, model girdisini ve atıf eşleşmesini aynı olay kaydına bağlayıp düzeltmeleri sürümlü test kümesinde karşılaştırıyoruz. Ölçüm seçimi için RAG değerlendirme metrikleri yazımıza, erişim kaynaklı hatalar için yetki duyarlı arama rehberimize, sıralama seçenekleri için hibrit arama ve yeniden sıralama yazımıza bakabilirsiniz. Kurumunuzdaki ilk adım, başarısız bir soruyu bu kayıt şemasıyla yeniden üretip düzeltilecek aşamayı belirlemektir.