Vektör Veritabanı

Vektör veritabanı, yüksek boyutlu sayısal vektörleri (embedding'leri) tutmak ve "bana buna en benzer vektörleri bul" sorgularını ölçekte yanıtlamak için özel olarak tasarlanmış bir veri deposudur — genellikle HNSW veya IVF gibi yaklaşık en yakın komşu (approximate nearest neighbor, ANN) algoritmaları kullanılır; bu algoritmalar, kaba kuvvet karşılaştırmaya kıyasla küçük bir doğruluk kaybını devasa bir hız kazancıyla takas eder. Bu, SaaS/AI geliştiricileri için önemlidir çünkü RAG, semantik arama, tekrar tespiti (deduplication) ve öneri özelliklerini mümkün kılan altyapı budur: tam anahtar kelime eşleştirmesi yerine anlam üzerinden eşleştirme yaparsınız. Popüler seçenekler geniş bir yelpazeye yayılır: Pinecone, Weaviate, Qdrant ve Milvus gibi özel vektör veritabanları, zengin filtreleme ve yatay ölçeklenme ile vektör öncelikli olarak inşa edilmiştir; pgvector, vektör sütunlarını ve benzerlik operatörlerini doğrudan PostgreSQL'e ekleyerek ekiplerin ölçekleri gerektirmediğinde ayrı bir veritabanı çalıştırmasını önler; Redis, Elasticsearch ve MongoDB ise mevcut motorlarına vektör aramayı sonradan eklemiştir. Mekanik şöyle işler: her doküman (veya doküman parçası) bir embedding modeli aracılığıyla bir vektöre dönüştürülür, metadata ile birlikte (kaynak URL, zaman damgası, etiketler) saklanır ve indekslenir. Bir sorgu da aynı şekilde embedding'e dönüştürülür ve veritabanı, bir uzaklık metriğine göre — genellikle kosinüs benzerliği veya nokta çarpımı — en yakın vektörleri döndürür. Postgres'te pgvector kullanan somut bir örnek: `CREATE TABLE docs (id serial, content text, embedding vector(1536)); CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops); SELECT content FROM docs ORDER BY embedding <=> '[0.012, -0.045, ...]' LIMIT 5;` — bu tek sorgu, milyonlarca satır arasında bile milisaniyeler içinde girdi vektörüne semantik olarak en benzer 5 dokümanı döndürür. Yönetilen bir vektör veritabanı ile Postgres içi pgvector arasında seçim yapmak gerçek bir mimari karardır: yönetilen servisler daha az operasyonel yükle daha ileri ölçeklenir ama yeni bir sistem ve maliyet kalemi ekler; pgvector ise zaten Postgres kullanıyorsanız ve verileriniz düşük milyonlarca vektör mertebesindeyse yığınınızı basit tutar. Ham benzerlik aramasının ötesinde, çoğu üretim vektör veritabanı metadata filtrelemeyi destekler (örneğin, "yalnızca `region: EU` ve `status: published` etiketli dokümanlarda ara"); bu, bir müşterinin RAG sorgularının başka bir müşterinin özel dokümanlarını asla ortaya çıkarmaması gereken çok kiracılı (multi-tenant) SaaS ürünleri için hayati önemdedir — filtreleme, yanlış kiracının verisini hiçbir zaman LLM'e iletmemek için sonradan bir kontrol olarak değil, veritabanı sorgu düzeyinde gerçekleşir. İndeks yeniden oluşturma stratejisi de operasyonel açıdan önemlidir: dokümanlar eklendikçe, güncellendikçe veya silindikçe vektör indeksinin senkron kalması gerekir; bazı veritabanları bunu neredeyse gerçek zamanlı upsert'lerle yönetirken bazıları periyodik tam yeniden indekslemeye ihtiyaç duyar — içeriği sık değişen bir ürün (canlı bir destek talebi bilgi tabanı gibi) ile nadiren değişen bir ürün (statik bir ürün kılavuzu gibi) arasında anlamlı bir fark yaratır.