RAG Nedir? Retrieval-Augmented Generation Mimarisi ve Üretim Sistemleri

RAG (Retrieval-Augmented Generation), bir soruya cevap vermeden önce ilgili belgeleri arayıp modelin önüne koyma yaklaşımıdır. Model böylece eğitim verisinden hatırladığı şeyi değil, o an gösterdiğin metni kullanarak cevap verir. Tek cümlelik özeti bu; ama bu tek cümlenin arkasında, üretimde çalışan bir sistem kurmak isteyen herkesin karşılaşacağı bir düzine mühendislik kararı var.

Bu yazı o kararları sırayla ele alıyor: belgeyi nasıl parçalayacağın, hangi gömme modelini seçeceğin, neden yalnızca vektör aramasının yetmediği, kaç belge göndereceğin, getirmenin mi yoksa modelin mi hata yaptığını nasıl ayırt edeceğin. Temel kavramlar için önce LLM tabanlı uygulama geliştirme yazısına bakmanı öneririm — burada oradaki kavramların üstüne inşa ediyoruz.

RAG neden var: modelin üç kör noktası

Bir dil modeli üç şeyi bilemez ve bu üçü de RAG'ın var oluş nedenidir.

• Eğitim sonrası olanları. Modelin verisi bir tarihte durur. Dünkü fiyat değişikliğini, geçen ayki politika güncellemesini bilmez.
• Sana özel olanı. Şirketinin iç dokümantasyonu, müşteri kayıtları, ürün kataloğu — hiçbiri eğitim verisinde yok.
• Nadir olanı. İnternette elli kez geçen bir konuyu model bulanık hatırlar; elli bin kez geçeni net hatırlar. Niş alanlarda hatırlama kalitesi hızla düşer.

Bu üç boşluğun ortak özelliği şu: model boşluğu boş bırakmaz. Bilmediği yeri, bildiği şeylerin olasılıksal ortalamasıyla doldurur ve sonuç akıcı, kendinden emin ve yanlış olur. RAG, o boşluğa doğru metni koyarak modelin uydurma ihtiyacını ortadan kaldırır.

Ne zaman RAG kurmamalısın

RAG modaya döndüğü için gerekmediği yerlerde de kuruluyor. Her sorguya arama eklemek gecikme, maliyet ve bakım yükü ekler. Şu durumlarda önce durup düşün:

• Model zaten doğru cevaplıyorsa. Genel bilgi sorularında RAG çoğu zaman kaliteyi artırmaz, sadece yavaşlatır.
• Belge sayısı gerçekten azsa. On sayfalık bir el kitabın varsa, tamamını bağlama koymak arama altyapısı kurmaktan basit, ucuz ve daha doğru olabilir.
• Cevap yapılandırılmış veride duruyorsa. "Bu müşterinin son üç siparişi" sorusunun cevabı veritabanında. SQL yaz, vektör araması yapma.
• Sorular öngörülebilirse. İlk on sorunun cevabı sabitse bir SSS ve iyi bir arama kutusu daha iyi iş görür.

Doğru soru "RAG kuralım mı" değil, "modelin bilmediği ve sürekli değişen bir bilgi var mı". Cevap hayırsa, eklediğin katman net bir yük.

Boru hattının iki yarısı

RAG sistemleri iki ayrı zamanda çalışan iki boru hattından oluşur ve bunları zihninde ayırmak, sorun giderirken hayat kurtarır.

1. 1İndeksleme (çevrimdışı): Kaynaktan belgeyi al → metne çevir → parçala → gömme vektörü çıkar → vektör deposuna yaz. Bu, veri değiştikçe periyodik çalışır.
2. 2Sorgu (çevrimiçi): Kullanıcı sorusunu al → gömme çıkar → benzer parçaları ara → yeniden sırala → bağlamı kur → modele gönder → cevabı doğrula. Bu, her istekte çalışır.

Kalite sorunlarının çoğu, herkesin baktığı yerde — sorgu tarafında — değil, kimsenin bakmadığı yerde, indekslemededir. PDF'ten metin çıkarırken tabloları bozmuşsan, sorgu tarafında ne yaparsan yap düzelmez.

Her soru arama gerektirmez: yönlendirme katmanı

Üretime çıkmış RAG sistemlerinin çoğunda gereksiz arama oranı şaşırtıcı biçimde yüksek. "Merhaba", "teşekkürler", "az önce ne demiştin" gibi mesajlar da arama tetikliyor; her biri bir gömme çağrısı, bir vektör sorgusu ve bağlama eklenen birkaç bin token demek.

Basit bir yönlendirme katmanı bunu ucuza çözer. Kullanıcı mesajını üç kovaya ayır: arama gerektiren (bilgi sorusu), gerektirmeyen (selamlaşma, teşekkür, meta sohbet) ve geçmişle cevaplanabilen (önceki turlarda zaten getirilmiş bilgiye dayanan takip sorusu). İlk sürüm için küçük ve ucuz bir modelle sınıflandırma yapmak yeterli; kural tabanlı bir ön eleme bile ilk faydayı verir.

ROUTE_SYSTEM = """Kullanıcı mesajını sınıflandır. Sadece şu JSON'u döndür:
{"route": "search" | "chat" | "followup"}

search   : yeni bilgi arayan soru
chat     : selamlaşma, teşekkür, sistem hakkında meta soru
followup : önceki cevapta geçen bir şeye dair takip ("peki ikincisi?")"""

route = classify(message)          # küçük, ucuz model
if route == "search":
    chunks = retrieve(rewrite_query(message, history))
elif route == "followup":
    chunks = last_turn_chunks          # zaten elimizde, tekrar arama yok
else:
    chunks = []                        # arama hiç yapılmaz

Ölçüm yapmadan bu katmanı eklemek de risk: yanlış sınıflandırılan bir bilgi sorusu, arama yapılmadığı için kaynaksız cevaplanır — yani halüsinasyon riski artar. Yönlendiriciyi de golden set'ine dahil et; yanlış "chat" kararı, yanlış "search" kararından çok daha pahalıdır.

Belge hazırlama: en sıkıcı ve en belirleyici adım

Kaynak belgelerin nadiren temiz metindir. PDF, Word, HTML, Confluence sayfası, destek bileti, kod deposu — hepsinin kendine özgü bozulma biçimi var.

Dikkat edilecekler:

• Tablolar. Naif PDF çıkarıcılar tabloyu satır satır düzleştirir ve sütun ilişkisi kaybolur. Fiyat tablosu içeren bir belgede bu, yanlış fiyat demektir. Tabloları Markdown tablosu olarak koru.
• Başlık hiyerarşisi. Bir parçanın hangi bölümün altında olduğu, anlamının yarısıdır. Başlık zincirini parçanın metnine ekle: Kurulum > Linux > Gereksinimler bilgisi olmadan "en az 8 GB" cümlesi neye dair belli değil.
• Kod blokları. Kodu düz metne karıştırma; girinti ve satır sonları anlam taşır.
• Yinelenen içerik. Her sayfanın altbilgisi, gezinme menüsü, çerez uyarısı — bunlar her parçaya bulaşır ve arama sonuçlarını kirletir. İndekslemeden önce temizle.
• Tarih ve sürüm. Belgenin ne zaman yazıldığı ve hangi sürüme ait olduğu metadata olarak saklanmalı; eski sürüm dokümantasyonunun yeniyle karışması en sinsi hata kaynağıdır.

Parçalama (chunking): kaç kelime, nerede kesilir

Modelin bağlamına bütün belgeyi koyamazsın; belgeyi parçalara ayırıp yalnızca ilgili parçaları getirirsin. Parça boyutu, RAG kalitesini en çok etkileyen tek parametredir.

İki pratik kural. Birincisi: anlamlı sınırlardan kes. Paragraf, başlık, madde sonu — sabit karakter sayısından değil. Cümlenin ortasından bölünen bir parça, iki yarım fikir üretir. İkincisi: örtüşme kullan. Ardışık parçalar arasında yüzde on-on beş örtüşme, sınıra denk gelen bilginin tamamen kaybolmasını engeller.

def chunk(text: str, target: int = 700, overlap: int = 80) -> list[str]:
    """Paragraf sınırlarını koruyarak hedef boyuta yakın parçalar üretir."""
    paras = [p.strip() for p in text.split("\n\n") if p.strip()]
    chunks, cur = [], []
    size = 0
    for p in paras:
        n = len(p.split())
        # Tek başına hedefi aşan paragrafı bölmek yerine kendi parçası yap;
        # bölmek tabloları ve kod bloklarını en çok bozan şey.
        if n > target:
            if cur: chunks.append("\n\n".join(cur)); cur, size = [], 0
            chunks.append(p)
            continue
        if size + n > target and cur:
            chunks.append("\n\n".join(cur))
            tail = cur[-1].split()[-overlap:]        # örtüşme
            cur, size = [" ".join(tail)], len(tail)
        cur.append(p); size += n
    if cur: chunks.append("\n\n".join(cur))
    return chunks

Parçayı zenginleştirmek: ebeveyn-çocuk deseni

Küçük parça iyi arama, büyük parça iyi cevap verir. Bu iki isteği aynı anda karşılayan yaygın bir desen var: küçük parçayı ara, büyük parçayı gönder. Gömme ve arama için 200 token'lık küçük parçalar kullanırsın; eşleşme bulunduğunda modele o parçanın ait olduğu daha geniş bölümü (ebeveyni) verirsin.

İkinci bir varyant, her parçaya indeksleme sırasında kısa bir bağlam cümlesi eklemek: "Bu bölüm, X ürününün Y sürümündeki kurulum adımlarını anlatır." Bu cümleyi bir kez model üretir ve parçayla birlikte saklarsın. Maliyeti indeksleme zamanında bir kereliktir; kazancı her aramada tekrarlanır, çünkü parça artık kendi başına anlaşılabilir hâle gelmiştir.

Gömme (embedding) modeli seçimi

Gömme, bir metni sayı dizisine — genellikle birkaç yüz ile birkaç bin boyutlu bir vektöre — çeviren modeldir. Anlamca yakın metinler, bu uzayda birbirine yakın noktalara düşer. Arama bu yakınlığı ölçerek çalışır.

Seçerken bakılacaklar:

• Dil desteği. Türkçe içerikle çalışacaksan, çok dilli bir model ya da Türkçe performansı ölçülmüş bir model seç. Yalnızca İngilizce üzerinde eğitilmiş bir gömme modeli Türkçe metinde belirgin biçimde zayıf kalır.
• Boyut. Yüksek boyut biraz daha iyi kalite, belirgin biçimde daha fazla depolama ve daha yavaş arama demek. Çoğu iş yükünde orta boyut yeterli.
• Maliyet ve yerleşim. API üzerinden gömme çıkarmak kolaydır ama her yeniden indekslemede fatura üretir. Kendi altyapında çalıştırılabilen açık modeller büyük koleksiyonlarda ciddi tasarruf sağlar.
• Asimetrik arama desteği. Soru ile belge farklı biçimlerdedir; bazı modeller sorgu ve belge için ayrı ön ek ("query:", "passage:") bekler. Bunu atlamak kaliteyi sessizce düşürür.

Vektör deposu: neyi nerede saklamalı

Vektörleri saklayacak ve benzerlik araması yapacak bir yer gerekiyor. Seçenekler kabaca üç grup:

Pratik tavsiye: zaten kullandığın veritabanıyla başla. Yüz bin parçaya kadar pgvector gibi bir eklenti gayet iyi iş görür ve yeni bir servis işletmek zorunda kalmazsın. Ölçek gerçekten büyüdüğünde taşınırsın — ve o zamana kadar hangi özelliklere ihtiyacın olduğunu öğrenmiş olursun. Bu tarafın derinlemesine anlatımı Vector Database Mühendisliği eğitiminde.

Benzerlik araması nasıl çalışır

Sorguyu da aynı gömme modelinden geçirir, elde ettiğin vektöre en yakın N vektörü ararsın. Yakınlık ölçüsü genellikle kosinüs benzerliği: iki vektör arasındaki açının kosinüsü, 1'e yaklaştıkça daha benzer.

Milyonlarca vektörde her birine tek tek bakmak pahalı olduğu için, vektör depoları yaklaşık komşu araması (ANN) yapar: HNSW gibi indeks yapılarıyla, doğruluktan biraz feragat ederek hızdan çok kazanırlar. Bu takas ayarlanabilir; indeks parametrelerini değiştirdiğinde hem hız hem isabet değişir. Varsayılanlarla başla, ölç, gerekiyorsa ayarla.

$ psql -c "explain analyze
    select id, 1 - (embedding <=> :q) as score
    from chunks order by embedding <=> :q limit 5;"
 
 Limit  (cost=0.00..8.12 rows=5)
   ->  Index Scan using chunks_embedding_hnsw on chunks
 Execution Time: 7.214 ms
# ✓ İndeks kullanılıyor.
 
$ # İndeks olmasaydı:
 Seq Scan on chunks  (cost=0.00..41233.00 rows=412330)
 Execution Time: 2841.006 ms
# → 400 kat fark. İndeksin varlığını mutlaka doğrula.

Vektör araması neden tek başına yetmez

Anlamsal arama güçlüdür ama bir zayıflığı var: tam eşleşme gerektiren şeylerde kötüdür. Ürün kodu, hata kodu, kişi adı, sürüm numarası — bunlar anlam taşımaz, kimlik taşır. "ERR-4412" sorgusunun vektörü, "ERR-4413" ile neredeyse aynıdır.

Çözüm hibrit arama: klasik anahtar kelime aramasını (BM25 gibi) vektör aramasıyla birlikte çalıştırıp sonuçları birleştirmek. Birleştirme için en yaygın ve en dayanıklı yöntem, iki listedeki sıralamaları harmanlayan basit bir formüldür — skorları doğrudan toplamaktan daha iyi çalışır, çünkü iki sistemin skor ölçekleri kıyaslanabilir değildir.

def reciprocal_rank_fusion(*ranked_lists, k: int = 60):
    """Skor ölçeklerini değil SIRALAMALARI birleştirir."""
    scores: dict[str, float] = {}
    for lst in ranked_lists:
        for rank, doc_id in enumerate(lst, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores, key=scores.get, reverse=True)

# kullanım
final = reciprocal_rank_fusion(
    vector_search(query, limit=50),
    keyword_search(query, limit=50),
)[:20]

Yeniden sıralama (reranking)

Arama elli aday getirdi; modele bunların hepsini gönderemezsin. Hangi beşi gerçekten ilgili? Gömme araması hızlıdır ama kabadır — sorgu ile belgeyi ayrı ayrı vektöre çevirdiği için aralarındaki ince ilişkiyi göremez.

Yeniden sıralayıcı (cross-encoder) sorgu ile adayı birlikte değerlendirir ve çok daha isabetli bir alaka skoru üretir. Yavaştır — bu yüzden bütün koleksiyona değil, aramanın getirdiği elli adaya uygulanır. İki aşamalı bu yapı — geniş ve hızlı arama, sonra dar ve isabetli sıralama — modern RAG sistemlerinin standardı.

Pratikte kazanç şöyle görünür: vektör aramasının ilk beşinde doğru belge yüzde altmış oranında varken, elli aday getirip yeniden sıralayınca ilk beşte bulunma oranı belirgin biçimde yükselir. Ölçüsünü kendi verinle çıkar; bu tür oranlar veri kümesine çok bağlıdır.

Bağlamı kurmak: kaç belge, hangi sırayla

Elinde sıralı beş parça var. Bunları prompt'a nasıl yerleştireceğin, sandığından daha önemli.

• Sayı: Üç ile beş arasında başla. Daha fazlası çoğu zaman kaliteyi artırmaz, maliyeti ve gecikmeyi artırır. On belge göndermek, modelin dikkatini dağıtmanın pahalı bir yoludur.
• Sıra: Modeller bağlamın başındaki ve sonundaki bilgiye, ortasındakinden daha çok dikkat eder. En alakalı parçayı ortaya gömme; başa ya da sona koy.
• Ayrım: Her parçayı kendi etiketli bloğuna koy ve kaynağını yaz. Parçaları tek bir metin blobuna yapıştırmak, modelin hangi bilginin nereden geldiğini kaybetmesine yol açar.
• Bütçe: Belgeler için bir token tavanı belirle ve aşıldığında en düşük skorlu parçayı at — konuşma geçmişini değil.

def build_context(chunks: list[Chunk], budget: int = 3000) -> str:
    parts, used = [], 0
    for i, c in enumerate(chunks, start=1):
        block = (
            f'<kaynak id="{i}" belge="{c.doc_title}" '
            f'bolum="{c.heading_path}" tarih="{c.updated_at}">\n'
            f"{c.text}\n</kaynak>"
        )
        n = count_tokens(block)
        if used + n > budget:
            break                      # en düşük skorlular doğal olarak dışarıda kalır
        parts.append(block); used += n
    return "\n\n".join(parts)

Prompt tarafı: kaynak gösterme ve bilmeme hakkı

Doğru belgeleri getirdin; iş bitmedi. Modele ne yapacağını söylemen gerekiyor ve burada iki talimat diğerlerinden daha değerli.

Birincisi kaynak gösterme zorunluluğu. Modelden her iddianın yanına kaynak numarasını yazmasını iste. Bu üç işe yarar: kullanıcı doğrulayabilir, sen hata ayıklayabilirsin ve — en önemlisi — model kaynak göstermek zorunda olduğunu bildiğinde uydurma eğilimi düşer.

İkincisi bilmeme hakkı. Getirilen belgelerde cevap yoksa model bunu söyleyebilmeli. Açıkça izin vermezsen, eldeki alakasız metinden bir cevap türetmeye çalışır. "Kaynaklarda bu bilgi yoksa 'Bu konuda kayıtlarımızda bilgi bulamadım' de" cümlesi, halüsinasyon oranını tek başına ciddi biçimde düşürür.

SYSTEM = """Sen bir dokümantasyon asistanısın.

Kurallar:
1. SADECE <kaynak> bloklarındaki bilgiyi kullan. Genel bilgini kullanma.
2. Her iddianın sonuna kaynak numarasını yaz: [1], [2].
3. Kaynaklarda cevap yoksa: "Bu konuda kayıtlarımızda bilgi bulamadım."
   Tahmin yürütme, benzer konudan çıkarım yapma.
4. Kaynaklar birbiriyle çelişiyorsa çelişkiyi belirt ve tarihi yeni olanı öne al.
"""

Metadata filtreleme ve yetkilendirme

Bu, RAG'ın en çok atlanan ve en tehlikeli tarafı. Vektör araması anlamsal olarak en yakın parçaları getirir — kullanıcının o parçayı görmeye yetkisi olup olmadığını umursamaz. İK belgelerini ve maaş bilgilerini aynı koleksiyona indekslersen, doğru soruyu soran herkes onları görebilir.

Doğru yaklaşım, yetkilendirmeyi arama sorgusunun içine koymak; sonucu aldıktan sonra filtrelemek değil:

# YANLIŞ: önce ara, sonra ele
hits = vector_search(q, limit=5)
visible = [h for h in hits if can_read(user, h.doc_id)]
# → 5 sonucun 4'ü elenirse elinde 1 parça kalır; kalite çöker,
#   üstelik hangi belgelerin var olduğu sızmış olur.

# DOĞRU: filtreyi aramaya ver
hits = vector_search(
    q,
    limit=5,
    where={"acl_group": {"$in": groups_of(user)}},   # depo seviyesinde filtre
)

Filtreyi depo seviyesinde uygulamak hem doğru sayıda sonuç almanı sağlar hem de yetkisiz içeriğin hiçbir aşamada sürece girmemesini garantiler. Çok kiracılı bir sistemde kiracı kimliğini de aynı şekilde filtreye koy — ve önbellek anahtarına eklemeyi unutma, yoksa bir kiracının cevabı diğerine servis edilebilir.

Çok kiracılı kurulumlar

Birden fazla müşteriye hizmet veren bir sistemde soru şu: tek koleksiyon mu, kiracı başına koleksiyon mu?

• Tek koleksiyon + kiracı filtresi. İşletmesi basit, maliyeti düşük. Riski, filtrenin bir kod yolunda unutulması — ve bu sızıntı sessizdir. Filtreyi depo erişim katmanında zorunlu kıl; çağıranın unutabileceği bir parametre olmasın.
• Kiracı başına koleksiyon. İzolasyon güçlü, silme talebi kolay (koleksiyonu düşürürsün). Yüzlerce kiracıda operasyon yükü artar.
• Hibrit. Küçük kiracılar ortak koleksiyonda, büyük veya düzenlemeye tabi kiracılar kendi koleksiyonunda. Çoğu SaaS bu noktaya geliyor.

Hangisini seçersen seç, üç yerde kiracı kimliği olmalı: arama filtresinde, önbellek anahtarında ve log satırında. Üçüncüsü hata ayıklama için, ilk ikisi sızıntıyı önlemek için.

Değerlendirme: getirmeyi ve üretmeyi ayrı ölç

RAG değerlendirmesinde en yaygın hata, sistemi tek bir kutu gibi ölçmek. Cevap kötü çıktığında "model kötü" denir ve prompt'la oynanır — oysa vakaların çoğunda doğru belge hiç gelmemiştir.

İki metriği ayrı tut:

Getirme metriğini ölçmek için elle hazırlanmış bir küme gerekir: soru + o soruyu cevaplayan belgenin kimliği. Elli soru yeterli bir başlangıç. Bu küme, parça boyutunu ya da gömme modelini değiştirdiğinde iyileştirip iyileştirmediğini söyleyecek tek şey. Değerlendirme altyapısının genel kurgusu için LLM tabanlı uygulama geliştirme yazısındaki golden set bölümüne, derinlemesine anlatım için AI Agent Evaluation & Observability eğitimine bakabilirsin.

Kötü cevabı teşhis etme sırası

Bir kullanıcı "cevap yanlış" dediğinde, bakılacak yerlerin bir sırası var. Bu sırayı atlayıp doğrudan prompt'la oynamak, RAG projelerinde en çok zaman kaybettiren alışkanlık.

1. 1Doğru belge koleksiyonda var mı? Yoksa problem indekslemede; arama ve prompt'la uğraşmanın anlamı yok.
2. 2Arama o belgeyi getirdi mi? Getirmediyse problem getirmede: parçalama, gömme modeli, hibrit arama, yeniden sıralama.
3. 3Getirdi ama sırası düşük mü? İlk elli içinde ama ilk beşte değilse, yeniden sıralayıcı eklemenin tam yeri.
4. 4Bağlama girdi mi? Token bütçesi yüzünden kesilmiş olabilir. Bütçe ve kesme mantığını logla.
5. 5Model önündeki bilgiyi kullandı mı? Buraya kadar her şey doğruysa ve cevap hâlâ yanlışsa, evet, artık prompt işi.

Bu beş adımı hızlı yürütebilmek için her istekte getirme ayrıntısını loglamak gerekir: hangi sorgu atıldı, hangi parça kimlikleri hangi skorla geldi, hangileri bağlama girdi. Bu log olmadan teşhis tahmine dönüşür. Bir hata ayıklama uç noktası açmak (yalnızca yetkili kullanıcılara) bu işi saniyelere indirir.

$ curl -s localhost:8080/debug/retrieve \
    -d '{"q":"sertifika yenileme süresi"}' | jq -r '.hits[] | "\(.score|.*1000|floor/1000)  \(.doc)  \(.heading)"'
0.812  sertifika-politikasi-v3.md  Yenileme > Süreler
0.774  sertifika-politikasi-v2.md  Yenileme > Süreler
0.603  onboarding.md               Sık Sorulanlar
# → v2 ve v3 birlikte gelmiş: eski sürüm hâlâ indekste.
# ✓ Teşhis getirmede, prompt'ta değil: sürüm filtresi eksik.

Bir vaka: aramanın sessizce boş dönmesi

Bir iç dokümantasyon asistanı, aylardır iyi çalışıyor. Bir gün kullanıcılar "artık hiçbir şey bilmiyor" demeye başlıyor. Model her soruya "Bu konuda kayıtlarımızda bilgi bulamadım" diye cevap veriyor — yani aslında talimatı doğru uyguluyor.

$ curl -s localhost:8080/debug/retrieve -d '{"q":"VPN kurulumu"}' | jq '.hits | length'
0
 
$ psql -c "select count(*) from chunks;"
 412330
# → Parçalar duruyor.
 
$ psql -c "select count(*) from chunks where embedding is null;"
 412330
# → Ama hiçbirinin vektörü yok.
 
$ kubectl logs job/reindex --tail=5
  embedding provider returned 429 (rate limited), retrying...
  embedding provider returned 429 (rate limited), retrying...
  giving up after 5 attempts; wrote 412330 rows with null embedding
# ✓ Yeniden indeksleme işi hız sınırına takılmış, ama sıfır çıkış koduyla bitmiş.

Kök neden: gece çalışan yeniden indeksleme işi, gömme sağlayıcısının hız sınırına takılmıştı. Hata yakalanmış, loglanmış ve — kritik hata — iş başarılı sayılarak bitirilmişti. Eski vektörler silinmiş, yenileri yazılamamıştı. Sistem teknik olarak çalışıyordu: arama sıfır sonuç dönüyor, model doğru davranıp bilmediğini söylüyordu.

Düzeltme üç parçaydı. İndeksleme işi kısmi başarıda sıfır dönmeyecek. Boş vektörlü satır oranı bir metrik olarak izlenecek. Ve en önemlisi: yeni indeks eskisini silmeden yazılacak, ancak doğrulama geçtikten sonra takas edilecek. Mavi-yeşil dağıtımın veri tarafındaki karşılığı.

Tazelik: veri değiştiğinde ne olur

Belgeler değişir, silinir, yenisi eklenir. İndeksin bunu takip etmesi gerekiyor ve bunun üç yaygın düzeni var.

• Tam yeniden indeksleme. Basit ve pahalı. Küçük koleksiyonlarda gece işi olarak gayet iyi; büyüdükçe sürdürülemez.
• Artımlı güncelleme. Yalnızca değişen belgeleri yeniden işlemek. Kaynak sistemde değişiklik tarihi veya webhook varsa en iyi seçenek. Silinen belgelerin indeksten çıkarılmasını unutma — en sık atlanan adım budur.
• Sürümlü indeks. Yeni indeksi ayrı bir koleksiyona yaz, doğrula, sonra takas et. Yukarıdaki vakanın önlemi; büyük yeniden indekslemelerde standart olmalı.

Tazelikle ilgili ikinci konu kullanıcıya ne söylediğin. Cevabın hangi tarihli belgeye dayandığını göstermek, güveni ciddi biçimde artırır. "Bu bilgi 14 Mart 2026 tarihli kurulum kılavuzundan" demek, aynı cevabı tarihsiz vermekten çok daha kullanışlıdır.

Maliyet ve gecikme

RAG iki yerde maliyet üretir ve ikisi farklı davranır. İndeksleme maliyeti koleksiyon boyutuyla orantılı, seyrek ve öngörülebilir. Sorgu maliyeti trafikle orantılı ve her istekte tekrarlanıyor: bir gömme çağrısı, bir arama, ve modelin bağlamına eklenen belgelerin token maliyeti.

En büyük kalem genellikle sonuncusu. Beş parça × 700 token = 3.500 token, her soruda. Gecikme tarafında da sıralama benzer: gömme çağrısı ve vektör araması genellikle toplamda yüz milisaniyenin altında kalır; asıl bekleme modelin cevabı üretmesinde.

• Sık sorulan sorular için cevap önbelleği kur — aynı soruya aynı cevap, hem bedava hem anında. Önbellek anahtarına kiracı ve yetki grubunu eklemeyi unutma.
• Getirilen parça sayısını deneysel olarak düşür; kalite kaybı olmadan beşten üçe inebiliyorsan maliyetin yüzde kırkını kestin.
• Gömme sonuçlarını önbellekle: aynı sorgu tekrar geldiğinde vektörü yeniden hesaplama.
• Akış (streaming) kullan — algılanan gecikmeyi dramatik biçimde düşürür.

Tablolar, sayılar ve karma içerik

Metin tabanlı RAG düz nesirde iyi çalışır; belgelerin tablo ve sayı ağırlıklı olduğunda ayrı bir strateji gerekir. Bir fiyat tablosunun satırını serbest metin gibi gömmek, arama açısından neredeyse işe yaramaz — çünkü "399" sayısının vektörü hiçbir anlam taşımaz.

Pratikte işe yarayan üç yaklaşım:

• Tabloyu cümleye çevir. Her satır için indeksleme sırasında bir cümle üret: "Başlangıç paketi aylık 399 TL, 5 kullanıcı ve 10 GB depolama içerir." Aranabilir olan bu cümledir; modele hem cümleyi hem orijinal satırı verirsin.
• Tabloyu bütün olarak sakla. Küçük tabloları parçalama; tamamını tek bir parça yap ve başlık satırını koru. Bölünmüş bir tablo, sütun ilişkisi koptuğu için yanlış cevap üretir.
• Sayısal soruları yönlendir. "Kaç", "toplam", "en yüksek" gibi soruları vektör aramasına değil, yapılandırılmış bir sorguya yönlendir. Bu tür sorularda RAG'ın yapısal olarak zayıf olduğunu kabul etmek, onu zorlamaktan iyidir.

Görsel içerik ve taranmış belgeler

Kurumsal arşivlerin önemli bir kısmı taranmış PDF: metin katmanı yok, sayfa aslında bir görsel. Bunları OCR'dan geçirmeden indekslemek mümkün değil ve OCR kalitesi doğrudan RAG kalitesine dönüşüyor.

İki nokta önemli. Birincisi, OCR hatası sessizdir: "1000" yerine "l000" okunduğunda arama da cevap da bozulur ama hiçbir yerde hata görünmez. İndeksleme sırasında OCR güven skorunu sakla ve düşük skorlu sayfaları işaretle. İkincisi, diyagram ve şema taşıyan sayfalarda metin tek başına yetmez; sayfanın görsel açıklamasını bir model ile üretip metne eklemek, o sayfaların aranabilirliğini belirgin biçimde artırır.

Bu tarafın kapsamı hızla genişliyor; çok biçimli içerikle çalışma Multimodal AI eğitiminin konusu.

RAG'ın sınırları

RAG her şeyi çözmez ve sınırlarını bilmek, yanlış yere yatırım yapmanı engeller.

• Toplama ve sayma sorularında zayıftır. "Kaç müşterimiz var" sorusunun cevabı bir belgede yazmıyorsa, benzerlik araması bulamaz. Bu tür sorular veritabanı sorgusu ister.
• Çok adımlı akıl yürütmede tek atış yetmez. "A ürününün B özelliğinin C sürümündeki davranışı" gibi sorular, birden fazla arama turu gerektirebilir. Burada iş ajanlara doğru kayar — bkz. AI ajanları nasıl çalışır.
• Belge kalitesinden iyi olamaz. Dokümantasyonun eksikse, RAG o eksikliği görünür kılar; kapatmaz. Çoğu RAG projesinin gerçek çıktısı, dokümantasyonun ne kadar kötü olduğunun ölçülmesidir.
• Üslup ve format problemi çözmez. Modelin cevap biçimini değiştirmek istiyorsan bu prompt işi ya da fine-tuning işi; RAG'ın konusu değil.

İleri varyantlar: ne zaman gerekir

Temel RAG'ı kurup ölçtükten sonra, gerçekten sıkıştığın yerde bakılacak birkaç yön var. Sıraya dikkat: bunlar temel sistem çalışmadan denendiğinde yalnızca karmaşıklık ekler.

Sorgu yeniden yazma

Kullanıcının sorusu arama için kötü biçimlendirilmiş olabilir: çok kısa, bağlama bağımlı ("peki ya ikincisi?") ya da birden fazla soruyu içeriyor. Aramadan önce modelden sorguyu yeniden yazmasını ya da alt sorulara bölmesini istemek, çok turlu sohbetlerde belirgin fark yaratır.

Çok turlu getirme (agentic RAG)

Model bir arama yapar, sonucu görür, eksik kalanı fark eder ve ikinci bir arama yapar. Karmaşık sorularda kaliteyi artırır; gecikmeyi ve maliyeti de artırır. Tur sayısına mutlaka üst sınır koy.

Graf destekli getirme

Belgeler arası ilişkileri bir grafta modelleyip aramayı bu yapı üzerinden genişletmek. Varlıklar arası ilişkilerin sorunun merkezinde olduğu alanlarda (organizasyon şemaları, bileşen bağımlılıkları) değerli; genel dokümantasyon aramasında getirisi kurulum maliyetini çoğu zaman karşılamaz.

Kaynak seçimi: her belgeyi indekslememek

İlk refleks bütün kurumsal içeriği indekslemek olur. Bu, neredeyse her zaman kaliteyi düşürür. Taslak hâlinde kalmış belgeler, iptal edilmiş projelerin notları, üç yıl önceki toplantı kayıtları — hepsi arama sonuçlarında gerçek dokümantasyonla yarışır ve bazen kazanır.

İndeksleme kararını bilinçli ver. Her kaynak için üç soru: güncel tutuluyor mu, bir sahibi var mı, doğruluğuna güveniliyor mu. Üçüne birden evet diyemediğin kaynağı ya dışarıda bırak ya da ayrı bir koleksiyona koyup arama sırasında düşük ağırlık ver. Kapsamı geniş tutmak cazip görünür; pratikte dar ve temiz bir koleksiyon, geniş ve kirli olandan belirgin biçimde daha iyi sonuç verir.

Aynı mantık silme tarafında da geçerli. Bir belge kaynak sistemde silindiğinde indeksten de düşmeli; artımlı güncellemede en sık atlanan adım budur ve sonucu, artık var olmayan bir politikayı anlatan bir asistandır.

Sık sorulanlar

Bağlam pencereleri büyüdü, RAG'a hâlâ gerek var mı?

Belge sayın azsa gerek kalmayabilir; yüz sayfalık bir el kitabını doğrudan bağlama koymak artık mümkün. Ama üç kısıt duruyor: o bağlamı her istekte tekrar ödüyorsun, gecikme bağlamla birlikte artıyor ve uzun bağlamda ortadaki bilginin gözden kaçma eğilimi tamamen kaybolmuyor. On binlerce belgeyle çalışıyorsan getirme katmanı hâlâ gerekli.

Getirme skorunun altına bir eşik koymalı mıyım?

Evet, ama dikkatli. Skor eşiği, alakasız parçaların bağlama girmesini engeller ve modelin "bilmiyorum" demesini kolaylaştırır. Riski, eşiği yüksek tutunca doğru ama düşük skorlu belgelerin de elenmesi. Pratik yol: eşiği getirme kümenle kalibre et — yanlış cevabı azaltırken kaç doğru cevabı kaybettiğini ölç. Sabit bir sayı yerine, koleksiyonun skor dağılımına göre belirlenmiş göreli bir eşik genelde daha dayanıklı.

Hangi parça boyutu en iyisi?

Evrensel bir cevabı yok ve olan bitenin çoğu veri türüne bağlı. 500-800 token iyi bir başlangıç; sonrasını elli soruluk getirme kümenle ölçerek ayarla. Bu parametreyi "en iyi uygulama" listelerinden değil, kendi verinden öğreneceksin.

Birden fazla dilde belgem var, ne yapmalıyım?

Çok dilli bir gömme modeli kullan; böylece Türkçe bir soru İngilizce bir belgeyi bulabilir. Alternatif olarak dil başına ayrı koleksiyon tutup sorgu dilini tespit edip yönlendirebilirsin — daha çok iş ama her dilde en iyi modeli kullanma esnekliği verir.

Kullanıcıya kaynakları göstermeli miyim?

Evet, neredeyse her zaman. Kaynak göstermek güveni artırır, kullanıcının doğrulamasına imkân verir ve destek yükünü azaltır. Kaynağın adını ve tarihini göster; mümkünse belgeye doğrudan bağlantı ver.

Kullanıcı sorusunu yeniden yazmak gerçekten gerekli mi?

Tek turlu aramalarda genelde gerekmez. Çok turlu sohbette ise neredeyse şart: "peki fiyatı ne kadar" sorusunun vektörü, neyin fiyatından bahsedildiğini bilmediği için işe yaramaz. Konuşma geçmişini kullanarak sorguyu bağımsız bir soruya çevirmek ("Başlangıç paketinin fiyatı ne kadar") bu durumu düzeltir. Maliyeti küçük bir model çağrısı, kazancı belirgin.

Aynı anda birden fazla koleksiyonda arama yapabilir miyim?

Evet ve çoğu olgun sistem bunu yapıyor: dokümantasyon, destek biletleri ve ürün kataloğu ayrı koleksiyonlarda durur, sorgu hepsine gider, sonuçlar birleştirilir. Avantajı her koleksiyonun kendi parçalama ve tazelik politikasına sahip olabilmesi. Birleştirmeyi yine sıralama harmanlamasıyla yap; koleksiyonlar arası skorlar doğrudan kıyaslanabilir değildir.

RAG kurmak ne kadar sürer?

Çalışan bir ilk sürüm birkaç gün. Üretim kalitesinde bir sistem — yetkilendirme, tazelik, değerlendirme, izleme dahil — haftalar. Sürenin çoğu model tarafında değil, belge hazırlama ve değerlendirme tarafında geçer; bu iki iş neredeyse her projede tahminlerin iki katını alır.

Ekip ve süreç tarafı

RAG projelerinin teknik olmayan başarısızlık biçimi hep aynı: kimsenin dokümantasyonu sahiplenmemesi. Sistem kurulur, ilk hafta iyi çalışır, sonra belgeler eskir ve kimse güncellemez. Altı ay sonra asistan eski politikayı anlatıyordur ve kimse ne zaman yanlışlamaya başladığını bilmez.

Bunu önleyen üç pratik var. Birincisi, her cevapta kaynak belgeyi ve tarihini göstermek — böylece eski bir belge kullanıcı tarafından fark edilir. İkincisi, en sık getirilen yirmi belgeyi periyodik olarak raporlamak; bunlar sistemin omurgası ve güncel tutulması gereken ilk belgeler. Üçüncüsü, "kayıtlarımızda bilgi bulamadım" cevaplarını loglamak: bu liste, dokümantasyonda hangi boşlukların olduğunu doğrudan söyleyen ücretsiz bir içerik yol haritasıdır.

Üretime çıkmadan önce kontrol listesi

1. 1Belge çıkarma sonuçlarını elle okudum; tablolar ve başlıklar bozulmuyor.
2. 2Parçalar başlık zinciri ve tarih metadata'sı taşıyor.
3. 3Hibrit arama açık; yalnızca vektör aramasına güvenmiyorum.
4. 4Yetkilendirme filtresi arama sorgusunun içinde, sonrasında değil.
5. 5Elli soruluk bir getirme kümem ve ölçülmüş bir recall@5 değerim var.
6. 6Model kaynak göstermek zorunda ve "bilmiyorum" diyebiliyor.
7. 7Sıfır sonuç dönen sorgu oranı ve boş vektör oranı izleniyor.
8. 8Yeniden indeksleme kısmi başarıda hata veriyor; yeni indeks doğrulanmadan takas edilmiyor.

Bu sekiz maddenin hepsi evet değilse sistem üretime hazır değil — demoda iyi çalışıyor olması bunu değiştirmiyor. Özellikle dördüncü madde: yetkilendirme sonradan eklenecek bir şey değil, baştan aramanın parçası olmalı.

Küçük başlamak için minimum kurulum

Bütün bu listeler kapsamlı bir sistemi anlatıyor; ilk sürüm bu kadar olmak zorunda değil. Bir hafta sonunda çalışan, işe yarar bir RAG için gereken asgari şu: bir klasör dolusu Markdown belge, paragraf sınırlarından parçalama, bir gömme modeli, pgvector kurulu bir PostgreSQL ve on beş satırlık bir arama fonksiyonu.

Bu ilk sürümü kurduğunda elde edeceğin en değerli şey kod değil, ölçüm: kendi verinle recall@5 ne çıkıyor, hangi sorular cevaplanamıyor, belgelerin gerçekte ne kadar dağınık. Bu üç bilgiyi öğrenmeden yapılan mimari tartışmaları, veriye değil tahmine dayanır. Önce ölç, sonra karmaşıklaştır — bu yazıdaki her ileri teknik, ancak ölçülmüş bir eksikliğe cevap verdiğinde değerlidir.

Sonraki adım

RAG, modelin bilgi boşluğunu kapatır. Ama bilgiyi okuyup cevap vermek, bazen yetmez: kullanıcı bir şeyin yapılmasını istiyorsa, modelin metin üretmenin ötesine geçmesi gerekir. Araç kullanımı, karar verme ve çok adımlı görevler konusu ayrı bir yazının konusu: AI ajanları nasıl çalışır.

Son bir hatırlatma: bu yazıdaki tekniklerin hiçbiri tek başına "iyi RAG" üretmez. Kalite, belge hazırlamadan yetkilendirmeye kadar uzanan zincirin en zayıf halkasıyla sınırlı. Zinciri baştan sona kurduktan sonra ölçmeye başla, ölçtükten sonra tek tek iyileştir — ve her iyileştirmede aynı elli soruyu tekrar çalıştır. Bu döngü, bu işi öğrenmenin en kısa yolu.

Vektör tarafını derinleştirmek istersen Vector Database Mühendisliği, RAG'ı uçtan uca bir eğitim olarak almak istersen RAG Mühendisliği sayfalarına bakabilirsin. Temel kavramlara geri dönmek için LLM tabanlı uygulama geliştirme her zaman açık.