Tabele wnioskowania na potrzeby monitorowania i debugowania modeli

W tym artykule opisano tabele wnioskowania dotyczące monitorowania obsługiwanych modeli. Na poniższym diagramie przedstawiono typowy przepływ pracy z tabelami wnioskowania. Tabela inferencyjna automatycznie przechwytuje przychodzące żądania i wychodzące odpowiedzi dla punktu końcowego modelu serwującego i rejestruje je jako tabela Delta w katalogu Unity. Dane w tej tabeli umożliwiają monitorowanie, debugowanie i ulepszanie modeli uczenia maszynowego.

Co to są tabele wnioskowania?

Monitorowanie wydajności modeli w przepływach pracy produkcyjnych jest ważnym aspektem cyklu życia modelu sztucznej inteligencji i uczenia maszynowego. Tabele wnioskowania upraszczają monitorowanie i diagnostykę modeli poprzez stałe logowanie danych wejściowych oraz odpowiedzi (przewidywań) z punktów końcowych usługi Mosaic AI Model Serving i ich zapisywanie do tabeli Delta w katalogu Unity. Następnie możesz użyć wszystkich funkcji platformy Databricks, takich jak zapytania SQL usługi Databricks, notesy i profilowanie danych, aby monitorować, debugować i optymalizować modele.

Tabele wnioskowania można włączyć dla dowolnego istniejącego lub nowo utworzonego punktu serwowania modelu, a żądania do tego punktu końcowego są następnie automatycznie rejestrowane w tabeli w UC.

Niektóre typowe aplikacje dla tabel wnioskowania są następujące:

• Monitorowanie jakości danych i modelu. Możesz stale monitorować wydajność i dryf danych modelu przy użyciu profilowania danych. Profilowanie danych automatycznie generuje pulpity nawigacyjne dotyczące jakości danych i modelu, które można udostępniać uczestnikom projektu. Ponadto możesz włączyć alerty, aby wiedzieć, kiedy trzeba ponownie trenować model na podstawie zmian danych przychodzących lub zmniejszenia wydajności modelu.
• Debugowanie problemów z produkcją. Dane rejestrowane przez tabele inferencji, takie jak kody statusu HTTP, czasy wykonywania modelu oraz kod JSON żądań i odpowiedzi. Te dane wydajności można używać do celów debugowania. Możesz również użyć danych historycznych w tabelach wnioskowania, aby porównać wydajność modelu z żądaniami historycznymi.
• Utwórz korpus treningowy. Łącząc tabele wnioskowania z etykietami podstawowych prawd, możesz utworzyć korpus szkoleniowy, którego można użyć do ponownego trenowania lub dostosowywania i ulepszania modelu. Za pomocą zadań Lakeflow można skonfigurować pętlę ciągłego feedbacku i zautomatyzować ponowne szkolenie.

Wymagania

• Obszar roboczy musi mieć włączony Unity Catalog.
• Zarówno twórca punktu końcowego, jak i modyfikator musi mieć uprawnienie Może zarządzać w punkcie końcowym. Zobacz Listy kontroli dostępu.
• Zarówno twórca punktu końcowego, jak i modyfikator muszą mieć następujące uprawnienia w katalogu Unity.
  • USE CATALOG uprawnienia do określonego katalogu.
  • USE SCHEMA uprawnienia do określonego schematu.
  • CREATE TABLE uprawnienia w schemacie.

Włączanie i wyłączanie tabel wnioskowania

W tej sekcji pokazano, jak włączyć lub wyłączyć tabele wnioskowania przy użyciu interfejsu użytkownika usługi Databricks. Możesz również użyć interfejsu API; Aby uzyskać instrukcje, zobacz Enable inference tables on model serving endpoints using the API (Włączanie tabel wnioskowania w modelu obsługujących punkty końcowe przy użyciu interfejsu API ).

Właścicielem tabel wnioskowania jest użytkownik, który utworzył punkt końcowy. Wszystkie listy kontroli dostępu (ACL) w tabeli są zgodne ze standardowymi uprawnieniami Unity Catalog i mogą być modyfikowane przez właściciela tabeli.

Aby włączyć tabele wnioskowania podczas tworzenia punktu końcowego, wykonaj następujące kroki:

1. Kliknij pozycję Obsługa w interfejsie użytkownika interfejsu sztucznej inteligencji mozaiki usługi Databricks.

2. Kliknij pozycję Utwórz obsługujący punkt końcowy.

3. Wybierz pozycję Włącz tabele wnioskowania.

4. W menu rozwijanych wybierz żądany wykaz i schemat, w którym ma znajdować się tabela.

   

5. Domyślna nazwa tabeli to <catalog>.<schema>.<endpoint-name>_payload. W razie potrzeby możesz wprowadzić niestandardowy prefiks tabeli.

6. Kliknij pozycję Utwórz obsługujący punkt końcowy.

Tabele wnioskowania można również włączyć w istniejącym punkcie końcowym. Aby edytować istniejącą konfigurację punktu końcowego, wykonaj następujące czynności:

1. Przejdź do strony punktu końcowego.
2. Kliknij pozycję Edytuj konfigurację.
3. Postępuj zgodnie z poprzednimi instrukcjami, zaczynając od kroku 3.
4. Po zakończeniu kliknij Aktualizuj punkt końcowy serwowania.

Postępuj zgodnie z tymi instrukcjami, aby wyłączyć tabele wnioskowania:

1. Przejdź do strony punktu końcowego.
2. Kliknij pozycję Edytuj konfigurację.
3. Kliknij Włącz tabelę wnioskowania, aby usunąć znacznik wyboru.
4. Po spełnieniu wymagań dotyczących specyfikacji punktu końcowego kliknij przycisk Aktualizuj.

Przepływ pracy: Monitorowanie wydajności modelu przy użyciu tabel wnioskowania

Aby monitorować wydajność modelu przy użyciu tabel wnioskowania, wykonaj następujące kroki:

1. Włącz tabele inferencyjne na swoim punkcie końcowym podczas jego tworzenia lub aktualizując go później.
2. Zaplanuj przepływ pracy, aby przetworzyć ładunki JSON w tabeli wnioskowania, rozpakując je zgodnie ze schematem punktu końcowego.
3. (Opcjonalnie) Dołącz rozpakowane żądania i odpowiedzi z etykietami rzeczywistości, aby możliwe było obliczanie metryk jakości modelu.
4. Utwórz monitor nad wynikową tabelą delty i odśwież metryki.

Notesy początkowe implementują ten przepływ pracy.

Notatnik startowy do monitorowania tabeli inferencyjnej

Poniższy notatnik implementuje kroki opisane powyżej, aby rozpakować żądania z tabeli analizy profilowania danych. Notatnik można uruchamiać zgodnie z harmonogramem cyklicznym lub na żądanie przy użyciu Lakeflow Jobs.

Notatnik startowy profilowania danych tabel wnioskowania

Pobierz laptopa

Notes początkowy do monitorowania jakości tekstu z punktów końcowych obsługujących usługi LLMs

Poniższy notes rozpakowuje żądania z tabeli wnioskowania, oblicza zestaw metryk oceny tekstu (takich jak czytelność i toksyczność) i umożliwia monitorowanie tych metryk. Notatnik można uruchamiać zgodnie z harmonogramem cyklicznym lub na żądanie przy użyciu Lakeflow Jobs.

Notes startowy do profilowania danych tabeli wnioskowej dla modelu LLM

Pobierz laptopa

Wykonywanie zapytań i analizowanie wyników w tabeli wnioskowania

Po dokonaniu gotowości obsługiwanych modeli wszystkie żądania wysyłane do modeli są rejestrowane automatycznie w tabeli wnioskowania wraz z odpowiedziami. Tabelę można wyświetlić w interfejsie użytkownika, wykonać zapytanie względem tabeli z bazy danych DBSQL lub notesu albo wykonać zapytanie względem tabeli przy użyciu interfejsu API REST.

Aby wyświetlić tabelę w interfejsie użytkownika: Na stronie punktu końcowego kliknij nazwę tabeli wnioskowania, aby otworzyć tabelę w Eksploratorze wykazu.

Aby wysłać zapytanie do tabeli z bazy danych DBSQL lub notesu usługi Databricks: Możesz uruchomić kod podobny do poniższego, aby wykonać zapytanie w tabeli wnioskowania.

SELECT * FROM <catalog>.<schema>.<payload_table>

Jeśli włączono tabele wnioskowania przy użyciu interfejsu użytkownika, payload_table to nazwa tabeli przypisana podczas tworzenia punktu końcowego. Jeśli włączono tabele wnioskowania przy użyciu interfejsu API, payload_table zostanie zgłoszone w state sekcji auto_capture_config odpowiedzi. Aby zapoznać się z przykładem, zobacz Włączanie tabel wnioskowania w modelu obsługujących punkty końcowe przy użyciu interfejsu API.

Uwaga dotycząca wydajności

Po wywołaniu punktu końcowego możesz zobaczyć wywołanie zarejestrowane w tabeli inferencji w ciągu godziny od wysłania żądania oceny. Ponadto usługa Azure Databricks gwarantuje, że dostarczanie dzienników odbywa się co najmniej raz, więc jest możliwe, choć mało prawdopodobne, że wysyłane są zduplikowane dzienniki.

Schemat tabeli katalogu Unity Catalog

Każde żądanie i odpowiedź, która jest rejestrowana w tabeli wnioskowania, jest zapisywana w tabeli delty przy użyciu następującego schematu:

Precyzować client_request_id

Pole client_request_id jest opcjonalną wartością, która użytkownik może podać w treści żądania obsługującego model. Dzięki temu użytkownik może podać swój własny identyfikator dla żądania, które jest wyświetlane w tabeli wyników wnioskowania w obszarze client_request_id i może służyć do łączenia żądania z innymi tabelami, które używają client_request_id, na przykład dołączania etykiety rzeczywistości. Aby określić element client_request_id, dołącz go jako klucz najwyższego poziomu ładunku żądania. Jeśli nie client_request_id zostanie określony, wartość będzie wyświetlana jako null w wierszu odpowiadającym żądaniu.

{
  "client_request_id": "<user-provided-id>",
  "dataframe_records": [
    {
      "sepal length (cm)": 5.1,
      "sepal width (cm)": 3.5,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.9,
      "sepal width (cm)": 3,
      "petal length (cm)": 1.4,
      "petal width (cm)": 0.2
    },
    {
      "sepal length (cm)": 4.7,
      "sepal width (cm)": 3.2,
      "petal length (cm)": 1.3,
      "petal width (cm)": 0.2
    }
  ]
}

Element client_request_id można później wykorzystać do łączenia etykiet z prawdziwymi danymi, jeśli istnieją inne tabele, które mają etykiety skojarzone z client_request_id.

Ograniczenia

• Klucze zarządzane przez klienta nie są obsługiwane.
• W przypadku punktów końcowych hostujących modele bazowe tabele inferencji są obsługiwane tylko w przypadku obciążeń zapewniających przepustowość.
• Usługa Azure Firewall może spowodować niepowodzenia w tworzeniu tabeli Delta usługi Unity Catalog, więc nie jest obsługiwana domyślnie. Skontaktuj się z zespołem konta usługi Databricks, aby go włączyć.
• Po włączeniu tabel wnioskowania limit całkowitej maksymalnej współbieżności we wszystkich obsługiwanych modelach w jednym punkcie końcowym wynosi 128. Skontaktuj się z zespołem konta usługi Azure Databricks, aby poprosić o zwiększenie tego limitu.
• Jeśli tabela wnioskowania zawiera więcej niż 500 000 plików, żadne dodatkowe dane nie są rejestrowane. Aby uniknąć przekroczenia tego limitu, uruchom OPTIMIZE lub skonfiguruj przechowywanie w tabeli, usuwając starsze dane. Aby sprawdzić liczbę plików w tabeli, uruchom polecenie DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• Dostarczanie dzienników tabel wnioskowania jest obecnie najlepszym rozwiązaniem, ale można oczekiwać, że dzienniki będą dostępne w ciągu 1 godziny od żądania. Skontaktuj się z zespołem kont usługi Databricks, aby uzyskać więcej informacji.

Aby uzyskać ogólne ograniczenia dotyczące obsługi punktów końcowych, zobacz Limity i regiony obsługi modeli.