Şirket İçi RAG Pipeline'ları için Vektör Veritabanı Mimarisi

Vektör veritabanı seçimi neden birinci sınıf bir altyapı kararıdır

Retrieval-augmented generation sistemleri, retrieval katmanının kalitesine ve hızına göre başarılı ya da başarısız olur. Bu katmanı tamamen şirket içinde çalıştırdığınızda, vektör veritabanı yalnızca bir indeks değil—yedekleme rutinlerinizle, güvenlik kontrollerinizle ve kapasite planlama süreçlerinizle entegre olması gereken uzun ömürlü bir operasyonel bileşendir. Bu konuya yeterince önem vermeyen kuruluşlar genellikle üretim ortamına geçtikten altı ay sonra ciddi sorunlarla karşılaşır: beklenmedik bellek baskısı, anlaşılması güç replikasyon semantiği ya da kesintisiz yükseltilemeyen indeks formatları.

Bu yazıda başlıca kendi altyapınızda barındırma seçeneklerini, depolama ve servis topolojisini nasıl tasarlayacağınızı ve RAG güvenilirliğini sessiz sedasız aşındıran sorunların önüne geçen operasyonel alışkanlıkları inceliyoruz.

Kendi altyapınızda barındırma seçeneklerinin haritası

Bugün şirket içi RAG dağıtımlarında dört vektör veritabanı öne çıkıyor: pgvector (bir PostgreSQL uzantısı), Qdrant, Milvus ve Weaviate. Her biri karmaşıklık-kapasite eğrisinde farklı bir konumda yer alıyor.

pgvector, halihazırda PostgreSQL kullanan kuruluşlar için pragmatik bir başlangıç noktasıdır. Vektör benzerlik sorguları ile ilişkisel birleştirmeleri aynı anda çalıştırabilir, tek bir yedekleme hedefine sahip olabilir ve tanıdık araçları kullanabilirsiniz. Tek düğüm üzerinde on milyonlarca vektörü aştığınızda sorgu gecikmesi artmaya başlar; ancak çoğu kurumsal bilgi tabanı bu sınırın çok altında kalır. Ekibiniz PostgreSQL operasyonlarına hakimse, ikinci bir depolama sistemi gerekmeksizin işe buradan başlamak mantıklıdır.

Qdrant, Rust ile yazılmış ve bölümlenmiş depolama modeliyle HNSW algoritması etrafında inşa edilmiştir. Düğüm başına yüz milyonlarca vektörü güvenle işleyebilir, temiz bir gRPC ve REST API sunar ve metadata filtreleme için adlandırılmış payload alanlarını destekler. Disk modunda vektörler RAM dışında tutulur; bu, mütevazı donanımda büyük indekslere olanak tanır ancak kuyruk gecikmesini biraz artırır.

Milvus, depolama, koordinasyon ve sorgu yürütme bileşenlerini birbirinden ayırır. Bu mimari yatay ölçeklemeyi mümkün kılar; ancak koordinasyon için etcd ve segment kalıcılığı için MinIO ya da S3 uyumlu bir depolama gerektirir. Çok sayıda ekip, koleksiyon ve yüksek eşzamanlı yazma işlemi söz konusu olduğunda Milvus doğru tercih olabilir.

Weaviate, sorgu pipeline'ına gömme modelleri ve yeniden sıralayıcılar çağırabilen bir modül sistemi sunar. Retrieval ile model çıkarımı arasında daha sıkı bir döngü isteyen ekipler için bu entegrasyon tekrar eden kod yazmayı azaltır. Dezavantajı ise Weaviate'in kendi konteyner imajlarına ve sürüm döngüsüne bağımlılık yaratmasıdır.

Depolama ve bellek topolojisi

Vektör indeksleri bellek açısından talepkardır. Düz float32 depolama için HNSW grafları tipik olarak vektör başına boyut başına yaklaşık 1,4–1,6 bayt gerektirir. Beş milyon adet 1536 boyutlu gömme içeren bir koleksiyon, düşük gecikme ile sunulabilmesi için yaklaşık 12 GB RAM gerektirir. Koleksiyonlar büyümeden önce düğüm boyutlandırmasını yapın.

Bellek baskısını azaltmak için iki strateji kullanılır. Birincisi niceleme (quantization): int8 skaler niceleme veya ürün niceleme, küçük bir hatırlama kaybı karşılığında bellek ayak izini 4–8 kat azaltabilir. Hem Qdrant hem de Milvus bunu yerel olarak destekler. İkincisi katmanlı depolama: sıklıkla sorgulanan koleksiyonları RAM destekli indekslerde tutun, soğuk koleksiyonları ise disk tabanlı depolamaya taşıyın. Erişim sıklığına göre katman yükseltme ve düşürme işlemlerini otomatikleştirin.

Yüksek erişilebilirlik dağıtımlarında en az iki düğüm arasında replikasyon yapın ve topolojiyi üretim ortamında sertifikalandırmadan önce gerçekçi yük altında yük devretme davranışını test edin.

Gömme pipeline entegrasyonu

Vektör veritabanı, retrieval pipeline'ının yalnızca bir parçasıdır. Şirket içi RAG ayrıca yerel olarak çalışan bir gömme modeli, belge alım servisi ve sorgu zamanında gömme adımı gerektirir. Gömme modelinin seçimi, vektör veritabanı şemasıyla doğrudan bağlantılıdır: modeli değiştirmek, büyük veri kümeleri için saatler ya da günler sürebilecek şekilde tüm belgelerin yeniden gömülmesini ve indekslenmesini gerektirir.

Alım pipeline'ınızı açık model versiyonlama metadatası üzerine tasarlayın. Her vektörün yanına gömme modeli adı ve revizyonunu depolayın. Modeli yükseltirken eski ve yeni sürümü paralel çalıştırın, artımlı yeniden indeksleme yapın ve yalnızca ayrılmış bir sorgu kümesinde hatırlamayı doğruladıktan sonra retrieval trafiğini geçirin.

Gömme için çıkarım verimi çoğunlukla vektör veritabanının kendisinden daha büyük bir darboğazdır. Toplu alım işleri, etkileşimli çıkarım yolundan ayrı bir GPU veya CPU çalışan havuzu kullanmalıdır.

Kiracı yalıtımı ve erişim denetimi

Kurumsal RAG dağıtımlarının neredeyse tamamında ekipler, ürünler veya müşteri segmentleri arasında veri yalıtımı gereksinimi doğar. Vektör veritabanları bunu farklı biçimlerde ele alır ve bu seçimin güvenlik açısından sonuçları vardır.

En güçlü yalıtım, kiracı başına ayrı koleksiyon kullanmaktır. Bir kiracının belgeleri fiziksel olarak ayrılır; yanlış yapılandırılmış bir sorgu sınırları aşamaz. İşletme maliyeti koleksiyon sayısıyla orantılı olarak artar. Bu model, kiracı sayısının onlarla sınırlı olduğu durumlarda iyi çalışır.

Payload tabanlı filtreleme ile paylaşılan koleksiyonlar işletme yükünü azaltır; ancak uygulama katmanının her sorguda kiracı tanımlayıcısını doğru şekilde uygulamasını gerektirir. Qdrant, birinci sınıf filtre ifadeleri olarak adlandırılmış payload alanlarını destekler. pgvector ise mevcut veritabanı kimlik doğrulama kontrolleriyle doğal olarak entegre olan standart PostgreSQL satır düzeyinde güvenlik ilkelerine dayanır.

Gözlemlenebilirlik ve operasyonel hijyen

Vektör veritabanları, çoğu altyapı izleme yığınının varsayılan olarak toplamadığı metrikler yayar. En azından şunları izleyin: koleksiyon bazında sorgu gecikmesi, planlı çalışan sentetik benchmark sorgularıyla hatırlama tahmini, indeks boyutu ve segment sayısı, yazma kuyruğu derinliği ve replika gecikmesi. Bu metrikler, kullanıcılar kalite düşüşünü fark etmeden önce retrieval katmanının sağlıklı olup olmadığını size söyler.

Ağır sıkıştırma işlerini düşük trafik saatlerine zamanlayın ve sorgu servis iş parçacıklarını aç bırakmamak için kaynak sınırları tanımlayın. pgvector'da ise büyük miktarda ekleme alan tablolar için otomatik vakum ayarlarını gözden geçirin.

Vektör veritabanını standart yedekleme ve kurtarma test takviminize dahil edin. Büyük bir koleksiyonun soğuk geri yüklenmesi çoğu ekibin beklediğinden çok daha uzun sürer; bunu ihtiyaç duyduğunuzda değil, daha önce ölçün.

Öne çıkan görsel: Donald Wu tarafından, Unsplash'tan.