Die Actian VectorAI-Datenbank unterstützt nun die IVF-Indizierung und die Vektorquantisierung

Actian VectorAI DB unterstützt bereits die HNSW-Indizierung (Hierarchical Navigable Small World), die nach wie vor die richtige Standardwahl ist, wenn es vor allem auf den Recall bei geringer Latenz ankommt und der Speicher keine Einschränkung darstellt.

Doch Speicher ist oft genau das. Deshalb unterstützt die Actian VectorAI DB jetzt die Indizierung mit Inverted-File-Verfahren (IVF) sowie die Vektorquantisierung neben HNSW und hilft Anwendern so, Speicherbeschränkungen zu umgehen. Sie wählen das Speicher-, Abruf- und Latenzprofil, das zu jedem Ziel im Bereich „ Deployment “ passt, anstatt überall ein und dasselbe Profil zu verwenden.

IVF verkleinert den Index und senkt die Kosten für Aktualisierungen, die Quantisierung komprimiert jeden Vektor zusätzlich, und zusammen ermöglichen sie die Vektorsuche in der Produktion auf Hardware, auf der ein Graph-Index nicht laufen würde. Ein semantischer Suchindex auf einem Mobilgerät oder einem industriellen Gateway, ein E-Commerce-Katalog, der sich häufig ändert, oder eine Sammlung, die ihr Speicherbudget überschritten hat: Sie wählen das Speicher-, Abruf- und Latenzprofil für jedes Ziel der „ Deployment “ aus, anstatt überall ein einheitliches Profil zu verwenden.

Warum IVF und Produktquantisierung zusammen wichtiger sind als jede für sich allein

Die Quantisierung bestimmt, wie viel Speicherplatz jeder Vektor beansprucht. IVF steuert, wie viel des Indexes ein „ abfragen “ durchsuchen muss und wie viel bei Datenänderungen neu aufgebaut werden muss. In Kombination optimieren sie den Speicherbedarf und den Rechenaufwand pro „abfragen “ in derselben Engine.

Diese Kombination verändert, welche Anwendungsfälle realisierbar sind:

Bereitstellungen mit begrenzten Speicherressourcen und Edge-Bereitstellungen: Ein kleinerer Index pro Vektor ermöglicht die Ausführung der semantischen Suche oder der „Retrieval-Augmented Generation“ auf einem mobilen Gerät, einem industriellen Gateway oder einem Sensor im Rahmen des „ IoT “ mit begrenztem Speicherplatz. Ein Graph-Index derselben Sammlung passt möglicherweise gar nicht auf das Gerät.

Daten mit hohem Schreibaufwand und häufiger Aktualisierung:Cluster Zuweisungen lassen sich kostengünstiger neu erstellen oder teilweise aktualisieren als ein Graph. E-Commerce-Kataloge mit ständigem Bestandsumschlag und umfangreicher Erkennung von „ Anomalie “ sind hier be Nutzen .

Infrastrukturkosten bei großem Umfang: Ein kleinerer Index bei gleicher „ Datensatz “ bedeutet weniger oder kleinere Knoten. Bei Hunderten von Millionen Vektoren wird der Speicherbedarf pro Vektor zu einer Frage der Knotenanzahl und damit zu einer Frage des Budgets.

Die Wahl zwischen HNSW und IVF

Verwenden Sie HNSW, wenn der Abruf mit geringer Latenz Priorität hat und der Speicher keine Einschränkung darstellt. Greifen Sie auf IVF zurück, wenn der Index einen geringeren Speicherbedarf haben muss, wenn sich die Daten ständig ändern oder wenn der Datenbestand so stark wächst, dass er die Kapazität des Speichers übersteigt.

Egal, wofür Sie sich entscheiden: Messen Sie die Leistung anhand Ihrer eigenen Daten. Eine Vektordatenbank kann den Recall nicht von sich aus ermitteln, da sie die richtigen Ergebnisse für eine „ abfragen “ nicht kennen kann. Sie benötigen „Ground Truth“, also einen Testsatz aus Abfragen mit bekannten richtigen Antworten, sowie einen Recall-Wert, der aus Hunderten dieser Abfragen gemittelt wird. Branchen-Benchmarks sind ein sinnvoller Ausgangspunkt für Vergleiche, aber nur Ihre eigenen „ abfragen “-Muster geben Aufschluss darüber, wie ein System bei Ihren „ Workload “ abschneidet.

Vorhandene Indizierung in der VectorAI-Datenbank

Bis zur Veröffentlichung im Oktober 2026 lieferte VectorAI DB ausschließlich HNSW aus. HNSW ist ein mehrschichtiger Graph, in dem jeder Vektor einen Knoten darstellt, der mit benachbarten Knoten verbunden ist. Die Suche beginnt mit großen Sprüngen über eine spärlich besetzte oberste Schicht und wird nach unten hin verfeinert, bis nur noch eine kleine Anzahl von Kandidaten verglichen werden muss. Dies sorgt für eine hohe Trefferquote bei geringer Latenz, was für Empfehlungssysteme, die durch Abruf erweiterte Generierung über einen Dokumentensatz hinweg und die semantische Suche in einem Katalog erforderlich ist.

Der Overhead bei der HNSW-Indizierung ist die Grafik selbst. HNSW speichert Verknüpfungen zusätzlich zu den Rohvektoren, sodass der Index deutlich größer ist als die Vektoren allein. Auch das Aufbauen dieser Verknüpfungen nimmt viel Zeit in Anspruch.

In von „ Cloud “ verwalteten Vektordatenbanken übernimmt der Dienst diesen Speicher-Overhead. Bei „ On-Premises “ oder am Edge fehlt jedoch die Skalierbarkeit, um diesen zu absorbieren. Der Overhead wird somit zu einer Einschränkung.

Was ist IVF?

IVF unterteilt Vektoren in Cluster, anstatt einen Graphen zu erstellen. Jeder „ Cluster “ verfügt über einen „Centroid“, einen synthetischen Punkt an der durchschnittlichen Position der ihm zugeordneten Vektoren. Jeder Vektor wird dem „ Cluster “ mit dem nächstgelegenen Centroid zugeordnet.

Die Suche erfolgt in zwei Schritten. Zunächst wird der „ abfragen “ mit den Zentren verglichen, um die vielversprechendsten Cluster zu identifizieren. Dieser Schritt ist ressourcenschonend, da es weitaus weniger Cluster als Vektoren gibt. Anschließend durchsucht der „ abfragen “ eine Teilmenge dieser Cluster. Die Größe dieser Teilmenge ist konfigurierbar: Sie wird über einen Parameter gesteuert. Niedrige Werte, die eine kleinere Teilmenge durchsuchen, liefern schneller Ergebnisse, während die Suche in einer größeren Teilmenge den Recall erhöht, allerdings auf Kosten der Latenz.

Aus dieser Struktur ergeben sich drei Eigenschaften:

• Der Index ist kleiner, da er Vektoren und „ Cluster “-Zuweisungen enthält und keinen Graphen.
• Die Recall-Genauigkeit lässt sich über die Parameter „ abfragen “ einstellen, sodass Sie sie auf einen bestimmten Latenzwert abstimmen können, ohne etwas neu kompilieren zu müssen.
• Das „ Cluster “-Layout bleibt im Vergleich zu festplattenbasiertem Speicher leistungsfähig, sodass der Index nicht durch den verfügbaren Arbeitsspeicher begrenzt wird.

Der Nachteil ist der Aufwand bei der Feinabstimmung. Um die Recall-Rate von HNSW zu erreichen, muss IVF mehr Cluster durchsuchen, was die Latenz erhöht. Änderungen an den IVF-Parametern wirken sich zudem auf die Recall-Rate aus, sodass die Feinabstimmung im Vergleich zu den Standardeinstellungen von HNSW umfangreichere Tests erfordert.

Was ist Vektorquantisierung?

Bei der Quantisierung wird jeder Vektor auf eine kleinere Darstellung komprimiert, wobei ein Teil der numerischen Genauigkeit zugunsten eines geringeren Datenbedarfs geopfert wird. Ein Vektor mit voller Genauigkeit speichert jede Dimension in voller Breite. Ein quantisierter Vektor approximiert diesen auf einem Bruchteil des Speicherplatzes.

VectorAI DB unterstützt drei IVF-Varianten:

• Flat: Unkomprimierte Vektoren in Clustern, ohne Quantisierung. Dieser Ansatz bietet die höchste Genauigkeit, beansprucht jedoch den gesamten Vektor-Speicherplatz.
• Produktquantisierung: Jeder Vektor wird in Teilvektoren aufgeteilt und anhand eines trainierten Codebuchs codiert, was die größte Reduzierung des Speicherbedarfs bewirkt
• Skalare Quantisierung: Die Genauigkeit jeder Dimension wird reduziert, wodurch in der Regel eine höhere Genauigkeit erhalten bleibt, die Speicherplatzersparnis jedoch geringer ist als bei der Produktquantisierung.

Die Quantisierung löst das Problem „Unser Index ist zu groß, um in den Arbeitsspeicher zu passen“ direkt, indem sie die Indexgröße zugunsten der Abrufgeschwindigkeit opfert. Sie legen das Gleichgewicht fest, indem Sie den Komprimierungsgrad wählen, der die Genauigkeitsanforderungen Ihrer use case erfüllt.

IVF überall dort einsetzen, wo Container eingesetzt werden können

Die Wahl des Indexes ist für eine Vektordatenbank das A und O. Der Umfang der Bereiche, in denen der Index ausgeführt werden kann, ist das, was VectorAI DB auszeichnet.

Regulierte Branchen, staatliche KI-Vorgaben, isolierte Standorte und datenschutzrelevante Anwendungen auf Endgeräten erfordern alle eine Vektorsuche innerhalb eines von ihnen kontrollierten Bereichs. Ein Index mit geringerem Speicherbedarf sorgt dafür, dass ein größerer Teil Ihrer „ Workload “ dort verbleiben kann. Dies ist besonders dann von Bedeutung, wenn eine lokale Inferenz erforderlich ist.

VectorAI DB ist eine „Local-First“-Vektordatenbank. Sie lässt sich als portabler Container oder als Edge-Laufzeitumgebung „ eingebettet “ bereitstellen, ohne dass ein „ Cloud “-Dienst im Hintergrund läuft und ohne dass Daten Ihre Umgebung verlassen. Dieselbe Engine kann auf einem „ Cloud “-Knoten, einem lokalen Server, einem industriellen Gateway oder in einer vom Netz getrennten Einrichtung ausgeführt werden. Durch IVF und Quantisierung macht VectorAI DB diese kleineren Zielsysteme nutzbar und reduziert den Speicherbedarf des Indexes auf ein Maß, das zur jeweiligen Hardware passt.

Bei anderen Lösungen bedeutet eine lokale Bereitstellung in der Regel, dass man sich mit einem geringeren Durchsatz abfinden muss. VectorAI DB minimiert diesen Kompromiss jedoch: Im Benchmark ist es 22-mal schneller als die gängigste Open-Source-Engine.

Probieren Sie IVF und Quantisierung anhand Ihrer eigenen Daten aus

Laden Sie die Actian VectorAI DB Community Edition herunter und erstellen Sie kostenlos einen IVF-Index. Für bestehende Nutzer von VectorAI DB entstehen keine neuen Abhängigkeiten und es muss nichts neu eingerichtet werden. Führen Sie Ihren eigenen Vergleich hinsichtlich Recall und Latenz mit HNSW durch und sprechen Sie dann mit Actian über einen Produktionsvertrag, sobald Sie bereit sind.

• Laden Sie VectorAI DB Community Edition kostenlos herunter .
• Sehen Sie sich das Spiel HNSW gegen IVF an : So wählen Sie den richtigen Vektorindex aus.
• Treten Sie der Actian-Discord-Community bei .

Über den Autor

Über Matthew D. Groves

Matthew D. Groves ist ein Entwickler, der seine Leidenschaft für Technologie in eine Karriere verwandelt hat, die Softwareentwicklung, Entwicklerförderung und Produktmarketing umfasst. Seine berufliche Programmier Migration n in den 1990er Jahren, als er für die Pizzeria seiner Eltern eine QuickBASIC-Kassenanwendung entwickelte. Heute ist Matthew als Director of Product Management für Datenbanken bei Actian tätig, wo er die Zukunft der Datenbanktechnologie mitgestaltet. Wenn er sich gerade nicht mit Datenbanken beschäftigt oder Code schreibt, verbringt Matthew gerne Zeit mit seiner Familie, unternimmt Ausflüge mit dem Auto, feuert die Cincinnati Reds an und betreibt eine Eisdiele in seiner Heimatstadt in Ohio.