Google hat mit EmbeddingGemma 2 ein offenes Embedding-Modell mit 740 Millionen Parametern vorgestellt. Embeddings sind numerische Repräsentationen von Inhalten: Ein Modell übersetzt Text, Bilder oder Code in lange Zahlenreihen, sogenannte Vektoren, deren Abstand zueinander die inhaltliche Ähnlichkeit abbildet. Genau darauf bauen semantische Suche und Empfehlungsfunktionen auf – also Suche, die nach Sinn statt nach exakter Zeichenkette arbeitet.

Das Besondere an der Ankündigung ist weniger der Funktionsumfang als der Ressourcenbedarf. Laut Google benötigt das Modell nur rund 191 MB Arbeitsspeicher und läuft direkt auf dem Endgerät. Zudem soll es in Vergleichsmessungen teilweise Modelle übertreffen, die doppelt so groß sind. Diese Angaben stammen vom Hersteller und sind entsprechend als Eigenangabe zu lesen.

Mehrere Datentypen in einem Vektorraum

EmbeddingGemma 2 verarbeitet nicht nur Text, sondern auch Bilder, Video, Audio und Code. Für Projekte heißt das: Unterschiedliche Inhaltstypen lassen sich über denselben Mechanismus durchsuchbar machen, ohne für jede Datenart eine eigene Pipeline aufzubauen.

Typische Einsatzfelder in Web- und CMS-Umgebungen sind:

  • semantische Suche über Redaktionsinhalte, die auch Synonyme und Umschreibungen findet
  • Ähnlichkeitsvorschläge für verwandte Artikel, Produkte oder Dokumente
  • Auffinden von Bildern und Mediendateien anhand beschreibender Eingaben
  • Zuordnung eingehender Anfragen zu bestehenden Wissensbeständen

Offline-RAG als eigentlicher Hebel

In Kombination mit Gemma 4 nennt Google Offline-RAG-Anwendungen mit Datenschutzfokus als Szenario. RAG steht für Retrieval Augmented Generation: Ein Sprachmodell beantwortet eine Frage nicht aus dem Gedächtnis, sondern bekommt zuvor passende Dokumentabschnitte aus einer eigenen Wissensbasis zugespielt. Das Embedding-Modell übernimmt dabei den Suchteil, das Sprachmodell die Formulierung der Antwort.

Bislang wandert bei solchen Aufbauten regelmäßig Inhalt in externe Dienste – entweder beim Erzeugen der Vektoren oder bei der Antwortgenerierung. Wenn beide Schritte lokal laufen können, entfällt dieser Abfluss. Für Organisationen mit internen Handbüchern, Verträgen, Personaldaten oder Kundendokumenten verändert das die Ausgangslage bei der Bewertung nach Datenschutzrecht spürbar, weil keine Auftragsverarbeitung mit einem Cloud-Anbieter für diese Verarbeitungsschritte nötig wird.

Kostenseite und Betrieb

Embedding-Aufrufe sind in Cloud-Szenarien ein laufender Posten. Sie fallen nicht nur einmal beim Indexieren an, sondern bei jeder Änderung an Inhalten und bei jeder Suchanfrage. Ein Modell, das sich auf gewöhnlicher Hardware betreiben lässt, verschiebt diese variablen Kosten in planbare Infrastruktur.

Gleichzeitig entsteht Betriebsaufwand an anderer Stelle. Das Modell muss bereitgestellt, versioniert und überwacht werden. Ein Wechsel der Modellversion zieht in der Regel eine Neuberechnung aller gespeicherten Vektoren nach sich, weil Vektoren verschiedener Modelle nicht miteinander vergleichbar sind. Wer eine Vektordatenbank einführt, sollte diesen Reindexierungsfall von Anfang an einplanen.

Einordnung für TYPO3- und Webprojekte

Für CMS-Projekte ist die Architektur überschaubar: Beim Speichern eines Inhalts werden Textabschnitte an das Modell gegeben, die resultierenden Vektoren landen in einem Index. Eine Suchanfrage wird auf demselben Weg in einen Vektor übersetzt und mit dem Index abgeglichen. Die Trefferliste kann direkt ausgegeben oder als Kontext an ein Sprachmodell weitergereicht werden.

Praktisch sinnvoll ist ein schrittweises Vorgehen:

  1. Einen klar umrissenen Anwendungsfall wählen, etwa die interne Dokumentensuche.
  2. Die Datenbasis aufräumen – unstrukturierte oder veraltete Inhalte liefern auch mit gutem Modell schwache Ergebnisse.
  3. Eine Testmenge realer Suchanfragen mit erwarteten Treffern aufbauen, um Qualität messbar zu machen.
  4. Erst danach über eine generative Antwortschicht nachdenken.

Wichtig bleibt die Erwartungssteuerung. Ein kompaktes Modell ersetzt keine redaktionelle Strukturierung, und Benchmark-Werte sagen wenig über die Trefferqualität in einer konkreten Fachdomäne aus. Ob die Ergebnisse tragen, zeigt sich erst an den eigenen Inhalten und am eigenen Vokabular.

Was daraus folgt

Die Entwicklung hin zu kleinen, lokal lauffähigen Modellen senkt die Einstiegshürde für KI-Funktionen in Web- und Softwareprojekten deutlich: Datenschutzbedenken und laufende API-Kosten waren bisher die beiden häufigsten Gründe, solche Features zu verschieben. Für Projekte mit sensiblen Inhalten lohnt es sich daher, Suche und Wissenszugriff jetzt als eigene Komponente zu planen, statt sie fest an einen Cloud-Dienst zu binden. Entscheidend bleibt der Aufwand für Betrieb, Indexpflege und Qualitätssicherung – dieser verschwindet nicht, sondern verlagert sich ins eigene Haus.

Quellen