RAG denince çoğu insanın aklına direkt büyük dil modeli geliyor. GPT-4, Claude, Gemini… Hani şu her yerde adı geçen yıldız oyuncular. Ama açık konuşayım — bir RAG sistemi kurup biraz gerçek veriyle boğuşunca, insanın kafasında taşlar bambaşka türlü yerine oturuyor. Asıl iş çoğu zaman modelde değil; hangi parçayı bulduğunuzda gizli.
Ben de ilk kez kurumsal dokümanlarla çalışan bir RAG akışını test ettiğimde bunu bayağı net gördüm. 2024’ün sonlarında, İstanbul’da küçük bir ürün ekibi için hazırladığımız iç destek botunda, model cevap veriyor diye seviniyorduk — sabahtan akşama kadar terminal ekranına baktık, çıktılar makul görünüyordu, herkes mutluydu. Sonra kullanıcı “dijital ürün iadesi olur mu?” diye sorunca sistem fiziksel ürün iade maddesini çekti, üstüne de gayet özgüvenli bir yanıt döktü. İşte o an net anladık: LLM tökezlememişti. Retrieval katmanı tökezlemişti.
Dur aslında, önce şunu söyleyeyim. Bu yazı “RAG nasıl kurulur?” rehberi değil. Daha çok “neden bazı RAG sistemleri kağıt üstünde iyi görünüp pratikte tuhaf davranır?” sorusuna odaklanıyor. Çünkü mesele yalnızca vektör veritabanı kurmak değil; doğru parçayı, doğru anda, doğru kullanıcı için yüzeye çıkarmak.
Herkes aynı dört adımı kopyalıyor
Çoğu eğitimde hikâye hep aynı yerden başlıyor: dokümanı al, parçalara böl, embed et, en yakın benzerleri getir, sonra LLM’e ver. Temiz görünüyor. Hatta biraz fazla temiz, hani LEGO seti gibi — kutudan çıkan parçalarla aynı evi kuruyorsunuz sanıyorsunuz ama köşe taşları hiç eşleşmiyor.
Hmm, bunu nasıl anlatsamdı…
Şema kabaca şöyle ilerliyor:
Ingest → Chunk → Embed → Retrieve → GenerateDürüst olmak gerekirse, Bu akışın kötü olduğunu söylemiyorum. Tam tersine, başlangıç için gayet iş görüyor (ciddiyim). Geçen yıl Ankara’daki bir fintech ekibinde buna benzer bir yapı test ettim; şirket politikaları için soru-cevap botu yapmıştık. Ilk demo herkesi mutlu etmişti — citation’lar vardı, yanıtlar düzgün görünüyordu, müdür de beğenmişti. Ta ki kullanıcılar köşeli sorular sormaya başlayana kadar. Sonra bozuldu.
İşin can sıkıcı kısmı şu. Retrieval katmanı biraz zayıfsa, en parlak model bile yanlış malzemeyi cilalıyor sadece. Sorun cevabın dili değil; cevaba giden yolun kendisi oluyor.
Neden retrieval aslında gerçek model?
Bunu ilk duyduğumda biraz iddialı gelmişti. Hani model ortada dururken neden asıl kahraman retrieval olsun? Ama birkaç farklı proje üst üste gelince fikrim değişti — hem de hızlı değişti. Retrieval katmanı; chunk stratejisi, embedding kalitesi, keyword eşleşmesi ve yeniden sıralama gibi detaylarla boğuşuyor. Görünmez işler bunlar, ama sonuç üzerindeki etkisi ağır.
Aşağıdaki tablo meseleyi gayet sade anlatıyor:
| İnsanların Önemsediği Şey | Gerçekte Belirleyici Olan |
|---|---|
| Hangi LLM kullanıldı? | Doküman nasıl bölündü? |
| Sistem prompt’u ne kadar iyi? | Embedding kalitesi nasıl? |
| Cevap güzel mi yazıldı? | Doğru bağlam bulundu mu? |
| Liderlik demosu beğendi mi? | Yanlış chunk geri geldi mi? |
Tabi burada küçük startup ile enterprise arasındaki fark da önemli bir yerde duruyor. Küçük ekiplerde genelde hızlı çözüm baskısı var; “bir şey çalışsın yeter” deniyor, chunk boyutu neredeyse rastgele seçiliyor, kimse itiraz etmiyor çünkü demo çalışıyor. Kurumsal tarafta ise olay çok daha sert: politika metinleri uzun, versiyonlu ve birbirine geçmiş durumda oluyor — özellikle hukuk ve uyum ekiplerinde bu kaos had safhaya çıkıyor. Orada retrieval hatası direkt güven kaybına dönüşüyor.
Kırılma noktası nerede başlıyor?
Kırılma genelde kullanıcı sorusu dokümanda birebir geçmediğinde başlıyor. Mesela “download sonrası iade yok” cümlesini arayan biri için semantik arama anlamı yakalayabilir. Exact phrase’i kaçırabilir. Ya da tam tersi; keyword arama ifadeyi bulur ama bağlamı anlayamaz. İkisi de yeterince sinir bozucu.
Bakın, Ben bunu Eylül 2024’te İzmir’de tek başıma yürüttüğüm bir PoC’de bizzat yaşadım. Teknik dökümanlarda “non-refundable after download” ifadesi açıkça geçiyordu ama sistem sürekli genel iade politikasını getiriyordu. Kullanıcı açısından bu resmen saçmalık gibi görünüyordu —. Doğru cümle iki paragraf ötede duruyordu, orada bekliyordu, kimse almıyordu.
Sadece vektör yetmiyor: Hybrid search neden işe yarıyor?
Lafı gevelemeden söyleyeyim. Semantic search tek başına çoğu zaman eksik kalıyor. BM25 gibi keyword tabanlı yöntemler de tek başına kuru kaçabiliyor. Hybrid search ise ikisini birlikte kullanıp daha dengeli, daha güvenilir sonuç veriyor — bir nevi hem sezgi hem kelime avcılığı yapıyorsunuz aynı anda.
Durun, bir saniye.
İşin garibi, Aşağıdaki örnek kod tam prod’a hazır sayılmaz ama mantığı gayet iyi gösteriyor:
from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
from rank_bm25 import BM25Okapi
docs = [
"Refund within 30 days, physical items only.",
"Digital products: non-refundable after download.",
"Contact support for defective digital items."
]
model = SentenceTransformer("all-MiniLM-L6-v2")
embeddings = model.encode(docs)
index = faiss.IndexFlatL2(embeddings.shape[1])
index.add(np.array(embeddings, dtype="float32"))
tokenized_docs = [doc.lower().split() for doc in docs]
bm25 = BM25Okapi(tokenized_docs)Kodun güzelliği basitliğinde yatıyor — ama asıl dert birleşimde çıkıyor (ben de ilk duyduğumda şaşırmıştım) (ilk duyduğumda inanamadım). Semantic skor ile keyword skorunu nasıl tartacaksınız? Alpha değeri burada hayati hale geliyor. Doğrusu sabit bir sayı her veri setinde aynı sonucu vermiyor, ben de bunu deneme yanılmayla öğrendim.
- Daha kısa dokümanlarda keyword ağırlığı işe yarayabiliyor.
- Daha uzun ve dağınık içerikte semantik skor öne çıkabiliyor.
- Düzenleme gerektiren kurumsal metinlerde yeniden sıralama ayrı önem kazanıyor.
Peki re-ranking niye önemli?
Çünkü ilk gelen sonuç neredeyse her zaman en iyisi olmuyor. Arama motoru mantığıyla düşünün; size rafın önünden kitap getiriyor ama doğru kitap bazen arkada sıkışmış kalmış oluyor (ki bu çoğu kişinin gözünden kaçıyor). Re-ranking katmanı bu yüzden iyi bir sigorta gibi çalışıyor — fazladan maliyet ama fazladan güvence.
Retrieval kötü ise LLM sadece güzel konuşan bir yanlış makineye dönüşür.
Bende neyi değiştirdi? Üç pratik ders
Birkaç projeden sonra şunu net öğrendim: chunk boyutunu körlemesine ayarlamak ciddi risk. Çok büyük chunk alınca alakasız bilgi karışıyor; çok küçük chunk alınca bağlam paramparça dağılıyor. Her iki uç da tatsız, her ikisi de kullanıcıyı şikâyetçi bırakıyor.
Şöyle ki, İkinci ders şu oldu — metadata’nın değerini hafife almışım meğer. Dosya türü, tarih, bölüm adı, hatta belge versiyonu bile retrieval sonucunu toparlayabiliyor. Mesela destek dökümanları ile politika dökümanları birbirine benzemeye başladığında, bu ufak ayrımlar kelimenin tam anlamıyla hayat kurtarıyor. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Üçüncü ders biraz can sıkıcıydı açıkçası. İyi embedding modeli almak yetmiyor; kendi verinizde test etmeden karar vermek kumar gibi bir şey. Mart 2025’te Kadıköy’de yaptığımız küçük bir benchmark’ta ucuz sayılan model bazı sorularda pahalı olanı geçti (ben de ilk duyduğumda şaşırmıştım). Evet. Beklediğim kadar değildi. Daha fazla bilgi için Claude Code Ayarları Makinenizle Birlikte Kaybolmasın yazımıza bakabilirsiniz.
Şimdi gelelim işin can alıcı noktasına.
Küçük startup vs enterprise senaryosu
Küçük startup tarafında hedef genelde hız. Bir hafta içinde çalışan demo çıkarırsınız, müşteri ilgilenmeye başlar, yapılacaklar listesi masaya oturur. Orada hybrid search artı basit re-ranking çoğu zaman yeterli oluyor — fazlasını kurmak için ne zaman ne bütçe var. Daha fazla bilgi için Manticore Search’ü Grafana ile Tek Komutla İzle yazımıza bakabilirsiniz.
Enterprise tarafında konu tamamen farklıdır. Güvenlik, denetlenebilirlik. Sürüm takibi devreye girer — hangi belge hangi tarihte indekslendi, hangi sürümden cevap geldi, kullanıcıya yanlış bilgi verilirse kim sorumlu tutuluyor? Bu soruların cevabı yoksa RAG projesi teknik olarak başarılı olsa bile operasyonel olarak sancılı bir hal alıyor.
Evet, doğru duydunuz.
Tam çalışan sistem değil, tam ölçülen sistem kazandırır
Bence burada en büyük tuzak şu: insanlar başarıyı demo ekranında ölçüyor. Oysa gerçek ölçüt, kullanıcı sorusunun doğru kaynaktan beslenip beslenmediği olmalıydı hep zaten.
Bir arkadaşım Londra’da böyle bir sistemi müşteri destek ekibine açtı. İlk hafta herkes bayıldı çünkü yanıtlar hızlıydı, ekran temiz görünüyordu. Sonra raporladılar: hatalı citation oranı düşük görünse de hayati sorularda hata payı yüksekmiş. Yani sayı güzel görünüyordu ama tablo pek iç açıcı değildi. Maalesef. Bu konuyla ilgili Yapay Zekâ Yığını: Kendi Akıllı Uygulamanı Kur yazımıza da göz atmanızı tavsiye ederim.
Neyse uzatmayalım; iyi RAG demek sadece iyi generation demek değil (evet, doğru duydunuz). Aşağıdaki kontrol listesi bana pratikte çok yardımcı oldu:
- Soru tiplerini ayırın: tanımlayıcı mı, işlem odaklı mı, istisna mı?
- Dökümanı alanlara göre bölün; düz metin yetmezse yapılandırılmış metadata ekleyin.
- Sadece top-k’ye bakmayın; recall@k ve source precision ölçün.
- Zor sorgular için hybrid search deneyin.
Sık yapılan hatalar ve can sıkıcı detaylar
Pek çok ekip embedding güncellemesini büyülü çözüm sanıyor. Değil. Bazen sorun tamamen chunk sınırlarında gizleniyor; bazen dil modeli yanlış yerde aşırı özgüven gösteriyor çünkü prompt içinde yeterince sert sınırlar çizilmemiş oluyor. Bunları bulmak sabır istiyor, gerçekten.
Bir başka klasik hata da dokümanların güncelliğini göz ardı etmek. Eski politika dosyası yeni politikadan önce indekslenmişse sistem size rahatlıkla eski cevabı verir — hem de gülümseyerek. Bu özellikle destek botlarında ciddi hayal kırıklığı yaratıyor çünkü kullanıcı haklı, sistem de emin, ama ikisi farklı dünyada yaşıyor.
Ayrıca içeriğin tamamını aynı yöntemle işlemenin de pek anlamı yok bence. Sözleşme maddeleriyle SSS sayfasını aynı sepete koyarsanız retriever şaşırır — ikisi aynı dili konuşmuyor ki. Ben bunu Haziran ayında Antalya’daki bir pilotta gördüm; teknik notlar ile pazarlama sayfasını birbirinden ayırınca kalite belirgin şekilde arttı. Basit gibi duruyor. Etkisi büyük.
Sıkça Sorulan Sorular
RAG’de en önemli parça hangisi?
Büyük dil modeli değil, çoğu durumda retrieval katmanı en kritik parçadır. Doğru belgeyi getiremezseniz model ne kadar iyi olursa olsun yanlış ya da eksik cevap üretir.
Sadece vektör araması yeterli mi?
Genelde yetmez. Semantik arama anlam yakalar ama exact phrase’leri kaçırabilir. Hybrid search çoğu gerçek senaryoda daha dengeli sonuç verir.
Chunk boyutu nasıl seçilmeli?
Sabit sihirli bir sayı yok. Dokümanın yapısına göre deneyip ölçmek gerekir ; çok büyük chunk bağlam karıştırır, çok küçük chunk ise bilgiyi böler.
Küçük ekipler RAG’i nasıl kurmalı?
Basit başlayın : temiz ingestion, düzgün metadata, hybrid search ve temel değerlendirme metrikleri. Kurulumdan çok doğruluk takibi sizi ileri taşır (bizzat test ettim).
Citation göstermek neden önemli?
Kullanıcı güveni için önemli çünkü cevabın nereden geldiğini gösterir. Hele bir de kurumsal ortamlarda kaynak belirtmeyen botlara kimse kolay kolay güvenmez.
Kaynaklar ve İleri Okuma
İtiraf edeyim, FAISS Proje Sayfası
Bir şey dikkatimi çekti: LangChain Dokümantasyonu
İşte, bir şey dikkatimi çekti: Sentence Transformers Resmi Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
