RAG Yanıtlarında Kaynak Gösterme Nasıl Doğrulanır?

Kaynak göstermek neden doğruluk garantisi değildir?

Kaynak atfı, modelin "bu cümle şu belgeye dayanıyor" iddiasıdır. Akademik ölçümler bu iddianın sık sık tutmadığını gösteriyor:

İkinci çalışmanın ayrımı önemlidir. Bir atıf doğru olabilir, yani belge iddiayı destekleyebilir, ama model yanıtı kendi bilgisinden üretip uygun bir belgeyi sonradan eklemiş olabilir. Yazarlar buna sonradan gerekçelendirme diyor.

Atıfla ilgili beş yaygın hata türü vardır:

• Uydurma atıf: Getirilmeyen ya da var olmayan bir kaynağın gösterilmesi.
• Desteklenmeyen iddia: Kaynak gerçek, ama cümle kaynakta yok.
• Çarpıtılmış özet: Kaynakta olan bilgi farklı anlamda aktarılır.
• Eski kaynak: Belge geçerliliğini yitirmiş ya da yeni sürümle değiştirilmiş.
• Yetkisiz kaynak: Kullanıcının erişim hakkı olmayan bir belge atıfta görünür.

Atıf hataları neden bir güvenlik sorunudur?

Atıf, kullanıcıya görünür bir güven işareti sunar. Kaynak bağlantısı gören kullanıcı yanıtı doğrulanmış sayar ve bağlantıyı çoğu zaman açmaz. Yanlış bir yanıt kaynak etiketiyle geldiğinde, etiketsiz yanlıştan daha inandırıcıdır. OWASP LLM07:2026 Misinformation maddesi, modelin inandırıcı ama yanlış bilgi üretmesini ve kullanıcının bu bilgiye aşırı güvenmesini ayrı bir risk olarak ele alır.

Güvenlik açısından iki boyut daha vardır. Birincisi, getirilen belge saldırgan tarafından zehirlenmiş olabilir. Bu durumda atıf teknik olarak doğrudur ama yanlış bir yanıtı destekler. Belge zehirlenmesinin ölçeği için RAG zehirleme saldırısı yazısına bakabilirsiniz. İkincisi, atıf listesi yetki süzgecinden geçmezse kullanıcıya erişemeyeceği bir belgenin adını, yolunu ya da alıntısını gösterebilir. Bu hem gizlilik hem doğruluk sorunudur. Vektör katmanındaki yetki ayrımı için RAG tenant izolasyonu yazısı yol gösterir.

RAG kaynak gösterme doğrulama hangi katmanlardan oluşur?

Doğrulama sırayla çalışan katmanlardan oluşur. Ucuz ve kesin kontroller önce gelir, pahalı ve olasılıksal kontroller sonra.

Desteği düşük iddialar yanıttan çıkarılır, yumuşatılır ya da "kaynakta doğrulanamadı" diye işaretlenir. Sistem yeterli kaynak bulamazsa "belgelerde bu konuda bilgi bulamadım" demek, uydurma bir yanıttan her zaman daha değerlidir.

Alıntı doğrulaması nasıl tasarlanır?

En sağlam tasarım, modeli yalnız getirilen parçalardan alıntı yapmaya zorlamak ve her iddiayı parça kimliğiyle birlikte üretmektir. Atıf biçimi serbest metin yerine yapılandırılmış olmalıdır, çünkü metne gömülü atıfları ayrıştırmak hataya açıktır. Sağlayıcıların yerleşik özellikleri bu adımı kolaylaştırır. Anthropic'in Citations özelliği, atıfları yanıttan ayrıştırıp alıntılanan metni doğrudan belgeden çıkardığı için atıfların sağlanan belgelere geçerli işaretçiler içermesini garanti ettiğini belirtir. Bu garanti işaretçinin geçerliliğiyle ilgilidir, iddianın desteklendiği ayrıca kontrol edilmelidir.

Uygulama tarafında doğrulama şöyle görünebilir:

def atiflari_dogrula(yanit, getirilen, kullanici):
    parcalar = {p.id: p for p in getirilen if yetki.gorebilir(kullanici, p.belge_id)}
    sonuc = []
    for iddia in yanit["iddialar"]:          # {"cumle", "parca_id", "alinti"}
        p = parcalar.get(iddia["parca_id"])
        if p is None:
            sonuc.append((iddia, "uydurma_ya_da_yetkisiz_kaynak"))
            continue
        if normalize(iddia["alinti"]) not in normalize(p.metin):
            sonuc.append((iddia, "alinti_bulunamadi"))
            continue
        if p.gecerlilik_sonu and p.gecerlilik_sonu < bugun():
            sonuc.append((iddia, "eski_surum"))
            continue
        puan = destek_puani(iddia["cumle"], p.metin)   # NLI ya da hakem model
        sonuc.append((iddia, "destekleniyor" if puan >= ESIK else "zayif_destek"))
    return sonuc

Parçalama kalitesi sonucu doğrudan etkiler. Belgeleri başlık, paragraf ve madde gibi anlamlı birimlere bölün, her parçaya sabit bir kimlik verin ve belge adı, sürüm, geçerlilik tarihi ve erişim sınıfını parçanın üst verisine ekleyin.

Destek puanı nasıl hesaplanır ve sınırları nedir?

Yorum ve özet içeren iddialarda birebir alıntı kontrolü yetmez. Burada iddianın parça tarafından desteklenip desteklenmediğini ölçen bir puan gerekir. Yaygın bir tanım RAGAS kütüphanesinin faithfulness ölçütüdür: yanıttaki iddialar çıkarılır, her biri getirilen bağlamla karşılaştırılır ve desteklenen iddia sayısı toplam iddia sayısına bölünür. Puan 0 ile 1 arasındadır.

Bu puanı üreten model de hata yapar. Hakem modelin önyargıları ve kalibrasyonu için LLM-as-a-Judge güvenilirliği yazısına bakabilirsiniz. Pratik kurallar:

• Doğrulayıcının eşiğini, insanların etiketlediği tarafsız bir örnek kümeyle ayarlayın.
• Doğrulayıcının hata oranını ayrıca raporlayın, tek bir "doğruluk" sayısı göstermeyin.
• Türkçe belgelerde doğrulayıcıyı Türkçe örneklerle sınayın.
• Kritik alanlarda düşük puanlı yanıtları insan incelemesine gönderin.

Arayüz atıf güvenini nasıl yönlendirir?

Arayüz, kullanıcının atfı kontrol etme kolaylığını belirler. Kaynak bağlantısı yalnız yanıtın sonuna eklenmişse kimse açmaz.

• Atfı iddia düzeyinde gösterin, yanıtın sonundaki genel bir liste yeterli değildir.
• Kaynak açılırken ilgili cümleyi vurgulayın.
• Doğrulama sonucunu açıklayıcı ifadeyle gösterin: "kaynakta doğrulandı", "kısmen destekleniyor", "doğrulanamadı".
• Yeşil onay işareti ya da yüzde güven puanı gibi sahte kesinlik izlenimi veren öğelerden kaçının.
• Kaynağın tarihini gösterin ve kullanıcıya hatalı atıf bildirme yolu verin.

RAG güvenlik testinde atıflar nasıl sınanır?

Atıf doğrulaması, bir RAG güvenlik testinin ayrı bir bölümü olmalıdır. Test kümesi kurum kendi bilgi tabanının bir kopyası üzerinde hazırlanır.

Sohbet asistanlarının uçtan uca test adımları için kurumsal chatbot güvenlik testi yazısına bakabilirsiniz. Bağımsız değerlendirme gerektiğinde bu senaryolar bir LLM pentest kapsamına eklenebilir.

Atıf kalitesi nasıl ölçülür ve izlenir?

Atıf kalitesi üç ölçüyle izlenir: atıf geçerliliği (kaynak getirilen listede mi), alıntı doğruluğu (metin kaynakta mı) ve destek oranı (iddia kaynakla destekleniyor mu).

1. Gerçek kullanıcı sorularından temsil edici bir örnek küme çıkarın, kişisel veriyi maskeleyin.
2. Her soru için beklenen kaynakları insan gözüyle işaretleyin.
3. Sistemi çalıştırın, üç ölçüyü hesaplayın ve hataları uydurma, desteksiz, çarpıtma, eski kaynak ve yetkisiz kaynak olarak sınıflandırın.
4. Model, istem ya da bilgi tabanı değiştiğinde kümeyi yeniden çalıştırın ve sonuçları sürüm bazında saklayın.

Üretimde de doğrulama sonuçlarını kaydedin. Başarısız doğrulama oranındaki ani artış, bilgi tabanında zehirli içerik ya da model davranışında bir değişiklik olduğuna işaret edebilir.

Sık Sorulan Sorular

Kaynak göstermek yanıtın doğru olduğunu garanti eder mi?

Hayır. Kaynak etiketi yalnız yanıtın hangi belgeye dayandığını iddia eder. Model kaynakta olmayan bir bilgiyi kaynakla birlikte sunabilir, kaynağı çarpıtabilir ya da yanıtı önce üretip sonra uygun görünen bir kaynak ekleyebilir. Liu ve arkadaşlarının dört üretken arama motorunda yaptığı denetimde cümlelerin yalnız yüzde 51,5'i atıflarca tam olarak destekleniyordu.

Uydurma atıf nasıl yakalanır?

RAG sisteminde her sorgu için getirilen parça listesi bilinir. Yanıttaki her atfın bu listedeki bir parça kimliğine karşılık gelip gelmediği otomatik olarak kontrol edilir. Listede olmayan kimlik uydurma atıftır ve yanıttan düşürülür. Bu kontrol ucuzdur, kural tabanlıdır ve ilk savunma hattı olmalıdır. Ardından alıntı metninin parçada birebir bulunup bulunmadığına bakılır.

Doğru atıf ile sadık atıf arasındaki fark nedir?

Doğru atıf, gösterilen belgenin iddiayı desteklemesidir. Sadık atıf ise modelin yanıtı üretirken o belgeye gerçekten dayanmış olmasıdır. Wallat ve arkadaşlarının çalışması, atıfların yüzde 57'ye varan kısmında modelin belgeye gerçekten dayanmadığını, yanıtı sonradan gerekçelendirdiğini gösterdi. Bu yüzden destek kontrolü, atfın yanında yanıtın kaynak dışı bilgi içerip içermediğini de ölçmelidir.

RAG güvenlik testinde atıflar nasıl sınanır?

Test kümesine bilinen yanıtlı sorular, kaynakta cevabı olmayan sorular, eski sürüm belgeler, kullanıcının yetkisi olmayan belgeler ve talimat içeren zehirli belgeler eklenir. Beklenen davranış; uydurma atıf üretmemek, bilgi yoksa bunu söylemek, eski belgeyi işaretlemek, yetkisiz belgeyi hiç göstermemek ve belgedeki talimata uymamaktır. Testler model ya da bilgi tabanı her değiştiğinde yeniden çalıştırılır.

Atıf doğrulaması tamamen otomatik yapılabilir mi?

Büyük ölçüde yapılabilir. Kimlik ve birebir alıntı kontrolü kural tabanlıdır ve kesin sonuç verir. Yorum ve özet içeren iddialarda destek puanını bir doğal dil çıkarımı modeli ya da hakem model hesaplar. Bu doğrulayıcılar da hata yapar. Kritik alanlarda insan örneklemesi ekleyin ve doğrulayıcının kendi hata oranını etiketli bir kümeyle ayrıca ölçün.

Kaynaklar

• arXiv: Liu, Zhang, Liang, Evaluating Verifiability in Generative Search Engines (2304.09848)
• arXiv: Wallat ve diğerleri, Correctness is not Faithfulness in RAG Attributions (2412.18004)
• Claude Platform Docs: Citations
• Ragas Docs: Faithfulness
• OWASP GenAI: LLM09:2025 Misinformation

İlgili Yazılar

• RAG Zehirleme Saldırısı: Bir Cevabı Ele Geçirmek İçin Kaç Zehirli Doküman Yeterli? Retrieval zehirlemesinin eşiği: ölçümlü bir bakış
• RAG Güvenlik İzleme Vektör Veritabanı Saldırılarına Karşı Savunma
• LLM-as-a-Judge Güvenilir mi? Hakem Modelin Sınırları
• RAG Security Nedir? Vektör Veritabanlarının Karanlık Yüzü