Leitfaden zur Leistungsoptimierung der Vektorsuche

Die Mosaik-KI-Vektorsuche ist für einen schnellen, skalierbaren Abruf aufgebaut. Die Leistung der Vektorsuche hängt von vielen Faktoren ab, einschließlich SKU-Auswahl, Indexgröße, Abfragetyp, Vektordimensionalität, Authentifizierungsmethoden und wie Ihre Anwendung Datenverkehrsspitzen verarbeitet. Die meisten Arbeitslasten funktionieren gut einsatzbereit, aber in Situationen, in denen Sie die Latenz skalieren oder optimieren müssen, enthält dieses Handbuch praktische Tipps und gängige Muster, mit denen Sie Ihr System für eine optimale Vektorsuchleistung konfigurieren können.

Faktoren, die sich auf die Leistung auswirken

Die Leistung ist keine einzelne Zahl – es handelt sich um einen Bereich, der von Workloadmerkmalen, Konfigurationsoptionen und Clientimplementierung abhängt. Dieser Leitfaden soll Ihnen helfen, ein klares mentales Modell dafür zu erstellen, wie die Leistung funktioniert, damit Sie die Mosaik AI Vector Search am effektivsten verwenden können.

Im Folgenden sind die wichtigsten Faktoren aufgeführt, die beeinflussen, wie sich das System verhält:

• SKU-Auswahl: Standard oder Speicher optimiert.
• Indexgröße: Anzahl der gespeicherten Vektoren.
• Einbettungsgröße: in der Regel 384–1536.
• Abfragetyp: ungefährer Nächster (ANN) oder Hybrid.
• Anzahl der angeforderten Ergebnisse: Höhere Werte erhöhen die Abrufzeit.
• Einbettungstyp: verwaltet oder selbstverwaltet.
• Abfrageladevorgang: Wie viel Datenverkehr im Laufe der Zeit auf den Endpunkt trifft.
• Authentifizierungsmethode: Wie Ihre App eine Verbindung mit Databricks herstellt.

Der Rest dieses Artikels enthält praktische Tipps für die Optimierung jeder dieser Variablen und erläutert, wie sie sich auf die Suchlatenz und den Abfragedurchsatz in realen Bereitstellungen auswirken.

Auswählen der richtigen SKU

Die Mosaik AI Vector Search bietet zwei SKUs, die je nach Workload zwischen Latenz, Skalierbarkeit und Kosteneffizienz ausgelegt sind. Die Wahl der richtigen SKU für Ihre Anwendung ist der erste Hebel zur Optimierung der Leistung.

Im Allgemeinen:

• Wählen Sie Standardendpunkte aus, wenn die Latenz kritisch ist und Ihr Index gut unter 320M-Vektoren liegt.
• Wählen Sie speicheroptimierte Endpunkte aus, wenn Sie mit 10M+-Vektoren arbeiten, eine zusätzliche Latenz tolerieren und eine bessere Kosteneffizienz pro Vektor benötigen (bis zu 7x günstiger).

Die folgende Tabelle enthält einige erwartete Leistungsrichtlinien.

Grundlegendes zur Indexgröße

Die Leistung ist am höchsten, wenn Ihr Index in eine einzelne Vektorsucheinheit passt, mit zusätzlichem Platz zum Verarbeiten zusätzlicher Abfragelasten. Da Workloads über eine einzelne Vektorsucheinheit hinausgehen (d. h. 2M+ Vektoren für Standard oder 64M+ für speicheroptimiert), erhöht sich die Latenz und QPS-Tipper deaktiviert. Schließlich sind QPS-Plateaus bei ca. 30 QPS (ANN) hoch.

Die Leistung hängt von vielen Faktoren ab, die für jede Workload eindeutig sind, z. B. Abfragemuster, Filter, Vektordimensionalität und Parallelität. Die folgenden Zahlen sind Referenzpunkte.

Minimieren der Einbettungsgröße

Die Vektordimensionalität bezieht sich auf die Anzahl der Features in jedem Vektor. Typische Werte sind 384, 768, 1024 oder 1536. Höhere Dimensionen bieten ausdrucksvollere Darstellungen, die die Qualität verbessern können, aber zu rechenkosten. Weniger dimensionale Vektoren erfordern während des Abrufs weniger Berechnung, was in schnellere Abfragezeiten und höhere QPS übersetzt wird. Umgekehrt erhöhen höherdimensionale Vektoren die Rechenlast und verringern den Durchsatz.

Wählen Sie in der Regel die kleinste Dimensionalität aus, die die Abrufqualität für Ihren Anwendungsfall bewahrt.

Beispielsweise verbessert die Reduzierung der Dimensionalität um den Faktor 2 (z. B. von 768 bis 384) QPS in der Regel um etwa 1,5x und reduziert die Latenz um etwa 20%, je nach Indexgröße und Abfragemuster. Diese Gewinne werden weiter zu sehr niedrigen Dimensionalitäten zusammengesetzt. Beispielsweise kann die Verwendung von 64-dimensionalen Vektoren im Vergleich zu den in der Tabelle gezeigten Benchmarks für 768 Dimensionen erheblich höhere QPS und eine deutlich niedrigere Latenz liefern. Dies macht 384 Dimensionen und darunter besonders attraktiv für fälle mit hohem Durchsatz, latenzempfindliche Anwendungsfälle, solange die Abrufqualität akzeptabel bleibt.

Verwenden von ANN zur Effizienz und Verwenden einer Hybridbereitstellung bei Bedarf

Verwenden Sie NACH Möglichkeit ANN-Abfragen. Sie sind die recheneffizientesten und unterstützen die höchsten QPS.

Verwenden Sie bei Bedarf die Hybridsuche. Die Hybridsuche verbessert den Rückruf in einigen Anwendungen, insbesondere, wenn domänenspezifische Schlüsselwörter wichtig sind. Die Hybridsuche verwendet in der Regel etwa doppelt so viele Ressourcen wie ANN und kann den Durchsatz erheblich reduzieren.

Verwenden von 10 bis 100 Ergebnissen

Jede Abfrage enthält einen num_results Parameter, der die Anzahl der zurückzugebenden Suchergebnisse darstellt. Dieser Wert wirkt sich direkt auf die Leistung aus. Das Abrufen weiterer Ergebnisse erfordert eine tiefere Überprüfung des Indexes, wodurch die Latenz erhöht und QPS reduziert wird. Der Effekt wird bei höheren Werten signifikanter. Beispielsweise kann die Erhöhung num_results um 10x die Abfragelatenz verdoppeln und die QPS-Kapazität je nach Indexgröße und Konfiguration um 3x reduzieren.

Als bewährte Methode sollten Sie den Bereich von 10 bis 1000 beibehalten num_results , es sei denn, Ihre Anwendung erfordert mehr. Probieren Sie verschiedene num_results Werte mithilfe realistischer Abfragen aus, um die Auswirkungen auf Ihre Workload zu verstehen.

Vermeiden von Skalierung zu Null für die Produktion

Die Vektorsuche unterstützt zwei Arten von Einbettungen mit unterschiedlichen Leistungskonflikten.

Verwaltete Einbettungen sind die bequemsten. Bei verwalteten Einbettungen generiert Databricks Automatisch Einbettungen für Ihre Zeilen und Abfragen. Zur Abfragezeit wird der Abfragetext an ein Modell übergeben, das den Endpunkt bedient, um die Einbettung zu generieren, die Latenz hinzufügt. Wenn das Einbettungsmodell extern ist, wird auch zusätzlicher Netzwerkaufwand eingeführt.

Mit selbstverwalteten Einbettungen können Sie vorab Einbettungen berechnen und die Vektoren direkt zur Abfragezeit übergeben. Dadurch wird die Laufzeitgenerierung vermieden und der schnellste Abruf ermöglicht. Alle in diesem Artikel enthaltenen Leistungsnummern basieren auf selbstverwalteten Einbettungen.

Vermeiden Sie modellbasierte Endpunkte, die auf Null skaliert werden, für Echtzeit-Produktionsfälle. Kaltstarts können Antworten um mehrere Minuten verzögern oder sogar Fehler verursachen, wenn der Endpunkt inaktiv ist, wenn eine Abfrage eingeht.

Planen von Abfragespitzen

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, da der Datenverkehr hochgefahren wird und wie Sie unter den kritischen Grenzwerten bleiben, die Latenzspitzen oder 429-Fehler (Zu viele Anforderungen) auslösen.

Die Latenz bleibt niedrig, wenn die Last moderat ist, und erhöht sich schrittweise, wenn Sie sich der maximalen QPS-Kapazität nähern. Wenn das System 100% QPS-Kapazität erreicht, beginnt es, 429 Fehler zurückzugeben. Wenn Sie keinen ordnungsgemäßen Backoff eingerichtet haben, reagiert die App möglicherweise nicht mehr.

429 Fehler dienen als Sicherheitsmechanismus zum Schutz des Systems. Sie weisen den Client an, zu einem späteren Zeitpunkt zurückzuschalten und erneut zu versuchen, damit der Endpunkt fehlerfrei und reaktionsfähig bleibt, auch unter plötzlichen Datenverkehrsspitzen.

Verwenden Sie als bewährte Methode das Vector Search Python SDK, das integrierte Backoff- und Wiederholungsbehandlung umfasst.

Wenn Sie die REST-API verwenden, implementieren Sie exponentielle Backoffs mit Jitter. Siehe Azure-Antipattern.

Verwenden von Dienstprinzipalen mit OAuth-Token

Verwenden Sie effiziente Authentifizierungsmethoden, um eine optimale Leistung zu erzielen. Databricks empfiehlt die Verwendung eines Dienstprinzipals mit OAuth-Token in allen Produktionsumgebungen. OAuth-Zugriffstoken bieten eine höhere Sicherheit und nutzen auch eine netzwerkoptimierte Infrastruktur, damit das System in voller Kapazität ausgeführt werden kann.

Vermeiden Sie die Verwendung von persönlichen Zugriffstoken (PERSONAL Access Tokens, PATs), da sie Netzwerkaufwand verursachen, Hunderte von Millisekunden Latenz hinzufügen und die QPS erheblich reduzieren können, die Ihr Endpunkt erhalten kann.

Verwenden des Python SDK

Verwenden Sie die neueste Version des Python SDK, um von integrierten Leistungs- und Zuverlässigkeitsoptimierungen zu profitieren.

Verwenden Sie das Indexobjekt für alle Abfragen wieder. Vermeiden Sie aufruft client.get_index(...).similarity_search(...) in jeder Anforderung, da durch dieses Muster unnötige Latenz hinzugefügt wird.

Initialisieren Sie den Index stattdessen einmal, und verwenden Sie ihn erneut:

# Initialize once
index = client.get_index(...)

# Then use it for every query
index.similarity_search(...)

Dies ist wichtig, wenn Sie den Vektorsuchindex in MLFlow-Umgebungen verwenden, in dem Sie das Indexobjekt bei der Endpunktinitialisierung erstellen und dann für jede Abfrage wiederverwenden können.

Diese Anleitung ist besonders bei Echtzeit-, Latenz-vertraulichen Anwendungen hilfreich. In RAG-Setups mit mehreren Indizes oder Im-Auftrag-von-Benutzer-Autorisierungsflüssen , bei denen Indexauswahl oder Anmeldeinformationen nur zur Abfragezeit verfügbar sind, kann die Initialisierung des Indexobjekts einmal nicht möglich sein. Diese Optimierung ist in diesen Szenarien nicht erforderlich.

Parallelisieren über Endpunkte hinweg

Databricks empfiehlt, die folgenden Strategien zu untersuchen, um den gesamten QPS im System zu erhöhen:

• Teilen sie Indizes über Endpunkte hinweg. Wenn Sie über mehrere Indizes verfügen, die jeweils einen erheblichen Teil des Datenverkehrs erhalten, hosten Sie sie auf separaten Endpunkten, um eine höhere Gesamtbandbreite zu erreichen.
• Replizieren Sie den Index über Endpunkte hinweg. Wenn der größte Datenverkehr auf einen einzelnen Index trifft, duplizieren Sie ihn über mehrere Endpunkte hinweg. Teilen Sie den Datenverkehr gleichmäßig auf Clientebene für lineare QPS-Gewinne.