Indeksowanie dużych zestawów danych w usłudze Wyszukiwanie AI platformy Azure

Uwaga

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.

Jeśli musisz indeksować duże lub złożone zestawy danych w rozwiązaniu wyszukiwania, w tym artykule omówiono strategie uwzględnienia długotrwałych procesów w usłudze Wyszukiwanie AI platformy Azure.

Te strategie zakładają znajomość dwóch podstawowych metod importowania danych: wypychania danych do indeksu lub ściągania danych z obsługiwanego źródła danych przy użyciu indeksatora wyszukiwania. Jeśli scenariusz obejmuje intensywne obliczeniowo wzbogacanie AI, indeksatory są wymagane, ze względu na zależność umiejętności od indeksatorów.

Ten artykuł uzupełnia porady dotyczące lepszej wydajności, która oferuje najlepsze rozwiązania dotyczące projektowania indeksów i zapytań. Dobrze zaprojektowany indeks zawierający tylko wymagane pola i atrybuty jest ważnym wymaganiem wstępnym dla indeksowania na dużą skalę.

Użyj usługi wyszukiwania utworzonej po 3 kwietnia 2024 r., aby korzystać z większej pojemności magazynowej na partycję. Możesz również zaktualizować starsze usługi, aby korzystać z większej pojemności partycji.

Uwaga

Strategie opisane w tym artykule zakładają pojedyncze duże źródło danych. Jeśli rozwiązanie wymaga indeksowania z wielu źródeł danych, zobacz Indeksowanie wielu źródeł danych w usłudze Wyszukiwanie AI platformy Azure , aby zapoznać się z zalecanym podejściem.

Indeksowanie danych przy użyciu interfejsów API typu push

API typu push, takie jak Documents Index REST API lub metoda IndexDocuments (Azure SDK dla platformy .NET), są najbardziej rozpowszechnioną formą indeksowania w usłudze Wyszukiwanie AI platformy Azure. W przypadku rozwiązań korzystających z interfejsu API wypychania strategia długotrwałego indeksowania może składać się z jednego lub obu z następujących składników:

  • Grupowanie dokumentów w partie
  • Zarządzanie wątkami

Grupuj wiele dokumentów na żądanie

Prostym mechanizmem indeksowania dużej ilości danych jest przesłanie wielu dokumentów lub rekordów w jednym żądaniu. Jeśli cały ładunek wynosi poniżej 16 MB, żądanie może obsłużyć maksymalnie 1000 dokumentów w operacji przekazywania zbiorczego. Te limity mają zastosowanie niezależnie od tego, czy używasz Documents Index REST API, czy IndexDocuments method w zestawie SDK platformy .NET. Przy użyciu dowolnego interfejsu API można spakować 1000 dokumentów w treści każdego żądania.

Przetwarzanie wsadowe dokumentów znacznie skraca czas potrzebny do pracy z dużą ilością danych. Określenie optymalnego rozmiaru partii danych jest kluczowym składnikiem optymalizacji szybkości indeksowania. Dwa podstawowe czynniki wpływające na optymalny rozmiar partii to:

  • Schemat twojego indeksu
  • Rozmiar danych

Ponieważ optymalny rozmiar partii zależy od indeksu i danych, najlepszym rozwiązaniem jest przetestowanie różnych rozmiarów partii w celu określenia, która z nich daje najszybszą szybkość indeksowania dla danego scenariusza. Aby uzyskać przykładowy kod do testowania rozmiarów partii przy użyciu .NET SDK, zobacz Samouczek: optymalizowanie indeksowania przy użyciu interfejsu API wypychania.

Zarządzanie wątkami i strategią ponawiania prób

Indeksatory mają wbudowane zarządzanie wątkami, ale w przypadku korzystania z API typu push kod aplikacji musi zarządzać wątkami. Upewnij się, że istnieją wystarczające wątki, aby w pełni korzystać z dostępnej pojemności, zwłaszcza jeśli niedawno uaktualniono usługę, przełączono się na wyższą warstwę cenową lub zwiększono partycje.

  1. Zwiększ liczbę współbieżnych wątków w kodzie klienta.

  2. Podczas zwiększania liczby żądań wysyłanych do usługi wyszukiwania mogą wystąpić kody stanu HTTP wskazujące, że żądanie nie zostało w pełni zrealizowane. Podczas indeksowania dwa typowe kody stanu HTTP to:

    • 503 Usługa niedostępna: ten błąd oznacza, że system jest obciążony dużym obciążeniem i nie można w tej chwili przetworzyć żądania.

    • 207 Wielo-stan: ten błąd oznacza, że niektóre dokumenty zakończyły się sukcesem, ale przynajmniej jeden dokument nie powiódł się.

  3. Aby obsłużyć błędy, żądania powinny być ponawiane z zastosowaniem strategii wykładniczego wycofywania.

Azure .NET SDK automatycznie ponawia próby dla kodów 503 i innych nieudanych żądań, ale musisz zaimplementować własną logikę, aby ponawiać próby dla kodów 207. Narzędzia typu open source, takie jak Polly , mogą również służyć do implementowania strategii ponawiania prób.

Użyj indeksatorów i interfejsów API pobierania

Indeksatory oferują kilka funkcji, które są przydatne w przypadku długotrwałych procesów:

  • Grupowanie dokumentów w partie
  • Równoległe indeksowanie danych partycjonowanych
  • Planowanie i wykrywanie zmian na potrzeby indeksowania tylko nowych i zmienionych dokumentów w czasie

Harmonogramy indeksatora mogą wznowić przetwarzanie w ostatnim znanym punkcie zatrzymania. Jeśli dane nie zostaną w pełni zindeksowane w przewidzianym oknie przetwarzania, indeksator wznowi pracę od miejsca, w którym ją przerwał, podczas następnego uruchomienia, o ile używasz źródła danych, które obsługuje wykrywanie zmian.

Partycjonowanie danych na mniejsze pojedyncze źródła danych umożliwia przetwarzanie równoległe. Możesz podzielić dane źródłowe, takie jak na wiele kontenerów w usłudze Azure Blob Storage, utworzyć źródło danych dla każdej partycji, a następnie uruchomić indeksatory równolegle, pod kątem liczby jednostek wyszukiwania usługi wyszukiwania.

Sprawdź rozmiar partii indeksatora

Podobnie jak w przypadku interfejsu API wypychania indeksatory umożliwiają skonfigurowanie liczby elementów na partię. W przypadku indeksatorów opartych na interfejsie API REST Create Indexer ustaw argument batchSize, aby dostosować to ustawienie tak, by lepiej odpowiadało charakterystyce danych.

Domyślne rozmiary partii są specyficzne dla źródła danych. Usługi Azure SQL Database i Azure Cosmos DB mają domyślny rozmiar partii 1000. Natomiast indeksowanie usługi Azure Blob i programu SharePoint (wersja zapoznawcza) ustawia wielkość partii na 10 dokumentów ze względu na większy średni rozmiar dokumentów.

Planowanie indeksatorów dla długotrwałych procesów

Planowanie indeksatora to ważny mechanizm przetwarzania dużych zestawów danych i obsługi procesów wolno działających, takich jak analiza obrazu w potoku wzbogacania.

Zazwyczaj przetwarzanie indeksatora jest uruchamiane w ciągu dwóch godzin. Jeśli obciążenie pracą indeksowania zajmuje dni zamiast godzin, można ustawić indeksator na kolejny, cykliczny harmonogram, który będzie się rozpoczynał co dwie godziny. Zakładając, że źródło danych ma włączone śledzenie zmian, indeksator wznawia przetwarzanie, w którym ostatnio zostało przerwane. W tym tempie indeksator może przechodzić przez zaległości dokumentów w ciągu kilku dni, aż wszystkie zaległe dokumenty zostaną przetworzone. Ten wzorzec jest szczególnie ważny podczas początkowego uruchomienia lub podczas indeksowania dużych kontenerów obiektów blob, w których sama faza wyświetlania listy obiektów blob może potrwać wiele godzin lub dni. W tym czasie indeksator nie pokazuje, że przetwarzane są jakiekolwiek obiekty blob, ale jeśli nie zostanie zgłoszony błąd, prawdopodobnie nadal przechodzi przez listę obiektów blob. Przetwarzanie dokumentów i wzbogacanie zaczynają się dopiero po zakończeniu tej fazy, a to zachowanie jest oczekiwane.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Jeśli nie ma już żadnych nowych lub zaktualizowanych dokumentów w źródle danych, raporty z historii wykonywania indeksatora wykazują 0/0 przetworzonych dokumentów, a przetwarzanie nie występuje.

Aby uzyskać więcej informacji na temat ustawiania harmonogramów, zobacz Tworzenie interfejsu API REST indeksatora lub Planowanie indeksatorów dla usługi Wyszukiwanie AI platformy Azure.

Uwaga

Maksymalne okno przetwarzania zależy od tego, czy indeksator ma zestaw umiejętności. Indeksatory z zestawami umiejętności są uruchamiane w wewnętrznie zarządzanym środowisku wielodzierżawnym z maksymalnym limitem 2 godzin. Indeksatory skonfigurowane do korzystania z współużytkowanych łączy prywatnych mają maksymalny czas działania wynoszący 24 godziny. Indeksatory bez zestawów umiejętności mogą działać maksymalnie przez 24 godziny.

Jeśli indeksator korzysta z zestawu umiejętności z buforowaniem wzbogacania danych, przed włączeniem pamięci podręcznej w przypadku obciążeń na dużą skalę zapoznaj się z poniższymi informacjami.

Caution

W przypadku obciążeń z umiejętnościami działającymi przez długi czas, powtarzającymi się przerwami lub częstymi niepowodzeniami pamięć podręczna wzbogacania może zwiększyć łączny zakres ponownego przetwarzania podczas początkowego pozyskiwania danych lub odzyskiwania po awarii. Pamięć podręczna wzbogacania danych nie jest kopią zapasową i nie śledzi, które dokumenty zostały już przetworzone.

Równoległe uruchamianie indeksatorów

W przypadku partycjonowania danych można utworzyć wiele kombinacji indeksatora-źródła danych, które ściągają z każdego źródła danych i zapisują je w tym samym indeksie wyszukiwania. Ponieważ każdy indeksator jest odrębny, można uruchomić je w tym samym czasie, dzięki czemu indeks wyszukiwania jest wypełniany szybciej, niż w przypadku sekwencyjnie uruchomionych.

Upewnij się, że masz wystarczającą pojemność. Jedna jednostka wyszukiwania w usłudze może uruchamiać jeden indeksator w danym momencie. Tworzenie wielu indeksatorów jest przydatne tylko wtedy, gdy mogą działać równolegle.

Liczba zadań indeksowania, które mogą być uruchamiane jednocześnie, różni się w przypadku indeksowania opartego na tekście i umiejętnościach. Aby uzyskać więcej informacji, zobacz Wykonywanie indeksatora.

Jeśli źródło danych jest kontenerem usługi Azure Blob Storage lub usługą Azure Data Lake Storage Gen 2, wyliczanie dużej liczby obiektów blob może zająć dużo czasu (nawet godzin), dopóki ta operacja nie zostanie ukończona. W związku z tym może się wydawać, że liczba dokumentów przetworzonych pomyślnie przez indeksator w tym czasie nie rośnie i że nie robi on żadnych postępów, choć w rzeczywistości tak jest. Jeśli chcesz, aby przetwarzanie dokumentów przebiegało szybciej dla dużej liczby obiektów blob, rozważ podzielenie danych na wiele kontenerów i utworzenie równoległych indeksatorów wskazujących na jeden indeks.

  1. Przejdź do usługi wyszukiwania w witrynie Azure Portal.

  2. Sprawdź liczbę jednostek wyszukiwania używanych przez usługę wyszukiwania. Wybierz Ustawienia>Skala, aby wyświetlić liczbę w górnej części strony. Liczba indeksatorów uruchamianych równolegle jest w przybliżeniu równa liczbie jednostek wyszukiwania.

  3. Partycjonowanie danych źródłowych między wieloma kontenerami lub wieloma folderami wirtualnymi wewnątrz tego samego kontenera.

  4. Utwórz wiele źródeł danych, po jednym dla każdej partycji, sparowanych z własnym indeksatorem.

  5. Określ ten sam docelowy indeks wyszukiwania w każdym indeksatorze.

  6. Zaplanuj indeksatory.

  7. Przejrzyj stan indeksatora i historię wykonywania w celu potwierdzenia.

Istnieje pewne ryzyko związane z indeksowaniem równoległym. Po pierwsze, należy pamiętać, że indeksowanie nie działa w tle, co zwiększa prawdopodobieństwo, że zapytania będą ograniczane lub odrzucane.

Po drugie usługa Wyszukiwanie AI platformy Azure nie blokuje indeksu aktualizacji. Współbieżne operacje zapisu są obsługiwane przez ponowienie próby, jeśli dana operacja zapisu nie powiedzie się przy pierwszej próbie, ale możesz zauważyć wzrost liczby błędów indeksowania.

Mimo że wiele zestawów indeksatora-źródła danych może być przeznaczonych dla tego samego indeksu, należy zachować ostrożność podczas uruchamiania indeksatora, który może zastąpić istniejące wartości w indeksie. Jeśli drugi indeksator-źródło danych jest przeznaczony dla tych samych dokumentów i pól, wszystkie wartości z pierwszego uruchomienia zostaną zastąpione. Wartości pól są zastępowane w całości; indeksator nie może scalić wartości z wielu przebiegów do tego samego pola.

Indeksowanie danych big data na platformie Spark

Jeśli masz architekturę danych big data i dane są w klastrze Spark, użyj usługi SynapseML do ładowania i indeksowania danych. Samouczek zawiera kroki użycia narzędzi Foundry Tools for AI do wzbogacania danych, ale można również użyć interfejsu API AzureSearchWriter do indeksowania tekstu.

Powiązana zawartość

  • Last updated on