# FAISS ile Vektörel Aramada İndeks Mimarisi > Vektör benzerlik aramasında indeks seçimi yalnız hız kararı değildir. Recall, RAM, build süresi, update davranışı, quantization hatası ve CPU/GPU veri hareketi birlikte değerlendirilmelidir. - Author: Muhammet Ali Köker - Language: tr - Canonical: https://alikoker.com.tr/faiss-vektorel-benzerlik-aramasinda-indeks-mimarisi - Published: 2019-03-15T12:00:00+03:00 - Modified: 2026-08-19T16:59:00+03:00 - Verified: 2026-08-19T16:59:00+03:00 - Type: article Bir milyon adet 768 boyutlu `float32` vektör yaklaşık 3 GB ham veri demektir. Yüz milyon vektöre çıktığınızda "cosine similarity hesaplarız" cümlesi artık algoritma tarifi değildir; bellek, indeks ve veri yerleşimi problemidir. Görüntü ve ses benzerliği gibi işlerde mesafe fonksiyonunu seçmek işin yalnız ilk kısmı. Büyük veri tarafında asıl soru, aramayı hangi hata bütçesi ve hangi gecikme sınırı altında yapacağınızdır. FAISS'i ilginç yapan da tek bir nearest-neighbor algoritması sunması değil, bu trade-off alanını açık biçimde modellemesidir. ## Exact search'in maliyeti `IndexFlatL2` veya inner-product tabanlı flat arama indeks oluşturma açısından neredeyse bedavadır. Vektörler tutulur ve sorgu geldiğinde adayların tamamı taranır. Bu yaklaşım küçük/orta veri kümelerinde güçlü bir baseline'dır. Approximate yöntemlere geçmeden önce exact sonucunu bilmek gerekir; aksi halde recall kaybını ölçemezsiniz. Flat aramanın karmaşıklığı kabaca `O(Nd)` olarak düşünülebilir. `N` vektör sayısı, `d` boyuttur. SIMD ve GPU çok büyük sabit hızlanmalar sağlayabilir fakat lineer tarama gerçeğini ortadan kaldırmaz. Bu yüzden önce baseline, sonra indeks. ## IVF: arama uzayını bölmek Inverted File (IVF) yaklaşımı vektör uzayını coarse centroid'lere böler. Her vektör en yakın centroid'in listesine yazılır. Sorgu sırasında bütün listeler yerine belirli sayıda yakın liste taranır. Buradaki temel parametrelerden biri `nprobe`'dur. Daha fazla liste taramak recall'u yükseltir, latency'yi artırır. Bu parametrenin güzel tarafı, indeks yeniden oluşturulmadan query-time kalite/hız dengesi ayarlanabilmesidir. Ancak centroid dağılımı kötü ise bazı listeler aşırı büyür. Ortalama liste boyutu tek başına yeterli değildir; imbalance ölçülmelidir. Production ortamında sıcak partition'ların tail latency'yi bozması şaşırtıcı değildir. ## Product Quantization: RAM karşılığında hata Product Quantization (PQ), yüksek boyutlu vektörü alt uzaylara ayırıp her alt uzayı küçük codebook indeksleriyle temsil eder. Böylece 768 adet float taşımak yerine çok daha kısa kodlar tutulabilir. Kazanç iki yerde gelir: bellek tüketimi düşer ve daha fazla aday cache'e sığar. Bedel ise quantization error'dur. Bu hata "yaklaşık arama zaten yaklaşık" diyerek geçiştirilemez. Uygulama için top-k sıralamasının ne kadar bozulduğunu ölçmek gerekir. Aynı recall değeri farklı sınıflar veya farklı query dağılımları için aynı iş anlamına gelmeyebilir. Adli benzerlik aramalarında örneğin false-negative maliyeti ile öneri sistemindeki false-negative maliyeti aynı değildir. ## HNSW ve graph tabanlı arama Graph tabanlı indeksler query sırasında uzayda iyi komşuluk bağlantıları üzerinden ilerler. HNSW, pratikte güçlü recall/latency dengesi nedeniyle yaygınlaşmıştır. Bununla birlikte HNSW için yalnız query hızına bakmak eksiktir. Graph bağlantıları ek bellek ister. Build maliyeti yükselebilir. Update/delete davranışı workload'a göre zorlaşabilir. FAISS'in güncel sürümlerinde HNSW ve IVF ailesi üzerinde optimizasyonlar devam ediyor. Bu da "bir kez seçilen ANN algoritması yıllarca değişmez" varsayımını zayıflatıyor. Kütüphane sürümü benchmark sonucunun bir parçasıdır. ## Cosine similarity ayrı bir indeks türü değildir Normalize edilmiş vektörler için cosine similarity, inner product üzerinden gerçekleştirilebilir. Bu basit ayrıntı veri pipeline'ında kritik bir sözleşmeye dönüşür. Vektörler indekslenmeden önce normalize ediliyor fakat query normalize edilmiyorsa sonuç semantiği bozulur. Tersi de geçerlidir. Normalization'ın embedding üretim katmanında mı, indeks servisinde mi yapılacağı tek bir yerde belirlenmelidir. İki katmanın da "nasıl olsa normalize ederiz" demesi gereksiz CPU maliyeti; hiçbirinin yapmaması ise sessiz doğruluk hatasıdır. ## GPU her durumda kazandırmaz FAISS'in güçlü yanlarından biri GPU indeksleridir. Büyük batch aramalarında GPU'nun paralelliği ciddi throughput sağlar. Fakat tekil düşük gecikmeli sorgularda host-device transferi, queueing ve kernel launch maliyeti hesaba katılmalıdır. Vektörler zaten GPU belleğinde değilse küçük sorgularda CPU daha iyi tail latency verebilir. GPU kararını verirken tek sorgu gecikmesi, batch throughput, indeksin GPU belleğine sığıp sığmaması, CPU-GPU transferi, multi-GPU sharding/replication ve eşzamanlı query sayısı ayrılmalıdır. Bir benchmark'ın 10.000 query'lik batch sonucu, request-response servisinin P99 davranışını açıklamaz. ## İndeks build süresi operasyonel maliyettir ANN sistemleri çoğu kez read-heavy varsayımıyla anlatılır. Gerçek sistemde embedding'ler güncellenebilir, yeni kayıtlar gelebilir, model sürümü değişebilir. Embedding modeli değiştiğinde eski ve yeni vektör uzaylarının birlikte tutulup tutulamayacağı sorgulanmalıdır. Çoğu durumda tüm corpus yeniden embed edilmelidir. Bu yalnız model migration değil, indeks rebuild operasyonudur. Milyarlarca vektörde build süresi ve geçici disk/RAM ihtiyacı deployment planının parçası olur. Ben bu nedenle indeks formatını cache gibi değil, versiyonlanmış bir veri ürünü gibi görmeyi daha güvenli buluyorum. ## Ölçülmesi gereken matris FAISS indekslerini karşılaştırırken tek kolonlu "QPS" tablosu yeterli değildir. Recall@k, P50/P95/P99 latency, RAM/VRAM, build time, serialized index size, update cost, query batch size, CPU/GPU utilization ve training set boyutu birlikte tutulmalıdır. 2025 ve 2026 değişikliklerinde FAISS tarafında Metal GPU backend'i, RISC-V Vector desteği, CAGRA entegrasyonu ve HNSW iyileştirmeleri gibi gelişmeler görülüyor. Dolayısıyla yıllar önce yapılan bir benchmark bugün aynı donanım/yazılım kombinasyonunu temsil etmeyebilir. ## Vektör veritabanından önce indeks semantiği Vektör veritabanı seçerken ürün özelliklerine geçmeden önce hangi indeks ailesine ihtiyaç olduğunu bilmek gerekir. Aksi halde dağıtık replication, filtreleme ve API özellikleri tartışılırken temel arama maliyeti görünmez kalır. Benzerlik aramasının özü hâlâ nettir: kabul edilebilir doğruluk kaybı karşılığında ne kadar bellek ve zaman kazanıldığı ölçülmelidir. FAISS bu hesabı görünür kıldığı için yalnız bir kütüphane değil, ANN sistemleri için iyi bir deney zemini olmaya devam ediyor. ## Kaynakça - [FAISS](https://github.com/facebookresearch/faiss) - [FAISS Wiki](https://github.com/facebookresearch/faiss/wiki) - [FAISS Changelog](https://github.com/facebookresearch/faiss/blob/main/CHANGELOG.md) ## Bu Çalışmaya Atıf Köker, M. A. (2019). FAISS ile Vektörel Aramada İndeks Mimarisi. alikoker.com.tr. https://alikoker.com.tr/faiss-vektorel-benzerlik-aramasinda-indeks-mimarisi - BibTeX: https://alikoker.com.tr/faiss-vektorel-benzerlik-aramasinda-indeks-mimarisi.bib - RIS: https://alikoker.com.tr/faiss-vektorel-benzerlik-aramasinda-indeks-mimarisi.ris - CSL-JSON: https://alikoker.com.tr/faiss-vektorel-benzerlik-aramasinda-indeks-mimarisi.csl.json