Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Note
Wyszukiwanie AI platformy Azure jest dostępna za pośrednictwem portalu Azure, interfejsów API REST i Azure SDKs. Jest także podstawą Foundry IQ — zarządzanej warstwy wiedzy, która przekształca treści przedsiębiorstwa w bazy wiedzy wielokrotnego użytku z uwzględnieniem uprawnień dla agentów w portalu Microsoft Foundry.
Ten artykuł zawiera odpowiedzi na często zadawane pytania dotyczące metryk magazynu, które są niespójne w witrynie Azure Portal, interfejsach API REST i zestawach SDK platformy Azure.
Dane z magazynu w usłudze Wyszukiwanie AI platformy Azure są zbierane okresowo i mogą nie odzwierciedlać stanu w czasie rzeczywistym. W związku z tym w większości scenariuszy oczekuje się krótkoterminowych rozbieżności.
Aby zapoznać się ze sposobem zbierania i raportowania metryk, zobacz Monitorowanie usługi Wyszukiwanie AI platformy Azure.
Dlaczego magazyn nie zmienia się natychmiast po usunięciu lub zaktualizowaniu dokumentów?
Po usunięciu dokumentów Wyszukiwanie AI platformy Azure natychmiast potwierdzi usunięcie, ale odzyskiwanie magazynu fizycznego odbywa się za pośrednictwem operacji scalania w tle. Dokument źródłowy jest oznaczony jako usunięty i pomijany podczas kolejnych zapytań. Wraz ze wzrostem indeksowania nowych dokumentów i wzrostu indeksu wewnętrznego system czyści usunięte dokumenty i odzyskuje zasoby. Oznacza to, że prawdopodobnie zauważysz opóźnienie między usuwaniem dokumentów a zwalnianiem zasobów bazowych.
Aktualizacje dokumentów mają podobny wpływ na przechowywanie. Ponieważ dokumenty są niezmienne, aktualizacja jest operacją usuwania i wstawiania: stara wersja jest oznaczona jako usunięta, a nowa wersja jest wstawiana. Dopóki operacje scalania w tle nie uporządkują starej wersji, możesz zauważyć, że przechowywanie tymczasowo się zwiększa, zamiast pozostawać na tym samym poziomie.
Te operacje scalania zwykle są wykonywane w ciągu od 24 do 72 godzin, w zależności od ilości obciążenia usługi. Jeśli zbliżasz się do limitu magazynu warstwy cenowej, należy uwzględnić ten tymczasowy wzrost podczas planowania aktualizacji na dużą skalę lub zamian dokumentów.
Aby uzyskać więcej informacji, zobacz Usuwanie dokumentów w indeksie wyszukiwania i Obciążenie związane z usuwaniem lub aktualizowaniem dokumentów w indeksie.
Dlaczego wartości portalu i interfejsu API różnią się w tym samym punkcie w czasie?
Witryna Azure Portal i interfejsy API REST mogą zgłaszać różne wartości, ponieważ mają różne cykle odświeżania. Specyficznie:
- Karta Użycie na stronie Przegląd portalu jest okresowo odświeżona, zazwyczaj co kilka minut.
-
Funkcja GET Service Statistics zwraca liczniki na poziomie usługi, w tym
storageSize,vectorIndexSizeidocumentCount. - Funkcja GET Index Statistics zwraca liczniki poszczególnych indeksów.
Statystyki na poziomie usług i na poziomie indeksu są zbierane niezależnie i w różnych odstępach czasu. Obraz z jednej powierzchni może nie być zgodny z obrazem z drugiej, jeśli nie uchwycono ich w tym samym czasie. To zachowanie jest normalne i nie wskazuje wady.
Aby uzyskać więcej informacji na temat powierzchni monitorowania, zobacz Monitorowanie usługi Wyszukiwanie AI platformy Azure.
Dlaczego ponownie utworzony indeks jest większy niż starszy indeks o podobnej zawartości?
Przebudowany indeks może tymczasowo wyświetlać inny profil wykorzystania pamięci masowej, ponieważ operacje scalania w tle nie zakończyły jeszcze usuwania starych wersji dokumentów. W zależności od obciążenia usługi te scalania zwykle trwa od 24 do 72 godzin. W tym okresie magazyn może wydawać się większy niż oczekiwano, co jest szczególnie ważne, jeśli zbliżasz się do limitu magazynu warstwy cenowej. Zaplanuj duże operacje ponownego kompilowania lub migracji w okresach mniejszej aktywności indeksowania i monitoruj metryki magazynu do momentu zakończenia scalania.
Nawet po zakończeniu operacji scalania ostateczny rozmiar przebudowanego indeksu może się nieznacznie różnić od oryginalnego. Rozmiar magazynu indeksu jest nieokreślony, a kilka czynników wpływa na wynik:
- Zmiany schematu, takie jak dodawanie pól, analizatorów lub konfiguracji wektorów.
- Wzorce pozyskiwania i aktualizacji, które wpływają na stosunek usuniętych dokumentów.
- Ustawienia optymalizacji wektorowej, takie jak kwantyzacja lub opcje redukcji pamięci.
Aby uzyskać więcej informacji na temat czynników wpływających na rozmiar, zobacz rozmiar indeksu wektorowego oraz limitylimity usług w Wyszukiwanie AI platformy Azure.
Dlaczego całkowita pamięć nie jest zgodna z rozmiarem indeksu wektora?
storageSize i vectorIndexSize mierz różne rzeczy:
-
storageSizeto całkowity ślad dysku indeksu, w tym zawartość wszystkich typów danych, takich jak tekst, metadane i wektory. -
vectorIndexSizeto limit rozmiaru indeksu wektorowego załadowanego do pamięci. Pola wektorów korzystające z wyczerpującego algorytmu KNN nie zużywają limitu indeksu wektorowego ani nie wykazują statusu zera dlavectorIndexSize. Aby uzyskać więcej informacji, zobacz Vector index size and limits (Rozmiar i limity indeksu wektorowego).
Na dysku łączna ilość miejsca używanego przez wektory może być większa niż rozmiar indeksu wektorów w pamięci, ponieważ usługa Wyszukiwanie AI platformy Azure przechowuje wiele kopii pól wektorów do różnych celów. Aby uzyskać informacje o tym, czym są te kopie i jak zmniejszyć użycie miejsca na dysku, zobacz Usuwanie opcjonalnych instancji wektorów z pamięci.
Jak prawidłowo porównać metryki?
Aby określić, czy rozbieżność jest rzeczywista, czy jest efektem czasowym, należy przechwytać wartości z tej samej powierzchni w spójnym przedziale czasu UTC.
- Wywołaj GET Service Statistics i GET Index Statistics w tym samym pięciominutowym oknie.
- Powtarzaj próbkowanie według stałej kadencji, na przykład co 20 do 30 minut.
- Porównaj co najmniej trzy kolejne okna przed stwierdzeniem, że wartości nie są zbieżne.
- Oceniaj
storageSizeoddzielnie odvectorIndexSize, ponieważ śledzą różne struktury fizyczne.
Kiedy jest oczekiwana rozbieżność w porównaniu z rzeczywistą wadą?
Większość rozbieżności jest oczekiwana i rozwiązana bez interwencji. Jeśli kryteria wad są spełnione, otwórz wniosek o pomoc techniczną z dowodami opisanymi w następnej sekcji.
Oczekiwana rozbieżność
- Ostatnio wykonano duże indeksowanie, aktualizacje lub usunięcia, a wartości są nadal zbieżne.
- Wartości portalu i interfejsu API różnią się, ale różnica zawęża się między powtarzającymi się przykładami.
-
storageSizeivectorIndexSizenie są zgodne, co jest zamierzonym efektem, ponieważ mierzą różne rzeczy.
Możliwa usterka
- Rozbieżność utrzymuje się w co najmniej trzech zsynchronizowanych oknach próbkowania pomiarowego podczas niewielkiej aktywności zapisu lub usuwania.
- Żaden trend zbieżności nie jest widoczny pomimo powtarzającego się próbkowania.
- Zgłoszone wartości prowadzą do nieprawidłowych decyzji operacyjnych, takich jak opóźnione wyzwalanie automatycznego skalowania lub niepowodzenia wymuszania limitu przydziału.
Co należy uwzględnić w żądaniu pomocy technicznej?
Dołącz następujące informacje do wniosku o pomoc techniczną:
- Znaczniki czasu UTC dla każdego portalu i przykładu interfejsu API.
- Nieprzetworzone odpowiedzi JSON z GET Service Statistics i GET Index Statistics.
- Przybliżone pozyskiwanie, aktualizowanie i usuwanie woluminu w okresie obserwacji.
- Opis wpływu operacyjnego, jak na przykład opóźnienie skalowania, blokada limitu przydziału lub błędne raportowanie pojemności.