Pinecone veröffentlicht pg_pinecone, eine Open-Source-Postgres-Erweiterung für die Vektorsuche

Was pg_pinecone leistet und welches Problem es angeht

Pinecone zufolge hängen KI-Funktionen wie Support-Assistenten, Empfehlungssysteme für Produkte und Agenten mit Gedächtnis davon ab, die relevantesten Datensätze schnell und präzise zu finden. Bei vielen Teams liegen diese Daten in Postgres. Der heute übliche Ansatz, ein Graphindex wie HNSW in pgvector, werde beim Skalieren teuer, argumentiert das Unternehmen. Graphindizes benötigen demnach immer mehr Arbeitsspeicher, um die Leistung zu halten, und brauchen lange für den Aufbau.

Eine zweite Schwäche sieht Pinecone bei der gefilterten Suche. Ist eine Abfrage auf einen Nutzer oder einen Mandanten begrenzt, kann ein Graphindex weniger Ergebnisse liefern als angefordert. Eine Anwendung verpasst dann womöglich Treffer, die sie hätte finden müssen.

pg_pinecone arbeitet mit den Vektorspalten, die bereits in pgvector vorhanden sind. Die Anwendung verbindet sich auf dieselbe Weise mit Postgres und sendet dasselbe SQL, etwa ORDER BY embedding <=> $1 LIMIT 10. Die Tabellen samt den vollständigen Vektoren bleiben, wo sie sind, und Postgres bleibt das führende System.

Drei Engines und ein anderes Indexdesign

Jede Tabelle nutzt eine von drei Engines. Der Wechsel zwischen ihnen erfordert einen Aufruf von pinecone.set_engine() und keine Änderung an den Abfragen:

• native (Standard): die eigene Engine von pg_pinecone, die ihren Index vollständig innerhalb von Postgres aufbaut und durchsucht, ohne Pinecone-Konto, API-Schlüssel oder Netzwerkaufrufe.
• pgvector: durchsucht den HNSW-Index von pgvector.
• remote: leitet die Suche an einen Index im verwalteten Dienst von Pinecone weiter.

Statt eines Graphen gruppiert die native Engine ähnliche Vektoren mithilfe eines invertierten Dateiindex (IVF) in Cluster. Sie speichert von jedem Vektor eine quantisierte Kopie als RaBitQ-Code, etwa ein Bit pro Dimension plus einige Korrekturwerte. Eine Suche prüft die nächstgelegenen Cluster, schätzt die Abstände anhand der kompakten Codes, behält die besten Kandidaten und sortiert sie mit den vollständigen Vektoren aus der Tabelle des Nutzers neu.

Für 1 Million Vektoren mit 768 Dimensionen baut die native Engine nach Angaben von Pinecone einen Index von 136 MB auf. Bei HNSW auf halfvec sind es 2,0 GB, bei Vektoren in voller Größe 4,1 GB.

Filtern während der Suche und gemeldete Benchmarks

Pinecone erklärt, dass das HNSW von pgvector die WHERE-Klausel erst anwendet, nachdem die nächsten Nachbarn gefunden wurden. Bei einem engen Filter, etwa einem Mandanten von hundert, wird der Großteil der Kandidaten verworfen, und eine Abfrage kann weniger Zeilen zurückgeben als ihr LIMIT vorsieht. Die native Engine filtert dagegen während der Suche und wählt eine Strategie nach Selektivität. Bei einem engen Filter (standardmäßig höchstens 3 % der Zeilen) filtert sie vorab: Sie durchsucht jede passende Zeile in allen Clustern und bewertet jede mit ihrem vollständigen Vektor, sodass die Ergebnisse exakt sind. Bei einem weiteren Filter nutzt sie einstufiges Filtern, durchsucht mehr der nächstgelegenen Cluster, bis zur Hälfte, und prüft den Filter innerhalb jedes Clusters.

Das Unternehmen nennt folgende Ergebnisse aus eigenen Tests mit 1 Mio. Vektoren mit 768 Dimensionen (wiki_dpr) auf einer AWS r6id.4xlarge mit 16 vCPUs und 128 GB RAM:

• Bei einem Recall von 0,95 dauert eine Abfrage 1,3 ms, gegenüber 1,7 ms bei HNSW auf halfvec und 2,7 ms bei Vektoren in voller Größe.
• Bei einem Recall von 0,99 sind es 2,3 ms gegenüber 4,7 ms und 6,7 ms.
• Wenn 10 % der Zeilen passen, erreicht die native Engine einen Recall von 1,000 in 12,3 ms, während HNSW mit iterativen Scans bestenfalls einen Recall von 0,920 in 5,9 ms schafft.

Pinecone gibt außerdem an, dass der Index auf denselben Daten schneller aufgebaut wird als pgvector HNSW. Das vollständige Setup und die Befehle, um die Tests erneut auszuführen, stehen in der README eines Benchmark-Harness. Die Zahlen stammen vom Unternehmen selbst.

Neue Zeilen werden dem nächstgelegenen Cluster zugeordnet und sind sofort durchsuchbar. Da die Zentroide an der Stelle bleiben, an die der Aufbau sie gesetzt hat, rät Pinecone nach großen Änderungen, etwa einem Bulk-Load, der die Tabelle verdoppelt, REINDEX auszuführen oder die automatische Wartung zu aktivieren.

Optionale Skalierung und Funktionen mit Pinecone-API-Schlüssel

Die native Engine soll die Suche für viele Anwendungen abdecken. Mit einem Pinecone-API-Schlüssel bietet dieselbe Erweiterung optionale Zusätze. Für Wachstum über einen einzelnen Server hinaus verlagert die Remote-Engine die Suche mit SELECT pinecone.set_engine('docs', 'remote'); zu Pinecone. Embeddings werden im Hintergrund mit einem Pinecone-Index synchronisiert, und Suchen laufen weiter in Postgres, bis die Kopie fertig ist. Die Abfragen ändern sich nicht, Postgres bleibt die maßgebliche Datenquelle, und auf dieselbe Weise lässt sich wieder zu native zurückwechseln.

Für Tabellen, die Text, aber keine Embeddings enthalten, ruft eine embed()-Funktion den Inferenzdienst von Pinecone auf, sodass Nutzer weder ein Modell hosten noch den Schlüssel eines anderen Anbieters verwalten müssen. Laut Pinecone deckt das kostenlose Kontingent einen ersten Aufbau ab.

Was das für Postgres-Nutzer bedeutet

Für Teams, die Vektoren bereits in Postgres halten, bietet pg_pinecone laut Pinecone einen alternativen Index, ohne dass ein zweites System betrieben werden muss. Im Mittelpunkt stehen ein geringerer Speicherbedarf, schnellere Indexaufbauten und gefilterte Abfragen, die vollständige Ergebnismengen liefern, was für mandantenfähige Anwendungen wichtig ist. Weil die Erweiterung bestehende pgvector-Spalten und SQL weiterverwendet und den Wechsel zwischen Engines mit einem Aufruf erlaubt, kann die Einführung schrittweise erfolgen. Die Leistungsangaben stammen aus Benchmarks von Pinecone mit einem Datensatz und einem Hardware-Setup, bei anderen Workloads können die Ergebnisse abweichen.