Tabelas de inferência para modelos de monitoramento e depuração

Visualização

Esse recurso está em visualização pública.

Este artigo descreve tabelas de inferência para modelos de monitoramento atendidos. O diagrama a seguir mostra um fluxo de trabalho típico com tabelas de inferência. A tabela de inferência captura automaticamente solicitações de entrada e respostas de saída para um endpoint de modelo autônomo e as logs como uma tabela Delta Unity Catalog . Você pode usar os dados desta tabela para monitorar, depurar e melhorar modelos de ML.

O que são tabelas de inferência?

Monitorar o desempenho dos modelos no fluxo de trabalho de produção é um aspecto importante do ciclo de vida do modelo de IA e ML. As tabelas de inferência simplificam o monitoramento e o diagnóstico de modelos, registrando continuamente entradas e respostas de solicitação de serviço (previsões) do endpoint do modelo operacional do Databricks e salvando-as em uma tabela Delta no Unity Catalog. Você pode então usar todos os recursos da plataforma Databricks, como query DBSQL, Notebook e Lakehouse Monitoring para monitorar, depurar e otimizar seus modelos.

Você pode habilitar tabelas de inferência em qualquer endpoint de modelo de operação existente ou recém-criado, e as solicitações para esse endpoint serão automaticamente logs em uma tabela no UC.

Algumas aplicações comuns para tabelas de inferência são as seguintes:

Monitore os dados e a qualidade do modelo. Você pode monitorar continuamente o desempenho do seu modelo e o desvio de dados usando o Lakehouse Monitoring. O Lakehouse Monitoring gera automaticamente dados e painéis de qualidade de modelo que você pode compartilhar com as partes interessadas. Além disso, você pode ativar o alerta para saber quando precisa treinar novamente seu modelo com base em mudanças nos dados recebidos ou em reduções no desempenho do modelo.
Depure problemas de produção. As tabelas de inferência logs dados como códigos de status HTTP, tempos de execução de modelo e código JSON de solicitação e resposta. Você pode usar esses dados de desempenho para fins de depuração. Você também pode usar o histórico de dados em Tabelas de Inferência para comparar o desempenho do modelo em solicitações históricas.
Crie um corpus de treinamento. Ao juntar tabelas de inferência com rótulo de verdade, você pode criar um corpus de treinamento que pode ser usado para treinar novamente ou ajustar e melhorar seu modelo. Usando Databricks Workflows, você pode configurar um ciclo de feedback contínuo e automatizar o novo treinamento.

Requisitos

Seu workspace deve ter o Unity Catalog habilitado.
Para habilitar tabelas de inferência em um endpoint, tanto o criador do endpoint quanto o modificador precisam das seguintes permissões:
- PODE GERENCIAR a permissão no site endpoint.
- USE CATALOG permissões no catálogo especificado.
- USE SCHEMA permissões no esquema especificado.
- CREATE TABLE permissões no esquema.

Habilitar e desabilitar tabelas de inferência

Esta seção mostra como habilitar ou desabilitar tabelas de inferência usando a UI do Databricks. Você também pode usar a API; consulte Habilitar tabelas de inferência no endpoint do modelo operacional usando a API para obter instruções.

O proprietário das tabelas de inferência é o usuário que criou o endpoint. Todas as listas de controle de acesso (ACLs) na tabela seguem as permissões padrão do Unity Catalog e podem ser modificadas pelo proprietário da tabela.

Aviso

A tabela de inferência poderá ser corrompida se você fizer o seguinte:

Altere o esquema da tabela.
Altere o nome da tabela.
Exclua a tabela.
Perder permissões para o catálogo ou esquema do Unity Catalog.

Nesse caso, o auto_capture_config do status do endpoint mostra um estado FAILED para a tabela de carga útil. Se isso acontecer, você deverá criar um novo endpoint para continuar usando tabelas de inferência.

Para habilitar tabelas de inferência durante a criação do endpoint, use os seguintes passos:

Clique em Servir na IU do Databricks Machine Learning.
Clique em Criar endpoint de serviço.
Selecione Habilitar tabelas de inferência.
Nos menus suspensos, selecione o catálogo e o esquema desejados onde você gostaria que a tabela fosse localizada.
O nome da tabela default é <catalog>.<schema>.<endpoint-name>_payload. Se desejar, você pode inserir um prefixo de tabela personalizado.
Clique em Criar endpoint de serviço.

Você também pode ativar tabelas de inferência em um endpoint existente. Para editar uma configuração de endpoint existente, faça o seguinte:

Navegue até a página do seu endpoint.
Clique em Editar configuração.
Siga as instruções anteriores, começando pelo passo 3.
Quando terminar, clique em Atualizar endpoint de serviço.

Siga estas instruções para desabilitar tabelas de inferência:

Importante

Ao desabilitar tabelas de inferência em um endpoint, você não poderá reativá-las. Para continuar usando tabelas de inferência, você deve criar um novo endpoint e ativar tabelas de inferência nele.

Navegue até a página do seu endpoint.
Clique em Editar configuração.
Clique em Habilitar tabela de inferência para remover a marca de seleção.
Quando estiver satisfeito com as especificações do endpoint, clique em Atualizar.

fluxo de trabalho: Monitore o desempenho do modelo usando tabelas de inferência

Para monitorar o desempenho do modelo usando tabelas de inferência, siga estes passos:

Habilite tabelas de inferência em seu endpoint, durante a criação do endpoint ou atualizando-o posteriormente.
programar um fluxo de trabalho para processar as cargas JSON na tabela de inferência, descompactando-as de acordo com o esquema do endpoint.
(Opcional) join as solicitações e respostas descompactadas com rótulo de verdade para permitir o cálculo das métricas de qualidade do modelo.
Crie um monitor na tabela Delta resultante e refresh as métricas.

O Notebook inicial implementa esse fluxo de trabalho.

Starter Notebook para monitoramento de tabela de inferência

O Notebook a seguir implementa os passos descritos acima para descompactar solicitações de uma tabela de inferência do Lakehouse Monitoring. O Notebook pode ser executado sob demanda ou em uma programação recorrente usando Databricks Workflows.

Tabela de inferência Notebook inicial do Lakehouse Monitoring

Abra o bloco de anotações em outra guia

Notebook inicial para monitoramento da qualidade do texto do endpoint atendendo LLMs

O Notebook a seguir descompacta solicitações de uma tabela de inferência, compute um conjunto de métricas de avaliação de texto (como legibilidade e toxicidade) e permite o monitoramento dessas métricas. O Notebook pode ser executado sob demanda ou em uma programação recorrente usando Databricks Workflows.

Tabela de inferência LLM Lakehouse Monitoring starter Notebook

Abra o bloco de anotações em outra guia

Consultar e analisar resultados na tabela de inferência

Depois que seus modelos atendidos estiverem prontos, todas as solicitações feitas aos seus modelos serão logs automaticamente na tabela de inferência, juntamente com as respostas. Você pode view a tabela na UI, query a tabela no DBSQL ou em um Notebook ou query a tabela usando a API REST.

Para view a tabela na UI: Na página endpoint , clique no nome da tabela de inferência para abrir a tabela no Catalog Explorer.

link para o nome da tabela de inferência na página do endpoint

Para query a tabela do DBSQL ou de um Databricks Notebook: Você pode executar um código semelhante ao seguinte para query a tabela de inferência.

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

Se você ativou tabelas de inferência usando a IU, payload_table será o nome da tabela atribuído quando criou o endpoint. Se você ativou tabelas de inferência usando a API, payload_table será relatado na seção state da resposta auto_capture_config . Por exemplo, consulte Habilitar tabelas de inferência no endpoint do modelo de atividade usando a API.

Nota de desempenho

Depois de invocar o endpoint, você poderá ver os logs de invocação em sua tabela de inferência dentro de 10 minutos após enviar uma solicitação de pontuação. Além disso, o Databricks garante que a entrega logs acontece pelo menos uma vez, pelo que é possível, embora improvável, que sejam enviados logs duplicados.

Esquema da tabela de inferência Unity Catalog

Cada solicitação e resposta que obtém logs para uma tabela de inferência é gravada em uma tabela Delta com o seguinte esquema:

Observação

Se você invocar o endpoint com um lote de entradas, todos os lotes serão logs como uma linha.

Nome da coluna	Descrição	Tipo
`databricks_request_id`	Um identificador de solicitação gerado pelo Databricks anexado a todas as solicitações de modelo de atividade.	String
`client_request_id`	Um identificador de solicitação opcional gerado pelo cliente que pode ser especificado no corpo da solicitação do modelo de operação. Consulte Especificar `client_request_id` para obter mais informações.	String
`date`	A data UTC em que a solicitação do modelo interativo foi recebida.	Data
`timestamp_ms`	O carimbo de data/hora em milissegundos de época em que a solicitação do modelo instalado foi recebida.	Long
`status_code`	O código de status HTTP retornado do modelo.	INT
`sampling_fraction`	A fração de amostragem usada no caso de a solicitação ter sido reduzida. Este valor está entre 0 e 1, onde 1 representa que 100% das solicitações recebidas foram incluídas.	DOBRO
`execution_time_ms`	O tempo de execução em milissegundos durante o qual o modelo executou a inferência. Isso não inclui latências de rede suspensas e representa apenas o tempo que o modelo levou para gerar previsões.	Long
`request`	O corpo JSON da solicitação bruta que foi enviado ao endpoint do modelo de atividade.	String
`response`	O corpo JSON da resposta bruta que foi retornado pelo endpoint do modelo funcional.	String
`request_metadata`	Um mapa de metadados relacionados ao endpoint do modelo de atividade associado à solicitação. Este mapa contém o nome endpoint , o nome do modelo e a versão do modelo usado para seu endpoint.	MAP<strings, strings>

Especifique `client_request_id`

O campo client_request_id é um valor opcional que o usuário pode fornecer no corpo da solicitação do modelo funcional. Isso permite que o usuário forneça seu próprio identificador para uma solicitação que aparece na tabela de inferência final sob o client_request_id e pode ser usado para unir sua solicitação a outras tabelas que usam o client_request_id, como a junção do rótulo de verdade. Para especificar um client_request_id, inclua-o como uma key de nível superior da carga útil da solicitação. Se nenhum client_request_id for especificado, o valor aparecerá como nulo na linha correspondente à solicitação.

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

O client_request_id poderá ser usado posteriormente para join do rótulo de verdade se houver outras tabelas que tenham rótulo associado ao client_request_id.

Limitações

key de gerenciamento do cliente não é suportada.
Para endpoints que hospedam modelos de fundação, as tabelas de inferência são compatíveis apenas com cargas de trabalho de Taxa de transferência de provisionamento.
- As tabelas de inferência no endpoint de provisionamento Taxa de transferência não suportam o registro de solicitações de transmissão.
Não há suporte para tabelas de inferência em endpoints que hospedam modelos externos.
O AWS PrivateLink não é compatível por default. Entre em contato com sua equipe account do Databricks para habilitá-lo.
Quando as tabelas de inferência estão habilitadas, o limite para a simultaneidade máxima total em todos os modelos atendidos em um único endpoint é 128. Entre em contato com sua equipe account do Databricks para solicitar um aumento nesse limite.
Se uma tabela de inferência contiver mais de 500 mil arquivos, nenhum dado adicional será registrado. Para evitar exceder esse limite, execute o OPTIMIZE ou configure a retenção em sua tabela excluindo os dados mais antigos. Para verificar o número de arquivos em sua tabela, execute DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.

Para conhecer as limitações gerais dos endpoints do modelo servindo, consulte Limites e regiões do modelo servindo.