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

info

Visualização

Esse recurso está em Public Preview.

important

Este artigo descreve os tópicos que se aplicam às tabelas de inferência para modelos personalizados. Para modelos externos ou cargas de trabalho de taxa de transferência de provisionamento, use tabelas de inferência habilitadas peloAI Gateway.

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

O que são tabelas de inferência?

O monitoramento do desempenho dos modelos em fluxo de trabalho de produção é um aspecto importante do ciclo de vida dos modelos AI e ML. As tabelas de inferência simplificam o monitoramento e o diagnóstico dos modelos, registrando continuamente as entradas e respostas das solicitações de serviço (previsões) do ponto de extremidade Mosaic AI Model Serving e salvando-as em uma tabela Delta em Unity Catalog. Em seguida, o senhor pode usar todos os recursos da plataforma Databricks, como Databricks SQL queries, Notebook e lakehouse monitoring para monitorar, depurar e otimizar seus modelos.

O senhor pode ativar tabelas de inferência em qualquer modelo de serviço existente ou recém-criado endpoint, e as solicitações para esse endpoint são então automaticamente registradas em uma tabela no UC.

Alguns aplicativos comuns para tabelas de inferência são os seguintes:

• Monitore os dados e a qualidade do modelo. O senhor pode monitorar continuamente o desempenho do modelo e o desvio de dados usando o lakehouse monitoramento. O lakehouse monitoramento gera automaticamente painéis de qualidade de dados e modelos que o senhor pode compartilhar com as partes interessadas. Além disso, o senhor pode ativar o alerta para saber quando precisa treinar novamente o modelo com base em mudanças nos dados recebidos ou reduções no desempenho do modelo.
• Depure problemas de produção. Tabelas de inferência log dados como códigos de status HTTP, tempos de execução do modelo e código JSON de solicitação e resposta. O senhor pode usar esses dados de desempenho para fins de depuração. O senhor também pode usar os dados históricos em Inference Tables para comparar o desempenho do modelo em solicitações históricas.
• Criar um corpus de treinamento. Ao juntar as tabelas de inferência com o rótulo de verdade terrestre, o senhor pode criar um corpus de treinamento que pode ser usado para retreinar ou ajustar e melhorar seu modelo. Usando o Databricks Jobs, o senhor pode configurar um loop de feedback contínuo e automatizar o re-treinamento.

Requisitos

• Seu workspace deve ter o Unity Catalog habilitado.
• Tanto o criador do endpoint quanto o modificador devem ter permissão para gerenciar o endpoint. Consulte Listas de controle de acesso.
• Tanto o criador do site endpoint quanto o modificador devem ter as seguintes permissões em Unity Catalog:
  • USE CATALOG permissões no catálogo especificado.
  • USE SCHEMA permissões no esquema especificado.
  • CREATE TABLE permissões no esquema.

Ativar e desativar tabelas de inferência

Esta seção mostra como ativar ou desativar tabelas de inferência usando a interface do usuário do Databricks. O senhor também pode usar o API; consulte Habilitar tabelas de inferência no endpoint servindo modelo usando o API para obter instruções.

O proprietário das tabelas de inferência é o usuário que criou o site 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.

atenção

A tabela de inferência pode ficar 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 endpoint mostra um estado FAILED para a tabela de carga útil. Se isso acontecer, o senhor deverá criar um novo endpoint para continuar usando as tabelas de inferência.

Para ativar as tabelas de inferência durante a criação do endpoint, siga as etapas abaixo:

1. Clique em Serving na UI do Databricks Mosaic AI.

2. Clique em Criar endpoint de serviço .

3. Selecione Habilitar tabelas de inferência .

4. Nos menus suspensos, selecione o catálogo e o esquema desejados onde você gostaria que a tabela fosse localizada.

   

5. O nome da tabela default é <catalog>.<schema>.<endpoint-name>_payload. Se desejar, você pode inserir um prefixo de tabela personalizado.

6. Clique em Criar endpoint de serviço .

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

1. Navegue até a página do seu endpoint.
2. Clique em Editar configuração .
3. Siga as instruções anteriores, começando com a etapa 3.
4. Quando terminar, clique em Update serving endpoint .

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

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

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

Para monitorar o desempenho do modelo usando tabelas de inferência, siga estas etapas:

1. Habilite as tabelas de inferência em seu endpoint, seja durante a criação do endpoint ou atualizando-o posteriormente.
2. Programar um fluxo de trabalho para processar os payloads do JSON na tabela de inferência, desempacotando-os de acordo com o esquema do endpoint.
3. (Opcional) junte as solicitações e respostas descompactadas com o rótulo de verdade terrestre para permitir que as métricas de qualidade do modelo sejam calculadas.
4. Crie um monitor sobre a tabela Delta resultante e refresh as métricas.

O Notebook para iniciantes implementa esse fluxo de trabalho.

Starter Notebook para monitoramento de uma tabela de inferência

O Notebook a seguir implementa as etapas descritas acima para descompactar as solicitações de uma tabela de inferência de monitoramento de lakehouse. O Notebook pode ser executado sob demanda ou em uma programação recorrente usando o siteDatabricks Jobs.

Tabela de inferência lakehouse monitoramento starter Notebook

Open notebook in new tab

Starter Notebook para monitorar a qualidade do texto de LLMs que atendem a endpoints

O Notebook a seguir descompacta as solicitações de uma tabela de inferência, calcula 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 o siteDatabricks Jobs.

LLM tabela de inferência lakehouse monitoramento starter Notebook

Open notebook in new tab

Consulte e analise os resultados na tabela de inferência

Depois que os modelos atendidos estiverem prontos, todas as solicitações feitas aos modelos serão registradas automaticamente na tabela de inferência, juntamente com as respostas. O senhor pode acessar view a tabela na interface do usuário, consultar a tabela a partir do DBSQL ou de um notebook, ou consultar a tabela usando o REST API.

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

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

SQL

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

Se o senhor ativou tabelas de inferência usando a interface do usuário, payload_table é o nome da tabela que o senhor atribuiu quando criou o endpoint. Se o senhor tiver ativado as tabelas de inferência usando a API, payload_table será relatado na seção state da resposta auto_capture_config. Para obter um exemplo, consulte Habilitar tabelas de inferência no endpoint servindo modelo usando o API.

Nota de desempenho

Depois de invocar o endpoint, o senhor pode ver os registros de invocação na sua tabela de inferências dentro de uma hora após o envio de uma solicitação de pontuação. Além disso, Databricks garante que a entrega de log ocorra pelo menos uma vez, portanto, é possível, embora improvável, que logs duplicado seja enviado.

Esquema da tabela de inferência do Unity Catalog

Cada solicitação e resposta que recebe registros em uma tabela de inferência é gravada em uma tabela Delta com o seguinte esquema:

nota

Se o senhor invocar o endpoint com um lote de entradas, o lote inteiro será registrado como uma linha.

Nome da coluna	Descrição	Tipo
databricks_request_id	Um identificador de solicitação gerado pelo site Databricks anexado a todas as solicitações de servindo modelo.	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 serviço. Consulte Specify client_request_id para obter mais informações.	String
date	A data UTC em que a solicitação do modelo de serviço foi recebida.	Data
timestamp_ms	O registro de data e hora em milissegundos de época em que a solicitação do modelo de serviço foi recebida.	Long
status_code	O código de status HTTP que foi retornado do modelo.	INT
sampling_fraction	A fração de amostragem usada no caso de a solicitação ter sido reduzida. Esse valor está entre 0 e 1, em que 1 representa que 100% das solicitações recebidas foram incluídas.	double
execution_time_ms	O tempo de execução em milissegundos para o qual o modelo realizou a inferência. Isso não inclui latências de rede aérea e representa apenas o tempo necessário para o modelo gerar previsões.	Long
request	O corpo bruto da solicitação JSON que foi enviado para o modelo de serviço endpoint.	String
response	O corpo da resposta bruta JSON que foi retornado pelo modelo de serviço endpoint.	String
request_metadata	Um mapa de metadados relacionados ao modelo de serviço endpoint associado à solicitação. Esse mapa contém o nome endpoint, o nome do modelo e a versão do modelo usados para o seu endpoint.	MAP<strings, strings>

Especificar client_request_id

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

JSON

{
  "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 site client_request_id pode ser usado posteriormente para a junção de rótulos de verdade se houver outras tabelas que tenham rótulos associados ao site client_request_id.

Limitações

• Não há suporte para a chave gerenciadora do cliente.
• 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.
• AWS O PrivateLink não é compatível com o site default. Entre em contato com a equipe do Databricks account para habilitá-lo.
• Quando as tabelas de inferência estão ativadas, o limite para a simultaneidade máxima total em todos os modelos atendidos em um único endpoint é 128. Entre em contato com a equipe do Databricks account para solicitar um aumento desse limite.
• Se uma tabela de inferência contiver mais de 500 mil arquivos, nenhum dado adicional será registrado. Para evitar exceder esse limite, execute OPTIMIZE ou configure a retenção em sua tabela, excluindo dados antigos. Para verificar o número de arquivos em sua tabela, execute DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• Tabelas de inferência log Atualmente, a entrega é feita com o máximo de esforço, mas o senhor pode esperar que o logs esteja disponível em até 1 hora após a solicitação. Entre em contato com a equipe do Databricks account para obter mais informações.

Para conhecer as limitações gerais do servindo modelo endpoint, consulte limites e regiões do servindo modelo.