RAG NEDİR? RETRİEVAL-AUGMENTED GENERATİON MANTIĞI, MİMARİ VE DEĞERLENDİRME

Bir LLM’ye “şirketimizin iade politikası nedir?” diye sorduğunuzda, modelin eğitildiği genel web bilgisinden cevap üretmesi çoğu zaman yetmez; asıl ihtiyaç, sizin güncel dokümanlarınızdan doğru bağlamı bulup onu kullanarak yanıt vermesidir. İşte RAG (Retrieval-Augmented Generation), üretken modelleri gerçek kurumsal bilgiyle besleyerek bu boşluğu kapatır.

RAG’ı yalnızca “vektör arama + LLM” diye özetlemek kolaydır; fakat pratikte kaliteyi belirleyen şey; veri hazırlama, parçalara ayırma, sorgu zamanındaki yeniden sıralama, alıntı stratejisi, değerlendirme metrikleri ve operasyonel dayanıklılıktır. Bu yazıda RAG mantığını, tipik mimariyi ve üretimde güvenilir bir RAG sistemi kurmak için kritik karar noktalarını ele alacağız.

Amacımız, “neden RAG?” sorusundan başlayıp, hangi bileşenlerin nerede konumlandığını netleştirmek ve ölçülebilir kalite kriterleriyle ilerleyen bir yaklaşım sunmak. Eğer konuyu daha geniş bir üretken yapay zekâ perspektifiyle ele almak isterseniz, Generative AI / LLM eğitimi içeriği de iyi bir tamamlayıcıdır.

RAG nedir ve hangi problemi çözer?

Retrieval-Augmented Generation mantığı

RAG, bir kullanıcının sorusuna yanıt üretmeden önce, harici bir bilgi kaynağından (doküman deposu, wiki, ürün kataloğu, politika dokümanları, kod tabanı vb.) ilgili parçaları “getirir” (retrieval) ve ardından bu parçaları LLM’e “bağlam” olarak verip yanıtı “ürettirir” (generation). Böylece yanıt, modelin parametrelerinde gömülü genel bilginin ötesine geçerek güncel ve kuruma özgü bilgiyle temellenir.

Bu yaklaşım, iki temel riski azaltır: (1) modelin güncel olmayan bilgiye dayanması, (2) belirsiz sorularda uydurma (hallucination) üretmesi. RAG, doğru getirimi yapabildiği ölçüde “grounded” yani kaynağa dayalı yanıtları mümkün kılar.

Ne zaman RAG, ne zaman fine-tuning?

RAG; hızlı güncellenen bilgi, geniş doküman setleri ve kaynak gösterimi gereken kullanım senaryolarında çok etkilidir. Fine-tuning ise daha çok üslup, format, görev öğrenimi (ör. sınıflandırma, özetleme şablonu) gibi “davranış” iyileştirmelerinde öne çıkar. Pek çok sistemde hibrit yaklaşım görülür: model davranışı için ince ayar, içerik doğruluğu için RAG.

RAG mimarisi: temel bileşenler ve veri akışı

İndeksleme hattı (offline) ve sorgu hattı (online)

RAG mimarisi genellikle iki hatta ayrılır. İndeksleme hattı dokümanları toplar, temizler, parçalara ayırır (chunking), embedding üretir ve vektör veritabanına yazar. Sorgu hattı ise kullanıcının sorusunu embedding’e çevirir, en ilgili parçaları getirir, gerekiyorsa rerank eder, ardından LLM’e bir prompt şablonu ile bağlamı ekleyerek yanıt üretir.

Bu ayrım, operasyonel olarak da önemlidir: indeksleme hattı batch veya event-driven çalışabilir; sorgu hattı ise düşük gecikme ve yüksek erişilebilirlik hedefler. Üretimde başarı, iki hattın da SLA’larının doğru tasarlanmasına bağlıdır.

Bileşenler: kaynaklar, dönüştürücüler ve depolar

• Kaynak bağlayıcıları: Dosya depoları, CMS, wiki, ticket sistemleri, veri ambarı gibi sistemlerden içerik çekme.
• Dönüştürme katmanı: PDF/HTML/Markdown gibi formatları normalize etme, bölümleme, metadata zenginleştirme.
• Vektör depo: Embedding’lerle benzerlik araması; filtreleme ve metadata sorguları.
• Reranker (opsiyonel): Getirilen adayları daha iyi sıralamak için cross-encoder veya LLM tabanlı değerlendirme.
• Prompt ve yanıt katmanı: Bağlamı güvenli şekilde birleştiren şablon; alıntı/kanıt üretimi; formatlama.

Doküman hazırlama: chunking, metadata ve embedding stratejileri

Chunking neden kaliteyi belirler?

RAG’ın kalbi retrieval olduğu için, retrieval’ın kalbi de chunking’dir. Çok büyük parçalar, gereksiz bağlamla modeli boğar ve doğruluğu düşürür; çok küçük parçalar ise anlam bütünlüğünü kaybettirir. İyi chunking; dokümanın mantıksal sınırlarını (başlıklar, madde işaretleri, tablolar, paragraflar) dikkate alır ve her parçaya zengin metadata ekler.

Pratik bir yaklaşım: bölüm bazlı ayrım + kaydırmalı pencere (overlap). Overlap, önemli cümlelerin iki parçaya bölünmesi riskini azaltır. Ancak overlap arttıkça indeks şişer, maliyet büyür. Bu nedenle ölçüm yapmak şarttır.

Metadata ile filtreleme ve doğruluk artırma

Chunk’ların yalnızca metnini değil, “nereden geldiğini” de taşıması gerekir: doküman adı, bölüm, tarih, sürüm, erişim yetkisi, ürün/ülke etiketi gibi alanlar. Bu metadata; (1) sorgu tarafında filtrelemeyi, (2) yanıt tarafında kaynak göstermeyi, (3) gözlemlenebilirliği kolaylaştırır. Ayrıca erişim kontrolü (ACL) için kritik bir temel oluşturur.

Embedding seçimi ve normalizasyon ipuçları

Embedding modeli seçimi; dil desteği, maliyet, hız ve semantik hassasiyet açısından dengelenir. Türkçe içerik yoğun ise çok dilli embedding’ler veya Türkçe performansı güçlü modeller tercih edilir. Bir diğer kritik konu da normalizasyondur: gereksiz HTML kalıntıları, gizli karakterler, kırık satır sonları embedding kalitesini bozar. “Temiz metin” üretmek, bazen model seçiminden daha fazla etki eder.

Gömme vektörlerinin “hangi uzayda” karşılaştırıldığı da önemlidir. Çoğu sistem cosine similarity kullanır; bazı vektör depoları iç çarpım/öklid de destekler. Seçim, embedding modelinin önerisiyle uyumlu olmalıdır; aksi durumda benzerlik skorları yanıltıcı hale gelebilir.

Sorgu zamanı akışı: retrieval, reranking ve prompt birleştirme

Sorgu yeniden yazımı ve çok aşamalı retrieval

Gerçek kullanıcı soruları kısa, bağlamsız veya muğlak olabilir. Bu nedenle “query rewriting” (sorgu yeniden yazımı) güçlü bir tekniktir: LLM, kullanıcı sorusunu daha arama-dostu bir forma dönüştürür; ardından vektör arama daha isabetli olur. Bazı sistemler çok aşamalı retrieval kullanır: önce geniş bir aday havuzu (top-k) çekilir, sonra filtreleme/rerank ile daraltılır.

Çok aşamalı yaklaşım, özellikle uzun doküman setlerinde ve benzer terimlerin bol olduğu kurumsal içeriklerde iyi sonuç verir. Ancak her aşama gecikmeyi artırır; bu nedenle performans bütçesi belirlemek gerekir.

Reranking: “en yakın” ile “en ilgili” arasındaki fark

Vektör arama “anlamsal yakınlık” yakalar; fakat her zaman “soruya en iyi yanıtı veren” parçayı üste taşımaz. Reranker; aday parçaları soru ile birlikte daha detaylı değerlendiren bir modeldir. Uygulamada iki popüler yaklaşım vardır: (1) cross-encoder reranker, (2) LLM tabanlı puanlama. Reranking, özellikle top-k içinde iyi adaylar varken sıralama hatalarını azaltır.

Prompt şablonu: bağlamı güvenli ve okunur hale getirmek

Prompt tasarımında iki hedef vardır: (1) LLM’i yalnızca verilen bağlama dayanarak cevap vermeye zorlamak, (2) kaynak parçalarını okunur, izlenebilir bir formatta sunmak. İyi bir şablon; parça başına kimlik, kaynak, tarih ve içerik bölümlerini içerir. Ayrıca “bilinmiyorsa belirt” kuralı net olmalıdır.

Önemli: Bağlam penceresi sınırlı olduğu için, her şeyi modele yığmak yerine seçmek gerekir. Rerank sonrası top-n parçayı almak, uzun parçaları özetleyip eklemek veya bölüm bazlı seçim yapmak bu noktada yardımcı olur.

# Basit bir RAG prompt şablonu (örnek)
SEN: Kurumsal bilgi asistanısın. Yalnızca aşağıdaki KAYNAKLAR'ı kullanarak yanıt ver.
Eğer KAYNAKLAR yeterli değilse "Bunu mevcut kaynaklarda bulamadım" de.

KAYNAKLAR:
[1] dokuman=IadePolitikasi, bolum=Genel Kosullar, tarih=2025-11-10
Metin: ... (chunk içeriği) ...

[2] dokuman=KargoSurecleri, bolum=Hasarli Urun, tarih=2025-10-02
Metin: ... (chunk içeriği) ...

SORU:
Müşteri hasarlı ürün iadesini kaç gün içinde başlatabilir?

YANIT:
- Kısa ve net yanıt
- Gerekirse maddeleyerek anlat
- Sonunda kaynak numaralarını belirt: [1], [2]

RAG uygulama örneği: minimal ama gerçekçi bir akış

Python ile vektör arama ve bağlam oluşturma

Aşağıdaki örnek, temel bir RAG akışını gösterir: soru embedding’i alınır, vektör depodan top-k parça çekilir, ardından bu parçalar bir prompt içinde birleştirilir. Üretimde elbette caching, rate limit, gözlemlenebilirlik ve erişim kontrolü gibi katmanlar eklenir; fakat çekirdek fikir aynıdır.

from typing import List, Dict

def build_context(chunks: List[Dict]) -> str:
    lines = []
    for i, c in enumerate(chunks, start=1):
        meta = f"dokuman={c['doc']}, bolum={c['section']}, tarih={c['date']}"
        lines.append(f"[{i}] {meta}
Metin: {c['text']}
")
    return "
".join(lines)

def rag_answer(question: str, embed, vector_db, llm) -> str:
    q_vec = embed(question)
    candidates = vector_db.search(q_vec, top_k=8, filters={"lang": "tr"})
    top = candidates[:4]  # basit seçim; pratikte rerank önerilir

    context = build_context(top)
    prompt = (
        "SEN: Yalnızca aşağıdaki KAYNAKLAR'a dayanarak yanıt ver.
"
        "Yetersizse 'Bunu mevcut kaynaklarda bulamadım' de.

"
        f"KAYNAKLAR:
{context}
"
        f"SORU:
{question}

YANIT:"
    )
    return llm(prompt)

# Not: embed, vector_db ve llm burada soyut arayüzlerdir.

Hata modları: yanlış bağlam, eksik bağlam, fazla bağlam

RAG’de sık görülen sorunlar üç başlıkta toplanır: (1) yanlış bağlam getirimi (irrelevant retrieval), (2) eksik bağlam (cevap için gereken parça yok), (3) fazla bağlam (modelin dikkatinin dağılması). Bu hataları azaltmanın en etkili yolu; iyi chunking + metadata filtreleme + rerank + düzenli değerlendirme döngüsüdür.

Bu döngü yoksa sistem, ilk demoda iyi görünür; fakat gerçek kullanıcı trafiğinde hızla sapmalar başlar. Özellikle benzer ürün isimleri, tarihli dokümanlar ve farklı sürümler RAG’i zorlar.

RAG değerlendirme: metrikler, test setleri ve izleme

Retrieval metrikleri: recall, precision ve coverage

RAG’in performansı iki katmanlıdır: retrieval kalitesi ve generation kalitesi. Retrieval için tipik ölçümler; “doğru parçanın top-k içinde olma oranı” (recall@k), “getirilen parçaların ne kadarının gerçekten alakalı olduğu” (precision@k) ve belirli konu kümelerinde kapsama oranıdır. Bu metrikler, altın standart (gold) etiketli bir soru-cevap setiyle hesaplanır.

Kurumsal ortamda gold set oluşturmak zahmetlidir; ancak küçük ve temsil gücü yüksek bir set bile çok değerli geri bildirim verir. Ayrıca, retrieval metriklerini “departman, ürün, dil, doküman türü” gibi dilimlerde takip etmek, sorunun kaynağını hızla bulmayı sağlar.

Generation metrikleri: doğruluk, alıntı uygunluğu ve tutarlılık

Üretim katmanı için sadece “cevap doğru mu?” yetmez. Yanıtın kaynaklara dayalı olup olmadığı, alıntıların doğru parçaları işaret edip etmediği, yanıtta çelişki olup olmadığı gibi boyutlar önemlidir. Uygulamada sık görülen metrikler:

1. Answer correctness: Yanıtın gerçeğe uygunluğu.
2. Faithfulness/grounding: Yanıtın verilen parçalardan türetilebilirliği.
3. Citation quality: Kaynak numaralarının doğru pasajları göstermesi.
4. Helpfulness: Kullanıcı ihtiyacını karşılama düzeyi.

Bu alanlarda otomatik ölçüm için LLM-as-a-judge yaklaşımı kullanılabilir; ancak en iyi sonuç, periyodik insan değerlendirmesiyle kalibrasyon yapmaktır. “Otomatik skorlar doğru yönü gösterir, nihai kaliteyi ise örnekler belirler.”

Gecikme ve maliyet: token bütçesi yönetimi

RAG’de gecikme, retrieval (vektör arama + rerank) ve generation (LLM çağrısı) toplamıdır. Token bütçesi arttıkça maliyet ve gecikme büyür; bu nedenle bağlamı “iyi seçmek” kritiktir. Bazı pratik teknikler: top-k’i dinamik ayarlamak, sık sorular için cache kullanmak, uzun chunk’ları özetleyip eklemek, düşük değerli metadata’yı prompt dışına almak.

Üretimde “kalite-maliyet-performans” üçgeni sürekli dengelenir. Bu dengeyi korumak için SLO’lar belirlemek ve A/B testleriyle değişiklikleri doğrulamak gerekir.

Üretimde RAG: güvenlik, erişim kontrolü ve bakım

Erişim yetkisi (ACL) ve veri sızıntısı riskleri

Kurumsal RAG’de en kritik konu, kullanıcının yetkisi olmayan dokümanlardan bağlam getirilmemesidir. Bu, yalnızca uygulama katmanında değil; vektör depo sorgularında da enforce edilmelidir. Metadata içinde erişim grupları veya kullanıcı kimliğiyle ilişkilendirilen etiketler tutulur ve retrieval aşamasında filtrelenir. Aksi halde model, kullanıcıya görmemesi gereken bilgiyi “doğru” şekilde de olsa sunabilir.

Ayrıca prompt injection riskleri vardır: dokümanların içine gömülü “talimatlar” modele sızabilir. Bu nedenle dokümanları güvenilirlik sınıfına ayırmak, şüpheli içerikleri işaretlemek ve prompt katmanında “doküman içi talimatları yok say” kuralları koymak iyi bir yaklaşımdır.

Güncelleme stratejisi: incremental indeksleme ve sürümleme

Dokümanlar değiştikçe indeksin güncel kalması gerekir. Büyük kurumlarda tam yeniden indeksleme pahalıdır; bu yüzden incremental indeksleme (değişen dokümanları güncelleme) tercih edilir. Sürümleme ile eski içerikler “tarih filtresi” veya “geçerlilik aralığı” üzerinden yönetilebilir. Böylece kullanıcıya “en güncel politika” ile “tarihsel bilgi” karışmaz.

Pratik tasarım kararları: kaliteyi hızlı artıran öneriler

Basit ama etkili kontrol listesi

• Chunking standardı: Başlık bazlı böl, kısa overlap kullan, tablo/ madde yapısını koru.
• Metadata zenginliği: Doküman adı, bölüm, tarih, sürüm, erişim etiketi olmadan başlamayın.
• Rerank ekleyin: İlk sürümde opsiyonel görünse de kaliteyi belirgin artırır.
• Alıntı standardı: Yanıt sonunda kaynak numarası; gerektiğinde pasaj alıntısı.
• Değerlendirme seti: En az 50–100 soru ile başlayıp periyodik genişletin.
• Gözlemlenebilirlik: Sorgu, getirilen parçalar, skorlar, token ve gecikmeyi loglayın.

Hallucination azaltma: “bilinmiyorsa söyle” disiplinini oturtmak

RAG, hallucination’ı otomatik olarak sıfırlamaz; yanlış bağlam geldiğinde model yine ikna edici bir metin üretebilir. Bu yüzden prompt’ta “yetersiz bağlam” davranışı net olmalı ve uygulama katmanında da güven puanı/threshold kullanılmalıdır. Örneğin top-1 benzerlik skoru belirli bir eşik altındaysa, kullanıcıdan ek bilgi istemek veya “bulamadım” demek, yanlış cevap vermekten daha güvenlidir.

Sonuç olarak RAG; doğru tasarlanır, ölçülür ve işletilirse, LLM’leri kurumsal bilgiyle buluşturan en pratik yaklaşımlardan biridir. Mimarinin her parçası birbirini etkiler: veri kalitesi, retrieval doğruluğu, prompt disiplini ve değerlendirme döngüsü aynı hedefe hizmet eder: güvenilir, izlenebilir ve güncel yanıtlar.