Güvenilirlik Sorunu Hangi Katmanda Başlar?

Retrieval-Augmented Generation (RAG), model yanıt üretmeden önce dış bilgi kaynaklarından bağlam getirir. Ancak arama katmanı eklemek, yanıtların otomatik olarak doğru olmasını garanti etmez. Hatalar genellikle üç noktada oluşur: ilgisiz belgelerin getirilmesi, doğru içeriğin eksik veya hatalı parçalanması ve modelin mevcut kanıtı yanlış yorumlaması.

Bu nedenle yalnızca “Yanıt doğru mu?” sorusuna bakmak yetersizdir. En az şu aşamalar ayrı değerlendirilmelidir:

• Beklenen belge veya pasaj arama sonuçlarında bulunuyor mu?
• Getirilen pasaj soruyu gerçekten destekliyor mu?
• Model, kanıtın kapsamını aşmadan yanıt veriyor mu?
• Yanıt, atıf yaptığı kaynakla çelişiyor mu?
• Kanıt yetersiz olduğunda sistem güvenli biçimde geri çekiliyor mu?

Bu ayrım, hatanın embedding modelinden mi, sorgu tasarımından mı, veri hazırlığından mı yoksa üretim katmanından mı kaynaklandığını belirlemeyi kolaylaştırır.

Belge Hazırlama ve Chunk Tasarımını Ölçmek

RAG kalitesinin önemli bir bölümü embedding aşamasından önce belirlenir. Başlık, bölüm adı, tablo açıklaması, belge sürümü ve yürürlük tarihi kaybolduğunda semantik olarak benzer görünen fakat bağlamı eksik parçalar üretilebilir. Sabit uzunlukta parçalama basit ve öngörülebilir olsa da teknik dokümanlarda cümle, madde veya bölüm sınırlarını bozabilir.

Uygulanabilir kontroller:

• Her parçanın belge, bölüm, sürüm, tarih ve erişim kapsamını metadata olarak koruyun.
• Çok kısa parçaların tek başına anlamlı olup olmadığını örnek sorularla inceleyin.
• Gerekirse bölüm başlığını ve üst başlıkları parçanın başına ekleyin; faydayı ölçmeden bunu varsayılan çözüm kabul etmeyin.
• Eski ve yeni sürümler birlikte getirildiğinde tarih veya sürüm önceliğini açıkça tanımlayın.
• Tabloları düz metne dönüştürürken satır-sütun ilişkilerinin bozulmadığını test edin.
• Gerçek kullanıcı sorularından oluşan, beklenen kaynakları işaretlenmiş küçük bir test kümesi hazırlayın.

İyi bir chunk yalnızca belirli sayıda karakter içeren parça değildir. Tek başına soruyu yanıtlamaya katkı sağlaması, gerekli bağlamı koruması ve komşu parçalarla gereksiz tekrar oluşturmaması gerekir. Overlap kullanımı sınırdaki bilgileri koruyabilir; ancak indeks boyutunu, maliyeti ve yinelenen bağlam gürültüsünü artırabilir.

Retrieval Değerlendirmesi ve Deney Tasarımı

Üretim modelini değiştirmeden önce retrieval katmanını izole ederek ölçmek daha sağlıklıdır. Her test sorusu için beklenen belge veya pasajları belirleyin. Ardından ilk sonuçlarda ilgili içeriğin bulunup bulunmadığını, doğru sırada gelip gelmediğini ve uygulanan filtreler nedeniyle elenip elenmediğini inceleyin.

Aşağıdaki değişkenleri tek tek karşılaştırabilirsiniz:

• Yalnızca vektör araması ile anahtar kelime ve vektör aramasının birlikte kullanılması.
• Kullanıcı sorgusunun doğrudan aranması ile sorgu yeniden yazımının kullanılması.
• Metadata filtrelerinin zorunlu tutulması veya yalnızca gerektiğinde uygulanması.
• İlk birkaç sonucun modele verilmesi ile daha geniş bir sonuç kümesinin yeniden sıralanması.
• Tek aşamalı retrieval ile ilk sonuçları ikinci bir sıralama adımından geçirme.

Her deneyde aynı soru kümesini mümkün olduğunca sabit tutun ve bir seferde tek değişkeni değiştirin. Ortalama başarıya ek olarak kritik sorularda yanlış belge oranını, ilgili belgenin ilk sonuçlarda bulunma oranını, cevapsız kalma oranını, gecikmeyi ve sorgu başına maliyeti izleyin. Daha fazla belge getirmek recall değerini artırabilir; fakat bağlam gürültüsü ve modelin yanlış kanıta yönelme ihtimali de artabilir.

Atıf, Kanıt Denetimi ve Güvenli Fallback

Bir RAG yanıtında kaynak gösterilmesi, yanıtın otomatik olarak doğrulandığı anlamına gelmez. Belge adı yerine mümkünse bölüm, sayfa, paragraf veya kayıt kimliği gibi daha dar bir referans sunulmalıdır. Atıf, yanıtın ilgili iddiasını gerçekten desteklemeli; yalnızca aynı konudan bahseden bir belgeye işaret etmemelidir.

Kanıt yetersiz, çelişkili veya güncelliği belirsiz olduğunda sistemin davranışı önceden tanımlanmalıdır. Örneğin model, kesin bir sonuç üretmek yerine hangi bilginin eksik olduğunu belirtebilir, daha dar bir soru isteyebilir veya insan incelemesine yönlendirebilir. Bu kuralı yalnızca prompt içine yazmak risklidir; uygulama katmanında da kaynak kapsamı, tarih, izin ve kanıt uyumu denetlenmelidir.



Bu kod üretim uygulaması değil, davranış kuralının basit bir taslağıdır. “evidence_supports_claims” değerlendirmesi; kural tabanlı kontroller, ayrı bir doğrulama modeli, yapılandırılmış iddia-kaynak eşleştirmesi veya gerektiğinde insan incelemesi gerektirebilir. Hiçbir yaklaşım tek başına hatasız kabul edilmemelidir.

Prompt Katmanı, İzlenebilirlik ve Operasyonel Kontrol

Prompt, retrieval hatalarını sihirli biçimde düzeltmez; ancak modelin kanıtı nasıl kullanacağını sınırlandırabilir. Bağlam ile kullanıcı isteğini açıkça ayırın, yalnızca verilen kaynaklara dayanmasını isteyin, kaynaklar çeliştiğinde bunu belirtmesini ve kanıt bulunmadığında tahmin yürütmemesini tanımlayın.

Her istekte kullanılan sorguyu, getirilen belge kimliklerini, sürümleri, uygulanan filtreleri, model yanıtını ve fallback nedenini güvenli biçimde kaydetmek hata ayıklamayı kolaylaştırır. Kayıtlar hassas veri içerebileceği için erişim yetkileri, saklama süresi ve maskeleme kuralları ayrıca tasarlanmalıdır.

Sonuç olarak güvenilir RAG yalnızca daha güçlü bir model seçme problemi değildir. Veri hazırlama, parçalama, retrieval, kanıt denetimi, atıf, fallback ve ölçümleme birlikte tasarlanmadığında sistem ikna edici fakat hatalı yanıtlar üretebilir. Kendi uygulamanızda en yüksek hata payı hangi katmanda ortaya çıkıyor: belge parçalama, arama, prompt talimatları, atıf doğrulama yoksa değerlendirme süreci mi?