Vektör Veritabanı Nedir, Ne Zaman Kullanılmalıdır?

Vektör veritabanı, yapılandırılmamış verilerin makine öğrenimi modelleri tarafından üretilen çok boyutlu sayısal temsillerini (vektör yerleştirmeleri) depolamak, indekslemek ve bunlar üzerinde milisaniye düzeyinde benzerlik araması yapmak için geliştirilmiş özel bir veri altyapısıdır. Vektör Veritabanı Nedir, Ne Zaman Kullanılmalıdır? sorusunun kurumsal yanıtı; metin, görsel ve ses gibi karmaşık verilerin anlamsal bağlamını koruyarak büyük dil modelleri (LLM), RAG mimarisi ve gelişmiş öneri motorlarıyla entegre çalışan sistemler kurma ihtiyacında yatar. Bu rehber; vektör indeksleme algoritmalarından donanım maliyetlerine, pgvector gibi hibrit çözümlerden bağımsız mimarilere kadar karar vericilerin ihtiyaç duyduğu tüm teknik kriterleri nesnel bir çerçevede sunmaktadır.

Vektör Veritabanı Kavramına Kurumsal Bir Bakış

Geleneksel ilişkisel (RDBMS) ve NoSQL veritabanı sistemleri; metinleri, sayıları ve ilişkisel tabloları kesin anahtar kelime eşleşmeleri (B-Tree, hash indeksleri) veya tam eşitlik üzerinden sorgulamak üzere tasarlanmıştır. Ancak modern işletmelerin ürettiği verilerin %80'inden fazlasını belgeler, müşteri destek kayıtları, ses dosyaları, ürün görselleri ve loglar gibi yapılandırılmamış veriler (unstructured data) oluşturmaktadır. Geleneksel indeksleme yapıları, "araba" ile "otomobil" sözcükleri arasındaki anlamsal bağı veya bir ürün görselinin başka bir fotoğrafla olan stil benzerliğini matematiksel olarak yakalayamaz.

Vektör veritabanları, verilerin semantik anlamını yakalayan sayısal dizileri depolamak amacıyla geliştirilmiştir. Bir yapay zeka veya gömme (embedding) modeli tarafından işlenen herhangi bir veri parçası, yüzlerce hatta binlerce boyuttan oluşan bir sayı dizisine dönüştürülür. Örneğin, metin tabanlı bir gömme modeli (OpenAI text-embedding-3-large, Cohere Embed v3 veya açık kaynaklı BAAI/bge-large), bir metin bloğunu 1536 veya 3072 boyutlu bir kayan noktalı sayı (float32) dizisine çevirir. Bu sayılar, söz konusu verinin çok boyutlu anlamsal uzaydaki koordinatlarını belirler.

Metin / Görsel / Ses ──► [ Embedding Modeli ] ──► [0.0124, -0.0891, 0.4412, ..., -0.1034] ──► Vektör Veritabanı

Vektör veritabanlarının temel görevi, bu devasa koordinat sisteminde birbirine en yakın olan noktaları bulmaktır. Geleneksel bir veritabanında WHERE description = 'koşu ayakkabısı' sorgusu çalıştırıldığında sistem yalnızca bu tam ifadeyi tararken, bir vektör veritabanında "maraton için dayanıklı spor giyim" sorgusu çalıştırıldığında anlamsal uzayda birbirine en yakın koordinatlarda bulunan koşu ayakkabısı kayıtları milisaniyeler içinde çekilir.

Bu mimarilerin kurumsal düzeyde sağladığı temel kazanımlar şunlardır:

• Yüksek Boyutlu Veri Yönetimi: 128 boyuttan 4096 boyuta kadar uzanan gömme vektörlerinin disk veya bellek (RAM) üzerinde performans kaybı yaşanmadan saklanması.

• Milisaniye Düzeyinde Benzerlik Araması: Milyonlarca veya milyarlarca vektör arasından en yakın k-adedinin (k-NN) yaklaşık en yakın komşu (ANN) algoritmalarıyla sorgulanabilmesi.

• Meta Veri Filtreleme (Metadata Filtering): Vektör aramalarının şirket ID'si, tarih aralığı, departman yetkilendirmesi veya ürün kategorisi gibi skaler verilerle eş zamanlı olarak filtrelenmesi.

• Yatay Ölçeklenebilirlik (Sharding & Replication): Çok büyük hacimli veri kümelerinde indekslerin bölümlenerek (sharding) yüksek sorgu hacimlerinin (QPS) karşılanması.

Vektör Veritabanları Nasıl Çalışır? Temel Mekanizmalar

Vektör veritabanlarının operasyonel gücü; ham verinin sayısallaştırılmasından, bu sayıların özel veri yapıları içinde indekslenmesine ve sorgu anında matematiksel mesafe fonksiyonlarıyla taranmasına dayanan üç aşamalı bir boru hattından (pipeline) gelir.

Verilerin Vektörleştirilmesi (Embeddings Süreci)

Vektörleştirme, yapılandırılmamış bir içeriğin makine öğrenimi modelleri aracılığıyla anlamsal bir koordinata dönüştürülmesidir. Bu süreçte kullanılan model mimarisi (Transformer tabanlı modeller, CLIP gibi multimodal ağlar veya ses işleme modelleri), üretilen vektörün boyutunu ve yakalanan anlamsal derinliği doğrudan belirler.

Bir kurumsal belgenin vektörleştirilmesinde şu adımlar izlenir:

1. Parçalama (Chunking): Uzun metinler (PDF'ler, sözleşmeler, teknik belgeler) belirli token uzunluklarına (örneğin 512 veya 1024 token) ve çakışma (overlap) oranlarına bölünür.

2. Modelden Geçirme (Inference): Her bir metin parçası gömme modeline girdi olarak verilir.

3. Vektör Çıktısı: Model, parçanın anlamsal özetini içeren yoğun bir vektör (dense vector) dizisi üretir.

Vektör boyutunun büyüklüğü (örneğin 768 vs 3072), verinin temsil kalitesini artırırken veritabanında kaplayacağı bellek miktarını ve hesaplama süresini doğrudan çarpan etkisiyle yükseltir.

Anlamsal ve Benzerlik Araması (Similarity Search)

Vektör veritabanlarında "arama" işlemi, bir sorgu vektörü ile veritabanındaki kayıtlı vektörler arasındaki geometrik mesafenin hesaplanmasıdır. Bu işlemde üç temel matematiksel metrik kullanılır:

Kurumsal sistemlerde vektörler genellikle veritabanına yazılmadan önce birim uzunluğa normalize edilir. Normalize edilmiş vektörlerde İç Çarpım ve Kosinüs Benzerliği matematiksel olarak aynı sıralamayı üretir, bu sayede işlemci seviyesinde SIMD (Single Instruction, Multiple Data) ve AVX-512 komut setleri kullanılarak arama süreleri dramatik şekilde düşürülür.

İndeksleme Algoritmaları ve Performans (ANN ve k-NN Yaklaşımları)

K-En Yakın Komşu (k-NN) algoritması, bir sorgu vektörünü veritabanındaki her bir vektörle tek tek karşılaştırır (kaba kuvvet / brute-force). Milyonlarca kaydın bulunduğu kurumsal bir veritabanında bu işlem saniyeler süren gecikmelere (latency) yol açar ve canlı sistemlerde kabul edilemez. Bu nedenle vektör veritabanları Yaklaşık En Yakın Komşu (ANN - Approximate Nearest Neighbor) algoritmalarından yararlanır. ANN, %98-99 gibi çok küçük bir doğruluk kaybı (recall trade-off) karşılığında sorgu sürelerini milisaniyelere indirir.

En yaygın kullanılan ANN indeksleme yaklaşımları şunlardır:

1. HNSW (Hierarchical Navigable Small World): Çok katmanlı çizge (graph) tabanlı bir indekstir. Üst katmanlarda geniş sıçramalarla arama yapılırken, alt katmanlara inildikçe en yakın komşular daralan yarıçapta taranır. Bellek kullanımı yüksektir ancak arama hızı ve doğruluk oranı (recall) açısından endüstri standardı kabul edilir.

2. IVF (Inverted File Index): Vektör uzayını Voronoi hücrelerine (kümelerine) böler. Arama sırasında sadece sorgu vektörüne en yakın birkaç kümenin içindeki vektörler taranır. Bellek tüketimi düşüktür ancak HNSW kadar yüksek doğruluk sağlamayabilir. Genellikle bellek kısıtı olan sistemlerde tercih edilir.

3. PQ (Product Quantization): Vektörleri daha küçük alt vektörlere böler ve kayan noktalı sayıları bayt seviyesine sıkıştırır (quantization). Bellek kullanımını %75-90 oranında azaltır, disk I/O operasyonlarını hızlandırır; büyük veri kümelerinde maliyet kontrolü için kritiktir.

Ham Veri (Float32) ──► PQ Sıkıştırma (Int8) ──► HNSW / IVF Çizgesi ──► Hızlı ANN Arama

Geleneksel Veritabanları ile Vektör Veritabanlarının Karşılaştırması

Geleneksel veritabanı mimarileri veriyi satırlar, sütunlar, belgeler (JSON) veya anahtar-değer çiftleri halinde yapılandırır. Vektör veritabanları ise veriyi çok boyutlu bir metrik uzayda yoğunlaştırılmış koordinatlar olarak konumlandırır. Bu iki yaklaşım arasındaki fark yalnızca veri tipinde değil, sorgulama mantığında, donanım kaynaklarının kullanımında ve tutarlılık modellerinde kendini gösterir.

Geleneksel bir ilişkisel veritabanında (PostgreSQL, MySQL, Oracle) bir sorgu kesin bir mantıksal önermedir (Boolean mantığı). Bir kayıt ya sorgu koşuluna uyar ya da uymaz. Vektör veritabanlarında ise sonuçlar olasılıksal ve görecelidir; sistem "bu kayıt aranan anlama %87 oranında benziyor" çıktısı üretir.

Bu ayrım, hibrit mimarilerin doğmasına yol açmıştır. pgvector eklentisi sayesinde PostgreSQL gibi olgun bir RDBMS içinde vektör operasyonları yürütmek mümkün hale gelmiştir. Ancak yüz milyonlarca vektörün söz konusu olduğu ve saniyede binlerce eşzamanlı benzerlik sorgusunun (high QPS) gerektiği senaryolarda, özel olarak bu iş için tasarlanmış bağımsız (vector-native) sistemler donanım verimliliği açısından öne çıkar.

Vektör Veritabanı Ne Zaman Kullanılmalıdır? (Stratejik Kullanım Senaryoları)

Vektör veritabanları her yazılım projesine rastgele eklenecek genel amaçlı bir bileşen değildir. Bu altyapıya yatırım yapma kararı; verinin doğasına, sorgulama biçimine ve hedeflenen kullanıcı deneyimine göre şekillenmelidir. Kurumsal sistemlerde vektör veritabanının zorunlu hale geldiği dört ana senaryo bulunmaktadır:

RAG (Retrieval-Augmented Generation) ve Kurumsal LLM Projeleri

Büyük dil modelleri (LLM), genel bilgiler konusunda güçlü olsalar da şirkete özel verilere (iç dokümantasyon, CRM kayıtları, teknik şartnameler, gizli kılavuzlar) doğrudan erişemezler. Modelleri bu verilerle sıfırdan eğitmek (fine-tuning) hem yüksek maliyetlidir hem de veri güncellendiğinde modelin hızla eskimesine yol açar.

RAG mimarisinde vektör veritabanı harici bir "uzun süreli kurumsal bellek" görevi görür:

• Kullanıcı sisteme bir soru iletir.

• Soru anında vektörleştirilir ve vektör veritabanında en ilgili şirket belgeleri taranır.

• En yüksek benzerlik skoruna sahip metin parçaları (context) çekilir.

• Bu bağlam ve kullanıcının sorusu birleştirilerek LLM'e prompt olarak gönderilir.

• LLM, yalnızca sağlanan doğrulanmış bağlama dayanarak yanıt üretir (halüsinasyon riski minimuma iner).

Bu mekanizma, müşteri hizmetleri botlarından şirket içi bilgi yönetim sistemlerine kadar kurumsal yapay zeka uygulamalarının temel omurgasını oluşturur.

Gelişmiş Öneri Motorları ve E-Ticaret Uygulamaları

Geleneksel e-ticaret öneri sistemleri, kullanıcıların geçmiş satın alma verilerine veya işbirlikçi filtreleme (collaborative filtering) matrislerine dayanır. Bu yaklaşım, yeni eklenen ürünlerde (cold-start problemi) veya kullanıcının o anki anlık niyet değişimlerinde yetersiz kalır.

Vektör tabanlı öneri motorları; ürünlerin görsel özelliklerini, metin açıklamalarını, kullanıcı tıklama dizilimlerini ve inceleme yorumlarını çok boyutlu bir uzayda birleştirir. Bir kullanıcı belirli bir tasarım stiline sahip bir sehpayı incelediğinde, sistem yalnızca "sehpa" kategorisindeki ürünleri değil; renk paleti, malzeme dokusu ve tasarım dili bakımından o ürüne anlamsal olarak en yakın koltuk ve aydınlatma ürünlerini de anında öneri listesine dahil eder.

Görsel, Ses ve Video Tabanlı İçerik Aramaları

Multimodal yapay zeka modellerinin yaygınlaşmasıyla birlikte, metin ile diğer medya türleri arasındaki sınırlar kalkmıştır. CLIP (Contrastive Language-Image Pre-training) benzeri modeller, görselleri ve metinleri aynı çok boyutlu vektör uzayına yerleştirir.

Bu sayede:

• Kullanıcı "yağmurlu havada yürüyen kırmızı ceketli adam" şeklinde metin girişi yaptığında, arşivdeki milyonlarca video karesi veya fotoğraf arasından bu sahneyi içeren anlar hiçbir manuel etiketleme olmaksızın bulunur.

• Telif hakkı denetimlerinde, ses frekanslarından üretilen vektörler taranarak modifiye edilmiş müzik parçaları saniyeler içinde tespit edilir.

Anomali Tespiti ve Siber Güvenlik Analizleri

Siber güvenlik operasyonlarında (SOC), ağ trafiği logları, kullanıcı oturum hareketleri ve API çağrı kalıpları vektörleştirilerek sürekli izlenir. Normal sistem davranışları vektör uzayında belirli yoğun kümeler oluşturur.

Sisteme sızma girişimi, olağandışı veri çekme hareketi veya sıfır gün (zero-day) saldırısı gerçekleştiğinde, bu eylemin vektörü normal davranış kümelerinin çok dışında, izole bir koordinatta kalır (outlier). Vektör mesafesi tabanlı anomali tespiti, önceden tanımlanmış kural veya imzalara ihtiyaç duymadan bilinmeyen tehdit kalıplarını gerçek zamanlı olarak yakalama imkanı sunar.

Temkinli Yaklaşım: Vektör Veritabanı Ne Zaman KULLANILMAMALIDIR?

Kurumsal mimari kararlarında yeni bir teknolojiyi nerede kullanacağını bilmek kadar, nerede kullanılmaması gerektiğini bilmek de teknik borç (technical debt) birikimini ve gereksiz altyapı maliyetlerini engeller. Vektör veritabanları her veri problemine uygun sihirli bir çözüm değildir.

Sadece Kesin Eşleşme (Exact Match) Gerektiren Finansal ve Operasyonel İşlemler

Bankacılık, faturalandırma, envanter sayımı ve ERP sistemleri deterministik (kesin) sonuçlar talep eder. Bir muhasebe yazılımında "Fatura No: 2026-9841" sorgusu çalıştırıldığında veya belirli bir kullanıcının bakiye değişimi incelendiğinde benzerlik değil, %100 kesin eşleşme ve güçlü ACID garantisi şarttır.

Vektör veritabanlarının sunduğu yaklaşık en yakın komşu (ANN) aramaları olasılıksaldır. Benzerlik skoruna dayalı bir tarama, kesin olarak eşleşmesi gereken bir finansal kaydı atlayabilir veya alakasız bir kaydı "yüksek benzerlik" sebebiyle listeye dahil edebilir. Bu tür iş yüklerinde PostgreSQL, MySQL veya Oracle gibi klasik ilişkisel sistemler kullanılmalıdır.

Düşük Boyutlu, Yapılandırılmış ve Sık Güncellenen Veri Kümeleri

Tablosal verilerde (yaş, şehir, sipariş adedi, ürün stok durumu) verilerin anlamsal bir koordinat uzayına taşınması mimari bir israftır. Bu tür veriler B-Tree veya Hash indeksleri üzerinden mikro saniyeler düzeyinde filtrelenebilir.

Ayrıca vektör indeksleri (özellikle HNSW), sık yapılan güncelleme (@@CODE0@@) ve silme (@@CODE1@@) operasyonlarına karşı duyarlıdır. Bir çizge indeksinde düğümlerin sürekli güncellenmesi indeksin bozulmasına, arama kalitesinin düşmesine ve yoğun yeniden indeksleme (re-indexing) maliyetlerine yol açar. Yüksek yazma/güncelleme trafiğine sahip tablosal iş yüklerinde vektör veritabanları tercih edilmemelidir.

Operasyonel Bütçe ve Kaynak Kısıtlaması Olan Küçük Ölçekli Projeler

Veri hacmi birkaç bin veya on binlerce kayıttan ibaret olan küçük projelerde bağımsız bir vektör veritabanı kümesi (cluster) kurmak ve yönetmek operasyonel yük getirir:

• Mevcut PostgreSQL veritabanına kurulacak bir pgvector eklentisi 100.000 kayda kadar olan iş yüklerini sıfır ek altyapı maliyetiyle yönetebilir.

• Yerel bir kütüphane (FAISS veya Chroma) uygulama sürecinin içinde (in-memory) çalıştırılarak harici sunucu masrafları engellenebilir.

Yetersiz veri hacmine rağmen bağımsız bir dağıtık vektör veritabanı altyapısına geçmek sunucu maliyetlerini, ağ gecikmesini (network latency) ve bakım karmaşıklığını artırır.

Kurumsal Uygulamalarda Dikkat Edilmesi Gereken Riskler ve Zorluklar

Kurumsal bir üretim ortamında (production) vektör veritabanı devreye alınırken yazılım mimarlarının ve altyapı ekiplerinin yönetmesi gereken teknik engeller bulunur:

Yüksek Bellek (RAM) Tüketimi ve Donanım Maliyetleri

Vektör aramalarında düşük gecikme (sub-50ms) elde etmek için HNSW indekslerinin ve sık erişilen vektörlerin doğrudan sunucu belleğinde (RAM) tutulması gerekir.

Örnek bir bellek hesabı:

• 10 milyon kayıtlı bir veri kümesi.

• 1536 boyutlu vektörler (Float32 formatında her sayı 4 bayt yer kaplar).

• Her vektör: $1536 \times 4 \text{ bayt} \approx 6.144 \text{ KB}$.

• 10 milyon vektör ham veri: Yaklaşık $61.44 \text{ GB}$.

• HNSW çizge bağlantılarının getirdiği ek yük (%50 - %100): Toplamda 100 GB - 120 GB RAM.

Bu hacim, yüksek bellekli bulut sunucu (RAM-optimized cloud instances) maliyetlerini doğrudan artırır. Mimaride Product Quantization (PQ) veya Scalar Quantization (SQ) gibi sıkıştırma teknikleri ile disk tabanlı önbellekleme katmanları doğru yapılandırılmazsa altyapı bütçesi kontrol dışına çıkabilir.

Vektör Kayması (Vector Drift) ve Model Bağımlılığı

Vektör veritabanına yazılan koordinatlar, o veriyi üreten gömme modeline (embedding model) sıkı sıkıya bağlıdır.

• Eğer metinleri vektörleştirmek için kullanılan model sürümü değiştirilirse (örneğin OpenAI text-embedding-ada-002'den text-embedding-3-large modeline geçilirse), eski modelin ürettiği vektörler ile yeni modelin ürettiği vektörler aynı uzayda birbiriyle karşılaştırılamaz.

• Bu durumda veritabanındaki tüm kurumsal arşivin baştan sona yeniden vektörleştirilmesi (full re-embedding & re-indexing) gerekir. Milyonlarca dokümanın bulunduğu sistemlerde bu işlem ciddi API maliyeti ve saatler süren kesinti riski yaratır.

Veri Gizliliği, İzolasyon ve Yetkilendirme (RBAC)

Kurumsal RAG uygulamalarında en sık göz ardı edilen güvenlik açığı yetkilendirmedir. Geleneksel SQL sistemlerinde her kullanıcının satır ve tablo bazlı erişim yetkileri (Row-Level Security) katı kurallarla ayrılmıştır.

Bir vektör veritabanında tüm departman belgeleri (İnsan Kaynakları maaş listeleri, Ar-Ge patent taslakları, genel duyurular) aynı vektör uzayına yazılırsa; yetkisiz bir stajyerin yaptığı anlamsal bir arama İK dokümanlarından parçaları çekip LLM yanıtına ekleyebilir. Bu durum KVKK ve GDPR kapsamında ciddi veri ihlalleri doğurur. Vektör sistemlerinde Meta Veri Tabanlı Ön Filtreleme (Pre-filtering) ve kiracı izolasyonu (Multi-Tenancy Partitioning) mimarinin en başında kurgulanmalıdır.

Pazardaki Önemli Vektör Veritabanı Çözümleri

Kurumsal bir proje için vektör veritabanı seçilirken iki temel yaklaşım bulunur: Sıfırdan yalnızca vektör iş yükleri için geliştirilmiş Bağımsız Vektör Veritabanları (Vector-Native) ve mevcut veritabanı motorlarına eklenen Vektör Eklentileri / Hibrit Motorlar.

Bağımsız Vektör Veritabanları (Vector-Native)

Bu sistemler doğrudan ANN algoritmaları, çok boyutlu sharding ve yüksek QPS hedefleriyle tasarlanmıştır:

• Pinecone: Tamamen yönetilen (fully-managed/serverless) bulut tabanlı bir vektör veritabanıdır. Altyapı yönetimi, sunucu bakımı ve indeks yapılandırmasıyla uğraşmak istemeyen, hızlı prototip ve üretim ortamı hedefleyen ekipler için uygundur.

• Milvus: Açık kaynaklı, son derece dağıtık ve milyarlarca vektörlük iş yüklerini kaldırabilen kurumsal düzeyde bir platformdur. Kubernetes üzerinde ölçeklenir; GPU hızlandırmalı indeksleme desteği sunar. Büyük ölçekli veri merkezleri için idealdir.

• Qdrant: Rust diliyle geliştirilmiş, bellek verimliliği ve gelişmiş meta veri filtreleme yetenekleriyle öne çıkan açık kaynaklı bir motordur. Hem yerel sunucularda (on-premise) hem de bulutta yüksek kararlılık sağlar.

• Weaviate: GraphQL ve REST API desteği sunan, yerleşik makine öğrenimi modülleriyle veriyi içeri aktarırken otomatik vektörleştirebilen esnek bir açık kaynak çözümdür.

• Chroma: Python ve JavaScript ekosistemine odaklanan, geliştirme ve prototipleme aşamalarında yerel olarak kolayca çalışan hafif bir açık kaynak vektör deposudur.

Vektör Destekli Geleneksel Motorlar (Eklentiler)

• PostgreSQL (pgvector): Mevcut PostgreSQL kümelerine vektör arama yeteneği kazandıran açık kaynaklı bir eklentidir. İlişkisel veriler ile vektörlerin tek bir ACID uyumlu veritabanında tutulmasını sağlar. Küçük ve orta ölçekli projeler için operasyonel maliyeti en düşük çözümdür.

• Elasticsearch & OpenSearch: Metin tabanlı ters indeksleme (inverted index) yeteneklerini yoğun vektör alanları (dense_vector) ve HNSW indeksleriyle birleştirerek güçlü hibrit arama (BM25 + Vektör) altyapısı sunar.

Kurumsal Dönüşüm İçin Uygulama Yol Haritası

Vektör veritabanı altyapısını kurumsal mimariye entegre etmek; veri modellemesinden donanım boyutlandırmasına kadar disiplinli bir mühendislik yaklaşımı gerektirir. Süreç şu temel adımlarla yürütülür:

1. İş İhtiyacının ve Arama Tipinin Belirlenmesi: Projenin anlamsal benzerliğe mi (semantic), yoksa kesin eşleşmeye mi (exact match) ihtiyaç duyduğu netleştirilir. Hibrit bir model gerekiyorsa (örneğin e-ticarette ürün koduyla tam arama + açıklamayla anlamsal arama), hibrit mimariler planlanır.

2. Veri Parçalama ve Gömme Modeli Seçimi: Şirket verisinin diline ve yapısına uygun embedding modeli belirlenir. Parçalama boyutları (chunk size: 256, 512, 1024 token) ve çakışma payları test edilerek bilgi kaybı engellenir.

3. İndeksleme Stratejisinin Kurulması: Bellek ve gecikme hedeflerine göre HNSW veya IVF-PQ indeks yapıları seçilir. HNSW parametreleri (@@CODE0@@ bağlantı sayısı, @@CODE1@@ arama derinliği) bellek kapasitesine göre ayarlanır.

4. Güvenlik ve Meta Veri Mimarisi: Veritabanına yazılacak her vektöre kiracı ID'si (tenant_id), departman yetki seviyesi ve zaman damgası gibi meta veriler eklenir. Ön filtreleme mekanizmaları test edilir.

5. Performans ve Doğruluk Değerlendirmesi: Sistemin canlıya alınmadan önce doğruluk (Recall@K) ve gecikme (p95/p99 latency) metrikleri stres testlerine tabi tutulur.