Die Vektor-Suche in Googles BigQuery ist seit kurzer Zeit offiziell verfügbar (GA). Die Gelegenheit, um sich die Vektor-Suche und deren Möglichkeiten anzusehen.
Vektor kommt vom Lateinischen vector, was mit Träger oder Fahrer übersetzt werden kann. Es gibt Vektoren in verschiedenen mathematischen und physikalischen Teilgebieten. Vektoren der Geometrie sind dabei Vektoren der Physik sehr ähnlich, aber nicht identisch. Es werden aber bspw. auch (n-) Tupel teilweise als Vektoren bezeichnet. Ihnen allen ist gemeinsam, dass auf sie, die Vektoren, in einem Vektor- oder Tupelraum, die Addition und skalare Multiplikation (lineare Algebra) anwendbar ist. Daher werden sie als Vektoren bezeichnet. Physikalische und viele geometrische Vektoren haben eine Position und eine Richtung und werden daher häufig als Pfeil dargestellt. Sie repräsentieren dabei bspw. eine physikalische Grösse wie die Geschwindigkeit. Vektoren im Sinne von Tupeln sind weit generischer und können diverse Informationen repräsentieren. Während sich Vektoren der Geometrie und Physik oft in Räumen der 2. und 3. Dimension wohlfühlen, bilden "Tupel-Vektoren" vielfach multidimensionale Räume. Ihre bildliche Darstellung ist entsprechend anspruchsvoll.
Die Vektorrechnung (wie wir sie heute kennen) wurde 1844 vom deutschen Mathematiker Hermann Günther Grassmann begründet. Also 180 Jahre nach der Entdeckung von Vektoren steht in BigQuery eine Vektor basierte Suche zur Verfügung.
Vektor-Suche in BigQuery - eine Plattform mit Bausteinen
Der Begriff "Vektor-Suche" suggeriert vielleicht eine zu einfache Vorstellung. Es ist nicht so, dass man in BigQuery nun anstelle von LIKE "%komm%" einfach VECTOR "komm" eingibt und BigQuery dann eine textbasierte Vektor-Suche vornimmt. Vielmehr ist die Vektor-Suche in BigQuery eine Plattform, mit welcher man eine Vektor-Suche realisieren kann. Dabei besteht eine Vektor-Suche grob aus zwei Komponenten: Den Vektoren selber und dem Distanz-Algorithmus.
Es geht also, anders als bspw. bei geometrischen Vektoren üblich, nicht darum, diese im Raum zu verschieben, sondern die Distanz zwischen Vektoren zu berechnen. Dabei muss die Distanz zwischen den Vektoren deren semantische Ähnlichkeit wiedergeben, um für eine Suche im Kontext von BigQuery sinnvolle Ergebnisse zu liefern. Schliesslich möchte man mit der Suche ja ähnliche, semantisch gleiche, Texte, Bilder, Videos. etc. finden können.
2 Varianten in BigQuery: Mit und ohne Modell
Wie erwähnt ist die Vektor-Suche in BigQuery ein Baukasten. Die aus Sicht von BigQuery minimalste Variante ist, wenn Sie die Vektoren in einer Tabelle speichern und für die Abfrage wiederum direkt einen Vektor als Array<Float64> mitgeben. BigQuery berechnet dann mit dem konfigurierten Distanz-Algorithmus die gewünschten nächsten Kandidaten. Google hat den ersten Teil bspw. im öffentlichen Patent-Datensatz bereits gemacht. Dort gibt es eine neue Spalte "embeddings_v1":
 |
| Embeddings von Google im Patentdatensatz |
Zu den Embeddings kommen wir gleich noch. Damit BigQuery weiss, wie Sie die Distanz berechnen wollen, müssen Sie definieren, welchen Distanz-Algorithmus Sie zur Berechnung der Vektor-Distanz verwenden wollen. BigQuery bietet aktuell die folgenden Algorithmen an:
- Euklidischer Abstand
- Kosinus-Ähnlichkeit
- Skalarprodukt.
Sie können dazu noch weitere Parameter wie top_k (die Anzahl Nachbaren die man zurück bekommen möchte) definieren.
Für grosse Datenmengen lohnt es sich, die gespeicherten Vektoren zusätzlich zu indexieren. BigQuery bietet dafür spezielle Vektor-Indizes an. Dies erhöht die Abfrage-Performance erheblich.
Embeddings und die Modelle
Nun kommen wir zum etwas schwierigeren Teil. Wie erhalte ich den die Vektoren und wie kommt die Semmantik in diese Vektoren?
Bislang sind wir einfach davon ausgegangen, dass Sie die Vektoren in BigQuery gespeichert haben und bei einer Abfrage einen Vektor angeben. Stellt sich die Frage, wie erhalten Sie die Vektoren zum Speichern und welche Modelle stehen Ihnen zur Verfügung?
Google stellt Ihnen in BigQuery über 20 verschiedene Modelle zur Verfügung:
Darüber hinaus können Sie Remote-Modelle verwenden. Soweit ich aktuell gesehen habe, stehen Ihnen für die Remote-Modelle zurzeit Modelle von Vertex AI zur Verfügung. Sie definieren entsprechend in Vertex AI das gewünschte Modell, trainieren es falls notwendig und können es anschliessend direkt in BigQuery verwenden. Gerade mit Vertex AI haben Sie grundsätzlich zwei Optionen: Sie berechnen die Vektoren direkt selber in Vertex AI und speichern Sie anschliessend in BigQuery. Dazu müssen Sie etwas Programm-Code schreiben. Das ist die erwähnte, aus Sicht BigQuery, minimalste Variante. Oder Sie binden die Modelle in BigQuery via Remote-Modell ein und können dann das Modell direkt in BigQuery, mit dem BigQuery SQL-Dialekt verwenden.
Damit zurück zur Frage, was sind Embeddings und wie kommt die Semantik in den Vektor?
Es ist nicht so, dass bspw. durch die Platzierung von Wörtern oder Buchstaben als Zahlen in einem mehrdimensionalen Vektorraum automatisch eine semantische Suche gemacht werden kann. Vielmehr hilft die Vektorisierung von semantischen Informationen bei der Suche, in dem die Algorithmen der linearen Algebra angewendet werden können. Dabei kommt einem auch die Effizienz solche Algorithmen zu Gute. Es ist aber natürlich auch nicht so, dass durch die Platzierung von Wörtern oder Buchstaben als Zahlen in einem mehrdimensionalen Vektorraum automatisch eine semantische Ähnlichkeit zwischen den Vektoren entsteht, umso näher sie sich sind.
Bevor wir uns etwas anhand von Textinformationen anschauen, wie die Semantik zu Stande kommt, muss der Vollständigkeitshalber erwähnt werden, dass die Vektor-Suche nicht nur für Texte geeignet ist. Man kann damit ebenso Bilder, Audio- und Video-Dateien suchen. Der Weg, wie die Semantik in solchen Fällen in den Vektor kommt, ist dabei entsprechend anders als bei Texten. Das jeweils konkrete Verfahren hängt dabei vom Zweck ab. Wollen Sie ähnliche Musik finden, Anomalien in Geräuschen feststellen (bspw. für die Qualitätssicherung) oder eine Spracherkennung haben (nur Musik mit italienischen Texten). Nicht jede Methode ist für jeden Zweck gleich gut geeignet.
Ein Embedding ist vereinfacht gesagt die semantische Positionierung des Wortes oder Textes in einem definierten Vektorraum. Damit ist ein Embedding eigentlich nichts anderes, als ein spezifischer Vektor. Ein Vektor, welcher die Semantik (von Texten) abbildet. Für die Berechnung des Embedding gibt es verschiedene Methoden und Verfahren wie Word2Vec, GloVe oder FastText. Dazu kommen Transformer basierte Methoden. Ich habe in diesem Beitrag hier über Transformer geschrieben. Ich kann nur mutmassen, gehe aber davon aus, dass Google in der Embedding-Engine von Gemini eine Transformator basierte Lösung nutzt (Link). Aktuell bietet Google 6 verschiedene Embedding-Modelle an. 4 Englisch sprachige und 2 Mehrsprachige:
- textembedding-gecko-multilingual@001
- text-multilingual-embedding-002
Für die Vektor-Suche von Texten in BigQuery eigenen sich daher wahrscheinlich die Embeddings von Gemini am besten als Vektoren. Die Embeddings von Gemini können in BigQuery ebenfalls direkt als Remote-Modell verwendet werden.
Exkurs Array: Die Darstellung der Embeddings in BigQuery als Array<Float64> ist nichts anderes als die Matrix-Schreibweise/Darstellung von Vektoren.
Grenzen der Ähnlichkeit
Embeddings sind kumulativ nur so gut wie die Trainingsdaten und die passende Verwendung. Bspw. könnten im Kontext von Fahrzeugen und Flucht, die Namen
Bonnie & Clyde nahe beieinander liegen. Will man einfach wissen, ob Bonnie ähnlich ist zu Clyde, ist das natürlich wenig hilfreich. Nebenbei bemerkt sind Namen generell extrem schwierig für sinnvolle Embeddings, da sie entweder stark Kontextbezogen (es geht gerade um diesen Namen) sind oder gar nicht (der name ist also gar nicht relevant). Zudem kommen viele Namen nicht so häufig in Trainingsdaten vor. Ähnlichkeiten zwischen Namen mit Hilfe von Embeddings zu suchen dürfte daher keine genügend robuste Ergebnisse liefern. Dazu gibt es zum Glück spezielle Softwarelösungen (wie bspw. ESC). Für viele Texte eignen sich aber Embeddings sehr gut um die semantische Ähnlichkeit festzustellen.
Die BigQuery Vektor-Suche-Dokumentation von Google finden Sie u.a. hier.
Was bedeutet die Möglichkeit aus Sicht IT-Architektur?
Eine neue Such-Funktion ist schön, doch was bedeutet dies aus Sicht einer IT-Architektur? Sie können damit die Architektur vereinfachen. In dem Sie die Funktion direkt in BigQuery umsetzen können, brauchen Sie keine Indexierungspipelines, welche die Daten laden und vektorisieren. Und Sie brauchen keine eigene Abfrage-, resp. Such-Logik zu schreiben, welche Sie dann wiederum mit Daten von BigQuery anreichern müssen. Sie können es direkt mit einer Abfrage mache. Das reduziert die Anzahl Komponenten, Services und Systeme und vereinfacht so insgesamt ihre Architektur. Zudem können Sie bestehende SQL-/BigQuery-Know-how wiederverwenden.
Die Gefahr besteht dabei etwas, dass ihre Anwendung zu einem Monolithen wird. Versuchen Sie auch innerhalb von BigQuery zu modularisieren und arbeiten Sie auch bei Datenmodellen mit Schnittstellen um die Komplexität zu reduzieren. Schaffen Sie die Möglichkeit, den Rest der Applikation unabhängig von der Vektor-Suche weiter zu entwickeln und anzupassen. Und natürlich auch umgekehrt, dass Sie die Vektor-Suche unabhängig vom Rest evolutionär verbessern können.
Damit können Sie optimal von der integrierten Vektor-Suche profitieren.
Out of the box? Nein.
Ich wiederhole mich, die Vektor-Suche in BigQuery ist ein leistungsstarker Baukasten und keine fertige out of the box Funktion. Um eine leistungsstarke Vektor-Suche in BigQuery zu realisieren brauchen Sie Know-how im Bereich vom maschinellen Lernen. Sie müssen die verschiedenen Modelle und deren Parameter verstehen. Sie müssen in der Lage sein, die Ähnlichkeitssuche zwecks Evaluation und Qualitätssicherung in eine Klassifizierung zu überführen um etablierte Evaluations-Metriken wie F1 anwenden zu können. Dazu brauchen Sie entsprechende (klassifizierte) Testdaten. Die Vektor-Suche in BigQuery lohnt sich für Sie also nur, wenn Sie damit einen echten Business-Value erzeugen können. Google gibt Ihnen Rechenpower und einen Werkzeugkasten an die Hand. Um es nützlich in der eigenen Anwendung anzuwenden, müssen Sie selber Hand anlegen.
Keine Kommentare:
Kommentar veröffentlichen