EmbeddingGemma 2: ein lokaler Suchprototyp für Text und Medien

Google veröffentlichte EmbeddingGemma 2 am 6. Oktober 2026 und stellt die Gewichte unter Apache 2.0 zum Download bereit. Das Modell wandelt Text, Code, Bilder, Videos und Audio in Vektoren um, die sich in einem gemeinsamen Raum mit 768 Dimensionen vergleichen lassen. Für Entwickler mit einer lokalen Sammlung stellen sich praktische Fragen: Welche Encoder sollen geladen werden, wie werden Abfragen und Dateien dargestellt, und sind die Treffer für diese Sammlung nützlich? Dieser Leitfaden folgt den veröffentlichten Anweisungen und der Modellkarte von Google; BIG CHANGE hat das Modell weder ausgeführt noch die Retrieval-Qualität gemessen.

Die große Veränderung

• Was sich geändert hat:Das frühere EmbeddingGemma-Modell verarbeitete Text. Version 2 ergänzt Vision- und Audio-Encoder, sodass sich eine Textabfrage ohne vorherige Bildbeschreibung oder Transkription mit unterstützten Medien im gemeinsamen Vektorraum vergleichen lässt. Google hat die Gewichte veröffentlicht; der ML-Kit-Dienst für Android soll in den kommenden Wochen verfügbar werden.
• Warum das wichtig ist:Entwickler können die für eine lokale Sammlung benötigten Encoder laden und einen gemeinsamen Retrieval-Index für die unterstützten Dateitypen erstellen. Googles AI Edge Galleryzeigt lokale Medienvektoren in SQLite mit einer Rangfolge nach Kosinusähnlichkeit. Eine Anwendung benötigt weiterhin Dateierfassung, Vektorspeicherung, Ergebnisanzeige und Prüfungen auf irreführende Treffer.
• Worauf zu achten ist:Die unmittelbare Frage lautet, ob repräsentative Dateien innerhalb des Speicher- und Latenzbudgets eines Geräts gut sortiert werden. Der spätere Android-Dienst könnte den Integrationsweg ändern; der angekündigte Zeitplan bedeutet nicht, dass er bereits verfügbar ist.

Wählen Sie die Eingaben, bevor Sie das Modell laden

Der Entwicklerleitfaden dokumentiert Sentence Transformers 6.1.0 oder höher sowie diesen Installationsbefehl für alle unterstützten Medien:

pip install -U sentence-transformers[image,audio,video] transformers

Der genaue Checkpoint ist google/embeddinggemma-2. Beim Laden mit den Standardeinstellungen von Sentence Transformers werden alle Encoder einbezogen. Für eine Sammlung aus Text und Code empfiehlt der Leitfaden, Vision und Audio beim Laden wegzulassen:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"vision_config": None, "audio_config": None},
)

Um Vision beizubehalten und Audio wegzulassen, ist config_kwargs={"audio_config": None} erforderlich; um Audio beizubehalten und Vision wegzulassen, config_kwargs={"vision_config": None}. Diese Optionen ändern die geladenen Gewichte, die resultierenden Vektoren bleiben jedoch im gemeinsamen Modellraum. Laut Leitfaden kann daher eine reine Textabfrage mit einem Bild verglichen werden, das mit einer Konfiguration einschließlich Vision kodiert wurde. Google beschreibt das Modell als für Verbrauchergeräte geeignet; das veröffentlichte Python-Beispiel ist jedoch ein Bibliotheks-Quickstart und keine gemessene Garantie für Speicherbedarf oder Latenz auf dem Gerät der Lesenden.

Abfragen und Sammlungselemente unterschiedlich kodieren

Für Text-Retrieval legt die Modellkarte getrennte Aufgabenanweisungen für Abfragen und Korpuselemente fest. Sentence Transformers übergibt sie mit prompt_name:

query_vector = model.encode("northern lights", prompt_name="SearchQuery")
document_vector = model.encode(
    "Charged particles from the sun cause the northern lights.",
    prompt_name="Document",
)
score = model.similarity(query_vector, document_vector)

Dieses dokumentierte Snippet erzeugt Vektoren und einen Ähnlichkeitswert; es ist kein in unserer Umgebung beobachtetes Ergebnis. Document fügt title: none ein. Hat ein Element einen tatsächlichen Titel, sollen Entwickler ihn laut Google ausdrücklich als title: {title} | text: {content} formatieren. Die Codesuche nutzt die Abfrageanweisung CodeRetrieval und einen Titel oder Dateinamen des indexierten Codes. Klassifizierung, Clustering und Satzähnlichkeit verwenden jeweils eigene symmetrische Anweisungen. Laut Modellkarte läuft das Modell auch ohne Textanweisungen, allerdings mit geringerer Präzision.

Das frühere model hat keinen Vision- oder Audio-Encoder. Laden Sie vor der Bildkodierung aus demselben Checkpoint die Text-und-Vision-Konfiguration des Leitfadens und verwenden Sie dieses Modell für Medium und Abfrage. Dieser Ablauf folgt der Dokumentation; wir haben ihn nicht ausgeführt:

media_model = SentenceTransformer(
    "google/embeddinggemma-2",
    config_kwargs={"audio_config": None},
)
image_vector = media_model.encode({"image": "photo.jpg"})
query_vector = media_model.encode("a photo query", prompt_name="SearchQuery")
score = media_model.similarity(query_vector, image_vector)

Für Audio laden Sie erneut und lassen audio_config: None weg, damit der Audio-Encoder aktiviert wird; beim vollständigen Standardladen sind Vision und Audio enthalten. Der Google-Leitfaden übergibt ein Dictionary wie {"audio": "recording.wav"} ohne Textaufgaben-Präfix. Text und Medien lassen sich auch kombinieren: Fügen Sie die Marker <|image|>, <|video|> oder <|audio|> in den Text ein und übergeben Sie die passenden Dateien im Dictionary. Dieser Aufruf erzeugt einen Vektor für die kombinierte Eingabe. Die Modellkarte legt Mono-Audio mit 16 kHz fest und nennt für Video standardmäßig eine Abtastrate von einem Bild pro Sekunde. Bilder, Videoframes, Audio und Text teilen sich ein Kontextbudget von 8.192 Tokens. Lange Clips oder gemischte Elemente erfordern daher eine Planung der Eingaben, statt anzunehmen, dass jede Datei hineinpasst.

Wählen Sie eine Vektorgröße und prüfen Sie den Kompromiss

Die native Ausgabe hat 768 Dimensionen. Laut Googles Modellkarte werden durch Abschneiden des Vektors auch 512, 256 und 128 Dimensionen unterstützt. Der Leitfaden dokumentiert truncate_dim=256 mit normalize_embeddings=True in model.encode(). Abfrage- und Indexvektoren müssen dieselbe Dimension haben; gekürzte Vektoren müssen vor dem Kosinusvergleich normalisiert werden. Laut Modellkarte geht bei 128 Dimensionen deutlich mehr multimodale Qualität verloren als bei 256; 128 wird vor allem für Text-Workloads empfohlen. Diese Werte stammen aus Googles Benchmarks mit voller Genauigkeit und sagen den Recall einer bestimmten Sammlung nicht voraus.

Auch die numerische Genauigkeit ist eine Einrichtungsentscheidung. Die Modellkarte empfiehlt bfloat16 auf unterstützter Hardware und andernorts float32 , auch auf den meisten CPUs. Sie warnt, dass float16 NaNs erzeugen oder Embeddings unbemerkt verschlechtern kann. Die Parameterzahlen für selektives Laden beschreiben Modellkomponenten; tatsächlicher Speicherbedarf und Suchtempo hängen von Ausführungspfad, Genauigkeit, Index und Eingabegröße ab.

Was vor der Nutzung der Ergebnisse geprüft werden sollte

Ein Prototyp kann eine kleine zulässige Stichprobe indexieren, repräsentative Abfragen zurückhalten und prüfen, ob die richtigen Elemente weit oben erscheinen. Text-zu-Text-, Text-zu-Bild- oder Text-zu-Audio-Fälle sollten nur aufgenommen werden, wenn die Sammlung diese Medien tatsächlich enthält. Vergleichen Sie 768 und 256 Dimensionen mit denselben Abfragen, prüfen Sie Fehler bei relevanten Sprachen und Dokumenttypen und messen Sie Speicher, Indexierungszeit und Abfragelatenz auf dem vorgesehenen Gerät. Das sind Evaluierungsschritte für Lesende; BIG CHANGE hat sie nicht durchgeführt.

Die in der Modellkarte veröffentlichten Ergebnisse weisen EmbeddingGemma 2 bei MTEB code v1 mit 78,68 gegenüber 68,76 für das Vorgängermodell aus; bei multilingual MTEB v2 sind es 61,36 gegenüber 61,15. Die Karte nennt auch Bild-, Video- und Audioergebnisse, für diese Modalitäten jedoch keinen Vergleich mit Version 1. Alle zitierten Benchmark-Ergebnisse verwenden den Checkpoint mit voller Genauigkeit. Sie beschreiben Googles Evaluierungsbedingungen, nicht die Genauigkeit in einem lokalen Archiv. Die Karte weist darauf hin, dass die Qualität je nach Sprache und Aufgabe variieren kann und Retrieval-Anwendungen eigene Filter- und Fairnessprüfungen benötigen.

Die Gewichte stehen unter Apache 2.0; der Leitfaden verlinkt auf das Hugging-Face-Repository. Googles Materialien beschreiben einen lokalen Ausführungsweg, nennen aber keinen allgemeingültigen Bereitstellungspreis: Gerät, Rechenleistung, Speicher und Engineering sind Anwendungskosten. Als Nächstes sollten Lesende prüfen, ob das Modell repräsentative Dateien innerhalb des Gerätebudgets korrekt sortiert.

Quellen und weiterführende Informationen

• Ankündigung von Google AI Edge, 6. Oktober 2026: Veröffentlichungsphase, lokale Mediensuche in AI Edge Gallery und angekündigter Zeitplan für ML Kit. Die Gerätemessungen in diesem Beitrag stammen von Google.
• EmbeddingGemma-2-Entwicklerleitfaden, 6. Oktober 2026: Bibliotheksversion, Ladeoptionen, Kodierungsbeispiele und Anweisungen zum Kürzen von Vektoren.
• Modellkarte zu EmbeddingGemma 2: Modellarchitektur, Eingabegrenzen, Aufgaben-Prompts, Genauigkeitswarnung, Benchmarktabellen und Einschränkungen. Die Ergebnisse stammen von Google.
• Google-Modell-Repository: der genannte Checkpoint und die veröffentlichten Modelldateien. Die Verfügbarkeit des Repositorys bestätigt nicht die Leistung in einer Anwendung.