Gemini Embedding 2 vereint fünf Modalitäten in einem einzigen Vektorraum

Ein Embedding-Raum statt fünf Pipelines

Der zentrale Anspruch dieses Releases ist architektonischer, nicht inkrementeller Natur. Gemini Embedding 2 bildet Text, Bilder, Video, Audio und Dokumente auf das ab, was Google einen einzigen, einheitlichen Embedding-Raum nennt. Das unterscheidet sich grundlegend davon, separate Encoder pro Modalität zusammenzuschalten und zu hoffen, dass ihre Vektoren zueinander passen.

Für Teams, die Retrieval-Systeme bauen, bedeutet das in der Praxis: Eine Anfrage in einer Modalität kann Inhalte in einer anderen abrufen, ohne einen Brückenschritt zu benötigen. Google beschreibt das als Vereinfachung komplexer Pipelines, und das trifft es ziemlich genau: weniger separate Modelle, die gehostet, versioniert und synchron gehalten werden müssen.

Gemini Embedding 2 bildet Text, Bilder, Videos, Audio und Dokumente auf einen einzigen, einheitlichen Embedding-Raum ab und erfasst semantische Absichten in über 100 Sprachen.Montana Labs

Die Abdeckung von mehr als 100 Sprachen wird zwar genannt, aber nicht weiter quantifiziert. Das sollte man als Fähigkeitsangabe verstehen, die man am eigenen Korpus prüfen muss, nicht als Benchmark-Ergebnis.

Die Input-Limits bestimmen, was Sie tatsächlich bauen können

Die Details sind wichtiger als die Schlagzeile. Text unterstützt bis zu 8192 Tokens. Bilder erlauben bis zu 6 pro Anfrage im PNG- oder JPEG-Format. Video akzeptiert bis zu 120 Sekunden in MP4 oder MOV. Dokumente können PDFs mit bis zu 6 Seiten sein. Das sind die Grenzen, um die Sie Ihr Design herum planen.

Eine Obergrenze von 120 Sekunden bei Video und ein Limit von 6 Seiten bei PDFs bedeuten, dass längere Medien vor dem Embedding zerteilt werden müssen. Diese Chunking-Strategie – wie man ein Video aufteilt, wie man ein langes Dokument fenstert – wird so zu einer technischen Entscheidung, die das Modell an Sie zurückgibt.

Das Detail zu Audio verändert Workflows am stärksten. Google gibt an, dass das Modell Audio nativ verarbeitet und einbettet, ohne zwischengeschaltete Texttranskriptionen zu benötigen. Der Wegfall des Speech-to-Text-Schritts beseitigt eine Fehler- und Latenzquelle, die die meisten Audio-Suchpipelines heute noch mitschleppen.

Verschachtelte Eingaben und Matryoshka-Dimensionen

Über die reine Einzelmodalitäts-Verarbeitung hinaus akzeptiert das Modell verschachtelte Eingaben – ein Bild plus Text in einer Anfrage – und kann so Beziehungen zwischen Medientypen erfassen, statt jeden isoliert einzubetten. Das ist der Unterschied zwischen der getrennten Indizierung eines Diagramms und seiner Beschriftung und der Einbettung beider als eine Sinneinheit.

Bei der Speicherung behält Gemini Embedding 2 das Matryoshka Representation Learning der früheren Textmodelle bei. Die Standardausgabe umfasst 3072 Dimensionen, Entwickler können auf 1536 oder 768 herunterskalieren, wobei Google genau diese drei Größen für höchste Qualität empfiehlt. Das gibt einen direkten Hebel, um Speicherkosten für Vektoren gegen Retrieval-Qualität abzuwägen, ohne irgendetwas neu trainieren zu müssen.

Verfügbar dort, wo Retrieval-Stacks bereits laufen

Das Modell ist als Public Preview über die Gemini API und Vertex AI verfügbar, mit interaktiven Colab-Notebooks für beide. Aufschlussreicher für die Akzeptanz ist die Liste der Integrationen: LangChain, LlamaIndex, Haystack, Weaviate, Qdrant, ChromaDB und Vector Search.

Das sind genau die Frameworks und Vektordatenbanken, auf denen die meisten RAG-Systeme bereits aufbauen. Teams dort abzuholen, wo sie mit ihren bestehenden Orchestrierungs- und Speicherwerkzeugen arbeiten, senkt die Einstiegshürde, ein neues Embedding-Modell gegen das bestehende Setup zu testen.

Was das Design mit einem einzigen Raum zum Umdenken zwingt

Die konkrete Implikation dieses Releases ist, dass Teams, die bisher separate Embedding-Pipelines pro Modalität pflegen, jetzt einen handfesten Grund zur Konsolidierung haben. Wenn Audio, Bilder, Video und Dokumente sich einen Vektorraum teilen können, wird cross-modales Retrieval vom Sonderprojekt zur einfachen Abfrage.

Was an Arbeit bleibt, ist wenig glamourös, aber real: die behauptete multimodale Qualität an den eigenen Daten überprüfen, Chunking-Strategien für Inhalte entwerfen, die die Grenzen von 120 Sekunden und 6 Seiten überschreiten, und eine MRL-Dimension wählen, die zum eigenen Speicherbudget passt. Es handelt sich um eine Public Preview – diese Entscheidungen sollten also validiert werden, bevor irgendetwas Kritisches davon abhängt.