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.
Para endpoints que hospedam modelos externos, o senhor só pode ativar tabelas de inferência usando o IA Gateway.
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 do modelo de 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.
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.
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.
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 Serving na UI do Databricks Mosaic AI.
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:
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 as solicitações de uma tabela de inferência de monitoramento de lagoas. O Notebook pode ser executado sob demanda ou em uma programação recorrente usando o site Databricks Jobs.
Notebook inicial para monitoramento da qualidade do texto do endpoint atendendo LLMs
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 site Databricks Jobs.
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.
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, 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 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 |
---|---|---|
|
Um identificador de solicitação gerado pelo Databricks anexado a todas as solicitações de modelo de atividade. |
String |
|
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 |
|
A data UTC em que a solicitação do modelo interativo foi recebida. |
Data |
|
O carimbo de data/hora em milissegundos de época em que a solicitação do modelo instalado foi recebida. |
Long |
|
O código de status HTTP retornado do modelo. |
INT |
|
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 |
|
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 |
|
O corpo JSON da solicitação bruta que foi enviado ao endpoint do modelo de atividade. |
String |
|
O corpo JSON da resposta bruta que foi retornado pelo endpoint do modelo funcional. |
String |
|
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.
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>
.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 dos endpoints do modelo servindo, consulte Limites e regiões do modelo servindo.