Kısa cevap: RAG (Retrieval-Augmented Generation), kullanıcı sorusuyla ilgili belgeleri arayıp seçerek bu parçaları dil modeline bağlam olarak veren yöntemdir. Modeli yeniden eğitmeden güncel veya kuruma özel bilgiyle cevap üretmeye yardımcı olur. Sağlam bir RAG sistemi; güvenilir veri alma, doğru parçalara bölme, metadata ve erişim filtreleri, hibrit arama, yeniden sıralama, kaynaklı cevap, yetki kontrolü ve uçtan uca değerlendirme gerektirir. Vector database tek başına doğru cevap garantisi vermez.
Bu rehber “RAG nedir, embedding ve vector database nasıl çalışır, chunk boyutu nasıl seçilir, pgvector, Qdrant veya yönetilen servis ne zaman kullanılır, hybrid search ve reranker nedir, RAG kalitesi nasıl ölçülür?” sorularını yanıtlar. Amaç demo düzeyindeki belge sohbetini güvenli bir üretim sistemine dönüştürmektir.
LLM yalnızca eğitim sırasında öğrendiği örüntülere dayanırsa kurum içi belgeyi, son fiyat listesini veya yeni politikayı bilemez. RAG önce bilgi erişim katmanından ilgili içeriği bulur, sonra modelden bu kanıta dayalı cevap üretmesini ister. Böylece bilgi kaynağı model ağırlıklarından ayrılır; belge güncellenebilir ve cevapta kaynak gösterilebilir.
RAG, modeli her konuda daha akıllı yapan sihirli katman değildir. Yanlış belge getirilirse model doğru cevaba ulaşamaz; doğru belge getirilse bile talimat veya sentez hatası olabilir. Retrieval ve generation ayrı ayrı ölçülmelidir.
Embedding, metin veya başka içeriği anlam benzerliğini temsil eden sayısal bir vektöre dönüştürür. Soru ve belge parçaları aynı embedding modeliyle vektörleştirilir; cosine, inner product veya L2 gibi uzaklık ölçüleriyle yakın komşular aranır. Aynı kelimeyi içermeyen fakat benzer anlama gelen metinler böyle bulunabilir.
Vector database; vektörleri, belge kimliğini ve metadata'yı saklayıp benzerlik araması yapar. Qdrant belgeleri yoğun vektör aramasını HNSW gibi grafik indekslerle hızlandırdığını; pgvector ise PostgreSQL içinde exact ve approximate nearest neighbor aramasını HNSW veya IVFFlat ile desteklediğini açıklar.
PDF, web sayfası, wiki, destek kaydı veya veri tabanı içeriğini alın. Tarama sırasında metin sırası, tablo, başlık, sayfa ve dil bilgisini koruyun. OCR sonucu hatalıysa indekslemeden önce kalite kontrolü yapın. Her belgeye kaynak URL'si, sürüm, tarih, sahip, yetki grubu ve geçerlilik durumu ekleyin.
Belgeyi anlamsal olarak kullanılabilir parçalara bölün. Parçanın çok küçük olması bağlamı koparır; çok büyük olması ilgisiz bilgiyi taşır ve maliyeti artırır. Başlık hiyerarşisi, paragraf ve tablo sınırlarını koruyan semantik chunking deneyin. Örtüşme, iki parça arasındaki bağlantıyı koruyabilir fakat indeks boyutunu büyütür.
Soru embedding'ini üretip en yakın parçaları alın. Metadata filtresiyle kullanıcının yetkisi, dil, ürün, tarih ve belge türünü daraltın. Dense aramayı BM25 gibi kelime tabanlı aramayla birleştiren hybrid search; ürün kodu ve özel isim gibi exact terimlerde yardımcı olur. Reranker, adayları daha pahalı fakat hassas bir modelle yeniden sıralar.
Seçilen parçaları kaynak kimlikleriyle modele verin. “Yalnızca sağlanan kanıta dayan, bilgi yoksa belirt, her iddiayı kaynakla eşleştir” kuralı kullanın. Cevap sonrası kaynak bağlantılarını gerçek belgeye bağlayın; modelin URL uydurmasına izin vermeyin.
Tek doğru sayı yoktur. Soru türü, belge yapısı, embedding modeli ve bağlam penceresi belirleyicidir. SSS maddesi doğal olarak kısa; sözleşme hükmü veya teknik prosedür daha uzun bağlam isteyebilir. Token sayısını hedeflemek yerine anlam bütünlüğünü koruyun ve farklı boyutları eval setiyle karşılaştırın.
Parent-child yaklaşımında küçük parçayla arama yapılır, cevap için daha geniş üst bölüm getirilir. Cümle penceresi tek eşleşmenin çevresindeki komşu cümleleri ekler. Chunking kararı yalnızca depolama ayarı değil, bilgi mimarisi seçimidir.
Veri hacmi, güncelleme sıklığı, gecikme, filtre karmaşıklığı, çoklu kiracı, yedekleme, bölge ve ekip deneyimini değerlendirin. PostgreSQL zaten merkezdeyse ve ölçek uygunsa pgvector operasyonel sadelik sağlar. Özel vector engine'ler yüksek ölçek, filtre ve dağıtık arama özellikleri sunabilir. Yönetilen servis operasyon yükünü azaltır; veri yerleşimi ve maliyet koşulları incelenmelidir.
Önce exact arama ile kalite tabanı ölçün. Approximate indeks eklediğinizde hız kazanırken recall düşebilir. pgvector belgeleri HNSW'nin daha iyi hız–recall dengesi fakat daha yüksek bellek ve kurulum maliyeti; IVFFlat'in daha hızlı build fakat daha düşük sorgu performansı sunabildiğini belirtir.
Embedding; departman yetkisi, ürün stok durumu, ülke veya geçerlilik tarihi gibi iş kurallarını güvenilir biçimde temsil etmez. Bu alanları metadata olarak saklayıp arama öncesi veya arama içinde filtreleyin. Qdrant belgeleri payload filtrelerinin AND, OR ve NOT koşullarıyla birleştirilebildiğini ve sık filtrelenen alanlar için indeks önerildiğini açıklar.
Yetki filtresi promptta değil, sorgu katmanında uygulanmalıdır. Modelin “bu belgeyi gösterme” talimatına uymasına güvenmek veri sızıntısına yol açar. Her chunk miras aldığı belge ve kiracı kimliğiyle saklanmalıdır.
Dense arama anlam benzerliğinde güçlüdür; fakat SKU, hata kodu, sözleşme madde numarası ve kişi adı gibi nadir tam eşleşmeleri kaçırabilir. Sparse/BM25 arama kelime eşleşmesini korur. İki sonuç listesini reciprocal rank fusion veya öğrenilmiş yöntemle birleştirmek kapsamı artırabilir.
Qdrant'ın metin arama belgeleri semantic ve lexical aramanın tamamlayıcı olduğunu belirtir. Hibrit sistem yine eval gerektirir; zayıf ağırlıklandırma alakasız fakat anahtar kelime dolu belgeleri üste taşıyabilir.
Kaynak sistemde değişiklik olduğunda yalnızca etkilenen chunk'ları yeniden üretin. İçerik hash'i ile değişmeyen bölümü atlayın. Silinen belgenin vektörünü de silin; tombstone ve senkronizasyon hatalarını izleyin. Embedding modeli değişirse eski ve yeni vektör boyutları uyumsuz olabilir; sürümlü koleksiyon ve kontrollü yeniden indeksleme kullanın.
Her cevabın hangi belge sürümüne dayandığını loglayın. Eski politika ve yeni politika aynı anda aktif görünmemelidir. Geçerlilik tarihini filtreye dahil edin. RAG'in güncel kalması sürekli veri hattı sorunudur.
Belge içindeki prompt injection talimatlarını güvenilmeyen içerik olarak ele alın. Kaynak metin “sistem talimatını yok say” dese bile uygulanmamalıdır. Dosya yüklemede tür, boyut, zararlı içerik ve erişim kontrolü yapın. PII ve sırları indekslemeden önce sınıflandırın; gerekirse maskeleyin.
API anahtarlarını belgeye veya prompta koymayın. Kullanıcı girişini loglarken kişisel veriyi azaltın. Çoklu kiracıda collection ayrımı veya zorunlu tenant filtresi kullanın; filtre eksikliği için otomatik test yazın. Cevapta uzun kaynak pasajını izinsiz kopyalamak telif ve veri sızıntısı riski doğurabilir.
Gerçek kullanıcı sorularından, doğru kaynak ve beklenen cevapla bir eval seti oluşturun. Retrieval için recall@k, precision@k, MRR veya nDCG; generation için kaynak sadakati, cevap doğruluğu, kapsam ve atıf doğruluğu ölçülebilir. Otomatik LLM judge yardımcıdır fakat insan değerlendirmesiyle kalibre edilmelidir.
Sadece cevaba bakmak retrieval hatasını gizler. Hata analizini “belge alınmadı, yanlış sıralandı, bağlam kesildi, model yanlış sentezledi” gibi sınıflara ayırın.
Hayır. RAG çalışma anında dış bilgiyi bağlama getirir; fine-tuning model davranışını veya görev uyumunu örneklerle değiştirir. Güncel bilgi için çoğunlukla RAG, stil ve kalıp için fine-tuning değerlendirilebilir; birlikte de kullanılabilir.
Evet. Küçük veri setinde keyword search, veri tabanı sorgusu veya sağlayıcının yönetilen file search özelliği yeterli olabilir. İhtiyaç olmadan ek altyapı kurmayın.
Sabit evrensel değer yoktur. Az k kritik belgeyi kaçırabilir, fazla k bağlamı kirletir ve maliyeti artırır. Soru tipine göre eval ile seçin veya dinamik retrieval kullanın.
Vektör boyutu ve uzayı değişebilir; eski vektörle yeni sorgu embedding'i karşılaştırılmamalıdır. Sürümlü indeks kurup belgeleri yeniden embed edin ve geçişi test edin.
Sonuç olarak başarılı RAG sistemi; temiz ve yetkili veri, anlamlı chunking, hibrit retrieval, zorunlu metadata filtresi, kaynak sadakati, sürüm yönetimi ve gerçek sorularla eval üzerine kurulur. Vector DB seçimini mimarinin başlangıcı değil, ölçülmüş gereksinimlerin sonucu yapın.
Bu rehber “RAG nedir, embedding ve vector database nasıl çalışır, chunk boyutu nasıl seçilir, pgvector, Qdrant veya yönetilen servis ne zaman kullanılır, hybrid search ve reranker nedir, RAG kalitesi nasıl ölçülür?” sorularını yanıtlar. Amaç demo düzeyindeki belge sohbetini güvenli bir üretim sistemine dönüştürmektir.
RAG nedir ve hangi sorunu çözer?
LLM yalnızca eğitim sırasında öğrendiği örüntülere dayanırsa kurum içi belgeyi, son fiyat listesini veya yeni politikayı bilemez. RAG önce bilgi erişim katmanından ilgili içeriği bulur, sonra modelden bu kanıta dayalı cevap üretmesini ister. Böylece bilgi kaynağı model ağırlıklarından ayrılır; belge güncellenebilir ve cevapta kaynak gösterilebilir.RAG, modeli her konuda daha akıllı yapan sihirli katman değildir. Yanlış belge getirilirse model doğru cevaba ulaşamaz; doğru belge getirilse bile talimat veya sentez hatası olabilir. Retrieval ve generation ayrı ayrı ölçülmelidir.
Embedding ve vector database nedir?
Embedding, metin veya başka içeriği anlam benzerliğini temsil eden sayısal bir vektöre dönüştürür. Soru ve belge parçaları aynı embedding modeliyle vektörleştirilir; cosine, inner product veya L2 gibi uzaklık ölçüleriyle yakın komşular aranır. Aynı kelimeyi içermeyen fakat benzer anlama gelen metinler böyle bulunabilir.Vector database; vektörleri, belge kimliğini ve metadata'yı saklayıp benzerlik araması yapar. Qdrant belgeleri yoğun vektör aramasını HNSW gibi grafik indekslerle hızlandırdığını; pgvector ise PostgreSQL içinde exact ve approximate nearest neighbor aramasını HNSW veya IVFFlat ile desteklediğini açıklar.
RAG mimarisi hangi adımlardan oluşur?
Belge alma ve normalleştirme
PDF, web sayfası, wiki, destek kaydı veya veri tabanı içeriğini alın. Tarama sırasında metin sırası, tablo, başlık, sayfa ve dil bilgisini koruyun. OCR sonucu hatalıysa indekslemeden önce kalite kontrolü yapın. Her belgeye kaynak URL'si, sürüm, tarih, sahip, yetki grubu ve geçerlilik durumu ekleyin.
Chunking ve embedding
Belgeyi anlamsal olarak kullanılabilir parçalara bölün. Parçanın çok küçük olması bağlamı koparır; çok büyük olması ilgisiz bilgiyi taşır ve maliyeti artırır. Başlık hiyerarşisi, paragraf ve tablo sınırlarını koruyan semantik chunking deneyin. Örtüşme, iki parça arasındaki bağlantıyı koruyabilir fakat indeks boyutunu büyütür.
Arama ve yeniden sıralama
Soru embedding'ini üretip en yakın parçaları alın. Metadata filtresiyle kullanıcının yetkisi, dil, ürün, tarih ve belge türünü daraltın. Dense aramayı BM25 gibi kelime tabanlı aramayla birleştiren hybrid search; ürün kodu ve özel isim gibi exact terimlerde yardımcı olur. Reranker, adayları daha pahalı fakat hassas bir modelle yeniden sıralar.
Cevap üretme
Seçilen parçaları kaynak kimlikleriyle modele verin. “Yalnızca sağlanan kanıta dayan, bilgi yoksa belirt, her iddiayı kaynakla eşleştir” kuralı kullanın. Cevap sonrası kaynak bağlantılarını gerçek belgeye bağlayın; modelin URL uydurmasına izin vermeyin.
Chunk boyutu nasıl seçilir?
Tek doğru sayı yoktur. Soru türü, belge yapısı, embedding modeli ve bağlam penceresi belirleyicidir. SSS maddesi doğal olarak kısa; sözleşme hükmü veya teknik prosedür daha uzun bağlam isteyebilir. Token sayısını hedeflemek yerine anlam bütünlüğünü koruyun ve farklı boyutları eval setiyle karşılaştırın.Parent-child yaklaşımında küçük parçayla arama yapılır, cevap için daha geniş üst bölüm getirilir. Cümle penceresi tek eşleşmenin çevresindeki komşu cümleleri ekler. Chunking kararı yalnızca depolama ayarı değil, bilgi mimarisi seçimidir.
Vector DB nasıl seçilir?
Veri hacmi, güncelleme sıklığı, gecikme, filtre karmaşıklığı, çoklu kiracı, yedekleme, bölge ve ekip deneyimini değerlendirin. PostgreSQL zaten merkezdeyse ve ölçek uygunsa pgvector operasyonel sadelik sağlar. Özel vector engine'ler yüksek ölçek, filtre ve dağıtık arama özellikleri sunabilir. Yönetilen servis operasyon yükünü azaltır; veri yerleşimi ve maliyet koşulları incelenmelidir.- pgvector: İlişkisel veri ve vektörü aynı PostgreSQL işlemlerinde tutma avantajı.
[/*] - Qdrant: HNSW tabanlı arama, payload filtreleri ve hybrid yaklaşımlar.
[/*] - Yönetilen servis: Bakım, ölçekleme ve yüksek erişilebilirlik kolaylığı; bağımlılık ve maliyet analizi gerekir.
[/*]
Önce exact arama ile kalite tabanı ölçün. Approximate indeks eklediğinizde hız kazanırken recall düşebilir. pgvector belgeleri HNSW'nin daha iyi hız–recall dengesi fakat daha yüksek bellek ve kurulum maliyeti; IVFFlat'in daha hızlı build fakat daha düşük sorgu performansı sunabildiğini belirtir.
Metadata filtreleri neden önemlidir?
Embedding; departman yetkisi, ürün stok durumu, ülke veya geçerlilik tarihi gibi iş kurallarını güvenilir biçimde temsil etmez. Bu alanları metadata olarak saklayıp arama öncesi veya arama içinde filtreleyin. Qdrant belgeleri payload filtrelerinin AND, OR ve NOT koşullarıyla birleştirilebildiğini ve sık filtrelenen alanlar için indeks önerildiğini açıklar.Yetki filtresi promptta değil, sorgu katmanında uygulanmalıdır. Modelin “bu belgeyi gösterme” talimatına uymasına güvenmek veri sızıntısına yol açar. Her chunk miras aldığı belge ve kiracı kimliğiyle saklanmalıdır.
Hybrid search ne zaman gerekir?
Dense arama anlam benzerliğinde güçlüdür; fakat SKU, hata kodu, sözleşme madde numarası ve kişi adı gibi nadir tam eşleşmeleri kaçırabilir. Sparse/BM25 arama kelime eşleşmesini korur. İki sonuç listesini reciprocal rank fusion veya öğrenilmiş yöntemle birleştirmek kapsamı artırabilir.Qdrant'ın metin arama belgeleri semantic ve lexical aramanın tamamlayıcı olduğunu belirtir. Hibrit sistem yine eval gerektirir; zayıf ağırlıklandırma alakasız fakat anahtar kelime dolu belgeleri üste taşıyabilir.
RAG'de güncellik ve sürüm yönetimi nasıl yapılır?
Kaynak sistemde değişiklik olduğunda yalnızca etkilenen chunk'ları yeniden üretin. İçerik hash'i ile değişmeyen bölümü atlayın. Silinen belgenin vektörünü de silin; tombstone ve senkronizasyon hatalarını izleyin. Embedding modeli değişirse eski ve yeni vektör boyutları uyumsuz olabilir; sürümlü koleksiyon ve kontrollü yeniden indeksleme kullanın.Her cevabın hangi belge sürümüne dayandığını loglayın. Eski politika ve yeni politika aynı anda aktif görünmemelidir. Geçerlilik tarihini filtreye dahil edin. RAG'in güncel kalması sürekli veri hattı sorunudur.
RAG güvenliği nasıl sağlanır?
Belge içindeki prompt injection talimatlarını güvenilmeyen içerik olarak ele alın. Kaynak metin “sistem talimatını yok say” dese bile uygulanmamalıdır. Dosya yüklemede tür, boyut, zararlı içerik ve erişim kontrolü yapın. PII ve sırları indekslemeden önce sınıflandırın; gerekirse maskeleyin.API anahtarlarını belgeye veya prompta koymayın. Kullanıcı girişini loglarken kişisel veriyi azaltın. Çoklu kiracıda collection ayrımı veya zorunlu tenant filtresi kullanın; filtre eksikliği için otomatik test yazın. Cevapta uzun kaynak pasajını izinsiz kopyalamak telif ve veri sızıntısı riski doğurabilir.
RAG kalitesi nasıl ölçülür?
Gerçek kullanıcı sorularından, doğru kaynak ve beklenen cevapla bir eval seti oluşturun. Retrieval için recall@k, precision@k, MRR veya nDCG; generation için kaynak sadakati, cevap doğruluğu, kapsam ve atıf doğruluğu ölçülebilir. Otomatik LLM judge yardımcıdır fakat insan değerlendirmesiyle kalibre edilmelidir.- Soruya gerekli chunk ilk k içinde geliyor mu?
[/*] - Yetkisiz veya eski belge hiç geliyor mu?
[/*] - Cevaptaki her iddia sağlanan bağlamda var mı?
[/*] - Kaynak bağlantısı doğru belge ve bölüme gidiyor mu?
[/*] - Bilgi yokken sistem güvenle “bulamadım” diyebiliyor mu?
[/*] - Gecikme ve başarılı cevap başına maliyet kabul edilebilir mi?
[/*]
Sadece cevaba bakmak retrieval hatasını gizler. Hata analizini “belge alınmadı, yanlış sıralandı, bağlam kesildi, model yanlış sentezledi” gibi sınıflara ayırın.
Yaygın RAG hataları nelerdir?
- Her PDF'yi kalite ve yetki kontrolü olmadan indekslemek.
[/*] - Sabit tek chunk boyutunu bütün belge türlerine uygulamak.
[/*] - Yalnızca vector search kullanıp exact terimleri kaçırmak.
[/*] - Metadata ve tenant filtresini modele bırakmak.
[/*] - Top-k değerini yükselterek her sorunu çözmeye çalışmak.
[/*] - Eski belgeyi silmeden yeniden indekslemek.
[/*] - Kaynak göstermeyi modele serbest URL üretimiyle yaptırmak.
[/*] - Model veya embedding değişiminde eval çalıştırmamak.
[/*]
RAG uygulaması kontrol listesi
- Kaynak sahipliği, sürümü ve güncelleme sıklığı tanımlı mı?
[/*] - Parser, OCR ve tablo kalitesi test edildi mi?
[/*] - Chunking belge yapısına göre mi?
[/*] - Dense, lexical ve hybrid seçenekleri eval edildi mi?
[/*] - Yetki filtresi sorgu katmanında zorunlu mu?
[/*] - Atıf gerçek kaynak kimliğinden mi oluşturuluyor?
[/*] - Silme ve embedding migrasyonu planlı mı?
[/*] - Retrieval ve generation ayrı ayrı ölçülüyor mu?
[/*] - Gecikme, token ve indeks maliyeti izleniyor mu?
[/*]
Sık sorulan sorular
RAG ile fine-tuning aynı şey mi?
Hayır. RAG çalışma anında dış bilgiyi bağlama getirir; fine-tuning model davranışını veya görev uyumunu örneklerle değiştirir. Güncel bilgi için çoğunlukla RAG, stil ve kalıp için fine-tuning değerlendirilebilir; birlikte de kullanılabilir.
Vector database olmadan RAG yapılabilir mi?
Evet. Küçük veri setinde keyword search, veri tabanı sorgusu veya sağlayıcının yönetilen file search özelliği yeterli olabilir. İhtiyaç olmadan ek altyapı kurmayın.
Top-k kaç olmalıdır?
Sabit evrensel değer yoktur. Az k kritik belgeyi kaçırabilir, fazla k bağlamı kirletir ve maliyeti artırır. Soru tipine göre eval ile seçin veya dinamik retrieval kullanın.
Embedding modeli değişirse ne olur?
Vektör boyutu ve uzayı değişebilir; eski vektörle yeni sorgu embedding'i karşılaştırılmamalıdır. Sürümlü indeks kurup belgeleri yeniden embed edin ve geçişi test edin.
Resmî kaynaklar
- OpenAI: Retrieval rehberi
[/*] - OpenAI: Embeddings rehberi
[/*] - Qdrant: Vector search nasıl çalışır?
[/*] - Qdrant: Metadata filtreleme
[/*] - Qdrant: Semantic ve lexical arama
[/*] - pgvector: Resmî proje belgeleri
[/*]
Sonuç olarak başarılı RAG sistemi; temiz ve yetkili veri, anlamlı chunking, hibrit retrieval, zorunlu metadata filtresi, kaynak sadakati, sürüm yönetimi ve gerçek sorularla eval üzerine kurulur. Vector DB seçimini mimarinin başlangıcı değil, ölçülmüş gereksinimlerin sonucu yapın.