Tabelle di inferenza per il monitoraggio e il debug dei modelli

Importante

Questa funzionalità è disponibile in anteprima pubblica.

Importante

Questo articolo descrive gli argomenti applicabili alle tabelle di inferenza per modelli personalizzati. Per i modelli esterni o i carichi di lavoro con throughput provisionato, usare tabelle di inferenza abilitate al gateway di intelligenza artificiale.

Questo articolo descrive le tabelle di inferenza per il monitoraggio dei modelli serviti. Il diagramma seguente mostra un flusso di lavoro tipico con tabelle di inferenza. La tabella di inferenza acquisisce automaticamente le richieste in ingresso e le risposte in uscita per un endpoint di gestione del modello e le registra come tabella Delta del catalogo Unity. È possibile usare i dati in questa tabella per monitorare, eseguire il debug e migliorare i modelli di Machine Learning.

Che cosa sono le tabelle di inferenza?

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. Le tabelle di inferenza semplificano il monitoraggio e la diagnostica per i modelli registrando continuamente gli input e le risposte delle richieste (stime) dagli endpoint di gestione del modello di intelligenza artificiale Mosaic e salvandoli in una tabella Delta nel catalogo unity. È quindi possibile usare tutte le funzionalità della piattaforma Databricks, ad esempio query SQL di Databricks, notebook e Monitoraggio Lakehouse per monitorare, eseguire il debug e ottimizzare i modelli.

È possibile abilitare le tabelle di inferenza in qualsiasi endpoint del modello esistente o appena creato e le richieste a tale endpoint vengono quindi registrate automaticamente in una tabella in UC.

Di seguito sono riportate alcune applicazioni comuni per le tabelle di inferenza:

• 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. Dati di log delle tabelle di inferenza, ad esempio codici di stato HTTP, tempi di esecuzione del modello e codice JSON di richiesta e risposta. È possibile usare questi dati sulle prestazioni a scopo di debug. È anche possibile usare i dati cronologici nelle tabelle di inferenza per confrontare le prestazioni del modello sulle richieste cronologiche.
• Creare un corpus per il training. Unendo tabelle di inferenza 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 Job di Databricks, è possibile configurare un ciclo di feedback continuo e automatizzare il riaddestramento.

Requisiti

• L'area di lavoro deve avere Unity Catalog abilitato.
• 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 che il modificatore devono avere le autorizzazioni seguenti nel catalogo Unity:
  • USE CATALOG autorizzazioni per il catalogo specificato.
  • USE SCHEMA autorizzazioni per lo schema specificato.
  • CREATE TABLE autorizzazioni nello schema.

Abilitare e disabilitare le tabelle di inferenza

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

Il proprietario delle tabelle di inferenza è l'utente che ha creato l'endpoint. Tutti gli elenchi di controllo di accesso (ACL) nella tabella seguono le autorizzazioni standard del catalogo Unity e possono essere modificati dal proprietario della tabella.

Avviso

La tabella di inferenza potrebbe essere danneggiata se si esegue una delle operazioni seguenti:

• Modificare lo schema della tabella.
• Modificare il nome della tabella.
• Eliminare la tabella.
• Perdere le autorizzazioni per un catalogo o uno schema di Unity Catalog.

In questo caso, il auto_capture_config dello stato dell'endpoint mostra uno stato FAILED per la tabella del payload. In questo caso, è necessario creare un nuovo endpoint per continuare a usare le tabelle di inferenza.

Per abilitare le tabelle di inferenza 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. Selezionare Abilitare le tabelle di inferenza.

4. Nei menu a discesa selezionare il catalogo e lo schema desiderati in cui si desidera trovare la tabella.

   

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

6. Cliccare Crea l'endpoint di servizio.

È anche possibile abilitare le tabelle di inferenza 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 Aggiorna l'endpoint di servizio.

Seguire queste istruzioni per disabilitare le tabelle di inferenza:

1. Passare alla pagina dell'endpoint.
2. Cliccare Modifica configurazione.
3. Fare clic su Abilita tabella di inferenza per rimuovere il segno di spunta.
4. Una volta soddisfatte le specifiche dell'endpoint, fare clic su Aggiorna.

flusso di lavoro : monitorare le prestazioni del modello usando le tabelle di inferenza

Per monitorare le prestazioni del modello usando le tabelle di inferenza, seguire questa procedura:

1. Abilita tabelle di inferenza nel tuo endpoint, durante la creazione dell'endpoint o aggiornandolo in seguito.
2. Pianificare un flusso di lavoro per elaborare i payload JSON nella tabella di inferenza decomprimendoli in base allo schema dell'endpoint.
3. (Facoltativo) Unire le richieste e le risposte decompresse con etichette di verità di base per consentire il calcolo delle metriche di qualità del modello.
4. Creare un monitoraggio sulla tabella Delta risultante e aggiornare le metriche.

I notebook di avvio implementano questo flusso di lavoro.

Notebook di avvio per il monitoraggio di una tabella di inferenza

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

Notebook iniziale della tabella di inferenza per il monitoraggio di Lakehouse

Prendi il notebook

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

Il notebook seguente decomprime le richieste da una tabella di inferenza, 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 per la tabella di inferenza LLM Lakehouse Monitoring

Ottieni il notebook

Eseguire query e analizzare i risultati nella tabella di inferenza

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

Per visualizzare la tabella nell'interfaccia utente: Nella pagina dell'endpoint fare clic sul nome della tabella di inferenza per aprire la tabella in Esplora cataloghi.

Per eseguire query sulla tabella da DBSQL o da un notebook di Databricks: È possibile eseguire codice simile al seguente per eseguire una query sulla tabella di inferenza.

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

Se sono state abilitate le tabelle di inferenza usando l'interfaccia utente, payload_table è il nome della tabella assegnato al momento della creazione dell'endpoint. Se sono state abilitate le tabelle di inferenza usando l'API, payload_table viene segnalato nella sezione state della risposta auto_capture_config. Per un esempio, vedere Abilitare le tabelle di inferenza nei modelli che servono gli endpoint usando l'API.

Note relative alle prestazioni

Dopo aver richiamato l'endpoint, è possibile visualizzare la chiamata registrata nella tabella di inferenza 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.

Schema della tabella di inferenza del catalogo Unity

Ogni richiesta e risposta registrata in una tabella di inferenza viene scritta in una tabella Delta con lo schema seguente:

Nota

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

Nome colonna	Descrizione	Tipo
databricks_request_id	Identificatore di richiesta generato da Azure Databricks associato a tutte le richieste di gestione del modello.	STRING
client_request_id	Identificatore di richiesta generato dal client facoltativo che può essere specificato nel corpo della richiesta di gestione 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, dove 1 rappresenta 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 impiegato per generare stime dal modello.	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 identificatore per una richiesta che appare nella tabella di inferenza finale sotto il client_request_id e può essere utilizzato per collegare la propria richiesta ad altre tabelle che usano il client_request_id, come ad esempio il collegamento dell'etichetta di verità di riferimento. 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 altre tabelle con etichette associate alla client_request_id.

Limiti

• Le chiavi gestite dal cliente (CMK) non sono supportate.
• Per gli endpoint che ospitano modelli fondamentali , le tabelle di inferenza sono supportate solo nei carichi di lavoro con throughput fornito .
• La presenza del Firewall di Azure può causare errori nella creazione della tabella Delta nel Catalogo Unity, quindi non è supportata per impostazione predefinita. Contattare il team dell'account Databricks per abilitarlo.
• Quando le tabelle di inferenza sono abilitate, il limite per la concorrenza massima totale in tutti i modelli serviti in un singolo endpoint è 128. Contattare il team dell'account Azure Databricks per richiedere un aumento di questo limite.
• Se una tabella di inferenza contiene più di 500.000 file, non vengono registrati dati aggiuntivi. Per evitare di superare questo limite, eseguire OPTIMIZE o configurare la conservazione nella tabella eliminando i dati meno recenti. Per controllare il numero di file nella tabella, eseguire DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• Il recapito dei log delle tabelle di inferenza è attualmente ottimale, ma è possibile prevedere che i log siano disponibili entro 1 ora da una richiesta. Per maggiori informazioni, contattare il team dell'account Databricks.

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