Embedding Nedir? Yapay Zeka Metni Nasıl Sayıya Çevirir?

1.536 sayı. "Fatura gecikince ne yapmalıyım?" cümlesini bir yapay zeka sistemine verdiğinizde, sistemin o cümleden ilk ürettiği şey bir cevap değil, 1.536 ondalık sayıdan oluşan bir listedir. Cümlenin kendisi o listeye dönüştükten sonra işlenir; arama da, "şirket belgelerimizle konuşan asistan" da, ürün önerisi de o listenin üzerine kurulur. Bu listeye embedding deniyor ve yapay zeka projelerinin çoğunda faturanın en küçük, sonucun en belirleyici kalemi o.

Embedding nedir sorusunun kısa cevabı şu: bir metnin anlamını sayılarla temsil etmek. Uzun cevabı, kaç sayı olacağı, hangi modelin üreteceği, Türkçede ne kadar iyi çalıştığı ve 10.000 sayfalık bir arşivin bu işlemden kaça çıktığı. Bu yazı o uzun cevabı, satın alma kararı verecek birinin ihtiyaç duyduğu ayrıntıda veriyor. Genel resim için AI altyapısı kararlarının patron özeti çatı yazısı var; burada o haritanın tek bir parçasına, metnin sayıya çevrildiği ana yakınlaşıyoruz.

Embedding nedir, sayılar anlamı nasıl taşır?

Embedding, bir kelimenin, cümlenin ya da belgenin anlamını yüzlerce ya da binlerce sayıdan oluşan bir vektörle temsil etme yöntemidir. Yapay zeka modelleri metni doğrudan okumaz; her metni bu sayı listesine çevirir ve anlamı, listeler arasındaki uzaklıkla ölçer. Anlamca yakın iki metnin vektörleri birbirine yakın, uzak olanlarınki uzak düşer.

Somutlaştıralım. "Kedi" ile "köpek" vektörleri birbirine yakındır, "kedi" ile "fatura" uzak. 2013 tarihli word2vec çalışmasının ünlü örneği bu aritmetiği gösteriyor: kral vektöründen erkek vektörünü çıkarıp kadın vektörünü eklediğinizde kraliçe vektörüne çok yakın bir noktaya varıyorsunuz. Sayılar anlamın kendisi değil, ama anlamın ilişkilerini şaşırtıcı bir sadakatle koruyor.

İş dünyası için en kullanışlı benzetme şu: her belgeye bir GPS koordinatı vermek. Alfabetik raflanmış bir kütüphanede "gecikme cezası" arayan biri, "temerrüt faizi" başlıklı belgeyi bulamaz; harfler eşleşmez. Koordinatla raflanmış kütüphanede iki belge yan yana durur, çünkü aynı şeyi anlatıyorlar. Anahtar kelime araması harf eşleştirir; embedding araması anlam eşleştirir. Bu farkın maliyet ve kalite sonuçlarını aşağıda sayılarla göreceksiniz.

Embedding modeli nasıl seçilir, boyut ne anlama gelir?

Embedding modeli, metni sayıya çeviren hazır bir sistemdir ve seçim üç ölçüte dayanır: vektör boyutu, fiyat ve dil performansı. Boyut, listedeki sayı adedidir ve doğrudan depolama ile arama hızını belirler. Fiyat, bir milyon token başına hesaplanır. Dil performansı ise, Türkçe için ayrıca test edilmesi gereken bir başlıktır.

Yazım tarihi itibarıyla üçüncü taraf karşılaştırma sitelerinde tutarlı görünen rakamlar şöyle. OpenAI'nin text-embedding-3-small modeli 1.536 boyut üretiyor ve milyon token başına 0,02 dolar; text-embedding-3-large 3.072 boyut, 0,13 dolar. Voyage'ın voyage-3-large modeli 1.024 boyutla 0,06 dolar; Cohere'in Embed v4 modeli 1.536 boyut, 0,12 dolar ve tek seferde 128 bin token'lık belge kabul ediyor. Google'ın Gemini embedding modeli 3.072 boyut üretiyor; fiyatı için aramada çelişkili rakamlar çıktığından burada vermiyoruz, resmi fiyat sayfasından bakılmalı.

Boyut konusunda yaygın bir yanılgı var: büyük boyut her zaman daha iyi değil. OpenAI'nin Ocak 2024'te yayımladığı kendi ölçümü bunu net gösteriyor: text-embedding-3-large modelinin 256 boyuta kısaltılmış hali, MTEB ölçütünde 62,0 puanla eski nesil ada-002 modelinin 1.536 boyutlu halini (61,0) geçiyor. Altı kat küçük vektör, daha iyi sonuç. Bunu mümkün kılan teknik Matryoshka temsil öğrenmesi: vektör baştan kesilerek kısaltılabiliyor ve anlam büyük ölçüde korunuyor. Model değiştirmeden maliyet, hız ve kalite arasında ayar yapmak bu sayede mümkün.

Bağımsız bir karşılaştırmada Mart 2026'da 10 model yan yana test edildi ve sonuç tek cümleyle özetlendi: hiçbir model her turu kazanmıyor. "En iyi embedding modeli" diye bir şey yok; iş yükünüze göre en iyi model var.

Açık kaynak tarafında iki isim öne çıkıyor. BAAI'nin BGE-M3 modeli 100'den fazla dili destekliyor, 1.024 boyut üretiyor ve aynı modelde hem anlam hem anahtar kelime eşleştirmesi yapabiliyor. Alibaba'nın Qwen3-Embedding ailesi ise 0,6 milyardan 8 milyar parametreye kadar üç boyda geliyor; 8 milyarlık sürümün kendi teknik raporuna göre MTEB İngilizce ölçütünde 75,22 puanla Gemini'yi (73,30) geçtiği belirtiliyor. Bu satıcı ölçümü; bağımsız doğrulaması ayrı bir konu. Her ikisi de kendi sunucunuzda ücretsiz çalışıyor.

10.000 sayfalık arşivi sayıya çevirmek kaça mal olur?

Yaklaşık bir iki dolar. 10.000 sayfalık bir Türkçe belge arşivini embedding'e çevirmenin model ücreti, en pahalı ticari modelde bile iki doları geçmiyor. Bu rakam, projenin kalan kalemleri yanında yuvarlama hatası kadar küçük. Asıl maliyet vektörlerin saklandığı veritabanında, parçalama mühendisliğinde ve sorgu tarafındaki dil modeli çağrısında birikiyor.

Hesabı açalım; kabuller yaklaşık. Bir sayfa 500 kelime olsun. İngilizce metinde kelime başına 1,3 token düşer; Türkçede eklemeli yapı ve tokenizer verimsizliği yüzünden bu oran yaklaşık iki katına çıkar, sayfa başına 1.000-1.300 token. 10.000 sayfa, Türkçe için kabaca 12 milyon token eder. Bu hacimle:

• text-embedding-3-small (0,02 $/M): yaklaşık 0,25 dolar.
• voyage-3-large (0,06 $/M): yaklaşık 0,70 dolar.
• Cohere Embed v4 (0,12 $/M): yaklaşık 1,45 dolar.
• text-embedding-3-large (0,13 $/M): yaklaşık 1,55 dolar.

Depolama tarafı da küçük. 12 milyon token, 400 token'lık parçalara bölündüğünde örtüşme payıyla yaklaşık 35 bin vektör eder. 1.536 boyutlu bir vektör, sayı başına 4 bayttan 6 kilobayt tutar; 35 bin vektör yaklaşık 200 megabayt. 3.072 boyutta 400 megabayt, 256 boyutta 35 megabayt. Bir dizüstü bilgisayarın hafızasına sığan rakamlar. Boyut kararı, milyonlarca belgede önem kazanıyor; on binlerce belgede kazanmıyor.

Sorgu tarafında da benzer bir asimetri var. Her arama sorgusu 20-50 token; bir milyon sorgu bile küçük modelde bir doların altında. Ama o sorguya cevap üreten dil modeli çağrısı, sorgu başına birkaç bin token tüketiyor ve embedding'in yüz ila bin katı pahalı. Bütçe konuşulurken embedding satırına değil, dil modeli satırına bakın. Bu arşivi saklayacak altyapı için vektör veritabanı yazımız hangi ölçekte hangi çözümün yettiğini anlatıyor; on binlerce vektör için PostgreSQL'e eklenen pgvector çoğu zaman yeterli.

Embedding Türkçede ne kadar iyi çalışır?

Ticari modeller Türkçede "yeterince iyi" seviyede; açık kaynakta BGE-M3 Türkçe karşılaştırmalarda öne çıkıyor; Türkçeye özel eğitilmiş TurkEmbed4Retrieval gibi modeller belirli görevlerde daha iyi sonuç bildiriyor. Ancak MTEB gibi uluslararası sıralamalar İngilizce ağırlıklı olduğundan, Türkçe için kararı kendi verinizle 50-100 soruluk bir testle vermek en güvenilir yol.

Türkçeye özel çalışmalar 2025 sonunda hızlandı. Newmind AI'ın Kasım 2025'te yayımladığı TurkEmbed4Retrieval, çok dilli bir temel modelin derin katmanlarını Türkçe arama verisiyle yeniden eğitiyor ve kendi ölçümüne göre bir Türkçe bilimsel arama testinde Turkish ColBERT'i yüzde 19-26 arasında geçiyor. Ayrıca Türkçeye özel bir değerlendirme seti olan TR-TEB üzerinde çalışılıyor. Bunlar tek kaynaklı bulgular; yön gösteriyor, karar verdirmiyor.

Türkçenin bir de gizli maliyeti var: token şişmesi. Aynı anlam Türkçede İngilizceden bir buçuk iki kat fazla token ediyor ve bu, hem embedding hem dil modeli faturasına doğrudan yansıyor. Yukarıdaki 12 milyon token hesabının yarısı bu şişmeden geliyor. Bir de yapısal sınır: Microsoft'un multilingual-e5-large modeli 512 token'da kesiyor; Türkçe bir sayfa bu sınırı aşıyor, bu yüzden parçalama zorunlu hale geliyor.

Embedding hakkında yanlış bilinen 5 şey

Aşağıdaki beş yanılgı, embedding konuşulan toplantılarda en sık duyduklarımız. Her birinin altında sayılarla neden yanlış olduğu var. Yanılgıların ortak noktası, embedding'i olduğundan daha pahalı, daha zeki ya da daha kalıcı sanmak.

• "Embedding yapmak model eğitmektir." Değil. Hazır modele metin gönderip vektör alırsınız; eğitim yok. TurkEmbed4Retrieval gibi ince ayarlı modeller ayrı ve nadiren gereken bir adım.
• "Büyük boyut daha iyidir." 256 boyutlu yeni model, 1.536 boyutlu eski modeli geçiyor. Boyut, kalitenin değil depolama ve gecikmenin ölçüsü.
• "Anahtar kelime aramanın yerini tamamen alır." Ürün kodu, kişi adı, tam ifade aramalarında anahtar kelime hâlâ üstün. Sektör standardı hibrit arama; BGE-M3'ün iki yöntemi tek modelde sunması bu yüzden.
• "Model metni anlıyor." İstatistiksel yakınlık öğreniyor. "İade edilebilir" ile "iade edilemez" vektörleri birbirine rahatsız edici derecede yakın çıkabiliyor; olumsuzlama ve sayısal karşılaştırma zayıf noktalar.
• "Bir kez çevirdim, bitti." Model değişirse tüm arşiv yeniden çevrilir; farklı modellerin vektörleri karşılaştırılamaz. Sağlayıcı bir modeli emekliye ayırdığında bu maliyet kendiliğinden gelir. Bu yüzden model adı ve sürümü her vektörün yanına kaydedilmeli.

Somut senaryo: 40 kişilik bir hukuk bürosunun 3 haftası (rakamlar yuvarlanmış)

İstanbul'da 40 kişilik bir hukuk bürosu, 15 yıllık sözleşme ve dilekçe arşivini "içinde anlam arayabilen" bir sisteme taşımak istedi. Arşiv yaklaşık 9.000 belge, 14.000 sayfa. İlk hafta belgelerin metne dönüştürülmesiyle geçti; taranmış PDF'lerin dörtte biri metin katmanından yoksundu ve optik karakter tanıma gerekti. Embedding'in kendisi bu haftada bir saat sürdü, model ücreti 3 doların altında kaldı.

İkinci hafta model karşılaştırmasına ayrıldı. Büro, avukatların gerçekten sorduğu 80 soruyu ve her sorunun doğru cevabını içeren belgeyi elle işaretledi. Üç model denendi: ticari bir büyük model, BGE-M3 ve TurkEmbed4Retrieval. İlk 5 sonuçta doğru belgeyi bulma oranı sırasıyla yüzde 84, 79 ve 81 çıktı. Ticari model önde, ama fark küçük; büro veri hassasiyeti nedeniyle kendi sunucusunda BGE-M3 ile devam etti ve üstüne anahtar kelime aramasını ekledi. Hibrit yapıyla oran yüzde 88'e çıktı. "Temerrüt faizi" araması artık "gecikme cezası" içeren belgeleri de getiriyor; dosya numarası araması ise eskisi gibi harfiyen çalışıyor.

Üçüncü haftada parça boyutu ayarlandı. 800 token'lık parçalarda madde numaraları birbirine karışıyordu; 350 token'a inip her parçanın başına belge adı ve madde başlığı eklenince sonuçlar belirgin biçimde temizlendi. Toplam altyapı maliyeti: mevcut PostgreSQL sunucusuna pgvector kurulumu ve iki günlük mühendislik. Embedding faturası projenin en ucuz kalemi olarak kaldı; en pahalı kalem, 80 soruluk test setini hazırlayan avukatların zamanıydı ve o zaman, projenin kalitesini belirleyen tek şeydi.

Sık sorulan sorular

Embedding ile vektör veritabanı arasındaki fark nedir?

Embedding, metni sayıya çevirme işleminin kendisi ve çıktısıdır. Vektör veritabanı, o sayıları saklayıp "en yakın komşuyu" hızlı bulan depodur: pgvector, Qdrant, Milvus, Pinecone, Weaviate. Biri üretim, diğeri raf. On binlerce vektör için mevcut PostgreSQL'e pgvector eklemek çoğu KOBİ'de yeterli.

Embedding modeli değişirse ne olur?

Eski vektörler yeni modelle uyumsuz hale gelir; tüm arşiv yeniden çevrilir. 10.000 sayfada bu birkaç dolar ve birkaç saat; milyonlarca belgede planlanması gereken bir operasyon. Model ve sürüm bilgisini her vektörle birlikte kaydetmek bu geçişi yönetilebilir kılar.

Chunking (parçalama) neden bu kadar önemli?

Model, bir parçanın anlamını tek vektöre sıkıştırır; 50 sayfalık belgeyi tek vektöre indirirseniz ayrıntı kaybolur. Tipik uygulama 200-500 token'lık, yüzde 10-20 örtüşmeli parçalar ve her parçanın başına belge adı gibi bağlam bilgisi eklemek. Yukarıdaki hukuk bürosu örneğinde en büyük kalite sıçraması bu ayardan geldi.

RAG ile embedding aynı şey mi?

Değil; embedding, RAG'in ilk adımı. RAG, sorgunun vektörüyle en yakın belge parçalarını bulup bunları dil modeline verir ve model cevabı o parçalara dayanarak üretir. RAG'in patron özeti bu zincirin tamamını ve maliyetini anlatıyor.

Kendi sunucumda mı çalıştırmalıyım, API mi kullanmalıyım?

Veri hassasiyeti yüksek ya da hacim büyükse açık kaynak model kendi sunucunuzda; hızlı başlangıç ve düşük hacimde API. Embedding ücreti her iki durumda da önemsiz olduğundan karar, veri lokasyonu ve operasyon yüküne göre verilir, fiyata göre değil.

Peki siz ne yapmalısınız?

• Önce 50-100 soruluk test seti hazırlayın: Ekibinizin gerçekten sorduğu sorular ve doğru cevabın bulunduğu belgeler. Model kararı bu sete göre verilir, sıralama tablolarına göre değil.
• Üç modeli aynı sette deneyin: Bir ticari model, BGE-M3 ve Türkçeye özel bir model. Toplam maliyet birkaç dolar, süre bir gün.
• Hibrit arama kurun: Anlam araması ile anahtar kelime aramasını birleştirin; kod ve isim aramalarını embedding'e bırakmayın.
• Parça boyutuyla oynayın: 300-400 token ile başlayın, her parçaya belge başlığını ekleyin, test setinde ölçün.
• Model sürümünü kaydedin: Her vektörün yanına hangi model ve sürümle üretildiğini yazın; ileride yeniden çevirme gerektiğinde kapsamı bilirsiniz.

Yazının başındaki 1.536 sayıya dönelim. O listenin kendisi neredeyse bedava; onu üreten model seçimi, parçalama kararı ve test seti ise projenin kalitesini belirleyen her şey. Elinizde çevrilmeyi bekleyen bir arşiv varsa, o 80 soruluk test setini nasıl kuracağınızı birlikte düşünmek isteriz; belgelerinizin türünü söylemeniz yeterli.