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

Importante

Esta funcionalidade está em Pré-visualização Pública.

Este artigo descreve tabelas de inferência para monitorar modelos servidos. 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 modelo de ponto de extremidade de serviço e as registra como uma tabela Delta do Unity Catalog. Você pode usar os dados nesta tabela para monitorar, depurar e melhorar modelos de ML.

Para pontos de extremidade de serviço de modelo que hospedam modelos externos, você só pode habilitar tabelas de inferência usando o AI Gateway.

O que são tabelas de inferência?

O monitoramento do desempenho de modelos em fluxos de trabalho de produção é um aspeto 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 as entradas e respostas de solicitações (previsões) do Mosaic AI Model Serving endpoints e salvando-as em uma tabela Delta no Unity Catalog. Em seguida, você pode usar todos os recursos da plataforma Databricks, como consultas Databricks SQL, notebooks e Lakehouse Monitoring para monitorar, depurar e otimizar seus modelos.

Você pode habilitar tabelas de inferência em qualquer modelo de ponto de extremidade de serviço existente ou recém-criado, e as solicitações para esse ponto de extremidade são automaticamente registradas em uma tabela na UC.

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

• Monitore a qualidade dos dados e 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 habilitar alertas para saber quando precisa treinar novamente seu modelo com base em mudanças nos dados recebidos ou reduções no desempenho do modelo.
• Depurar problemas de produção. As Tabelas de Inferência registram dados como códigos de status HTTP, tempos de execução do 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 os dados históricos nas Tabelas de Inferência para comparar o desempenho do modelo em solicitações históricas.
• Crie um corpus de formação. Ao unir as Tabelas de Inferência com rótulos de verdade básica, você pode criar um corpus de treinamento que pode ser usado para treinar novamente ou ajustar e melhorar seu modelo. Usando o Databricks Jobs, você pode configurar um ciclo de feedback contínuo e automatizar o retreinamento.

Requerimentos

• Seu espaço de trabalho deve ter o Unity Catalog habilitado.
• Tanto o criador do ponto de extremidade quanto o modificador devem ter a permissão Pode gerenciar no ponto de extremidade. Consulte Listas de controle de acesso.
• Tanto o criador do ponto de extremidade quanto o modificador devem ter as seguintes permissões no Unity Catalog:
  • 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 interface do usuário do Databricks. Você também pode usar a API; consulte Habilitar tabelas de inferência em pontos de extremidade de serviço de modelo usando a API para obter instruções.

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

Aviso

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.
• Perca permissões para o catálogo ou esquema do Catálogo Unity.

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

Para habilitar tabelas de inferência durante a criação do ponto de extremidade, use as seguintes etapas:

1. Clique em Servindo na interface do usuário do Databricks Mosaic AI.

2. Clique em Criar ponto de extremidade de serviço.

3. Selecione Ativar tabelas de inferência.

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

   

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

6. Clique em Criar ponto de extremidade de serviço.

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

1. Navegue até a página do ponto final.
2. Clique em Editar configuração.
3. Siga as instruções anteriores, começando com o passo 3.
4. Quando terminar, clique em Atualizar ponto de extremidade de serviço.

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

1. Navegue até a página do ponto final.
2. Clique em Editar configuração.
3. Clique em Ativar tabela de inferência para remover a marca de seleção.
4. Quando estiver satisfeito com as especificações do ponto final, 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 estas etapas:

1. Habilite tabelas de inferência em seu ponto de extremidade, durante a criação do ponto de extremidade ou atualizando-o posteriormente.
2. Agende um fluxo de trabalho para processar as cargas úteis JSON na tabela de inferência, descompactando-as de acordo com o esquema do ponto de extremidade.
3. (Opcional) Junte-se às solicitações e respostas descompactadas com rótulos de verdade básica para permitir que as métricas de qualidade do modelo sejam calculadas.
4. Crie um monitor sobre a tabela Delta resultante e atualize as métricas.

Os blocos de anotações iniciais implementam esse fluxo de trabalho.

Caderno inicial para monitorar uma tabela de inferência

O bloco de anotações a seguir implementa as etapas descritas acima para descompactar solicitações de uma tabela de inferência do Lakehouse Monitoring. O bloco de anotações pode ser executado sob demanda ou em uma programação recorrente usando o Databricks Jobs.

Tabela de inferência Lakehouse Monitoring starter notebook

Obter o bloco de notas

Bloco de anotações inicial para monitorar a qualidade do texto de pontos finais que atendem LLMs

O bloco de anotações a seguir descompacta 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 bloco de anotações pode ser executado sob demanda ou em uma programação recorrente usando o Databricks Jobs.

Tabela de inferência LLM Lakehouse Monitoring starter notebook

Obter o bloco de notas

Consultar e analisar 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. Você pode exibir a tabela na interface do usuário, consultar a tabela do DBSQL ou de um bloco de anotações ou consultar a tabela usando a API REST.

Para exibir a tabela na interface do usuário: Na página do ponto de extremidade, clique no nome da tabela de inferência para abri-la no Gerenciador de Catálogos.

Para consultar a tabela a partir do DBSQL ou de um bloco de anotações Databricks: Você pode executar um código semelhante ao seguinte para consultar a tabela de inferência.

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

Se você habilitou tabelas de inferência usando a interface do usuário, payload_table é o nome da tabela que você atribuiu quando criou o ponto de extremidade. Se você habilitou tabelas de inferência usando a API, payload_table é relatado state na seção da auto_capture_config resposta. Para obter um exemplo, consulte Habilitar tabelas de inferência em pontos de extremidade de serviço de modelo usando a API.

Nota sobre o desempenho

Depois de invocar o ponto de extremidade, você pode ver a invocação registrada em sua tabela de inferência dentro de uma hora após o envio de uma solicitação de pontuação. Além disso, o Azure Databricks garante que a entrega de logs aconteça pelo menos uma vez, portanto, é possível, embora improvável, que logs duplicados sejam enviados.

Esquema da tabela de inferência do Unity Catalog

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

Nota

Se você invocar o ponto de extremidade com um lote de entradas, todo o lote será registrado como uma linha.

Nome da coluna	Description	Type
databricks_request_id	Um identificador de solicitação gerado pelo Azure Databricks anexado a todas as solicitações de serviço de modelo.	STRING
client_request_id	Um identificador de solicitação gerado pelo cliente opcional que pode ser especificado no corpo da solicitação de serviço do modelo. Consulte Especificar client_request_id para obter mais informações.	STRING
date	A data UTC em que o modelo de solicitação de notificação foi recebido.	DATE
timestamp_ms	O carimbo de data/hora em milissegundos de época quando a solicitação de serviço do modelo foi recebida.	LONGO
status_code	O código de status HTTP que foi retornado do modelo.	INT
sampling_fraction	A fração de amostragem utilizada no caso de o pedido ter sido reduzido para amostragem. Esse valor está entre 0 e 1, onde 1 representa que 100% das solicitações recebidas foram incluídas.	DUPLO
execution_time_ms	O tempo de execução em milissegundos para o qual o modelo realizou inferência. Isso não inclui latências de rede de sobrecarga e representa apenas o tempo que o modelo levou para gerar previsões.	LONGO
request	O corpo JSON de solicitação bruta que foi enviado para o ponto de extremidade de serviço do modelo.	STRING
response	O corpo JSON de resposta bruta que foi retornado pelo ponto de extremidade de serviço do modelo.	STRING
request_metadata	Um mapa de metadados relacionados ao modelo que serve o ponto de extremidade associado à solicitação. Este mapa contém o nome do ponto de extremidade, o nome do modelo e a versão do modelo usado para o seu ponto de extremidade.	CADEIA DE CARACTERES DO MAPA<, STRING>

Especificar client_request_id

O client_request_id campo é um valor opcional que o usuário pode fornecer no corpo da solicitação de serviço do 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 sob o client_request_id e pode ser usado para unir sua solicitação com outras tabelas que usam o , como a client_request_idjunção de rótulo de verdade básica. Para especificar um client_request_id, inclua-o como uma chave de nível superior da carga útil da solicitação. Se não 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 pode ser usado posteriormente para junções de rótulos de verdade de base se houver outras tabelas que tenham rótulos associados ao client_request_id.

Limitações

• Não há suporte para chaves gerenciadas pelo cliente.
• Para pontos de extremidade que hospedam modelos de base, as tabelas de inferência só são suportadas em cargas de trabalho de taxa de transferência provisionadas.
• O Firewall do Azure pode resultar em falhas na criação da tabela Delta do Catálogo Unity, portanto, não é suportado por padrão. Entre em contato com sua equipe de conta Databricks para ativá-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 ponto de extremidade é 128. Entre em contato com sua equipe de conta do Azure Databricks para solicitar um aumento até esse limite.
• Se uma tabela de inferência contiver mais de 500 mil arquivos, nenhum dado adicional será registrado. Para evitar exceder esse limite, execute OTIMIZE ou configure a retenção em sua tabela excluindo dados mais antigos. Para verificar o número de ficheiros na tabela, execute DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• Atualmente, a entrega de logs de tabelas de inferência é o melhor esforço, mas você pode esperar que os logs estejam disponíveis dentro de 1 hora após uma solicitação. Entre em contato com sua equipe de conta Databricks para obter mais informações.

Para obter limitações gerais do modelo que serve o ponto de extremidade, consulte Limites e regiões do serviço de modelo.