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 Mantığı

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.

Embedding “Neyi” Vektöre Çevirir?

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.

Metin embedding: Arama, RAG retrieval, sınıflandırma, benzer doküman bulma
Görsel embedding: Benzer görsel bulma, ürün eşleştirme, sahne/nesne benzerliği
Ses embedding: Konuşmacı benzerliği, ses parçası arama, ses sınıflandırma

Metin, Görsel, Ses: Hepsi Aynı Mantıkla mı?

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.

Vektörün Boyutu: 384 / 768 / 1536 Ne Demek?

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.

Boyut Artınca Her Zaman Daha mı İyi?

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 Nasıl Çalışı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.

Token → Katmanlar → Vektör Çıktısı

Bir cümle modele girer:

Metin tokenize edilir (alt parçalara bölünür).
Her token bir başlangıç vektörüne dönüştürülür.
Transformer katmanları bağlamı öğrenir (hangi kelime hangi kelimeyle ilişkili?).
Çıktıda “tek bir vektör” elde etmek için pooling yapılır (ör. mean pooling).

“Anlam” Vektörde Nasıl Temsil Edilir?

“Anlam”, vektör uzayındaki konumla temsil edilir. Benzer anlamlı cümleler uzayda birbirine yaklaşır. Örneğin:

“Faturadaki toplam tutar nedir?”
“Belgedeki ödenecek miktarı bul.”

Bu iki cümle kelime olarak farklı olsa da embedding’leri yakın olma eğilimindedir.

Cosine Similarity ile Benzerlik Hesabı

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.

Cosine mı, Dot Product mı, L2 mi?

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.

Embedding ile Semantic Search

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.

Anahtar Kelime Arama ile Farkı

Klasik arama (keyword) “kelime geçiyor mu?” diye bakar. Semantic search “aynı şeyi farklı söylemiş mi?” sorusuna daha iyi cevap verir. Bu özellikle:

eş anlamlılar,
farklı yazım biçimleri,
kullanıcının doğru terimi bilmemesi,
çok kısa/çok doğal dil sorguları

gibi durumlarda ciddi fark yaratır.

“Benzer Anlam” Yakalama Örnekleri

Ö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.

Top-K Sonuçlar ve Re-Ranking Mantığı

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.

Yanlış Eşleşmeler Neden Olur?

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’ler Nerede Kullanılır?

Embedding, sadece arama değil, pek çok ML probleminde güçlü bir ara temsildir. “Benzerlik” üzerinden birçok iş kolaylaşır.

Arama, Öneri, Sınıflandırma, Kümeleme

Arama: semantic search, RAG retrieval
Öneri: “benzer ürün/içerik” önerileri
Sınıflandırma: embedding + küçük bir classifier ile hızlı çözüm
Kümeleme: dokümanları konu kümelerine ayırma

Deduplication ve Near-Duplicate Tespiti

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.

Anomali Tespiti için Vektör Yaklaşımı

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.

Hangi Problemde Hangi Yöntem Daha Mantıklı?

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 ile Embedding İlişkisi

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’de Embedding’in Rolü: “Retrieve” Katmanı

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 ve Embedding Kalitesi

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.

Chunk Boyutu, Overlap ve Kayıp Bilgi Problemi

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.

Embedding Kötüyse RAG Nasıl Çöker?

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.

Vector Database ve Index Mantığı

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.

pgvector, Qdrant, Milvus: Embedding’i Nasıl Saklar?

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.

HNSW / IVF: Hız-Doğruluk Dengesi

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.

Filtreleme: Metadata + Vektör Arama Birlikte

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.

Gerçek Hayatta En Yaygın Tasarım Hataları

Chunking’i rastgele yapmak (doküman türüne göre ayarlamamak)
Metadata filtresi olmadan her şeyi tek havuza atmak
Re-ranking kullanmamak (özellikle benzer dokümanların çok olduğu yerde)
Model değişiminde yeniden-embedding planı olmaması

Embedding Modeli Seçimi

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ç mı, Domain-Özel mi?

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 İçerikte Nelere Dikkat Etmeli?

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.

Multi-lingual Modeller Ne Zaman Gerekli?

İç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.

Model Değişince Eski Vektörler Ne Olur?

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.

Kalite Ölçümü ve Test

“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.

Retrieval Kalitesi Nasıl Ölçülür?

Ö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.

Recall@K, MRR, nDCG Basit Anlatım

Recall@K: İlk K sonuç içinde doğru parça var mı?
MRR: Doğru parça kaçıncı sırada? (erken gelirse puan artar)
nDCG: Birden fazla alakalı sonuç varsa “sıralama kalitesi”

Altın Soru Seti (Golden Set) Oluşturma

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 mi, Online A/B mi?

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.

Güvenlik ve KVKK Perspektifi

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 İçinde Veri Sızar mı?

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.

PII Maskeleme ve Erişim Kontrolü

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 Kurulumda Dikkat Edilecekler

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.

Loglama: Ne Kaydedilmeli, Ne Kaydedilmemeli?

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).

#Semantic Search ile Etiketlenmiş Yazılar

Embedding Nedir? Anlamı Vektörlere Çeviren Teknoloji (2025 Rehberi)