Was ich in zwei Jahren bei einem Vector-DB-Unternehmen gelernt habe

Während meiner Arbeit bei der Vector-DB Weaviate habe ich 37 Erkenntnisse aus der realen Praxis zusammengestellt
↳ Von BM25 und dem Nutzen der Keyword-Suche bis hin zu Vector Search, Embeddings und Hybrid Search

1. BM25 ist eine starke Baseline für die Suche

• In der Praxis ist es sinnvoll, die Leistung zunächst mit einfacher Keyword-Suche wie BM25 statt mit komplexer Vector Search zu prüfen und dann schrittweise auf Vector Search zu erweitern

2. Vector Search ist approximativ (Approximate), nicht exakt (Exact)

• Bei großen Datenmengen wird die Geschwindigkeit durch Approximate-Nearest-Neighbor-(ANN)-Algorithmen (HNSW, IVF, ScaNN usw.) erhöht, wobei man bei der Genauigkeit gewisse Kompromisse eingeht
• Vector Indexing ist der Schlüssel dafür, dass eine Vector DB bei großen Datenmengen hohe Geschwindigkeit liefern kann

3. Eine Vector DB speichert nicht nur Embeddings

• Sie speichert auch Originaldaten (z. B. Text) und Metadaten und ermöglicht dadurch Metadaten-Filterung, Keyword-Suche, Hybrid Search usw.

4. Der Hauptanwendungsfall von Vector DBs ist nicht Generative AI, sondern „Search“

• Auch das Einfügen von Kontext in ein LLM ist im Kern „Retrieval“, und Vector DBs und LLMs sind eine sehr passende Kombination

5. Die Anzahl der Suchergebnisse muss explizit angegeben werden

• Wenn kein Parameter wie limit oder top_k gesetzt wird, werden alle Ergebnisse zurückgegeben, die der Query am nächsten sind, sortiert nach Nähe

6. Es gibt viele Arten von Embeddings

• Neben Dense-Vektoren gibt es auch verschiedene Embedding-Vektorformate wie Sparse-, Binary- und Multi-Vector

7. Benchmarks zur Auswahl von Embedding-Modellen

• MTEB deckt verschiedene Embedding-Tasks wie Klassifikation, Clustering und Search ab
• Für Benchmarks mit Fokus auf Information Retrieval siehe BEIR

8. Die meisten Modelle in MTEB sind nur für Englisch gedacht

• In mehrsprachigen oder nicht-englischen Umgebungen empfiehlt sich der Benchmark MMTEB

9. Die Geschichte der Embeddings: Static vs. Contextual

• Statische Embeddings wie Word2Vec und GloVe sind feste Repräsentationen pro Wort
• Kontextuelle Embeddings wie BERT erzeugen Vektoren dynamisch je nach Kontext
• Statische Embeddings können in ressourcenbeschränkten Umgebungen schnell nachgeschlagen werden

10. Der Unterschied zwischen Sparse Vector und Sparse Embedding

• Sparse Vector: erzeugt durch statistische Verfahren wie TF-IDF/BM25 oder neuronale Verfahren (Sparse Embeddings, SPLADE usw.)
• Jedes Sparse Embedding ist ein Sparse Vector, aber nicht jeder Sparse Vector ist ein Sparse Embedding

11. Nicht nur Text lässt sich einbetten

• Auch Bilder, PDFs (nach Umwandlung in Bilder), Graphen usw. können eingebettet werden, um multimodale Vector Search zu ermöglichen

12. Embedding-Dimensionen und Speicherkosten

• Mit steigender Dimensionszahl steigen auch die Speicherkosten
• Für einfache Anwendungsfälle wie „für Chatbots“ sind hochdimensionale Modelle möglicherweise unnötig
• Mit Matryoshka Representation Learning ist auch eine Reduktion auf niedrigere Dimensionen möglich

13. „Chat with your docs“-Tutorials sind das Hello World von Generative AI

14. Embedding-Modelle müssen wiederholt aufgerufen werden

• Nicht nur bei der Dokumentenaufnahme (ingestion), sondern auch bei Queries, beim Hinzufügen/Ändern von Dokumenten und beim Wechsel des Embedding-Modells sind Embedding und Indexing erforderlich

15. Vector Similarity und tatsächliche Relevanz können unterschiedlich sein

• Ähnliche Sätze (z. B. „Wie repariert man einen Wasserhahn?“ vs. „Wo kauft man einen Wasserhahn?“) können inhaltlich wenig relevant zueinander sein

16. Cosine Similarity und Cosine Distance sind nicht dasselbe

• Ähnlichkeit und Distanz stehen mathematisch in einem umgekehrt proportionalen Verhältnis
• Bei identischen Vektoren ist die Similarity 1 und die Distance 0

17. Bei normalisierten Vektoren sind Cosine Similarity und Dot Product identisch

• Bei normalisierten Vektoren ist das Dot Product rechnerisch effizienter

18. Das R in RAG steht nicht für „vector search“, sondern für „retrieval“

• In RAG gibt es viele Formen von Retrieval (Keyword, Vector, Filter usw.)

19. Vector Search ist nur eines von vielen Suchwerkzeugen

• Wichtig ist die Kombination mit verschiedenen Methoden wie Keyword-Suche, Filterung und Reranking (Hybrid)

20. Wann Keyword- und Vector Search jeweils passend sind

• Für semantisches bzw. synonymbasiertes Matching eignet sich Vector Search, für exakte Keywords die Keyword-Suche; wenn beides nötig ist, helfen Hybrid Search und die Steuerung der Gewichtung über alpha

21. Was Hybrid Search bedeutet

• Meist ist damit die Kombination aus Keyword- und Vector-Suche gemeint, aber auch Kombinationen mit anderen Suchmethoden wie Metadaten werden insgesamt als „Hybrid“ bezeichnet

22. Filterung erhöht nicht immer die Geschwindigkeit

• Zum Beispiel kann die Connectivity eines HNSW-Graphen beeinträchtigt werden, und bei nachträglicher Filterung gibt es womöglich gar keine Ergebnisse
• Jede Vector DB nutzt dafür unterschiedliche Optimierungstechniken

23. Der Nutzen einer zweistufigen Suchpipeline

• Nicht nur in Empfehlungssystemen, sondern auch bei RAG kann nach einer ersten Kandidatenauswahl die Qualität durch leistungsstarkes Reranking in einer zweiten Stufe verbessert werden

24. Der Unterschied zwischen Vector Search und Reranking

• Vector Search liefert aus der gesamten DB einen Teil der Ergebnisse zurück, Reranking ordnet die bereits erhaltene Ergebnismenge neu

25. Die Wahl der Chunk-Größe für Embeddings ist schwierig

• Ist sie zu klein, geht Kontext verloren; ist sie zu groß, wird die Bedeutung verwässert
• Man kann auch das gesamte Dokument per Mean Pooling vektorisieren, doch dabei kann Information verwässert werden (wie bei einem Poster, das aus allen Filmframes zusammengefügt wurde)

26. Der Unterschied zwischen Vector-Indexing-Bibliotheken und Vector DBs

• Beide sind schnell, aber Vector DBs bieten zusätzlich Datenmanagementfunktionen wie Durability, CRUD sowie Filter und Hybrid Search

27. Auch mit größerem LLM-Kontext entwickelt sich RAG weiter

• Immer wenn LLMs mit langem Kontext erscheinen, wird diskutiert, ob „RAG tot ist“, doch in der Praxis bleibt es weiterhin notwendig

28. Mit Vector Quantization lassen sich 97 % der Information einsparen und Search bleibt erhalten

• Mit Methoden wie Binary Quantization lässt sich der Speicherbedarf um das 32-Fache senken (z. B. 32-bit float → 1-bit)

29. Vector Search ist gegenüber Tippfehlern nicht robust

• Auch in großen Textkorpora sind nicht automatisch alle Tippfehler abgedeckt; nur einige davon werden erfasst

30. Es gibt viele Metriken zur Bewertung der Suchqualität

• Ranking-basierte Metriken wie NDCG@k sowie einfache Metriken wie Precision/Recall können je nach Situation wirksam sein

31. Praxisbeispiel für den Precision-Recall-Trade-off

• Erläutert an Extremfällen wie nur ein Ergebnis zurückgeben (Precision ↑ / Recall ↓) oder alle Ergebnisse zurückgeben (Recall ↑ / Precision ↓)

32. Metriken, die die Reihenfolge von Suchergebnissen berücksichtigen

• Precision/Recall berücksichtigen die Reihenfolge nicht; dafür braucht man Metriken wie MRR@k, MAP@k, NDCG@k

33. Der Einfluss des Tokenizers

• Nicht nur BPE, auch die Qualität von Keyword- und Hybrid Search wird durch den Tokenizer beeinflusst

34. Out-of-domain und out-of-vocabulary sind nicht dasselbe

• OOV kann mit intelligenten Tokenizern gelöst werden, aber bei out-of-domain ist bereits das Embedding selbst nicht mehr sinnvoll

35. Die Notwendigkeit von Query-Optimierung

• Wie bei der Keyword-Suche sollte man sich auch bei Vector Search an die Optimierung der Query-Eingaben gewöhnen

36. Das Paradigma nach Vector Search

• Die Entwicklung verläuft von Keyword-Suche → Vector Search → Retrieval auf Basis von LLM Reasoning

37. Information Retrieval ist derzeit das „heißeste“ Feld

• Zusammen mit LLMs ist die Suche nach der „besten Information“ für das LLM heute eine der zentralsten und wichtigsten Aufgaben

[mhj5730]

Es ist schön, dass es viele Überlegungen zum Thema Vektorsuche gibt.