RAG nedir, ne zaman gerekir?
RAG, modele soruyu cevaplarken kullanacağı kaynak metni bulup veren bir yaklaşımdır: önce soruya en yakın belge parçaları aranır, sonra bu parçalar talimata eklenir ve cevap yalnızca onlardan üretilir. Amacı iki tanedir: modelin bilmediği kendi verinle çalışabilmesi ve uydurma oranının düşmesi. Küçük belge kümelerinde gerekmez; birkaç yüz sayfaya kadar olan içerik doğrudan talimata sığdığında aynı sonuç daha az karmaşıklıkla alınır. Kurulumda kaliteyi belirleyen üç karar parçalama biçimi, arama yöntemi ve kaynak gösterme zorunluluğudur.
Bir modele kendi şirket belgelerini sorduğunda iki şeyden biri olur: ya bilmediğini söyler ya da bilmediğini fark etmeden bir şeyler uydurur. RAG, bu iki sonucun da önüne geçmek için kurulan bir düzendir.
Bu yazı kaynak bağlamanın çalışma mantığını, uzun bağlamla farkını, küçük ölçekte ne zaman gereksiz olduğunu ve kurulumda kaliteyi belirleyen üç kararı anlatıyor.
Çalışma mantığı
RAG üç adımdan oluşur ve üçü de her soruda tekrarlanır.
- Arama. Sorulan soruya en yakın belge parçaları, hazırlanmış bir dizinde aranır.
- Ekleme. Bulunan parçalar talimatın içine yapıştırılır.
- Üretim. Model cevabı yalnızca bu parçalardan üretir ve hangi parçadan aldığını belirtir.
Önemli olan üçüncü adımdaki kısıttır: model kendi hafızasından değil, verilen metinden cevap verir. Bu kısıt olmadan kurulan bir RAG, halüsinasyonu azaltmaz.
Uzun bağlamla farkı
Modellerin tek seferde işleyebildiği metin miktarı arttıkça şu soru doğal hâle geldi: bütün belgeleri doğrudan talimata koysak olmaz mı?
Küçük kümelerde olur ve daha iyidir. Birkaç yüz sayfaya kadar olan içerik doğrudan verildiğinde ne dizin kurmak ne arama yazmak gerekir; sonuç genellikle daha isabetlidir çünkü arama adımının hatası devreye girmez.
Fark ölçekte ortaya çıkar. Binlerce belgede tamamını her soruda göndermek hem maliyetli hem yavaştır; ayrıca ilgisiz metin cevabın kalitesini düşürür. Maliyet hesabı bu eşiği sayıyla görmeyi sağlar.
Pratik kural: belgelerin toplamı talimata rahatça sığıyorsa RAG kurma. Sığmıyorsa kur.
Kaliteyi belirleyen üç karar
1. Parçalama biçimi. Belgeler arama için parçalara bölünür. Parçalar çok küçükse bağlam kopar, çok büyükse ilgisiz metin cevaba karışır. Doğal sınırlardan bölmek (başlık, bölüm) rastgele uzunluktan iyidir.
2. Arama yöntemi. Anlam benzerliğine dayalı arama, kelime eşleşmesine dayalı aramayı her zaman yenmez. Özel terimlerin, ürün kodlarının ve isimlerin geçtiği içerikte kelime eşleşmesi daha isabetlidir; ikisini birlikte kullanmak çoğu durumda en iyi sonucu verir.
3. Kaynak gösterme zorunluluğu. Cevabın yanında hangi parçadan geldiği yazılmıyorsa sistem denetlenemez. Bu zorunluluk aynı zamanda modelin uydurmasını da zorlaştırır.
Ne zaman gereksiz?
RAG, karmaşıklık ekler: dizin kurulur, güncel tutulur, arama kalitesi izlenir. Bu karmaşıklık her zaman karşılığını vermez.
Gereksiz olduğu üç durum:
- Belge sayısı az ve içerik doğrudan talimata sığıyor.
- Sorular sabit ve sayılı; her soru için doğru kaynağı elle eşlemek mümkün.
- İçerik sık değişmiyor ve güncelliği kritik değil.
Bu durumlarda daha basit bir çözüm işi görür: kaynağı elle seçip talimata koymak. Otomasyon eşiği mantığı burada da geçerlidir; karmaşıklık ancak tekrar sayısı yükseldiğinde haklı çıkar.
Dizin güncel tutulmazsa ne olur?
Kurulan bir sistemin en sessiz arızası, dizinin bayatlamasıdır. Belgeler değişir, dizin eski hâliyle kalır ve model güvenle eski bilgiyi verir.
Bu arıza fark edilmesi en zor olanıdır; çünkü sistem hata vermez, yalnızca yanlış cevap verir. Fiyat değişikliği, kaldırılmış bir hizmet ya da güncellenmiş bir süreç, aylarca eski hâliyle anlatılmaya devam edebilir.
Önlemi üç maddedir. Birincisi, her belgeye bir güncelleme tarihi eklemek ve cevabın yanında bu tarihi göstermek. İkincisi, dizin yenileme işini belge değişikliğine bağlamak; elle tetiklenen yenileme er geç unutulur. Üçüncüsü, ayda bir küçük bir kontrol seti çalıştırmak: cevabı bilinen beş soru sor, cevapların hâlâ doğru olduğunu gör.
Bu üç madde olmadan kurulan RAG, zaman içinde en güvenilir görünen yanlış bilgi kaynağına dönüşür.
Kurduktan sonra ölçmek
RAG kurulduktan sonra en sık yapılan hata, sistemi ölçmeden kullanmaya başlamaktır. Oysa iki ayrı yerde hata olabilir ve ikisi farklı çözümler ister.
Arama hatası: doğru parça hiç bulunamamıştır. Bu durumda cevabın yanlış olması modelin suçu değildir. Çözüm parçalama ve arama tarafındadır.
Üretim hatası: doğru parça bulunmuş ama model yanlış özetlemiştir. Çözüm talimattadır.
İkisini ayırmanın yolu basittir: yanlış cevap geldiğinde önce hangi parçaların getirildiğine bak. Bu ayrımı yapmayan ekipler, arama sorununu talimat değiştirerek çözmeye çalışır ve aylarca ilerleyemez. Ölçüm disiplini için haftalık ölçüm sistemi yazısındaki yaklaşım uyarlanabilir.
Sık sorulan sorular
RAG açılımı nedir?
Retrieval Augmented Generation, yani getirmeyle güçlendirilmiş üretim. Model cevabı kendi hafızasından değil, soruya göre bulunup talimata eklenen kaynak metinden üretir.
Uzun bağlam varken RAG gerekli mi?
Küçük belge kümelerinde gerekli değildir; içerik doğrudan talimata sığıyorsa dizin kurmadan daha isabetli sonuç alınır. RAG binlerce belgede, maliyet ve hız nedeniyle gerekir.
RAG yanlış cevap verirse nereye bakılır?
Önce getirilen parçalara. Doğru parça hiç bulunamadıysa sorun arama ve parçalama tarafındadır; doğru parça bulunmuş ama yanlış özetlenmişse sorun talimattadır. Bu ayrım yapılmadan yapılan düzeltmeler sonuç vermez.
Kaynak bağlı üretimi hazır al
Yazıda anlatılan kaynak bağlama disiplini, SEO/GEO Ajanının denetim ve raporlama akışında kurulu hâlde. Tek seferlik lisans, abonelik yok; her ay yama ve güncellemeler e-postana gelir.
SEO/GEO Ajanı · Satın al 4 ajanın tamamını gör