Jak pokonać problem miliarda wektorów w Azure AI Search
By Mirko Peters ·
Witamy w naszym szczegółowym omówieniu jednego z najpilniejszych wyzwań współczesnej korporacyjnej sztucznej inteligencji: skalowania wyszukiwania wektorowego do miliardów rekordów. Jeśli pracujesz z nowoczesnymi systemami generowania wspomaganego wyszukiwaniem (RAG, retrieval-augmented generation), wyszukiwarkami semantycznymi lub asystentami AI, prawdopodobnie widziałeś, jak szybko narastają dan
Automatically translated with AI from the original post. Read the English original
Witamy w naszym szczegółowym omówieniu jednego z najpilniejszych wyzwań współczesnej korporacyjnej sztucznej inteligencji: skalowania wyszukiwania wektorowego do miliardów rekordów. Jeśli pracujesz z nowoczesnymi systemami generowania wspomaganego wyszukiwaniem (RAG, retrieval-augmented generation), wyszukiwarkami semantycznymi lub asystentami AI, prawdopodobnie widziałeś, jak szybko narastają dane. Gdy organizacje pozyskują miliony, a czasem miliardy dokumentów, obrazów i interakcji użytkowników, tradycyjne architektury wyszukiwania zaczynają pękać pod tym obciążeniem. Dlatego zrozumienie mechaniki indeksowania wektorów na skalę miliardów nie jest już opcjonalne dla architektów i deweloperów; jest warunkiem przetrwania.
W tym obszernym wpisie omówimy techniczne przeszkody związane z wielowymiarowymi przestrzeniami wektorowymi, porównamy dwa z wiodących w branży algorytmów indeksowania opartych na grafach, Hierarchical Navigable Small World (HNSW) oraz DiskANN firmy Microsoft, i pokażemy, jak Azure AI Search pozwala efektywnie obsługiwać takie obciążenia. Niezależnie od tego, czy dostrajasz parametry pamięci, próbujesz kontrolować koszty infrastruktury sprzętowej, czy chcesz zmaksymalizować trafność wyszukiwania (recall), ten przewodnik da Ci techniczną mapę drogową, której potrzebujesz. Jeśli wolisz treści audio, koniecznie posłuchaj powiązanego odcinka podcastu HNSW vs DiskANN for Vector Search in Azure AI Search w M365 FM.
Problem miliarda wektorów w Azure AI Search
Wyzwania wyszukiwania wektorowego na skali miliardów
Problem miliarda wektorów pojawia się, gdy musisz indeksować i przeszukiwać ogromne zbiory danych w korporacyjnej AI. Obsługa miliardów wektorów wiąże się z unikalnymi wyzwaniami technicznymi. Musisz zbudować wydajne systemy indeksowania, które przetworzą dane na dużą skalę bez spadku wydajności. Aktualizacje w czasie rzeczywistym są ważne, ponieważ chcesz, aby wyniki wyszukiwania były aktualne i trafne. Zarządzanie osadzeniami (embeddings) o wysokiej wymiarowości jest również kluczowe dla dokładnych wyników wyszukiwania.
Podczas pracy z zbiorami danych na skali miliardów napotkasz kilka ograniczeń:
- Wysoka wymiarowość zwiększa koszty obliczeniowe i może spowolnić wyszukiwanie.
- Luka semantyczna między reprezentacjami wektorowymi a rzeczywistym znaczeniem może prowadzić do nieprecyzyjnych wyników.
- Usuwanie nieaktualnych danych staje się trudne, przez co trudno jest wyczyścić z indeksów przestarzałe informacje.
- Jakość wektorów zależy od wybranego modelu osadzania, a to wpływa na dokładność wyszukiwania.
- Skalowanie zwiększa wymagania pamięciowe i może wydłużać czas wyszukiwania.
- Problem zimnego startu utrudnia wyszukiwanie nowych elementów bez dobrych reprezentacji wektorowych.
- Interpretowalność jest niska, dlatego zrozumienie, dlaczego dany wynik wyszukiwania się pojawił, bywa trudne.
Te wyzwania sprawiają, że problem miliarda wektorów jest jednym z najtrudniejszych we współczesnej AI.
Dlaczego wybór algorytmu ma znaczenie
Wybór algorytmu bezpośrednio wpływa na to, jak rozwiążesz problem miliarda wektorów. Jeśli wybierzesz algorytm taki jak HNSW, zyskasz szybki dostęp i efektywne wyszukiwanie w dużych zbiorach danych. Potrzebujesz jednak sporo pamięci RAM, co może podnieść koszty. Inne algorytmy, jak wyczerpujące KNN (exhaustive KNN), oferują wysoką dokładność, ale wymagają znacznie więcej obliczeń, dlatego lepiej sprawdzają się w mniejszych zbiorach danych. Właściwy algorytm pomaga zrównoważyć szybkość, dokładność i zużycie zasobów. Możesz zoptymalizować wydajność dla swojej konkretnej aplikacji, dopasowując algorytm do potrzeb. Ta decyzja determinuje, jak dobrze poradzisz sobie z ogromnymi zbiorami danych i ile wydasz na sprzęt.
Przegląd Azure AI Search
Azure AI Search to potężna platforma do rozwiązywania problemu miliarda wektorów. Możesz przygotować dane za pomocą zaawansowanych narzędzi do czyszczenia i wzbogacania, co poprawia jakość wektorów przed indeksowaniem. Platforma organizuje informacje w bazę wektorową zaprojektowaną z myślą o zadaniach wyszukiwania i nowoczesnych potrzebach w zakresie wyszukiwania. Korzystasz z solidnych funkcji wyszukiwania i pobierania, w tym przetwarzania języka naturalnego do rozumienia semantycznego. Bezpieczeństwo jest na wysokim poziomie dzięki szyfrowaniu i kontroli dostępu chroniącej Twoje dane.
Azure AI Search płynnie integruje się z innymi usługami Microsoft Azure oraz platformami firm trzecich. Możesz użyć wyszukiwania hybrydowego, które łączy wyszukiwanie słów kluczowych z wyszukiwaniem wektorowym, aby uzyskać najlepsze wyniki. Rankingi i dostrajanie trafności pozwalają dostosować sposób wyświetlania wyników wyszukiwania, dzięki czemu są one bardziej przydatne dla użytkowników. Platforma oferuje też inteligentne doświadczenia wyszukiwania, takie jak autouzupełnianie i sugerowane wyniki. Azure AI Search, zbudowana na globalnej infrastrukturze Azure, zapewnia skalowalność i niezawodność potrzebne przy ogromnych zbiorach danych i dużych projektach przetwarzania danych.
Indeks grafowy: HNSW i DiskANN

Czym jest HNSW
Być może słyszałeś o HNSW, czyli hierarchicznym nawigowalnym małym świecie (ang. hierarchical navigable small world). Ten algorytm indeksowania oparty na grafie pomaga szybko znajdować podobne wektory w dużych zbiorach danych. HNSW buduje wielowarstwową strukturę grafu, która łączy punkty danych w sposób umożliwiający szybkie i dokładne wyszukiwanie. Każda warstwa grafu ma inną gęstość: górne warstwy mają mniej węzłów, a dolne – więcej. Dzięki tej konstrukcji możesz rozpocząć wyszukiwanie od góry i schodzić w dół, stopniowo zawężając wyniki. HNSW jest zoptymalizowany pod kątem wyszukiwania wektorowego w pamięci, dlatego przechowuje cały graf w pamięci RAM. Takie podejście zapewnia wyniki o niskim opóźnieniu, ale oznacza też, że przy rosnącym zbiorze danych potrzebujesz dużo pamięci.
Czym jest DiskANN
DiskANN to odpowiedź Microsoftu na wyzwania wyszukiwania wektorowego w skali miliardów. Ten indeks oparty na grafie stosuje podejście hybrydowe, łączące pamięć i pamięć SSD. DiskANN pozwala przechowywać większość indeksu na dyskach SSD, które są znacznie tańsze niż pamięć RAM. W pamięci zachowujesz tylko najważniejsze dane nawigacyjne. Ta konstrukcja pomaga zarządzać ogromnymi zbiorami danych bez wysokich kosztów sprzętu. DiskANN wykorzystuje algorytm grafu Vamana, aby prowadzić wyszukiwanie po danych. Stosuje też specjalną metodę przycinania, która utrzymuje graf zróżnicowany i wydajny. DiskANN firmy Microsoft napędza Azure AI Search i inne usługi, co czyni go kluczową innowacją dla sztucznej inteligencji w przedsiębiorstwach.
| Innowacja | Opis |
|---|---|
| Szybkie wyszukiwanie ANN | Architektura DiskANN umożliwia wydajne wyszukiwanie ANN na dyskach SSD, co pomaga ograniczyć koszty sprzętu. |
| Hybrydowy system pamięci | DiskANN wykorzystuje połączenie DRAM i dysków SSD do obsługi miliardów punktów na jednej maszynie. |
| Ekonomiczne przechowywanie danych | DiskANN przechowuje indeks ANN na dysku, zapewniając przystępne cenowo rozwiązanie do obsługi danych o wysokiej wymiarowości. |
Jak działa HNSW
Budowa grafu
HNSW buduje indeks oparty na grafie, tworząc hierarchię grafów wyszukiwania. Zaczynasz od pustej struktury. Pierwszy dodany wektor staje się jedynym węzłem w górnej warstwie. Dla każdego kolejnego wektora HNSW losowo decyduje, do ilu warstw powinien należeć. Nowy wektor łączy się ze swoimi najbliższymi sąsiadami w każdej warstwie, aż do przypisanego mu maksimum. Górna warstwa ma najmniej węzłów, dzięki czemu jest dobrym punktem startowym wyszukiwania. Dolne warstwy mają więcej węzłów, co pozwala na szczegółowe wyszukiwanie. HNSW może aktualizować swój graf bez pełnej przebudowy, więc możesz dodawać nowe dane wraz ze wzrostem potrzeb.
Proces wyszukiwania
Gdy wyszukujesz za pomocą HNSW, zaczynasz od górnej warstwy grafu. Używasz połączeń dalekiego zasięgu, aby szybko przejść w okolice, w których może znajdować się szukany wektor. Schodząc przez kolejne warstwy, połączenia stają się gęstsze. Pozwala to doprecyzować wyszukiwanie i zbliżyć się do najlepszego dopasowania. Na najniższej warstwie HNSW wykorzystuje wyszukiwanie wiązkowe (beam search), aby znaleźć najbliższych sąsiadów. Ten proces zapewnia szybkie i dokładne wyniki, zwłaszcza gdy cały graf mieści się w pamięci.
- Zasady projektowe HNSW:
- Zoptymalizowany pod kątem operacji w pamięci, zapewniający niskie opóźnienia i wysoki recall.
- Wykorzystuje wielowarstwową strukturę grafu opartą na sieciach małego świata.
- Stosuje strategię przycinania, która usuwa nadmiarowe krawędzie i sprzyja różnorodności.
- Wyszukiwanie polega na schodzeniu przez warstwy: od rzadkich połączeń dalekiego zasięgu do wyszukiwania wiązkowego na warstwie bazowej.
Jak widzisz, zarówno HNSW, jak i DiskANN korzystają z indeksu opartego na grafie, ale ich konstrukcja odpowiada różnym potrzebom. HNSW sprawdza się najlepiej, gdy możesz trzymać wszystko w pamięci. DiskANN pozwala skalować się do miliardów wektorów dzięki wykorzystaniu dysków SSD, co czyni go idealnym rozwiązaniem dla obciążeń przedsiębiorstw w Azure AI Search.
Jak działa DiskANN
Architektura hybrydowa: pamięć i dysk SSD
Z DiskANN korzystasz w wyszukiwaniu miliardów wektorów w sposób, który wyróżnia się na tle innych rozwiązań. DiskANN łączy pamięć RAM i dyski SSD w hybrydową architekturę. Dzięki takiemu rozwiązaniu większość indeksu wektorowego możesz przechowywać na dyskach SSD, które są tańsze od pamięci RAM. W pamięci zostawiasz tylko niezbędne dane nawigacyjne. Ta metoda pozwala skalować wyszukiwanie do miliardów wektorów bez konieczności stosowania drogiego sprzętu.
DiskANN wykorzystuje dwie główne techniki optymalizacji przechowywania i szybkości:
- Graf Vamana: Ta struktura służy do wydajnej nawigacji po indeksie.
- Kwantyzacja produktowa (PQ): Wektory są kompresowane w pamięci, co zmniejsza zużycie pamięci RAM.
Zyskujesz dzięki dwuetapowemu procesowi wykonywania zapytań. W pierwszej fazie DiskANN używa wektorów skompresowanych metodą PQ, znajdujących się w pamięci RAM, aby szybko wskazać zbiór kandydatów. W tym kroku nie trzeba odczytywać danych z dysku. W drugiej fazie DiskANN pobiera z dysku SSD wektory o pełnej precyzji dla zbioru kandydatów. Następnie obliczasz dokładne odległości, aby znaleźć najlepsze dopasowania. Ten proces zapewnia wysoki poziom trafności (recall) i niskie opóźnienia, a jednocześnie utrzymuje niskie wymagania dotyczące pamięci.
Wskazówka: Hybrydowa architektura DiskANN, łącząca pamięć i dysk SSD, umożliwia wyszukiwanie na skalę sieciową na standardowym sprzęcie. Indeksy wektorowe możesz przechowywać na dyskach SSD zamiast w pamięci RAM, co sprawia, że aplikacje na dużą skalę są bardziej przystępne cenowo.
Proces wyszukiwania
Wyszukiwanie w DiskANN zaczyna się od nawigacji po grafie Vamana z wykorzystaniem skompresowanych wektorów w pamięci. Ten krok pomaga szybko znaleźć obiecujących kandydatów. Na tym etapie unikasz odczytów z dysku, co przyspiesza cały proces. Gdy masz już zbiór kandydatów, DiskANN przechodzi do kolejnej fazy.
Dla każdego kandydata pobierasz z dysku SSD wektory o pełnej precyzji. Obliczasz dokładne odległości między zapytaniem a tymi kandydatami. Dzięki temu dwuetapowemu procesowi uzyskujesz dokładne wyniki, bez spowalniania wyszukiwania. Osiągasz wysoki poziom trafności, ponieważ DiskANN szczegółowo sprawdza najlepszych kandydatów. Utrzymujesz też niskie opóźnienia, bo większość pracy odbywa się w pamięci.
Proces wyszukiwania w DiskANN dobrze sprawdza się w przypadku ogromnych zbiorów danych. Możesz obsługiwać miliardy wektorów bez konieczności posiadania dużych ilości pamięci RAM. Otrzymujesz szybkie i wiarygodne wyniki nawet wtedy, gdy dane rosną. Dlatego DiskANN jest mocnym wyborem dla przedsiębiorstw korzystających z obciążeń AI w usłudze Azure AI Search.
| Krok | Co robisz | Korzyść |
|---|---|---|
| Faza 1: Nawigacja | Użyj wektorów skompresowanych metodą PQ w pamięci RAM, aby znaleźć kandydatów | Szybkie wyszukiwanie, brak odczytów z dysku |
| Faza 2: Doprecyzowanie | Pobierz z dysku SSD wektory o pełnej precyzji i oblicz odległości | Wysoki poziom trafności, niskie opóźnienia |
Widzisz, że hybrydowa architektura DiskANN i proces wyszukiwania pomagają efektywnie rozwiązać problem miliardów wektorów. Możesz skalować wyszukiwanie, obniżać koszty i utrzymywać wydajność w miarę wzrostu danych.
Zalety i wady
Zalety i wady HNSW
Do wyszukiwania wektorowego często wybierasz HNSW, ponieważ zapewnia najwyższą klasę szybkości wyszukiwania i wysoki poziom trafności. Po odpowiednim dostrojeniu HNSW uzyskujesz szybkie wyniki i precyzyjne dopasowania. Dobrze radzi sobie z wektorami o wysokiej liczbie wymiarów, co jest ważne w nowoczesnych obciążeniach AI. Korzystasz też z przyrostowego dodawania, dzięki czemu możesz aktualizować indeks bez jego całkowitej przebudowy.
Oto krótki przegląd zalet i wad HNSW:
| Zalety | Wady |
|---|---|
| Najwyższa klasa szybkości wyszukiwania i wysoki poziom trafności po odpowiednim dostrojeniu. | Duże zużycie pamięci, ponieważ przechowywane są połączenia grafu dla każdego wektora. |
| Dobrze radzi sobie z danymi o wysokiej liczbie wymiarów. | Długi czas budowy indeksu przy wysokiej jakości parametrach konstrukcji. |
| Efektywnie obsługuje przyrostowe dodawanie. | Złożone usuwanie elementów może z czasem pogarszać wydajność. |
HNSW skaluje się efektywnie, ponieważ budowa indeksu ma złożoność O(N log N). Budowa równoległa pozwala wykorzystać procesory wielordzeniowe, co przyspiesza cały proces. Zużycie pamięci rośnie liniowo wraz z rozmiarem zbioru danych, dzięki czemu można przewidzieć potrzeby w zakresie przechowywania. Trzeba jednak trzymać cały graf w pamięci RAM, co ogranicza skalowalność dla zbiorów liczących miliardy wektorów.
Zalety i wady DiskANN
Po DiskANN sięgasz wtedy, gdy musisz skalować wyszukiwanie wektorowe poza to, co mieści się w pamięci RAM. DiskANN jest zoptymalizowany pod kątem wykorzystania dysków SSD, co obniża koszty sprzętu i pozwala zarządzać ogromnymi zbiorami danych. Uzyskujesz wysoką dokładność i niskie opóźnienia, łącząc wyszukiwanie w pamięci z grupowymi odczytami z dysków SSD. DiskANN obsługuje aktualizacje w czasie rzeczywistym oraz wyszukiwanie hybrydowe, dzięki czemu możesz efektywnie filtrować i pobierać wektory.
Zwróć uwagę na następujące kwestie dotyczące DiskANN:
- Opłacalna skalowalność dzięki wykorzystaniu dysków SSD zamiast pamięci RAM.
- Wysoka dokładność i niskie opóźnienia w dużej skali dzięki wyszukiwaniu w pamięci i odczytom z dysków SSD.
- Aktualizacje w czasie rzeczywistym oraz hybrydowe wyszukiwanie łączące wektory z filtrowaniem.
- Długi czas budowy, ponieważ konstrukcja grafu Vamana jest obliczeniowo kosztowna.
- Wydajność zależy od przepustowości i opóźnień dysków SSD.
- Aktualizacje są droższe w porównaniu ze strukturami działającymi w pamięci, takimi jak HNSW.
- Wdrożenie i strojenie wymagają starannej optymalizacji.
Zyskujesz dzięki zdolności DiskANN do obsługi wektorów skwantyzowanych, która kompresuje dane i poprawia wyszukiwanie pod kątem efektywności pamięci. Możesz używać DiskANN do obciążeń obejmujących miliardy wektorów, nie martwiąc się limitami pamięci RAM.
Efektywność pamięci i pamięci masowej
Wybierając między HNSW a DiskANN na potrzeby wyszukiwania wektorowego, musisz wziąć pod uwagę efektywność pamięci i pamięci masowej. HNSW dobrze sprawdza się w przypadku zbiorów danych mieszczących się w pamięci RAM serwera. Zapewnia szybki dostęp i wysoką wydajność, ale nie możesz wykroczyć poza limity pamięci. DiskANN pozwala rozszerzyć rozmiar zbioru danych do pojemności dysku, kosztem pewnego spowolnienia. Większość indeksu przechowujesz na dyskach SSD, dlatego DiskANN idealnie nadaje się do bardzo dużych zbiorów wektorów.
| Cecha | HNSW | DiskANN |
|---|---|---|
| Efektywność pamięci | Bardzo wydajny dla zbiorów danych mieszczących się w pamięci podręcznej serwera (RAM). | Zaprojektowany dla zbiorów danych zbyt dużych, by zmieścić się w pamięci RAM. |
| Efektywność pamięci masowej | Ograniczony ilością dostępnej pamięci RAM. | Rozszerza rozmiar zbioru danych do pojemności dysku, kosztem pewnego spowolnienia. |
| Optymalizacja wydajności | Wykorzystuje szybki dostęp do pamięci, zapewniając wysoką szybkość. | Minimalizuje straty wydajności wynikające z wolniejszej pamięci dyskowej. |
| Przydatność dla zbiorów danych | Odpowiedni dla zbiorów danych mieszczących się w pamięci RAM. | Odpowiedni dla bardzo dużych zbiorów danych przekraczających pojemność pamięci RAM. |
W HNSW i DiskANN używasz wektorów skwantyzowanych, aby zmniejszyć potrzeby w zakresie pamięci masowej i przyspieszyć wyszukiwanie. Hybrydowa architektura DiskANN pozwala skalować wyszukiwanie wektorowe, utrzymując niskie koszty. Osiągasz wydajne pod względem pamięci wyszukiwanie w zadaniach na dużą skalę, zwłaszcza gdy pracujesz z wektorami skwantyzowanymi i pamięcią SSD.
Porównanie algorytmów wyszukiwania wektorowego

Wydajność przy dużej skali
Musisz zmierzyć, jak algorytm wyszukiwania wektorowego działa wraz ze wzrostem zbioru danych. HNSW i DiskANN mają na celu zapewnienie wysokiej trafności (recall) i szybkości, ale ich strategie się różnią. HNSW opiera się na grafach działających w pamięci, co oznacza, że uzyskujesz szybkie wyszukiwanie najbliższych sąsiadów, gdy wektory mieszczą się w pamięci RAM. DiskANN wykorzystuje podejście hybrydowe, łączące pamięć i dyski SSD, dzięki czemu możesz skalować wydajność wyszukiwania bez obaw o limity pamięci.
Gdy wykonujesz wyszukiwanie najbliższych sąsiadów na milionach wektorów, HNSW zapewnia szybkie pobieranie wyników i niskie opóźnienia. Parametry możesz dostroić pod kątem trafności i szybkości. DiskANN utrzymuje wysoką trafność i szybkość nawet wtedy, gdy zbiór danych rośnie. Większość indeksu przechowujesz na dyskach SSD, co pozwala obsługiwać miliardy wektorów. Stosujesz wyszukiwanie dwuetapowe, aby zrównoważyć szybkość i dokładność: pierwszy etap znajduje kandydatów w pamięci, a drugi doprecyzowuje wyniki na podstawie dysków SSD.
Obydwa algorytmy zapewniają wysoką trafność i szybkość, ale DiskANN pozwala skalować wydajność wyszukiwania poza granice pamięci RAM.
Skalowalność dla miliardów wektorów
Stajesz przed nowymi wyzwaniami, gdy zbiór danych rośnie od milionów do miliardów wektorów. HNSW dobrze sprawdza się przy liczbie do 50 milionów wektorów. Używasz HNSW jako domyślnego algorytmu wyszukiwania wektorowego i dostrajasz parametry pod kątem trafności. Gdy liczba wektorów wynosi od 50 do 500 milionów, wdrażasz shardowanie i kwantyzację skalarną. Dla zwiększenia wydajności możesz zastosować wyszukiwanie dwufazowe. Dla zbiorów danych przekraczających 500 milionów wektorów potrzebujesz wyszukiwania hierarchicznego i architektur wielopoziomowych. Dla danych rzadko używanych stosujesz agresywną kwantyzację.
| Zakres liczby wektorów | Strategia HNSW |
|---|---|
| 1–50 mln | Użyj HNSW jako domyślnego algorytmu, zadbaj o to, by wektory mieściły się w pamięci RAM, i dostrój parametry pod kątem trafności. |
| 50–500 mln | Wdróż shardowanie, włącz kwantyzację skalarną i rozważ wyszukiwanie dwufazowe dla zwiększenia wydajności. |
| 500 mln+ | Zastosuj wyszukiwanie hierarchiczne, architektury wielopoziomowe i agresywną kwantyzację dla danych rzadko używanych. |
DiskANN zmienia zasady gry w wyszukiwaniu wektorowym na skali miliardów. Większość indeksu przechowujesz na dyskach SSD, więc nie musisz martwić się limitami pamięci RAM. Do kompresji wektorów używasz kwantyzacji produktowej, a dane nawigacyjne utrzymujesz w pamięci. Skalujesz wyszukiwanie najbliższych sąsiadów do miliardów wektorów bez utraty wydajności. DiskANN obsługuje przybliżone wyszukiwanie oparte na klastrowaniu oraz wyszukiwanie hybrydowe, co ułatwia zarządzanie bardzo dużymi zbiorami danych.
DiskANN pozwala skalować algorytm wyszukiwania wektorowego do miliardów wektorów, co czyni go idealnym rozwiązaniem dla obciążeń w przedsiębiorstwach.
Opóźnienia zapytań i przepustowość
Podczas wyszukiwania wektorowego na dużą skalę zwracasz uwagę na opóźnienie zapytań i przepustowość. HNSW zapewnia niskie opóźnienie wyszukiwania najbliższych sąsiadów, ponieważ przechowuje cały graf w pamięci. Dzięki temu zapytania są szybko obsługiwane, a przepustowość jest wysoka dla zbiorów danych mieszczących się w pamięci RAM. Gdy zbiór danych rośnie, opóźnienie wzrasta, dlatego trzeba stosować podział na shardy lub architektury wielopoziomowe.
DiskANN korzysta z dwuetapowego procesu wyszukiwania. Najpierw przeszukujesz skompresowane wektory w pamięci, co pozwala szybko wybrać kandydatów. Następnie doprecyzowujesz zapytanie, pobierając wektory o pełnej precyzji z dysków SSD. Takie podejście utrzymuje niskie opóźnienie i wysoką przepustowość, nawet dla zbiorów danych liczonych w miliardach wektorów. Możesz zoptymalizować wyszukiwanie, grupując odczyty z dysków SSD w paczki i stosując wydajne struktury nawigacyjne.
Dzięki DiskANN osiągasz wysoką trafność i szybkość, nawet gdy liczba zapytań rośnie. Nie musisz martwić się limitami pamięci, dzięki czemu możesz skalować wydajność wyszukiwania w aplikacjach przedsiębiorstw.
DiskANN zapewnia niezawodne opóźnienie zapytań i przepustowość, dzięki czemu jest mocnym wyborem do wyszukiwania najbliższych sąsiadów na dużą skalę.
Wpływ na koszty i zasoby
Wybierając algorytm wyszukiwania wektorowego dla usługi Azure AI Search, musisz wziąć pod uwagę wpływ na koszty i zasoby. Sposób, w jaki każdy algorytm wykorzystuje pamięć i pamięć masową, wpływa na Twój budżet i zdolność do skalowania.
DiskANN wyróżnia się w obciążeniach obejmujących miliardy wektorów. Większość indeksu możesz przechowywać na dyskach SSD, które są tańsze od pamięci RAM. Ta konstrukcja pozwala skalować od tysięcy do miliardów wektorów bez dużego wzrostu kosztów pamięci. DiskANN dobrze sprawdza się w produkcyjnych obciążeniach AI, ponieważ efektywnie wykorzystuje dyski SSD i utrzymuje w pamięci tylko najważniejsze dane.
HNSW najlepiej sprawdza się w przypadku średnich zbiorów danych. Musisz trzymać cały indeks w pamięci RAM, co ogranicza możliwość skalowania. Jeśli zbiór danych stanie się zbyt duży, mogą wzrosnąć koszty operacyjne. HNSW jest też ograniczony do 2000 wymiarów, co może zawęzić Twoje przypadki użycia.
| Typ indeksu | Odpowiedni dla obciążeń obejmujących miliardy wektorów | Wymagania dotyczące pamięci | Koszty operacyjne |
|---|---|---|---|
| DiskANN | Tak, zaprojektowany z myślą o wydajności dysków SSD | Skaluje się od tysięcy do miliardów wektorów | Zalecany dla produkcyjnych obciążeń AI |
| HNSW | Nie, odpowiedni dla średnich zbiorów danych | Wymaga, aby indeks mieścił się w pamięci RAM | Ograniczony do 2000 wymiarów |
Wskazówka: Jeśli chcesz kontrolować koszty i skalować wyszukiwanie do miliardów wektorów, DiskANN daje Ci wyraźną przewagę. Możesz korzystać z przystępnych cenowo dysków SSD i utrzymywać niskie zapotrzebowanie na pamięć.
Przykłady zastosowań w praktyce
Wartość tych algorytmów widać w rzeczywistych aplikacjach. Wiele organizacji używa DiskANN i HNSW do różnych typów problemów wyszukiwania wektorowego.
- Do przybliżonego wyszukiwania najbliższych sąsiadów możesz zastosować opłacalną metodę hybrydową. Łączy ona pamięć masową SSD ze strukturami grafowymi w pamięci.
- DiskANN możesz wdrożyć dla statycznych zbiorów danych, takich jak korpusy badawcze, w których dane nie zmieniają się często.
- DiskANN warto wybrać dla wdrożeń wrażliwych na koszty. Dobrze sprawdza się w aplikacjach na skalę miliardów, gdzie musisz kontrolować wydatki.
- DiskANN możesz wykorzystać do zapytań, które tolerują opóźnienia poniżej 10 milisekund. Ta szybkość jest wystarczająca w wielu zadaniach wyszukiwania w przedsiębiorstwach.
- Do wyszukiwania hybrydowego możesz połączyć HNSW z odwróconymi plikami indeksów opartymi na dysku (HNSW-IF). Ta metoda zapewnia wysoką trafność i utrzymuje niskie opóźnienie.
| Przypadek użycia | Opis |
|---|---|
| Statyczne zbiory danych | Idealne dla korpusów badawczych, w których dane nie zmieniają się często. |
| Wdrożenia wrażliwe na koszty | Odpowiednie dla aplikacji na skalę miliardów, gdzie koszt ma znaczenie. |
| Zapytania tolerujące opóźnienia | Dobrze sprawdza się w zapytaniach, które tolerują opóźnienia poniżej 10 ms. |
Uwaga: Wiele organizacji osiąga 90% trafności przy opóźnieniu 10 ms, stosując metody hybrydowe. Taka wydajność spełnia potrzeby większości aplikacji wyszukiwania AI w przedsiębiorstwach.
Dopasuj wybór algorytmu do swojego obciążenia. Jeśli musisz skalować, kontrolować koszty i utrzymywać niskie opóźnienie, DiskANN zapewni Ci elastyczność i wydajność, których potrzebujesz.
Kiedy użyć HNSW lub DiskANN
Wybór właściwego algorytmu dla obciążenia w usłudze Azure AI Search może znacząco wpłynąć na szybkość, koszty i dokładność. Musisz uwzględnić dane, sprzęt oraz to, jak często dane się zmieniają. Przeanalizujmy główne kryteria decyzyjne, abyś mógł wybrać najlepsze narzędzie do potrzeb wyszukiwania wektorowego.
Kryteria decyzyjne
Rozmiar zbioru danych
Zawsze zacznij od sprawdzenia wielkości zbioru danych. Jeśli pracujesz z milionami wektorów, HNSW zapewnia szybkie i dokładne wyniki wyszukiwania. Najlepiej sprawdza się wtedy, gdy dane mieszczą się w pamięci. Gdy zbiór danych urośnie do miliardów wektorów, lepszym wyborem staje się DiskANN. Wykorzystuje dyski SSD do przechowywania większości indeksu, dzięki czemu nie musisz martwić się brakiem pamięci RAM.
| Kryterium | HNSW | DiskANN |
|---|---|---|
| Wielkość zbioru danych | Przeznaczony dla milionów wektorów | Doskonale sprawdza się dla miliardów wektorów |
Widać, że HNSW pasuje do mniejszych obciążeń, a DiskANN obsługuje ogromne zbiory danych bez spowalniania.
Sprzęt i koszty
Na wybór wpływają również sprzęt i budżet. HNSW wymaga dużej ilości pamięci RAM, ponieważ przechowuje cały graf w pamięci. Może to być kosztowne, gdy baza wektorowa rośnie. DiskANN pozwala oszczędzać, ponieważ przechowuje większość indeksu na dyskach SSD, które są tańsze od pamięci RAM. Potrzebujesz pamięci tylko na część nawigacyjną indeksu.
| Kryterium | HNSW | DiskANN |
|---|---|---|
| Infrastruktura | Wymagania dotyczące pamięci RAM | Zmniejsza koszty pamięci |
Jeśli chcesz utrzymać niskie koszty i jednocześnie przeszukiwać miliardy wektorów, DiskANN daje wyraźną przewagę.
Wymagania dotyczące opóźnienia
Zastanów się, jak szybko potrzebujesz wyników wyszukiwania. HNSW zapewnia bardzo niskie opóźnienie, ponieważ wyszukuje w pamięci. Wyniki możesz uzyskać w zaledwie kilka milisekund, jeśli dane mieszczą się w pamięci RAM. DiskANN równoważy szybkość i skalę. Używa dwuetapowego procesu wyszukiwania, dzięki czemu nawet przy ogromnych zbiorach danych wyniki są szybkie. W przypadku większości zastosowań korporacyjnych DiskANN utrzymuje czas zapytań poniżej 10 milisekund.
- HNSW najlepiej sprawdza się w obciążeniach, w których liczy się każda milisekunda.
- DiskANN dobrze sprawdza się, gdy potrzebujesz szybko przeszukiwać duże zbiory danych i możesz zaakceptować niewielki wzrost opóźnienia.
Wzorce aktualizacji
Na wybór wpływa także to, jak często zmieniają się dane. HNSW dobrze sprawdza się w przypadku danych statycznych lub wolno zmieniających się. Jeśli często aktualizujesz wektory, może być konieczne przebudowanie indeksu, co zajmuje czas. DiskANN lepiej radzi sobie z częstymi aktualizacjami. Zachowuje stabilną dokładność i czułość (recall), nawet gdy często dodajesz lub zmieniasz wektory.
| Cecha | HNSW | DiskANN |
|---|---|---|
| Opóźnienie aktualizacji | Wymaga pełnej przebudowy indeksu | Efektywnie dostosowuje się do zmian |
| Czułość (recall) | Wysoka, ale zależna od zmian | Stabilna dokładność przy częstych modyfikacjach |
Jeśli Twoja aplikacja musi obsługiwać dużo aktualizacji, DiskANN daje większą elastyczność.
Scenariusze przykładowe
Możesz skorzystać z rzeczywistych scenariuszy, które pomogą wybrać algorytm odpowiedni dla Twoich potrzeb.
| Metryka | HNSW | DiskANN |
|---|---|---|
| Średnia czułość (recall) | 0.6 | 0.7 |
| Dokładność end-to-end | 0.972 | 0.933 |
| Robustness-0.2@10 | 0.998 | 0.984 |
| Robustness-0.9 | 0.84 | 0.81 |
- HNSW zapewnia wysoką czułość i szybką przepustowość zapytań. W zbiorach danych takich jak SIFT1M można osiągnąć około 95% czułości przy 10 wynikach, w zaledwie 1–2 milisekundy na zapytanie na procesorze CPU.
- DiskANN osiąga wyższą średnią czułość, co oznacza, że znajduje więcej rzeczywistych trafień w dużych zbiorach danych. Utrzymuje wysoką dokładność nawet wtedy, gdy dane rosną.
- HNSW najlepiej sprawdza się w systemach rekomendacji i wyszukiwarkach, w których liczy się najwyższa dokładność i szybkość.
- DiskANN nadaje się do wyszukiwania na dużą skalę, na przykład przeszukiwania miliardów obrazów produktów lub dokumentów, gdy trzeba zrównoważyć szybkość, koszty i skalę.
HNSW wyróżnia się w obciążeniach wymagających możliwie najszybszego wyszukiwania na mniejszych zbiorach danych. DiskANN sprawdza się wtedy, gdy trzeba przeszukiwać ogromne ilości danych bez przekraczania budżetu.
Migracja i podejścia hybrydowe
Nie musisz wybierać jednego algorytmu do każdej sytuacji. Wiele organizacji zaczyna od HNSW dla mniejszych zbiorów danych. Gdy baza wektorowa rośnie, przechodzą na DiskANN, aby obsłużyć więcej danych i utrzymać niższe koszty. Możesz też zastosować podejście hybrydowe. Na przykład najczęściej używane lub najnowsze wektory możesz trzymać w pamięci w HNSW, a starsze lub rzadziej używane przechowywać na dyskach SSD w DiskANN.
- Zacznij od HNSW do szybkiego prototypowania i małych obciążeń.
- Przejdź na DiskANN, gdy zbiór danych przekroczy limity pamięci.
- Połącz oba podejścia, aby uzyskać najlepsze połączenie szybkości i skali.
Wskazówka: Regularnie przeglądaj swoje obciążenia. Wraz ze zmianą danych i potrzeb możesz dostosować podejście, aby uzyskać najlepszą wydajność i wartość.
Rozumiejąc wielkość zbioru danych, sprzęt, wymagania dotyczące opóźnienia i wzorce aktualizacji, możesz świadomie wybrać między HNSW a DiskANN. Dzięki temu zbudujesz system wyszukiwania wektorowego, który odpowiada Twoim celom i rozwija się wraz z Twoją firmą.
Najlepsze praktyki wyszukiwania wektorowego w usłudze Azure
Wskazówki dotyczące konfiguracji indeksu
Wysoką wydajność w usłudze Azure AI Search osiągniesz, stosując kilka istotnych wskazówek dotyczących konfiguracji. Zacznij od upewnienia się, że rozmiar indeksu mieści się w jednej jednostce wyszukiwania wektorowego. Pomoże to utrzymać szybkie i niezawodne wyszukiwanie. Staraj się minimalizować rozmiar osadzeń. Mniejsze osadzenia skracają czas zapytań i zwiększają liczbę zapytań na sekundę. Korzystaj z zapytań Approximate Nearest Neighbor, ponieważ przyspieszają wyszukiwanie bez większej utraty dokładności.
Ogranicz liczbę wyników na zapytanie do zakresu od 10 do 100. Ten przedział zmniejsza opóźnienia i utrzymuje responsywność wyszukiwania. Unikaj punktów końcowych modeli, które skalują się do zera, w środowisku produkcyjnym. Zimne starty mogą spowolnić wyszukiwanie i frustrować użytkowników. Planuj szczytowe obciążenia zapytań, aby system radził sobie z nagłym wzrostem ruchu wyszukiwania. Używaj jednostek usługi (service principals) z tokenami OAuth, aby zapewnić bezpieczne i wydajne uwierzytelnianie. Zawsze korzystaj z najnowszej wersji SDK dla Pythona, aby czerpać korzyści z ulepszeń wydajności. Jeśli potrzebujesz wyższej przepustowości, skaluj punkt końcowy lub rozłóż obciążenie na wiele punktów końcowych.
Wskazówka: dobrze skonfigurowany indeks to fundament zoptymalizowanego wyszukiwania wektorowego w usłudze Azure.
Monitorowanie i optymalizacja
Musisz monitorować i optymalizować system wyszukiwania, aby utrzymać wysoką wydajność, zwłaszcza przy obciążeniach obejmujących miliardy wektorów. Poniższa tabela przedstawia kilka skutecznych technik:
| Technika | Opis |
|---|---|
| Indeksy wielopoziomowe | Używaj szybkich indeksów dla danych często wykorzystywanych i kompresuj dane rzadko używane, aby oszczędzić miejsce. |
| Kontrola fan-out | Zarządzaj interakcjami między fragmentami (shardami) i klastrami, aby ograniczyć liczbę przeskoków sieciowych. |
| Kwantyzacja | Zmniejszaj rozmiar wektorów metodami takimi jak IVF-PQ, aby zmieścić je w limitach pamięci. |
| Dostrajanie centroidów | Dostosowuj liczbę centroidów, aby zrównoważyć czułość wyszukiwania (recall) i narzut. |
| Asymetryczne obliczanie odległości | Przyspieszaj wyszukiwanie, porównując zapytania o pełnej precyzji ze skompresowanymi wektorami. |
| Celowe kierowanie zapytań | Używaj metadanych i grupowania, aby uniknąć zbędnego rozsyłania zapytań podczas wyszukiwania. |
| Minimalizacja ładunków sieciowych | Między węzłami przesyłaj tylko identyfikatory i wyniki, a nie pełne wektory. |
| Hierarchiczna agregacja | Agreguj wyniki lokalnie, aby ograniczyć koordynację i ustabilizować opóźnienia. |
| Dominacja pamięci | Upewnij się, że wektory mieszczą się w pamięci, aby uzyskać najlepszą wydajność wyszukiwania. |
| Sytuacyjne użycie GPU | Używaj procesorów GPU do indeksowania, jeśli zachodzi taka potrzeba, ale sprawdź, czy poprawiają one przepustowość wyszukiwania. |
| Jakość sieci | Monitoruj warunki sieciowe, ponieważ wpływają one na opóźnienia wyszukiwania. |
Uwaga: regularne monitorowanie pomaga wcześnie wykrywać problemy i utrzymać płynne działanie wyszukiwania.
Typowe pułapki
Podczas konfigurowania lub skalowania systemu wyszukiwania w usłudze Azure możesz napotkać typowe pułapki. Jedną z nich jest dopuszczenie do zbyt dużego wzrostu indeksu względem pojedynczej jednostki wyszukiwania. Może to spowolnić zapytania i obniżyć niezawodność wyszukiwania. Duże osadzenia również mogą pogorszyć wydajność. Zawsze utrzymuj osadzenia tak małe, jak to możliwe dla swojego przypadku użycia.
Inną pułapką jest ignorowanie szczytowych obciążeń zapytań. Jeśli nie planujesz nagłych wzrostów ruchu wyszukiwania, system może nie wytrzymać presji. Poleganie na punktach końcowych skalujących się do zera może powodować opóźnienia zimnego startu, które spowalniają wyszukiwanie. Brak aktualizacji SDK lub niekorzystanie z tokenów OAuth może prowadzić do zagrożeń bezpieczeństwa i utraty korzyści wydajnościowych.
Pamiętaj: unikaj tych pułapek, aby wyszukiwanie było szybkie, bezpieczne i niezawodne.
Stosując te sprawdzone praktyki, zbudujesz solidne i wydajne środowisko wyszukiwania w usłudze Azure. Z łatwością obsłużysz duże zbiory danych i dostarczysz użytkownikom szybkie, trafne wyniki.
Problem miliardów wektorów w usłudze Azure AI Search rozwiążesz, wybierając algorytm odpowiedni do swoich potrzeb. DiskANN zapewnia opłacalną skalowalność dla ogromnych zbiorów danych, natomiast HNSW dostarcza szybkich wyników dla mniejszych obciążeń. Dopasowujesz algorytm do obciążenia, skali i budżetu. Poniższa tabela pomoże Ci wybrać najlepszy punkt końcowy:
| Typ SKU | Opis przypadku użycia |
|---|---|
| Standard Endpoints | Najlepsze rozwiązanie przy krytycznych wymaganiach dotyczących opóźnień, dla indeksów z mniej niż 320M wektorów. |
| Storage-Optimized Endpoints | Idealne dla ponad 10M wektorów, gdy można tolerować pewne opóźnienia i wymagana jest efektywność kosztowa. |
- Oszacuj potrzeby dotyczące magazynu, testując działanie na kilku dokumentach.
- Uwzględnij aktualizacje i łączną ilość treści.
Azure AI Search zapewnia elastyczność i wspiera innowacje Microsoft dla sztucznej inteligencji w przedsiębiorstwach. Aby połączyć wszystkie te wnioski techniczne z rzeczywistą architekturą chmury, koniecznie posłuchaj towarzyszącego odcinka podcastu HNSW vs DiskANN for Vector Search in Azure AI Search.
Często zadawane pytania
Jaka jest główna różnica między HNSW a DiskANN?
Do wyszukiwania wektorów w pamięci używasz HNSW. DiskANN pozwala przechowywać większość indeksu na dyskach SSD. Dzięki temu DiskANN lepiej radzi sobie z miliardami wektorów bez wysokich kosztów pamięci.
Czy można używać DiskANN w aplikacjach czasu rzeczywistego?
Tak. DiskANN zapewnia wyszukiwanie o niskim opóźnieniu, często poniżej 10 milisekund. Można go używać do zadań wyszukiwania AI w czasie rzeczywistym, nawet przy bardzo dużych zbiorach danych.
Jak wybrać algorytm w Azure AI Search?
Wybierz HNSW dla mniejszych zbiorów danych, które mieszczą się w pamięci RAM. Wybierz DiskANN dla ogromnych zbiorów danych, które wymagają opłacalnego skalowania. Uwzględnij rozmiar danych, sprzęt i wymagania dotyczące opóźnień.
Czy DiskANN wymaga specjalnego sprzętu?
Nie. DiskANN można uruchomić na standardowych serwerach z dyskami SSD. Nie potrzebujesz drogich maszyn z dużą ilością pamięci. Dzięki temu skalowanie jest prostsze i tańsze.
Jak Azure AI Search chroni dane?
Azure AI Search korzysta z szyfrowania i kontroli dostępu. To Ty decydujesz, kto ma dostęp do danych. Funkcje zabezpieczeń Microsoft pomagają chronić poufne informacje.
Czy można aktualizować indeks wektorowy bez przestojów?
Można aktualizować zarówno indeksy HNSW, jak i DiskANN. DiskANN obsługuje wydajne aktualizacje dużych zbiorów danych. Wyniki wyszukiwania pozostają aktualne, a system nie musi być wyłączany.
Jakie są najlepsze praktyki optymalizacji wydajności wyszukiwania wektorowego?
Używaj mniejszych osadzeń (embeddingów), utrzymuj indeks w obrębie jednej jednostki wyszukiwania i monitoruj opóźnienie zapytań. Zawsze aktualizuj zestaw SDK i planuj szczyty obciążenia zapytaniami, aby utrzymać wysoką wydajność.
🎧 Posłuchaj tego odcinka
Chcesz praktycznego wyjaśnienia różnic między HNSW a DiskANN w wyszukiwaniu wektorowym w Azure AI Search? Ten odcinek w przystępny sposób omawia ten temat i pokazuje, dlaczego ma on znaczenie dla Microsoft 365, Azure, Power Platform, bezpieczeństwa, AI i nowoczesnej pracy.
Posłuchaj tego odcinka, jeśli chcesz:
- Zrozumieć kluczowe koncepcje dotyczące HNSW a DiskANN w wyszukiwaniu wektorowym w Azure AI Search
- Zobaczyć, jak ten temat wpisuje się w szerszy ekosystem technologii Microsoft
- Dowiedzieć się, gdzie może przynieść praktyczną wartość Twojej organizacji
Możesz też polubić te powiązane odcinki M365 FM:
- Improve Microsoft Copilot Accuracy Beyond Vector Search
- Azure AI Search – Simply Explained
- Vector Databases - Simply Explained
- Wykrywanie zasobów Microsoft Graph API na potrzeby semantycznego wyszukiwania w przedsiębiorstwie
- Jak sprawić, by wyszukiwarka SharePoint najpierw pokazywała właściwe pliki
Odkryj więcej praktycznych rozmów o Microsoft na stronie M365 FM.
Ostatnia weryfikacja: lipiec 2026.
Dla kogo jest ten odcinek
Ten odcinek jest przeznaczony dla administratorów Microsoft, architektów, deweloperów, specjalistów ds. bezpieczeństwa i liderów biznesowych, którzy potrzebują praktycznych podstaw przed podjęciem decyzji dotyczących wdrożenia, eksploatacji lub zarządzania.
🎧 Warto też posłuchać
- Azure Resource Manager — wyraźnie powiązany kolejny krok w rozwijaniu tego tematu.
- Infrastructure as Code — wyraźnie powiązany kolejny krok w rozwijaniu tego tematu.
- Azure Policy — wyraźnie powiązany kolejny krok w rozwijaniu tego tematu.