TEKNİK YAZI / Yapay Zekâ Entegrasyonları

Vector Database: Anlamsal Arama ve RAG Altyapısı

Vector database yapısı: embedding, HNSW ve IVF indeksleri, metadata filtresi, BM25 ile hibrit arama, reranker, nicemleme ve pgvector ile RAG altyapısı.

Yayınlandı: Güncellendi:

Vector database (vektör veritabanı), embedding vektörlerini saklayan ve bir sorgu vektörüne en yakın kayıtları benzerlik ölçütü ve metadata filtreleriyle bulmak için optimize edilmiş veri katmanıdır. Anlamsal arama, öneri ve retrieval-augmented generation (RAG) akışlarında kullanılır; ilişkisel veritabanının yerine geçmekten çok, farklı bir sorgu ihtiyacını tamamlar.

Problem: anlamsal benzerlik

Klasik bir sorgu olan SELECT * FROM products WHERE name = 'laptop' yalnız tam eşleşmeyi bulur. Kullanıcı “notebook” ya da “taşınabilir bilgisayar” yazdığında sonuç dönmez. Tam metin arama motorları kök bulma (stemming) ve eş anlamlı sözlükleriyle bu açığın bir kısmını kapatır; ancak eş anlamlıların tanımlanması gerekir ve ortak kelime içermeyen iki ifadenin aynı şeyi anlattığı kendiliğinden çıkarılamaz.

Embedding modeli bu ifadeleri yakın vektörlere yerleştirirse vektör araması aynı kavrama ait sonuçları yakalayabilir. Bu davranış otomatik bir garanti değildir; model, dil, alan verisi ve benzerlik eşiğiyle birlikte ölçülmelidir.

Embedding nedir?

Embedding, bir metnin, görüntünün veya sesin sabit uzunluklu bir sayı dizisiyle, yani bir vektörle temsilidir. Örneğin “kedi” kelimesi [0.2, -0.5, 0.8, ...] gibi 768 boyutlu bir vektör olabilir. İyi eğitilmiş bir modelde “kedi” ve “köpek” vektörleri birbirine, “fatura” vektörüne olduğundan daha yakın düşer; çünkü model benzer bağlamlarda geçen ifadeleri yakın konumlara yerleştirmeyi öğrenir.

Vektörleri bir embedding modeli üretir: barındırılan API’ler (OpenAI, Google, Cohere gibi sağlayıcıların embedding uç noktaları) ya da Sentence Transformers gibi kütüphanelerle yerelde çalıştırılan açık ağırlıklı modeller. Model seçerken Türkçe desteğine, vektör boyutuna, lisansa ve maliyete bakılır. Farklı modellerin vektörleri birbiriyle karşılaştırılamaz; modeli değiştirmek bütün verinin yeniden embedding’e çevrilmesini gerektirir.

Geleneksel veritabanı ve vektör veritabanı

Geleneksel veritabanı:

Vektör veritabanı:

Nasıl çalışır?

  1. Embedding üretimi: Ham veri (metin, görüntü) parçalara bölünür ve embedding modeline verilir.
  2. İndeksleme: Vektörler metadata ile birlikte bir indekse yazılır.
  3. Sorgu: Arama metni aynı modelle vektöre çevrilir.
  4. Benzerlik araması: Sorgu vektörüne en yakın K vektör bulunur; kiracı, tarih veya yetki gibi metadata filtreleri uygulanır.
  5. Sonuç: En benzer kayıtlar benzerlik skorlarıyla döner.

“Yapay zekâ hakkında makale” araması vektöre çevrilir; veritabanı bu vektöre en yakın makale vektörlerini, yani anlamca en ilgili makaleleri bulur.

İndeks yapıları

Milyonlarca vektörde sorgu vektörünü her kayıtla tek tek karşılaştırmak yavaştır. Yaklaşık en yakın komşu (approximate nearest neighbor, ANN) indeksleri küçük bir isabet kaybı karşılığında aramayı hızlandırır.

Düz indeks (flat): Sorguyu bütün vektörlerle karşılaştırır. Kesin sonuç verir ama büyük veride yavaştır; küçük veri setlerinde ve diğer indekslerin isabetini ölçmek için referans olarak kullanılır.

HNSW (Hierarchical Navigable Small World): Malkov ve Yashunin’in (2016) önerdiği çok katmanlı bir yakınlık grafiğidir. Arama üst katmanda kaba adımlarla başlar, alt katmanlarda incelir. Hız ve isabet dengesi iyidir; buna karşılık bellek kullanımı ve indeks oluşturma süresi yüksektir.

IVF (Inverted File Index): Vektörleri k-means ile kümelere ayırır; sorguda yalnız en yakın birkaç küme taranır. Küme merkezlerini öğrenmek için bir eğitim adımı gerekir. Taranan küme sayısı arttıkça isabet artar, hız düşer.

LSH (Locality Sensitive Hashing): Benzer vektörleri yüksek olasılıkla aynı kovaya düşüren hash fonksiyonları kullanır.

Meta’nın Faiss projesi bir embedding modeli değil, bu indeksleri ve nicemleme yöntemlerini sunan bir benzerlik arama kütüphanesidir. Faiss ekibinin makalesi kütüphaneyi, vektör veritabanlarının çekirdek işlevi olan benzerlik aramasına ayrılmış bir indeksleme araç takımı olarak tanımlar.

Nicemleme (quantization)

Vektörler çoğunlukla 32 bitlik kayan noktalı sayılarla tutulur; 1.024 boyutlu tek bir vektör yalnız ham veri olarak 4 KiB yer kaplar. Nicemleme bu maliyeti düşürür:

Nicemleme isabeti düşürür. Yaygın çözüm, nicemlenmiş indeksle geniş bir aday listesi alıp adayları orijinal vektörlerle yeniden sıralamaktır. pgvector’ün halfvec tipi ve binary_quantize fonksiyonu bu teknikleri PostgreSQL içinde sunar.

Benzerlik ölçütleri

Kosinüs benzerliği: İki vektör arasındaki açıya bakar, uzunluğu yok sayar. Metin embedding’lerinde yaygındır.

İç çarpım (dot product): Hesaplaması ucuzdur. Vektörler birim uzunluğa normalize edilmişse kosinüs benzerliğiyle aynı sıralamayı verir.

Öklid (L2) uzaklığı: İki nokta arasındaki doğrusal uzaklıktır. Normalize vektörlerde o da kosinüs benzerliğiyle aynı sıralamayı verir.

Manhattan (L1) uzaklığı: Boyut farklarının mutlak değerlerinin toplamıdır.

Hangi ölçütün kullanılacağını embedding modelinin nasıl eğitildiği belirler; model belgesinde önerilen ölçütü kullanın. Bu ölçütler vektörler arasındaki geometrik yakınlığı ölçer. İki olasılık dağılımı arasındaki farkı ölçmek için ise Kullback-Leibler divergence gibi farklı araçlar kullanılır.

Hibrit arama ve yeniden sıralama

Vektör araması anlamı yakalar, ama ürün kodu, hata mesajı veya kişi adı gibi birebir ifadelerde zayıf kalabilir; anahtar kelime araması ise tersine bu ifadelerde güçlüdür. Bu yüzden RAG sistemlerinde iki yöntem sık sık birlikte kullanılır:

  1. Anahtar kelime araması: Elasticsearch, OpenSearch ve Weaviate gibi sistemlerde BM25 (Weaviate’te BM25F), PostgreSQL’de tam metin arama (full-text search).
  2. Vektör araması: Aynı sorgu için ANN indeksi üzerinde arama.
  3. Birleştirme: İki sonuç listesi, Reciprocal Rank Fusion (RRF) gibi sıraya dayalı yöntemlerle veya ağırlıklı skorla birleştirilir. Weaviate’te alpha parametresi iki tarafın ağırlığını belirler: 1 saf vektör, 0 saf anahtar kelime araması demektir.
  4. Yeniden sıralama (reranking): Birleştirilmiş listenin başındaki adaylar, sorguyu ve belgeyi birlikte okuyan bir cross-encoder modeliyle yeniden puanlanır (Nogueira ve Cho, 2019). Cross-encoder yavaştır, ama yalnız az sayıda adaya uygulandığı için toplam gecikme sınırlı kalır.

pgvector ile örnek

pgvector, PostgreSQL’e vektör tipi, uzaklık operatörleri ve HNSW ile IVFFlat indeksleri ekleyen bir eklentidir. Vektörler diğer sütunlarla aynı tabloda durduğu için PostgreSQL’in ACID işlemleri, JOIN’leri ve yedekleme araçları vektörler için de geçerlidir.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  tenant_id bigint NOT NULL,
  content text NOT NULL,
  embedding vector(1024) NOT NULL -- boyut, embedding modelinin çıktısıyla aynı olmalı
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- Uygulamadan parametreli sorgu: $1 sorgu embedding'i, $2 kiracı kimliği
SELECT id, content, embedding <=> $1 AS distance
FROM documents
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 5;

<=> kosinüs uzaklığını verir; küçük değer daha benzer demektir. Yaklaşık indekslerde WHERE filtresi indeks tarandıktan sonra uygulanır. pgvector belgesine göre koşul satırların %10’unu eşliyorsa, HNSW ve varsayılan hnsw.ef_search = 40 ile ortalama yalnız 4 satır döner. pgvector 0.8.0 ve sonrasında SET hnsw.iterative_scan = relaxed_order; yeterli sonuç bulunana kadar indeksi taramayı sürdürür. Filtre satırların küçük bir kısmını seçiyorsa tenant_id üzerindeki sıradan bir B-tree indeksiyle kesin arama da iyi bir seçenektir.

Vektör veritabanı seçenekleri

Ayrı vektör veritabanları:

Vektör desteği olan genel amaçlı sistemler:

Vektör veritabanı ve LLM: RAG

RAG yaklaşımı (Lewis vd., 2020), bir dil modelinin cevabını dışarıdan getirilen belgelerle koşullar. Vektör araması modele güncel veya kuruma özgü kaynak parçaları sağlayabilir. Bu, uydurma cevap (hallucination) riskini azaltmaya yardım eder; ama yanlış getirilen parça, güncellenmemiş indeks veya kaynağı dikkate almayan model yanıtı nedeniyle hatayı tamamen ortadan kaldırmaz.

RAG akışı:

  1. Kullanıcının sorusu embedding’e çevrilir; hibrit aramada anahtar kelime sorgusu da çalışır.
  2. Kullanıcının erişim yetkisi olan belgeler arasından en ilgili parçalar getirilir.
  3. Bu parçalar kaynak bilgileriyle birlikte LLM’e bağlam olarak verilir.
  4. LLM cevabı bu parçalara dayanarak üretir ve hangi parçayı kullandığını gösterir.

Örnek: “Yurt dışından uzaktan çalışmaya izin veriliyor mu?” sorusunun cevabı insan kaynakları politikası, çalışan el kitabı ve duyurular gibi yapılandırılmamış metinlerin içindedir. Vektör araması, soru kelimelerini birebir içermeyen “Uluslararası uzaktan çalışma” başlıklı bölümü bulabilir; LLM ilgili paragrafa atıf yaparak cevap verir ve kullanıcı kaynağı kontrol edebilir.

Buna karşılık “Şirketimizin 2023 geliri neydi?” gibi tek bir sayıya inen soru, finans tablosundan SQL ile daha güvenilir cevaplanır. Böyle bir soruyu metin parçalarından çıkarmaya çalışmak, benzer görünen başka bir rapordaki yanlış rakama yol açabilir.

Ne zaman vektör veritabanı kullanılmalı?

Uygun durumlar:

Gereksiz olduğu durumlar:

Sonuç

Vektör araması, anlamsal yakınlık gereken akışlarda güçlüdür; ancak getirme kalitesini, yetkilendirmeyi, güncellik politikasını ve kaynak gösterimini tek başına çözmez. Küçük bir değerlendirme veri setiyle embedding, filtre ve hibrit arama davranışını ölçün. Mevcut PostgreSQL altyapısında pgvector yeterliyse ayrı bir servis eklemeyin; ölçek ve operasyon gereksinimi kanıtlandığında özel çözümleri karşılaştırın.

Birincil kaynaklar