Google hat für BigQuery drei Suchfunktionen vorgestellt, die einem Gedanken folgen: Die Bedeutung eines Textes soll dort erschlossen werden, wo der Text liegt. Lange war das anders. Wer PDFs, Audiodateien oder Bilder auswerten wollte, baute eine zweite Welt daneben – einen Vector Store hier, eine LLM-Pipeline dort, dazu Skripte, die beide Seiten halbwegs synchron hielten. Google nennt diesen Zustand in der Ankündigung eine fragmentierte Architektur.
Die Ankündigung stammt aus dem Google-Cloud-Blog, geschrieben von Produktmanager Joe Malone und Engineering Manager Francis Lan, und erschien bereits am 8. August. Alle Leistungsangaben darin sind Herstellerangaben.
Der Ausgangspunkt ist ein Ungleichgewicht, das viele Unternehmen kennen. Strukturierte Daten in Tabellen lassen sich mit SQL sauber abfragen. Unstrukturierte Daten sammeln sich in Ablagen und wachsen schneller, als man sie erschließen kann. BigQuery will diese Trennung auflösen und Bedeutung, Suche und Auswertung im selben System zusammenführen. Wer verstehen will, was KI dabei leistet, sollte nicht mit den Modellen anfangen, sondern mit der Frage, wo die Daten liegen und wie man sie wiederfindet.
Die Bibliothek als Bild: warum zwei Suchwege nötig sind
Man kann sich das als Bibliothek vorstellen. Der eine Weg führt über den Zettelkasten: Man schlägt unter einem Stichwort nach und bekommt genau die Bücher, in denen dieses Wort steht. Der andere Weg führt über die Auskunft am Eingang: Man beschreibt, was man wissen möchte, und bekommt Bücher, in denen das gesuchte Wort gar nicht vorkommt, die aber inhaltlich passen. Beide Wege haben Stärken und blinde Flecken.
Die klassische Schlüsselsuche – in der Fachsprache lexikalische Suche – ist präzise und billig, aber sie ist wörtlich. Wer nach Behandlungen für fortgeschrittene Tumoren fragt, findet keine Dokumente, in denen nur von Chemotherapie die Rede ist. Die semantische Suche, also die Suche über Vektoren, versteht Bedeutungszusammenhänge und findet genau solche Dokumente. Dafür verliert sie die Genauigkeit bei Zeichenfolgen, die keine Bedeutung tragen – Bestellnummern, Produktcodes, Wirkstoffkürzel.
BigQuery setzt beide Wege nebeneinander und nennt das Hybrid Search. Für echte Unternehmensdaten ist das keine Spielerei, sondern notwendig. Reale Bestände enthalten immer beides: Prosa und Codes, Beschreibungen und Kennungen. Wer nur einen Weg anbietet, lässt regelmäßig die Treffer liegen, auf die es ankommt.
Embeddings, die sich von selbst aktualisieren
Damit semantische Suche funktioniert, braucht es Embeddings – Zahlenreihen, die den Inhalt eines Textes als Punkt in einem hochdimensionalen Raum abbilden. Ähnliche Inhalte liegen nahe beieinander, unähnliche weit auseinander. So findet eine Suche nach Behandlungen für fortgeschrittene Tumoren auch Dokumente über Chemotherapie – genau das Beispiel, das Google zeigt. Bisher musste man diese Embeddings selbst berechnen lassen, in einer eigenen Pipeline, mit Wiederholungsversuchen, Fehlerprotokollen und einer Warteschlange, die bei jedem neuen Datensatz anspringt.
Die nun allgemein verfügbare Funktion Autonomous Embedding Generation nimmt diesen Teil ab. Man definiert im Schema eine Spalte, und BigQuery erzeugt die Embeddings asynchron und fortlaufend, sobald neue Daten eintreffen. Die Modellwahl bleibt offen: entweder ein externes Modell wie die Text-Embeddings von Vertex AI oder ein Gemma-Modell direkt in BigQuery. Ändert sich der Quelltext, werden die Embeddings automatisch nachgezogen.
Ein Detail am Rand: Die Funktion unterstützt inzwischen auch Bilder, die über Objektverweise eingebunden sind. Damit wird multimodale Suche möglich, also die Suche über Text und Bild in einem Abfrageweg. Das klingt nach einem Zusatz, ist aber der Bruch mit der alten Architektur. Wer Bildinhalte durchsuchen wollte, brauchte bisher ein separates System mit eigener Indexierung.
AI.SEARCH: suchen in normaler Sprache
Auf den Embeddings sitzt die zweite Neuerung. AI.SEARCH erlaubt Suche in natürlicher Sprache, ohne dass man im Suchpfad selbst Embeddings erzeugen muss. Wer eine Suchanfrage stellt, will keine Vektorrechnung anstoßen, sondern ein Ergebnis sehen.
Google hat nach eigener Angabe die Ausführung einzelner Abfragen stark optimiert, wie sie vor allem in Online-Anwendungen und bei Agenten vorkommen, und berichtet dort von einer bis zu 133-fach besseren Slot-Effizienz. Slots sind die virtuellen Recheneinheiten, die BigQuery Abfragen zuteilt. Das ist ein Höchstwert des Herstellers, kein Durchschnitt. Er zeigt aber die Richtung: Der Ressourcenbedarf pro Suche sinkt, und davon hängt ab, ob sich viele gleichzeitige Suchanfragen von Nutzern direkt aus BigQuery bedienen lassen.
Dieselbe Modellkonfiguration wird verwendet, die schon für die Embeddings im Datensatz zuständig war. Das ist unspektakulär, aber wichtig. Ein häufiger Fehler in solchen Aufbauten: beim Indexieren ein anderes Modell nutzen als beim Suchen. Die Vektoren liegen dann in unterschiedlichen Räumen, und die Ergebnisse sind still falsch. Man merkt es nicht an einer Fehlermeldung, sondern daran, dass die Suche schlecht trifft.
Hybrid Search: wenn der Wirkstoffname kein Bedeutungsumfeld hat
Das eingängigste Beispiel in der Ankündigung ist ein Wirkstoffkürzel wie „MK3475“. Eine reine Vektorsuche tut sich damit schwer, weil eine solche Zeichenfolge kaum semantischen Gehalt besitzt. Sie ist ein Etikett, kein Begriff. Ein Forscher, der genau dieses Kürzel sucht, will keinen thematisch verwandten Treffer, sondern diesen einen. Hier greift Hybrid Search ein und kombiniert die lexikalische Übereinstimmung mit der semantischen Nähe.
Technisch geschieht das über Verfahren wie Reciprocal Rank Fusion und BM25 – zwei etablierte Algorithmen aus dem Information Retrieval, die Ranglisten zusammenführen und Worthäufigkeiten gewichten. Man muss sie nicht selbst implementieren. Es hilft aber zu wissen, dass hier keine neue Zauberei am Werk ist, sondern jahrzehntealte Suchtechnik, neu verdrahtet. In der Praxis aktiviert man den Hybridmodus in den Funktionen AI.SEARCH und VECTOR_SEARCH über den Parameter mode => ‚HYBRID‘ oder lexical_search_columns. Für mehr Tempo lassen sich die Vektorindizes um die Schlüsselwortspalten erweitern.
Ein zweiter Effekt, den Google hervorhebt: Durch das Neusortieren der Treffer nach Schlüsselwort und Bedeutung sinkt die Zahl der Fehlinformationen, die ein Sprachmodell später verarbeitet. Man nennt das Halluzinationen, und ihre Kosten sind nicht nur inhaltlicher Natur. Jeder unnötige Dokumentkontext, der in ein Modell fließt, verbraucht Rechenzeit und Geld. Gute Suche ist damit auch eine Kostenmaßnahme.
Der komplette Weg von der PDF-Datei bis zur Antwort
Die drei Neuerungen sind Teil eines größeren Ablaufs, den Google in fünf Schritten beschreibt: Access, Process, Ground, Relate, Activate. Im ersten Schritt werden PDFs und Dokumente direkt dort abgefragt, wo sie liegen – über Objekttabellen in Google Cloud Storage, ohne vorherige Kopie. Im zweiten Schritt kommen Funktionen zum Einsatz, die Dokumente layoutgerecht zerlegen (die Funktion dafür ist erst angekündigt), Entitäten extrahieren, zusammenfassen und klassifizieren. Das geschieht innerhalb der SQL-Pipeline, nicht in einem separaten Werkzeug.
Der dritte Schritt – Ground – ist der, um den sich die drei Ankündigungen drehen: Embeddings und Hybridsuche erzeugen den inhaltlich belastbaren Kontext, auf dem ein Sprachmodell sinnvoll arbeiten kann. Im vierten Schritt werden extrahierte Entitäten wie Studien, Sponsoren und Medikamente in einen Graphen überführt, um verborgene Zusammenhänge sichtbar zu machen, ohne eine spezialisierte Graphdatenbank zu betreiben. Der fünfte Schritt bringt alles in eine dialogfähige Oberfläche, in der man mit den Daten spricht und Auswertungen erzeugen lässt.
Für Einsteiger ist vor allem die Reihenfolge lehrreich. Viele beginnen mit dem Modell und wundern sich, dass die Antworten unzuverlässig sind. Der Hebel liegt weiter vorn: Welche Daten sind zugänglich, und wie präzise findet man sie wieder? Das ist weniger spektakulär als ein neues Sprachmodell, entscheidet aber über das Ergebnis.
Was das konkret bedeutet – und wo die Grenzen liegen
Google wirbt damit, dass BigQuery komplexe Vektordatenbanken von Drittanbietern überflüssig mache. So pauschal stimmt das nicht, spezialisierte Vektorsuche hat weiterhin ihren Platz. Aber ein Teil der typischen KI-Anwendungen kommt ohne eigene Vektordatenbank aus, wenn das Data Warehouse die Aufgabe übernimmt. Für Unternehmen bedeutet das weniger bewegliche Teile: keine zweite Kopie der Daten, keine Synchronisationslogik, kein eigener Dienst, der nachts ausfällt. Weniger Architektur ist fast immer ein Vorteil, weil jede zusätzliche Komponente betrieben, überwacht und bezahlt werden muss.
Zugleich sollte man die Reifegrade auseinanderhalten. Embedding-Erzeugung und AI.SEARCH sind allgemein verfügbar, Hybrid Search ist in öffentlicher Vorschau. Wer darauf produktiv aufsetzen will, sollte Schnittstellen und Verhalten beobachten, denn in Vorschaufunktionen ändern sich Details noch. Und keine Technik ersetzt eine durchdachte Datenvorbereitung: Wie man Dokumente zerlegt, welche Spalten man indexiert, welche Metadaten man mitführt – diese Entscheidungen wirken stärker auf die Trefferqualität als die Wahl des Modells.
Eine Grenze verschiebt sich, die lange selbstverständlich schien. Unstrukturierte Daten waren der Sonderfall, den man irgendwie daneben verwaltete; jetzt werden sie ein normaler Teil der Abfragesprache. Wer KI-Anwendungen baut, wird künftig häufiger über Indexierung, Zerlegung und Trefferlisten sprechen als über Modellparameter. Weniger spektakulär, aber hier entscheidet sich, ob die Suche funktioniert.
Quelle: cloud.google.com
