Vektör Veritabanı Nedir? Şirket İçi Aramanın Yeni Beyni

Destek ekibinden bir arkadaş şirket arşivinde "iade koşulları" diye arıyor. Sonuç yok. Oysa aradığı belge orada duruyor, sadece içinde "geri gönderim şartları" yazıyor. İkisi aynı şeyi kastediyor ama arama kutusu bunu bilmiyor.

Bu sahne Türkiye'deki hemen her orta ölçekli şirkette yaşanıyor ve çözümü genelde şu oluyor: insanlar aramayı bırakıp birbirine soruyor. Kurumsal bilgi arama kutusundan çıkıp koridorda dolaşmaya başlıyor.

Vektör veritabanı tam bu problemi çözmek için var. Bu yazıda ne olduğunu, ne zaman gerektiğini, çoğu şirket için ne zaman gereksiz olduğunu ve gerçek maliyetini karar verici diliyle anlatıyoruz. Konuyu bütün olarak görmek isterseniz AI altyapısı kararlarının patron özetine bakın; burada o haritanın tek bir parçasına yakınlaşıyoruz.

Vektör veritabanı nedir, klasik aramadan farkı ne?

Klasik arama harf dizisi eşleştirir: yazdığınız kelime belgede geçiyorsa bulur, geçmiyorsa bulamaz. Vektör arama ise anlam eşleştirir. Metinler önce sayı dizilerine (vektörlere) çevrilir; benzer anlamlı metinler bu sayı uzayında birbirine yakın düşer. Vektör veritabanı, bu dizileri saklayan ve "bana anlamca en yakın on kaydı getir" sorusunu hızlıca cevaplayan depodur.

Metni sayı dizisine çeviren şeye embedding deniyor. Bir embedding modeli "iade koşulları" ile "geri gönderim şartları" cümlelerini birbirine yakın iki noktaya yerleştirir. Arama artık kelimeyi değil, kastedileni buluyor.

Ama burada hemen bir denge kurmak gerekiyor: tam kelimeyi bulmakta klasik arama hâlâ daha iyidir. Bir ürün kodunu, bir hata numarasını, bir sözleşme maddesinin tam ifadesini ararken anlam benzerliği işinize yaramaz; harfi harfine eşleşme lazımdır. Bu yüzden olgun sistemler ikisini birlikte çalıştırır. Aşağıda buna döneceğiz.

Zaten PostgreSQL kullanıyoruz, ayrı bir veritabanı kurmalı mıyız?

Büyük olasılıkla hayır. PostgreSQL'in pgvector eklentisi, vektörleri mevcut veritabanınızın içinde saklamanıza ve aramanıza izin veriyor. Belgeniz, metadata'nız ve vektörünüz aynı yerde durur, tek sorguyla birlikte sorgulanır. Ayrı bir sistem kurmuyorsunuz, var olana bir eklenti ekliyorsunuz.

Bu kararın fiyattan daha güçlü bir gerekçesi var: senkronizasyon derdi. Belgeler PostgreSQL'de, vektörler ayrı bir serviste durduğunda ikisinin arasında sürekli bir tutarlılık sorunu üretirsiniz. Biri yazılır diğeri yazılamazsa elinizde ya vektörü olmayan bir belge ya da belgesi silinmiş yetim bir vektör kalır. Bunu düzeltmek için bir eşitleme işi yazarsınız, o iş de bakım ister. pgvector'de belge ile vektör tek kayıt olarak yazılır ve bu problem hiç doğmaz.

Ayrı bir vektör veritabanının asıl maliyeti abonelik bedelinde çıkmaz. İki sistemi tutarlı tutma yükümlülüğünde çıkar ve bu yük aylık faturada hiç görünmez.

Kaç dokümandan sonra özel vektör veritabanı gerekir?

Dürüst cevap: eşik tek bir sayı değil ve kaynaklar da bu konuda birbiriyle çelişiyor. Pratikte üç bant üzerinden düşünmek işe yarıyor. Yaklaşık bir milyon vektöre kadar tartışma bile açmayın, pgvector rahatça taşır. Bir ila on milyon arası "duruma bağlı" bölgedir. On milyonun üzerinde özel bir vektör veritabanını ciddi ciddi konuşmaya başlayın.

"Duruma bağlı" bölgede kararı vektör sayısı belirlemiyor. İki başka faktör belirliyor. Birincisi eşzamanlı sorgu hacmi: günde birkaç yüz arama ile saniyede onlarca arama aynı şey değildir. İkincisi metadata filtreleme yoğunluğu: "sadece bu departmanın, son iki yıla ait, onaylanmış belgeleri içinde ara" tipi filtreler arttıkça özel vektör veritabanlarının avantajı belirginleşir.

Ölçek büyüdüğünde en sık geçilen adresler Qdrant ve Pinecone oluyor. Qdrant kendi sunucunuzda çalıştırmak için pratik bir seçenek; Pinecone operasyon yükünü tamamen üstlenen yönetilen bir servis. Milyar ölçekli sistemler için Milvus gibi ağır çözümler var ama bunlar adanmış bir altyapı ekibi olmadan taşınabilecek yük değil.

Vektör veritabanı maliyeti ne kadar?

Kalemleri ayırmak gerekiyor, çünkü şirketlerin pahalı sandığı kalem genelde en ucuz olanı çıkıyor.

Embedding üretimi neredeyse bedava. Yaygın kullanılan küçük embedding modellerinin fiyatı milyon token başına birkaç sent bandında. Kabaca on bin sayfalık bir kurumsal arşivi düşünün: bu, on ila on beş milyon token civarında bir metin demek. Tamamını embedding'e çevirmenin maliyeti bir doların altında kalıyor. Yıllardır biriken tüm dokümanlarınızı bir kereye mahsus işlemek, bir öğle yemeğinden ucuz.

Asıl para saklama ve sorguda. Yönetilen servislerde bir milyon vektör bandı aylık onlarca dolar seviyesinde başlıyor, elli milyon vektör bandında binlerce dolara çıkabiliyor. Kendi sunucunuzda çalıştırıyorsanız hesap RAM üzerinden yürüyor: kabaca her yüz bin ile bir milyon vektör için birkaç gigabayt ek bellek ayırmanız gerekiyor. Birkaç milyon vektörlük bir kurulum, aylık 30 ila 100 dolar bandındaki bir sunucuda rahat çalışıyor.

Bu rakamları büyüklük mertebesi olarak alın. Yönetilen servislerin çoğu kullanım tabanlı fiyatlandırıyor ve aylık faturayı önceden kestirmek gerçekten zor. Karar öncesi sağlayıcının kendi hesaplayıcısını, kendi sorgu hacmi tahmininizle doldurun. Tahmininizi yaparken şunu da hesaba katın: bir arama kutusu iyi çalışmaya başladığında kullanımı artar. İlk ay için hesapladığınız sorgu hacmi, altıncı ayda ikiye katlanmış olabilir ve kullanım tabanlı fiyatlandırmada bu artış doğrudan faturaya yansır.

Neden sadece vektör arama yetmiyor?

Çünkü kullanıcıların önemli bir kısmı anlam benzerliği aramıyor; tam ifade arıyor. Bir üretim ortamı değerlendirmesinde saf vektör aramanın ilk on sonuçtaki isabet oranı %78 çıkmış; saf anahtar kelime aramasında %65; ikisini birleştiren hibrit aramada %91. Aradaki fark, iki yöntemin farklı sorularda battığı gerçeğinden geliyor.

Bu rakamlar tek bir kaynaktan geliyor ve akademik bir kıyaslama değil, o yüzden mutlak doğru gibi okumayın. Ama gösterdikleri yön sahada gördüğümüzle örtüşüyor: destek sorgularının önemli bir bölümü içinde bir hata kodu, bir ürün tanımlayıcısı ya da bir mevzuat maddesi numarası taşıyor. Saf vektör arama tam da bu sorgularda tökezliyor.

Hibrit aramada iki sonuç listesi birleştirilir. Burada acemi hata, iki yöntemin skorlarını toplayıp ortalamasını almaktır. Skorlar farklı ölçeklerde üretildiği için bu birleştirme anlamsız sonuç verir. Doğru yöntem skorları değil sıraları birleştirmektir; sektörde bunun standart karşılığı RRF adı verilen basit bir sıralama birleştirme yöntemi.

Aramanızın kalitesini belirleyen görünmez karar: chunking

Uzun belgeler veritabanına bütün olarak konmaz; parçalara bölünerek konur. Bu parçalama işine chunking deniyor ve arama kalitesini veritabanı seçiminden daha fazla etkiliyor.

Sebebi şu: bir vektör, temsil ettiği metnin ortalama anlamını taşır. Kırk sayfalık bir yönetmeliği tek parça olarak koyarsanız, o parçanın vektörü hiçbir spesifik soruya yakın düşmez; her şeyin biraz uzağında bir noktada durur. Aşırı küçük parçalara bölerseniz bu sefer bağlam kaybolur, sonuç olarak dönen paragraf tek başına anlamsız kalır.

Bir de tutarlılık meselesi var. Arşivinizin yarısı iki yüz kelimelik parçalardan, yarısı beş bin kelimelik belgelerden oluşuyorsa, anahtar kelime tarafındaki uzunluk normalizasyonu iki farklı korpusla aynı anda boğuşmak zorunda kalır ve isabet oranı düşer. Parça boyutlarını tutarlı tutmak, hiçbir yeni yazılım almadan arama kalitesini yükselten en ucuz müdahaledir.

Sık sorulan sorular

Bu konuyu konuştuğumuz toplantılarda dönüp dolaşıp aynı dört soru geliyor. Cevapları burada topladık.

Vektör veritabanı ile normal veritabanı arasındaki fark ne?

Normal veritabanı "bu değere eşit olan kayıtları getir" sorusunu cevaplar. Vektör veritabanı "bu anlama en yakın kayıtları getir" sorusunu cevaplar. Birincisi kesin eşleşme, ikincisi yakınlık sıralaması üretir. Aynı kaydı ikisi de saklayabilir; ayrıştıkları yer sorunun türüdür.

Kaç dokümandan sonra özel bir vektör veritabanı gerekir?

Doküman sayısı yanıltıcı bir ölçü, çünkü belgeleriniz parçalara bölünerek saklanıyor. Yüz sayfalık bir belge yüzlerce vektöre dönüşebilir. Kabaca on bin sayfalık bir arşiv birkaç yüz bin vektör üretir ve bu, pgvector için rahat bir yük. Milyonlu bantlara çıktığınızda tartışmayı yeniden açın.

Verilerimiz dışarı çıkar mı?

Bu, veritabanının kendisiyle değil embedding üretimiyle ilgili bir soru. Vektör veritabanını kendi sunucunuzda çalıştırsanız bile, metni sayı dizisine çevirmek için dışarıdaki bir servise gönderiyorsanız veri dışarı çıkmış olur. Tamamen kurum içinde kalması gereken belgelerde embedding modelini de kendi sunucunuzda çalıştırmanız gerekir.

Zaten bir arama motorumuz var, onu atmalı mıyız?

Hayır, üstelik atmamanız daha iyi. Elinizdeki anahtar kelime araması hibrit kurgunun yarısını zaten oluşturuyor. Yapılacak iş, onun yerine yeni bir sistem koymak yerine yanına anlam tabanlı bir katman eklemek ve iki listeyi birleştirmek. Bu yaklaşım hem daha ucuz hem de mevcut aramanın iyi olduğu sorgularda kalite kaybı yaratmıyor. Var olan aramayı kapatıp yerine saf vektör arama koyan ekipler, ürün kodu arayan kullanıcıların şikayetiyle birkaç hafta içinde geri dönüyor.

Hazır bir asistana dosya yüklemekten farkı ne?

Birkaç dosyalık işlerde fark yok, hatta dosya yüklemek daha pratik. Fark, arşiv büyüdüğünde ortaya çıkıyor: on binlerce belgeyi her soruda yeniden yükleyemezsiniz. Vektör veritabanı, o arşivi bir kez işleyip her soruda yalnızca ilgili parçaları getirmenizi sağlıyor.

Sahada gördüğümüz dört hata

• Veritabanını seçip işi bitmiş saymak. Kaliteyi belirleyen chunking, hibrit arama ve gerektiğinde yeniden sıralama katmanıdır. Veritabanı markası bu üçünün yanında ikincil bir karardır.
• İndeksi ilk günden kurmak. Küçük tablolarda indekssiz arama zaten milisaniyelerle ölçülür. Sorgular yavaşladığında HNSW indeksini eklemek, baştan yanlış parametrelerle kurmaktan iyidir.
• Yeniden sıralamayı erken eklemek. Sonuçları yeniden sıralayan modeller isabeti artırır ama sorgu başına birkaç yüz milisaniye gecikme ve ciddi bir maliyet farkı getirir. Önce hibrit aramayı kurun, ölçün, gerekirse ekleyin.
• Değerlendirme setini hiç oluşturmamak. Elli gerçek soru ve bunların doğru cevaplarının bulunduğu belgelerden oluşan küçük bir liste hazırlamadan hiçbir iyileştirmenin işe yarayıp yaramadığını bilemezsiniz. Bu liste bir öğleden sonrada hazırlanır ve aylarca işinize yarar.

Peki siz ne yapmalısınız?

• Önce ölçeğinizi sayın. Kaç belge, kaç sayfa, günde kaç arama? Bir milyon vektörün altındaysanız araç tartışmasını kapatın, pgvector ile başlayın.
• Mevcut veritabanınızın üzerine kurun. PostgreSQL zaten çalışıyorsa yeni bir sistem eklemenin operasyonel bedelini ödemeden önce eklentiyi deneyin.
• Hibrit aramayı baştan planlayın. Saf vektör arama ile başlayan projelerin çoğu birkaç ay sonra anahtar kelime katmanını geri ekliyor. Baştan kurmak daha ucuz.
• Chunking'e vakit ayırın. Belgelerinizi hangi mantıkla böleceğiniz, hangi veritabanını seçtiğinizden daha belirleyici.
• Verinin nereye gittiğini bilin. Embedding üretimi için dışarıdaki bir servise metin gönderiyorsanız, o metin yurt dışına çıkıyor demektir. Hassas belgelerde bu karar teknik olmaktan çıkıp hukuki bir karara dönüşür.

Vektör veritabanı, kurumsal aramayı kelime eşleştirmekten anlam eşleştirmeye taşıyan gerçek bir sıçrama. Ama tek başına bir çözüm sayılmaz; bir yapı taşıdır. Bu yapı taşını doğru yere koyduğunuzda arşivinizdeki bilgi koridorda değil arama kutusunda bulunmaya başlıyor. Nasıl bir soru-cevap katmanı kurulacağını merak ediyorsanız RAG yazımız bu yapı taşının üzerine ne inşa edildiğini anlatıyor.