RAG nedir, ne zaman gerekir?

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.

1. Arama. Sorulan soruya en yakın belge parçaları, hazırlanmış bir dizinde aranır.
2. Ekleme. Bulunan parçalar talimatın içine yapıştırılır.
3. Ü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.

RAG mı, uzun bağlam mı, ince ayar mı?

Üç yol birbirinin alternatifi gibi anlatılır ama üçü ayrı sorunu çözer. Uzun bağlam, bilgiyi doğrudan talimata koyar. RAG, bilgiyi soruya göre seçip getirir. İnce ayar ise bilgiyi değil, modelin üslubunu ve çıktı biçimini oturtmak için kullanılır; bilgi değiştiğinde eğitimi yenilemek gerektiği için sık değişen içerik taşımaya uygun değildir.

Tablodaki ilk satırın geçerli olup olmadığını, bilgi tabanının bağlam penceresine sığıp sığmadığı belirler.

Eylül 2026 itibarıyla Anthropic'in bağlam penceresi belgesine göre Claude Opus 5.5 ve Sonnet 5.5 dahil yeni modellerde pencere 1 milyon token, Claude Sonnet 4.5 gibi diğer modellerde ise 200 bin token.

Aynı belge bir uyarı da taşıyor: token sayısı arttıkça doğruluk ve hatırlama düşüyor, bu olguya bağlam çürümesi (context rot) deniyor. Yani bağlam penceresi büyük diye her şeyi içine doldurmak iyi bir fikir olmaz.

Eylül 2026 itibarıyla Anthropic'in Contextual Retrieval yazısı, bilgi tabanı 200.000 token'dan (yaklaşık 500 sayfa) küçükse bütün içeriği RAG kurmadan doğrudan talimata koymayı öneriyor.

Yazı Eylül 2024 tarihli ve pencereler o günden bu yana büyüdü. Ama bağlam çürümesi yüzünden eşiği kendiliğinden yükseltmek yerine, kendi sorularınla iki yolu karşılaştırmak daha güvenlidir.

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.

Arama kalitesi ne kadar fark yaratır?

Arama tarafındaki iyileştirme, RAG'ın en ölçülebilir kısmıdır. Eylül 2026 itibarıyla Anthropic'in Contextual Retrieval yazısına göre, parçalara kısa bir bağlam notu eklemek ve anlam aramasını kelime aramasıyla (BM25) birleştirmek ilk 20 parçadaki getirme hatasını yüzde 5,7'den yüzde 2,9'a indiriyor.

Aynı ölçümde yeniden sıralama adımı eklenince hata yüzde 1,9'a düşüyor. Bu oranlar Anthropic'in kendi test veri kümelerinden geliyor; senin belgelerinde farklı çıkabilir, bu yüzden kendi kontrol setinde ölç.

Pratik çıkarım şu: RAG kurduysan önce parçalama ve arama tarafını ölç. Modele verdiğin talimatı değiştirmek çoğu zaman ikinci adımdı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.

RAG kurmadan önce hangi dört soruyu sormalı?

Karar için dört soru yeter. Cevapların çoğu "hayır" ise RAG kurmadan başlamak daha akıllıcadır.

1. Bilgi tabanı kaç token? Belgelerin toplam boyutunu token maliyeti hesabıyla ölç. Yaklaşık 500 sayfanın altındaysa önce doğrudan talimata koymayı dene.
2. İçerik ne sıklıkla değişiyor? Büyük ve sık değişen bir içerik dizin yenileme işini de getirir. Bu işi kimin, ne zaman yapacağını baştan yaz.
3. Cevabın kaynağını göstermek zorunlu mu? Müşteri desteği, hukuk ya da finans gibi alanlarda parça bazında kaynak gösterimi RAG'ın en somut kazancıdır.
4. Yanlış cevabın bedeli ne? Bedel yüksekse cevabı kontrol eden bir kapı ve insan onayı ekle. Bedel düşükse en basit yolla başla.

Küçük ve sabit bir bilgi tabanı için kalıcı ve düzenli yol, kaynak metinleri referans dosyası olarak bir skill klasörüne koymaktır: skill'in adı ve açıklaması her zaman yüklü kalır, dosyalar iş eşleşince okunur. Kurulumu Claude Skills yazısında adım adım var.

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.