RAG ve vektör veritabanları: bağlamı modele taşırken bilmeniz gerekenler
RAG’in amacı: modelin hafızası değil, kanıtlanabilir bağlam
RAG (Retrieval-Augmented Generation) akışı tipik olarak şöyle işler: kullanıcı sorusu → sorgu embed edilir veya metin ile indeks aranır → en alakalı parçalar seçilir → bu parçalar modele sistem mesajı veya bağlam bloğu olarak eklenir → model cevap üretir. Başarıyı belirleyen şey çoğu zaman modelin “ne kadar büyük” olduğundan çok hangi parçaların seçildiği ve seçimin kalitesidir. Yanlış veya bağlam dışı parça seçimi halüsinasyonu besler; doğru parça seçimi ise model mecburen daha bağlı kalır.
Chunking ve örtüşme (overlap)
Belgeyi yanlış boyutta keserseniz cümleyi iki parçaya bölersiniz ya da gereksiz gürültü taşıyan dev blokları modele sızdırırsınız. Tipik yaklaşım: anlamlı sınır (paragraf, başlık) öncelikli, token/s karakter limiti ikincil. Örtüşme (ör. ardışık parçalar arasında %10–20 tekrar) bağlam kopukluğunu azaltır fakat indeks boyutunu ve maliyeti artırır. Domain’e göre chunk boyutu A/B ile ölçülmelidir — sabit 512 token her veri seti için optimal değildir.
Embedding modelleri ve benzerlik metrikleri
Metinleri vektöre çeviren modeller dil ve domain’e duyarlıdır; hukuk metinleri ile teknik API dokümantasyonu aynı embedder ile her zaman iyi ayrışmaz. Cosine benzerliği yaygın kullanılır; fakat normalize edilmemiş vektörlerde veya kısa sorgularda sonuçlar sapabilir. Çok dilli içerikte çok dilli embedder seçimi şart. Ayrıca embedding sürümünü değiştirdiğinizde indeksi yeniden oluşturmanız gerekir — bu operasyonel maliyeti planlayın.
Vektör indeksleri: HNSW, IVF ve maliyet
Gerçek zamanlı yakın komşu araması için yoğun indeks yapıları (HNSW gibi graf tabanlı yaklaşımlar, IVF gibi kümeleme tabanlı yaklaşımlar) kullanılır. Her yapının bellek ayak izi, ekleme maliyeti ve hatırlama (recall) eğrisi farklıdır. Küçük veri setinde brute force bile yeterli olabilir; milyonlarca vektörde ise yanlış indeks seçimi hem gecikmeyi hem maliyeti şişirir. Üretimde indeks parametrelerini yük altında ölçün.
Reranking ve çok aşamalı retrieval
İlk aşamada hızlı ama kaba vektör araması, ikinci aşamada daha ağır cross-encoder veya küçük bir sınıflandırıcı ile yeniden sıralama birçok üründe kaliteyi ciddi artırır. Maliyet artar; bu yüzden ilk aşamada aday kümesini daraltıp ikinci aşamayı sadece top-k üzerinde çalıştırmak tipik desendir. Loglardan ‘doğru parça kaçıyor mu?’ sorusunu izleyin.
Operasyonel kontrol listesi
- ACL: retrieval sonucu kullanıcı rolüne göre filtrelenmeli — modelden önce.
- Kaynak atfı: hangi chunk ID’lerinin bağlama girdiğini loglayın; destek vakalarında hayat kurtarır.
- Drift: doküman güncellenince eski embedding’ler yanıltıcı olur — yeniden indeksleme borcu birikir.
- Eval: referans soru seti + beklenen kaynak parça ID’leri ile otomatik skor.
- Maliyet: embedding + vektör DB + model çıktısı üçlüsünü birlikte izleyin.



