RAG NEDİR VE UYGULAMA
RAG'i "vektör veritabanına soru atıp en yakın chunk'ı LLM'e veren bir boru hattı" sanmak, pek çok ekibin ilk pilotta tökezlemesinin baş nedeni. Gerçek RAG; metni nasıl parçaladığınız, hangi arama stratejisini seçtiğiniz, sonuçları nasıl yeniden sıraladığınız ve cevap kalitesini neye göre ölçtüğünüzle var olur. Tek başına bir cosine similarity sorgusu RAG değildir; olsa olsa onun en görünür adımıdır.
RAG Hakkındaki En Yaygın Yanılgı
Retrieval-Augmented Generation, adı üstünde iki parçalı: önce retrieval (getirme), sonra generation (üretim). Çoğu tanıtım sunumu sadece "embedding üret, vector DB'ye yaz, sorgula, prompt'a yapıştır" akışını gösterir. Bu, oyuncak demolar için yeter ama üretimde kırılır. Sebep basit: gerçek dokümanlar dağınıktır, sorular bulanıktır, kullanıcılar tek bir doğru cevap bekler.
RAG'i bir mimari olarak düşünmek gerek — birbirine bağlı dört halka var: chunking, hybrid search, reranking ve evaluation. Bir halkayı zayıf bırakırsanız diğer üçü de hissetmeden çalışır görünür ama cevaplar yavaş yavaş güvenilirliğini yitirir. Pratik detaylar için ayrıntılı belgeleri incelenebilir.
Chunking: Cevabın Şekli Burada Belirlenir
Bir PDF'i 500 token'lık bloklara böldüğünüzde aslında "modelin görebileceği en büyük gerçeklik birimi" budur diyorsunuz. Yanlış kesilmiş bir chunk, doğru sorulmuş bir soruyu bile karşılıksız bırakır. Cümle ortasından bölünen bir tanım, tablo başlığından kopmuş bir satır, alt başlığı kaybetmiş bir paragraf — hepsi sessiz hata kaynağı.
- Sabit boyutlu chunking: Hızlı kurulur, semantik bütünlüğü bozar.
- Recursive chunking: Paragraf, cümle, kelime sınırlarına saygı duyar; ilk tercih budur.
- Semantic chunking: Embedding benzerliğine göre böler; uzun teknik dokümanlarda işe yarar.
- Document-aware: Markdown başlıklarını, kod bloklarını, tablo yapısını tanıyıp koruyarak böler.
- Overlap: Komşu chunk'lar arasında 10-20% örtüşme, bağlam kaybını ciddi biçimde azaltır.
Chunk boyutu için sihirli bir sayı yok. Hukuki metinlerde 1000-1500 token mantıklıyken, FAQ tarzı içerikte 200-300 token daha isabetlidir. Buradaki seçim, ileride evaluation aşamasında geri dönüp ayarlamak zorunda kalacağınız ilk parametredir.
Vector Search Tek Başına Neden Yetmez
Embedding'ler anlamsal yakınlığı yakalar ama tam terim eşleşmesini sıklıkla ıskalar. Kullanıcı "ISO 27001 Annex A.8.24" diye sorduğunda, semantik arama benzer ama yanlış bir kontrol maddesi getirebilir. Çünkü embedding modeli "27001" ile "27002"yi yakın yorumlar; oysa kullanıcı için bu fark her şeydir.
Çözüm hybrid search: dense (vector) ve sparse (BM25 gibi kelime tabanlı) aramaları birlikte koşturup sonuçları birleştirmek. Reciprocal Rank Fusion (RRF) en yaygın birleştirme yöntemidir; her iki listeden gelen sıralamayı tek bir skorda toplar. Pratikte hybrid search, sadece vector search'e göre top-k recall'unu %15-30 bandında iyileştirir — bu da reranker'a daha temiz aday seti sunmak demektir.
Reranking: Doğru Belgeyi Üste Çıkarmak
Retriever genelde top-20 ya da top-50 aday döndürür. LLM'in context window'una hepsini tıkamak hem maliyet hem gürültü demektir. İşte burada cross-encoder reranker devreye girer: her aday belgeyi sorgu ile birlikte tek tek modele verir ve bir alaka skoru hesaplar. Bi-encoder'a göre çok daha pahalıdır ama sadece 20-50 aday üzerinde çalıştığı için tolere edilebilir.
Cohere Rerank, BGE Reranker veya Jina Reranker gibi modeller bu işin yaygın araçlarıdır. Tek bir reranker eklemek, çoğu zaman tüm chunking stratejisini değiştirmekten daha hızlı kazanç getirir. Cevap kalitesini doğrudan etkileyen üretim adımına geçmeden önce sıralamayı düzeltmek, halüsinasyonun en büyük tetikleyicisini söndürür.
Evaluation Döngüsü: Tahmin Etmeyi Bırakmak
RAG'in en sessiz hatası, "iyi çalışıyor gibi görünüyor" tuzağıdır. Sayısal ölçüm olmadan hiçbir iyileştirme kanıtlanamaz. Üç boyutta ölçmek gerek:
- Retrieval kalitesi: Context Precision, Context Recall, MRR, NDCG.
- Generation kalitesi: Faithfulness (cevap getirilen bağlama mı dayanıyor), Answer Relevance.
- Uçtan uca: Gold-standard soru-cevap seti üzerinden insan veya LLM-as-judge değerlendirmesi.
Ragas, TruLens, DeepEval gibi kütüphaneler bu metrikleri otomatikleştirir. 50-100 soruluk küçük bir altın küme bile, parametre değişikliklerinin etkisini görmek için yeterlidir. Konunun temellerini ve uygulama örneklerini derinlemesine çalışmak isteyenler için Generative AI ve LLM eğitimi programındaki RAG modüllerinden yararlanabilirsiniz.
Üretime Geçerken Sık Atlanan Detaylar
- Metadata filtreleme: Tarih, kaynak, doküman tipi gibi alanlarla aramayı daraltmak hem hızı hem isabeti artırır.
- Query rewriting: Kullanıcının ham sorusunu retrieval için yeniden yazmak, özellikle çok turlu sohbetlerde kritik.
- Citation zorunluluğu: LLM'e cevabını hangi chunk'tan ürettiğini belirtmesini söylemek, halüsinasyonu görünür kılar.
- Maliyet izleme: Embedding, rerank ve generation çağrılarının token başı maliyetlerini ayrı ayrı loglamak şarttır.
- Cache katmanı: Sık sorulan sorular için cevap önbelleği, gecikmeyi yarıya indirir.
Bir RAG sistemi kurmak, tek seferlik bir entegrasyon işi değildir; chunking parametresini değiştirip evaluation skorunu izlemek, reranker modelini güncelleyip latency'i ölçmek, query rewriting prompt'unu iyileştirip recall'a bakmak gibi sürekli bir döngü ister. LLM altyapısının daha geniş resmini görmek için LLM tabanlı uygulama geliştirme kaynaklarını inceleyebilirsiniz.
Özetle: RAG'in zor kısmı vector DB seçimi değil, dokümanlarınızın gerçek dünyadaki dağınıklığıyla başa çıkmaktır. Chunking'i, hybrid search'ü, reranking'i ve evaluation'ı bir bütün olarak ele alan ekipler, "demo'da çalışıyordu, üretimde tutmadı" cümlesini kurmak zorunda kalmaz.
