Kazanimlar:
- Embedding'in metni anlam uzayında bir vektöre çevirdiğini ve benzer anlamların yakın vektörler olduğunu kavramak
- Cosine ve dot benzerlik ölçütleriyle ANN aramanın nasıl çalıştığını açıklamak
- Yaygın vektör veritabanlarını maliyet, ölçek ve metadata filtreleme ihtiyacına göre seçmek
RAG'in kalbinde tek bir soru var: "Kullanıcının sorusuna en çok hangi metin parçası benzer?" Bilgisayar metni anlamıyla değil, sayılarla işler. Bu yüzden metni önce anlamını taşıyan sayılara çevirmemiz gerekir. İşte embedding budur: bir metni, o metnin anlamını temsil eden bir sayı dizisine (vektöre) dönüştüren işlem. Bu üniteyi bitirdiğinizde embedding'in nasıl çalıştığını, benzerliğin nasıl ölçüldüğünü ve doğru vektör veritabanını (vector database) nasıl seçeceğinizi bileceksiniz.
Embedding: Anlamı Koordinata Çevirmek
Bir embedding modeli (bu iş için özel eğitilmiş bir yapay zeka), verdiğiniz metni örneğin 1024 sayıdan oluşan bir vektöre çevirir. Bu vektörü, çok boyutlu bir uzayda bir koordinat gibi düşünün. Sihir şudur: anlamca benzer metinler bu uzayda birbirine yakın koordinatlara düşer.
Basit bir örnek: "yıllık izin", "tatil hakkı" ve "yıllık ücretli izin" farklı kelimeler kullanır ama aynı şeyi anlatır — vektörleri birbirine yakındır. "Bordro hesabı" ise farklı bir konudur — vektörü uzaktadır. Böylece kullanıcı "kaç gün tatil hakkım var?" diye sorduğunda, içinde "tatil" kelimesi geçmeyen ama "yıllık izin 14 gündür" yazan bir dokümanı bile bulabiliriz. Bu, klasik anahtar kelime aramasının (kelimeyi birebir eşleştiren arama) yapamadığıdır.
İpucu: Embedding'i "anlamın parmak izi" gibi düşünün. Aynı anlamı taşıyan iki cümlenin parmak izleri benzer çıkar; kelimeleri farklı olsa bile.
Önemli bir kural: soruyu embed ederken kullandığınız model ile dokümanları embed ederken kullandığınız model aynı olmalıdır. Farklı modeller farklı uzaylar üretir; koordinatlar kıyaslanamaz hâle gelir.
Benzerlik Nasıl Ölçülür?
İki vektörün ne kadar benzediğini ölçmek için birkaç yöntem var. En yaygını cosine benzerliği (kosinüs benzerliği): iki vektör arasındaki açıyı ölçer. Açı küçükse (vektörler aynı yöne bakıyorsa) benzerlik yüksektir. Değer −1 ile 1 arasındadır; 1'e yakın = çok benzer.
Ölçüt
Neyi ölçer
Ne zaman tercih edilir
Cosine (kosinüs)
Vektörler arasındaki açı (yön)
En yaygın; metin anlam benzerliğinde varsayılan
Dot product (nokta çarpımı)
Yön + büyüklük birlikte
Vektörler normalize edilmişse cosine ile aynı sonucu verir; hızlıdır
Euclidean (öklid uzaklığı)
Koordinatlar arası düz mesafe
Bazı kümeleme senaryolarında; metinde daha az kullanılır
Pratikte çoğu embedding modeli normalize (boyları 1'e ayarlanmış) vektör üretir; bu durumda cosine ve dot product aynı sıralamayı verir. Karar felç olmayın: cosine ile başlayın.
Milyonlarca vektör içinde her seferinde hepsini tek tek kıyaslamak yavaştır. Bu yüzden vektör veritabanları ANN (Approximate Nearest Neighbor, yaklaşık en yakın komşu) algoritmaları kullanır. ANN, "kesin en yakını" yerine "neredeyse kesin en yakınları" çok hızlı bulur. Örneğin HNSW denen yöntem, 10 milyon vektörde bile birkaç milisaniyede sonuç döndürebilir. Küçük bir doğruluk ödünü karşılığında büyük hız kazanırsınız.
Vektör Veritabanı Ne Yapar?
Bir vektör veritabanı üç işi bir arada yapar: (1) vektörleri saklar, (2) bir sorgu vektörüne en benzer vektörleri hızlıca bulur, (3) her vektörün yanındaki metadata ile filtreleme yapar. Metadata, o parçaya iliştirdiğiniz etiketlerdir: kaynak dosya, tarih, departman, gizlilik seviyesi gibi. Metadata filtreleme kurumsal RAG'de kritiktir; çünkü "sadece Finans departmanının 2025 dokümanlarında ara" gibi kısıtlar koyabilmeniz gerekir.
# Vektör veritabanına kayıt (kavramsal)vektor_db.ekle( id="izin-politikasi-parca-3", vektor=embed("Yıllık ücretli izin 14 gündür..."), metin="Yıllık ücretli izin 14 gündür...", metadata={"kaynak": "ik_el_kitabi.pdf", "departman": "IK", "tarih": "2025-06", "gizlilik": "ic"})
# Metadata filtreli arama (kavramsal)sonuc = vektor_db.ara( vektor=embed("kaç gün iznim var?"), top_k=4, filtre={"departman": "IK", "gizlilik": ["ic", "acik"]})
Doğru Veritabanını Seçmek
Araç
Öne çıkan yönü
Uygun olduğu durum
Yerleşik / dosya-tabanlı (gömülü kütüphane)
Kurulum yok, tek makine
Prototip, küçük set (< birkaç yüz bin parça)
Yönetilen bulut servisi
Ölçekleme ve bakım sizde değil
Üretim, hızlı büyüyen veri, küçük ekip
Kendi sunucunuzda açık kaynak
Tam kontrol, veri sizde kalır
Gizlilik zorunluğu, mevcut altyapı
Mevcut veritabanına eklenti
Ayrı sistem yönetmezsiniz
Zaten kullandığınız DB'ye vektör desteği eklemek
Seçerken sorun: Kaç parça olacak? Metadata filtreleme ne kadar kritik? Veri şirket dışına çıkabilir mi (gizlilik)? Ekip bir altyapıyı işletebilir mi? Küçük başlayıp gerektiğinde büyütmek çoğu zaman en akıllıca yoldur.
Zayıf Yaklaşım / Güçlü Yaklaşım
Zayıf (embedding'i düz saklamak, metadata yok):
Sadece metni ve vektörü kaydet. Arama: en benzer 4 vektörü getir.# Sorun: "sadece güncel HR dokümanları" gibi filtre yapılamaz;# eski/yetkisiz parçalar da cevaba karışabilir.
Güçlü (zengin metadata + filtreli arama):
Her parçaya kaynak, tarih, departman ve gizlilik etiketi ekle.Arama sırasında kullanıcının yetkisine ve güncelliğe göre filtrele:filtre = {"gizlilik": kullanici_yetkisi, "tarih_gte": "2024-01"}# Böylece hem güvenli hem güncel sonuç gelir.
Üç Mini Vaka
Vaka 1 — Yanlış model karışımı. Bir ekip dokümanları A modeliyle, soruları B modeliyle embed etmiş. Aramalar anlamsız sonuç dönmüş, doğru-cevap oranı %31'de kalmış. Tek modele geçince (her ikisi de aynı embedding modeli) oran %88'e fırlamış. Ders: soru ve doküman aynı uzayda olmalı.
Vaka 2 — Metadata olmadan gizlilik riski. Bir sağlık şirketinde tüm departman dokümanları metadata'sız tek havuza atılmış. Bir satış çalışanı soru sorduğunda sistem, hasta verisi içeren bir parçayı bağlama getirmiş. Metadata + filtre eklenince (yetki seviyesine göre) bu risk kapanmış; retrieval'da yetkisiz 12 parça hiç getirilmez olmuş.
Vaka 3 — Ölçek darboğazı. Bir e-ticaret firması 8 milyon ürün açıklamasını basit "hepsini tara" yöntemiyle aramış; her sorgu 6 saniye sürmüş. HNSW tabanlı ANN'e geçince süre 45 milisaniyeye inmiş, doğrulukta sadece %1 kayıpla. Ders: büyük sette ANN zorunludur.
Sık yapılan hatalar
- Soru ve dokümanı farklı modellerle embed etmek: Sonuçlar anlamsız çıkar; her zaman tek model.
- Metadata'yı atlamak: Filtre yapamazsınız; gizlilik ve güncellik kontrolünü kaybedersiniz.
- Embedding'i şifreleme sanmak: Embedding tersine çevrilebilir bilgi taşır; hassas veriyi "gizlendi" varsaymak yanlıştır.
- Küçük sette gereksiz büyük altyapı kurmak: 5.000 parça için yönetilen dev bir küme gereksiz karmaşıklıktır.
- Benzerlik ölçütünü fazla dert etmek: Metinde cosine ile başlayın; ince ayar sonradan gelir.
Dikkat: Embedding, metnin anlamını sayılara gömer ama içeriği "yok etmez". Bir vektör veritabanı sızarsa, saklanan orijinal metinler de (çoğu kurulumda metin de saklanır) tehlikeye girer. Vektör deposunu, içindeki dokümanlar kadar gizli tutun.
Özetle
- Embedding, metni anlamını taşıyan bir sayı vektörüne çevirir; benzer anlamlar yakın vektörlerdir.
- Benzerlik çoğunlukla cosine ile ölçülür; normalize vektörlerde dot product aynı sonucu verir.
- Büyük veride ANN (ör. HNSW) kesin aramanın yerini alır: küçük doğruluk ödünüyle büyük hız.
- Vektör veritabanı vektör saklama + benzerlik araması + metadata filtreleme yapar; metadata kurumsal RAG için şarttır.
- Soru ve doküman aynı embedding modeliyle çevrilmelidir; aksi hâlde koordinatlar kıyaslanamaz.
Uygulama görevi
Bir önceki ünitede seçtiğiniz dokümandan 10 kısa parça (her biri 3-6 cümle) çıkarın. (1) Her parçaya en az üç metadata etiketi tasarlayın (kaynak, tarih ve iş bağlamınıza uygun bir üçüncü: departman, ürün, gizlilik vb.). (2) 3 farklı kullanıcı sorusu için hangi metadata filtresinin uygulanması gerektiğini yazın. (3) Aynı anlamı farklı kelimelerle ifade eden 3 soru-parça çifti bulun (ör. "tatil hakkı" ↔ "yıllık izin") ve bunların neden anahtar kelime aramasıyla eşleşmeyeceğini ama embedding ile eşleşeceğini bir cümleyle açıklayın.
Kontrol listesi
- [ ] Embedding'in metni anlam uzayında bir vektöre çevirdiğini ve benzer anlamların yakın olduğunu anlatabiliyorum.
- [ ] Cosine benzerliğinin açı ölçtüğünü ve metinde varsayılan tercih olduğunu biliyorum.
- [ ] ANN'in neden büyük veride gerekli olduğunu açıklayabiliyorum.
- [ ] Metadata'nın neden gizlilik ve güncellik kontrolü için kritik olduğunu biliyorum.
- [ ] Soru ve dokümanı aynı embedding modeliyle çevirme kuralını uyguluyorum.