Inferenza tables per il monitoraggio e il debug dei modelli

Importante

Questa funzionalità è disponibile in anteprima pubblica.

Questo articolo descrive l'inferenza tables per il monitoraggio dei modelli serviti. Il diagramma seguente illustra un flusso di lavoro tipico con inferenza tables. L'inferenza table acquisisce automaticamente le richieste in ingresso e le risposte in uscita per un endpoint che serve un modello e le registra come Delta di Unity Catalogtable. È possibile usare i dati in questa table per monitorare, eseguire il debug e migliorare i modelli di Machine Learning.

Per la gestione di endpoint che ospitano modelli esterni, è possibile abilitare solo abilitare l'inferenza tables usando il gateway di intelligenza artificiale.

Cosa sono le tablesinferenze?

Il monitoraggio delle prestazioni dei modelli nei flussi di lavoro di produzione è un aspetto importante del ciclo di vita del modello di Intelligenza artificiale e Machine Learning. L'inferenza tables semplifica il monitoraggio e la diagnostica per i modelli registrando continuamente gli input delle richieste e le risposte (stime) dagli endpoint di Mosaic AI Model Serving e salvandoli in un Delta table in Unity Catalog. È quindi possibile usare tutte le funzionalità della piattaforma Databricks, ad esempio Databricks SQL queries, notebook e Lakehouse Monitoring per monitorare, eseguire il debug e optimize i modelli.

È possibile abilitare l'inferenza tables in qualsiasi endpoint del modello esistente o appena creato e le richieste a tale endpoint vengono quindi registrate automaticamente in un table in UC.

Di seguito sono riportate alcune applicazioni comuni per l'inferenza tables:

• Monitorare i dati e la qualità del modello. È possibile monitorare continuamente le prestazioni del modello e la deriva dei dati usando Lakehouse Monitoring. Lakehouse Monitoring genera automaticamente dashboard di qualità dei dati e dei modelli che è possibile condividere con gli stakeholder. Inoltre, è possibile abilitare gli avvisi per sapere quando è necessario ripetere il training del modello in base ai turni nei dati in ingresso o a riduzioni delle prestazioni del modello.
• Eseguire il debug dei problemi di produzione. L'inferenza dei dati di log Tables, come i codici di stato HTTP, i tempi di esecuzione del modello e il codice JSON di richiesta e risposta. È possibile usare questi dati sulle prestazioni a scopo di debug. È anche possibile usare i dati cronologici in Inference Tables per confrontare le prestazioni del modello sulle richieste cronologiche.
• Creare un corpus per il training. Unendo inferenza Tables con etichette di verità di base, è possibile creare un corpus di training che è possibile usare per eseguire nuovamente il training o ottimizzare e migliorare il modello. Usando i processi di Databricks, è possibile set un ciclo di feedback continuo e automatizzare il nuovo training.

Requisiti

• Unity Catalog deve essere abilitato per l'area di lavoro.
• Sia l'autore dell'endpoint che il modificatore devono disporre dell'autorizzazione Gestisci per l'endpoint. Consultare Elenchi di controllo di accesso.
• Sia l'autore dell'endpoint sia il modificatore devono possedere le seguenti autorizzazioni in Unity Catalog:
  • USE CATALOG autorizzazioni per il catalogspecificato.
  • USE SCHEMA autorizzazioni per il schemaspecificato.
  • CREATE TABLE autorizzazioni nel schema.

Abilitare e disabilitare l'inferenza tables

Questa sezione illustra come abilitare o disabilitare l'inferenza tables usando l'interfaccia utente di Databricks. È anche possibile usare l'API; Per istruzioni, vedere Abilitare l'inferenza tables sui modelli che servono gli endpoint usando l'API.

Il proprietario dell'inferenza tables è l'utente che ha creato l'endpoint. Tutti gli elenchi di controllo di accesso (ACL) nel table seguono le autorizzazioni standard di Unity Catalog e possono essere modificati dal proprietario del table.

Avviso

L'inferenza table potrebbe essere danneggiata se si esegue una delle operazioni seguenti:

• Cambia il tableschema.
• Modifica il nome table.
• Eliminare il table.
• Perdono i permessi per Unity Catalog,catalog o schema.

In questo caso, il auto_capture_config dello stato dell'endpoint mostra uno stato FAILED per il payload table. In questo caso, è necessario creare un nuovo endpoint per continuare a usare l'inferenza tables.

Per abilitare l'inferenza tables durante la creazione dell'endpoint, seguire questa procedura:

1. Cliccare Serving nell'interfaccia utente IA di Databricks Mosaic.

2. Cliccare Crea l'endpoint di servizio.

3. Select Abilitare l'inferenza tables.

4. Nei menu a discesa select il catalog desiderato e schemawhere si desidera che si trovi il table.

   

5. Il nome table predefinito è <catalog>.<schema>.<endpoint-name>_payload. Se lo si desidera, è possibile immettere un prefisso personalizzato table.

6. Cliccare Crea l'endpoint di servizio.

È anche possibile abilitare l'inferenza tables in un endpoint esistente. Per modificare una configurazione dell'endpoint esistente, eseguire le seguenti operazioni:

1. Passare alla pagina dell'endpoint.
2. Cliccare Modifica configurazione.
3. Seguire le istruzioni precedenti, a partire dal passaggio 3.
4. Al termine, fare clic su Update endpoint di servizio.

Seguire queste istruzioni per disabilitare l'inferenza tables:

1. Passare alla pagina dell'endpoint.
2. Cliccare Modifica configurazione.
3. Fare clic su Abilita inferenza table per remove il segno di spunta.
4. Una volta accertate le specifiche dell'endpoint, fare clic su Update.

flusso di lavoro : monitorare le prestazioni del modello usando l'inferenza tables

Per monitorare le prestazioni del modello usando l'inferenza tables, seguire questa procedura:

1. Abilitare inferenza tables nell'endpoint, durante la creazione dell'endpoint o aggiornandola in seguito.
2. Pianificare un flusso di lavoro per elaborare i payload JSON nell'inferenza table decomprimendoli in base al schema dell'endpoint.
3. (Facoltativo) Join le richieste e le risposte decompresse con etichette di veridicità per consentire il calcolo delle metriche di qualità del modello.
4. Crea un monitoraggio sulle metriche risultanti del Delta table e refresh.

I notebook di avvio implementano questo flusso di lavoro.

Taccuino di avvio per il monitoraggio di un modello di inferenza table

Il seguente notebook implementa i passaggi descritti in precedenza per elaborare le richieste dal sistema di inferenza di Lakehouse Monitoring table. Il notebook può essere eseguito su richiesta o su una pianificazione ricorrente usando Databricks Jobs.

Notebook iniziale di inferenza table Lakehouse Monitoring

Get taccuino

Notebook di avvio per il monitoraggio della qualità del testo dagli endpoint che servono LLM

Il notebook seguente decomprime le richieste da un'inferenza table, calcola un set di metriche di valutazione del testo (ad esempio leggibilità e tossicità) e abilita il monitoraggio su queste metriche. Il notebook può essere eseguito su richiesta o su una pianificazione ricorrente usando Databricks Jobs.

Notebook iniziale di inferenza LLM table Lakehouse Monitoring

Get portatile

Effettuare query e analizzare i risultati nel processo di inferenza table

Dopo che i modelli serviti sono pronti, tutte le richieste effettuate ai modelli vengono registrate automaticamente nell'inferenza table, insieme alle risposte. È possibile visualizzare il table nell'interfaccia utente, eseguire una query sul table da DBSQL o da un notebook oppure eseguire una query sul table usando l'API REST.

Per visualizzare il table nell'interfaccia utente: Nella pagina dell'endpoint fare clic sul nome dell'inferenza table per aprire il table in Esplora Catalog.

Per eseguire una query sul table da DBSQL o da un notebook di Databricks: è possibile eseguire codice simile al seguente per eseguire una query sull'inferenza table.

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

Se hai abilitato l'inferenza tables utilizzando la UI, payload_table è il nome table che hai assegnato quando hai creato l'endpoint. Se è stata abilitata l'inferenza tables usando l'API, payload_table viene segnalata nella sezione state della risposta auto_capture_config. Per un esempio, vedere Abilitare l'inferenza tables sui modelli che servono gli endpoint usando l'API.

Note relative alle prestazioni

Dopo aver richiamato l'endpoint, è possibile visualizzare la chiamata registrata all'inferenza table entro un'ora dall'invio di una richiesta di assegnazione dei punteggi. Inoltre, Azure Databricks garantisce che il recapito dei log avvenga almeno una volta, quindi è possibile, anche se improbabile, che vengano inviati log duplicati.

table schema inferenza di Unity Catalog

Ogni richiesta e risposta registrata in un'inferenza table viene scritta in un Delta table con il seguente schema:

Nota

Se si richiama l'endpoint con un batch di input, l'intero batch viene registrato come una riga.

nome Column	Descrizione	Tipo
databricks_request_id	Una richiesta generata da Azure Databricks identifier è allegata a tutte le richieste di servizio del modello.	STRING
client_request_id	Un client facoltativo ha generato una richiesta identifier che può essere specificata nel corpo della richiesta del modello. Per altre informazioni, consultareIdentificatori di tipiclient_request_id.	STRING
date	Data UTC in cui è stata ricevuta la richiesta di gestione del modello.	DATE
timestamp_ms	Timestamp in millisecondi di periodo in cui è stata ricevuta la richiesta di gestione del modello.	LONG
status_code	Codice di stato HTTP restituito dal proxy.	INT
sampling_fraction	Frazione di campionamento utilizzata nel caso in cui la richiesta sia stata campionata. Questo valore è compreso tra 0 e 1, where 1 indica che sono stati inclusi 100% di richieste in ingresso.	DOUBLE
execution_time_ms	Tempo di esecuzione in millisecondi per il quale il modello ha eseguito l'inferenza. Ciò non include latenze di rete sovraccariche e rappresenta solo il tempo necessario per il modello per generate stime.	LONG
request	Corpo JSON della richiesta non elaborato e inviato all'endpoint di gestione del modello.	STRING
response	Corpo JSON della risposta non elaborata e restituito dall'endpoint di gestione del modello.	STRING
request_metadata	Mappa dei metadati correlati all'endpoint di gestione del modello associato alla richiesta. Questa mappa contiene il nome dell'endpoint, il nome del modello e la versione del modello usati per l'endpoint.	MAP<STRING, STRING>

Identificaclient_request_id

Il client_request_id campo è un valore facoltativo che l'utente può fornire nel corpo della richiesta di gestione del modello. In questo modo l'utente può fornire il proprio identifier per una richiesta che appare nell'inferenza finale table sotto il client_request_id e può essere utilizzata per collegare la richiesta ad altri tables che utilizzano il client_request_id, come ad esempio l'unione delle etichette di verità di base. Per identificare un client_request_id , includerlo come chiave di primo livello del payload della richiesta. Se non viene specificato alcun valore client_request_id, il valore viene visualizzato come nullo nella riga corrispondente alla richiesta.

{
  "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
    }
  ]
}

Il client_request_id può essere usato in un secondo momento per i join di etichette di verità di base se sono presenti altri tables con etichette associate all'client_request_id.

Limiti

• Le chiavi gestite dal cliente (CMK) non sono supportate.
• Per gli endpoint che ospitano modelli di base , le tables di inferenza sono supportate solo nei carichi di lavoro di velocità effettiva con provisioning.
• Azure Firewall può causare errori durante la creazione di Unity Catalog Delta table, pertanto non è supportato per impostazione predefinita. Contattare il team dell'account Databricks per abilitarlo.
• Quando l'inferenza tables è abilitata, il limit per la concorrenza massima totale in tutti i modelli serviti in un singolo endpoint è 128. Contatta il team del vostro account Azure Databricks per richiedere un aumento di questo limit.
• Se un'inferenza table contiene più di 500.000 file, non vengono registrati dati aggiuntivi. Per evitare di superare questo limit, esegui OPTIMIZE o set per aumentare la conservazione nei table eliminando i dati meno recenti. Per controllare il numero di file nel table, esegui il comando DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• L'inferenza tables relativa al recapito dei log è attualmente a migliore sforzo, ma puoi aspettarti che i log siano disponibili entro 1 ora dalla richiesta. Per maggiori informazioni, contattare il team dell'account Databricks.

Per informazioni generali sulle limitazioni degli endpoint, consultare Limiti e aree di Model Serving.