Vektör Veritabanı Seçimi: pgvector Ne Zaman Yeter, Ne Zaman Ayrı Sistem Gerekir?

Çoğu işletme uygulaması için pgvector yeterlidir. pgvector, PostgreSQL veritabanına vektör saklama ve benzerlik araması yeteneği ekleyen açık kaynaklı bir eklentidir. Dokümanlarınız, ürün kataloğunuz ya da destek geçmişiniz onbinlerden birkaç milyon kayda kadar çıkıyorsa, ayrı bir vektör veritabanı satın almak çoğu zaman gereksiz karmaşıklıktır.

Bu yazı, kendi verinizle çalışan bir arama ya da asistan kuruyorsanız (bu yapıya yapay zekâ entegrasyonu hizmetimiz kapsamında RAG diyoruz) veritabanı kararını hangi kriterlere göre vereceğinizi anlatır.

Vektör veritabanı tam olarak ne işe yarar?

Vektör veritabanı, metnin anlamını temsil eden sayı dizilerini saklar ve 'buna en yakın kayıtlar hangileri?' sorusunu hızlı yanıtlar. Bir yapay zekâ modeli her doküman parçasını yüzlerce ya da binlerce sayıdan oluşan bir diziye çevirir; buna gömme (embedding) denir. Anlamca yakın metinlerin dizileri de birbirine yakın çıkar.

Kullanıcı bir soru sorduğunda soru da aynı şekilde sayıya çevrilir, veritabanı en yakın doküman parçalarını bulur ve bu parçalar dil modeline 'sadece bunlara dayanarak cevapla' diye verilir. Bu akışın ayrıntısı doküman özetleme otomasyonu yazımızda ve işletmeler için yapay zekâ rehberimizde var; burada yalnızca depolama katmanına odaklanıyoruz.

pgvector hangi durumlarda yeterli olur?

Veri hacmi orta ölçekliyse ve verinin geri kalanı zaten PostgreSQL'deyse pgvector en az riskli seçimdir. Dört somut avantajı var:

• Tek veritabanı: Vektörler, kullanıcı, yetki ve içerik tablolarınızla aynı yerde durur. Ayrı bir sistemle senkron tutmak zorunda kalmazsınız.
• Birleşik filtreleme: 'Yalnızca bu müşterinin dokümanlarında ara' ya da 'son bir yılın kayıtlarında ara' gibi koşullar normal SQL ile yazılır. Yetki kontrolü, kurumsal aramada en kritik gereksinimdir ve burada en kolay çözülür.
• Tanıdık işletim: Yedekleme, izleme ve erişim kontrolü zaten bildiğiniz PostgreSQL araçlarıyla yürür. Yeni bir servis, yeni bir fatura kalemi ve yeni bir güvenlik incelemesi doğmaz.
• Silme ve güncelleme kolaylığı: Bir doküman değiştiğinde ya da bir kullanıcının verisini silmeniz gerektiğinde işlem tek bir transaction içinde yapılır; bu, KVKK taleplerinde işinizi kolaylaştırır.

Yaygın yönetilen PostgreSQL servislerinin birçoğu pgvector'u hazır sunar; kendi sunucunuzda ise eklenti tek komutla etkinleştirilir. Bu yüzden kurulum maliyeti pratikte sıfıra yakındır.

pgvector'un sınırları nelerdir?

Sınırlar, çok büyük hacimde ve çok yüksek eşzamanlı yükte ortaya çıkar. Eklenti iki tür indeks sunar: HNSW (hızlı ve isabetli ama bellek yiyen, grafik tabanlı yapı) ve IVFFlat (daha az bellek kullanan, kümelere bölen yapı). Her ikisi de 'yaklaşık en yakın komşu' araması yapar; yani çok küçük bir isabet kaybını hız karşılığında kabul edersiniz.

Dikkat edilecek noktalar şunlardır:

1. İndeks belleğe sığmadığında sorgu süreleri belirgin biçimde uzar; vektör sayısı onlarca milyona yaklaştıkça bu sık görülür.
2. Yoğun yazma altında (sürekli yeni doküman akışı) indeks bakımı ana veritabanınızın performansını etkileyebilir.
3. İndekslenebilir vektör boyutunun bir üst sınırı vardır; çok büyük boyutlu gömme modelleri seçerken eklentinin güncel belgelerini kontrol edin.
4. Filtreli aramada indeks, filtreyi sonradan uyguladığı için çok seçici filtrelerde az sonuç dönebilir; sorgu planını test etmek gerekir.

Bu sınırların hiçbiri küçük ve orta ölçekli bir kurumsal arama için engel değildir. Onlarca milyonluk kayıt, çok yüksek sorgu hacmi ya da veritabanı ekibinizin yönetemeyeceği bir yük söz konusuysa ayrı bir sistem düşünülür.

Ayrı bir vektör veritabanı ne zaman mantıklı?

Vektör araması ürünün çekirdeğiyse ve yük PostgreSQL'i zorluyorsa ayrı bir sistem haklı hale gelir. Özel olarak vektör için tasarlanmış servisler (yönetilen bulut ürünleri ya da Qdrant, Milvus, Weaviate gibi açık kaynak sistemler) şu durumlarda öne çıkar:

• Vektör sayısı onlarca milyonu aşıyor ve büyümeye devam ediyor.
• Arama, uygulamanın ana özelliği; gecikme ve eşzamanlı sorgu hedefleri çok sıkı.
• Ana veritabanınızı arama yükünden korumak istiyorsunuz.
• Hibrit arama, yeniden sıralama (reranking) ya da çoklu vektör gibi özellikleri hazır paket olarak istiyorsunuz.

Bedeli de açık: ikinci bir sistem, veriyi iki yerde tutmak, senkronizasyon hataları, ayrı bir yetki modeli ve ek işletme yükü. Maliyeti belirleyen kalemlerin genel çerçevesi için yazılım projesi maliyeti rehberimize bakabilirsiniz.

Karar tablosu: hangi durumda hangisi?

Seçimden önce neyi ölçmelisiniz?

Karar, tahmine değil kendi verinizle yapılmış küçük bir ölçüme dayanmalı. Bir hafta içinde yapılabilecek basit bir deney şu adımlardan oluşur:

1. Gerçek dokümanlarınızdan temsili bir örnek alın ve parçalara bölün.
2. Gerçek kullanıcıların soracağı 30–50 soru yazın ve her biri için doğru kaynağı elle işaretleyin.
3. pgvector ile arama yapın; doğru kaynağın ilk beş sonuç içinde çıkma oranına bakın.
4. Sorgu süresini ve bellek kullanımını, beklediğiniz veri hacminin birkaç katında tekrar ölçün.

Burada çoğu zaman şunu görürsünüz: sonuç kalitesini belirleyen şey veritabanı değil, dokümanı nasıl parçaladığınız ve hangi gömme modelini seçtiğinizdir. Veritabanı değişikliği isabeti nadiren birkaç puandan fazla oynatır; parçalama stratejisi ise tabloyu baştan aşağı değiştirebilir. Kaliteyi sistematik ölçmek ayrı bir konu ve sırada.

Yanlış seçim yaparsam geri dönüşü zor mu?

Hayır, doğru kurulursa taşıma zor değildir. Vektörler kaynak metinden yeniden üretilebilir; bu yüzden en kötü senaryoda gömmeleri baştan hesaplayıp yeni sisteme yazarsınız. Taşımayı kolaylaştıran iki alışkanlık var: arama çağrısını uygulamanızda tek bir katmanın arkasına koymak ve ham metni ile doküman kimliklerini her zaman asıl veritabanınızda tutmak.

Bu yüzden pratik öneri sade: pgvector ile başlayın, ölçün, gerçek bir darboğaz görürseniz taşıyın. Kendi verinizle çalışan bir arama ya da asistan kurmayı düşünüyorsanız, kapsamı birlikte netleştirmek için bize yazabilirsiniz.