Embedding Nedir? Yapay Zeka Metinleri Anlamca Nasıl "Yakın" Buluyor

İki cümle yazın: "köpek havladı" ve "it ürüdü". Ortak tek bir kelime yok — ama ikisi de aynı şeyi anlatıyor. Bir arama kutusuna "köpek havladı" yazıp aratırsanız, klasik bir anahtar kelime araması "it ürüdü" geçen bir metni asla bulamaz, çünkü kelimeler eşleşmiyor. Oysa bugün kullandığımız yapay zeka sistemlerinin neredeyse hepsi — arama motorundan RAG sistemine, öneri motorundan içerik moderasyonuna kadar — bu iki cümlenin anlamca aynı olduğunu biliyor. Bunu mümkün kılan şeyin adı embedding. Bu yazıda embedding'in ne olduğunu, nasıl hesaplandığını ve nerede gerçekten işe yaradığını, soyut tanımlara boğmadan somut bir örnekle anlatıyorum.

##Embedding Nedir? Basitçe

Embedding, bir kelimenin, cümlenin ya da dokümanın anlamını sayılardan oluşan bir listeye (bir vektöre) çeviren bir temsil biçimi. Bu liste genelde birkaç yüz ila birkaç bin sayıdan oluşuyor — örneğin 384, 768 ya da 1536 boyutlu bir vektör. Önemli olan tek tek sayıların ne anlama geldiği değil (bunu insan gözüyle okumak mümkün değil), bu sayıların birlikte oluşturduğu konum. Bir embedding modeli, anlamca birbirine yakın iki metni, bu çok boyutlu uzayda birbirine yakın iki noktaya yerleştirecek şekilde eğitiliyor. "Köpek havladı" ve "it ürüdü" farklı kelimelerle yazılmış olsa da, bu uzayda birbirine çok yakın iki nokta olarak temsil ediliyor — tıpkı "kahve" ve "espresso"nun yakın, ama "kahve" ve "lastik"in uzak olması gibi.

Bu modeli eğiten şey, milyarlarca cümlelik metin üzerinde hangi kelimelerin hangi bağlamlarda birlikte geçtiğini öğrenmek. Bir dil modelinin (LLM) kendisi gibi, embedding modeli de devasa bir metin kümesinden örüntü çıkarıyor; ama LLM'in aksine yeni metin üretmiyor, sadece verilen metni bir vektöre sıkıştırıyor. Bu yüzden embedding modelleri çok daha küçük, çok daha hızlı ve çok daha ucuz çalışıyor — bir cümleyi vektöre çevirmek, o cümleye bir yanıt ürettirmekten onlarca kat daha az hesaplama gerektiriyor.

##Bu Sayılar Gerçekte Ne İfade Ediyor? Küçük Bir Örnek

Embedding'leri anlamanın en kolay yolu boyutu düşürüp iki eksenli bir harita hayal etmek. Diyelim ki bir eksen "resmiyet", diğeri "duygu yoğunluğu" olsun. "Siparişiniz için teşekkür ederiz" cümlesi bu haritada resmi ve nötr bir bölgeye düşer; "çok teşekkürler, harikasınız!" aynı bölgeye yakın ama duygu ekseninde daha yukarıda bir noktaya düşer; "ürün iade talebi" ise tamamen farklı bir bölgeye, konu ekseninde uzak bir noktaya düşer. Gerçek embedding modelleri bunu 2 eksende değil 768 ya da 1536 eksende yapıyor — insan gözüyle hayal edilemeyecek kadar çok boyutlu bir uzayda — ama mantık aynı: anlamca yakın olan şeyler, bu uzayda da yakın konumlanıyor.

İki vektörün ne kadar "yakın" olduğunu ölçmek için genelde kosinüs benzerliği (cosine similarity) kullanılıyor — iki vektör arasındaki açıyı ölçen bir hesaplama, sonuç -1 ile 1 arasında bir sayı veriyor; 1'e yakınsa neredeyse aynı anlam, 0'a yakınsa ilgisiz, negatifse zıt yönde. "Köpek havladı" ile "it ürüdü" karşılaştırıldığında bu skor genelde 0.85-0.95 bandında çıkar; "köpek havladı" ile "borsa düştü" karşılaştırıldığında ise 0.1'in altına iner. Embedding tabanlı bir arama sistemi, kullanıcının sorgusunu bir vektöre çevirip veritabanındaki tüm vektörlerle bu benzerlik skorunu hesaplıyor ve en yüksek skora sahip olanları döndürüyor — işte "semantik arama" dediğimiz şey tam olarak bu.

##Embedding Gerçekte Nerede Kullanılıyor?

Embedding, RAG sistemlerinin kalbinde duruyor — ama kullanım alanı oraya hapsolmuş değil. Pratikte en sık karşılaştığım kullanım alanları şunlar:

• ▸Semantik arama: kullanıcı tam kelimeyi bilmese bile, aradığı anlama en yakın sonuçları bulmak (e-ticaret, dokümantasyon, destek merkezi aramaları).
• ▸RAG (retrieval-augmented generation): bir LLM'e soruyla ilgili doküman parçalarını bulup bağlam olarak vermek.
• ▸Öneri sistemleri: "bunu alanlar şunu da aldı" yerine, ürün açıklamalarının anlamca yakınlığına dayalı öneri çıkarmak.
• ▸Tekilleştirme (deduplication): aynı ürünün, aynı sorunun ya da aynı destek talebinin farklı kelimelerle yazılmış kopyalarını yakalamak.
• ▸Kümeleme ve sınıflandırma: binlerce müşteri yorumunu ya da destek talebini, kimse etiketlemeden konu kümelerine ayırmak.
• ▸Anomali tespiti: bir metnin, geri kalan kümeden anlamca ne kadar uzak düştüğünü ölçerek alışılmadık içeriği yakalamak.

Ortak payda şu: embedding, "bu ikisi birbirine ne kadar benziyor?" sorusuna sayısal bir cevap veriyor. Bu soru cevaplanabildiği anda arama, öneri, gruplama ve eşleştirme gibi çok farklı problemler aynı temel araçla çözülebiliyor.

##Embedding Modeli Nasıl Seçilir, Maliyeti Nasıl İşliyor?

Embedding modelleri genelde boyut (dimension) ile anılır — 384, 768, 1536, 3072 gibi. Daha yüksek boyut genelde daha ince anlam farklarını yakalıyor ama iki bedeli var: depolama alanı büyüyor ve benzerlik hesaplaması yavaşlıyor. Milyonlarca kayıtla çalışan bir sistemde 3072 boyutlu bir embedding, 384 boyutluya göre sekiz kat daha fazla disk ve sekiz kat daha yavaş arama anlamına gelebilir. Küçük-orta ölçekli bir proje için genelde orta boy bir model (768-1536 boyut civarı) hem kaliteyi hem performansı makul bir dengede tutuyor; milyonlarca kaydı olmayan bir sistemde boyut farkının kalitede yarattığı iyileşme çoğu zaman gözle görülür değil.

Maliyet tarafında embedding, bir LLM'den yanıt üretmekten çok daha ucuz — çünkü model metin üretmiyor, sadece bir vektöre sıkıştırıyor. Asıl maliyet kalemi genelde embedding'in kendisi değil, onu sakladığınız vektör veritabanı ve her sorguda yapılan benzerlik hesaplaması. Açık kaynak modeller (kendi sunucunuzda çalıştırılabilen) ile bulut sağlayıcıların API'leri arasındaki seçim de burada devreye giriyor: veri gizliliği kritikse ya da hacim çok yüksekse kendi barındırdığınız bir model; hızlı başlamak ve bakım yükünü azaltmak önemliyse bir API daha mantıklı bir başlangıç noktası oluyor.

##Gerçek Bir Senaryo: Bir E-Ticaret Kataloğunda Yinelenen Ürünleri Yakalamak

Üç farklı tedarikçiden ürün alan orta ölçekli bir e-ticaret sitesini düşünün. Aynı kablosuz kulaklık modeli, üç farklı tedarikçi tarafından üç farklı başlıkla sisteme girilmiş: "Kablosuz Bluetooth Kulaklık Siyah", "BT 5.0 Kulak İçi Kulaklık - Siyah Renk" ve "Wireless Earbuds Black Edition". Klasik bir anahtar kelime eşleştirmesi bu üçünü aynı ürün olarak yakalayamaz çünkü ortak kelime oranı düşük. Çözüm: her ürün başlığı ve kısa açıklaması bir embedding modelinden geçiriliyor, çıkan vektörler bir vektör veritabanına kaydediliyor. Ardından her yeni ürün eklendiğinde, sistem o ürünün vektörünü mevcut kataloğun tamamıyla karşılaştırıp kosinüs benzerliği 0.9'un üzerinde olan kayıtları "olası yinelenen" olarak işaretliyor. Bu eşik çok düşük tutulursa alakasız ürünler yanlışlıkla eşleşir (örneğin "kulaklık" ile "kulak temizleme çubuğu"), çok yüksek tutulursa gerçek yinelenenler kaçırılır — pratikte doğru eşiği bulmak birkaç yüz örnek üzerinde deneme-yanılmayla netleşiyor, tek seferde doğru çıkmıyor. Sonuçta işaretlenen eşleşmeler otomatik birleştirilmiyor, bir operasyon ekranına düşüyor ve insan tek tıkla onaylıyor ya da reddediyor — tam otomatik birleştirme, yanlış pozitiflerin maliyeti yüksek olduğu için tercih edilmiyor.

Bu kurulumun sonucu, elle karşılaştırmanın imkansız olduğu bir ölçekte (on binlerce ürün) saatler değil dakikalar süren bir kontrol döngüsü. Aynı mantık destek taleplerinde de işliyor: "şifremi unuttum" ile "hesabıma giremiyorum" farklı kelimelerle yazılmış olsa da embedding üzerinden aynı kategoriye düşüyor ve otomatik yönlendirme bu sayede kelime eşleşmesine değil anlam eşleşmesine dayanıyor.

##Sık Sorulan Sorular

>Embedding ile klasik anahtar kelime araması (full-text search) arasındaki fark ne?

Anahtar kelime araması, sorguda geçen kelimelerin dokümanda da geçip geçmediğine bakar — eşleşme harfi harfine veya köküne yakın olmalı. Embedding tabanlı arama ise anlam benzerliğine bakar; kelimeler tamamen farklı olsa bile anlam yakınsa sonuç bulunur. En güçlü sistemler ikisini birlikte kullanır (hybrid search): anahtar kelime araması tam eşleşen terimleri (ürün kodu, marka adı gibi) yakalarken, embedding anlamca yakın ama farklı kelimelerle yazılmış sonuçları tamamlar.

>Embedding boyutu (dimension) ne demek, büyük olan her zaman daha mı iyi?

Hayır. Boyut, bir metnin kaç sayıyla temsil edildiğini gösterir; daha yüksek boyut genelde daha ince anlam ayrımları yakalar ama depolama ve hesaplama maliyetini de artırır. Küçük-orta ölçekli bir projede orta boy bir model (768-1536 civarı) çoğu zaman en iyi performans/maliyet dengesini veriyor; milyonlarca kayıt ve çok ince anlam ayrımı gereken durumlarda daha yüksek boyut tercih edilebilir.

>Embedding modelini kendi verimle eğitmem (fine-tune) gerekir mi?

Çoğu durumda hayır. Genel amaçlı embedding modelleri gündelik dil, ürün açıklamaları ve çoğu iş metni için zaten iyi sonuç veriyor. Fine-tuning genelde çok özel bir jargonun hâkim olduğu alanlarda (hukuk, tıp, çok teknik bir sektör terminolojisi) ya da aynı kelimenin bağlama göre çok farklı anlamlara geldiği durumlarda gündeme geliyor — ve bu, küçük bir projede nadiren ilk adım olarak gerekiyor.

>Embedding modeli değişirse ya da güncellenirse eski vektörler hâlâ işe yarar mı?

Hayır, genelde yaramıyor. Farklı bir embedding modelinden çıkan vektörler aynı uzayda yer almıyor — yani eski modelle hesaplanmış vektörlerle yeni modelle hesaplanmış bir sorgu vektörünü karşılaştırmak anlamsız sonuçlar verir. Model değiştiğinde tüm kataloğun yeniden vektörleştirilmesi (re-embedding) gerekiyor; bu yüzden embedding modeli seçimini sık değiştirilecek bir ayar gibi değil, üzerine düşünülerek yapılan bir mimari karar gibi ele almak gerekiyor.

>Embedding, Türkçe gibi diller için de aynı kalitede çalışıyor mu?

Çoğu güncel model çok dilli (multilingual) eğitiliyor ve Türkçe dahil onlarca dilde makul bir performans veriyor, ama hepsi aynı seviyede değil — bazı modeller İngilizce'de çok daha güçlü, Türkçe gibi agglütinatif bir dilde ise belirgin şekilde zayıf kalabiliyor. Kritik bir sistemde modelin dokümantasyonuna körü körüne güvenmek yerine, birkaç gerçek Türkçe örnek cümleyle hızlı bir test yapıp benzerlik skorlarının beklendiği gibi çıkıp çıkmadığını kontrol etmek en güvenilir yol.

Embedding, tek başına göz alıcı bir özellik değil — ama arama, öneri, tekilleştirme ya da RAG gibi onlarca farklı problemin altında sessizce çalışan ortak bir mekanizma. Hangi problemde işinize yarayabileceğini netleştirmek için birkaç soru genelde yeterli oluyor; iletişim sayfasından yazabilirsiniz.