Vektör Veritabanı Seçimi 2026: pgvector, Qdrant, Milvus, Weaviate Üretim Karşılaştırması

TL;DR — 2026'da bir RAG sistemini üretime alacaksanız vektör veritabanı seçimi, projenin kaderini belirleyen kararlardan biri. Kısaca özetleyeyim: Zaten Postgres kullanıyorsanız ve ~10 milyon vektörün altındaysanız pgvector en akıllı varsayılan; ayrı bir sistem kurmadan aynı yedekleme ve operasyon disiplininde kalırsınız. Düşük gecikmeli, filtreli RAG için Qdrant benim ilk tercihim (p50 ~4 ms, p99 ~25 ms; çoğu iş yükünde Weaviate ve Milvus'a göre yaklaşık %10–25 daha hızlı). Kutudan çıkan olgun hibrit arama ve gömme (vectorizer) entegrasyonu istiyorsanız Weaviate. Milyar ölçekli iş yükleri için Milvus/Zilliz Cloud. Sadece prototip için Chroma. Ama en kritik uyarım şu: Hızlı ama recall'ı düşük bir veritabanı beş para etmez. Önce retrieval değerlendirmesini (precision/recall, bağlam ilgisi, faithfulness) kurun, sonra veritabanı tartışın.

Merhaba. Yıllardır Türkiye'de kurumsal AI projelerinde saha çalışıyorum; bankalarda, sigorta şirketlerinde, üretim firmalarında RAG (Retrieval-Augmented Generation) mimarileri kuruyor, ekiplere eğitim veriyorum. Bu yazıyı, sahada defalarca aynı soruyla karşılaştığım için yazıyorum: "Hocam biz vektör veritabanı olarak hangisini seçelim?" Sorunun ardında genellikle bir panik var, çünkü internette onlarca benchmark, her hafta çıkan yeni bir araç ve birbiriyle çelişen tavsiyeler dolaşıyor. Bugün bu kalabalığı sizin için sadeleştirmek istiyorum. Size pazarlama broşürü değil, sahadan gözlem anlatacağım.

Baştan bir şey söyleyeyim: Doğru cevap "en popüler olan" değil, "sizin iş yükünüze, ölçeğinize ve ekibinizin operasyon kapasitesine uyan" olandır. Bir bankada gördüğüm en pahalı hatalardan biri, henüz 400 bin doküman parçasıyla çalışan bir ekibin, "ileride milyarlara çıkarız" diye milyar ölçekli, karmaşık bir dağıtık sistem kurup altı ay boyunca onu ayakta tutmaya çalışmasıydı. O altı ayı ürünü iyileştirmeye harcayabilirlerdi. Gelin, bu tür hataları hep birlikte önleyelim.

RAG'ı bir kütüphane gibi düşünün. Kullanıcı bir soru soruyor, siz de o soruya en alakalı kitap sayfalarını bulup dil modeline "bak, bunlara dayanarak cevap ver" diyorsunuz. İşin sihri, "en alakalı sayfayı bulma" kısmında. Vektör veritabanı tam da bu işi yapar. Ama nasıl yaptığını anlamadan hangi aracı seçeceğinizi tartışmak, motoru bilmeden araba almaya benzer. O yüzden birkaç temel kavramı, sahada anlattığım en yalın haliyle özetleyeyim.

Gömmeler (embeddings). Bir metni, bir görseli ya da bir ses parçasını, anlamını temsil eden bir sayı dizisine (vektöre) dönüştürürüz. "Kredi kartı borcu" ile "kart ekstresi ödemesi" ifadeleri kelime olarak farklı ama anlamca yakın olduğu için bu iki metnin vektörleri de birbirine yakın düşer. RAG'ın kalbi bu: Kelime eşleşmesi değil, anlam yakınlığı. Vektörün boyutu (örneğin 768, 1024, 1536) kullandığınız gömme modeline bağlıdır ve bu boyut, hem depolama maliyetinizi hem de arama hızınızı doğrudan etkiler. Sahada sık gözden kaçan nokta: Gömme modelini değiştirdiğinizde tüm indeksinizi yeniden üretmeniz gerekir. Bu yüzden model seçimi, veritabanı seçiminden bile daha kalıcı bir karardır.

ANN indeksleri (HNSW, IVF). Elinizde 10 milyon vektör var ve gelen sorunun vektörüne en yakın 10 tanesini bulmak istiyorsunuz. Hepsini tek tek karşılaştırırsanız (buna "brute force" ya da kesin en yakın komşu deriz) doğru sonucu alırsınız ama yavaş olur. Bunun yerine "yaklaşık en yakın komşu" (Approximate Nearest Neighbor, ANN) algoritmalarını kullanırız. İki tanesini bilmeniz yeter:

• HNSW (Hierarchical Navigable Small World): Vektörleri, katmanlı bir graf yapısında birbirine bağlar. Aramayı üst katmandaki birkaç düğümden başlatıp aşağı indikçe hedefe yaklaşır. Çok hızlı ve yüksek recall verir; bugün üretimdeki çoğu sistemin varsayılanı budur. Bedeli, bellek tüketiminin yüksek olması ve indeks kurulumunun görece pahalı olmasıdır.
• IVF (Inverted File Index): Vektör uzayını önce kümelere böler, arama sırasında sadece en alakalı birkaç kümeye bakar. Belleği daha ekonomik kullanır, çok büyük veri kümelerinde avantajlıdır ama ayarı (kaç kümeye bakılacağı) recall'ı doğrudan etkiler. Genelde niceleme (quantization) ile birlikte anılır.

Filtreleme (filtering). Gerçek dünyada arama nadiren "sadece anlamca en yakını bul" şeklindedir. Neredeyse her zaman bir koşul vardır: "Bu kullanıcının erişim yetkisi olan belgeler içinde", "sadece 2025 sonrası dokümanlarda", "yalnızca 'İK politikaları' departmanına ait olanlarda". İşte bu metadata filtrelemesi, üretim RAG'ının en çok terlettiği yerdir. Bir veritabanının benchmark'ta parlak görünüp gerçek hayatta yavaşlaması genellikle filtreli aramalarda olur. Qdrant'ın öne çıktığı yerlerden biri tam da budur: Filtreleme ile vektör aramasını verimli biçimde birleştirir.

Niceleme (quantization). Vektörler varsayılan olarak 32-bit ondalık sayılarla tutulur. Niceleme, bu sayıları daha az bit ile temsil ederek (örneğin skaler niceleme ile 8-bit'e, ikili niceleme ile 1-bit'e) bellek ayak izini dramatik biçimde düşürür. Sahada bunun anlamı şu: Aynı sunucuda çok daha fazla vektör tutabilir, maliyeti aşağı çekebilirsiniz. Bedeli, küçük bir recall kaybıdır ki çoğu iş yükünde bu kayıp, yeniden sıralama (re-ranking) ile fazlasıyla telafi edilebilir. Bellek maliyetinin döviz kuruna bağlı olarak canınızı yaktığı Türkiye şartlarında nicelemeyi ciddi bir kaldıraç olarak görüyorum.

Hibrit arama (hybrid search). Vektör araması anlam yakalar ama bazı şeyleri kaçırır: Ürün kodları, kanun madde numaraları, özel isimler, kısaltmalar. "KVKK madde 6" derken kullanıcı tam olarak o ifadeyi arıyordur; anlamsal komşuluk burada yetmez. Bu yüzden vektör benzerliğini, klasik anahtar kelime aramasıyla (BM25) tek bir sorguda birleştiririz. Buna hibrit arama denir ve çoğu RAG iş yükünde recall'ı gözle görülür biçimde artırır. Weaviate, Qdrant, Turbopuffer ve Elasticsearch bunu doğal olarak destekler; içlerinde en olgun, kutudan çıkan hibrit arama deneyimi Weaviate'te.

Recall ve gecikme dengesi (recall vs latency tradeoff). Bu ikisi bir terazinin iki kefesidir ve bu yazıda anlatacağım her şeyin altında bu denge yatıyor. Recall, "bulmam gereken alakalı sonuçların yüzde kaçını gerçekten buldum" demektir. Gecikme (latency) ise "cevabı ne kadar sürede döndürdüm". ANN algoritmasını daha çok arama yapacak şekilde ayarlarsanız recall artar ama yavaşlarsınız; daha az arama yaptırırsanız hızlanırsınız ama alakalı sonuçları kaçırma riskiniz artar. Sahadaki en büyük hatalardan biri, sadece gecikmeye bakıp recall'ı ölçmeden "çok hızlı, harika" demektir. Hızlı ama yanlış cevap, yavaş doğru cevaptan daha tehlikelidir; çünkü kullanıcının güvenini sessizce aşındırır.

Çünkü "vektör arama" tek bir problem değil, bir problem ailesi. Kimi ekip Postgres'in içinde, mevcut düzeninin dışına çıkmadan bu işi halletmek ister. Kimi ekibin milyarlarca vektörü ve devasa bir trafiği vardır. Kimi ekip milisaniyelerin peşindedir çünkü ürünü gerçek zamanlıdır. Kimi de sadece bir hafta sonunda prototip çıkarıp fikri doğrulamak ister. Bu ihtiyaçlar o kadar farklı ki, tek bir aracın hepsinde birinci olması beklenemez. O yüzden ben size "en iyi vektör veritabanı" demeyeceğim; "sizin durumunuzda en iyisi" diyeceğim. Şimdi tek tek gidelim.

Sahada en sık verdiğim tavsiye bu ve çoğu zaman en az heyecan uyandıranı. pgvector, PostgreSQL'e vektör arama yeteneği ekleyen bir eklentidir. Yani ayrı bir sistem kurmuyor, öğrenmeniz gereken yeni bir operasyon dünyası açmıyorsunuz. Uygulama verilerinizle aynı veritabanında, aynı yedekleme rutininde, aynı erişim kontrolünde, aynı izleme panelinizde vektörlerinizi de tutuyorsunuz.

Bunun değerini küçümsemeyin. Bir kurumda yeni bir veritabanı sistemi devreye almak sadece teknik bir iş değildir; yedekleme politikası, felaket kurtarma planı, güvenlik denetimi, nöbetçi ekibin eğitimi, lisans ve satın alma süreçleri... Hepsi birer aydan aylara varan iştir. pgvector bu yükün neredeyse tamamını ortadan kaldırır çünkü kurumunuz zaten Postgres işletmeyi biliyordur.

Benim pratik kuralım şu: ~10 milyon vektörün altındaysanız ve zaten Postgres kullanıyorsanız, pgvector varsayılanınız olmalı. Ölçek ya da iş yükü sizi zorlamadıkça bunu değiştirmeyin. HNSW indeksini destekler, metadata filtrelemesini SQL'in tüm gücüyle yapabilirsiniz (ki bu, karmaşık koşullu sorgularda büyük konfor sağlar), ve JOIN'lerle vektör aramasını ilişkisel verinizle birleştirebilirsiniz. Bir müşteri destek sisteminde, "bu kullanıcının açık taleplerine ait dokümanlar içinde ara" gibi bir sorguyu tek bir SQL cümlesinde kurmak paha biçilmezdir.

Sınırları da dürüstçe söyleyeyim: Çok yüksek eşzamanlı sorgu trafiğinde ve on milyonlarca vektörün üzerinde, amaca özel yapılmış sistemler kadar hızlı olmayabilir. HNSW indeksinin bellek tüketimi ve indeks kurulum süresi, veriniz büyüdükçe hissedilir hale gelir. Ama şunu net söyleyeyim: Çoğu Türk kurumunun RAG projesi, ilk bir-iki yılında bu sınırlara asla ulaşmaz. "İleride lazım olur" diye baştan aşırı mühendislik yapmak, en pahalı hatadır.

Amaca özel bir vektör veritabanına geçmeye karar verdiyseniz, benim varsayılan önerim Qdrant. Nedeni basit: Sahadaki performansı çok tutarlı ve özellikle filtreli aramalarda güçlü. Rust ile yazılmış olması, bellek yönetimi ve öngörülebilir gecikme açısından ona ciddi bir avantaj kazandırıyor.

Rakamlara bakalım. Qdrant, amaca özel vektör veritabanları arasında en düşük p50 gecikmelerinden birine sahip: yaklaşık 4 ms p50, yaklaşık 25 ms p99. Yaygın iş yüklerinde Weaviate veya Milvus'a göre kabaca %10–25 daha hızlı. 10 milyon vektör ölçeğinde P99 gecikmeleri şöyle kıyaslanıyor: Qdrant ~12 ms, Weaviate ~16 ms, Milvus ~18 ms. Bu farklar küçük görünebilir ama gerçek zamanlı bir üründe, üstüne dil modelinin cevap üretme süresini de eklediğinizde, retrieval katmanındaki her milisaniye kullanıcı deneyimine doğrudan yansır.

Qdrant'ı sevmemin asıl nedeni sadece ham hız değil, filtreleme ile vektör aramasını birlikte verimli çalıştırması. Daha önce vurguladım: Üretimde neredeyse hiçbir arama filtresiz değildir. Erişim yetkisi, tarih aralığı, departman, dil, doküman türü... Qdrant bu koşulları arama sürecine verimli biçimde gömer; benchmark'ta parlayıp gerçek filtreli iş yükünde çöken sistemlerin aksine, burada tutarlılığı koruyor. Ayrıca niceleme desteği olgun; bellek maliyetini düşürmek isteyen Türk ekipleri için bu ciddi bir kaldıraç. Hibrit aramayı da doğal olarak destekliyor.

Kendi kendine barındırma (self-hosted) tarafında da rahat. Docker ile ayağa kaldırması kolay, kaynak tüketimi öngörülebilir. KVKK gereği verisini yurt dışına çıkaramayan, on-prem çalışmak zorunda olan kurumlar için bu çok önemli; birazdan bu konuya ayrı bir başlık açacağım.

Weaviate'in en güçlü olduğu yer, en olgun kutudan çıkan hibrit arama deneyimini sunması. Yani vektör benzerliği ile BM25 anahtar kelime aramasını harmanlama işini, siz elle mimari kurmadan, doğrudan sağlıyor. Hibrit aramanın RAG kalitenizde ne kadar fark yarattığını yukarıda anlattım; eğer iş yükünüz ürün kodları, hukuki referanslar, teknik terimler gibi tam eşleşme gerektiren içerikle doluysa, Weaviate'in bu olgunluğu size zaman kazandırır.

İkinci güçlü yanı, gömme modellerini (vectorizer) doğrudan entegre etmesi. Metni verirsiniz, Weaviate uygun modülle vektöre çevirip saklar; siz ayrı bir gömme boru hattı (pipeline) kurmakla uğraşmazsınız. Hızlı yol almak, prototipi üretime yakın bir mimariyle kurmak isteyen ekipler için bu konfor değerli.

Bedeli ne? Ham gecikmede Qdrant kadar keskin değil (yukarıdaki 10M ölçeğindeki P99 rakamlarını hatırlayın: ~16 ms Weaviate, ~12 ms Qdrant). Bu fark her projede belirleyici olmayabilir; ama gerçek zamanlı, gecikmeye çok duyarlı bir üründeyseniz tartın. Benim ayrımım genelde şu: Önceliğiniz olgun hibrit arama ve entegre vectorizer ise Weaviate; önceliğiniz en düşük filtreli gecikme ise Qdrant.

Bazı iş yükleri gerçekten devasadır. Yüz milyonlarca, hatta milyarlarca vektör; sürekli akan veri; yatay ölçeklenme ihtiyacı. Milvus (ve yönetilen bulut sürümü Zilliz Cloud) tam bu senaryo için tasarlanmış, dağıtık mimarisiyle milyar ölçekli iş yüklerini kaldırabilen bir sistem. Farklı indeks türlerini (HNSW, IVF varyantları ve daha fazlası) destekler, bileşenlerini bağımsız ölçeklendirebilirsiniz.

Ama dürüst olalım: Bu güç, operasyonel karmaşıklıkla gelir. Milvus'un dağıtık mimarisi, birden fazla bileşeni yönetmeyi gerektirir ve bunu doğru işletmek ciddi bir DevOps olgunluğu ister. 10 milyon vektörünüz varken Milvus'a geçmek, iki kişilik bir taşınmaya tır kiralamak gibidir; işi görür ama size fayda değil yük getirir. Yönetilen Zilliz Cloud bu yükün bir kısmını alır. Benim tavsiyem net: Milvus'u gerçekten milyar ölçeğe çıkacağınız kanıtlandığında düşünün, tahmine dayanarak değil.

Bir fikri hafta sonunda doğrulamak, bir demo hazırlamak, ekibe RAG kavramını göstermek istiyorsanız Chroma harika. Kurulumu neredeyse sıfır sürtünme; birkaç satır Python ile ayağa kalkar, geliştirici deneyimi çok temiz. Eğitimlerimde kavramları anlatırken sık sık Chroma kullanıyorum çünkü dikkati altyapıya değil, RAG mantığına odaklıyor.

Ama Chroma'yı ne için önerdiğim kadar, ne için önermediğim de önemli: Bunu ağır üretim iş yükünüzün, yüksek trafikli gerçek zamanlı sisteminizin bel kemiği yapmayın. Prototipte parlar, ölçekte zorlanır. Doğru araç, doğru aşama için. Prototipi Chroma ile doğrulayıp üretime pgvector, Qdrant ya da Weaviate ile geçmek son derece makul bir yoldur.

Aşağıdaki tabloyu, sahada bir ekibe ilk beş dakikada çizdiğim özet gibi düşünün. Nüansları yukarıda anlattım; burada hızlı karar için topluyorum.

Veritabanı	En iyi olduğu senaryo	Hibrit arama	Ölçek	Barındırma
pgvector	Zaten Postgres kullananlar; ~10M altı	Sınırlı (BM25 için ek çözüm gerekir)	~10M vektöre kadar rahat	Postgres neredeyse her yerde: on-prem, bulut, yönetilen
Qdrant	Düşük gecikmeli, filtreli RAG	Doğal destek	On milyonlar; tutarlı performans	Self-hosted (Docker) veya yönetilen bulut
Weaviate	Olgun hibrit arama + entegre vectorizer	En olgun, kutudan çıkan	On milyonlar	Self-hosted veya yönetilen bulut
Milvus / Zilliz	Milyar ölçekli, dağıtık iş yükleri	Destekler	Milyarlar	Self-hosted (karmaşık) veya Zilliz Cloud
Chroma	Prototipleme, demo, öğrenme	Temel	Küçük/orta	Genelde lokal / gömülü

Bir hatırlatma: Bu tablo bir başlangıç noktası, mutlak hüküm değil. Her araç sürekli gelişiyor; ama bu konumlandırmalar, ekiplerin en isabetli ilk kararı vermesine yetiyor.

Şimdi bu yazının en önemli bölümüne geldik ve bunu vurgulayarak söylüyorum: Hızlı ama recall'ı düşük bir veritabanı beş para etmez. Sahada gördüğüm en yaygın hata, ekiplerin benchmark rakamlarına, gecikme grafiklerine hayran olup, "sistem gerçekten doğru dokümanı buluyor mu?" sorusunu hiç ölçmemesi. Bir vektör veritabanı 4 milisaniyede cevap dönebilir ama döndürdüğü sonuçlar alakasızsa, o hız sadece yanlış cevabı daha hızlı üretmenizi sağlar.

O yüzden veritabanı tartışmasından önce bir retrieval değerlendirme (evaluation) düzeni kurmanızı istiyorum. Ölçmeniz gereken temel şeyler:

• Precision (kesinlik): Getirdiğiniz sonuçların yüzde kaçı gerçekten alakalı? Yüksek precision, dil modeline gürültü değil, temiz bağlam verdiğiniz anlamına gelir.
• Recall (anma): Var olan alakalı dokümanların yüzde kaçını yakaladınız? Düşük recall, doğru cevabın kaynağını sisteme hiç sunamamış olmanız demektir; model ne kadar iyi olursa olsun, görmediği belgeye dayanarak doğru cevap üretemez.
• Bağlam ilgisi (context relevance): Getirdiğiniz bağlam parçaları soruyla ne kadar örtüşüyor? Alakasız bağlam, hem token maliyetini artırır hem de modeli yanlış yöne çeker.
• Faithfulness (kaynağa sadakat): Modelin ürettiği cevap, getirdiğiniz bağlama gerçekten dayanıyor mu, yoksa uyduruyor (halüsinasyon) mu? RAG'ın tüm varlık sebebi, cevabı kaynağa bağlamaktır; faithfulness bunu ölçer.

Pratik önerim: Kendi verinizden gerçek soru-cevap çiftlerinden oluşan küçük ama temsili bir değerlendirme kümesi (altın küme) oluşturun. Elli-yüz iyi seçilmiş örnek bile başlangıç için çok şey söyler. Sonra her veritabanı ve her ayar değişikliğinde bu kümeyi çalıştırıp precision, recall ve faithfulness'ı ölçün. Bir gömme modelini değiştirdiğinizde, nicelemeyi açtığınızda, hibrit aramayı devreye aldığınızda bu metrikler nasıl kıpırdıyor görün. Kararı hisle değil, ölçümle verin.

Bir örnek vereyim. Bir sigorta müşterimde, ekip Qdrant'ı devreye almış ve gecikmeden çok memnundu. Ama poliçe teminatlarıyla ilgili sorularda cevaplar tuhaf biçimde eksik geliyordu. Değerlendirme kümesini kurduğumuzda gördük ki recall düşüktü: Kullanıcılar "hasar muafiyeti" gibi spesifik terimler kullanıyor, saf vektör araması bu tam-eşleşme gereken terimleri kaçırıyordu. Çözüm veritabanını değiştirmek değildi; hibrit aramayı devreye almak ve bir yeniden sıralama (re-ranking) adımı eklemekti. Recall belirgin şekilde yükseldi, gecikme hâlâ kabul edilebilir kaldı. İşte bu, ölçmeden asla göremeyeceğiniz türden bir kazanımdır.

Şimdi çok önemli bir konuya, Türkiye'de çalışmanın kendine özgü gerçeklerine gelelim. Sahada bu konuları es geçen ekipler, projeyi ileri aşamada duvara toslatıyor.

KVKK ve veri yerelliği. Kişisel Verilerin Korunması Kanunu (KVKK) kapsamında, özellikle bankacılık, sigorta, sağlık ve kamu tarafında verinin nerede işlendiği ve saklandığı kritik. Birçok kurum, müşteri verisini yurt dışındaki bir bulut hizmetine göndermek istemez ya da mevzuat gereği gönderemez. Burada iyi haber şu: Bu yazıda konuştuğumuz araçların çoğu kendi kendine barındırılabiliyor (self-hosted). pgvector zaten sizin Postgres'inizde, yani kendi veri merkezinizde ya da yerli bulutunuzda çalışır. Qdrant, Weaviate ve Milvus'un da self-hosted seçenekleri var; bunları kendi sunucularınızda, verinizi hiç dışarı çıkarmadan işletebilirsiniz. Yönetilen bulut kolaylığını seçmeden önce, kurumunuzun veri yerelliği gereksinimlerini hukuk ve uyum ekibinizle netleştirin; bu, mimariyi baştan doğru kurmanın anahtarıdır.

On-prem operasyon gerçeği. Kendi sunucunuzda çalıştırmak, sorumluluğu da size verir: Yedekleme, sürüm yükseltme, ölçekleme, izleme, güvenlik yamaları. İşte tam bu noktada pgvector'ün "aynı Postgres operasyonu" avantajı altın değerinde. Zaten Postgres işleten bir kurum için pgvector, sıfır yeni operasyonel yük demektir. Amaca özel bir sisteme geçecekseniz, Qdrant'ın öngörülebilir kaynak tüketimi ve Docker ile kolay kurulumu, on-prem ekipler için işi kolaylaştırıyor.

Maliyet ve döviz kuru. Türkiye'de bulut maliyetleri döviz cinsinden faturalandığı için, dolar/TL kuru bütçenizi doğrudan vuruyor. Bu yüzden bellek verimliliği burada dünyanın başka yerlerinden daha kritik. Nicelemeyi (quantization) ciddiye alın: 32-bit vektörleri 8-bit'e indirmek bellek ayak izini büyük ölçüde düşürür, yani aynı donanımda daha fazla vektör tutar, daha az sunucu kiralarsınız. Küçük bir recall kaybını yeniden sıralama ile telafi edebilirsiniz. Ayrıca, gereğinden büyük bir sistem kurmamak da başlı başına bir maliyet disiplinidir; 400 bin vektörle milyar ölçekli bir dağıtık sistemi ayakta tutmaya çalışan ekibin altı ayını hatırlayın. O altı ayın maliyeti, herhangi bir lisans farkından çok daha büyüktü.

Yerli bulut ve hibrit senaryolar. Türkiye'de yerli veri merkezleri ve bulut sağlayıcıları giderek olgunlaşıyor. Verinin ülkede kalması gereken hassas projelerde, self-hosted vektör veritabanını yerli bir bulutta ya da kendi veri merkezinizde çalıştırmak son derece uygulanabilir bir yol. Dil modelini de yerelde çalıştırma ihtiyacı varsa, retrieval katmanını buna uyumlu, tamamen kendi kontrolünüzde tutabilmeniz büyük avantaj. pgvector ve Qdrant, bu tür tam-kontrollü senaryolarda benim en sık önerdiğim ikili.

Size hisle değil, birkaç somut soruyla ilerleyen bir çerçeve bırakayım. Bunları sırayla kendinize sorun.

1. Zaten Postgres kullanıyor musunuz ve ~10 milyon vektörün altında mısınız? Cevabınız evetse, pgvector ile başlayın ve tartışmayı burada kapatın. Ölçek ya da iş yükü sizi zorlayana kadar başka bir şeye geçmeyin. Bu, projelerin çoğu için doğru cevaptır ve en sıkıcı olduğu için en çok göz ardı edilen cevaptır.

2. Öncelikli derdiniz düşük gecikme ve ağır filtreli arama mı? Öyleyse Qdrant'a bakın. Gerçek zamanlı bir üründeyseniz, erişim yetkisine, tarihe, departmana göre yoğun filtreliyorsanız, Qdrant'ın tutarlılığı ve hızı sizi mutlu edecektir.

3. Olgun, kutudan çıkan hibrit arama ve entegre vectorizer sizin için belirleyici mi? İçeriğiniz tam-eşleşme gerektiren terimlerle doluysa ve ayrı bir gömme boru hattı kurmakla uğraşmak istemiyorsanız Weaviate güçlü bir aday.

4. Gerçekten milyar ölçeğe çıkacağınız kanıtlandı mı? Tahmin değil, kanıt diyorum. Öyleyse Milvus/Zilliz Cloud'u değerlendirin ve operasyonel karmaşıklığa hazır olun.

5. Sadece prototip mi çıkarıyorsunuz? Chroma ile başlayın, fikri hızlıca doğrulayın, sonra üretim aracına geçin.

Ve bu beş sorunun üstünde, hepsinden önce gelen bir sıfırıncı soru var: Retrieval değerlendirme düzeninizi kurdunuz mu? Bunu kurmadan hangi veritabanının sizin için daha iyi olduğunu bilemezsiniz, çünkü karşılaştıracağınız gerçek bir ölçütünüz olmaz. Önce altın kümenizi oluşturun, precision/recall/faithfulness'ı ölçün, sonra adayları bu ölçüte göre yarıştırın.

Yıllar içinde damıttığım, tabloya sığmayan birkaç notu da paylaşmak isterim.

Gömme modelinizi veritabanınızdan daha ciddiye alın. Yanlış bir gömme modeli, dünyanın en hızlı veritabanında bile kötü recall verir; iyi bir gömme modeli, mütevazı bir veritabanında bile parlar. Türkçe içerikle çalışıyorsanız, modelin Türkçe'deki performansını kendi verinizde ölçün; İngilizce benchmark'lardaki başarı sizi yanıltmasın.

Yeniden sıralamayı (re-ranking) hafife almayın. Vektör aramasıyla ilk aday kümesini geniş tutup, ardından daha güçlü bir modelle bu adayları yeniden sıralamak, recall ve precision'ı aynı anda iyileştirebilen az sayıdaki numaradan biridir. Gecikme bütçenize sığdığı sürece, çoğu projede kaliteyi belirgin biçimde yükseltir.

Doküman parçalama (chunking) stratejinizi ihmal etmeyin. En iyi veritabanı bile, kötü parçalanmış dokümanlardan iyi bağlam çıkaramaz. Parça boyutu, örtüşme, dokümanın yapısını koruma; bunların hepsi retrieval kalitenizi doğrudan etkiler ve çoğu zaman veritabanı seçiminden daha çok fark yaratır.

Ve son olarak: Kararınızı geri döndürülebilir tutun. Retrieval katmanını, gömme boru hattınızdan ve uygulama mantığınızdan temiz bir arayüzle ayırın. Böylece ileride Qdrant'tan Milvus'a ya da pgvector'den Qdrant'a geçmeniz gerekirse, tüm sistemi baştan yazmak zorunda kalmazsınız. İyi mimari, doğru kararı ilk seferde vermekten çok, yanlış kararı ucuza düzeltebilmektir. Ölçün, küçük başlayın, veriye kulak verin; gerisi gelir.