Pinecone integriert Embedding in die Documents API: Nutzer senden nur noch Text

Was sich für Entwickler ändert

Über weite Strecken der Firmengeschichte von Pinecone mussten Nutzer sowohl ihre Daten als auch jede Suchanfrage mit einer eigenen Embedding-Pipeline selbst in Vektoren umwandeln. Mit der Records API holte Pinecone das Embedding 2024 erstmals in die Datenbank. Denselben Ansatz bietet das Unternehmen nun in der Documents API an, die zudem Volltextsuche unterstützt.

Laut Pinecone müssen Teams keinen Embedding-Anbieter mehr prüfen und keine Pipeline mehr bauen und pflegen, die einen solchen Anbieter aufruft. Bisher musste ein Plattformteam diese Pipeline sowohl auf dem Schreib- als auch auf dem Abfrageweg betreuen, samt eigener Schlüssel, Ratenlimits, Wiederholungsversuche und Überwachung. Beim integrierten Embedding laufen die Modelle stattdessen innerhalb von Pinecone.

Pinecone zufolge werden Dokumente und Anfragen mit demselben Modell eingebettet, sodass eine Anfrage nie mit Vektoren verglichen wird, die ein anderes Modell erzeugt hat. Ändert sich ein Dokument, bettet Pinecone den neuen Text im selben Schreibvorgang ein. Semantische Suche und Volltextsuche spiegeln die Änderung wider, ohne dass ein Re-Embedding-Job geplant oder überwacht werden muss.

Modelle und Einrichtung

Zum Start stehen drei Embedding-Modelle zur Verfügung:

• llama-text-embed-v2 ist der Standard für die semantische Suche und verarbeitet lange Textpassagen in 26 Sprachen.
• multilingual-e5-large ist eine Alternative für mehrsprachige Texte.
• pinecone-sparse-english-v0 ergänzt ein Matching nach Art der Schlüsselwortsuche, das lernt, welche Wörter in einer Passage am wichtigsten sind.

Entwickler weisen im Index-Schema einem Textfeld ein Embedding-Modell zu, direkt neben der Volltextsuche-Einstellung dieses Felds. Pinecone verwendet es dann für jedes Dokument und jede Anfrage auf diesem Feld. Nutzer können außerdem jede vom Modell unterstützte Dimension wählen. Um auf demselben Feld eine Sparse-Suche zu ergänzen, fügen sie eine sparse_embed-Einstellung mit pinecone-sparse-english-v0 hinzu. Die Indexbeschreibung zeigt Modell, Dimension und Metrik an, die jedes Feld verwendet.

Die Anwendung wählt für jede Anfrage die Suchmethode, lexikalisch oder semantisch, über dieselbe API und dasselbe Feld.

Wie Pinecone zu diesem Punkt kam

In einem Engineering-Beitrag beschreibt Silas Smith den Weg zu dieser Veröffentlichung. In der ursprünglichen Vectors API mussten Nutzer einen Embedding-Anbieter eines Drittanbieters anbinden und die Integration oft doppelt bauen, einmal für Schreibvorgänge und einmal für Abfragen. Zudem mussten sie entscheiden, wo der Quelltext liegt, entweder in einem separaten Datenspeicher oder in einem Metadatenfeld, was Speicher- und Schreibkosten erhöht.

Die Grundlagen legte Pinecone 2024 und 2025. 2024 begann das Unternehmen, Modelle selbst zu hosten, und ergänzte eigenständige Embed- und Rerank-Endpunkte. Anfang 2025 lieferte es die Slab-Architektur für Serverless-Indizes aus, die laut Smith die Indexauswahl auch für andere Indexarten als Vektoren modular machte. Die Volltextsuche wurde später eine davon.

Die Records API, Ende 2024 gestartet, bewies das Muster, Text anzuliefern und das Embedding in Pinecone erledigen zu lassen. Smith schreibt, sie sei letztlich verfrüht gewesen. Sie ummantelt die Vectors API, der Text liegt weiterhin in einem Metadatenfeld, und jeder Index war an ein Modell und ein Textfeld gebunden. Für native Volltextsuche gab es zudem keinen Spielraum.

Ende November 2025 traf sich das Engineering-Team in New York City und einigte sich auf drei Bausteine: native Volltextsuche in der Slab-Architektur, eine flexible Schemasprache sowie eine Document API und eine Search API als Grundlage. Dokumentindizes unterstützen ein benutzerdefiniertes Schema mit typisierten Feldern. In der ersten Version waren das String-Felder für die Volltextsuche, Dense- und Sparse-Vektorfelder sowie Metadaten zum Filtern. Laut Smith speichert ein Volltextfeld den Rohtext einmal im Slab und baut daneben einen invertierten Tantivy-Index auf, die Ergebnisse werden mit BM25 bewertet.

Was das für Teams bedeutet

Die Änderung richtet sich vor allem an Teams, die semantische Suche ohne einen separaten Embedding-Stack betreiben wollen. Plattformteams müssen nur noch einen Anbieter betreuen statt je Anwendung einen neuen Anbieter samt Pipeline, und eine Rechnung deckt Embedding und Suche ab. Anwendungsteams können auf einem einzigen Feld zwischen Schlüsselwort- und semantischer Suche wechseln. Pineones erklärtes Ziel ist es, mit Smiths Worten, dass Nutzer mehr Zeit in ihre Anwendung und weniger in den Aufbau von Retrieval-Pipelines stecken.