Embedding Modeli Seçimi 2026: Türkçe RAG İçin Doğru Vektörleştiriciyi Bulmak (Qwen3, Cohere, OpenAI, BGE-M3)

TL;DR — Embedding modeli, bir RAG sisteminin sessiz kahramanıdır: kullanıcı görmez ama her şey ona bağlıdır. 2026 itibarıyla açık ağırlıklı modeller (Qwen3-Embedding-8B, BGE-M3, Jina v5) ticari API'lerle (Google Gemini Embedding, Cohere embed-v4) başa baş yarışıyor; Qwen3-Embedding-8B MTEB çok dilli liderlik tablosunda ~70.6 puanla birinci sırada. Ama benim sana en ısrarla söyleyeceğim şey şu: MTEB bir pusula, hüküm değil. Türkçe verinde hangisinin işe yaradığını ancak kendi verinle test ederek öğrenirsin. Bu yazıda çok dilli mi İngilizce-merkezli mi, boyut/maliyet/gecikme dengesi, hibrit arama ve yeniden sıralama, matryoshka boyutları, self-host mu API mı (KVKK ve veri ikametgâhı dahil), chunking etkileşimi ve yeniden gömme (re-embedding) maliyeti üzerine alandan gözlemlerimi paylaşıyorum; sonunda bir karar çerçevesi ve tablo var.

Sahada gördüğüm en yaygın yanılgıyla başlayayım. Çoğu ekip bir RAG projesine girdiğinde tüm enerjisini büyük dil modeline (LLM) ayırıyor: "GPT mi kullansak, Claude mı, yoksa yerli bir model mi?" Embedding modeli ise neredeyse hiç konuşulmadan, varsayılan olarak seçiliyor — genellikle "herkes OpenAI'ı kullanıyor" diye text-embedding-3-large ya da elimize ilk geçen ne ise o. Oysa ben yıllardır şunu söylüyorum: RAG'in cevap kalitesi, retrieval kalitesini geçemez. LLM ne kadar zeki olursa olsun, ona yanlış ya da alakasız belge parçaları verirseniz, kibarca yanlış cevap verir. Embedding modeli işte tam burada, retrieval'in en başında devreye girer ve sonradan düzeltilmesi en pahalı katmandır.

Embedding modeli ne yapar? Metni — bir cümleyi, bir paragrafı, bir belge parçasını — sayısal bir vektöre, yani anlamı temsil eden bir koordinata dönüştürür. Kullanıcının sorusunu da aynı uzaya gömersiniz ve "soruya en yakın belgeler hangileri?" sorusunun cevabını bu vektörler arasındaki mesafeyle ararsınız. Yani embedding modeliniz, sisteminizin "anlam pusulası"dır. Pusula bozuksa, ne kadar güçlü bir motora sahip olursanız olun yanlış yöne gidersiniz.

Türkçe söz konusu olduğunda bu mesele bir kat daha kritikleşiyor. Türkçe, sondan eklemeli (agglutinatif) bir dil. "Ev", "evler", "evlerimizde", "evlerimizdekiler" — kök aynı ama yüzeysel biçim her seferinde değişiyor. İngilizce-merkezli ya da Türkçeyi zayıf gören bir embedding modeli, bu morfolojik zenginliği yakalayamaz; "evlerimizde" ile "ev" arasındaki anlamsal bağı kaçırabilir. Sonuçta kullanıcı "ev kredisi faiz oranları" diye sorar, sistem "konut finansmanı" başlıklı asıl belgeyi getiremez çünkü model bu iki ifadenin akraba olduğunu yeterince güçlü kodlayamamıştır. İşte Türkçe RAG'de embedding seçiminin kaderi belirlemesinin sebebi budur: yanlış model, kullanıcının doğru soruyu sormasına rağmen doğru belgeyi bulamamasına yol açar.

"

Bir RAG sisteminde hata ayıklarken her zaman önce retrieval'a bakarım. "Model saçmalıyor" diye gelen şikâyetlerin çoğunda LLM masum çıkar; suçlu, ona getirilen alakasız bağlamdır. Ve o bağlamı getiren embedding modelidir.

2026'da bir embedding modeli seçerken karşına çıkan ilk büyük çatallanma bu. Modellerin önemli bir kısmı İngilizce-merkezli eğitilmiştir; başka dillerde "idare eder" ama asıl performansları İngilizce'dedir. Diğer kısım ise gerçek anlamda çok dilli (multilingual) eğitilmiştir.

Türkçe için bu ayrım pazarlık konusu değil. Sana net söyleyeyim: Türkçe RAG kuruyorsan çok dilli bir modelle başlamalısın. Qwen3-Embedding ailesi 100'den fazla dili destekliyor ve MTEB çok dilli tablosunun zirvesinde. BGE-M3 de güçlü bir çok dilli seçenek. Cohere embed-v4 ve Google Gemini Embedding de API tarafında çok dilli liderler arasında. Bunların ortak özelliği, eğitim verilerinde Türkçe de dahil onlarca dilin ciddi temsil edilmesi.

Ama burada ince bir nüans var ve bunu sahada öğrendim: "çok dilli" etiketi tek başına yeterli garanti değil. Bir model 100 dili "destekleyebilir" ama Türkçe'ye ayrılan eğitim verisi cüce kalmışsa, pratikte performans hayal kırıklığı yaratabilir. Tersine, daha az dil destekleyen ama Türkçe verisi zengin bir model seni daha çok memnun edebilir. Yani etiketlere değil, kendi verindeki sonuçlara bakacaksın. Bu beni doğrudan bu yazının kalbindeki mesaja getiriyor.

İzin ver bunu büyük harflerle söyleyeyim, çünkü görmezden gelinen tek bir cümle varsa o da budur: Kendi Türkçe verinde değerlendirme yapmak zorundasın. MTEB (Massive Text Embedding Benchmark) muhteşem bir kaynak, dünya çapında standart bir karşılaştırma zemini. Qwen3-Embedding-8B'nin orada ~70.6 ile birinci olması anlamlı bir sinyal. Ama MTEB bir ortalamadır — onlarca görev, onlarca dilin karışımı. Senin işin, senin müşterin, senin belge havuzun o ortalamanın içinde belki yüzde birlik bir dilime karşılık geliyor.

Şöyle düşün: MTEB sana hangi modellerin "genel olarak iyi" olduğunu söyler. Ama senin RAG'in bir hukuk bürosunun Türkçe sözleşmelerinde mi çalışacak, yoksa bir e-ticaret sitesinin ürün açıklamalarında mı, yoksa bir hastanenin tıbbi raporlarında mı? Bu üç senaryo birbirinden tamamen farklı dil dağılımlarına, terminolojiye, jargon yoğunluğuna sahip. MTEB'de birinci olan model, senin hukuk sözleşmelerinde üçüncü, e-ticaret verinde birinci olabilir. Bunu önceden bilemezsin; ölçersin.

Pratik tavsiyem şu: kendi verinden 50-100 gerçekçi soru-cevap (ya da soru-doğru belge) çifti çıkar. Buna küçük bir "altın küme" (golden set) diyelim. Sonra aday modelleri bu küme üzerinde Recall@k, MRR, nDCG gibi metriklerle yarıştır. Yani "kullanıcının sorusuna gerçekten doğru belge ilk 5'te (ya da ilk 10'da) geliyor mu?" sorusunu sayısal olarak yanıtla. Bu küçük yatırım — bir-iki günlük emek — sana aylar sonra "neden bu sistem doğru cevap vermiyor" diye yapacağın kazıdan çok daha ucuza mal olur.

"

MTEB liderlik tablosu, bir restoran rehberindeki yıldızlar gibidir. Hangi restoranların genelde iyi olduğunu söyler. Ama senin damak tadına, senin akşamına en uygun olanı ancak gidip yiyince anlarsın. Türkçe verinde test etmek, o yemeği tatmaktır.

Birkaç yıl önce "ciddi RAG istiyorsan ticari API kullanacaksın" neredeyse bir doğruydu. Açık modeller İngilizce'de bile geriden gelirdi, çok dilli işlerde ise umutsuzdu. 2026 itibarıyla bu denklem kökten değişti. Sana referans noktaları vereyim:

• OpenAI text-embedding-3-large MTEB'de yaklaşık 64.6 civarında. Hâlâ sağlam, yaygın bir RAG tercihi; ama artık tablonun tepesinde değil.
• Google tarafı yaklaşık 68.3 ile daha yukarıda. Gemini Embedding, API seçenekleri arasında lider konumda.
• Qwen3-Embedding-8B ise ~70.6 ile zirvede ve bu bir açık ağırlıklı model. Yani indirip kendi sunucunda çalıştırabileceğin bir model, en pahalı ticari API'leri MTEB çok dilli ortalamasında geçiyor.

Bu, sektör için sessiz bir devrim. Çünkü artık "en iyi" ile "kendi kontrolümde" arasında seçim yapmak zorunda değilsin; ikisi aynı modelde buluşabiliyor. Jina v5 (~677M parametre) gibi daha küçük açık modeller bile MTEB'de ticari API'lerle eşleşiyor. BGE-M3 ise ayrı bir kategori açıyor: yalnızca yoğun (dense) embedding değil, aynı zamanda seyrek/sözcüksel (sparse/lexical) ve çok-vektörlü (ColBERT tarzı multi-vector) temsilleri tek modelde sunuyor — buna birazdan hibrit arama bölümünde döneceğim.

Yanlış anlaşılmasın: ticari API'lerin yeri hâlâ var. Voyage AI voyage-3-large ve OpenAI text-embedding-3-large birçok ekip için "sıfır altyapı derdi, hızlı sonuç" anlamına geliyor ve bu çok değerli. Mesele "açık her zaman daha iyi" demek değil; mesele artık gerçek bir seçeneğin olması.

Embedding modeli seçimi, MTEB puanından çok daha fazlası. Sahada projeleri yere düşüren genelde puan değil, bu dört pratik kuvvettir.

Boyut (dimension). Her embedding, belirli sayıda boyuta sahip bir vektördür: 384, 768, 1024, 1536, 3072, hatta 4096. Yüksek boyut genelde daha zengin anlam yakalar ama her vektörü saklamak ve karşılaştırmak daha pahalıdır. Burada Qwen3-Embedding'in güzel bir özelliği var: çıktı boyutunu 32 ile 4096 arasında esnek ayarlayabiliyorsun. Bu, matryoshka (iç içe geçmiş boyut) yaklaşımıyla ilişkili — birazdan ayrı başlık açıyorum.

Maliyet. API kullanıyorsan, gömdüğün her token için ödeme yaparsın. İlk gömme (initial embedding) bir kez olur ama büyük bir kurumsal arşivde milyonlarca belge parçası varsa bu fatura ciddi olabilir. Self-host edersen API ücreti ödemezsin ama GPU/altyapı maliyeti ve operasyon yükü devralırsın. Bu bir takas; "ücretsiz" değil, "farklı yerden ödenen".

Gecikme (latency). Kullanıcı bir soru sorduğunda, o sorunun anlık olarak gömülmesi gerekir (query-time embedding). API'ye gidip dönmek ağ gecikmesi ekler; self-host edilen bir model yerelde milisaniyeler içinde cevap verebilir ama bunun için GPU'yu hazır tutman gerekir. Yüksek trafikli bir uygulamada bu fark, kullanıcı deneyiminde hissedilir.

Depolama (storage). 3072 boyutlu, float32 bir vektör yaklaşık 12 KB yer kaplar. Milyonlarca parçada bu, gigabaytlara, vektör veritabanı indeks maliyetine ve RAM baskısına dönüşür. Boyutu yarıya indirmek depolamayı ve arama maliyetini de yaklaşık yarıya indirir. İşte bu yüzden boyut seçimi salt bir kalite kararı değil, bir bütçe kararıdır.

Bu dördünü birlikte düşünmek gerekir. Çok yüksek boyutlu bir modeli seçip sonra "neden vektör DB faturamız patladı, neden arama yavaşladı" diye şaşırmak, sahada sık gördüğüm bir tuzak. Önce şu soruyu sor: bu kalite artışı, getirdiği maliyete değer mi? Çoğu Türkçe kurumsal senaryoda 1024 boyut, 4096'nın getirdiği marjinal kazançtan çok daha pratiktir.

Matryoshka temsilleri (iç içe Rus bebekleri gibi düşün) modern embedding'lerin en zarif özelliklerinden biri. Fikir şu: model öyle eğitilir ki vektörün ilk N boyutu tek başına anlamlı ve kullanılabilir bir temsil oluşturur. Yani 4096 boyutlu bir vektör ürettiğinde, onun ilk 1024'ünü ya da ilk 512'sini kesip atsan bile elindeki hâlâ tutarlı bir embedding olur — sadece biraz daha az detaylı.

Bu pratikte neden bu kadar değerli? Çünkü tek bir modelle birden çok rejimi aynı anda çalıştırabilirsin. Örneğin: kaba bir ilk eleme (ilk-aşama retrieval) için vektörlerin kısa hâlini kullanıp hızlı ve ucuz tararsın; sonra elde kalan az sayıda adayı tam boyutta yeniden değerlendirirsin. Qwen3-Embedding'in 32'den 4096'ya kadar esnek boyut sunması tam da bu esnekliği veriyor. Depolamayı kısmak istediğinde modeli değiştirmek zorunda kalmazsın; aynı modelden daha kısa vektör istersin. Migrasyon derdi olmadan kalite-maliyet kaydırağını ayarlarsın.

Tavsiyem: matryoshka destekli bir model seçtiysen, üretime geçmeden önce birkaç boyutta (örneğin 512, 1024, tam boyut) altın kümen üzerinde Recall ölç. Çoğu zaman kalitenin belirli bir boyuttan sonra düzleştiğini, ötesinin sadece maliyet eklediğini görürsün. O "yeterince iyi" noktayı yakalamak, mühendisliğin en tatmin edici anlarından biridir.

Şimdi sahanın en az anlaşılan ama en çok fark yaratan konusuna geliyorum. Yoğun (dense) embedding harikadır — anlamsal benzerliği yakalar, eş anlamlıları, parafrazları bulur. Ama bir zayıflığı vardır: nadir, spesifik terimleri bazen kaçırır. Bir ürün kodu, bir yasa maddesi numarası, bir özel isim, bir kısaltma — bunlar anlamsal uzayda "seyrek" olduğu için dense embedding onları her zaman güçlü yakalayamaz.

İşte burada hibrit arama devreye girer: yoğun (anlamsal) aramayı, seyrek/sözcüksel (lexical, BM25 benzeri tam-eşleşme odaklı) aramayla birleştirirsin. Türkçe için bu özellikle değerli, çünkü terminoloji ve özel adlar yoğun. BGE-M3'ün bu noktada güzel bir avantajı var: tek modelden hem dense, hem sparse/lexical, hem de ColBERT tarzı çok-vektörlü temsil üretebiliyor. Yani üç farklı arama stratejisini tek bir gömme altyapısıyla besleyebilirsin.

Hibrit aramanın üstüne bir de yeniden sıralama (reranking) koyabilirsin. Mantık şu: önce embedding ile geniş bir ağ at (örneğin ilk 50 aday), sonra daha ağır ama daha isabetli bir cross-encoder reranker ile bu 50'yi yeniden puanlayıp en iyi 5'i seç. Reranker, soru ile her adayı birlikte değerlendirdiği için anlamsal isabeti ciddi artırır. Maliyeti yüksektir, bu yüzden onu sadece embedding'in elediği küçük aday kümesine uygularsın. Sahada gördüğüm en büyük kalite sıçramaları, çoğu zaman daha iyi bir embedding modelinden değil, var olan embedding'in üstüne iyi bir reranker eklemekten geldi.

"

Tek bir vektör benzerliğine her şeyi yıkmak, tek bir gözle dünyaya bakmak gibidir. Hibrit arama ikinci gözü, reranking ise gözlüğü ekler. Türkçe gibi terminoloji yoğun bir dilde bu fark, "fena değil" ile "vay be" arasındaki farktır.

Türkiye'de kurumsal danışmanlık yaparken bu soru neredeyse her projede masaya geliyor ve teknik olduğu kadar hukuki bir karar. Mesele sadece "hangisi daha ucuz/hızlı" değil; verinin nereye gittiği meselesi.

API yolunu seçersen, gömeceğin her metin parçası — sözleşmelerin, müşteri kayıtların, iç raporların — gömme için bir dış sağlayıcının sunucularına gider. Çoğu senaryoda bu kabul edilebilir ve sağlayıcılar ciddi güvenlik taahhütleri sunar. Ama KVKK (Kişisel Verilerin Korunması Kanunu) kapsamında kişisel veri işliyorsan, verinin yurt dışına aktarımı, açık rıza, veri ikametgâhı (data residency) gibi başlıklar devreye girer. Sağlık, finans, kamu gibi sektörlerde bu çoğu zaman bir kırmızı çizgidir: veri kurumun sınırlarından çıkamaz.

İşte açık ağırlıklı modellerin 2026'daki asıl değeri burada parlıyor. Qwen3-Embedding-8B gibi bir modeli kendi sunucunda, kendi veri merkezinde (on-prem) ya da kontrolündeki bir bulutta çalıştırabilirsin. Veri kurumun duvarlarının dışına hiç çıkmaz; gömme işlemi tamamen senin kontrolündeki donanımda gerçekleşir. Üstelik bu artık "kaliteden ödün vermek" anlamına gelmiyor — Qwen3-Embedding MTEB zirvesinde. vLLM ve SGLang gibi çıkarım (inference) altyapıları bu modelleri birinci sınıf destekliyor, yani üretim ölçeğinde verimli servis etmek pratik ve olgun.

Karar verirken kendine şu soruları sor: İşlediğim veride kişisel/hassas bilgi var mı? Sektörel düzenleme (BDDK, KVKK, sağlık mevzuatı) veri ikametgâmını zorunlu kılıyor mu? GPU işletecek teknik kapasitem var mı, yoksa bunu yönetmek bana ağır mı gelir? Trafiğim, GPU'yu sürekli açık tutmayı ekonomik kılacak yoğunlukta mı? Cevaplar seni ya net bir self-host ya da net bir API kararına götürür; arada kaldığın durumlarda hassas veriyi on-prem açık modelle, hassas olmayanı API ile gömen hibrit bir mimari de kurulabilir.

Embedding modelinin performansı, ona ne verdiğinle doğrudan bağlı — yani chunking (belgeleri parçalara bölme) stratejinle. Bu ikisini ayrı düşünmek, sahada gördüğüm en pahalı hatalardan biri.

Şunu hatırla: Qwen3-Embedding 32K bağlam penceresi sunuyor. Bu, çok uzun parçaları bile tek seferde gömebileceğin anlamına gelir. Ama "gömebilmek" ile "iyi gömmek" aynı şey değil. Bir parçaya çok fazla farklı konu sıkıştırırsan, ortaya çıkan vektör bir "ortalama anlam" olur ve hiçbir spesifik soruyla güçlü eşleşmez — buna anlamın sulanması diyorum. Tersine, parçaları aşırı küçültürsen bağlam kopar; "o" zamiri neyi işaret ediyor, hangi başlığın altındayız belli olmaz.

Türkçe için pratik gözlemlerim: anlamsal bütünlüğü koruyan, başlık/altbaşlık sınırlarına saygılı, makul örtüşmeli (overlap) parçalar en iyi sonucu veriyor. Uzun bağlam penceresi olan bir modelle çalışıyorsan, parçaları biraz daha büyük tutup her parçaya kısa bir bağlamsal başlık eklemek (örneğin belge adı + bölüm başlığı) retrieval isabetini gözle görülür artırıyor. Önemli nokta: chunking stratejini de altın kümen üzerinde test etmelisin. Aynı embedding modeli, farklı chunking ile çok farklı Recall verir. Yani "model mi kötü?" diye sormadan önce "parçalama mı kötü?" diye sor.

Bu, ekiplerin en sık ihmal ettiği ama en geç pişman olduğu kalemdir. Diyelim ki bugün bir embedding modeli seçtin, milyonlarca belge parçasını gömdün, vektör veritabanını doldurdun ve sistem yayında. Altı ay sonra daha iyi bir model çıktı ya da mevcut modelin Türkçe'de zayıf kaldığını fark ettin. Şimdi ne olacak?

Cevap acı: embedding modelini değiştirmek demek, tüm arşivi sıfırdan yeniden gömmek demek. Çünkü farklı modellerin vektör uzayları birbiriyle uyumlu değildir; eski model A'nın vektörleriyle yeni model B'nin sorgu vektörünü karşılaştıramazsın. Yani migrasyon, sadece "ayarı değiştir" değil; milyonlarca parçayı yeniden işlemek, yeni indeks kurmak, eski-yeni geçişini kesintisiz yönetmek demek. Hem hesaplama maliyeti hem operasyonel risk taşır.

Bunun pratik sonucu: ilk seçimi ciddiye al. Birkaç gün altın küme testine yatırım yapmak, altı ay sonra terabaytlarca veriyi yeniden gömmekten çok daha ucuz. Ayrıca migrasyon riskini baştan azaltacak kararlar verebilirsin: matryoshka destekli bir model seçmek, en azından boyut değişikliklerinde yeniden gömmeden kurtarabilir (aynı modelden kısa vektör alarak). Soyutlama katmanı kullanmak (embedding sağlayıcısını koddan ayırmak) ileride geçişi kolaylaştırır. Ve modelini versiyonla — hangi vektörün hangi model/versiyonla üretildiğini sakla ki kademeli (incremental) migrasyon yapabilesin.

"

Embedding seçimi bir evlilik değil ama boşanması pahalı bir ilişki. Baştan biraz flört etmek — birkaç adayı kendi verinde denemek — sonradan bütün arşivi yeniden gömme acısından korur.

Aşağıdaki tablo, bu yazıda konuştuğumuz adayları pratik karar boyutlarıyla özetliyor. Sayılar (MTEB, parametre, boyut, bağlam) verilen referans noktalarına dayanıyor; geri kalanı sahadaki niteliksel gözlemim. Kesin hüküm değil, başlangıç pusulası olarak oku.

Model	Tür	MTEB (referans)	Bağlam	Boyut	Öne çıkan
Qwen3-Embedding-8B	Açık ağırlıklı	~70.6 (çok dilli #1)	32K	32–4096 (esnek)	100+ dil, matryoshka, vLLM/SGLang; en güçlü self-host adayı
BGE-M3	Açık ağırlıklı	Güçlü çok dilli	Uzun	Dense + sparse + multi-vector	Hibrit aramayı tek modelden besler
Jina v5	Açık ağırlıklı	API'lerle eşleşiyor	—	~677M param	Küçük ama rekabetçi açık model
Google Gemini Embedding	API	~68.3	—	—	API tarafında lider
Cohere embed-v4	API	Lider seviye	—	—	Güçlü çok dilli API
OpenAI text-embedding-3-large	API	~64.6	—	3072'ye kadar	Sağlam, yaygın, kolay RAG tercihi
Voyage voyage-3-large	API	Üst düzey	—	—	Yaygın, sağlam RAG seçeneği

Bu tabloya bakarken hatırla: "MTEB #1" sütunu seni cezbetmesin. O sayı, senin Türkçe verinde değil, küresel ortalamada birinci demek. Tablo, kısa listeni daraltmak içindir; kararı altın kümen verir.

Bu yazıyı kapatmadan, projelerde tekrar tekrar karşıma çıkan ve ders kitaplarında pek geçmeyen birkaç pratik notu daha bırakmak istiyorum. Çünkü embedding seçimi sadece "hangi model" sorusu değil; o modeli nasıl beslediğin, nasıl ölçtüğün ve nasıl izlediğinle bütünleşik bir karar.

Normalizasyon ve ön işleme. Türkçe metinde küçük tutarsızlıklar — Türkçe "i/ı", "İ/I" büyük-küçük harf dönüşümleri, noktalama, gereksiz boşluklar — embedding kalitesini sessizce aşındırabilir. Sorgu metnini ve belge metnini aynı şekilde normalize ettiğinden emin ol. Sorguyu bir biçimde, belgeleri başka biçimde işlersen, ikisi aynı vektör uzayında olsalar bile yapay bir mesafe yaratırsın. Tutarlılık, çoğu zaman daha pahalı bir modelden daha çok kazandırır.

Çok dilli sorgu-belge eşleşmesi. Türkçe RAG'lerde sık görülen bir senaryo: belgeler Türkçe ama kullanıcı bazen İngilizce terim ya da kısaltma kullanıyor ("KPI", "ROI", "compliance"). Gerçek anlamda çok dilli bir embedding modeli, "verim" ile "efficiency" arasındaki köprüyü kurabilir; İngilizce-merkezli ya da zayıf çok dilli bir model bu çapraz-dil eşleşmesinde tökezler. Altın kümene bu tür karışık-dil sorgularından da koymayı unutma, çünkü kullanıcıların gerçekte böyle yazdığını göreceksin.

İzleme ve geri bildirim döngüsü. Üretime geçmek bitiş değil, başlangıçtır. Hangi sorguların boş ya da alakasız sonuç döndürdüğünü logla; bu loglar, altın kümeni büyütmen ve modelini ya da chunking'ini iyileştirmen için altın değerinde bir hammadde. Sahada en sağlıklı RAG sistemleri, ilk günkü embedding kararına saplanıp kalmayan, kullanıcı davranışından sürekli öğrenen sistemler oldu. Embedding modelin sabit kalsa bile, onu beslediğin veri ve çevresindeki reranking/hibrit katmanlar zamanla olgunlaşır.

Bütün bunların altını şöyle çizeyim: doğru embedding modeli, iyi bir başlangıçtır ama tek başına bir bitiş değildir. Onu doğru chunking, tutarlı ön işleme, hibrit arama, reranking ve sürekli ölçümle çevrelediğinde, ortaya kullanıcının güvenebileceği bir Türkçe RAG çıkar. Tek bir parametreyi mükemmelleştirmeye değil, bu zinciri uçtan uca sağlam kurmaya odaklan.

Sana reçete veremem çünkü doğru cevap senin kısıtlarına bağlı. Ama sahada kullandığım karar çerçevesini paylaşayım; sırayla bu soruları yanıtla, yol kendiliğinden netleşir.

1. Veri hassasiyeti ve mevzuat. İşlediğin veride kişisel/hassas bilgi var mı? KVKK, BDDK ya da sektörel düzenleme veri ikametgâhını zorunlu kılıyor mu? Cevap "evet" ise, açık ağırlıklı bir modeli (Qwen3-Embedding-8B, BGE-M3) on-prem çalıştırmaya doğru güçlü bir eğilim var. "Hayır, veri hassas değil" ise API'ler (Gemini, Cohere, Voyage, OpenAI) hızlı başlangıç sunar.

2. Dil profili. RAG'in ağırlıklı Türkçe mi? O zaman çok dilli modeller şart; İngilizce-merkezli olanları kısa listenden çıkar. Türkçe + birkaç başka dil karışıksa, Qwen3'ün 100+ dil desteği rahatlatıcıdır.

3. Ölçek ve maliyet. Kaç milyon parça gömeceksin? Trafiğin ne kadar? Yüksek hacimde, sürekli açık GPU'yu ekonomik kılan bir self-host; düşük/değişken hacimde, kullandıkça öde mantığıyla API daha mantıklı olabilir. Depolama ve boyut maliyetini önden hesapla; matryoshka destekli modelle boyutu kısma seçeneğini cebinde tut.

4. Kalite hedefi ve karmaşıklık iştahı. En yüksek isabeti mi istiyorsun? O zaman embedding + hibrit arama + reranking üçlüsünü planla; BGE-M3 gibi hibridi tek modelden besleyen bir seçenek mimariyi sadeleştirir. Hızlı, "yeterince iyi" bir başlangıç mı yetiyor? Tek bir güçlü embedding ile başla, sonra reranker ekleyerek büyüt.

5. Doğrulama — her zaman son adım. Hangi yolu seçersen seç, üretime geçmeden önce 2-3 adayı kendi Türkçe altın kümen üzerinde Recall@k ve nDCG ile yarıştır. Bu adımı atlama. Bu yazıdaki tek pazarlıksız kural budur.

Pratikte benim bugün çoğu Türkçe kurumsal proje için ilk denememe başladığım yer şu: hassas veri ve on-prem ihtiyacı varsa Qwen3-Embedding-8B'yi (uygun boyutta, matryoshka ile ayarlanmış) hibrit arama ve bir reranker ile; hassas veri yoksa ve hız önemliyse Cohere embed-v4 ya da Gemini Embedding'i yine reranker'la denerim. BGE-M3'ü ise hibrit aramayı tek altyapıdan yönetmek isteyen ekiplere özellikle öneririm. Ama bunların hiçbiri senin için kesin doğru değil — senin için kesin doğru, kendi verinde ölçtüğün şeydir.

Şimdi yapacağın iş net: kısa listeni bu çerçeveyle daralt, küçük bir altın küme hazırla, iki üç modeli yarıştır, kazananı hibrit arama ve reranking ile güçlendir, boyutu maliyetine göre ayarla, ve modelini versiyonlayarak ileride yeniden gömme acısına karşı kendini sigortala. Embedding modeli sessiz kahramandır; ona hak ettiği ilgiyi verirsen, Türkçe RAG sistemin kullanıcının önüne her seferinde doğru belgeyi koyar — ve gerisi çok daha kolay gelir.