VectorVFS – Dateisystem als Vektordatenbank nutzen

• VectorVFS speichert Vektor-Embeddings als Metadaten pro Datei und ermöglicht so, das Linux-Dateisystem selbst als Vektordatenbank zu nutzen
• Ohne externen Index oder DB wird durch die xattrs-Funktion (erweiterte Attribute) des Dateisystems eine Indexierung ohne Overhead erreicht
• Ähnliche Dateien lassen sich per Embedding-Suche finden, wobei keine Abhängigkeit von einem bestimmten Modell besteht und verschiedene Embedding-Modelle angebunden werden können
• Mit Metas Perception Encoders (PE) werden bild-/videobasierte Vektor-Embeddings erzeugt, die eine höhere Zero-Shot-Performance als andere Modelle zeigen
• Durch die leichte und portable Architektur ist die direkte Nutzung ohne separaten Daemon oder Service möglich

---

Einführung

• VectorVFS ist eine leichtgewichtige Python-Bibliothek, die allein mit den Grundfunktionen des Linux-Dateisystems das Speichern und Durchsuchen von Embeddings für Dateien ermöglicht
• Ohne externe Datenbank werden Embedding-Werte in den erweiterten Attributen (xattrs) jeder Datei gespeichert
• So lässt sich eine bestehende Verzeichnisstruktur unverändert beibehalten und zugleich zu einem System mit semantischer Suche erweitern

Hauptfunktionen

• Indexierung ohne Overhead

  • Vektor-Embeddings werden direkt als xattr der Datei gespeichert
  • Kein externer Indexierungsdienst und kein zusätzlicher Speicher erforderlich, da die Daten nur als Metadaten neben der Datei existieren

• Nahtlose Suche

  • Vektorbasierte Ähnlichkeitssuche über das gesamte Dateisystem möglich
  • Beispiel: Ähnliche Bilddateien können mit find_similar_images('example.jpg') gefunden werden

• Flexible Embedding-Unterstützung

  • Standardmäßig wird Metas Modell Perception Encoders (PE) verwendet
  • Künftig ist Unterstützung für verschiedene Embedding-Modelle geplant, z. B. für Text, Audio und Multimodalität
  • Auch benutzerdefinierte Embedding-Modelle lassen sich per Plugin anbinden

• Leichtgewichtig und portabel

  • Auf Basis der Linux-VFS-(xattr-)Funktionen sind keine separaten Daemons oder Server-Konfigurationen nötig
  • Durch den portablen Ansatz ist die Nutzung auch in lokalen Verzeichnissen oder auf externen Speichern möglich

• Verwendetes Embedding-Modell: Meta Perception Encoders

  • PE ist ein von Meta vorgestelltes Vision-Language-Modell für Bilder und Videos
  • Gegenüber Konkurrenzmodellen wie InternVL3, Qwen2.5VL und SigLIP2 bietet es bessere Zero-Shot-Performance
  • Künftig sollen weitere Embedding-Modelle als Backend hinzukommen

Zusammenfassung

• Es lässt sich ein Vektorsystem mit semantischer Suche aufbauen, ohne die bestehende Dateistruktur zu verändern
• Die Kosten für die Speicherung von Embeddings sind nahezu null, und das System funktioniert ohne separate Infrastruktur
• Besonders geeignet ist es für Datenschutz und Suchfunktionen auf Offline- oder Edge-Geräten

[GN⁺]

Hacker-News-Kommentare

• Der Vergleich mit einer Vector Database ist verwirrend. Eine Datenbank bedeutet normalerweise Unterstützung für Indizes und Abfragen

  • Embeddings als Dateien zu speichern, ist ein interessantes Konzept. In einigen Dateiformaten (EXIF) wird das bereits genutzt. Für die Verarbeitung in großem Maßstab ist jedoch eine echte Datenbank nötig
  • Die Herausforderung besteht darin, verschiedene Modelle und Embedding-Formate zu unterstützen, um die Portabilität der Daten zu erhöhen. Unabhängig davon, in welches System eine Datei eingebracht wird, sollten die Embeddings nahtlos integriert werden

• Es geht darum, Metadaten an Dateien anzuhängen, damit Werkzeuge, die LLMs oder Embedding-Vektoren verstehen, die Datei verstehen können, ohne ihren Inhalt zu lesen

  • Es gibt viele interessante Anwendungsfälle. Zum Beispiel könnte man das Dateisystem mit einem Prompt wie „Spiele das Video ab, in dem ich letzten Monat beim Campen einen Truthahnschwarm gesehen habe“ schnell durchsuchen. Allerdings müsste dafür dennoch eine echte Vector DB auf dem System laufen

• Es könnte interessant sein, dem Projekt optional Weaviate und flat-index hinzuzufügen

  • Es ist vollständig festplattenbasiert, ohne externe Services zu verwenden. Das gesamte Dateisystem kann durchsucht werden (etwa 1,5 KB pro Datei, 384 Dimensionen)

• Eine großartige Idee

  • Die Dokumentation braucht mehr Informationen, zum Beispiel welche GPU-Backends unterstützt werden und wie sich Embedding-Informationen löschen lassen
  • Einen Versuch ist es wert

• Wenn VectorVFS die Suchlogik hinter intransparenten Embeddings verbirgt, frage ich mich, wie Nutzer debuggen sollen, warum eine Datei erscheint oder nicht erscheint

• Die alte Debatte zwischen Dateisystem und Datenbank ist immer interessant. Wenn ich so etwas lese, habe ich am Ende immer noch mehr Fragen

• Ich habe etwas Ähnliches gemacht, aber mit EXT4-Anforderungen

  • harte Links (für Backups funktionierte nur tar)
  • kleine Dateigrößen (die Inodes waren früher erschöpft als der Speicherplatz)
  • nützlich für weltweit verteilte Echtzeitdaten. Das P in CAP ist für Schreibvorgänge nicht nötig

• Embeddings in Inodes zu speichern, ist eine witzige Idee. Sehr clever

  • Für eine Vector Database ist das nichts, was sich wirklich verwenden lässt. Es gibt kein Konzept für Suchindizes. Alle Dateien werden mit einer linearen O(N)-Suche durchsucht
  • Trotzdem eine witzige Idee

• Ich habe vor ein paar Jahren etwas Ähnliches untersucht. Dabei wurden Embeddings in xattrs gespeichert