Vektör veritabanına gerçekten ne zaman ihtiyacınız var? Embedding'ler üzerine pratik bir rehber

"Belgelerimiz hakkında soru cevaplayan bir sistem kuracağız" kararının hemen ardından gelen soru genellikle "hangi vektör veritabanını kullanalım?" olur. Karşılaştırma tabloları okunur, hesaplar açılır, bir altyapı kurulur. Oysa ellerindeki belge sayısı birkaç bindir ve bütün vektörler bir dizüstü bilgisayarın belleğine rahatça sığar.

Vektör veritabanları gerçek bir ihtiyaca cevap verir. Ama o ihtiyaç çoğu zaman sanıldığı yerde, yani ölçekte değildir. Bu yazı önce embedding'lerin ne olduğunu, sonra bir veritabanına ne zaman gerçekten ihtiyaç duyduğunuzu anlatıyor.

Embedding nedir?

Bir metnin anlamını temsil eden, sabit uzunlukta bir sayı listesidir.

Bir embedding modeli "iade süresi ne kadar?" cümlesini alır ve birkaç yüz ya da birkaç bin sayıdan oluşan bir vektöre çevirir. Anlamca birbirine yakın metinler birbirine yakın vektörler üretir: "ürünü kaç gün içinde geri gönderebilirim?" cümlesi, hiçbir ortak kelimesi olmasa da ilkine yakın düşer. Anlamsal aramanın bütün fikri budur: soruyu ve belgeleri aynı uzaya çevirmek ve soruya en yakın belgeleri bulmak.

Benzerlik puanı neyi söyler, neyi söylemez?

İki metnin birbirine ne kadar benzediğini söyler; belgenin soruyu cevaplayıp cevaplamadığını söylemez.

Yakınlık genellikle kosinüs benzerliğiyle ölçülür ve en yakın sonuç her zaman vardır. Sorduğunuz şeyin cevabı belgelerinizde hiç yoksa bile arama size bir "en yakın" sonuç döndürür. Bu yüzden getirme sisteminin bir yerinde, gelen sonucun kullanılacak kadar iyi olup olmadığına karar veren bir adım olmalıdır.

İkinci tuzak eşik değerleridir. Bir blog yazısında "0,8'in üstü alakalıdır" diye okuduğunuz bir sayı, başka bir embedding modelinde, başka bir dilde ya da başka bir belge türünde hiçbir şey ifade etmez. Puanların dağılımı modelden modele değişir. Doğru eşik, kendi sorularınız ve kendi belgelerinizle ölçülerek bulunur.

Vektör veritabanına ne zaman ihtiyaç vardır?

Ölçek için değil, genellikle kalıcılık, filtreleme ve silme için.

Birkaç on bin parçaya kadar bütün vektörleri bellekte tutup her soruda hepsiyle karşılaştırmak hem basit hem de yeterince hızlıdır. Bir veritabanına geçmeyi gerçekten haklı çıkaran ihtiyaçlar genellikle şunlardır:

• Kalıcılık: Uygulama her yeniden başladığında bütün belgeleri yeniden embed etmek istemiyorsunuz.
• Filtreleme: "Yalnızca bu müşterinin belgelerinde ara" ya da "yalnızca son bir yıl" gibi koşullar gerekiyor. Çok kullanıcılı bir sistemde bu bir güvenlik gereğidir: bir müşterinin sorusu başka bir müşterinin belgesini getirmemelidir.
• Silme ve güncelleme: Bir belge değiştiğinde ya da bir kullanıcı verisinin silinmesini istediğinde, ilgili vektörleri bulup kaldırabilmeniz gerekir.
• Gerçek ölçek: Milyonlarca parça ve düşük gecikme gerektiğinde, yaklaşık en yakın komşu (ANN) indeksleri devreye girer.

Çoğu proje için iyi bir ilk adım, zaten kullandığınız ilişkisel veritabanının vektör desteğidir: verileriniz ve vektörleriniz aynı yerde durur, filtreleme sıradan bir sorgu koşulu olur.

Anahtar kelime araması ne zaman daha iyidir?

Kesin bir değer arandığında: ürün kodu, hata mesajı, kişi ya da yer adı.

Embedding'ler anlamı yakalamakta iyidir ama "ERR-4021" gibi bir kodu ya da az geçen bir özel adı yakalamakta zayıf kalabilir. Bu tür sorularda klasik anahtar kelime araması daha güvenilirdir. Bu yüzden gerçek sistemlerde sık görülen çözüm hibrit aramadır: iki aramayı birlikte çalıştırıp sonuçlarını birleştirmek. Hangisinin sizin sorularınızda daha iyi çalıştığını yine ancak ölçerek bilebilirsiniz.

Embedding modelini değiştirmek neden pahalıdır?

Çünkü farklı modellerin vektörleri birbiriyle karşılaştırılamaz; değiştirdiğinizde her şeyi yeniden embed etmeniz gerekir.

Bir modelin ürettiği vektör uzayı ona özgüdür. Yeni bir modelle soruyu embed edip eski modelle üretilmiş belge vektörleriyle karşılaştırmak anlamsız sonuçlar verir. Bu yüzden embedding modeli seçimi, ilk bakışta göründüğünden daha kalıcı bir karardır. Her vektörün yanında hangi modelle üretildiğini kaydetmek ve yeniden embed etmenin süresini ve maliyetini baştan hesaplamak, ileride yaşanacak sürprizlerin en yaygınını önler.

Belgeler nasıl parçalara bölünmeli?

Anlam birimlerine göre; sabit karakter sayısına göre değil.

Bir belgeyi her beş yüz karakterde bir kesmek en kolay yöntemdir ve en sık hataya yol açanıdır: bir tabloyu ortadan, bir paragrafı cümlenin ortasından böler. Daha iyi sonuç veren yaklaşım, başlıklara ve paragraflara göre bölmek, parçalar arasında küçük bir örtüşme bırakmak ve her parçanın başına ait olduğu bölümün başlığını eklemektir. Bu basit ekleme, arama kalitesine çoğu zaman embedding modelini değiştirmekten daha fazla katkı yapar. Kendi verinizde denemenin maliyeti birkaç satır koddur.

Embedding ve arama kavramlarının tamamını, birbirleriyle bağlantılarıyla birlikte ücretsiz bilgi haritasında görebilirsiniz.

Kaynaklar

• Cohere: What are embeddings?: embedding kavramına sağlayıcı gözünden kısa bir giriş. (eklenme: 2026-08)
• Sentence Transformers: semantic search: bir veritabanı olmadan anlamsal aramanın nasıl yapıldığı. (eklenme: 2026-08)
• FAISS wiki: guidelines for choosing an index: hangi ölçekte hangi indeks türünün gerektiği. (eklenme: 2026-08)
• MTEB: Massive Text Embedding Benchmark: embedding modellerinin karşılaştırması; kendi verinizde ölçmenin yerini tutmaz. (eklenme: 2026-08)