Embedding Modeli Seçimi: Türkçe İçerikte Nelere Bakmalı

Embedding modeli seçimi, bir Türkçe RAG (bilgi getirimiyle üretim) sisteminin kalitesini sessizce belirleyen ama çoğu zaman aceleye getirilen bir karardır. Bu yazıda embedding modeli seçimini, "hangi model popüler" sorusundan çıkarıp "benim Türkçe verimde hangi model doğru parçayı daha isabetli getiriyor" sorusuna taşıyan bir mühendislik disiplini olarak ele alıyoruz. Çünkü doğru embedding modeli seçimi, en pahalı üretme modelinin bile telafi edemeyeceği bir kalite tavanını yukarı çeker; yanlış seçim ise tüm sistemin isabetini baştan sınırlar.

Embedding'in ne olduğunu ilk kez duyuyorsanız, temel için embedding nedir ve mimarinin bütününü görmek için RAG nedir rehberleri iyi bir zemin sağlar. Bu yazı ise özel bir soruya odaklanır: Türkçe içerikte embedding modeli seçimi yaparken tam olarak nelere bakmalı, çok dilli ve Türkçeye özel modeller arasında nasıl karar vermeli, boyut ve performans dengesini nasıl kurmalı, benchmark'ları nasıl okumalı ve en önemlisi kendi verinizle nasıl test etmeli. Amacımız size tek bir "en iyi model" adı vermek değil; hangi model gelirse gelsin doğru kararı verebilmenizi sağlayan, tekrarlanabilir bir yöntem kazandırmaktır. Çünkü modeller hızla değişir, ama iyi bir değerlendirme disiplini yıllarca değer üretir.

Tanım

Embedding Modeli Seçimi

Bir metni anlamını temsil eden bir vektöre çeviren modelin, belirli bir kullanım senaryosu için kanıta dayalı biçimde belirlenmesi süreci. Türkçe içerikte doğrudan getirme (retrieval) kalitesini belirler. Karar; genel benchmark sıralaması, çok dilli veya Türkçeye özel model tercihi, boyut ve performans dengesi, maliyet, gecikme, alan uyumu ve değiştirme maliyeti kriterlerinin kurumun kendi Türkçe değerlendirme seti üzerinde ölçülmesiyle verilir.

Ayrıca: embedding model seçimi, gömme modeli seçimi, Türkçe embedding seçimi, vektör modeli seçimi

Embedding modeli seçiminin neden bu kadar önemli olduğunu anlamak için, embedding'in RAG boru hattındaki konumuna bakmak gerekir. Bir RAG sisteminde kullanıcı bir soru sorar; bu soru bir vektöre çevrilir; vektör veritabanında bu soruya anlamca en yakın belge parçaları bulunur; en iyi adaylar seçilir ve modele bağlam olarak verilir. İşte bu zincirin ilk ve en belirleyici halkası embedding'dir. Metni vektöre çeviren model ne kadar iyiyse, "anlamca yakın"lık o kadar isabetli olur; model zayıfsa, doğru belge hiç getirilmeyebilir.

Buradaki kilit gerçek şudur: getirme aşamasında kaçırılan bir belge, sonraki hiçbir adımda geri gelmez. Reranking (yeniden sıralama) yalnızca getirilen adaylar arasından seçim yapar; getirilmeyeni sıralayamaz. Üretme modeli yalnızca kendisine verilen bağlama dayanabilir; verilmeyeni bilemez. Dolayısıyla embedding modeli seçimi, tüm sistemin isabetine bir tavan koyar. En güçlü reranker ve en pahalı dil modeli bile, embedding kötü olduğu için ilk elemede kaybolan doğru belgeyi kurtaramaz. Bu yüzden RAG'de "çöp girerse çöp çıkar" ilkesi en çok embedding katmanında geçerlidir.

Türkçe içerikte bu etki daha da keskinleşir. Türkçe; eklemeli (sondan eklemeli) yapısı, zengin çekim sistemi ve tek kökten çok sayıda türetilmiş biçim üretmesiyle, embedding modelinden özel bir dil yeteneği talep eder. İngilizce'de iyi çalışan bir model, Türkçe'nin bu morfolojik zenginliğini zayıf temsil edebilir ve anlamı kaçırabilir. Bu yüzden Türkçe bir kurumsal bilgi tabanında embedding modeli seçimi, İngilizce bir projeye göre çok daha bilinçli yapılması gereken bir karardır. Türkçe'nin bu zorluklarını Türkçe NLP'de veri, morfoloji ve değerlendirme zorlukları yazısında ayrıntılı ele alıyoruz.

Embedding modeli seçimini Türkçe özelinde konuşmadan önce, Türkçe'nin neden özel bir durum olduğunu netleştirmek gerekir. İngilizce merkezli birçok model, dünyanın en çok kaynağı olan dili baz alarak eğitilir ve Türkçe gibi dilleri "ikincil" olarak, çok dilli bir eğitim karışımının küçük bir parçası olarak öğrenir. Bu, Türkçe gömme kalitesinin İngilizce'ye göre sistematik olarak daha düşük olabileceği anlamına gelir — ama her model için aynı ölçüde değil. İşte embedding modeli seçimini kritik yapan da bu değişkenliktir.

Türkçe'nin ilk zorluğu morfolojidir. "Ev", "evler", "evimde", "evlerimizden" gibi biçimler aynı kökten türer ama yüzeyde çok farklı görünür. İyi bir embedding modeli bu biçimleri anlamca birbirine yakın konumlandırmalıdır; zayıf bir model ise onları uzak görebilir ve "evimde" araması "evler" içeren belgeyi kaçırabilir. İngilizce'de bu sorun çok daha hafiftir çünkü çekim sistemi görece basittir. Dolayısıyla bir modelin İngilizce'deki başarısı, Türkçe'deki başarısını garanti etmez.

İkinci zorluk, alana özgü Türkçe terminolojidir. Hukuk, sağlık, bankacılık ve mühendislik gibi alanlar, kendi Türkçe jargonlarına sahiptir ve bu jargon genel web metinlerinde seyrek geçer. Bir embedding modeli bu terimleri eğitim verisinde az gördüyse, onların anlamını zayıf temsil eder. Üçüncü zorluk, kod-değiştirme (Türkçe metinde İngilizce teknik terimlerin serpiştirilmesi) ve Türkçe'ye özgü karakterlerin (ı, İ, ğ, ş, ç, ö, ü) tutarlı işlenmesidir. Bu üç zorluk bir araya geldiğinde, Türkçe içerikte embedding modeli seçimi "İngilizce'de iyi olanı al" kolaycılığına asla indirgenemez; kendi Türkçe verinizle doğrulama şarttır. Doğal dilin makine tarafında nasıl işlendiğini doğal dil işleme nedir yazısında bulabilirsiniz.

Türkçe için embedding modeli seçiminin en sık sorulan sorusu budur: güçlü bir çok dilli model yeterli mi, yoksa Türkçeye özel bir model şart mı? Kısa cevap, "çoğu zaman çok dilli model yeterlidir ama bu bir varsayım değil, bir ölçüm sonucudur" şeklindedir. İki seçeneğin de gerçek artıları ve eksileri vardır ve doğru karar, senaryonuza ve verinize bağlıdır.

Çok dilli model, tek bir modelle onlarca dili kapsayan, geniş eğitim verisiyle beslenmiş genel amaçlı bir çözümdür. Avantajları operasyoneldir: tek model bakımı, birden çok dildeki içeriği (örneğin hem Türkçe hem İngilizce belgeler) aynı vektör uzayında tutabilme, geniş ekosistem ve araç desteği, ve genellikle olgun dokümantasyon. Bir kurumun belgeleri birden çok dilde ise, çok dilli model doğal bir tercihtir çünkü Türkçe bir soru İngilizce bir belgeyi de bulabilir. Çok dilli cümle gömme yaklaşımının mantığını çok dilli cümle embeddingleri yazısında ele alıyoruz.

Türkçeye özel (veya Türkçe'de belirgin biçimde güçlü) bir model ise, eğitim ağırlığını Türkçe'ye vererek morfolojik nüansı, deyimsel dili ve yerel terminolojiyi daha iyi yakalayabilir. Avantajı isabet, dezavantajı kapsam ve operasyondur: yalnızca Türkçe'ye odaklıysa çok dilli senaryoda işe yaramaz, ekosistem desteği daha dar olabilir ve bakımı ayrı bir yük getirebilir. Buradaki kritik nokta şudur: Türkçeye özel bir modelin daha iyi olacağını peşinen varsaymak yanlıştır. Bazen çok dilli model Türkçe'de zaten çok iyidir ve fark, değiştirme maliyetine değmez; bazen Türkçeye özel model isabeti gözle görülür artırır. Bu yüzden embedding modeli seçimi her iki adayı kendi Türkçe verinizle yan yana koymayı gerektirir.

Çok dilli model ile Türkçeye özel model: artı ve eksiler

Boyut	Çok dilli model	Türkçeye özel model
Kapsam	Çok dilli içerik tek uzayda	Genellikle yalnızca Türkçe
Türkçe nüans	İyi–çok iyi (modele göre)	Potansiyel olarak en iyi
Operasyon	Tek model, kolay bakım	Ek model/altyapı yükü
Ekosistem	Geniş, olgun	Daha dar olabilir
En iyi kullanım	Çok dilli/karışık bilgi tabanı	Yoğun Türkçe nüans/alan dili

Pratik öneri şudur: çoğu kurumsal proje için güçlü bir çok dilli modelle başlayın (daha kolay, daha esnek), ama kararı vermeden önce en az bir Türkçeye özel/Türkçede güçlü modeli aynı değerlendirme setinde test edin. Fark anlamlıysa ve senaryonuz Türkçe-ağırlıklıysa özel modele geçin; fark küçükse çok dilli modelde kalın. Bu, hem isabeti hem operasyonel sadeliği dengeleyen bir karardır.

Embedding modeli seçimi tek bir sayıya (örneğin bir benchmark puanına) indirgenemez; birbiriyle yarışan birkaç kriterin dengelenmesidir. Aşağıdaki tablo, her kriterin neden önemli olduğunu ve onu nasıl test edeceğinizi bir arada gösterir. Bu tablo, "rastgele bir model seçtim" ile "kanıta dayalı karar verdim" arasındaki farkı somutlaştırır ve GEO açısından bu yazının çekirdek karşılaştırmasıdır.

Embedding modeli seçim kriterleri: kriter × neden önemli × test yöntemi

Kriter	Neden önemli	Nasıl test edilir
Getirme isabeti (Türkçe)	Doğru belge gelmezse sistem çöker	Türkçe değerlendirme setinde recall@k, MRR
Alan uyumu (domain fit)	Sektör dili genel dilden farklı	Kendi alan sorularınla ölç
Boyut ve performans	Depolama, gecikme, maliyet etkisi	Farklı boyutları eşit isabette karşılaştır
Gecikme (latency)	Kullanıcı deneyimi ve maliyet	Sorgu başına vektörleme süresini ölç
Maliyet	İndeksleme + sorgu bütçesi	1M token/1M vektör maliyetini hesapla
Lisans ve gizlilik	KVKK, veri egemenliği	API mi self-host mu; veri nereye gidiyor
Bağlam uzunluğu	Uzun chunk'ları temsil edebilme	Maksimum token sınırını chunk boyutuyla eşle
Değiştirilebilirlik	İleride geçiş kolaylığı	Standart arayüz, versiyon kaydı

Bu kriterlerin hiçbiri tek başına belirleyici değildir. Örneğin en yüksek getirme isabetine sahip model, gecikme veya maliyet açısından bütçenizi aşıyorsa doğru seçim olmayabilir; ya da benchmark'ta ortalama görünen bir model, sizin alan dilinizde en iyisi olabilir. Embedding modeli seçimi, bu kriterleri kendi önceliklerinize göre ağırlıklandırıp dengeli bir karar vermektir. Bir hukuk asistanında isabet her şeyin önündeyken, yüksek hacimli bir müşteri destek botunda gecikme ve maliyet öne çıkabilir. Değerlendirme disiplininin genel çerçevesini LLM değerlendirme nedir yazısında bulabilirsiniz.

Embedding modeli seçiminde en çok yanlış anlaşılan kriter boyuttur. Bir embedding vektörünün boyutu (örneğin 384, 768, 1024, 1536 veya daha yüksek), o vektörün kaç sayıdan oluştuğunu belirtir. Sezgisel beklenti "daha yüksek boyut = daha iyi kalite"dir, ama bu yanıltıcıdır. Boyut ve performans arasındaki ilişki doğrusal değildir; belirli bir noktadan sonra boyut artışı, getirme isabetine çok az katkı verirken maliyeti ve gecikmeyi belirgin biçimde artırır.

Yüksek boyutun bedelini net görelim. Her ek boyut; her vektör için daha fazla depolama, vektör veritabanında daha büyük bir indeks, daha fazla bellek kullanımı ve arama sırasında daha fazla hesaplama demektir. Milyonlarca parçalık bir bilgi tabanında, vektör boyutunu iki katına çıkarmak depolama ve arama maliyetini kabaca iki katına çıkarabilir. Buna karşılık, gömme kalitesindeki kazanç genellikle çok daha mütevazıdır ve hızla azalan getiri gösterir. Yani "en büyük boyutu seç" stratejisi, çoğu zaman bütçeyi boşa harcar.

Modern embedding modellerinin bir kısmı, bu dengeyi yönetmek için esnek boyut (Matryoshka tarzı gömme öğrenimi) sunar: model yüksek boyutlu bir vektör üretir, ama siz bu vektörü kaliteyi çok az kaybederek daha düşük bir boyuta kısaltabilirsiniz. Bu, boyut ve performans dengesini bütçenize göre ayarlamanızı sağlar — örneğin arama hızının kritik olduğu bir senaryoda düşük boyut, isabetin kritik olduğu bir senaryoda yüksek boyut kullanabilirsiniz. Vektör normalizasyonu ve boyutun arama üzerindeki etkisini derinleştirmek için vektör yazısı temel sağlar.

Embedding boyutu seçiminde tipik ödünleşimler

Boyut aralığı	Tipik avantaj	Tipik bedel	Uygun senaryo
Düşük (ör. 256–384)	Hızlı arama, düşük depolama	Nüansta olası kayıp	Yüksek hacim, düşük gecikme
Orta (ör. 768–1024)	İyi denge	Makul maliyet	Çoğu kurumsal RAG
Yüksek (ör. 1536+)	Potansiyel en yüksek isabet	Yüksek depolama/gecikme	İsabetin kritik olduğu dar alan

Doğru yaklaşım, boyutu bir "ne kadar çoksa o kadar iyi" değişkeni değil, bir tasarım parametresi olarak görmektir. Aday modellerinizi farklı boyutlarda test edin; getirme isabetindeki gerçek kazancı, maliyet ve gecikme artışıyla yan yana koyun. Çoğu kurumsal senaryoda orta boyutlu bir model en iyi dengeyi verir. Unutmayın: kullanıcı, vektörünüzün 1536 boyutlu olduğunu değil, doğru cevabı hızlı aldığını umursar.

Embedding modeli seçimi genellikle bir benchmark tablosuna bakmakla başlar ve maalesef çoğu zaman orada da biter. MTEB (Massive Text Embedding Benchmark) gibi kapsamlı karşılaştırmalar, embedding modellerini çok sayıda görev (getirme, sınıflandırma, kümeleme, yeniden sıralama, benzerlik) ve veri kümesinde ölçer ve bir sıralama sunar. Bu değerlidir — ama nasıl okunacağı bilinmezse yanıltıcıdır. Benchmark'ları okuma becerisini benchmark okuma rehberi yazısında ayrıntılı ele alıyoruz; burada embedding'e özgü tuzaklara odaklanalım.

Birinci tuzak, dil yanlılığıdır. Popüler embedding benchmark'larının önemli bir kısmı İngilizce-ağırlıklıdır; ortalama skor, İngilizce görevlerin başarısını yansıtır ve Türkçe performansı hakkında az şey söyler. Bir model genel sıralamada üstte olabilir ama Türkçe getirmede vasat kalabilir. Bu yüzden mümkünse benchmark'ın çok dilli veya Türkçe alt kümesine, tek bir ortalama yerine, ilgili görevin skoruna bakın.

İkinci tuzak, görev uyumsuzluğudur. Bir model sınıflandırmada mükemmel ama getirmede (retrieval) ortalama olabilir. RAG için önemli olan getirme skorudur; kümeleme veya benzerlik skoru sizi yanıltabilir. Üçüncü tuzak, veri sızıntısı ve aşırı uyumdur: modeller bazen benchmark veri kümelerine benzer veriyle eğitilmiş olabilir, bu da skoru gerçekte olduğundan yüksek gösterir. Dördüncü tuzak, ortalamanın yanıltıcılığıdır: tek bir ortalama puan, sizin senaryonuza hiç benzemeyen görevlerin etkisini taşır. Benchmark'ın genel mantığını benchmark yazısında da ele alıyoruz.

Embedding modeli seçiminde çoğu ekibin gözden kaçırdığı en belirleyici kriter alan uyumudur. Bir modelin genel bir benchmark'taki ortalama başarısı ile sizin özel alanınızdaki (hukuk sözleşmeleri, tıbbi raporlar, banka mevzuatı, mühendislik şartnameleri) başarısı çok farklı olabilir. Çünkü alan dili, genel web dilinden sözcük dağarcığı, kalıp ve anlam yapısı bakımından ayrışır; ve model bu alanı eğitim verisinde ne kadar gördüyse, o alanın gömme kalitesi o kadar yüksek olur.

Bunu somutlaştıralım. Genel bir modele göre "temlik", "muvazaa" veya "zamanaşımı" gibi hukuk terimleri seyrek kelimelerdir; model bunların ince anlam ayrımlarını zayıf temsil edebilir. Oysa hukuk metinleriyle bolca karşılaşmış bir model, bu terimleri ve aralarındaki ilişkileri çok daha isabetli konumlandırır. Aynı durum tıp, finans ve mühendislik için de geçerlidir. Dolayısıyla "genel olarak en iyi model" ile "benim alanımda en iyi model" çoğu zaman aynı değildir. Alan-özel embedding yaklaşımının mantığını alana özgü embeddingler yazısında ele alıyoruz.

Alan uyumunu test etmek basittir ama atlanır: değerlendirme setinizi genel sorulardan değil, kendi alanınızın gerçek sorularından oluşturun. Eğer değerlendirme setiniz "hava durumu nedir" gibi genel sorulardan oluşuyorsa, hukuk alanındaki performansı hiç ölçmemiş olursunuz. Kendi alan sorularınızla ölçtüğünüzde, benchmark'ta parlayan bir modelin sizin jargonunuzda tökezlediğini veya tersine, ortalama bir modelin sizin alanınızda mükemmel olduğunu görebilirsiniz. Bu yüzden embedding modeli seçiminde altın kural şudur: modeli sizin işinizin diliyle test edin, genel bir sınavla değil.

Embedding modeli seçiminin kalbi budur: kendi verinizle bir değerlendirme (evaluation) seti kurmak. Bu, tahmini kanıta çeviren tek yoldur ve göründüğünden çok daha erişilebilirdir. Amaç, aday modelleri aynı Türkçe verinizde adil biçimde karşılaştırıp hangisinin doğru belgeyi daha sık ve daha üstte getirdiğini ölçmektir. Aşağıdaki adımlar bunu tekrarlanabilir bir sürece dönüştürür.

Nasıl Yapılır

Türkçe embedding değerlendirme seti kurma

Aday embedding modellerini kendi Türkçe verinizle adil biçimde karşılaştırmak için adım adım kurulum.

1. 1

   Temsili soru kümesi topla

   Gerçek kullanıcı sorularından (destek kayıtları, arama logları) 50–200 temsili Türkçe soru seçin; alanınızın çeşitliliğini yansıtsın.

2. 2

   Altın küme (ground truth) işaretle

   Her soru için doğru cevabı içeren belge parçasını/parçalarını elle işaretleyin; bu, isabetin ölçüleceği referanstır.

3. 3

   Değişkenleri sabitle

   Chunking, ön işleme ve sorgu biçimini tüm adaylar için aynı tutun; yalnızca embedding modelini değiştirin ki fark modelden gelsin.

4. 4

   Her adayı indeksle ve sorgula

   Aday modellerle aynı belgeleri vektörleyip aynı soruları sorgulayın; her soru için ilk k sonucu kaydedin.

5. 5

   Metriklerle ölç

   recall@k, MRR ve nDCG hesaplayın; doğru parça getirildi mi ve kaçıncı sırada geldi bakın.

6. 6

   Maliyet ve gecikmeyi ekle

   İsabetin yanına sorgu gecikmesi ve maliyet sütununu koyun; kararı tek boyutta vermeyin.

7. 7

   Karar ver ve versiyonla

   Kazanan modeli seçin, seçim gerekçesini ve setin sürümünü kaydedin; her model değişiminde aynı seti tekrar çalıştırın.

Bu sürecin en zor ama en değerli adımı, altın kümenin işaretlenmesidir. Doğru cevabı içeren parçayı her soru için insan eliyle belirlemek emek ister; ama bir kez kurulduğunda, her model değişikliğinde otomatik olarak tekrar çalıştırılabilen kalıcı bir varlık olur. Küçük bir set (50-100 iyi seçilmiş soru) bile, hiç ölçmemekten kıyaslanamayacak kadar iyidir. Zamanla seti büyütür ve gerçek kullanıcı sorularıyla zenginleştirirsiniz.

Bir uyarı: değerlendirme setini yalnızca kolay sorulardan oluşturmayın. Gerçek gücü, zor, belirsiz ve nadir sorularda görürsünüz — çünkü modeller kolay sorularda benzer performans gösterir, asıl ayrışma zor sorularda olur. Ayrıca değerlendirmeyi yalnızca embedding için değil, tüm getirme hattı (chunking, hybrid search, reranking) için de kullanabilirsiniz; bu, hangi katmanın kaliteyi sınırladığını gösterir. Hibrit aramanın embedding ile nasıl birleştiğini hibrit arama ve RAG yazısında ele alıyoruz.

Embedding modeli seçimini sayısallaştıran metrikleri anlamak, doğru kararın vazgeçilmez parçasıdır. Getirme kalitesini ölçen üç temel metrik vardır ve her biri farklı bir soruya cevap verir. Bunları anlamadan bir benchmark tablosunu veya kendi ölçümünüzü doğru yorumlayamazsınız.

Recall@k (ilk k'da geri çağırma), "doğru belge, getirilen ilk k sonuç içinde var mı?" sorusuna cevap verir. Örneğin recall@5 = 0.9 ise, soruların yüzde 90'ında doğru parça ilk beş sonuç arasında gelmiştir. Bu metrik RAG için özellikle önemlidir çünkü reranker ve model, yalnızca getirilen ilk k parça üzerinde çalışır; doğru parça ilk k'ya girmezse sonraki adımlar onu kurtaramaz. Yüksek recall, iyi bir embedding modeli seçiminin ilk işaretidir.

MRR (Mean Reciprocal Rank / Ortalama Karşılıklı Sıra), doğru belgenin ortalama olarak kaçıncı sırada geldiğini ölçer; ilk sırada gelmesini ödüllendirir. Doğru parça hep birinci sıradaysa MRR 1'e yaklaşır; hep aşağılardaysa MRR düşer. Bu, sıralama kalitesini yakalar — recall doğru parçanın "geldi mi" sorusuna, MRR "ne kadar üstte geldi" sorusuna cevap verir. nDCG (normalized Discounted Cumulative Gain) ise birden çok ilgili belge olduğunda ve sıralama önemliyken, hem ilgililiği hem konumu birlikte tartan daha zengin bir metriktir. Benzerlik ve mesafe metriklerinin bu ölçümlerle ilişkisini semantik arama nedir yazısında bulabilirsiniz.

Getirme metrikleri: ne ölçer, ne zaman öne çıkar

Metrik	Cevapladığı soru	RAG'de önemi
Recall@k	Doğru parça ilk k'da mı?	Kritik: k'ya girmeyen kaybolur
MRR	Doğru parça kaçıncı sırada?	Sıralama kalitesi, dikkat yönetimi
nDCG	İlgililik + konum birlikte	Çok ilgili belgeli durumlar
Gecikme	Sorgu ne kadar sürüyor?	Deneyim ve maliyet dengesi

Pratikte embedding modeli seçimi için recall@k ve MRR birlikte bakılır: recall doğru parçanın hiç gelip gelmediğini, MRR ne kadar üstte geldiğini söyler. İkisi de yüksekse model hem kapsayıcı hem isabetlidir. Bu metrikleri kendi Türkçe değerlendirme setinizde hesaplayınca, "hangi model daha iyi" tartışması bir görüş çatışması olmaktan çıkıp bir sayı karşılaştırmasına dönüşür — ve karar netleşir.

Gömme kalitesi soyut bir kavram gibi görünse de, embedding modeli seçiminde onu somut biçimde ölçmenin yolları vardır ve bu incelikleri bilmek yanlış kararları önler. Gömme kalitesi, en yalın haliyle, "anlamca ilgili metinlerin vektör uzayında birbirine yakın, ilgisizlerin uzak konumlanma" başarısıdır. Ama bu başarıyı ölçerken sık düşülen tuzaklar vardır.

İlk incelik, simetrik ve asimetrik arama ayrımıdır. Bazı senaryolarda karşılaştırılan iki metin benzer türdedir (cümle-cümle benzerliği: simetrik); RAG'de ise genellikle kısa bir soru ile uzun bir belge parçası eşleştirilir (soru-belge: asimetrik). Bir model simetrik görevde parlayıp asimetrik getirmede zayıf kalabilir. Bu yüzden gömme kalitesini, sizin gerçek kullanımınıza — yani soru-belge eşleşmesine — benzer biçimde ölçmelisiniz; cümle benzerliği skoruna bakıp RAG kararı vermek yanıltıcıdır.

İkinci incelik, talimatlı (instruction-tuned) embedding modelleridir. Bazı modeller, sorguyu ve belgeyi vektörlerken önlerine kısa bir talimat (örneğin "bu bir arama sorgusudur") eklemeyi bekler; bu talimat verilmezse gömme kalitesi düşebilir. Modeli yanlış kullanmak, iyi bir modeli kötü göstermek demektir. Üçüncü incelik, normalizasyon ve mesafe metriğidir: vektörler normalize edildi mi, benzerlik kosinüs mü nokta çarpım mı ile ölçülüyor — bunlar tutarsızsa gömme kalitesi ölçümü bozulur. Kosinüs benzerliği ve normalizasyonun ayrıntısını vektör yazısında ele alıyoruz.

Embedding modeli seçimi yalnızca modeli değil, o modelin vektör veritabanı ve indeksle nasıl etkileşeceğini de kapsar. Bir model harika vektörler üretse bile, yanlış mesafe metriği veya uyumsuz bir indeks yapılandırmasıyla getirme kalitesi düşebilir. Bu yüzden model kararı, altyapı kararından bağımsız düşünülemez.

İlk konu mesafe metriğidir. Embedding'ler arasındaki "yakınlık" genellikle kosinüs benzerliği, nokta çarpımı veya Öklid mesafesiyle ölçülür. Model üreticisi hangi metriği önerdiyse onu kullanmak önemlidir; çünkü model o metriğe göre eğitilmiştir. Kosinüs için genellikle vektörlerin normalize edilmesi gerekir; normalize edilmemiş vektörlerle kosinüs beklendiği gibi çalışmaz. Yanlış metrik seçimi, iyi bir embedding modeli seçimini bile boşa çıkarabilir.

İkinci konu, yaklaşık en yakın komşu (ANN) indeksleriyle etkileşimdir. Büyük ölçekte vektör veritabanları, hız için kesin arama yerine yaklaşık arama (örneğin HNSW indeks) kullanır. Bu, küçük bir isabet kaybı karşılığında büyük bir hız kazancı sunar; ama indeks parametreleri kötü ayarlanırsa, iyi bir modelin isabeti indeks katmanında erir. Dolayısıyla embedding modelini test ederken, üretimde kullanacağınız indeks yapılandırmasıyla test etmek önemlidir; kesin aramayla mükemmel görünen bir model, gevşek bir ANN ayarıyla vasatlaşabilir. Vektör veritabanının bu rolünü vektör veritabanı nedir yazısında ele alıyoruz.

Üçüncü konu boyut-indeks etkileşimidir: daha yüksek boyut, indeksin bellek ayak izini ve arama süresini artırır. Bu, boyut ve performans dengesini yeniden gündeme getirir — model, boyut ve indeks üçlüsü birlikte tasarlanmalıdır. Özetle, embedding modeli seçimini bir vakumda değil, gerçek altyapı bağlamında yapın; model, metrik ve indeks bir ekip olarak çalışır.

Embedding modeli seçimini "geri dönülebilir bir deneme" gibi görmek tehlikeli bir hatadır; çünkü modeli sonradan değiştirmek pahalı ve emek yoğun bir operasyondur. Bunun nedeni temel bir gerçektir: farklı embedding modelleri birbiriyle uyumsuz vektör uzayları üretir. Bir modelin ürettiği vektör, başka bir modelin vektörüyle aynı uzayda değildir; dolayısıyla modeli değiştirdiğinizde eski vektörler işe yaramaz hale gelir.

Bunun pratik sonucu şudur: embedding modelini değiştirmek, tüm belge tabanını yeni modelle baştan vektörlemek (re-embed) demektir. Milyonlarca parçalık bir bilgi tabanında bu; ciddi bir hesaplama maliyeti, uzun bir yeniden indeksleme süresi ve dikkatli bir kesintisiz geçiş planı gerektirir. Ayrıca sorgu tarafı da yeni modele geçmelidir; soru eski modelle, belgeler yeni modelle vektörlenirse, ikisi aynı uzayda olmadığı için getirme tamamen bozulur. Bu asimetri, sinsi ve fark edilmesi zor bir hatadır.

Bu maliyet, embedding modeli seçimini baştan ciddiye almanın en güçlü gerekçesidir — ama aynı zamanda versiyonlama disiplinini de zorunlu kılar. Her belgenin hangi model ve hangi model sürümüyle vektörlendiğini kaydetmek (embedding versiyonlama), ileride bir geçiş gerektiğinde hangi vektörlerin yenilenmesi gerektiğini bilmenizi sağlar. Ayrıca kademeli geçiş (eski ve yeni indeksi bir süre paralel çalıştırıp karşılaştırma) riski azaltır. Embedding sürüm yönetiminin önemini, kurumsal RAG mimarisini ele aldığımız kurumsal RAG rehberi yazısında da vurguluyoruz.

Embedding modeli seçimi, teknik isabetin ötesinde bir dağıtım (deployment) kararını da içerir: modeli bir sağlayıcının API'si üzerinden mi çağıracaksınız, yoksa kendi altyapınızda mı (self-host) çalıştıracaksınız? Bu karar; maliyeti, gecikmeyi, ölçeklenebilirliği ve en önemlisi Türkiye bağlamında KVKK ve veri egemenliğini doğrudan etkiler.

API tabanlı embedding, operasyonel basitlik sunar: altyapı yönetmez, ölçeklemeyi sağlayıcıya bırakır, genellikle güçlü ve güncel modellere erişirsiniz. Bedeli, verinizin sağlayıcıya gönderilmesi ve token/çağrı başına ücrettir. Yüksek hacimde bu ücret birikir; ayrıca kişisel veya gizli belgeleri dış bir servise göndermek, KVKK ve gizlilik açısından değerlendirilmesi gereken bir konudur. Self-host embedding ise veriyi kendi sınırlarınızda tutar (veri egemenliği), yüksek hacimde birim maliyeti düşürebilir ve gecikmeyi kontrol etmenizi sağlar; bedeli, altyapı kurulumu, model bakımı ve donanım (GPU) yatırımıdır.

Türkiye'de kişisel veri içeren kurumsal belgelerle çalışıyorsanız, bu karar teknik olduğu kadar hukukidir. Verinin nereye gittiği, nerede işlendiği ve nerede saklandığı; KVKK uyumunun merkezindedir. Açık kaynak bir embedding modelini kendi altyapınızda çalıştırma seçeneği, bu açıdan giderek daha cazip hale gelir. Kararın teknik boyutunu değerlendirdiğiniz kadar hukuki boyutunu da kurumunuzun hukuk/uyum birimiyle birlikte ele almanız gerekir; bu, hukuki tavsiye değil, mimari bir hatırlatmadır.

Embedding: API ile self-host karşılaştırması

Boyut	API tabanlı	Self-host
Kurulum	Anında, altyapısız	Kurulum ve bakım gerekir
Birim maliyet (yüksek hacim)	Çağrı başına birikir	Ölçekte düşebilir
Veri gizliliği/KVKK	Veri dışarı gider	Veri içeride kalır
Gecikme kontrolü	Sağlayıcıya bağlı	Tam kontrol
En uygun	Hızlı başlangıç, düşük hacim	Gizli veri, yüksek hacim

Deneyimli bir gözle bakıldığında, Türkçe RAG projelerinde embedding modeli seçimi benzer hatalarla yanlış yapılır. Bu hataları önceden bilmek, aylarca sürecek bir yanlıştan kurtarabilir. En yaygın olanları şöyle sıralanabilir:

• Sadece benchmark sıralamasına bakmak: "MTEB'de birinci olan modeli aldım" demek, kendi Türkçe verinizi hiç ölçmemek demektir. Benchmark eler, karar vermez.
• İngilizce başarısını Türkçe'ye taşımak: Bir modelin İngilizce'de iyi olması, Türkçe morfolojiyi iyi yakaladığı anlamına gelmez. Türkçe içerikte kanıt kendi verinizden gelmelidir.
• En yüksek boyutu seçmek: Boyut ve performans dengesini gözetmeden en büyük vektörü seçmek, maliyeti şişirir ve isabete çoğu zaman az katkı verir.
• Alan uyumunu atlamak: Genel sorularla test edip alan dilini (hukuk, tıp, finans) hiç ölçmemek, üretimde büyük sürprizlere yol açar.
• Modeli yanlış kullanmak: Talimat öneki, normalizasyon veya mesafe metriğini yanlış ayarlayıp iyi bir modeli kötü göstermek. Adil karşılaştırma her modeli kendi en iyi ayarında çalıştırmayı gerektirir.
• Değiştirme maliyetini hafife almak: Modeli "sonra değiştiririm" diye düşünüp versiyonlama kurmamak; ileride tüm tabanı yeniden vektörlemek gerektiğinde büyük acı doğurur.
• Simetrik skora bakıp asimetrik karar vermek: Cümle benzerliği skoruna bakıp soru-belge getirme kararı vermek; RAG'de asimetrik getirme ölçülmelidir.
• Reranker'ın her şeyi düzelteceğini sanmak: Zayıf embedding'i güçlü reranker'la telafi etmeye çalışmak; reranker getirilmeyeni kurtaramaz.

Şimdi tüm kriterleri tek bir karar çerçevesinde toplayalım. Embedding modeli seçimi, senaryonuzun önceliklerine göre farklı sonuçlar verir; aşağıdaki rehber, tipik durumlar için başlangıç yönü sunar. Bu bir reçete değil, bir düşünme haritasıdır; nihai kararı yine kendi değerlendirme setinizle verirsiniz.

Önce senaryonuzu sınıflandırın. Belgeleriniz tek dilde (Türkçe) mi, çok dilli mi? Alanınız genel mi, yoğun jargonlu mu (hukuk, tıp, finans)? Önceliğiniz isabet mi, gecikme mi, maliyet mi? Verileriniz gizli mi (KVKK), yoksa kamuya açık mı? Bu dört soruya verdiğiniz cevaplar, embedding modeli seçimini büyük ölçüde yönlendirir. Örneğin gizli hukuk belgeleriyle çalışan, isabet öncelikli bir kurum ile çok dilli, yüksek hacimli, gecikme öncelikli bir müşteri destek uygulaması çok farklı tercihler yapar.

Senaryoya göre embedding modeli seçimi başlangıç yönü

Senaryo	Öncelik	Başlangıç yönü
Çok dilli kurumsal bilgi tabanı	Kapsam + esneklik	Güçlü çok dilli model, orta boyut
Yoğun Türkçe, alan yoğun (hukuk/tıp)	İsabet + alan uyumu	Türkçede güçlü/alan modeli, kendi setinle doğrula
Yüksek hacimli müşteri destek	Gecikme + maliyet	Düşük-orta boyut, hızlı model, cache
Gizli veri (KVKK)	Veri egemenliği	Self-host açık kaynak model
Küçük pilot / hızlı başlangıç	Hız + basitlik	API tabanlı çok dilli model

Bu rehberdeki "başlangıç yönü" ifadesine dikkat edin: hiçbiri kesin bir reçete değildir. Doğru embedding modeli seçimi, bu yönle başlamak, iki-üç adayı kendi Türkçe değerlendirme setinizde karşılaştırmak ve kazananı kanıtla seçmektir. Süreç şöyle özetlenebilir: senaryoyu sınıflandır → benchmark ile aday listesi çıkar → kendi verinde recall@k ve MRR ölç → maliyet ve gecikmeyi ekle → kazananı seç ve versiyonla. Bu disiplin, embedding modeli seçimini bir tahmin oyunundan bir mühendislik kararına dönüştürür.

Embedding modeli seçimini soyutlaştırmadan somut bir örnekle görelim. Varsayalım ki bir hukuk departmanı, binlerce Türkçe sözleşme ve mevzuat belgesi üzerinde soru-cevap yapan bir RAG asistanı kuruyor. Ekip başlangıçta "genel olarak en iyi model" diye bilinen güçlü bir çok dilli modeli seçiyor ve pilotu kuruyor. İlk testlerde sistem makul görünüyor — ama gerçek hukukçu sorularıyla denendiğinde, "temlik yasağı hangi maddede düzenlenmiş" gibi alan yoğun sorularda doğru maddeyi sık sık kaçırıyor.

Ekip burada doğru olanı yapıyor: bir değerlendirme seti kuruyor. 120 gerçek hukukçu sorusu topluyor, her soru için doğru cevabı içeren sözleşme maddesini altın küme olarak işaretliyor. Sonra üç adayı — mevcut çok dilli modeli, Türkçede güçlü bir ikinci modeli ve mümkünse hukuk/resmi metne yakın bir üçüncüyü — aynı belgeler ve aynı sorularla test ediyor. recall@5 ve MRR ölçüyor. Sonuç çarpıcı: mevcut çok dilli modelin recall@5'i vasat çıkarken, Türkçede güçlü model aynı sorularda doğru maddeyi belirgin biçimde daha sık ve daha üstte getiriyor. Alan uyumu, genel benchmark sıralamasının vaat ettiğinden farklı bir tablo çiziyor.

Ekip ayrıca boyut ve performans dengesini test ediyor: Türkçede güçlü modelin yüksek ve orta boyutlu sürümlerini karşılaştırıyor ve orta boyutun, isabette neredeyse aynı sonucu çok daha düşük depolama ve gecikmeyle verdiğini görüyor. Gizlilik gereği (sözleşmeler ticari sır içeriyor) modeli kendi altyapılarında self-host çalıştırmaya karar veriyorlar. Son olarak, her belgeyi hangi modelle vektörlediklerini kaydediyorlar ki ileride bir yükseltme gerektiğinde geçiş kontrollü olsun. Bu vaka, embedding modeli seçiminin neden tek bir sıralamaya değil, kendi verinizle kurulan bir sürece dayanması gerektiğini özetler: kararı ölçüm verdi, tahmin değil. Böyle bir hukuk asistanı için reranking katmanının önemini cross-encoder reranking ve reranker nedir yazılarında ele alıyoruz.

Embedding modeli seçimi kritik olsa da, tek başına bir RAG sisteminin kaderini belirlemez; getirme hattının bir parçasıdır ve diğer bileşenlerle birlikte çalışır. Doğru bir bakış açısı, embedding'i chunking, hybrid search ve reranking ile birlikte, bir sistem olarak düşünmektir. Aksi halde, tek bir bileşeni mükemmelleştirip diğerlerini ihmal etme tuzağına düşülür.

Chunking, embedding'in üzerinde çalıştığı parçaları belirler; kötü bir chunking, en iyi embedding modelini bile boğar çünkü model, anlamı kopmuş bir parçayı doğru temsil edemez. Bu yüzden embedding modeli seçimini, chunking stratejinizle birlikte değerlendirmek gerekir. Chunking yaklaşımlarını chunking stratejileri yazısında ele alıyoruz. Hybrid search ise embedding'in zayıf olduğu yeri — tam eşleşme gereken kod, isim, madde numarası — klasik anahtar kelime aramasıyla kapatır; Türkçe'nin morfolojik zenginliğinde bu birleşim özellikle değerlidir.

Reranking, embedding'in getirdiği adayları temizleyerek son bağlamı iyileştirir; ama daha önce vurguladığımız gibi, getirilmeyeni kurtaramaz. Dolayısıyla sağlam bir hat şöyle kurulur: iyi chunking + doğru embedding modeli seçimi + gerekiyorsa hybrid search + reranking + sürekli değerlendirme. Bu bileşenlerin her biri kendi kaldıracıdır; ama embedding, ilk elemeyi yaptığı için tavanı koyar. Bu yüzden embedding modeli seçimine yatırım yapmak, tüm hattın potansiyelini yükseltir. Hibrit yaklaşımın bütününü hibrit arama ve RAG yazısında bulabilirsiniz; kurumsal RAG tasarımının tümünü ise RAG nedir rehberinde ele alıyoruz.

Bu bütünsel bakışın pratik sonucu şudur: embedding modeli seçimini bir kez yapıp unutulacak bir kutu işareti gibi değil, getirme kalitesi ölçüldükçe gözden geçirilen bir karar gibi görün. Değerlendirme setiniz büyüdükçe, alan diliniz genişledikçe veya yeni ve daha iyi modeller çıktıkça, bu kararı yeniden ele almak doğaldır. Önemli olan, her seferinde tahminle değil, kendi verinizle ölçerek karar vermektir.

Embedding modeli seçiminde sık atlanan ama sessizce belirleyici bir teknik kriter, modelin desteklediği maksimum bağlam uzunluğudur — yani tek seferde kaç token'lık metni vektöre çevirebildiği. Her embedding modelinin bir üst sınırı vardır; bu sınır aşılırsa metin ya kırpılır ya da hata verir. Bu yüzden embedding modeli seçimi, chunking stratejinizle uyumlu düşünülmelidir: modelin bağlam sınırı, parça boyutunuzla eşleşmiyorsa ya bilgi kaybedersiniz ya da kapasiteyi boşa harcarsınız.

Sorun şudur: bir model 512 token'lık bir sınıra sahipse ve siz 1000 token'lık parçalar üretirseniz, modelin gördüğü her parçanın ilk yarısıdır; ikinci yarı sessizce yok sayılır ve o bilgi asla getirilemez. Tersine, model 8000 token destekliyorken siz 200 token'lık minik parçalar üretirseniz, anlam bütünlüğünü koparır ve modele bağlamı zenginleştirme fırsatı vermezsiniz. Doğru yaklaşım, parça boyutunu modelin bağlam penceresiyle bilinçli biçimde hizalamaktır. Bağlam penceresi kavramını context window nedir ve parçalamayı chunking nedir yazılarında ele alıyoruz.

Bir başka incelik, uzun parçaların "anlam ortalaması" tuzağıdır. Çok uzun bir metni tek bir vektöre sıkıştıran model, o metnin farklı alt konularını tek bir ortalama noktaya bastırır; sonuçta ne bu konuya ne şu konuya tam yakın, "arada" bir vektör çıkar. Bu, uzun parçalarda gömme kalitesini düşürür. Türkçe metinlerde cümlelerin uzunluğu ve bağlaçlı yapısı bu etkiyi artırabilir; bu yüzden Türkçe içerikte parça boyutunu modelin sınırına dayamak yerine, anlam yoğunluğuna göre ayarlamak daha güvenlidir. Özetle, embedding modeli seçimi ile chunking birlikte tasarlanan bir ikilidir; birini diğerinden bağımsız optimize etmek yanıltıcı sonuç verir.

Birçok Türk kurumunun bilgi tabanı tek dilli değildir: teknik dokümantasyon, tedarikçi sözleşmeleri veya uluslararası raporlar İngilizce, iç prosedürler ve destek kayıtları Türkçe olabilir. Bu karışık senaryoda embedding modeli seçimi, çapraz dil getirme (cross-lingual retrieval) yeteneğini de kapsamalıdır: Türkçe sorulan bir soru, İngilizce bir belgeyi bulabilmeli. Bu, yalnızca güçlü çok dilli modellerin iyi yaptığı bir iştir.

Çapraz dil getirmenin çalışması için, farklı dillerdeki anlamca eşdeğer metinlerin aynı vektör uzayında birbirine yakın konumlanması gerekir — yani "iade politikası" Türkçe sorgusu, "return policy" İngilizce belgesine yaklaşmalıdır. İyi bir çok dilli model bunu başarır; Türkçeye özel, yalnızca Türkçe eğitilmiş bir model ise İngilizce belgeyi hiç bulamaz çünkü o dili temsil edemez. Dolayısıyla belgeleriniz çok dilliyse, Türkçeye özel modelin cazip görünen isabet avantajı, çapraz dil körlüğü yüzünden bir dezavantaja dönüşebilir. Çok dilli cümle temsili yaklaşımını çok dilli cümle embeddingleri ve genel cümle temsilini cümle embeddingleri yazılarında ele alıyoruz.

Buradaki karar, senaryonuzun dil profiline bağlıdır. Belgeleriniz baskın biçimde Türkçe ve İngilizce içerik nadirse, Türkçeye özel bir model isabette öne geçebilir. Belgeleriniz gerçekten çok dilli ve kullanıcılar dilden bağımsız cevap bekliyorsa, çapraz dil yeteneği olan bir çok dilli model neredeyse zorunludur. Bu yüzden değerlendirme setinizi kurarken, çapraz dil sorularını da (Türkçe soru → İngilizce doğru belge) dahil edin; aksi halde bu kör noktayı hiç ölçmemiş olursunuz. Embedding modeli seçimi, dil profilini görmezden gelemez.

Embedding modeli seçimi kadar, modele metni nasıl verdiğiniz de gömme kalitesini etkiler; ve Türkçe'de bunun özel bir tuzağı vardır. Türkçe'ye özgü karakterler (ı, İ, ğ, ş, ç, ö, ü) ve özellikle noktalı/noktasız "i" ayrımı, dikkatsiz bir ön işleme adımında bozulabilir. En bilinen hata, İngilizce mantığıyla yapılan küçük harfe çevirmedir: "İSTANBUL" kelimesi, Türkçe kurallarına uymayan bir küçültme ile "istanbul" yerine "i̇stanbul" gibi bozuk bir biçime dönüşebilir ve model bunu farklı bir kelime olarak görebilir.

Bu, embedding'in kendisinden değil, ona giden veri hattından kaynaklanan bir kalite kaybıdır; ama sonuç aynıdır: Türkçe embedding isabeti düşer. Bu yüzden Türkçe içerikte, hem belgeleri hem sorguları aynı ve Türkçe-duyarlı biçimde normalize etmek kritiktir. Belge tarafında bir normalizasyon, sorgu tarafında başka bir normalizasyon uygulanırsa, aynı kelime iki farklı biçime gider ve eşleşme bozulur. Tutarlılık, embedding modeli seçiminin başarısını korumanın ön koşuludur.

Bir başka konu, aşırı ön işlemenin zararıdır. Klasik NLP'de yaygın olan agresif kök bulma (stemming) veya durak kelime (stopword) atma, modern embedding modelleriyle çoğu zaman gereksiz ve hatta zararlıdır; çünkü bu modeller ham metnin bağlamından anlam çıkarır ve siz kelimeleri buduladıkça anlamı zayıflatırsınız. Modern bir embedding modeliyle çalışırken, metni olabildiğince doğal bırakıp yalnızca tutarlı ve Türkçe-duyarlı bir normalizasyon uygulamak en iyisidir. Türkçe metin işlemenin bu inceliklerini Türkçe NLP zorlukları yazısında derinleştiriyoruz. Kısaca: en iyi embedding modeli seçimi bile, bozuk bir ön işleme hattıyla heba olabilir.

Türkçe embedding'in en sık karşılaşılan pratik zorluklarından biri, nadir terimler ve kısaltmalardır. Bir embedding modeli, eğitim verisinde bolca gördüğü kelimeleri iyi temsil eder; ama sizin kurumunuza özel ürün kodları, iç kısaltmalar (örneğin bir sürecin şirket-içi adı) veya çok teknik jargon, modelin nadiren karşılaştığı kelimelerdir ve bunların gömme kalitesi zayıf olabilir. Bu, embedding modeli seçiminde alan uyumuyla iç içe geçen bir sorundur.

Sorunun tipik belirtisi şudur: kavramsal sorular iyi çalışır ama tam bir terim, kod veya kısaltma arandığında sistem şaşırır. "Sözleşmenin feshi koşulları" gibi kavramsal bir soru doğru parçayı getirirken, "TX-4021 prosedürü" gibi bir kod araması boş dönebilir; çünkü model bu kodu anlamlı bir vektöre oturtamaz. İşte bu noktada saf anlamsal aramanın sınırı belli olur ve hibrit arama devreye girer: klasik anahtar kelime bileşeni, tam eşleşme gereken terim ve kodları yakalar. Bu birleşimi hibrit arama ve RAG yazısında ele alıyoruz.

İkinci bir çözüm, terminoloji sözlüğü ve sorgu genişletmedir: kurumunuzun kısaltmalarını ve eş anlamlılarını bir sözlükte tutup, sorguyu embedding'e vermeden önce genişletmek (örneğin kısaltmanın açık halini eklemek), nadir terim sorununu hafifletir. Üçüncüsü, alanınıza gerçekten çok özgü bir terminoloji varsa, embedding modelini kendi verinizle uyarlamak (bir sonraki bölümde ele alıyoruz) bu terimlerin temsilini iyileştirebilir. Ama ilk ve en pratik adım, embedding modeli seçiminin yanına hibrit aramayı koymaktır; çünkü tek başına hiçbir embedding modeli, hiç görmediği bir kodu sihirle anlamlandıramaz.

Çoğu kurumsal proje için hazır bir embedding modeli seçmek yeterlidir; ama bazı ileri senaryolarda, embedding modelini kendi alan verinizle uyarlamak (fine-tuning / alan adaptasyonu) belirgin bir isabet kazancı sağlayabilir. Bu, embedding modeli seçiminin bir uzantısıdır: hazır modeli bir başlangıç noktası alıp, kendi Türkçe ve alan-özel verinizle onu sizin dilinize daha da yakınlaştırmak. Fine-tuning'in genel mantığını fine-tuning nedir yazısında ele alıyoruz.

Bir embedding modelini uyarlamanın tipik yolu, kendi verinizden "olumlu" ve "olumsuz" çiftler oluşturmaktır: birbirine gerçekten ilgili soru-belge çiftleri (olumlu) ve ilgisiz çiftler (olumsuz). Model, olumlu çiftleri vektör uzayında yaklaştırmayı, olumsuzları uzaklaştırmayı öğrenir; böylece sizin alanınızın "neyin neye yakın olduğu" anlayışını içselleştirir. Bu, özellikle çok özel bir jargonu olan alanlarda (hukuk, tıp, mühendislik) gömme kalitesini gözle görülür artırabilir. Karşıtlıklı öğrenme mantığını alana özgü embeddingler yazısında bulabilirsiniz.

Ancak uyarlama bir maliyet ve bakım yükü getirir: etiketli veri hazırlamak, eğitim yapmak, sonucu değerlendirmek ve model güncellendiğinde tekrarlamak gerekir. Bu yüzden doğru sıralama şudur: önce hazır modellerle embedding modeli seçimi yapın ve kendi değerlendirme setinizde ölçün; ancak en iyi hazır model bile alan diliniz üzerinde yetersiz kalıyorsa uyarlamaya geçin. Uyarlamayı bir başlangıç noktası değil, kanıtlanmış bir ihtiyacın çözümü olarak düşünün. Çoğu Türkçe RAG projesinde, iyi bir hazır çok dilli veya Türkçeye özel model + hibrit arama + reranking, uyarlamaya gerek kalmadan yeterli kaliteyi verir.

Şimdiye kadar embedding modeli seçimini, her parçayı tek bir vektörle temsil eden klasik yaklaşım üzerinden konuştuk. Ama bir alternatif daha vardır ve bazı senaryolarda isabeti artırır: late-interaction (geç etkileşim) ve çok-vektörlü temsiller. Bu yaklaşımda bir belge tek bir vektöre sıkıştırılmaz; her token veya alt-birim için ayrı vektörler tutulur ve eşleşme, sorgu ile belge token'ları arasında daha ince bir düzeyde yapılır. Bu tekniği late-interaction embeddingler yazısında ele alıyoruz.

Late-interaction'ın avantajı, tek-vektör sıkıştırmasının kaybettiği ince eşleşmeleri yakalayabilmesidir: uzun bir belgede yalnızca belirli bir cümlenin soruyla ilgili olduğu durumlarda, tek vektör bu ilgiyi ortalama içinde eritebilirken, çok-vektörlü yaklaşım o cümleyi öne çıkarabilir. Bu, özellikle uzun belgelerde ve ince ayrıntının önemli olduğu alanlarda gömme kalitesini artırabilir. Dezavantajı ise maliyettir: her belge için çok sayıda vektör saklamak, depolama ve hesaplama yükünü belirgin biçimde artırır ve altyapı desteği daha dardır.

Bu yüzden çok-vektörlü yaklaşımlar, embedding modeli seçiminde varsayılan değil, belirli bir ihtiyaç ortaya çıktığında değerlendirilecek bir ileri seçenektir. Doğru yol, klasik tek-vektör bir modelle başlamak, kaliteyi ölçmek ve ancak ince eşleşme eksikliği sistematik bir sorun haline geldiğinde late-interaction'ı denemektir. Tıpkı GraphRAG ve agentic RAG gibi, bu da "karmaşıklığı ancak kanıtlanmış ihtiyaç varken ekle" ilkesine tabidir. Çoğu Türkçe kurumsal senaryo, iyi seçilmiş bir tek-vektör modeliyle mükemmel biçimde çözülür; çok-vektörlü teknikler, sınırda kalan zorlu senaryolar için bir üst vitestir.

Embedding modeli seçimi, model canlıya alındığında bitmez; üretimde de yaşamaya devam eden bir karardır. Zamanla iki şey değişir: belgeleriniz (yeni içerik eklenir, eskisi güncellenir) ve kullanıcı sorularınız (yeni konular, yeni terimler ortaya çıkar). Bu değişim, başlangıçta mükemmel çalışan bir embedding modelinin zamanla göreli performansının düşmesine — bir tür sessiz kayma (drift) yaşamasına — yol açabilir. Bu yüzden üretimdeki bir RAG sistemi izlenmelidir. Üretimde model izleme ve drift yönetimini model izleme ve drift tasarımı yazısında ele alıyoruz.

Pratikte izleme şöyle işler: kullanıcıların hangi sorularda tatmin edici cevap alamadığını (düşük memnuniyet, tekrar sorma, insana yönlendirme) toplarsınız ve bu "başarısız sorular", değerlendirme setinizi büyütmek için altın kaynaktır. Bu sorularda doğru parçanın getirilip getirilmediğini incelediğinizde, sorunun embedding katmanında mı yoksa chunking, reranking veya üretme katmanında mı olduğunu teşhis edebilirsiniz. Eğer doğru parça hiç getirilmiyorsa, sorun büyük olasılıkla embedding modeli seçimine veya chunking'e işaret eder.

Buradaki disiplin, embedding modeli seçimini periyodik olarak yeniden gözden geçirmektir: değerlendirme setinizi büyütmek, yeni çıkan modelleri aynı set üzerinde test etmek ve fark anlamlıysa geçişi planlamak. Yeni ve daha iyi bir model çıktığında, onu kendi verinizle mevcut modele karşı ölçmeden geçmeyin; "yeni olan daha iyidir" bir varsayımdır, kanıt değil. Bu yüzden bir kez kurduğunuz değerlendirme seti, ömür boyu değer üreten bir varlıktır: her model kararını, her yükseltmeyi ve her drift şüphesini onunla sınarsınız. Kurumsal RAG'i uçtan uca tasarlarken bu operasyon katmanını da kurumsal RAG rehberi yazısında ele alıyoruz.

Embedding modeli seçimini kendi verinizle ölçerken doğal bir soru gelir: değerlendirme setinde kaç soru yeterlidir? Çok az soruyla yapılan bir karşılaştırma yanıltıcıdır; iki model arasındaki küçük bir fark, gerçek bir üstünlük değil, örneklem tesadüfü olabilir. Çok fazla soru ise hazırlaması pahalıdır. Doğru denge, istatistiksel güvenle pratik emek arasında kurulur. İstatistiksel gücün mantığını istatistiksel güç yazısında bulabilirsiniz.

Pratik bir kural olarak, anlamlı bir ilk karşılaştırma için 50-100 iyi seçilmiş soru genellikle yeterlidir; ama kritik bir üretim kararı veriyorsanız, 200 veya daha fazla soruyla güveni artırmak değer. Önemli olan yalnızca sayı değil, çeşitliliktir: sorular alanınızın farklı konularını, farklı zorluk seviyelerini ve farklı soru biçimlerini (kısa/uzun, açık/belirsiz, kavramsal/terim odaklı) kapsamalıdır. Homojen, hep-kolay bir set, modeller arasındaki gerçek farkı gizler; çünkü tüm modeller kolay sorularda iyidir.

Bir başka incelik, farkın büyüklüğüne bakmaktır. İki model arasında recall@5 farkı yüzde 1-2 ise, bu fark muhtemelen gürültüdür ve model değiştirmeye — hele değiştirme maliyetini düşününce — değmez. Ama fark yüzde 10-15 gibi belirginse, bu gerçek bir sinyaldir. Embedding modeli seçiminde küçük farkları kovalamak yerine, belirgin ve tekrarlanabilir farklara güvenin. Ve kararı bir kez değil, seti zamanla büyüterek tekrar tekrar sınayın; güven, tek bir ölçümden değil, tutarlı tekrarlardan gelir. Değerlendirme disiplinini genel çerçevede LLM değerlendirme nedir yazısında ele alıyoruz.

Embedding modeli seçimi yaparken, adayları nereden bulacağınız ve haklarındaki bilgiyi nasıl okuyacağınız da bir beceridir. Açık kaynak embedding ekosistemi hızla büyüyor; Türkçe destekleyen çok dilli modeller ve Türkçeye özel modeller giderek çoğalıyor. Bu bolluk bir fırsattır ama aynı zamanda bir seçim yükü getirir: doğru adayları eleyip anlamlı bir kısa listeye inmek gerekir. Açık kaynak modellerin kurumsal kullanımını açık kaynak LLM nedir yazısında ele alıyoruz.

Bir modeli değerlendirirken, model kartını (model card) dikkatle okumak kritiktir. Model kartında şunlara bakın: hangi dillerde ve hangi veriyle eğitildi (Türkçe kapsamı ne kadar), vektör boyutu ve maksimum bağlam uzunluğu nedir, önerilen mesafe metriği ve talimat kullanımı nasıl, lisansı ticari kullanıma uygun mu, ve varsa hangi benchmark'larda nasıl skorlar aldı. Bu bilgiler, bir modeli değerlendirme setinize almadan önce hızlı bir uygunluk elemesi yapmanızı sağlar. Örneğin ticari kullanıma kapalı bir lisans, model ne kadar iyi olursa olsun kurumsal projeniz için baştan elenebilir.

Buradaki tuzak, model kartındaki iddialara körü körüne güvenmektir. Bir model "Türkçe destekler" diyebilir ama bu desteğin kalitesi zayıf olabilir; ya da yüksek benchmark skorları İngilizce görevlerden gelmiş olabilir. Model kartı bir başlangıç filtresidir, tıpkı benchmark gibi; nihai kararı yine kendi Türkçe değerlendirme setiniz verir. Türkçe modeller özelinde daha ayrıntılı bir aday karşılaştırması için Türkçe RAG için embedding modelleri karşılaştırma rehberini inceleyebilirsiniz; bu yazı ise size o karşılaştırmayı kendi verinizle nasıl yapacağınızın yöntemini verir. Kısaca: ekosistemi tarayın, model kartlarını okuyun, kısa liste çıkarın — ama embedding modeli seçimini daima kendi ölçümünüzle kapatın.

Embedding modeli seçimi ne kadar iyi olursa olsun, kötü biçimlendirilmiş bir soru kötü bir getirme üretir; çünkü embedding, önüne gelen metni temsil eder, kullanıcının niyetini okumaz. Türkçe kullanıcı soruları genellikle kısa, eksiltili ve bağlama gömülüdür: "peki ya devri?", "bu maddede mi?", "iznimi nasıl kullanırım". Bu tür sorular tek başına vektörlendiğinde, embedding'in yakalayacağı yeterli sinyal içermez ve en iyi model bile alakasız parçalar getirir. İşte bu noktada soru yeniden yazma (query rewriting), embedding modeli seçiminin tek başına çözemeyeceği bir sorunu çözer.

Soru yeniden yazma, kullanıcının bağlama gömülü, eksiltili sorusunu, kendi başına anlamlı ve arama için zengin bir sorguya dönüştürür. "Peki ya doğum izni?" sorusu, konuşma geçmişiyle birleştirilip "Doğum izni bir sonraki yıla devrediliyor mu?" biçimine getirilir; ve embedding'e verilen bu zenginleştirilmiş sorgudur. Böylece embedding, temsil edeceği daha net bir metin bulur ve gömme kalitesi pratikte artar — model değişmese bile. Bu, embedding modeli seçiminin çevresindeki hattın, seçimin başarısını ne kadar etkilediğini gösteren güzel bir örnektir.

Türkçe'de yeniden yazmanın ek bir faydası, morfolojik ve terminolojik normalleştirmedir: kısaltmaları açmak, eş anlamlıları eklemek ve soruyu belge diline yaklaştırmak, embedding'in işini kolaylaştırır. Bu yüzden Türkçe bir RAG sisteminde, iyi bir embedding modeli seçimi kadar iyi bir soru işleme katmanı da kurmak gerekir; ikisi birlikte çalışır. Kısacası embedding, aldığı sorgu kadar iyidir; sorguyu iyileştirmek, çoğu zaman modeli değiştirmekten daha ucuz ve daha etkili bir kaldıraçtır. Doğal dil işlemenin bu katmanını doğal dil işleme nedir yazısında ele alıyoruz.

Kendi verinizle ölçüm yaptıktan sonra elinizde bir sayı tablosu olur: her aday model için recall@k, MRR, gecikme ve maliyet. Ama bu tabloyu doğru yorumlamak, embedding modeli seçiminin son ve en çok atlanan adımıdır. En yaygın hata, tek bir metriğe bakıp karar vermektir — örneğin yalnızca en yüksek recall@5'e sahip modeli seçmek. Oysa karar, metrikler arasındaki ödünleşimi görmeyi gerektirir: en isabetli model, gecikme veya maliyet açısından bütçenizi aşıyorsa doğru seçim olmayabilir.

Yorumlamada ikinci incelik, farkın anlamlılığıdır. İki model arasında recall farkı küçük ve MRR'de biri az önde, diğeri gecikmede çok daha iyiyse, karar senaryonuzun önceliğine göre değişir: bir hukuk asistanında isabet, yüksek hacimli bir destek botunda gecikme öne çıkar. Bu yüzden sonuçları tek bir "kazanan" arayışıyla değil, "benim önceliğime göre en iyi denge hangisi" sorusuyla okuyun. Gömme kalitesi tablonun sadece bir sütunudur; karar, tüm sütunların önceliğe göre tartılmasıdır.

Üçüncü incelik, sonuçları segmentlere ayırmaktır. Ortalama bir recall skoru, kavramsal sorularda mükemmel ama terim/kod sorularında zayıf bir modeli gizleyebilir. Sonuçları soru tipine göre ayırdığınızda (kavramsal, terim odaklı, çok dilli, uzun/kısa), hangi modelin nerede güçlü olduğunu görürsünüz; bu, embedding modeli seçimini hibrit arama gibi tamamlayıcı kararlarla birleştirmenizi sağlar. Örneğin bir model kavramsalda üstün ama terimde zayıfsa, o modeli seçip yanına hibrit arama koymak akıllıca olur. Sayıları segmentlere ayırıp önceliğe göre yorumlamak, embedding modeli seçimini kaba bir sıralamadan bilinçli bir mühendislik kararına dönüştürür.

Embedding modeli seçiminde maliyet çoğu zaman soyut bırakılır; oysa iki kalemi somut biçimde modellemek, kararı netleştirir. Birinci kalem tek seferlik indeksleme maliyetidir: tüm belge tabanınızı ilk kez vektörlemek. İkinci kalem sürekli sorgu maliyetidir: her kullanıcı sorusunun ve yeni eklenen her belgenin vektörlenmesi. Bu ikisi çok farklı büyüklükte olabilir; büyük bir arşivi bir kez indekslemek pahalı ama tek seferlik, günlük sorgular ise küçük ama sürekli birikendir.

Kaba bir çerçeve (aşağıdaki sayılar illustratiftir, gerçek fiyat değildir) şöyle kurulur: belge tabanınızdaki toplam token sayısını tahmin edin; bunu seçtiğiniz modelin birim maliyetiyle çarpın; sonuç, indeksleme bütçenizdir. Sorgu tarafında ise günlük soru sayısı × soru başına ortalama token × birim maliyet, günlük sorgu bütçenizi verir. Buna vektör veritabanı barındırma ve depolama maliyetini eklerseniz, embedding modeli seçiminin toplam sahip olma maliyetini görürsünüz. Bu hesap, "hangi model daha ucuz" sorusunu bir his olmaktan çıkarıp bir tabloya dönüştürür.

Buradaki kritik içgörü, maliyetin boyutla ve model seçimiyle doğrudan ilişkili olmasıdır: daha yüksek boyutlu bir model daha çok depolama, self-host bir model donanım ama düşük birim maliyet, API bir model sıfır altyapı ama çağrı başına ücret getirir. Boyut ve performans dengesini burada da görürüz — daha düşük boyutlu bir model, hem depolamayı hem arama maliyetini düşürür. Doğru embedding modeli seçimi, en yüksek isabeti değil, bütçeniz içinde kabul edilebilir isabeti veren dengeyi bulmaktır. Yüksek hacimli senaryolarda küçük bir birim maliyet farkı bile, yıllık toplamda büyük bir rakama dönüşür; bu yüzden maliyeti baştan modellemek, sonradan sürpriz faturayla karşılaşmaktan iyidir.

Embedding modeli seçiminin bir uzantısı, üretilen vektörlerin nasıl saklanacağıdır. Milyonlarca yüksek boyutlu vektör, ciddi bir depolama ve bellek yükü demektir; ve burada nicemleme (quantization) devreye girer. Nicemleme, her vektör bileşenini tam hassasiyetli bir sayı yerine daha az bit kullanan bir yaklaşımla saklamaktır; örneğin 32-bit yerine 8-bit. Bu, depolamayı ve bellek kullanımını belirgin biçimde düşürürken, gömme kalitesinde genellikle çok küçük bir kayba yol açar. Tam sayı nicemlemenin mantığını int8 nicemleme yazısında ele alıyoruz.

Benzer biçimde, vektör normalizasyonu hem doğru mesafe metriği için hem de bazı sıkıştırma tekniklerinin sağlıklı çalışması için önemlidir. Normalize edilmiş vektörler, kosinüs benzerliğini nokta çarpımıyla hesaplamayı mümkün kılar ve sıkıştırma sonrası tutarlılığı korur. Normalizasyonun ayrıntısını vektör normalizasyonu yazısında bulabilirsiniz. Bu teknikler, yüksek boyutlu bir modelin maliyetini yönetilebilir kılabilir; yani boyut ve performans dengesini yalnızca boyutu düşürerek değil, saklama biçmini optimize ederek de kurabilirsiniz.

Pratik sonuç şudur: embedding modeli seçimini yalnızca modelin ürettiği vektörün kalitesiyle değil, o vektörü ölçekte saklama ve arama maliyetiyle birlikte değerlendirin. Yaklaşık en yakın komşu (ANN) indeksleri, nicemleme ve normalizasyon; hepsi, iyi bir modelin isabetini üretimde ekonomik biçimde ayakta tutmanın araçlarıdır. Türkçe içerikte, yüksek isabet için orta-yüksek boyutlu bir model seçip ardından nicemlemeyle depolamayı düşürmek, çoğu zaman "düşük boyutlu ucuz model" ile "yüksek boyutlu pahalı model" arasında akıllı bir orta yol sunar. Böylece gömme kalitesinden ödün vermeden maliyet kontrol altına alınır.

Tüm bu tartışmayı uygulanabilir bir özete indirgeyelim. Aşağıdaki kontrol listesi, Türkçe içerikte embedding modeli seçimini fikirden karara sağlam biçimde yürütmenin pratik bir rehberidir. Bu adımları sırayla geçebiliyorsanız, kararınızı tahmine değil kanıta dayamış olursunuz.

Nasıl Yapılır

Türkçe embedding modeli seçimi kontrol listesi

Türkçe içerikte embedding modeli seçimini kanıta dayalı biçimde vermek için adım adım kontrol listesi.

1. 1

   Senaryonu sınıflandır

   Dil profili (tek/çok dilli), alan (genel/jargon), öncelik (isabet/gecikme/maliyet) ve gizlilik (KVKK) sorularını yanıtla.

2. 2

   Aday listesi çıkar

   Benchmark ve model kartlarıyla 2–4 aday belirle: güçlü çok dilli, Türkçede güçlü ve varsa alan modeli.

3. 3

   Değerlendirme seti kur

   Kendi Türkçe (ve gerekirse çapraz dil) sorularınla 50–200 soruluk, altın kümesi işaretli bir set hazırla.

4. 4

   Adil karşılaştır

   Chunking, normalizasyon ve talimatı sabitleyip her modeli kendi en iyi ayarında çalıştır; recall@k ve MRR ölç.

5. 5

   Boyut, maliyet ve gecikmeyi tart

   İsabetin yanına depolama, gecikme ve maliyet sütunlarını koy; boyut ve performans dengesini senaryona göre seç.

6. 6

   Gizlilik ve lisansı doğrula

   API mi self-host mu, veri nereye gidiyor, lisans ticari kullanıma uygun mu — KVKK açısından karar ver.

7. 7

   Kazananı seç ve versiyonla

   En iyi dengeyi veren modeli seç, her belgeyi hangi model/sürümle vektörlediğini kaydet.

8. 8

   İzle ve periyodik yeniden değerlendir

   Başarısız soruları topla, seti büyüt, yeni modelleri aynı sette sına; drift görürsen geçişi planla.

Bu kontrol listesinin özü, embedding modeli seçimini bir kerelik bir tahmin değil, tekrarlanabilir bir mühendislik döngüsü olarak kurmaktır. Küçük bir pilotta bu adımları uygulamak, büyük bir "en iyi modeli seçtim" iddiasından çok daha değerlidir; çünkü ölçülmüş küçük bir kazanç, ölçülmemiş büyük bir vaatten her zaman daha ikna edicidir. Kurumunuza özel bir değerlendirme kurulumu ve embedding stratejisi tasarlamak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin bu süreci içselleştirmesi için kurumsal eğitim seçeneklerini inceleyebilirsiniz.

Kısaca, embedding modeli seçimi Türkçe bir RAG sisteminin getirme kalitesini belirleyen en kritik karardır ve tek bir benchmark sıralamasıyla değil, kendi Türkçe verinizle kurulmuş bir değerlendirme setiyle kanıta dayalı verilir. Çok dilli model çoğu senaryoda yeterlidir ve operasyonel olarak kolaydır; Türkçeye özel model nüans ve alan yoğun içerikte fark yaratabilir — ama bunu varsaymak değil, ölçmek gerekir. Boyut ve performans bir dengedir: en büyük vektör değil, gömme kalitesi ile maliyet-gecikme arasında senaryonuza uyan denge doğrudur.

En önemli mesaj şudur: embedding modeli seçimini popülariteyle değil, kendi sorularınız ve belgeleriniz üzerinde ölçülen getirme isabetiyle yapın. Benchmark eler, karar sizin verinizden gelir. Unutmayın ki iyi bir embedding modeli seçimi tek başına yeterli değildir; onu doğru chunking, gerektiğinde hibrit arama, etkili reranking ve sürekli değerlendirme ile birlikte kurmak gerekir. Alan uyumu genel skordan önemlidir; değiştirme maliyeti yüksektir, bu yüzden versiyonlama baştan planlanır; ve model, boyut, indeks ve mesafe metriği birlikte tasarlanır. Bu disiplinle yapılan bir embedding modeli seçimi, ortalama bileşenlerle bile güvenilir bir Türkçe RAG sistemi kurmanın temelini atar.

Temel kavramları derinleştirmek için embedding nedir, vektör veritabanı nedir ve semantik arama nedir rehberlerine bakabilirsiniz; kurumunuza özel bir RAG mimarisi ve embedding stratejisi tasarlamak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin bu kararları doğru vermesi için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz. Bu konuda bültenimizden güncel içerikleri almak veya bir proje görüşmesi için iletişime geçebilirsiniz.