Bilgi modelde değil, kaynakta
Belgeyi güncellediğinizde yanıt da güncellenir; modeli yeniden eğitmeye gerek yoktur. Bu, RAG'i güncel ve denetlenebilir kılar.
Bir dil modeli yalnızca eğitildiği veriyi bilir; şirketinizin dokümanlarını, ürün kataloğunu ya da dünkü destek kayıtlarını bilmez. RAG (retrieval-augmented generation) bu boşluğu, modeli yeniden eğitmeden kapatır: soruyla ilgili belgeleri bir arama katmanından çekip modelin context'ine ekler, model de yanıtını bu kaynağa dayanarak üretir. Bu aramanın kalbinde vektör veritabanları durur: metni anlamını temsil eden vektörlere (embedding) çevirip, bir sorguya anlamca en yakın parçaları hızla bulurlar. Bu sayfada RAG'in neden gerektiğini, belgeleri parçalara bölmeyi (chunking) ve embedding'lemeyi, vektör index'lerinin (ANN, HNSW) nasıl hızlı arama yaptığını, retrieval ile hybrid search'ü, reranking ve context birleştirmeyi ve son olarak bir RAG hattını nasıl değerlendireceğinizi birlikte ele alıyoruz.
Bir LLM'in iki temel sınırı vardır: eğitim verisinin bittiği tarihten (knowledge cutoff) sonrasını bilmez ve zaten hiç görmediği özel verilerinize (iç dokümanlar, müşteri kayıtları) erişemez. Bu boşlukta model ya "bilmiyorum" der ya da daha kötüsü, makul görünen bir şey uydurur (hallucination). RAG bu sorunu, bilgiyi modelin ağırlıklarına gömmek yerine çalışma anında sağlayarak çözer: soru geldiğinde ilgili belgeleri arar, bulduklarını prompt'a ekler ve modelden "yalnızca bu bağlama dayanarak" yanıt vermesini ister. Böylece bilgi denetlediğiniz kaynakta kalır — güncellemek için yeniden eğitim gerekmez, yanıt kaynak gösterebilir ve modelin uydurma alanı daralır.
# 1) soru embedding'e çevrilir
soru: "İade politikası kaç gün?" → [0.11, -0.4, …]
# 2) vektör DB en yakın chunk'ları döner (retrieve)
chunk#42 "İadeler 14 gün içinde…" skor 0.89
chunk#7 "Kargo süreci…" skor 0.61
# 3) chunk'lar prompt'a eklenir (augment)
# 4) model yalnızca bu bağlamdan yanıtlar (generate)
yanıt "İade süresi 14 gündür." (+ kaynak: chunk#42)
Belgeyi güncellediğinizde yanıt da güncellenir; modeli yeniden eğitmeye gerek yoktur. Bu, RAG'i güncel ve denetlenebilir kılar.
Yanıt hangi chunk'lardan geldiğini işaret edebildiği için, kullanıcı doğrulayabilir; kurumsal senaryolarda bu güvenin şartıdır.
RAG'in kalitesi retrieval'ın kalitesidir. Yanlış ya da eksik chunk gelirse, en güçlü model bile doğru yanıt üretemez.
Bir belgeyi olduğu gibi aramak işe yaramaz; onu önce anlamlı parçalara, chunk'lara bölersiniz. Her chunk daha sonra bir embedding modeliyle vektöre çevrilir ve vektör veritabanına, çoğunlukla kaynak/başlık gibi metadata'sıyla birlikte yazılır. Bu hazırlık aşamasına indexing denir ve RAG kalitesinin çoğu burada belirlenir. Kritik karar chunk boyutudur: çok büyük chunk'lar alakasız metni de taşıyıp aramayı bulanıklaştırır ve context'i şişirir; çok küçük chunk'lar ise bağlamı koparıp anlamı bölebilir. Yaygın pratik, orta boy chunk'lar ile aralarında hafif overlap (örtüşme) bırakmak ve mümkünse doğal sınırlardan (paragraf, başlık) bölmektir.
# belge overlap'li chunk'lara bölünür
[chunk 1]───────
└──[chunk 2]─────── # örtüşme bağlamı korur
└──[chunk 3]───────
# her chunk embedding + metadata ile saklanır
chunk#42 vektör[…] { kaynak: "iade.md", başlık: "İade" }
Büyük chunk bağlamı korur ama gürültü ve maliyet ekler; küçük chunk keskin eşleşir ama bağlamı kaybedebilir. Veri türünüze göre ayarlanır.
Belgeleri ve sorguyu aynı modelle embedding'lemelisiniz; farklı model farklı uzay demektir, benzerlik anlamsızlaşır.
Kaynak, tarih, erişim izni gibi metadata, hem filtreleme hem kaynak gösterimi için taşınır. İzin denetimi çoğu zaman burada başlar.
Bir sorgu vektörüne en yakın chunk'ları bulmak, teoride tüm vektörlerle tek tek karşılaştırma (brute-force) gerektirir — milyonlarca chunk'ta bu çok yavaştır. Vektör veritabanları bu yüzden ANN (approximate nearest neighbor) index'leri kullanır: kesin en yakını garanti etmek yerine, çok daha hızlı biçimde "yeterince yakın" komşuları bulurlar. En yaygın yapı HNSW'dir (hierarchical navigable small world); vektörleri katmanlı bir graf olarak bağlar ve aramayı üstten aşağı hızlı bir gezinmeye çevirir. Yakınlık ise bir benzerlik ölçüsüyle hesaplanır — çoğunlukla cosine similarity. Buradaki takas nettir: biraz doğruluktan feragat edip büyük bir hız kazanırsınız.
# brute-force: kesin ama O(n), milyonlarda yavaş
her vektörle karşılaştır → en yakın k
# HNSW: katmanlı graf, hızlı gezinme
üst katman ● ───── ● ─────── ● # seyrek, uzun atlar
│ │
alt katman ●─●─●─●─●─●─●─●─●─● # yoğun, ince ayar
▼
yaklaşık en yakın k komşu
Vektör araması güçlüdür ama her derde deva değildir. Semantik arama (vektör) anlamı yakalar: "araç kirası" sorgusu "oto kiralama" belgesini bulur. Ama tam eşleşme gereken durumlarda — bir ürün kodu, bir hata numarası, nadir bir özel ad — anlam benzerliği yanıltabilir. Burada klasik anahtar kelime araması (lexical, ör. BM25) daha isabetlidir. Hybrid search ikisini birleştirir: hem semantik hem lexical skorları hesaplayıp harmanlar, böylece hem "anlamca yakın" hem "birebir geçen" sonuçları yakalar. Buna bir de metadata filtresi (tarih, dil, erişim izni) eklenince, retrieval hem alakalı hem yetkili sonuçlar döndürür.
Vektör benzerliğiyle eş anlamlıları ve yakın kavramları bulur. Kelimeler farklı olsa da niyeti eşleştirir; doğal dil sorgularında güçlüdür.
Anahtar kelime araması (BM25) tam terimleri yakalar. Ürün kodu, hata numarası, özel ad gibi kesinlik gereken sorgularda semantikten üstündür.
Semantik ve lexical skorları birleştirir; her iki dünyanın gücünü alır. Üretim RAG hatlarında giderek varsayılan yaklaşım budur.
Retrieval genellikle hızlı ama kaba bir ilk elemedir: aday olarak birçok chunk döner. Reranking, bu adayları daha güçlü (ama daha yavaş) bir modelle yeniden puanlayıp gerçekten en alakalı birkaçını öne çıkarır — önce genişçe topla, sonra dikkatle ele. Kalan chunk'lar sonra bir context haline getirilip prompt'a yerleştirilir. Burada iki sınır vardır: modelin context window'u ve maliyet. Ne kadar çok chunk koyarsanız yanıt o kadar zenginleşebilir ama gürültü, gecikme ve fatura da artar; ayrıca modeller uzun bağlamın ortasındaki bilgiyi gözden kaçırabilir ("lost in the middle"). Bu yüzden az sayıda, gerçekten alakalı ve iyi sıralanmış chunk, çok sayıda vasat chunk'tan daima iyidir.
# retrieval: hızlı, geniş (ör. top-20)
aday: chunk#42, #7, #91, #13, … (20 aday)
# rerank: güçlü model yeniden puanlar
chunk#42 0.94 ← context'e
chunk#13 0.88 ← context'e
chunk#91 0.42 ✕ elendi
chunk#7 0.31 ✕ elendi
# az ama alakalı chunk → temiz context → iyi yanıt
İlk retrieval hızı için kaba tutulur; rerank pahalı ama isabetli bir ikinci süzgeçtir. En alakalı chunk'ın gerçekten üste çıkmasını sağlar.
Context'i doldurmak cazip ama ters teper: gürültü modeli şaşırtır, maliyet ve gecikme artar. Az ve öz her zaman kazanır.
Uzun context'te modeller baş ve sona daha çok dikkat eder. En kritik chunk'ları öne ya da sona koymak isabeti artırabilir.
RAG'de iki ayrı şey bozulabilir, bu yüzden ikisini ayrı ayrı ölçün. Birincisi retrieval kalitesi: doğru chunk gerçekten geliyor mu? (recall, isabet). İkincisi üretim kalitesi: model gelen bağlama sadık ve doğru yanıt veriyor mu, yoksa bağlamı görmezden gelip uyduruyor mu (faithfulness)? Bir yanıt yanlışsa, hatanın retrieval'da mı yoksa üretimde mi olduğunu ayırmadan düzeltemezsiniz. En sık tuzaklar da bellidir: bayatlamış index (belge güncellendi ama yeniden embedding'lenmedi), kötü chunk sınırları, izin sızıntısı (kullanıcının görmemesi gereken chunk'ın context'e girmesi) ve context'i gereksiz şişirip maliyeti patlatmak.
"Doğru chunk geldi mi?" ile "model doğru mu yanıtladı?" farklı sorulardır. İkisini ayrı ölçmeden kök nedeni bulamazsınız.
Kaynak belge değiştiğinde ilgili chunk yeniden embedding'lenmeli. Aksi halde RAG, güncel görünüp eski bilgiyi kaynak gösterir.
Retrieval, kullanıcının yetkisi olmayan bir chunk'ı context'e koyarsa veri sızar. İzin filtresi retrieval anında uygulanmalı, sonrasında değil.
RAG bilgiyi çalışma anında context'e ekler; güncellemesi kolaydır ve kaynak gösterir — bir bilgi sorununu çözer. Fine-tuning modelin ağırlıklarını eğitir; üslup ve davranışı kalıcı kılar — bir davranış sorununu çözer. Güncel/doğru bilgi istiyorsanız RAG; tutarlı biçim/üslup istiyorsanız fine-tuning. İkisi birlikte de kullanılabilir.
Semantik arama embedding benzerliğiyle anlamı yakalar; farklı kelimelerle aynı kavramı bulur. Anahtar kelime araması (lexical/BM25) tam terimi yakalar; kod, numara, özel ad gibi kesinlik gerektiren sorgularda üstündür. Modern RAG çoğu zaman ikisini hybrid search'te birleştirir.
Klasik veritabanı tam eşleşme ve yapısal sorgular (WHERE, JOIN) için optimizedir. Vektör veritabanı ise "en benzer"i bulmak için ANN index tutar. İkisi rakip değildir; birçok kurulum, pgvector gibi uzantılarla klasik veritabanına vektör aramayı ekler ve tek yerde birleştirir.
Retrieval geniş bir aday kümesini hızlıca getiren ilk elemedir. Reranking ise bu adayları daha güçlü bir modelle yeniden puanlayıp en alakalı birkaçını seçen ikinci süzgeçtir. Biri kapsam (recall), diğeri isabet (precision) için çalışır; ardışık kullanılırlar.
Belge kaynağın tamamıdır (bir PDF, bir sayfa). Chunk ise o belgenin aranabilir hale gelmesi için bölündüğü parçadır. Retrieval belgeyi değil chunk'ı döner; bu yüzden chunk sınırlarının kalitesi, RAG'in bulma isabetini doğrudan belirler.
RAG'i ve vektör aramanın temel algoritmalarını tanımlayan makaleler ile açık kaynak referansları.
Chunking stratejisinden vektör veritabanı seçimine, hybrid search ve değerlendirmeye kadar; kendi verinizle güvenilir bir RAG sistemi kurmak için bize yazabilirsiniz. Temeller için LLM & Üretken AI rehberimize de göz atabilirsiniz.