Udostępnij przez


Przewodnik dotyczący wydajności wyszukiwania wektorowego

Wyszukiwanie wektorów mozaiki sztucznej inteligencji jest tworzone na potrzeby szybkiego, skalowalnego pobierania. Wydajność wyszukiwania wektorowego zależy od wielu czynników, w tym wyboru jednostki SKU, rozmiaru indeksu, typu zapytania, wymiarowości wektora, metod uwierzytelniania i sposobu obsługi skoków ruchu przez aplikację. Większość obciążeń działa dobrze, ale w sytuacjach, w których konieczne jest skalowanie lub optymalizowanie opóźnienia, ten przewodnik przedstawia praktyczne wskazówki i typowe wzorce, które ułatwiają skonfigurowanie systemu pod kątem optymalnej wydajności wyszukiwania wektorów.

Czynniki wpływające na wydajność

Wydajność nie jest jedną liczbą — jest to zakres, który zależy od właściwości obciążeń, wyborów konfiguracji i implementacji klienta. Ten przewodnik jest przeznaczony do ułatwienia tworzenia jasnego modelu psychicznego działania wydajności, dzięki czemu można najektywniej korzystać z funkcji Wyszukiwania wektorów sztucznej inteligencji mozaiki.

Poniżej przedstawiono kluczowe czynniki wpływające na zachowanie systemu:

  • Wybór jednostki SKU: standardowa lub zoptymalizowana pod kątem magazynu.
  • Rozmiar indeksu: liczba przechowywanych wektorów.
  • Rozmiar osadzania: zazwyczaj 384–1536.
  • Typ zapytania: przybliżony najbliższy sąsiad (ANN) lub hybrydowy.
  • Liczba żądanych wyników: wyższe wartości zwiększają czas pobierania.
  • Typ osadzania: zarządzany lub samodzielny.
  • Ładowanie zapytań: ile ruchu trafia do punktu końcowego w czasie.
  • Metoda uwierzytelniania: sposób łączenia aplikacji z usługą Databricks.

W pozostałej części tego artykułu zawarto praktyczne porady dotyczące dostrajania każdej z tych zmiennych i wyjaśniono, jak wpływają one na opóźnienie wyszukiwania i przepływność zapytań we wdrożeniach w świecie rzeczywistym.

Wybierz odpowiednią jednostkę SKU

Narzędzie Mosaic AI Vector Search oferuje dwie jednostki SKU, z których każda została zaprojektowana w celu zrównoważenia opóźnień, skalowalności i wydajności kosztów w zależności od obciążenia. Wybór odpowiedniej jednostki SKU dla aplikacji to pierwsza dźwignia dostrajania wydajności.

Ogólnie rzecz biorąc:

  • Wybierz standardowe punkty końcowe, gdy opóźnienie jest krytyczne, a indeks znajduje się poniżej 320 mln wektorów.
  • Wybierz punkty końcowe zoptymalizowane pod kątem magazynu podczas pracy z wektorami 10M+, mogą tolerować pewne dodatkowe opóźnienia i wymagają lepszej wydajności kosztowej na wektor (do 7 razy tańszy).

W poniższej tabeli przedstawiono pewne oczekiwane wytyczne dotyczące wydajności.

SKU Opóźnienie QPS Pojemność indeksu Rozmiar jednostki wyszukiwania wektorowego (VSU)
Standard 20–50 ms 30–200+ Wektory 320M Wektory 2M
Zoptymalizowane pod kątem magazynu 300–500 ms 30–50 Wektory 1B Wektory 64M

Omówienie rozmiaru indeksu

Wydajność jest najwyższa, gdy indeks mieści się w jednej jednostce wyszukiwania wektorów, z dodatkowym miejscem na obsługę dodatkowego obciążenia zapytań. W miarę skalowania obciążeń poza pojedynczą jednostką wyszukiwania wektorów (czyli wektorami 2M+ dla warstwy Standardowa lub 64M+ w przypadku zoptymalizowanej pod kątem magazynu), opóźnienia zwiększają się i wyłączają naciśnięcia QPS. Ostatecznie płaskowyż QPS wynosi około 30 QPS (ANN).

Wydajność zależy od wielu czynników unikatowych dla każdego obciążenia, takich jak wzorce zapytań, filtry, wymiarowość wektorowa i współbieżność. Poniższe liczby są punktami odniesienia.

SKU Vectors Wymiar Opóźnienie QPS Zapytania miesięczne
Standard 10 000 768 20 ms 200+ 500 mln+
10 mln 768 40 ms 30 78 mln
100 mln 768 50 ms 30 78 mln
Zoptymalizowane pod kątem magazynu 10 mln 768 300 ms 50 130 mln
100 mln 768 400 ms 40 100 mln
1B 768 500 ms 30 78 mln

Minimalizowanie rozmiaru osadzania

Wymiarowość wektorowa odnosi się do liczby cech w każdym wektorze. Typowe wartości to 384, 768, 1024 lub 1536. Wyższe wymiary zapewniają bardziej wyraziste reprezentacje, które mogą poprawić jakość, ale są kosztami obliczeniowymi. Wektory o niższych wymiarach wymagają mniejszej mocy obliczeniowej podczas pobierania, co przekłada się na szybsze czasy zapytań i wyższe QPS. Z drugiej strony wektory o wyższych wymiarach zwiększają obciążenie obliczeniowe i zmniejszają przepływność.

Ogólnie rzecz biorąc, wybierz najmniejszą wymiarowość, która zachowuje jakość pobierania dla danego przypadku użycia.

Na przykład zmniejszenie wymiarowości przez współczynnik dwóch (powiedzmy, z 768 do 384) zwykle poprawia QPS o około 1,5 x i zmniejsza opóźnienie o około 20%, w zależności od rozmiaru indeksu i wzorca zapytania. Zyski te dodatkowo w bardzo niskich wymiarach. Na przykład użycie 64-wymiarowych wektorów może zapewnić znacznie wyższe QPS i znacznie mniejsze opóźnienie w porównaniu z testami porównawczymi 768 wymiarów przedstawionymi w tabeli. To sprawia, że 384 wymiary i poniżej są szczególnie atrakcyjne dla przypadków użycia o wysokiej przepływności, opóźnieniach, o ile jakość pobierania pozostaje akceptowalna.

Używanie nazwy ANN do wydajności i używanie hybrydowego w razie potrzeby

Używaj zapytań ANN zawsze, gdy jest to możliwe. Są one najbardziej wydajne pod względem obliczeń i obsługują najwyższy poziom QPS.

W razie potrzeby użyj wyszukiwania hybrydowego. Wyszukiwanie hybrydowe poprawia kompletność w niektórych aplikacjach, szczególnie w przypadku, gdy słowa kluczowe specyficzne dla domeny są ważne. Wyszukiwanie hybrydowe zwykle używa około dwa razy więcej zasobów niż ANN i może znacznie zmniejszyć przepływność.

Użyj 10–100 wyników

Każde zapytanie zawiera num_results parametr, który jest liczbą wyników wyszukiwania do zwrócenia. Ta wartość ma bezpośredni wpływ na wydajność. Pobieranie większej liczby wyników wymaga dokładniejszego skanowania indeksu, co zwiększa opóźnienie i zmniejsza QPS. Efekt staje się bardziej znaczący na wyższych wartościach. Na przykład zwiększenie num_results o 10 razy może podwoić opóźnienie zapytań i zmniejszyć pojemność QPS o 3 razy, w zależności od rozmiaru indeksu i konfiguracji.

Najlepszym rozwiązaniem jest zachowanie num_results zakresu od 10 do 100, chyba że aplikacja wymaga więcej. Wypróbuj różne num_results wartości przy użyciu realistycznych zapytań, aby zrozumieć wpływ obciążenia.

Unikaj skalowania do zera w środowisku produkcyjnym

Wyszukiwanie wektorowe obsługuje dwa typy osadzania z różnymi kompromisami wydajności.

Najwygodniejsze są zarządzane osadzanie. Dzięki funkcjom osadzania zarządzanego usługa Databricks generuje osadzanie zarówno dla wierszy, jak i zapytań automatycznie. W czasie wykonywania zapytania tekst zapytania jest przekazywany do punktu końcowego obsługującego model w celu wygenerowania osadzania, co zwiększa opóźnienie. Jeśli model osadzania jest zewnętrzny, wprowadza również dodatkowe obciążenie sieci.

Osadzanie zarządzane przez siebie umożliwia wcześniejsze obliczanie osadzania i przekazywanie wektorów bezpośrednio w czasie zapytania. Pozwala to uniknąć generowania środowiska uruchomieniowego i umożliwia najszybsze pobieranie. Wszystkie numery wydajności zawarte w tym artykule są oparte na samodzielnie zarządzanych osadzaniach.

W przypadku przypadków użycia w środowisku produkcyjnym w czasie rzeczywistym unikaj punktów końcowych modelu, które są skalowane do zera. Zimne uruchomienia mogą opóźniać odpowiedzi o kilka minut, a nawet powodować błędy, jeśli punkt końcowy jest nieaktywny po nadejściu zapytania.

Planowanie przypadków wzrostu liczby zapytań

W tej sekcji opisano, czego można oczekiwać w miarę zwiększania się ruchu i jak utrzymać się poniżej krytycznych limitów, które wyzwalają skoki opóźnień lub błędy 429 (zbyt wiele żądań).

Opóźnienie pozostaje niskie, gdy obciążenie jest umiarkowane i stopniowo wzrasta w miarę zbliżania się do maksymalnej pojemności QPS. Gdy system osiągnie 100% pojemności QPS, zacznie zwracać błędy 429. Jeśli nie skonfigurowaliśmy odpowiedniego wycofywania, aplikacja może nie odpowiadać.

Błędy 429 służą jako mechanizm bezpieczeństwa w celu ochrony systemu. Poinstruują klienta, aby wycofał się i ponowił próbę później, aby punkt końcowy pozostał w dobrej kondycji i odpowiedzi, nawet w przypadku nagłych skoków ruchu.

Najlepszym rozwiązaniem jest użycie zestawu SDK języka Python wyszukiwania wektorowego, który obejmuje wbudowaną obsługę wycofywania i ponawiania prób.

Jeśli używasz interfejsu API REST, zaimplementuj wycofywanie wykładnicze za pomocą trząsku. Zobacz Antywzorce platformy Azure.

Używanie jednostek usługi z tokenami OAuth

Użyj wydajnych metod uwierzytelniania, aby uzyskać najlepszą wydajność. Databricks zaleca użycie jednostki serwisowej z tokenem OAuth we wszystkich środowiskach produkcyjnych. Tokeny dostępu OAuth zapewniają większe bezpieczeństwo, a także wykorzystują infrastrukturę zoptymalizowaną pod kątem sieci, aby umożliwić systemowi działanie w pełnej pojemności.

Unikaj używania osobistych tokenów dostępu (PATs), ponieważ wprowadzają obciążenie sieci, dodaj setki milisekund opóźnienia i znacznie zmniejsz QPS, które punkt końcowy może utrzymać.

Używanie zestawu Python SDK

Korzystaj z najnowszej wersji zestawu SDK języka Python, aby korzystać z wbudowanych optymalizacji wydajności i niezawodności.

Użyj ponownie obiektu indeksu w zapytaniach. Unikaj wywoływania client.get_index(...).similarity_search(...) w każdym żądaniu, ponieważ ten wzorzec dodaje niepotrzebne opóźnienie.

Zamiast tego zainicjuj indeks raz i użyj go ponownie:

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

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

Jest to ważne w przypadku korzystania z indeksu wyszukiwania wektorowego w środowiskach MLFlow, gdzie można utworzyć obiekt indeksu podczas inicjowania punktu końcowego, a następnie ponownie użyć go dla każdego zapytania.

Te wskazówki są szczególnie przydatne w aplikacjach wrażliwych na opóźnienia w czasie rzeczywistym. W konfiguracjach RAG z wieloma indeksami lub przepływami autoryzacji w imieniu użytkownika , gdzie wybór indeksu lub poświadczenia są dostępne tylko w czasie zapytania, inicjowanie obiektu indeksu raz może nie być możliwe. Ta optymalizacja nie jest konieczna w tych scenariuszach.

Zrównoleglenie na punktach końcowych

Usługa Databricks zaleca zapoznanie się z następującymi strategiami w celu zwiększenia całkowitej liczby QPS w systemie:

  • Podziel indeksy między punkty końcowe. Jeśli masz wiele indeksów, z których każda otrzymuje znaczną część ruchu, hostuj je w oddzielnych punktach końcowych, aby osiągnąć większą łączną przepustowość.
  • Replikowanie indeksu między punktami końcowymi. Jeśli większość ruchu osiągnie pojedynczy indeks, zduplikuj go w wielu punktach końcowych. Podziel ruch równomiernie na poziomie klienta w celu uzyskania liniowych zysków QPS.

Użyj testowania obciążenia, aby upewnić się, że punkty końcowe mają prawidłowy rozmiar

Test obciążeniowy mierzy wydajność punktu końcowego wyszukiwania wektorów na różnych poziomach ruchu, symulując rzeczywiste użycie i pomagając prawidłowo dostosować punkt końcowy do wymagań produkcyjnych. Aby uzyskać szczegółowe informacje na temat tworzenia i uruchamiania testu obciążeniowego , zobacz Konfigurowanie testu obciążeniowego dla punktów końcowych wyszukiwania wektorów .