6 puan yazan GN⁺ 2025-05-06 | 1 yorum | WhatsApp'ta paylaş
  • VectorVFS, her dosya için vektör gömmelerini metadata olarak depolar ve böylece Linux dosya sisteminin kendisini bir vektör veritabanı olarak kullanmayı mümkün kılan bir Python paketidir
  • Harici indeks veya DB olmadan, dosya sisteminin xattrs (genişletilmiş öznitelikler) özelliği üzerinden sıfır ek yükle indeksleme gerçekleştirir
  • Gömmeler üzerinde arama ile benzer dosyaları keşfetmek mümkündür ve belirli bir modele bağlı olmadan çeşitli gömme modelleri bağlanabilir
  • Meta'nın Perception Encoders (PE) modelini kullanarak görüntü/video tabanlı vektör gömmeleri üretir; bu model diğer modellere göre daha yüksek zero-shot performansı gösterir
  • Hafif ve taşınabilir yapısı sayesinde ayrı bir daemon veya servis olmadan doğrudan kullanılabilir

Giriş

  • VectorVFS, yalnızca Linux dosya sisteminin temel özellikleriyle dosyalar için gömme depolama ve arama imkanı sunan hafif bir Python kütüphanesidir
  • Harici bir veritabanı olmadan, her dosyanın genişletilmiş özniteliklerinde (xattrs) gömme değerlerini saklar
  • Mevcut dizin yapısını aynen korurken bunu anlamsal arama yapabilen bir sisteme genişletebilir

Başlıca özellikler

  • Zero-overhead indexing

    • Vektör gömmelerini doğrudan dosyanın xattr alanına kaydeder
    • Harici bir indeksleme servisi veya ek depolama gerekmez; yalnızca dosyanın yanında metadata olarak bulunur
  • Seamless retrieval

    • Tüm dosya sistemi üzerinde vektör tabanlı benzerlik araması yapılabilir
    • Örnek: find_similar_images('example.jpg') gibi bir yöntemle benzer görsel dosyaları bulunabilir
  • Flexible embedding support

    • Varsayılan olarak Meta'nın Perception Encoders (PE) modeli kullanılır
    • İleride çeşitli gömme modellerinin (ör. metin, ses, multimodal) desteklenmesi planlanıyor
    • Kullanıcı tanımlı gömme modelleri de eklenti biçiminde entegre edilebilir
  • Lightweight and portable

    • Linux VFS (xattr) özelliğine dayandığı için ayrı bir daemon veya sunucu kurulumu gerektirmez
    • Taşınabilir yapısı sayesinde yerel dizinlerde veya harici depolamada da kullanılabilir
  • Kullanılan gömme modeli: Meta Perception Encoders

    • PE, Meta'nın duyurduğu görüntü/video tabanlı bir vision-language modelidir
    • Rakip modeller InternVL3, Qwen2.5VL ve SigLIP2'ye göre zero-shot performansı daha yüksektir
    • İleride çeşitli backend gömme modelleri eklenecektir

Özet

  • Mevcut dosya yapısını korurken anlam tabanlı arama yapabilen bir vektör sistemi kurulabilir
  • Gömme depolama maliyeti neredeyse yoktur ve ek altyapı olmadan çalışabilir
  • Çevrimdışı/edge cihazlarda gizliliği koruyarak arama işlevi sunmak için uygundur

1 yorum

 
GN⁺ 2025-05-06
Hacker News görüşleri
  • Bunu Vector Database ile karşılaştırmak kafa karıştırıcı. Veritabanı genelde indeksleme ve sorgu desteği anlamına gelir

    • Embedding'leri dosya olarak saklamak ilginç bir fikir. Bazı dosya biçimlerinde (EXIF) zaten kullanılıyor. Ancak büyük ölçekli işlem için gerçek bir veritabanı gerekir
    • Farklı modelleri ve embedding biçimlerini destekleyerek verinin taşınabilirliğini artırmak mesele. Dosyalar hangi sisteme konursa konsun, embedding'ler sorunsuz biçimde entegre olmalı
  • Amaç, dosyaya metadata ekleyerek LLM'leri veya embedding vektörlerini anlayabilen araçların dosyanın içeriğini okumadan da dosyayı anlayabilmesini sağlamak

    • İlginç birçok kullanım senaryosu var. Örneğin, "geçen ay kampa gittiğimde hindi sürüsü gördüğüm videoyu oynat" gibi bir prompt ile dosya sistemi hızlıca aranabilir. Ancak sistemde gerçek bir vektör DB'nin çalışıyor olması gerekir
  • Projeye isteğe bağlı olarak Weaviate ve flat-index eklemek ilginç olabilir

    • Harici servis kullanmadan tamamen disk tabanlı. Tüm dosya sistemi aranabilir (dosya başına yaklaşık 1.5kb, 384 boyut)
  • Harika bir fikir

    • Dokümantasyonda daha fazla bilgi olmalı. Örneğin hangi GPU backend'lerinin desteklendiği ya da embedding bilgisinin nasıl silineceği gibi
    • Denemeye değer
  • VectorVFS arama mantığını opak embedding'lerin arkasına gizlerse, kullanıcı dosyanın neden göründüğünü ya da neden görünmediğini nasıl debug edecek, merak ediyorum

  • Dosya sistemi ile veritabanı arasındaki eski tartışma her zaman ilgi çekici. Böyle şeyler okuyunca aklımda hep daha fazla soru oluşuyor

  • Benzer bir şey yaptım ama EXT4 gereksinimlerini kullandım

    • Hard link'ler (tar yedekler için tek çalışan şeydi)
    • Küçük dosya boyutu (disk alanından önce inode'lar tükeniyordu)
    • Dünya geneline dağılmış gerçek zamanlı veriler için kullanışlı. CAP'teki P, yazma tarafında gerekli değil
  • Embedding'leri inode'a kaydetmek eğlenceli bir fikir. Oldukça zekice

    • Aslında vektör veritabanı olarak kullanılabilecek bir şey değil. Arama indeksi kavramı yok. Tüm dosyalar O(N) doğrusal olarak taranıyor
    • Yine de eğlenceli bir fikir
  • Birkaç yıl önce benzer bir şeyi araştırmıştım. Embedding'leri xattrs içinde sakladım