Embedding, metin/görsel/ses gibi verileri bilgisayarın “anlam” düzeyinde karşılaştırabilmesi için sayısal bir temsile (vektöre) dönüştürme yöntemidir. Basitçe: “benzer şeyleri” uzayda birbirine yaklaştırır, “farklı şeyleri” uzaklaştırır. Bu sayede anahtar kelime aramasıyla yakalanamayan bağlamsal benzerlikler bulunabilir; RAG sistemleri doğru paragrafları çekebilir; öneri, sınıflandırma, kümleme gibi görevler daha güçlü hale gelir.
Bu yazıda embedding’in mantığını, nasıl üretildiğini, semantic search ve RAG içindeki rolünü, vektör veritabanlarını, model seçimini, kalite ölçümünü ve KVKK güvenlik boyutunu net örneklerle ele alacağız.
Embedding’in temel fikri şudur: Bir içeriğin (cümle, paragraf, doküman, görsel vb.) “anlamını” sayısal bir vektöre kodlarsın. Bu vektörler üzerinde matematiksel benzerlik hesapları yaparak “en yakın anlamlı” sonuçları bulursun.
En yaygın kullanım metin embedding’idir: bir cümleyi ya da doküman parçasını tek bir vektöre dönüştürür. Ama embedding yalnızca metin değildir; modern modeller görsel, ses, video, hatta tablo gibi çoklu modaliteyi de vektör uzayına taşıyabilir.
Evet, ortak mantık aynı: içerik → model → vektör. Fark, modelin eğitildiği veri ve hedef fonksiyonda. Örneğin çok-modlu modellerde metin ve görsel “aynı uzaya” oturtularak “bu görselin açıklaması hangi metin?” gibi eşleştirmeler yapılabilir.
Bu sayılar embedding vektörünün kaç elemandan oluştuğunu (boyutunu) ifade eder. Boyut büyüdükçe model daha fazla “özellik” taşıyabilir; ama depolama, index maliyeti ve sorgu süresi de artar. Pratikte 384–1536 bandı çok yaygındır.
Hayır. Boyut artışı bazen kaliteyi artırır ama her zaman değil. Domain’in (Türkçe, sigorta dokümanları, teknik yazılar vb.) doğası, chunk yapısı ve arama stratejisi daha belirleyicidir. Ayrıca yanlış chunking, en iyi embedding’i bile zayıflatır.
Embedding üretimi genelde transformer tabanlı modellerle yapılır. Model, girdi metni token’lara böler, katmanlardan geçirir ve en sonunda metni temsil eden bir vektör üretir.
Bir cümle modele girer:
“Anlam”, vektör uzayındaki konumla temsil edilir. Benzer anlamlı cümleler uzayda birbirine yaklaşır. Örneğin:
Bu iki cümle kelime olarak farklı olsa da embedding’leri yakın olma eğilimindedir.
En sık kullanılan ölçü cosine similarity’dir. İki vektörün yön benzerliğini ölçer (büyüklükten çok yön önemlidir). Aramada amaç genellikle sorgu vektörüne en çok benzeyen (en yüksek cosine) vektörleri bulmaktır.
Hepsi kullanılır. Cosine çoğu metin senaryosunda güvenli bir default’tur. Dot product bazı index ve model kombinasyonlarında hızlı/uygun olabilir. L2 (Öklid) mesafesi özellikle normalize edilmemiş vektörlerde farklı davranır. En doğru seçim: kullandığın embedding modelinin önerdiği ve ölçümle (MRR/Recall@K) en iyi çıkan metriktir.
Semantic search, “kelime eşleşmesi” yerine “anlam benzerliği” ile arama yapmaktır. Kullanıcı sorgusunu embedding’e çevirir, veri tabanındaki embedding’lerle karşılaştırır ve en yakın sonuçları döndürür.
Klasik arama (keyword) “kelime geçiyor mu?” diye bakar. Semantic search “aynı şeyi farklı söylemiş mi?” sorusuna daha iyi cevap verir. Bu özellikle:
gibi durumlarda ciddi fark yaratır.
Örnek: “poliçe no” ile “sigorta sözleşme numarası” aynı alanı işaret edebilir. Keyword arama bazen kaçırır; semantic search bu eşleşmeyi yakalama olasılığını artırır.
Retrieval aşamasında genelde Top-K (ör. 10, 20, 50) sonuç çekilir. Ardından re-ranking ile daha iyi sıralama yapılır. Re-ranker, daha pahalı ama daha doğru bir modelle (ör. cross-encoder) “hangi sonuç gerçekten en alakalı?” sorusunu çözer.
En yaygın nedenler: yanlış chunking (çok uzun/çok kısa parçalar), yetersiz domain uyumu, kirli metin (OCR hataları), yetersiz metadata filtreleri ve eksik re-ranking. Bu yüzden embedding tek başına değil, “pipeline” olarak düşünülmelidir.
Embedding, sadece arama değil, pek çok ML probleminde güçlü bir ara temsildir. “Benzerlik” üzerinden birçok iş kolaylaşır.
Aynı içerik farklı yazılmış olabilir (özellikle OCR sonrası). Embedding ile benzerlik eşiği belirleyip “neredeyse aynı” içerikleri bulabilirsin. Bu, veri temizliği ve bilgi tabanı kalitesi için çok değerlidir.
Vektör uzayında “normal örneklerin” yoğunlaştığı bölgeler oluşur. Bu yoğunluk dışındaki örnekler anomali olabilir. Örneğin bir doküman türü normalde “poliçe” iken bir anda “dilekçe” benzeri bir dil kullanıyorsa embedding uzayında sapabilir.
Arama/RAG için embedding neredeyse standarttır. Sınıflandırmada veri azsa embedding + basit model çok işe yarar. Kümeleme/anomali içinse iyi bir ön-işleme (temizlik, OCR düzeltme) ve doğru metrik seçimi kritik olur.
RAG’in “R” (Retrieval) kısmı çoğu senaryoda embedding ile çalışır. Yani embedding, RAG’de LLM’e doğru kaynağı buldurmanın ana motorudur.
RAG akışı özetle: Sorgu → embedding → vektör arama → ilgili chunk’lar → LLM → cevap. Bu zincirde embedding kalitesi düşükse LLM “doğru belgeyi” görmez ve en iyi prompt bile yetmez.
Chunking, dokümanı hangi parçalara böleceğini belirler. Çok uzun chunk: çok gürültü, düşük odak. Çok kısa chunk: bağlam kaybı. İdeal chunk, “tek bir fikri” taşıyacak kadar küçük ama bağlamı kaybetmeyecek kadar büyük olmalıdır.
Overlap (örtüşme), cümlelerin chunk sınırında bölünüp bağlam kaybetmesini azaltır. Ama overlap arttıkça veri büyür, maliyet artar. Dengeli bir ayar, hem kaliteyi hem maliyeti optimize eder.
Yanlış chunk’lar çekilirse LLM “halüsinasyon” yapmaya daha yatkın olur. Çünkü model “kaynak” yerine tahmin üretir. Bu yüzden RAG kalitesi için embedding + chunking + re-ranking birlikte tasarlanmalıdır.
Embedding’leri saklamak için basit bir tabloda tutmak mümkündür ama büyük ölçekte hızlı arama için vektör index gerekir. Vektör veritabanları veya pgvector gibi eklentiler bu işi optimize eder.
Temel olarak hepsi şunu yapar: vektör + metadata saklar, benzerlik sorgusu alır, en yakın komşuları döndürür. Farklar; ölçek, yönetim kolaylığı, dağıtık mimari, filtreleme, index seçenekleri ve operasyonel yükte ortaya çıkar.
Bu index yapıları “yaklaşık en yakın komşu” (ANN) araması yapar. Amaç: milyonlarca vektörde hızlı sonuç üretmek. Hız arttıkça bazen doğruluk (gerçek en yakını bulma) azabilir; iyi ayarlarla denge kurulur.
Kurumsal senaryoda sadece “benzerlik” yetmez. Örneğin “sadece 2025 poliçeleri”, “sadece müşteri X”, “sadece TR dilindeki dokümanlar” gibi filtreler gerekir. Bu yüzden metadata alanları (tarih, kaynak, departman, izin seviyesi) tasarımın parçasıdır.
Doğru embedding modeli seçimi, tüm pipeline’ın temel taşlarından biridir. Tek bir “en iyi” model yoktur; kullanım senaryosu ve dil/domain belirleyicidir.
Genel amaç modeller hızlı başlatır, geniş kapsama sunar. Domain-özel (ör. sigorta/finans dokümanları) modeller ise doğru veriyle daha iyi retrieval kalitesi verebilir. Pratik yaklaşım: önce genel amaçla MVP, sonra ölçümlere göre domain optimizasyonu.
Türkçe eklemeli bir dil olduğu için kelime biçimleri çok değişir. Bu yüzden Türkçe’de iyi performans veren çok dilli modeller veya Türkçe odaklı modeller daha tutarlı retrieval sağlayabilir. Ayrıca OCR kaynaklı hatalar (ı/i, ş/s, ğ/g vb.) embedding’i etkileyebilir; temel metin temizliği önemlidir.
İçerik hem Türkçe hem İngilizce ise veya kullanıcı farklı dillerde sorgu atıyorsa çok dilli embedding kritik olur. Tek dilli model kullanıp çapraz dil sorguda zorlanmak yaygın bir hatadır.
Genellikle yeniden embedding gerekir. Çünkü farklı model, farklı uzay üretir; eski vektörlerle yeniler karışınca benzerlik anlamını kaybeder. Bu yüzden “model versiyonu” metadata’sı ve yeniden indeksleme planı iyi bir mühendislik pratiğidir.
“Embedding iyi mi?” sorusu hisle değil, ölçümle cevaplanır. RAG ve arama sistemlerinde temel hedef: doğru parçayı doğru sırada getirmek.
Önce bir “soru → doğru chunk” eşleştirme seti (golden set) hazırlanır. Sonra sistemin Top-K sonuçlarında doğru chunk’ı kaçıncı sırada getirdiği ölçülür.
10–30 soru ile başlayıp (MVP), sonra 100+ soruya genişletmek iyi bir pratiktir. Sorular gerçek kullanıcı diliyle yazılmalı ve her bir sorunun “doğru kaynağı” net olmalıdır.
Offline test hızlıdır ve geliştirme sırasında idealdir. Online A/B ise gerçek kullanıcı davranışına göre nihai doğrulamadır. Kurumsal projelerde önce offline metriklerle ilerleyip, pilotta online ölçümlemek genelde en sağlıklı yoldur.
Kurumsal bilgiyle çalışırken embedding sadece teknik bir konu değildir; veri güvenliği ve KVKK uyumu da tasarımın parçasıdır.
Embedding, metnin aynısı değildir ama “bilgi taşıyabilir”. Bu yüzden hassas veri (PII) barındıran içeriklerde maskeleme, erişim kontrolü ve log politikası kritik hale gelir.
Kimlik no, telefon, adres, IBAN gibi alanlar mümkünse indexing öncesi maskeleme/anonimleştirme ile kontrol altına alınır. Ayrıca kullanıcı bazlı yetkilendirme ile “hangi vektörler kim tarafından aranabilir” net olmalıdır.
On-prem kurulum, veri egemenliği açısından avantaj sağlar; ancak anahtar yönetimi, yedekleme, izleme, erişim kayıtları gibi operasyonel konular iyi kurgulanmalıdır.
Sorgu metnini ve çekilen chunk’ları loglamak debug için faydalıdır ama KVKK açısından riskli olabilir. En güvenlisi: gerektiğinde maskelenmiş/sınırlı log, kısa süreli saklama, rol bazlı erişim ve denetim izi (audit trail).
Embedding, metin veya veriyi sayısal bir vektöre dönüştürerek anlam benzerliği üzerinden karşılaştırma yapılmasını sağlayan temsil yöntemidir.
Semantic search, RAG (retrieval), öneri sistemleri, sınıflandırma, benzer doküman bulma ve kümeleme gibi birçok alanda kullanılır.
Hayır. Embedding vektörün kendisidir; vektör veritabanı ise bu vektörleri saklayıp hızlı benzerlik araması yapan altyapıdır.
Boyut; vektörün kaç elemandan oluştuğunu belirtir. Performans/kalite/maliyet dengesi açısından doğru boyut ve model seçimi önemlidir.
RAG (Retrieval-Augmented Generation), LLM’leri kurumsal dokümanlarla konuşturmanın en etkili yoludur. Bu rehberde RAG’in mantığını, mimarisini, chunking ve semantic aramayı, doğruluk ve güvenlik boyutlarını net örneklerle açıklıyoruz.