Udostępnij za pośrednictwem

Wnioskowanie tables na potrzeby monitorowania i debugowania modeli

  • Artykuł

Ważne

Ta funkcja jest dostępna w publicznej wersji zapoznawczej.

Ważne

W tym artykule opisano tematy dotyczące wnioskowania tables dla modeli niestandardowych . W przypadku modeli zewnętrznych lub obciążeń z aprowizowaną przepływnością należy użyć wnioskowania obsługiwanego przez Bramę Sztucznej Inteligencji tables.

W tym artykule opisano wnioskowanie tables na potrzeby monitorowania obsługiwanych modeli. Na poniższym diagramie przedstawiono typowy przepływ pracy z wnioskowaniem tables. Wnioskowanie table automatycznie przechwytuje przychodzące żądania i wychodzące odpowiedzi dla punktu końcowego obsługującego model i rejestruje je jako Delta Catalog Unity table. Dane w tym table umożliwiają monitorowanie, debugowanie i ulepszanie modeli uczenia maszynowego.

przepływ pracy wnioskowania tables

Czym jest wnioskowanie tables?

Monitorowanie wydajności modeli w przepływach pracy produkcyjnych jest ważnym aspektem cyklu życia modelu sztucznej inteligencji i uczenia maszynowego. Inferencja tables ułatwia monitorowanie i diagnostykę modeli przez ciągłe rejestrowanie danych wejściowych i odpowiedzi (przewidywań) żądań obsługujących z punktów końcowych Mosaic AI Model Serving i zapisywanie ich w Delta table w Unity Catalog. Następnie możesz użyć wszystkich możliwości platformy Databricks, takich jak zapytania SQL usługi Databricks, notesy i monitorowanie usługi Lakehouse, aby monitorować, debugować i optimize modele.

Możesz włączyć wnioskowanie tables dla dowolnego istniejącego lub nowo utworzonego punktu końcowego do obsługi modelu, a żądania do tego punktu końcowego są automatycznie rejestrowane w table w UC.

Niektóre typowe zastosowania wnioskowania tables są następujące:

  • Monitorowanie jakości danych i modelu. Możesz stale monitorować wydajność i dryf danych modelu przy użyciu monitorowania usługi Lakehouse. Monitorowanie usługi Lakehouse 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 dziennika związane z wnioskowaniem Tables, takie jak kody stanu HTTP, czasy wykonywania modelu oraz kod JSON żądania i odpowiedzi. Te dane wydajności można używać do celów debugowania. Możesz również użyć danych historycznych w wnioskowaniu Tables, aby porównać wydajność modelu w odniesieniu do żądań historycznych.
  • Utwórz korpus treningowy. Łącząc wnioskowanie Tables z etykietami podstawowych prawdy, można utworzyć korpus szkoleniowy, którego można użyć do ponownego trenowania lub dostosowywania i ulepszania modelu. Za pomocą zadań usługi Databricks można set pętli ciągłej opinii i automatyzować ponowne trenowanie.

Wymagania

  • Twój obszar roboczy musi mieć włączoną funkcję 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 Catalogaparatu Unity:
    • USE CATALOG uprawnienia do określonego catalog.
    • USE SCHEMA uprawnienia do określonego schema.
    • CREATE TABLE uprawnienia w schema.

Włączanie i wyłączanie wnioskowania tables

W tej sekcji pokazano, jak włączyć lub wyłączyć wnioskowanie tables przy użyciu interfejsu użytkownika usługi Databricks. Możesz również użyć interfejsu API. Aby uzyskać instrukcje, zobacz Włącz wnioskowanie tables na punktach końcowych obsługujących model przy użyciu interfejsu API.

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

Ostrzeżenie

Wnioskowanie table może ulec uszkodzeniu, jeśli wykonasz dowolną z następujących czynności:

  • Zmień tableschema.
  • Zmień nazwę table.
  • Usuń table.
  • Utracić uprawnienia do Unity Catalog,catalog lub schema.

W tym przypadku auto_capture_config stanu punktu końcowego pokazuje stan FAILED ładunku table. W takim przypadku należy utworzyć nowy punkt końcowy, aby nadal korzystać z wnioskowania tables.

Aby włączyć wnioskowanie tables 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. Select Włącz wnioskowanie tables.

  4. W menu rozwijanych select żądanych catalog i schemawhere chcesz, aby table znajdowała się.

    catalog i schema na potrzeby wnioskowania table

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

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

Możesz również włączyć wnioskowanie tables 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 pozycję Update obsługującego punkt końcowy.

Postępuj zgodnie z tymi instrukcjami, aby wyłączyć wnioskowanie tables:

  1. Przejdź do strony punktu końcowego.
  2. Kliknij pozycję Edytuj konfigurację.
  3. Kliknij pozycję Włącz wnioskowanie table, aby remove znacznik wyboru.
  4. Kiedy będziesz zadowolony ze specyfikacji punktu końcowego, kliknij Update.

przepływ pracy : monitorowanie wydajności modelu przy użyciu wnioskowania tables

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

  1. Włącz wnioskowanie tables na swoim punkcie końcowym, podczas jego tworzenia lub poprzez późniejszą aktualizację.
  2. Zaplanuj przepływ pracy, aby przetworzyć ładunki JSON-owe w wnioskowaniu table, rozpakowując je zgodnie z procedurą schema punktu końcowego.
  3. (Opcjonalnie) Join rozpakowanych żądań i odpowiedzi z etykietami ground-truth, aby umożliwić obliczanie metryk jakości modelu.
  4. Utwórz monitor dla metryk Delta table i refresh, które powstały.

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

Notatnik początkowy do monitorowania wnioskowania table

Poniższy zeszyt implementuje kroki opisane powyżej w celu rozpakowywania żądań z wnioskowania w systemie Lakehouse Monitoring table. Notes można uruchamiać na żądanie lub zgodnie z harmonogramem cyklicznym przy użyciu zadań usługi Databricks.

Notebook startowy monitorowania Lakehouse table

Get notesu

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

Poniższy notebook rozpakowuje żądania z procesu wnioskowania table, oblicza zestaw set metryk oceny tekstu (takich jak czytelność i toksyczność) i umożliwia monitorowanie danych tych metryk. Notes można uruchamiać na żądanie lub zgodnie z harmonogramem cyklicznym przy użyciu zadań usługi Databricks.

Wnioskowanie LLM table notatnik startowy monitorowanie Lakehouse

Get notesu

Analizowanie wyników zapytań w kontekście wnioskowania table

Po przygotowaniu obsługiwanych modeli wszystkie żądania wysyłane do modeli są automatycznie rejestrowane w dzienniku tablewnioskowań wraz z odpowiedziami. Możesz wyświetlić table w interfejsie użytkownika, wykonać zapytanie dotyczące table z bazy danych DBSQL lub notesu albo wykonać zapytanie dotyczące table przy użyciu interfejsu API REST.

Aby wyświetlić table w interfejsie użytkownika: Na stronie punktu końcowego kliknij nazwę wnioskowania table, aby otworzyć table w eksploratorze Catalog.

link do nazwy wnioskowania table na stronie punktu końcowego

Aby wykonać zapytanie dotyczące table z bazy danych DBSQL lub notesu usługi Databricks: Możesz uruchomić kod podobny do poniższego, aby wykonać zapytanie dotyczące wnioskowania table.

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

Jeśli włączono wnioskowanie tables przy użyciu interfejsu użytkownika, payload_table jest nazwą table przypisaną podczas tworzenia punktu końcowego. Jeśli włączono wnioskowanie tables przy użyciu interfejsu API, payload_table jest raportowany w sekcji state odpowiedzi auto_capture_config. Aby zapoznać się z przykładem, zobacz Włącz inferencję tables na punktach końcowych modelu obsługi przy użyciu interfejsu API.

Uwaga dotycząca wydajności

Po wywołaniu punktu końcowego zobaczysz wywołanie zarejestrowane w wnioskowaniu table w ciągu godziny od wysłania żądania oceniania. 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.

Unity Catalog wnioskowania tableschema

Każde żądanie i każda odpowiedź, które są rejestrowane w elemencie wnioskowania table, są zapisywane do Delta table według następujących schema:

Uwaga

Jeśli wywołasz punkt końcowy z partią danych wejściowych, cała partia zostanie zarejestrowana jako jeden wiersz.

nazwa Column opis Type
databricks_request_id Żądanie identifier wygenerowane przez Azure Databricks zostało dołączone do wszystkich żądań obsługi modelu. STRUNA
client_request_id Opcjonalny klient wygenerował żądanie identifier, które można określić w treści żądania obsługującego model. Zobacz Określanie client_request_id , aby uzyskać więcej informacji. STRUNA
date Data UTC, w której odebrano żądanie obsługi modelu. DATE
timestamp_ms Sygnatura czasowa w milisekundach epoki po odebraniu żądania obsługi modelu. DŁUGI
status_code Kod stanu HTTP zwrócony z modelu. INT
sampling_fraction Ułamek próbkowania używany w przypadku, gdy żądanie zostało próbkowane w dół. Ta wartość wynosi od 0 do 1, where 1 oznacza, że uwzględniono 100% żądań przychodzących. PODWÓJNY
execution_time_ms Czas wykonywania w milisekundach, dla których model wykonał wnioskowanie. Nie obejmuje to opóźnień sieciowych wynikających z narzutów i reprezentuje tylko czas, jaki zajęło modelowi generate przewidywanie. DŁUGI
request Treść nieprzetworzonego żądania JSON, która została wysłana do punktu końcowego obsługującego model. STRUNA
response Treść nieprzetworzonej odpowiedzi JSON zwrócona przez punkt końcowy obsługujący model. STRUNA
request_metadata Mapa metadanych związanych z modelem obsługującym punkt końcowy skojarzony z żądaniem. Ta mapa zawiera nazwę punktu końcowego, nazwę modelu i wersję modelu używaną dla punktu końcowego. CIĄG MAPY<, CIĄG>

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ć własne identifier dla żądania, które jest wyświetlane w finalnym wnioskowaniu table w ramach client_request_id i może służyć do łączenia żądania z innymi tables, które używają client_request_id, takimi jak łączenie z etykietą prawdy podstawowej. 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
    }
  ]
}

client_request_id można później użyć do połączeń etykiet odniesienia, jeśli istnieją inne tables, które mają etykiety powiązane z client_request_id.

Ograniczenia

  • Klucze zarządzane przez klienta nie są obsługiwane.
  • W przypadku punktów końcowych hostujących modele fundamentów , wnioskowanie jest obsługiwane tylko w przypadku obciążeń o zaprojektowanej przepustowości .
  • Usługa Azure Firewall może powodować błędy podczas tworzenia Unity Catalog Delta table, dlatego nie jest domyślnie obsługiwana. Skontaktuj się z zespołem konta usługi Databricks, aby go włączyć.
  • Gdy tables wnioskowania są włączone, limit łączna maksymalna współbieżność we wszystkich obsługiwanych modelach w jednym punkcie końcowym wynosi 128. Skontaktuj się z zespołem swojego konta Azure Databricks, aby poprosić o zwiększenie tej wartości limit.
  • Jeśli wnioskowanie table zawiera więcej niż 500 000 plików, żadne dodatkowe dane nie są rejestrowane. Aby uniknąć przekroczenia tego limit, uruchom OPTIMIZE lub set przechowywanie na table, usuwając starsze dane. Aby sprawdzić liczbę plików w table, uruchom DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
  • Obecnie dostarczanie dzienników dla wnioskowania tables odbywa się na zasadzie najlepszych starań; jednak można oczekiwać, że będą dostępne w ciągu godziny od złożenia żą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.