Microsoft Copilot tarafında arama altyapısı kuran biriyle konuşsanız, size ilk söyleyeceği şey büyük ihtimalle şu olur: demo ile prod ortamı arasında küçük bir uçurum değil, bayağı derin bir vadi var. Ben de bunu geçen yıl, Şubat 2025’te İstanbul’da bir müşteri sunumu hazırlarken yeniden yaşadım. Kağıt üstünde şahane görünen bir RAG akışı, gerçek veriyle karşılaşınca tökezledi. İlginç, değil mi? Hani tutorial’daki “split et, embed et, vector DB’ye at” yaklaşımı vardır ya — işte o yaklaşım prod’da tek başına pek yürümüyor.
Dürüst olmak gerekirse, Bu yazıda meseleye tam da oradan bakacağım. Semantic search. RAG altyapısını ölçekli şekilde kurarken nelerin can yaktığını, hangi parçaların sandığımızdan çok daha kritik olduğunu ve küçük ekiplerle kurumsal ekiplerin neden farklı oynadığını kendi yorumumla anlatacağım. Açık konuşayım: burada iş sadece model seçmek değil. Neden önemli bu? Veri kalitesi, chunking mantığı, re-ranking ve tazelik gibi konuların hepsi aynı masada oturuyor.
Hmm, bunu nasıl anlatsamdı…
Demo Çalışıyor Ama Üretimde Neden Dağılıyor?
Tutorial’larda her şey tertemiz görünür (buna dikkat edin). Belgeyi parçalara ayırırsın, embedding üretirsin, vektör veritabanına koyarsın, sorguda en yakın beş sonucu çekip LLM’e verirsin. Kulağa düzgün geliyor. Fakat pratikte kullanıcı soruları gri alanda dolaşıyor — yarım cümleler geliyor, bağlam eksik oluyor, bazen dokümanlar birbirine karışıyor. Sistem bir anda elini kolunu sallayarak yanlış yere gidiyor (bizzat test ettim)
Açık konuşayım, Ben bu farkı ilk kez 2023 sonunda kendi yan projelerimden birinde yaşadım. Bir teknik destek bilgi tabanı kuruyorduk; sistem “benzer” sonuçları iyi getiriyordu. Gerçekten doğru cevabı bulmakta şaşırtıcı derecede isteksizdi. Yani arama motoru gibi davranıyordu, yardımcı asistan gibi değil. İşin aslı şu ki semantic search’te “benzer” ile “ilgili” aynı şey değil. Bu fark küçük gibi görünüyor ama üretimde sizi çok yoruyor.
Hmm, bunu nasıl anlatsamdı…
Bir de kaynakların güncel kalması meselesi var. Doküman değişiyor ama indeks eski sürümü taşıyorsa kullanıcıya yanlış cevap veriyorsunuz — ve güven çabuk eriyor. En çok da enterprise tarafta bu hata affedilmiyor; çünkü tek bir eski paragraf bile hukuk metninde ya da iç politika dokümanında ciddi sorun çıkarabiliyor, departmanlar arası gerginliğe dönüşebiliyor.
RAG’i sağlam yapan şey sadece model değil; doğru parçayı doğru zamanda getirebilmek.
Chunking: Metni Bölmek Değil, Anlamı Korumak
Bakın, Bence en çok hafife alınan konu chunking. İnsanlar bunu hâlâ “uzun metni böl, geç” diye görüyor. Öyle değil. Paragrafın ortasında keserseniz anlam kırılıyor; cümlenin sonunu başka yere atarsanız referans kayboluyor; başlıkla gövdeyi ayırmazsanız bağlam uçup gidiyor. Bir nevi yemek yaparken soğanı rastgele doğramak gibi — malzeme var ama lezzet yok.
Peki neden?
Bunu yaşayan biri olarak söyleyeyim, Kendi testlerimde özellikle hukuki sözleşmeler. Ürün dökümantasyonunda bölüm bazlı chunking’in düz split’e göre belirgin biçimde daha iyi çalıştığını gördüm. Ankara’daki bir ekiple yaptığım denemede aynı soru için klasik token bazlı parçalama yerine başlık odaklı yapı kullandık. Ilgili sonuçların isabet oranı gözle görülür şekilde arttı. Şaşırdım açıkçası, o kadar dramatik bir fark beklemiyordum.
Burada overlap meselesi de önemli. Chunk’lar arasında azıcık tekrar olması kötü değil; tam tersine sınırdaki bilgiyi koruyor. Tabii fazla overlap maliyet şişiriyor — yani dozunda olacak.
Sade Bir Chunker Mantığı Nasıl Görünür?
class SemanticChunker:
def chunk(self, document: str, max_tokens: int = 512) -> list:
sections = self._split_by_headers(document)
chunks = []
for section in sections:
if self._token_count(section) <= max_tokens:
chunks.append(section)
else:
paragraphs = section.split("
")
chunks.extend(self._merge_paragraphs(paragraphs, max_tokens))
return chunks
def _merge_paragraphs(self, paragraphs, max_tokens):
merged = []
current = ""
for para in paragraphs:
if self._token_count(current + para) <= max_tokens:
current += "
" + para
else:
if current:
merged.append(current.strip())
current = para
if current:
merged.append(current.strip())
return mergedEvet, kod basit görünüyor. Ama burada asıl mesele satırlar değil, prensipler. Section bazlı ayrıştırma yoksa belgenin ruhunu kaçırıyorsunuz — sonra da modelden mucize bekliyorsunuz.
Neden Sadece Vektör Benzerliği Yetmiyor?
Vector search güzel bir başlangıç noktası. Ama son durak değil. Benzerlik skoru yüksek olan her sonuç kullanıcının — en azından ben öyle düşünüyorum — niyetini karşılamıyor çünkü — bazen iki metin dil olarak çok yakın görünüyor ama biri teknik detay, diğeri satış broşürü çıkıyor. Buyurun size yanlış yönlendirme. TEAPOT.EXE: 418’i Ciddiye Alan En Şaşırtıcı SaaS Şovu yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Lenovo Legion Go 2’nin Fiyatı Uçtu: 2.849 Dolar Şoku yazımıza bakabilirsiniz.
Yani, Bunun üzerine ikinci katmanı eklemek gerekiyor: re-ranking ve filtreleme işlemleriyle adayları yeniden tartmak lazım. Geçen mart ayında Berlin’deki bir workshop sırasında bunu canlı test ettik; ilk aşamada top-k geniş tutulduğunda sistem daha fazla aday buldu, ama nihai doğruluk ancak cross-encoder benzeri yeniden sıralama devreye girince toparlandı. Fark belliydi. Daha fazla bilgi için 2026’da Kod Asistanı Seçimi: Tek Araç Değil, Set yazımıza bakabilirsiniz.
| Aşama | Ne Yapıyor? | Neden Gerekli? |
|---|---|---|
| İlk retrieval | Adayları geniş tarar | Daha çok olası eşleşme toplar |
| Re-ranking | Adayları sorguya göre yeniden sıralar | “Benzer” ile “ilgili” farkını kapatır |
| Filtreleme | Tarih / kaynak / izin kontrolü yapar | Zaman aşımı ve yanlış içerik riskini azaltır |
| Nihai context seçimi | LLM’e gidecek parçaları daraltır | Token israfını önler |
E tabi, buradaki bedel ekstra gecikmedir. Kaçınılmaz.
Kontekst Penceresi Yönetimi: Her Şeyi Prompt’a Tıkma Hatası
İnsanlar genelde şöyle düşünüyor: “Topladığım beş chunk’ı prompt’a koyayım, bitsin.” Kağıt üstünde mantıklı duruyor. Pratikte ise prompt’u gereksiz bilgiyle doldurmuş oluyorsunuz. LLM’e verdiğiniz her token kıymetli — bir nevi valize kışlık montla plaj havlusunu birlikte sığdırmaya çalışmak gibi. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Bakın, Şahsen ben en iyi sonucu genelde üç katmanda aldım: 1) sorguyla gerçekten ilişkili parçalar, 2) kısa özetlenmiş bağlam, 3) gerekiyorsa ham pasaj. Üniversite kampüsündeki bir iç araçta bunu denediğimizde cevap süresi biraz uzadı ama alakasız içerik dramatik biçimde düştü. Şey gibi dursun diye demiyorum — gerçekten işe yaradı.
Küçük Startup vs Enterprise Ne Yapmalı?
- Küçük startup için: Basit chunking + hafif re-ranking çoğu zaman yeterli olur.
- Kurum seviyesinde: Yetkilendirme filtresi, doküman sürüm takibi, audit log şart olur.
- Maliyet baskısı yüksekse: 4K yerine dar context tasarımı daha mantıklı olabilir.
Peki hangisi daha zor? Enterprise tarafı tabii ki. Çünkü veri çok, kural çok, itiraz eden departman sayısı da cabası. Buna rağmen küçük ekiplerde de rehavet tehlikesi var — hızlı çıkan demo yüzünden mimari borç sessiz sedasız büyüyebiliyor.
Tazelik Meselesi: “İndeks Acaba Güncel mi?”
Duran indeks, RAG’in sessiz düşmanıdır. Doküman değişince indeksi yenilemezseniz, kullanıcıya dünün gerçeğini bugünün cevabı diye sunarsınız. Bunu Ağustos 2024’te İzmir’de çalışan bir SaaS ekibinde gördüm; sözleşme maddesi güncellenmişti ama arama sistemi hâlâ eski sürümü gösteriyordu. Bayağı tatsızdı. Müşteri temsilcileri ilk hafta bunun yüzünden epey yoruldu.
Tazelik yönetimi için full re-index şart değil. Gerekirse yapılır ama çoğu durumda artımlı güncelleme daha akıllıca. Yeni belge geldiyse ekle, değiştiyse ilgili chunk’ları yenile, silindiyse temizle. Hani mutfağın tamamını söküp yeniden kurmuyorsunuz — sadece bozulan çekmeceyi hallediyorsunuz.
Garip gelecek ama, Aşağıdaki noktalar bana göre olmazsa olmaz:
- Sürüm numarası tutmak
- Metriklere freshness alarmı koymak
- Anomali yakalayınca manuel inceleme yapmak
Neyi İyi Yaptığında Sistem Rahatlar?
Neyse, garip gelecek ama, Sistemi rahatlatan şey aslında birkaç temel alışkanlık. Temiz metadata tutuyorsanız, dokümanın nereden geldiği belliyse, hangi bölümün hangi tarihte oluştuğu izlenebiliyorsa işler baya kolaylaşıyor. Bu kadar mı? Evet, çoğu zaman evet. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Bana kalırsa en büyük kazanç şu: gözlemleme olmadan yapılan RAG işi kör pilotaja benziyor. Log yoksa, relevance feedback yoksa, kullanıcının neden memnun olmadığını anlayamıyorsunuz. Mart 2025’te Kadıköy’de yaptığım kısa bir danışmanlıkta bunu net gördük — dashboard ekleyince sorunlu query kümeleri hemen ortaya çıktı.
Aşağıda pratik kontrol listemi bırakıyorum:
- sorguyu kaydet;
- dönen candidate listesini sakla;
- LLM’e giden final context’i ayrı logla;
- düşük güven skorlarında alarm üret;
- sık gelen boş sonuçlara özel analiz aç.
Lafı gevelemeden söyleyeyim: bu liste olmadan optimizasyon yapmak tahmin yürütmeye dönüşüyor. Tahmin bazen işe yarar, ama ölçek büyüdüğünde pek şaka kaldırmıyor (buna dikkat edin)
Bana Göre En Doğru Mimari Nasıl Olmalı?
Küçük Proje İçin Pratik Kurgu
Elinizde sınırlı bütçe varsa önce sade başlayın. Başlangıçta iyi metadata, başlık temelli chunking ve basic rerank çoğu işi çözüyor. Bunu kendi blog prototiplerimde defalarca gördüm — fazla karmaşa erken aşamada fayda yerine yük getiriyor.
Enterprise seviyede ise oyun değişiyor. İzin kontrolleri, tenant izolasyonu, versiyonlama (belki yanılıyorum ama) ve observability devreye giriyor. Yani sadece “doğru cevabı bul” yetmiyor; aynı zamanda “doğru kişiye göster” kısmını da çözmeniz gerekiyor. Açıkçası burası tutorial dünyasının pek sevmediği yer — çünkü kir pas çıkıyor.
Son söz niyetine şunu söyleyeyim: RAG altyapısında başarı biraz mühendislik, biraz ürün sezgisi, biraz da sabır istiyor. Model iyidir, vector DB iyidir, hatta reranker da iyidir. Hepsinin üstüne sağlam veri disiplini koymazsanız sistem orta karar kalıyor. “Beklediğim kadar değildi” dediğim birçok demo oldu, buna rağmen çıkan dersler fena halde değerliydi.
Sıkça Sorulan Sorular
Semantic search ile klasik keyword search arasındaki fark nedir?
Keyword search kelime eşleşmesine bakar; semantic search ise anlam benzerliği arar. Kullanıcı farklı ifade kullansa bile ilgili sonucu bulmaya çalışıyor. Bu yüzden doğal dil sorularında genelde çok daha iyi hissettiriyor.
RAG için en önemli parça hangisi?
Tek bir parça seçmem gerekse veri hazırlığı derdim. Chunking, metadata, tazelik ve erişim kontrolü düzgün değilse LLM tarafındaki kalite hızla düşüyor. Model ne kadar güçlü olursa olsun kötü girdiyi sihirle düzeltemez.
Re-ranking gerçekten gerekli mi?
Çoğu gerçek senaryoda evet. İlk retrieval aday toplamak için var; re-ranking ise o adayların gerçekten soruya uygun olup olmadığını ayıklıyor. Peki, en çok da büyük doküman havuzlarında fark bariz oluyor.
Küçük startup’lar nasıl başlamalı?
Basit başlayıp ölçerek ilerlemeli. Önce iyi chunking, sonra hafif filtreleme, ardından ihtiyaç varsa re-ranker eklemek genelde yeterli oluyor. Gereksiz karmaşık mimari erken aşamada maliyet şişirebilir — neyse, dağıtmayayım: ölçmeden büyütmeyin.
Kaynaklar ve İleri Okuma
- Azure AI Search Documentation
- Microsoft GraphRAG GitHub Sayfası
- Pinecone Learn Merkezi
- AI’yi Projene 2 Saatte Eklemenin Gerçek Hali
- Specification-First Agentic Development AI ile Kod Yazmanın Daha Temiz Yolu
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.
