2026'da şirketlerde devreye alınan AI sohbet botlarının büyük çoğunluğu RAG'a (Retrieval-Augmented Generation) dayanır. Yine de denetimlerimizde işe yarayan projeler ile vejete eden projeler arasında büyük bir fark görüyoruz: neredeyse hiçbir zaman sorun yaratan LLM değildir. Bilgi tabanıdır. Aynı GPT-4 Turbo veya aynı Mistral Large 2, iki farklı RAG pipeline'ına bağlandığında, parlak bir asistan veya kibar bir halüsinasyon üreticisi üretebilir. Fark %90 oranında retrieval mühendisliğinde oynanır.

Bu makale, sohbet botunuzu gerçekten faydalı kılan bir RAG inşa etmek için bir teknik rehberdir. Altı adımı detaylandırıyoruz: kaynak denetimi, chunking, embeddings, vektör veri tabanı, reranking, değerlendirme. Her adım, belgelenmiş trade-off'lar ve projelerimizden elde edilen rakamlarla somut bir hakemlik taşır. Amaç: bir RAG bütçesi imzalamadan önce sormanız gereken doğru soruları ve mevcut bir projenin raydan çıktığını tespit etmek için doğru sinyalleri size vermek.

RAG 2026'da neden belirleyici adım haline geldi

Sınır LLM'leri büyük ölçüde ilerledi, ancak sektörünüz konusunda temelde cahil kalıyorlar. Faydalı bir iç asistan dokümantasyonunuza, prosedürlerinize, sözleşmelerinize, ürünlerinize göre yanıt vermelidir. Fine-tuning ağır, pahalı ve haftalık olarak gelişen kaynaklara karşı az çevik kalır. RAG kendini dayattı çünkü doğru uzlaşmayı sunar: sorgu anında ilgili bağlamı modele dokunmadan enjekte etmek, neredeyse gerçek zamanlı güncelleme mümkün.

Ancak RAG çok katmanlı karmaşık bir sistemdir. Her katman bütünü bozabilir. Kötü temizlenmiş bir kaynak, kaba bir chunking, Türkçeye uyumsuz bir embedding, kötü yapılandırılmış bir vektör veri tabanı, reranking yokluğu, ve LLM mükemmel olsa bile son yanıt hayal kırıklığı yaratacaktır. Bu nedenle RAG'ı her zaman tam ölçüm ve sürekli iyileştirme döngüsüne sahip kendine özgü bir mühendislik disiplini olarak ele alıyoruz.

1. Kaynakları denetleyin ve temizleyin

Her şey derlemle başlar. Bir RAG sohbet botu hiçbir şey icat etmez: ona verdiklerinizi seçer, yeniden formüle eder ve sentezler. İç dokümantasyon bir prosedürün üç çelişkili sürümünü içeriyorsa, RAG üçünden birini rastgele çıkaracaktır. Bir SharePoint'te unutulmuş 2019'dan kalma eski bir PDF varsa, sonunda onu alıntılayacaktır. İlk adımımız sistematik olarak bir belge denetimidir: kaynakları haritalandırmak, kopyaları tanımlamak, eski içerikleri işaretlemek, çelişkileri tespit etmek.

Somut olarak, lotlar halinde çalışıyoruz: bir iş-teknik ikilisi tarafından gözden geçirilen 200 ila 500 belge, bir nitelendirme ızgarasıyla (otoriter mi? güncel mi? tutarlı mı?). Bu iş tatsız ama belirleyicidir. Bu adımı atlayan projeler asla geriye dönüş yapamaz: hasta bir derlemi telafi etmek için teknik katmanlar yığarlar.

  • Tam kopyaları ve neredeyse kopyaları kaldırın
  • Eski içerikleri son kullanma tarihiyle işaretleyin
  • Çelişkileri iş ile karara bağlayın (açık doğrulama)
  • Formatları normalleştirin (taranmış PDF'lerden çok temiz Markdown)

2. Bir chunking stratejisi seçin

Chunking, her belgeyi indekslenebilir parçalara ayıran operasyondur. Üç parametre önemlidir: boyut, overlap ve strateji. Çok küçük (200 token altı), her chunk bağlamını kaybeder ve retrieval tutarsız parçalar getirir. Çok büyük (1500 token üstü), chunk'lar bulanıklaşır ve embedding çok farklı fikri ortalar. Varsayılan aralığımız: 64 ila 128 token overlap ile 512 token. Ancak bu değer asla kutsal değildir: golden dataset üzerinde kalibre ederiz.

Strateji boyut kadar önemlidir. Fixed chunking (her N token) uygulaması hızlıdır ancak yapılandırılmış belgelerde brüttür. Semantic chunking (cümle embeddings'lerine dayalı) anlam birimlerine daha iyi saygı duyar. Structure-aware chunking (HTML etiketlerini, Markdown başlıklarını, PDF yapısını kullanan) teknik dokümantasyonda neredeyse her zaman üstündür. Bir e-ticaret sitesi için bir ürün sayfası bir chunk olarak kalmalıdır. Bir teknik kılavuz için her H2 veya H3 bölümü doğal bir chunk oluşturur.

3. Embeddings'leri seçin

Embeddings her chunk'ı bir vektöre dönüştürür. RAG'ın arama organıdır. Seçim üç kritere bağlıdır: dilinizdeki kalite (Türkçe ve Fransızca, yalnızca İngilizce modellerce yeterince kapsanmaz), boyut (modellere göre 512 ila 3072, depolama maliyeti ve gecikme üzerinde doğrudan etki) ve maliyet. 2026'da dört tekrarlayan adayımız: OpenAI text-embedding-3-large (3072 boyut, mükemmel çok dilli kalite, milyon token başına ~0,13 €), Cohere Embed v3 (1024 boyut, çok dilli olarak çok iyi, türlü semantik aramayı destekler), açık kaynak BGE-M3 (1024 boyut, dikkat çekici performans, self-host edilebilir) ve çok Türkçe veya Fransızca derlemler için Solon veya CamemBERT-large gibi uzmanlaşmış modeller.

Yöntemimiz: müşteri golden dataset üzerinde en az iki embeddings modelini test etmek. Recall@5 ve recall@10 ölçmek. Fark bazen muhteşemdir — çok özel Fransızca hukuki bir derlem üzerinde BGE-M3'ün OpenAI'yi yendiğini ve çok dilli teknik bir derlem üzerinde tersini gördük. Hiçbir model evrensel olarak daha iyi değildir.

4. Vektör veri tabanını seçin

Vektör veri tabanı embeddings'leri depolar ve benzerlik araması (kosinüs, dot-product, L2) yürütür. Beş seçenek hakim. Yönetilen Pinecone, time-to-market'te yenilmez kalır: birkaç satır kod, otomatik ölçeklendirme, ancak tekrarlayan maliyet ve ABD sağlayıcısına bağımlılık. Açık kaynak, self-host edilebilir, performanslı, Rust'ta yazılmış Qdrant: egemenlik önemli olduğunda varsayılan seçimimiz. Postgres'iniz zaten varsa pgvector: bir hizmet eklemenize gerek yok, birkaç milyon vektöre kadar mükemmel. Zengin şemalar ve gelişmiş hibrit arama için Weaviate. Yerel hızlı POC'ler için Chroma.

Gösterge maliyeti: hacme ve moda göre (yönetilen vs self-host) ayda 50 ila 500 €. 10 milyon vektörün ötesinde veya güçlü egemenlik kısıtlamalarında self-host neredeyse zorunlu hale gelir. Araçları zincirlemekten kaçınmanızı öneriyoruz: iyi yönetilen tek bir vektör deposu, kötü entegre edilmiş üç tanesinden daha değerlidir.

5. Reranking'i uygulayın

Reranking, RAG'ın en hafife alınan adımıdır. İlk retrieval tipik olarak vektör benzerliğiyle aday chunk'ların top-20 veya top-50'sini getirir. Ancak embedding benzerliği gerçek alakanın kaba bir yaklaşımıdır. Bir reranker — daha ağır model, cross-encoder tipi — her (soru, chunk) çiftini ince değerlendirerek bu adayları yeniden sıralar. Projelerimizde reranking eklemek, son istemde tam olarak enjekte edilecek olan top-3'te %10 ila %15 daha fazla doğruluk getirir.

İki seçenek hakim. Cohere Rerank v3 mükemmel yönetilen bir hizmettir, çok dilli, yaklaşık 1.000 istek için 1 €. BGE-reranker açık kaynaktır, self-host edilebilirdir, neredeyse aynı performanslıdır, egemen bağlamda idealdir. Yatırım minimumdur — birkaç saatlik entegrasyon, birkaç on milisaniyelik gecikme — bir LLM değişikliğinden çok daha üstün bir kalite kazancı için.

6. Sürekli değerlendirin

Değerlendirme olmayan bir RAG, sessizce sapan bir kara kutudur. Standardımız: çerçevelemeden itibaren iş tarafından doğrulanmış 50 ila 100 soru-yanıttan oluşan bir iç golden dataset inşa etmek ve her yinelemede RAGAS ile yapılandırıcı metrikleri ölçmek: faithfulness (yanıt kaynaklara yapışıyor mu?), answer relevance (soruyu yanıtlıyor mu?), context precision, context recall. Bu dört metrik tam pipeline'ı izler ve bir gerilemenin nerede ortaya çıktığını kesin olarak konumlandırmaya izin verir.

Buna üretim değerlendirmesi eklenir: kullanıcı geri bildirimi (yorumlu başparmak yukarı/aşağı), tatmin edici yanıtsız soruların izlenmesi, iki yapılandırma arasında A/B testi (örneğin chunking 512 vs 768, reranker'lı veya reranker'sız). LangChain ve LlamaIndex artık bu ölçümler için yerel ölçüm hook'ları sunuyor ve Langfuse veya Arize Phoenix gibi araçlar bunları temiz şekilde toplar.

Bir RAG'ı başarısızlığa uğratan tuzaklar

Denetimlerimizde dört hata sistematik olarak geri döner. Birincisi, sonsuza kadar bir kez tanımlanan ve hiçbir zaman yeniden kalibre edilmeyen çok ince veya çok geniş bir chunking. İkincisi, Türkçe veya Fransızca üzerinde test edilmeden varsayılan olarak seçilen embeddings, oysa dil belirli derlemlerde büyük bir fark yaratır. Üçüncüsü, pipeline'ın en kârlı adımı olan reranking yokluğu, yine de düzenli olarak atlanıyor. Dördüncüsü, güncelleme pipeline'ı yokluğu: bilgi tabanı devreye alma tarihinde donar ve sohbet botu artık var olmayan ürünler hakkında sorulara yanıt verir.

Bu teknik tuzaklara metodolojik bir tuzak eklenir: bir RAG'ı "göze" yargılamak. Golden dataset olmadan, RAGAS olmadan, A/B olmadan, kalite hakkında her tartışma özneldir ve dolayısıyla yönetilemez. İlk yinelemeden itibaren ölçümü dayatıyoruz, çünkü yalnızca ölçtüğümüz şeyi iyileştiriyoruz.

Şimdi ne yapmalı?

Performanslı bir RAG birkaç günlük bir proje değildir. Tasarlanan, ölçülen ve sürdürülen bir sistemdir. Ancak ekiplerinizin gerçekten kullandığı bir sohbet botu ile üç hafta sonra terk edilen bir gadget arasındaki farkı yaratan tam olarak bu yatırımdır. DevHighWay'de, teslim ettiğimiz her sohbet botunun omurgası olarak RAG'ı ele alıyoruz: denetlenmiş kaynaklar, kalibre edilmiş chunking, test edilmiş embeddings, yerinde reranker, sürekli değerlendirme.

  • RAG çerçevelemesi için iletişime geçin (1 günlük atölye, rakamsallaştırılmış teknik savaş planı)
  • Tarifelerimize bakın — paketlerimiz RAG'ın bakımını ve sürekli değerlendirmesini içerir
  • Denetimimiz asistanınızın SEO ve GEO görünürlüğünü de kapsayabilir

Bu makaleden tek bir fikir alırsanız: bir RAG sohbet botunun kalitesi LLM seçiminde oynanmaz, retrieval mühendisliğinde oynanır. Burada açıklanan altı adım isteğe bağlı değildir, bir sistem oluştururlar. Birini atlamak, son kalitenin sistemik bozulmasını kabul etmektir. Yöntem ve ölçümle ciddi şekilde ele almak, ekiplerinizin her gün kullanacağı bir asistanı sunma araçlarını kendinize vermektir — ve uzun vadede organizasyonunuzun stratejik bir varlığı haline gelecektir.