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

Importante

Esse recurso está em uma versão prévia.

Este artigo descreve as tabelas de inferência para monitorar os 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 as solicitações de entrada e as respostas de saída para um ponto de extremidade de serviço de modelo e as registra como uma tabela Delta do Catálogo do Unity. Você pode utilizar os dados dessa tabela para monitorar, depurar e melhorar os modelos de ML.

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

O que são tabelas de inferência?

Monitorar o desempenho dos modelos nos fluxos 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ções de veiculação (previsões) dos pontos de extremidade do Serviço do Modelo do Mosaic AI e salvando-as em uma tabela Delta no Catálogo do Unity. Você pode usar todas as capacidades da plataforma do Databricks, como consultas ao SQL, notebooks e Lakehouse Monitoring do Databricks para monitorar, depurar e otimizar seus modelos.

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

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

• Monitoramento da qualidade dos dados e do modelo. Você pode monitorar continuamente o desempenho do modelo e o descompasso de dados usando o Monitoramento do Lakehouse. O Monitoramento do Lakehouse gera automaticamente painéis de qualidade de dados e modelo que você pode compartilhar com os stakeholders. Além disso, você pode habilitar alertas para saber quando precisa treinar novamente seu modelo com base em mudanças nos dados de entrada ou em reduções no desempenho do modelo.
• Depuração de problemas de produção. As Tabelas de Inferência registram dados como código 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 em Tabelas de Inferência para comparar o desempenho do modelo em solicitações históricas.
• Criação de um corpus de treinamento. Ao unir Tabelas de Inferência com rótulos de verdade terrestre, você pode criar um corpus de treinamento que pode ser usado para retreinar ou ajustar e aprimorar seu modelo. Com os trabalhos do Databricks, você pode configurar um loop contínuo de comentários e automatizar o retreinamento.

Requisitos

• Seu workspace precisa estar com o Catálogo do Unity habilitado.
• Tanto o criador do ponto de extremidade quanto o modificador devem ter a permissão Pode gerenciar no ponto de extremidade. Confira Listas de Controle de Acesso.
• Tanto o criador do ponto de extremidade quanto o modificador devem ter as seguintes permissões no Catálogo do Unity:
  • Permissões USE CATALOG no catálogo especificado.
  • Permissões USE SCHEMA no esquema especificado.
  • Permissões CREATE TABLE 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 ACLs (listas de controle de acesso) na tabela seguem as permissões padrão do Catálogo do Unity e podem ser modificadas pelo proprietário da tabela.

Aviso

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

• Alterar o esquema da tabela.
• Alterar o nome da tabela.
• Excluir a tabela.
• Perder permissões para o catálogo ou esquema do Catalog do Unity.

Nesse caso, o auto_capture_config do status do ponto de extremidade mostra um estado FAILED para a tabela de conteúdo. 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 Veiculação na interface do usuário do Databricks Mosaic AI.

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

3. Selecione Habilitar tabelas de inferência.

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

   

5. O nome da tabela padrão é <catalog>.<schema>.<endpoint-name>_payload. Se quiser, 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 de extremidade.
2. Clique em Editar configuração.
3. Siga as instruções anteriores, começando com a etapa 3.
4. Quando terminar, clique em Atualizar o ponto de extremidade de serviço.

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

1. Navegue até a página do ponto de extremidade.
2. Clique em Editar configuração.
3. Clique em Habilitar tabela de inferência para remover a marca de seleção.
4. Depois de ficar satisfeito com as especificações do ponto de extremidade, clique em 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 tabelas de inferência em seu ponto de extremidade, durante a criação dele ou atualizando-o posteriormente.
2. Faça o agendamento de um fluxo de trabalho para processar os conteúdos JSON na tabela de inferência descompactando-os de acordo com o esquema do ponto de extremidade.
3. (Opcional) Junte as solicitações e respostas desempacotadas com rótulos de veracidade para permitir que as métricas de qualidade do modelo sejam calculadas.
4. Crie um monitoramento para a tabela Delta resultante e atualize as métricas.

Os notebooks iniciais implementam esse fluxo de trabalho.

Notebook inicial para monitorar uma tabela de inferência

O notebook a seguir implementa as etapas descritas acima para desempacotar solicitações de uma tabela de inferência de monitoramento do Lakehouse. O notebook pode ser executado sob demanda ou em um agendamento recorrente usando Trabalhos do Databricks.

Notebook inicial de monitoramento de tabela de inferência do Lakehouse

Obter notebook

Notebook inicial para monitorar a qualidade do texto dos pontos de extremidade que servem LLMs

O notebook a seguir desempacota 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 um agendamento recorrente usando Trabalhos do Databricks.

Notebook inicial para monitoramento de Lakehouse usando tabela de inferência de LLM

Obter notebook

Consultar e analisar resultados na tabela de inferência

Depois que os modelos servidos estiverem prontos, todas as solicitações feitas aos modelos serão registradas automaticamente na tabela de inferência. Você pode exibir a tabela na interface do usuário, consultar a tabela a partir do DBSQL ou de um notebook ou consultá-la 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 abrir a tabela no Gerenciador de Catálogos.

Para consultar a tabela a partir do DBSQL ou de um notebook do 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 será 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 será relatado na seção state da resposta auto_capture_config. Para obter um exemplo, consulte Habilitar tabelas de inferência em pontos de extremidade de serviço de modelo usando a API.

Observação de 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 Catálogo Unity

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

Observação

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

Nome da coluna	Descrição	Tipo
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 a solicitação de serviço de modelo foi recebida.	DATE
timestamp_ms	O carimbo de data/hora em milissegundos de época em que a solicitação de serviço do modelo 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 o pedido ter sido reduzido para baixo. Esse valor está entre 0 e 1, onde 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 inferência. Isso não inclui latências de rede de sobrecarga e representa apenas o tempo necessário para o modelo gerar previsões.	LONG
request	O corpo JSON da 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 ponto de extremidade de serviço de modelo associado à solicitação. Este mapa contém o nome do ponto de extremidade, o nome do modelo e a versão do modelo usados para o ponto de extremidade.	MAP<STRING, STRING>

Especificar client_request_id

O campo client_request_id é 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 client_request_id e pode ser usado para unir sua solicitação com outras tabelas que usam client_request_id, como a junçã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 houver client_request_id especificado, o valor aparecerá como null 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ótulo verdade de terra 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 básico, as tabelas de inferência só têm suporte em cargas de trabalho de taxa de transferência provisionada.
• O Firewall do Azure não tem suporte por padrão e pode resultar em falhas na criação da tabela Delta do Catálogo do Unity. Entre em contato com sua equipe de conta 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 fornecidos em um único ponto de extremidade é 128. Alcance a equipe da sua conta do Azure Databricks 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 mais antigos. Para verificar o número de arquivos em sua tabela, execute DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• A entrega de logs de tabelas de inferência é atualmente 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 a equipe da sua conta do Databricks para obter mais informações.

Para obter informações sobre limitações de modelos de ponto de extremidade de serviço de caráter geral, confira limites e regiões de modelos de serviço.