1 Punkte von GN⁺ 2024-01-13 | 1 Kommentare | Auf WhatsApp teilen
  • Da AI-Anwendungen mit unstrukturierten, hochdimensionalen Daten arbeiten, werden Vektordatenbanken als spezialisierte Systeme zum Speichern und Abrufen von Daten in Form numerischer Arrays immer wichtiger
  • Im Kern geht es darum, Datensätze nicht über Zeilen, Spalten oder explizite Beziehungen zu verknüpfen, sondern anhand der Ähnlichkeit zwischen Dateneigenschaften und so implizite Bedeutung zu nutzen
  • Wenn semantische Beziehungen als multidimensionale Vektoren codiert werden, lassen sich Analyseaufgaben wie Ähnlichkeitssuche, Clustering und Klassifizierung schneller durchführen
  • In generativer AI werden sie eingesetzt, um große Mengen hochdimensionaler Daten zu verwalten und über die Suche nach ähnlichen Vektoren die Geschwindigkeit von Training und Inferenz sowie personalisierte Ergebnisse zu verbessern
  • Fortgeschrittenes Indexing reduziert den Suchraum auf relevante Teilmengen, senkt so die Suchzeit und ermöglicht komplexe Abfragen, die Ähnlichkeit mit anderen Bedingungen kombinieren

Welche Datenformen Vektordatenbanken verarbeiten

  • Vektordatenbanken sind spezialisierte Datenbanken zum Speichern, Verwalten und Verarbeiten von Vektoren als hochdimensionale Datenrepräsentationen
  • Anders als traditionelle Datenbanken, die Daten in Zeilen und Spalten speichern, legen Vektordatenbanken Daten als Vektoren in einem multidimensionalen Raum ab
  • Jeder Vektor ist ein numerisches Array, das Merkmale oder Eigenschaften eines Datenpunkts repräsentiert

Verknüpfungen auf Basis von Bedeutung und Ähnlichkeit

  • Traditionelle Datenbanken stellen Beziehungen zwischen Elementen auf Basis expliziter Links oder Hierarchien her
  • Vektordatenbanken verknüpfen Datensätze algorithmisch anhand der Ähnlichkeit von Dateneigenschaften
  • Dieser Ansatz kann intuitivere Verbindungen auf Grundlage der impliziten Bedeutung innerhalb der Datenbankelemente herstellen

Struktur für analytische Abfragen

  • Wenn Daten als multidimensionale Vektoren, also numerische Arrays, codiert werden, die semantische Beziehungen abbilden, lassen sich fortgeschrittene Analyseaufgaben schnell ausführen
  • Zu den unterstützten Aufgaben gehören Ähnlichkeitssuche, Clustering und Klassifizierung
  • Das Rechenmodell eignet sich für Mustererkennung, prädiktive Analysen und Anwendungen mit hohen Analyseanforderungen

Einsatz in AI und generativer AI

  • Die Verbreitung von AI und Machine Learning ist ein wichtiger Grund für die steigende Nachfrage nach Vektordatenbanken
  • Im Bereich generativer AI sind Vektordatenbanken darauf ausgelegt, große Mengen hochdimensionaler Daten effizient zu speichern und zu verwalten
  • Da ähnliche Vektoren schnell gesucht und Ergebnisse abgerufen werden können, lassen sich die Prozesse von Training und Inferenz generativer AI-Modelle deutlich beschleunigen
  • Sie werden außerdem genutzt, damit generative AI-Systeme Nutzern stärker personalisierte und relevantere Inhalte bereitstellen können

Indexing und komplexe Suchbedingungen

  • Vektordatenbanken nutzen fortgeschrittene Indexing-Techniken, um ähnliche Vektoren schnell nachzuschlagen und zu suchen
  • Indizes grenzen den Suchraum auf kleinere, relevantere Teilmengen von Vektoren ein und reduzieren die Suchzeit erheblich
  • Sie können auch komplexe Abfragen verarbeiten, die Ähnlichkeitsbedingungen mit anderen Suchkriterien kombinieren
  • Diese Flexibilität ist wichtig für fortgeschrittene AI-Anwendungen, die anspruchsvolle Suchfunktionen benötigen

1 Kommentare

 
GN⁺ 2024-01-13
Meinungen auf Hacker News
  • Ein paar zusätzliche Materialien:
    A Comprehensive Survey on Vector Database: Storage and Retrieval Technique, Challenge: https://arxiv.org/abs/2310.11703
    Survey of Vector Database Management Systems: https://arxiv.org/abs/2310.14021
    What are Embeddings: https://raw.githubusercontent.com/veekaybee/what_are_embeddi...
    Quellenangabe: https://twitter.com/eatonphil/status/1745524630624862314 und https://twitter.com/ChristophMolnar/status/17457316026829826...
  • Die Folie Braucht man eine dedizierte Vektordatenbank? ist ziemlich interessant, beantwortet die Frage aber letztlich nicht
    Das ist auch ein Punkt, der mich interessiert; Kriterien oder Faustregeln dazu wären hilfreich
    Ich habe mich neulich mit Embeddings in Simon Willisons hervorragendem llm-Tool beschäftigt, und der Ansatz ist denkbar einfach: Embeddings in SQLite speichern, zusammen mit ein paar UDFs zur Distanzberechnung
    Diese Einfachheit ist attraktiv, aber ab einem bestimmten Maß an Traffic und Daten wird man wohl eine spezialisiertere Datenbank brauchen; mich würde interessieren, wo diese Grenze ungefähr liegt
    • Vor ein paar Jahren habe ich einen Vektorindex mit LSH gebaut
      Die Suche war möglichst simpel: alles durchscannen und per Hamming-Distanz (xor und popcount) vergleichen; auf einem einzelnen Kern eines MBP von 2011 konnte ich 200.000 Hashes in unter 10 ms scannen und den ähnlichsten Eintrag finden
    • Ich habe einmal die schnelle, dreckige Engine hinter findsight.ai auf zig Millionen Vektoren skaliert; Details dazu gibt es in diesem Vortrag: https://youtu.be/elNrRU12xRc?t=1556
      Das waren grob 1.000 Zeilen Code, daher brauchten wir am Ende keine externe Vektordatenbank
    • Ehrlich gesagt sind bei rund 100.000 Vektoren Ansätze wie alles im Speicher halten oder SQLite, pgvector usw. völlig in Ordnung
      Darüber hinaus werden brauchbare Optionen wie Pinecone aber komplexer, langsamer und absurd teuer
      Die beste Option, die ich kenne, ist turbopuffer.com; es ist ungefähr 100-mal günstiger als Pinecone und scheint tatsächlich zu skalieren
      Da es in der Liste der empfohlenen Vektor-DBs in den Folien fehlt, werfe ich es als brauchbare Empfehlung in den Raum
    • Es kommt sicher auf den Einzelfall an, aber dieser Beitrag von vor ein paar Wochen hat sehr dabei geholfen, den Blick darauf zu richten, was wir tatsächlich brauchen: Am Ende war es eine Suchmaschine
      https://news.ycombinator.com/item?id=38703943
  • Vor ein paar Monaten habe ich für einen privaten Kunden von TGE Data einen Kurs zu Vektordatenbanken gegeben und danach beschlossen, ihn als kurze Vorlesung für ein breiteres Publikum aufzuzeichnen
    Die Vorlesung kombiniert Theorie und Demos zu den Grundkonzepten von Vektoren, Vektordatenbanken, Indizes und Ähnlichkeitssuche und endet mit Demos der Datenbanken Pinecone und Weaviate
    • Cool. Gibt es dann auch ein Video?
  • Ein gutes Einführungsmaterial, aber ich habe das Gefühl, dass solche Einführungen das Problem der Feature-Auswahl zu schnell übergehen
    In diesem Schritt fließt menschliches Urteil sehr subtil ein, manchmal fast unmerklich, wodurch das Ganze nach außen wie ein stark automatisiertes „einfach Mathematik“-System wirkt
    Nehmen wir Audio als Beispiel: Welche Merkmale extrahiert man, um einen N-dimensionalen Vektor zu erzeugen? Die einfache Antwort könnte lauten: „so viele wie möglich“
    Aber erstens hat man selbst für leicht benennbare Merkmale möglicherweise keinen Zugriff auf die Daten, die sie charakterisieren
    Zweitens weiß man ohne tiefes Domänenwissen vielleicht nicht einmal, dass bestimmte latente Merkmale existieren, die man verwenden sollte
    Drittens kennt man selbst mit tiefem Domänenwissen möglicherweise weiterhin nicht alle latenten Merkmale, die man verwenden sollte
    Angenommen zum Beispiel, man ist Fan von Minimal Music mit Phasenverschiebungen im Stil von Reich. Man stellt eine indirekte Anfrage an eine Vektordatenbank, um Musik zu finden, die typischen Stücken dieses Genres ähnelt, etwa Piano Phase
    Die Datenbank verwendet verschiedene Audio- und Musikmerkmale wie dominante Frequenzen, Abstände zwischen Toneinsätzen, Lautstärke, klangfarbliche Merkmale auf Basis der Frequenzverteilung, scheinbaren Grundton und Tonleiter

Wenn jedoch die Eigenschaftsmenge der Datenbank nicht „die Abstände zwischen Tönen über die Zeit sind konstant“ enthält, kann eine Abfrage zwar Dinge finden, die in Klangfarbe, Harmonik, Melodie und Rhythmus ähnlich sind, aber Stücke zu finden, die das Kernmerkmal teilen, dass sich die relative Phase zweier Melodielinien stetig verändert, bleibt reines Glück
Ähnliche Beispiele lassen sich für visuelle Daten, Text, Zahlen und praktisch jede andere Art von Daten leicht konstruieren
Das heißt natürlich nicht, dass Vektordatenbanken und Feature-Klassifikation nutzlos wären
Eine der ersten Fragen, die man stellen sollte, wenn man in einem bestimmten Datensatz Übereinstimmungsmuster findet oder nicht findet, ist, ob stark garantiert ist, dass die Feature-Menge vollständig ist, und falls nicht, wie man sie erweitern sollte

  • Vektordatenbanken sind auf Suche und Retrieval von Suchergebnissen ausgerichtet
    Üblicherweise erzeugt man Vektoren, indem man große vortrainierte Modelle feinjustiert und interne Repräsentationen extrahiert
    Da der Datensatz erfolgreiche Abfragen und Retrieval-Ergebnisse enthält, kann man die Rohdaten verwenden, um die Verlustfunktion für das von der Vektordatenbank unterstützte Ähnlichkeitsziel zu optimieren
    Bei gängigen Modalitäten wie Tabellen, Text, Bildern und Audio fließt kaum menschliches Urteil in die Feature-Auswahl ein; man wendet einfach Attention an
    Nebenbei: Moderne Text-zu-Vektor-Modelle wie E5-Mistral benötigen nicht einmal menschliche Kuratierung im Datensatz

  • Der Punkt, dass man „nicht weiß, was man nicht weiß“, ist gut getroffen
    Schön, noch einen Steve-Reich-Fan zu sehen, und ich wäre neugierig auf Empfehlungen für Stücke, die meinem Lieblingsstück Music for 18 Musicians ähneln

  • Eine hervorragende Übersicht, aber der letzte Abschnitt behandelt nicht die naheliegende Frage, ob man einen Vektorspeicher wie Postgres+pgvector oder eine Vektordatenbank wie Pinecone verwenden sollte
    Ich würde gern mehr Vorträge sehen, die verschiedene Trade-offs wie Abfragegeschwindigkeit, Einfüge- und Indexaufbaugeschwindigkeit sowie Benutzerfreundlichkeit diskutieren und so helfen, die passende Wahl für die jeweilige Anwendung zu treffen

    • Ich hatte früher angefangen, Vergleiche verschiedener Vektorsuchwerkzeuge zu sammeln: http://vectorsearch.dev/
      PRs sind jederzeit willkommen
    • Ersteres würde ich Vektorerweiterung nennen
      Eine Datenbank ist ein Speicher mit diversen zusätzlichen Funktionen
  • digitaloceanspaces.com ist ein Hosting-Anbieter im S3-Stil, daher wäre es gut, wenn Hacker News dies speziell behandeln und statt die Domain einfach als digitaloceanspaces.com anzuzeigen, etwas wie tge-data-web.nyc3.digitaloceanspaces.com zeigen würde
    Allerdings scheint S3 dasselbe Problem zu haben: https://news.ycombinator.com/item?id=38876761
    Anderswo gibt es dafür Präzedenzfälle. Subdomain-Sites unter x.github.io werden hier speziell behandelt: https://news.ycombinator.com/from?site=lfranke.github.io

  • Dieses Material wirkt ziemlich riskant als Ausgangspunkt für Ingenieure
    Formulierungen wie, dass nach Bedeutung geclustert werde oder dass es für Analyse optimiert sei, sind fragwürdig
    Clustering hängt von den berechneten Embeddings ab. Wenn man glaubt, dass die Embeddings die Bedeutung der Daten gut approximieren, kann man vielleicht so darüber denken
    Aber man kann sich leicht Embeddings vorstellen, die das brechen. Wenn man zum Beispiel eine Audiodatei und eine Textdatei mit gleicher Bedeutung in denselben Embedding-Prozess gibt, liegen sie im Embedding-Vektorraum wahrscheinlich weit auseinander, sofern er nicht multimodal ist
    Ich denke, künftig wird es sicher auch Embeddings geben, die Objekte im Vektorraum nicht nach semantischer Ähnlichkeit, sondern nach Nutzungsart nahe beieinander platzieren
    Wenn man ein Empfehlungssystem baut, möchte man verschiedene Varianten eines einmaligen Kaufs nicht nah beieinander gruppieren
    Beispielsweise wären semantisch die ähnlichsten Flüge andere Abflugzeiten zum selben Ziel oder Flüge zu nahegelegenen Flughäfen, aber in der Praxis möchte man vielleicht Hotels gruppieren, die Menschen, die diesen Flug gekauft haben, häufig ebenfalls gebucht haben
    Eine Vektordatenbank kann auch zusätzliche Dimensionen wie Zeitbewusstsein in die Daten aufnehmen. Man muss nicht zwingend Vektoren verwenden, die Bedeutung encodieren
    Deshalb sind Vektordatenbanken für Lookups oder Suche auf Basis von Eingabevektoren optimiert und ähneln nicht OLAP-Abfragen
    Sie sind eher Elasticsearch als Snowflake. Wenn man eine Vektordatenbank nutzt und Reporting oder groß angelegte Analysen über den Vektorraum erwartet, gibt es meines Wissens derzeit kein wirklich brauchbares Produkt

    • Embedding-Berechnung ist für mich immer noch ein Mysterium
      Ich verstehe, dass man von einem Apfelbild zu einem Vektor gelangt, der „Apfelhaftigkeit“ repräsentiert, und diesen Vektor dann mit gewöhnlicher Mathematik mit anderen Vektoren vergleicht
      Was ich nicht verstehe, ist: Wer oder was nimmt ein Bild als Eingabe und gibt einen Vektor aus?
      Dasselbe gilt für Dokumente. Wenn ich eine Dimension hinzufügen möchte, indem ich einfach eine weitere Zahl in ein Array einfüge, welchen Teil der Vektordatenbank muss ich ändern, damit diese Dimension in die Vektorberechnung einfließt?
      Oder findet der Prozess, Dokumente, Bilder oder was auch immer in Vektorrepräsentationen umzuwandeln, außerhalb der Datenbank auf andere Weise statt?
      Nachtrag: Embedding-Berechnung scheint Aufgabe eines Machine-Learning-Algorithmus zu sein, aber dann muss auch dieser Algorithmus zuerst trainiert werden. Am Ende läuft es also auf endloses Training hinaus
  • Ich weiß nicht, warum PQ als „Indexstrategie“ aufgeführt wurde
    PQ ist eine Technik zur Vektorkompression und -quantisierung, kein Mittel zur Partitionierung des Suchraums
    Man kann Vektoren bei Brute-Force-/Flat-Index-Suche, IVF-Indizes und HNSW mit PQ encodieren; in Faiss gibt es sie entsprechend als IndexPQ, IndexIVFPQ und IndexHNSWPQ
    Wenn man will, kann man sie auch mit k-D-Bäumen oder ANNOY verwenden
    Auch die Aussage „Wenn Abfragegeschwindigkeit wichtiger ist als Genauigkeit, sollte man für sehr große Datensätze HNSW oder Annoy verwenden“ ist problematisch
    Graphbasierte Verfahren haben hohen Speicher-Overhead und hohe Aufbaukosten und sind für Datensätze im Milliardenmaßstab nicht praktikabel
    Sie sind zwar meist genauer und schneller als IVF-Verfahren, weil IVF für ähnliche Genauigkeit viele Zellen besuchen muss
    Andererseits kann IVF im Gegensatz zu anderen Verfahren ohne großen Overhead bis zu Datenbanken im Billionenmaßstab skalieren und dabei einen vernünftigen Kompromiss aus Geschwindigkeit und Genauigkeit bieten
    Ich würde sagen: „Verwenden, wenn Abfragegeschwindigkeit wichtig ist, man aber auch hohe Genauigkeit möchte und ein Flat-/Brute-Force-Index für mittelgroße Datensätze nicht praktikabel ist“

    • Dabei wird ein kontinuierlicher Raum in einen diskreten Raum umgewandelt
      Man führt zuerst PQ aus und macht dann KNN auf den neuen diskreten Vektoren
      So lässt sich der Vokabularraum auf eine feste Größe komprimieren
  • In der Tabelle auf Folie 15 wirken die Felder Indexing & Search Efficiency von Traditional Databases und Vector Databases vertauscht

    • Für mich sieht auch die letzte Zeile so aus, als wäre sie vertauscht
  • Gibt es Empfehlungen für eine eingebettete Embedding-Datenbank wie SQLite?
    Sie wäre für kleinere Probleme gedacht, aber es wäre schön, wenn sie bequemer wäre als LMDB + FAISS

    • Man kann sich txtai (https://github.com/neuml/txtai) ansehen
      Es kann innerhalb eines Python-Prozesses laufen, speichert Inhalte in SQLite und unterstützt das Speichern von Embedding-Vektoren in lokalen Vektorindex-Formaten (Faiss, HNSW, Annoy)
      Zur Einordnung: Ich bin der Hauptautor von txtai
    • Ich habe gerade einen Proof of Concept für eine Ähnlichkeitssuche in HN-Kommentaren mit DuckDB fertiggestellt
      https://github.com/patricktrainer/hackernews-comment-search
    • Zur Einordnung: Simon Willisons Tool llm verwendet nur SQLite und ein paar UDFs
      Diese Einfachheit ist reizvoll, aber ich habe kein gutes Gefühl dafür, wann und warum sie nicht mehr ausreicht
    • Soweit ich weiß, kann man Chroma [1] in Python eingebettet verwenden
      Für Go habe ich kürzlich begonnen, chromem-go zu entwickeln, inspiriert von der Chroma-Schnittstelle: https://github.com/philippgille/chromem-go
      Es ist noch nicht für fortgeschrittene Funktionen oder große Skalierung gedacht, aber RAG-Demos funktionieren
      [1] https://github.com/chroma-core/chroma
    • https://github.com/asg017/sqlite-vss